[kimixa]

> There's plenty of blame to go around, really. My current project has a workaround for a user-mode graphics driver that sets the thread name without checking if D3D11_CREATE_DEVICE_SINGLETHREADED is set -- so there's code to detect this and call SetThreadDescription() to change it back so the main thread can be found in the debugger again.

I hope that wasn't the one I worked on :P Though I'm surprised that changed much there - the flag just means we can avoid wrapping some state in mutexes (and in many paths is a NOP as the driver still uses multiple threads internally, not worth the gain for the few things they won't touch), I'm surprised that makes it rename the user thread.

[ack_complete]

From what I can tell, the driver author simply assumed that the user-mode graphics driver was running on a dedicated worker thread, and unconditionally set the thread name. However, when single-threaded mode is in use, it gets invoked on the application's thread -- and thus changes the name of the main thread instead.

CEF had this issue as well, and the result was that initializing the WebBrowser plugin in Unreal would rename the main thread there too.

[kimixa]

That's why I'm surprised - that flag doesn't mean we don't spawn worker threads for the driver, just that user API calls only come from a single thread.

I suspect this is someone assuming the flag actually mean "the driver should only use one thread" - or more likely a popular app assumed that and relied on that behavior, and the driver ended up having to emulate that behavior and you app just happened to hit whatever heuristics enabled that option.

It feels like half the driver size is due to nonsense "workarounds" like that - like the recent Fallout3/New Vegas issue was due to the app trying to autodetect the driver and versions and doing something slightly different (which hasn't really been "valid" since soon after release) - so when a version number or driver ID changes a little too much for it to cope with it completely fails - so we added an entire new "fake" driver that just lies about it's name and version.

It's honestly a PITA and something I've hit on different vendor's driver in my own projects - you can rename the executable and get completely different behavior.

It's probably not surprising that GPU drivers are hundreds of megabytes in size, even compressed :P

[ack_complete]

The thread description is only for debugging purposes, though, and is only available on newer versions of Windows 10 anyway. I'm more inclined to believe it's an oversight as games seldom request non-thread-safe operation.

As for detecting the driver, yeah, it's easy to get that wrong. IIRC, GL drivers on Windows had to limit their reported extensions because GLQuake would overflow a buffer if the extension string was too long. I also saw a game where the telemetry code had a bug and would crash if the driver description was too long. Then there was the extreme weirdness with early hybrid devices where you'd bring up DXDiag and it'd say that the system had an Intel Integrated Graphics adapter driven by an ATI graphics driver DLL!

The root of all of this is that modern GPUs/drivers/graphics APIs are hugely complex. These days, drivers have entire compilers built into them, that are expected to run as fast as possible under demanding conditions while generating efficient shaders. But again, anyone who thinks the fault mainly is on one side is getting an incomplete picture. I remember the DirectX team complaining about how in the early days of Vista about how a large %age of their driver crashes were from NVIDIA drivers. On the other hand, NVIDIA said that they had to redesign and rewrite six full drivers from scratch on top of a new architecture with incomplete documentation that was changing up to the last minute.