What are the pros and cons of OpenGL, Vulkan, SoftPoly, and DirectX11?

[Dweller Dark]

I know that they generally "sharpen" a game's image in a way and can take stress off certain hardware components, but I'm a bit confused on what the benefits and drawbacks are between them. 

[Gez]

One of these things is not like the others...

 

 

OpenGL, Vulkan, and DirectX are backends that allow to render and display things more efficiently. OpenGL and Vulkan are cross-platform, while DirectX is Microsoft-only. Putting SoftPoly in the middle, however, tells me this isn't the answer you're looking for. Because you're specifically referring to GZDoom here, aren't you?

 

So the first thing to do is to explain there are two steps to bring things to life on your screen: the first step is rendering it, basically get the computer to figure out how it should look like. The second step? Displaying it. The image has been computed, now actually put it on the screen.

 

For the first step, GZDoom offers a choice of three renderers:

1. Classic "Carmack" software renderer (like the original, though with a number of additional features)
2. Hardware-accelerated renderer (OpenGL or Vulkan; get your graphic card to do the rendering work for better performances)
3. SoftPoly software renderer (a fully 3D polygonized renderer, but rendered by the CPU instead of the GPU)

For the second step, well, if you render with OpenGL, you display with OpenGL. If you render with Vulkan, you display with Vulkan. No choice here, it would be stupid to use a different backend. So it's only if you use a software renderer (classic or softpoly) that you get to choose between OpenGL, Vulkan, or DirectX. But as far as image quality goes, it shouldn't change much to use one instead of another here, since they don't render the image, they just display it at this point.

 

For best performances, you should use Vulkan if your computer supports it, OpenGL otherwise.

[Dweller Dark]

19 minutes ago, Gez said:

One of these things is not like the others...

 

 

OpenGL, Vulkan, and DirectX are backends that allow to render and display things more efficiently. OpenGL and Vulkan are cross-platform, while DirectX is Microsoft-only. Putting SoftPoly in the middle, however, tells me this isn't the answer you're looking for. Because you're specifically referring to GZDoom here, aren't you?

 

So the first thing to do is to explain there are two steps to bring things to life on your screen: the first step is rendering it, basically get the computer to figure out how it should look like. The second step? Displaying it. The image has been computed, now actually put it on the screen.

 

For the first step, GZDoom offers a choice of three renderers:

1. Classic "Carmack" software renderer (like the original, though with a number of additional features)
2. Hardware-accelerated renderer (OpenGL or Vulkan; get your graphic card to do the rendering work for better performances)
3. SoftPoly software renderer (a fully 3D polygonized renderer, but rendered by the CPU instead of the GPU)

For the second step, well, if you render with OpenGL, you display with OpenGL. If you render with Vulkan, you display with Vulkan. No choice here, it would be stupid to use a different backend. So it's only if you use a software renderer (classic or softpoly) that you get to choose between OpenGL, Vulkan, or DirectX. But as far as image quality goes, it shouldn't change much to use one instead of another here, since they don't render the image, they just display it at this point.

 

For best performances, you should use Vulkan if your computer supports it, OpenGL otherwise.

 

I'm specifically referring to both GZDoom and Doom 64, since they both have backends like Vulkan and OpenGL. Though Doom 64 doesn't seem to have a software renderer that I can think of, at least with the official port. But for clarity, if I'm running the Vulkan backend, choose "Hardware Accelerated" in the software render options?

[Edward850]

36 minutes ago, DavetheDoomguy said:

I'm specifically referring to both GZDoom and Doom 64

Doom64 and GZDoom in terms of rendering options have about as much in common as chalk and cheese, these aren't equivalent questions at all.

 

With the new Doom64 port in Kex3, things are divided up into RHIs (Rendering Hardware Interface), to which there's actually 4; DirectX11 (with 10.0 compatibility support), OpenGL 3.2, Vulkan and GNM. However there's only 1 renderer which is unique to Doom64, the RHIs act as an abstraction layer between it and the desired graphics API. They even run the same shaders (in terms of code, they are compiled into different shader binaries of course).

This means in an ideal situation, there is no difference, they should all act the same and visually they should all be expected to produce identical results. However the actual difference will be defined by your hardware and driver compatibility. Your Graphics drivers may support everything in OpenGL3.2 but not Vulkan, or your hardware may be more optimised to run Vulkan and thus perform faster than OpenGL.

Because the renderer doesn't actually know what RHI it's running on, you could in theory make a software driven RHI as well. However this would not be the same as Doom's original renderer, which Doom64 no longer supports.

 

None of what I explained applies to GZDoom, which does have 4 entirely separate renderers (OpenGL and Vulkan appear to be two distinct pipelines), and 3 different APIs to output the software ones.

Edited January 23, 2021 by Edward850

[Dweller Dark]

13 minutes ago, Edward850 said:

Doom64 and GZDoom in terms of rendering options have about as much in common as chalk and cheese, these aren't equivalent questions at all.

 

With the new Doom64 port in Kex3, things are divided up into RHIs (Rendering Hardware Interface), to which there's actually 4; DirectX11 (with 10.0 compatibility support), OpenGL 3.2, Vulkan and GNM. However there's only 1 renderer which is unique to Doom64, the RHIs act as an abstraction layer between it and the desired graphics API. They even run the same shaders (in terms of code, they are compiled into different shader binaries of course).

This means in an ideal situation, there is no difference, they should all act the same and visually they should all be expected to produce identical results. However the actual difference will be defined by your hardware and driver compatibility. Your Graphics drivers may support everything in OpenGL3.2 but not Vulkan, or your hardware may be more optimised to run Vulkan and thus perform faster than OpenGL.

Because the renderer doesn't actually know what RHI it's running on, you could in theory make a software driven RHI as well. However this would not be the same as Doom's original renderer, which Doom64 no longer supports.

 

None of what I explained applies to GZDoom, which does have 4 entirely separate renderers (OpenGL and Vulkan appear to be two distinct pipelines), and 3 different APIs to output the software ones.

 

So, the RHI's work between the base renderer and the API and don't affect the visual quality? Whereas GZDoom has just the renderers and APIs, the latter of which affect visual quality?

[Blzut3]

14 minutes ago, Edward850 said:

None of what I explained applies to GZDoom.

Actually that's very close to how the Vulkan, OpenGL, and SoftPoly selection works in GZDoom.  With SoftPoly basically being that software RHI.  There's otherwise a large chunk of "hardware renderer" code that's shared between the three of them.

 

This is of course independent from the Carmack software renderer which can use any of those three as a rendering target.  When using SoftPoly with the Carmack software renderer this effectively becomes a Direct3D target on Windows.

45 minutes ago, DavetheDoomguy said:

But for clarity, if I'm running the Vulkan backend, choose "Hardware Accelerated" in the software render options?

For most people, yes if you have Vulkan hardware you should use Vulkan and use the hardware accelerated renderer.  There are people like myself that prefer use the classic renderer with all it's little quirks, so this is ultimately a personal preference.

 

I'm not aware of any hardware where OpenGL is the better choice unless Vulkan just isn't supported, but in some cases it might be faster at throwing the Carmack renderer onto the screen than Vulkan (depends entirely on your drivers).  SoftPoly in "hardware accelerated" mode (which isn't actually accelerated) is mostly a curiosity, but due to the use of Direct3D it can for some hardware be the fastest way to throw the Carmack renderer to the screen.  It's more of a last resort fallback though.

[Dweller Dark]

3 minutes ago, Blzut3 said:

Actually that's very close to how the Vulkan, OpenGL, and SoftPoly selection works in GZDoom.  With SoftPoly basically being that software RHI.  There's otherwise a large chunk of "hardware renderer" code that's shared between the three of them.

 

This is of course independent from the Carmack software renderer which can use any of those three as a rendering target.  When using SoftPoly with the Carmack software renderer this effectively becomes a Direct3D target on Windows.

For most people, yes if you have Vulkan hardware you should use Vulkan and use the hardware accelerated renderer.  There are people like myself that prefer use the classic renderer with all it's little quirks, so this is ultimately a personal preference.

 

I'm not aware of any hardware where OpenGL is the better choice unless Vulkan just isn't supported, but in some cases it might be faster at throwing the Carmack renderer onto the screen than Vulkan (depends entirely on your drivers).  SoftPoly in "hardware accelerated" mode (which isn't actually accelerated) is mostly a curiosity, but due to the use of Direct3D it can for some hardware be the fastest way to throw the Carmack renderer to the screen.  It's more of a last resort fallback though.

 

I've never seen the Carmack renderer in the settings, is it under a different name?

[Blzut3]

Just now, DavetheDoomguy said:

 

I've never seen the Carmack renderer in the settings, is it under a different name?

It's called "Doom Software Renderer" under render mode.  Used to specifically be called the "Carmack" renderer in previous releases.

[Dweller Dark]

1 minute ago, Blzut3 said:

It's called "Doom Software Renderer" under render mode.  Used to specifically be called the "Carmack" renderer in previous releases.

 

So the Carmack renderer makes things look closer to what the original game was like?

[Blzut3]

Just now, DavetheDoomguy said:

 

So the Carmack renderer makes things look closer to what the original game was like?

Yes.  It is the same renderer code from the original game, just heavily modified and expanded.  You can tweak the hardware accelerated renderer to look aesthetically very close to the original game though these days, but things like the way sprites are drawn is still wrong.  The Carmack renderer doesn't have these issues since it's still following the way the original code worked.  The flip side is you have to deal with things like limited support for free look because the renderer is just incapable of changing the camera pitch by design.

[Dweller Dark]

1 minute ago, Blzut3 said:

Yes.  It is the same renderer code from the original game, just heavily modified and expanded.  You can tweak the hardware accelerated renderer to look aesthetically very close to the original game though these days, but things like the way sprites are drawn is still wrong.  The Carmack renderer doesn't have these issues since it's still following the way the original code worked.  The flip side is you have to deal with things like limited support for free look because the renderer is just incapable of changing the camera pitch by design.

 

If I wanted Doom to look as close to the original, what other settings would I have to change? I already have dynamic lighting, texture filtering, and freelook turned off, so that's part of it.

[Edward850]

20 minutes ago, Blzut3 said:

Actually that's very close to how the Vulkan, OpenGL, and SoftPoly selection works in GZDoom.  With SoftPoly basically being that software RHI.  There's otherwise a large chunk of "hardware renderer" code that's shared between the three of them.

Huh, really? When I looked at it initially it seemed like different code paths entirely, outside the usual setup in d_display. There was also this weird stuff going on like all the assets in vulkan memory being upside down (instead of the screen itself which is what would normally be the case.) 

[Blzut3]

2 minutes ago, Edward850 said:

Huh, really? When I looked at it initially it seemed like different code paths entirely, outside the usual setup in d_display. There was also this weird stuff going on like all the assets in vulkan memory being upside down (instead of the screen itself which is what would normally be the case.) 

The stuff in src/common/rendering/hwrenderer and src/rendering/hwrenderer should all be shared amongst Vulkan, OpenGL, and SoftPoly.  My understanding is this includes, among other things, everything about determining what polygons to draw.  Just the stuff in src/common/rendering/{gl,polyrenderer,vulkan} should be specific.  Keep in mind though that I personally have no investment in the hardware renderers so you might be able to find a counter example, but that's the gist of it.  You guys may or may not have a more complete abstraction I really can't say.  But your high level description fits both projects just fine.

8 minutes ago, DavetheDoomguy said:

 

If I wanted Doom to look as close to the original, what other settings would I have to change? I already have dynamic lighting, texture filtering, and freelook turned off, so that's part of it.

For the hardware accelerated renderer, the big thing is to change the sector light mode to Software or Vanilla.  Software is supposed to match the lighting you see when you set render mode to Doom Software Renderer (or the true color sw renderer).  The vanilla mode is supposed to be closer to vanilla since if I recall correctly the algorithm for determining the lighting was resolution dependent and it turned out ZDoom didn't fix that issue correctly or something like that.

 

With the software or vanilla light modes you can also turn on "Banded SW Lightmode" for an emulation of the 8-bit lighting aesthetic.

 

There might be a few other tweaks that could be done, but like I said I personally just use the Carmack renderer.  I just know with the right settings you can take screen shots that really require a trained eye to reliably determine what renderer was used.  The biggest giveaway being whenever geometry cuts off sprites.

[Dweller Dark]

38 minutes ago, Blzut3 said:

The stuff in src/common/rendering/hwrenderer and src/rendering/hwrenderer should all be shared amongst Vulkan, OpenGL, and SoftPoly.  My understanding is this includes, among other things, everything about determining what polygons to draw.  Just the stuff in src/common/rendering/{gl,polyrenderer,vulkan} should be specific.  Keep in mind though that I personally have no investment in the hardware renderers so you might be able to find a counter example, but that's the gist of it.  You guys may or may not have a more complete abstraction I really can't say.  But your high level description fits both projects just fine.

For the hardware accelerated renderer, the big thing is to change the sector light mode to Software or Vanilla.  Software is supposed to match the lighting you see when you set render mode to Doom Software Renderer (or the true color sw renderer).  The vanilla mode is supposed to be closer to vanilla since if I recall correctly the algorithm for determining the lighting was resolution dependent and it turned out ZDoom didn't fix that issue correctly or something like that.

 

With the software or vanilla light modes you can also turn on "Banded SW Lightmode" for an emulation of the 8-bit lighting aesthetic.

 

There might be a few other tweaks that could be done, but like I said I personally just use the Carmack renderer.  I just know with the right settings you can take screen shots that really require a trained eye to reliably determine what renderer was used.  The biggest giveaway being whenever geometry cuts off sprites.

 

Thanks, I got my Doom the way I want it to look now. And by geometry cutting off the sprites, do you mean the map geometry or something to do with the screen (such as Hexen's problem with player arms)?

 

Edit: As a sidenote, when it comes to music playback in GZDoom, is FluidSynth the best option?

[Blzut3]

1 hour ago, DavetheDoomguy said:

Thanks, I got my Doom the way I want it to look now. And by geometry cutting off the sprites, do you mean the map geometry or something to do with the screen (such as Hexen's problem with player arms)?

Start Doom 2 MAP01 and then in the main hallway summon revenant from the console.  Switch between the render modes.  Notice the hardware accelerated renderer cuts off his head.  This effect manifests itself in much more subtle ways in just about everything.

 

The Hexen thing you mention is just the sprites being designed for 4:3 and nothing to do with the renderer.

2 hours ago, DavetheDoomguy said:

Edit: As a sidenote, when it comes to music playback in GZDoom, is FluidSynth the best option?

This is entirely personal preference.  You'll get a different answer from everyone.

[dpJudas]

12 hours ago, Edward850 said:

There was also this weird stuff going on like all the assets in vulkan memory being upside down (instead of the screen itself which is what would normally be the case.) 

That was done on purpose to make custom GLSL shaders written for OpenGL compatible with the vulkan backend. The RHI was mainly written with OpenGL in mind and that did mean I had to either do something like this or make extensive improvements to the RHI.

[seed]

14 hours ago, Gez said:

For best performances, you should use Vulkan if your computer supports it, OpenGL otherwise.

 

Well, yes, if it worked right, that is.

 

Last time I checked Vulkan was leaking memory like there's no tomorrow, and performance improvements were marginal on NVIDIA hardware. It's more meaningful for AMD due to their abysmal GL support.

[dpJudas]

1 hour ago, seed said:

 

Well, yes, if it worked right, that is.

 

Last time I checked Vulkan was leaking memory like there's no tomorrow, and performance improvements were marginal on NVIDIA hardware. It's more meaningful for AMD due to their abysmal GL support.

So you keep saying. Yet, the last time I tested those claims I found no memory leaks at all on my system. Either you're using some setup that doesn't match what mine is (read: the bug report was not reproducible), or the memory leak has since then been fixed. In any case, I added a ccmd that can output the memory usage according to the vulkan memory allocator if you truly want to prove there is one.

[seed]

34 minutes ago, dpJudas said:

So you keep saying. Yet, the last time I tested those claims I found no memory leaks at all on my system. Either you're using some setup that doesn't match what mine is (read: the bug report was not reproducible), or the memory leak has since then been fixed. In any case, I added a ccmd that can output the memory usage according to the vulkan memory allocator if you truly want to prove there is one.

 

Fair enough.

 

What was the CCMD?