Good news!
Is there much structural changes to support DX11 or even 12? Its always such a pain when MS change things by breaking compatibility.
Finally, a DirectX 10 video driver for Irrlicht
Re: Finally, a DirectX 10 video driver for Irrlicht
For DX11, i don't think so. But DX12/Vulkan are radically diferent and you better think of new methods for the video driver. Calls like "setRendertarget", "set/getTransform" or even "setMaterial" rely on a model that is no longer valid under those API. I mean, it is still perfectly feasible to create DX12/VK drivers for Irrlicht as it is right now, and might provide better performance than the current APIs on some scenarios, but with the current set up you're very likely losing their greatest potential. The problem with DX12/VK is that they don't rely on global states in the video driver anymore, but on pipelines.
Think of a pipeline as a snapshot of the current driver state, including shaders, blending states, texture sampling states and so on. and that anything that uses a pipeline will get rendered using that style. It is like a material, but with extended capabilities, that you can't change during the rendering, save, obviously, the used texture maps, and that can be reutilized once and again without change. So, basicly, you use each pipeline for each type of render you want, this is a bit less flexible than a dynamic state model, but the gain is important, compared, there is no need for state caches anymore, because the state changes are not possible during the render and you still can define and use an array of pipelines. Actually, even if many renderstate changes may happen during the running of a program, these use to be on very few options, so the potential combinatory explosion that using an array of pipelines may cause is greatly reduced because of this and thus, makes sense to use them. And anyway, in Vulkan, at least, it is possible to define derivative pipelines, so you might have a master pipeline and derive others from it. I still have to check how goes that, but on the paper, it is possible.
As the pipelines are static objects, they can be referenced on multiple threads, and there is no need to worry about modifying them accidentally, or perhaps, you can, but you have to understand that changing a pipeline will change any rendering that takes place using it. The multiple threads are meant to build the draw calls and record them, and the actual rendering is deferred until the moment all the draw calls have been recorded, and takes place after, and only after, you tell the API to start. You can establish rendering dependences, at least on Vulkan, to make sure some renders take place before others, and that's it. Anything that sets a global parameter (a model/view/projection transform, a rendering material on the driver or a rendertarget...) that can't be shared among all the API calls you send is a rendering dependance that may prevent other tasks to run in parallel. So any new structure for those new APIs, should keep in mind the problem of the parallelism to make sure you use them the most efficiently way possible.
Think of a pipeline as a snapshot of the current driver state, including shaders, blending states, texture sampling states and so on. and that anything that uses a pipeline will get rendered using that style. It is like a material, but with extended capabilities, that you can't change during the rendering, save, obviously, the used texture maps, and that can be reutilized once and again without change. So, basicly, you use each pipeline for each type of render you want, this is a bit less flexible than a dynamic state model, but the gain is important, compared, there is no need for state caches anymore, because the state changes are not possible during the render and you still can define and use an array of pipelines. Actually, even if many renderstate changes may happen during the running of a program, these use to be on very few options, so the potential combinatory explosion that using an array of pipelines may cause is greatly reduced because of this and thus, makes sense to use them. And anyway, in Vulkan, at least, it is possible to define derivative pipelines, so you might have a master pipeline and derive others from it. I still have to check how goes that, but on the paper, it is possible.
As the pipelines are static objects, they can be referenced on multiple threads, and there is no need to worry about modifying them accidentally, or perhaps, you can, but you have to understand that changing a pipeline will change any rendering that takes place using it. The multiple threads are meant to build the draw calls and record them, and the actual rendering is deferred until the moment all the draw calls have been recorded, and takes place after, and only after, you tell the API to start. You can establish rendering dependences, at least on Vulkan, to make sure some renders take place before others, and that's it. Anything that sets a global parameter (a model/view/projection transform, a rendering material on the driver or a rendertarget...) that can't be shared among all the API calls you send is a rendering dependance that may prevent other tasks to run in parallel. So any new structure for those new APIs, should keep in mind the problem of the parallelism to make sure you use them the most efficiently way possible.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Finally, a DirectX 10 video driver for Irrlicht
I thought that DX10 and DX11 were similar, just with 11 have extra features. Is the jump to 12 really that radical?
Each material must still have its own properties of course, but general render states for each pipe is nothing too complex.
Parallel processing would be good, but requires that the GPU readily supports mutliple rendering requests, which must get quiote complicated to say the least.
Is there any news from Grantye on his DX10 driver?
Each material must still have its own properties of course, but general render states for each pipe is nothing too complex.
Parallel processing would be good, but requires that the GPU readily supports mutliple rendering requests, which must get quiote complicated to say the least.
Is there any news from Grantye on his DX10 driver?
Re: Finally, a DirectX 10 video driver for Irrlicht
It is what i am finding in Vulkan, and from what i read about DX12, seems their approach is similar. It isn't that complex to support diferent rendering request, think of a MRT setup, actually you're telling the GPU to render 4 rendertargets at a time, who says that setup isn't done in the API runtime? Although, for instance, NVidia supports Vulkan only from their 600 series and above, so i don't know to what extent those capabilities are tied to the hardware.
I don't say it is complex, what i mean is that, for instance, setting a model/world transform only serves for a single object, and currently, that is done as a general state. To support multiple rendering processes, a global state isn't useful. To provide simultaneous renderings, Vulkan devices expose a number of queues where you can send the drawing commands. You can send any amount of commands to any queue, and they're processed at the same time when the render begins
I don't say it is complex, what i mean is that, for instance, setting a model/world transform only serves for a single object, and currently, that is done as a general state. To support multiple rendering processes, a global state isn't useful. To provide simultaneous renderings, Vulkan devices expose a number of queues where you can send the drawing commands. You can send any amount of commands to any queue, and they're processed at the same time when the render begins
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Finally, a DirectX 10 video driver for Irrlicht
Well, they will be processed at the same time if a rendering core is available, otherwise the calls will be held in wait.
Of course the problem isn´t rendering textures to different objects, its rendering complex models to the frame buffer in parallel!
To make that truly parallel possible, we'd need a sort of sprite-based frame buffer, where depth issues would be automatically resolved not at render time, but at draw time.
Of course the problem isn´t rendering textures to different objects, its rendering complex models to the frame buffer in parallel!
To make that truly parallel possible, we'd need a sort of sprite-based frame buffer, where depth issues would be automatically resolved not at render time, but at draw time.
Re: Finally, a DirectX 10 video driver for Irrlicht
There are many issues to be solved before a render even begins, but i guess the API design has been made to take full advantage of the parallelism the GPU can give you, so it doesn't matter the complexity of the model, or it is something secondary. One complex model may run on a queue while the other queues can be used for less complex stuff. Queues might at most, wait for results from other queues, BUT something positive is that this something that falls on the hands of the application programmer now, not in the hands of the API, if you want, you may reserve always a queue for light operations. At least, in Vulkan, i don't know how would DX12 behave, but i think it is something similar.
This NVidia article talks about the dos and donts of DX12, it may help to get more insight of how it works
https://developer.nvidia.com/dx12-dos-and-donts
This NVidia article talks about the dos and donts of DX12, it may help to get more insight of how it works
https://developer.nvidia.com/dx12-dos-and-donts
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Finally, a DirectX 10 video driver for Irrlicht
thanks, I´ll take a look at that!
Re: Finally, a DirectX 10 video driver for Irrlicht
I find kind of sad though that currently a DX10/DX11 driver for Irrlicht is openly outdated 
Even if it finally works, it is already superseeded by more advanced tech.
Even if it finally works, it is already superseeded by more advanced tech."There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Finally, a DirectX 10 video driver for Irrlicht
Looking at those nVidia notes on DX12 and Vulcan, I wouldn't be surprised if they never go mainstream.
There is more load on the CPU than before, requiring multicore processor support, more complexity, less error protections... and all this adds up to more development costs, and more expensive hardware, which is only good news for Intel and Microsoft; as usual comercial interests are over user interests.
I think we will be better off with a good DX10/11 driver, which will do us for years to come, and forget about these new drivers at least for a few years.
There is more load on the CPU than before, requiring multicore processor support, more complexity, less error protections... and all this adds up to more development costs, and more expensive hardware, which is only good news for Intel and Microsoft; as usual comercial interests are over user interests.
I think we will be better off with a good DX10/11 driver, which will do us for years to come, and forget about these new drivers at least for a few years.
Re: Finally, a DirectX 10 video driver for Irrlicht
I'm still working on it almost everything work the last issue i have with it is the text scenenode is aparently zwriting or somethingrobmar wrote:Is there any news from Grantye on his DX10 driver?
It somewhat is but considering the dx11 driver is now a 5 years old project and not yet integrated into the trunk how long do you think it will take for DX12/Vulkan to make it thereMel wrote:I find kind of sad though that currently a DX10/DX11 driver for Irrlicht is openly outdated
Re: Finally, a DirectX 10 video driver for Irrlicht
DX11 will be supported and in use by many games for years to come, and the benefits of DX12 are very uncertain, and probably not worth the effort.
In a few years time we´ll have new super GPUs, or APUs, and maybe DX20 will be out and we can look at that!
In a few years time we´ll have new super GPUs, or APUs, and maybe DX20 will be out and we can look at that!
Re: Finally, a DirectX 10 video driver for Irrlicht
I know that it may be frustrating, but It's related to a long period of v1.9 release (merge with ogl-es branch). I should release new FVF branch soon and of course I'll move D3D11 from shader-pipeline to the new branch. If this combo will work fine IMO we should quickly merge them to trunk (branches with a very long lifecycle like ogl-es or even shader-pipeline are problematic).Granyte wrote:It somewhat is but considering the dx11 driver is now a 5 years old project and not yet integrated into the trunk how long do you think it will take for DX12/Vulkan to make it there
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
Re: Finally, a DirectX 10 video driver for Irrlicht
Good luck with all that, and i will stop hijacking this thread XD
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Finally, a DirectX 10 video driver for Irrlicht
Maybe someone wants to branch my irrlicht GL 3.3+ version and add the support there?
Re: Finally, a DirectX 10 video driver for Irrlicht
Pro Evolution Soccer 2016 still using the legacy directx9 , which is 15 years old .