Possible support for multi core rendering?
Moderator: GZDoom Developers
-
- Posts: 225
- Joined: Fri Jan 30, 2015 10:32 pm
- Location: Pittman Center
Possible support for multi core rendering?
Is there a chance that multicore rendering can be implemented into the hardware renderer code at some point? That can potentially help with performance issues on OpenGL or Vulkan when it comes to things like a map having an excessive amount of monsters or a mod incorporating a large amount of fancy effects.
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Possible support for multi core rendering?
The Renderer already uses multiple CPU cores to its best adavantage. Real improvements are to be found elsewhere.
See https://vkdoom.org/
See https://vkdoom.org/
-
- Posts: 225
- Joined: Fri Jan 30, 2015 10:32 pm
- Location: Pittman Center
Re: Possible support for multi core rendering?
That reminds me: what advantages do they have over each other otherwise? I know VKDoom has a far more optimized renderer, but is there any reason to still use GZDoom over VKDoom? Also, aren’t most of VK doom's renderer improvements in Vulkan as opposed to OPENGL? It’s Open GL improvements that concern me
-
-
- Posts: 17934
- Joined: Fri Jul 06, 2007 3:22 pm
Re: Possible support for multi core rendering?
If your hardware doesn't support Vulkan, you will not get anything interesting out of VkDoom.Ultimate Freedoomer wrote: ↑Wed Feb 21, 2024 1:15 pm That reminds me: what advantages do they have over each other otherwise? I know VKDoom has a far more optimized renderer, but is there any reason to still use GZDoom over VKDoom?
-
- Posts: 225
- Joined: Fri Jan 30, 2015 10:32 pm
- Location: Pittman Center
Re: Possible support for multi core rendering?
My PC does support both. I’m just wondering WHY the Open GL renderer goes potato when in the 2 scenarios I pointed out. Heck, running mods in Open GL in general seems to chug GZDoom, even on hardware as powerful as mine.
-
-
- Posts: 3133
- Joined: Sat May 28, 2016 1:01 pm
Re: Possible support for multi core rendering?
The OpenGL renderer was initially optimized for how GPU's worked a long time ago. At that time you won performance by creating one big shader that dealt with everything due to very high costs in changing the active pipeline. However, as time went on people (me and others) added more and more features to the shader and eventually it grew so big that performance began to suffer.
In the same time period GPU vendors introduced a new API that was optimized to solve this problem by making switching between pipelines almost completely free. The Vulkan backend in GZDoom didn't take advantage of this yet, but the changes to the shaders in VKDoom does. That is why the OpenGL renderer is falling behind Vulkan when you compare the two backends. It is also one of reasons OpenGL ES performs better than OpenGL: the shader is simpler and on really low end hardware it makes a big difference.
In the same time period GPU vendors introduced a new API that was optimized to solve this problem by making switching between pipelines almost completely free. The Vulkan backend in GZDoom didn't take advantage of this yet, but the changes to the shaders in VKDoom does. That is why the OpenGL renderer is falling behind Vulkan when you compare the two backends. It is also one of reasons OpenGL ES performs better than OpenGL: the shader is simpler and on really low end hardware it makes a big difference.
-
- Lead GZDoom+Raze Developer
- Posts: 49182
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Possible support for multi core rendering?
Actually, the GL renderer wasn't optimized to how GPUs worked but to how OpenGL worked. AFAIK Direct3D never had this insanity of coupling uniform values with the shader. This was the primary reason to write that ugly megashader in the first place, because due to the coupled values and each shader using different indices for the same uniforms would have made it extremely inefficient to split it up, constantly having to hunt down references and making sure that values always match.