Direct3D 9 Over Vulkan Hits New Milestone

[mannerov]

Which again has nothing to do with gallium nine, because CSMT does multithreading for the translation layer between GL<-->DX, which is completely absent in Gallium nine. So what did they multithread exactly in their csmt branch?

The d3d9 DDI documentation (The interface for windows drivers implementing the interface needed by Microsoft d3d9.dll - The documentation is public and is on msdn) describes a bit how windows csmt work. Basically they say most commands are put in a thread, and it waits for completion on resource creation, and when calling Present() if there is an entire frame delay not yet executed by the worker thread. A few key functions are reentrant (d3d9.dll will call them from the main thread, and it has to work without waiting on the worker thread).

The gallium nine branch basically reworks gallium nine internals to enable to put the work of most commands in a thread (and the internal state is stored and maintained in the worker thread. The main thread keeps a copy of a few states it has to know for some calls). Some key functions that return result are implemented such that you don't need to wait on the worker thread. The branch is not yet finished and some more functions will get that treatment (and for now they wait for the worker thread to finish all queued job). A lot of games don't call any of such functions though during gameplay, and thus are already at full speed. It always waits worker thread completion when calling Present()

You can find some similarity with the system described by the d3d9 DDI documentation, and even if behaviour may be similar, implementations are different.

I don't know exactly the details of wine csmt (it has likely changed a lot since that 2013 thread).

[starshipeleven]

Even so...

• Vulkan does everything DX12 does
• Vulkan is not controlled by a single entity with monopolistic behaviour
• Vulkan can run on the same platforms that DX12 can and more (Linux, mobile devices)
• If a new version of Windows comes, your users won't have to update to have the latest version of Vulkan supported

https://news.ycombinator.com/item?id=12115454

With both as an option, why would you, as a developer, go with DX12, is something that eludes me.

For the same reason most developers are on DX and not on OGL even now. Their company's game engine was made when DX was better than OGL and changing everything would be a suicide.

Those using third party game engines instead don't give a shit as the rendering backend is a module so the engine can go wherever, just swap the module.

[AsuMagic]

For the same reason most developers are on DX and not on OGL even now. Their company's game engine was made when DX was better than OGL and changing everything would be a suicide.

Those using third party game engines instead don't give a shit as the rendering backend is a module so the engine can go wherever, just swap the module.

That's not logical because they keep implementing new backends for new consoles. If Bethesda can make a playstation special backend for their games, they have no reason not to port their engine to OpenGL, except lack of will (or time, or another valid justification).

[artivision]

The d3d9 DDI documentation (The interface for windows drivers implementing the interface needed by Microsoft d3d9.dll - The documentation is public and is on msdn) describes a bit how windows csmt work. Basically they say most commands are put in a thread, and it waits for completion on resource creation, and when calling Present() if there is an entire frame delay not yet executed by the worker thread. A few key functions are reentrant (d3d9.dll will call them from the main thread, and it has to work without waiting on the worker thread).

The gallium nine branch basically reworks gallium nine internals to enable to put the work of most commands in a thread (and the internal state is stored and maintained in the worker thread. The main thread keeps a copy of a few states it has to know for some calls). Some key functions that return result are implemented such that you don't need to wait on the worker thread. The branch is not yet finished and some more functions will get that treatment (and for now they wait for the worker thread to finish all queued job). A lot of games don't call any of such functions though during gameplay, and thus are already at full speed. It always waits worker thread completion when calling Present()

You can find some similarity with the system described by the d3d9 DDI documentation, and even if behaviour may be similar, implementations are different.

I don't know exactly the details of wine csmt (it has likely changed a lot since that 2013 thread).

Is there a PPA for Gallium Nine CSMT?

[mannerov]

Is there a PPA for Gallium Nine CSMT?

It's not finished. When it will be, it will be put into mesa git.

[nomadewolf]

For the same reason most developers are on DX and not on OGL even now. Their company's game engine was made when DX was better than OGL and changing everything would be a suicide.

Those using third party game engines instead don't give a shit as the rendering backend is a module so the engine can go wherever, just swap the module.

That makes perfect sense up until DX11. Also because OpenGL has it's issues, while DX just works.
But both DX12 and Vulkan are such a break of paradigm that between updating your game engine to DX12 or Vulkan, the difference wouldn't be that much bigger...

[starshipeleven]

That makes perfect sense up until DX11. Also because OpenGL has it's issues, while DX just works.
But both DX12 and Vulkan are such a break of paradigm that between updating your game engine to DX12 or Vulkan, the difference wouldn't be that much bigger...

Yeah, if you TRULY overhaul the engine to fully utilize the new API.

Point is, most games are just adding some features on DX12 while the main engine is still mostly-DX11. (this was valid on any DX version and probably OpenGL too for that matter, there were a ton of mostly-DX9 games that were advertised as DX11 just because of some features, but ran 100% fine without them on a DX9 system)

[nomadewolf]

Yeah, if you TRULY overhaul the engine to fully utilize the new API.

Point is, most games are just adding some features on DX12 while the main engine is still mostly-DX11. (this was valid on any DX version and probably OpenGL too for that matter, there were a ton of mostly-DX9 games that were advertised as DX11 just because of some features, but ran 100% fine without them on a DX9 system)

Unfortunately, there's a lot of truth in this...