🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

OpenGL vs D3D11 performance in 2022

Started by
14 comments, last by Geri 1 year, 7 months ago

Having been some time away from active graphics programming, thought I'd try my hand with a forward+ style renderer. I first got it working on D3D11, but in the interest of other platform compability I also ported it to OpenGL3.2. Not looking into D3D12 or Vulkan yet, just got it running with the “easy” API's first.

My rendering is fairly simple, first render all shadow maps into an atlas, then a depth only prepass and then the forward shading pass with a 3D cluster light lookup.

I'm testing a scene with a somewhat large amount (400) of unique meshes, which together with the Z-prepass and shadow maps ends up at roughly 2000 draw calls per frame. The passes are nothing out of the ordinary, just a loop of setting the world matrix, binding the vertex / index buffers, and drawing. Not even setting different materials for now.

On OpenGL I end up getting about 4x longer frame time (AMD GPU) or 2x longer (NVIDIA GPU) compared to D3D11. The clustered lighting shader doesn't seem to be a problem when compiled in GLSL, but the overhead per draw call just adds up much more rapidly on OpenGL. In my findings using ordinary uniforms instead of UBO's helps somewhat. Also tried using VAO's to capture the vertex & index buffer bindings; these help to reduce the draw call submission time on AMD, but then I just end up stalling for more time in SwapBuffers. On NVIDIA however, using VAO's increases the draw call submission time, though the frametime overall doesn't suffer much.

I'd like to hear if there are others with comparable experiences, or some hints to what I might be doing wrong, if anything. Or maybe it's just that GPU driver optimization for D3D11 during the years I've been away has been much more thorough?

Advertisement

OpenGL is a mule. It meant to be run on multiple platforms including linux, bsd, windows, mac, embedded systems, consoles, phones, multiple generations of chips cards, combining multiple type of renderings from multiple era, starting from like 1993, includes every luggage and baggage of the past like glbegin, gllists, vertex arrays, vertex objects, support for multiple type of ngeons, lines, multiple generatios of shaders, including vendor specific extensions, a total 200-300 extensions. not just for gaming, but for CAD/CAM type usage.

They tried to simplify somewhat with opengl 3+ profiles, but the driver under the hood is just the same anyway, so you will not win too much compared to the traditional opengl profile. I personally dont recommend to use modern profiles. Use the normal one to maximalize your compatibility with all types of cards and generations, so you can cover pretty much everything from w9x era to the most modern windows, linux, and other types of operating systems to some extent.

You must realize and accept all of its pros and cons, when you are using opengl.

Directx11 is exclusive for windows, meanwhile i dont consider it a bad solution, it obviously lacks the flexibility of opengl, it has about 90-95% smaller complexity internally in the driver, so it will be much faster, but speed is not the only thing you must take into consideration when investing time into writing an engine.

Of course you can support both of it if you can simplify it enough for your engine.

Geri said:
I personally dont recommend to use modern profiles. Use the normal one to maximalize your compatibility with all types of cards and generations

I had to use core profile to get compute shaders to work on AMD. A single deprecated glBegin somewhere, and CS did just produce random numbers.
I guess GL is just too bloated we could expect it runs on every platform and HW without any quirks.

AgentC said:
Not looking into D3D12 or Vulkan yet, just got it running with the “easy” API's first.

I've switched to Vulkan mainly because of the ‘draw call problem’, which in my case was many compute shader dispatches, often doing just very little work.
Got a nice speedup of two due to prerecorded command buffers. Multi threaded command buffer generation is another new option. Perf. is good on both NV and AMD. I'm pretty happy.

Rendering is much more complicated than GPGPU, but it became a bit easier with optional render passes recently, and there are good tutorials.

It's often frustrating, but i prefer this kind of frustration over from what i remember form OpenGL, mainly never being sure if the chosen from 10 options to do one thing is actually good or bad.
So if you're not happy with GL perf., i'd consider to go low level instead trying to put fixes on top of black boxes and legacy bloat. Sounds you're experienced enough.


JoeJ said:
So if you're not happy with GL perf., i'd consider to go low level instead trying to put fixes on top of black boxes and legacy bloat. Sounds you're experienced enough.

I partially agree, but i think he still must keep the opengl path alive. He cant be sure what platform he ends up, what the demands will be… Its better to be prepared than suddenly face the need for opengl and not having it. Its essential.

For example, even my computer doesnt supports vulkan or d3d12, i am pretty sure i am not his target audience but based on this you cant really expect the average joe with his first gen i3 laptop to have it either.

Agentc, also d3d12… i wouldnt even consider that. It lacks the backwards compatibility to dx10 cards, it doesnt works on win7, the emulation on linux is crappy…

If you really have to do a d3d version, then stay with d3d11, that will at least work. But ensure it works! Then have a normal opengl profile, and ensure it WORKS as well, with any drivers, maybe including 1.x support as old intel hd graphics will not support newer ones. Not all effects have to work on older cards. If some effect is hard to implement, you can even skip it. It doesnt even have to be optimized and you dont need to spend time on it. or anything, but be sure it exists, works and runs. It absolutelty doesnt matters if it runs 4x slower than the d3d version, just ensure it works. Believe me, it will save your life. Also a little bit ifdefing and you will have opengl es below the same smoke done.

And then all of your optimization efforts can go to the d3d11 codebase.

It's not so much the API you use, it's what you're doing with it.

At their core, both of them are interfaces that go through drivers to the same hardware. While there is some driver overhead, for any non-trivial program the actual work being done will be the overwhelming factor. The different API's can allow for easier or more difficult access to certain features, but that's not a performance concern in itself. It's all about what you're doing and how you use it.

Geri said:
I partially agree, but i think he still must keep the opengl path alive. He cant be sure what platform he ends up, what the demands will be… Its better to be prepared than suddenly face the need for opengl and not having it.

That goes both ways. Imagine to invest serious time into a GL renderer, and when you're done with your game it turns out meanwhile everybody has ray tracing, mesh shaders, VRS, etc., and you would like to use those things bot can't because you're stuck on GL not getting any updates. For somebody who implements something like Forward+ that's quite likely to happen i guess.

Geri said:
For example, even my computer doesnt supports vulkan or d3d12

Now that's interesting. Do you use Apple or really old HW? Something else?

Thanks for the answers and their perspective! Yes indeed much depends on whether I'd aim to publish something and on what platforms, for now this is just a toy renderer. I did see from testing my older codebase that D3D9 and OpenGL are roughly comparable in perf on even modern hardware with the same kind of workload (minus the clustered lighting, just traditional forward or deferred), it's just that D3D11 is such a beast. For the sake of experimenting for cross-platform, Vulkan is indeed a logical next step for me.

AgentC said:
Vulkan is indeed a logical next step for me.

The first triangle is the hardest. After that you have an impression on complexity and can decide.

Validation layers are really helpful. If you do something wrong, you get a debug break with a string holding verbal description of the issue plus object pointers to track back the error quite easily.

Geri said:
For example, even my computer doesnt supports vulkan or d3d12

Now that's interesting. Do you use Apple or really old HW? Something else?

My strongest video card is a Radeon 4850. i digged it out from the e-waste a few months ago. Before that, i had a 8800gt which i got last year, but it was in a box, and i didnt used it in my computer as nouveau is buggy and the 8800gt is unstable under linux. They still didnt fixed the drivers. Very disappointing.

I very rarely spend on computer parts, it makes barely any sense since the hardware development slowed down so much since 2007. I usually buy something if it dies, spending not more on something than 10-20$ usually, even if i could afford to spend a little bit more on it. Almost everything in my computer is from pre-2010. If i buy something, thats usually a collectible item, or i need it for my work somehow as testhardware. But i dont buy stuff as a consumer, as i am not really a consumer... My phone is also from 2012. Last week i damaged its screen a little bit, so i might switch to a newer model soon.

This topic is closed to new replies.

Advertisement