robmar wrote:Was DX12 really so bad we needed a completely new driver? ;(
More than bad, it is diferent. Up to DX11/GL the video card is modeled as a state machine whose parameters can be changed constantly (There is a state cache or something the like in the GL driver to change these the least possible) Multithreading would imply accessing this state machine and make sure there are no data races, which is complex on a state machine.
From VK/DX12//Metal on (i am assuming Apple's Metal is the like...) There are no state machines, but command buffers which would represent the flow of a render. There are pipelines, which are static objects that can be replaced quickly and that would represent a whole set of states of the previous GL/DX11 machine (ZRead/Write, alpha blending, polygon order and the like), framebuffers, which would represent the rendertargets, more or less, Descriptor sets, which would be the resources needed for each render/task in the form of Uniform Buffers and Textures, they can't be told to be exactly irrlicht materials, because part of their functionality is on the pipelines as well, buffers (vertices, indices and instance buffers) which are what they look like and more. These objects are read only most of the times, the only variations are done either at creation time, or outside the command recording, because every operation is recorded into command buffers, every rendering operation can be reduced to recording the appropriate commands such as bind this pipeline, these buffers, these descriptors, and issue a rendering command, and then playing back these buffers back. You can record several command buffers at a time, and can synchronize their execution, so some may finish before others, if necesary or they *might* run in parallel. The multithreading becomes easier because you won't alter the objects during the recording, and you can provide each thread their own command buffer, so there are no data races when recording them.
tl;dr From VK on, everything works on objects. The objects are used by the command buffers, which are recorded ahead of execution, and played back, and reused when needed or reset and recorded again. To use threading without mutually excluding the threads from the resources, every thread can be provided its own command buffer, and every object is pretty much read only. In the end, the command buffers may run in parallel all along, or they can be synced properly so some end before others and so on, and that's it.
The problem would be matching every element of Irrlicht into this scheme, but it is not a trivial problem. For instance: begin/end scene would be ambiguous, because now you'd need to tell where are you begining the scene, in which framebuffer. SetTransform would not work as expected because some tasks within a command buffer may end before others, changing a single parameter of a material now would involve changing from a pipeline to other or even creating on the fly the appropriate pipeline, something that would end causing a potential combinatory explosion of pipelines. The efficiency achieved comes with the cost of planning ahead what you will do. The good news though is that when you know how things are done, everything becomes a matter of programming outisde the video driver.
So i'd say yes, finish a proper
GL driver and port to DX11 as much as possible, and then, create a whole different driver, or even engine (Irrlicht 2? command buffers could be emulated for GL/DX11
) for Vulkan and don't bother with DX12, almost nobody seems eager to work with it, and if you see it, has logic, Windows Phones aren't precisely top notch lately, Android is going 100% with Vulkan and it is a really wide platform, and not only phones, Nintendo Switch uses VK, there is even an extension written by Nintendo and NVidia and it is in the VKSDK already, and to some extent, PS4 could use VK, besides, some of the OpenVR standards are trying to go for Vulkan, so, it looks like a promising choice. It has matured a lot during this year it has been out, so it is not a bad choice at all, it has future.
Word has it though that VK works better on AMD than on NVidia XD
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt