Testing a new rendering backend (New tests needed)
Moderator: GZDoom Developers
-
- Posts: 309
- Joined: Tue Apr 10, 2018 8:14 am
Re: Testing a new rendering backend (New tests needed)
From my understanding, performance is a red herring here. Whether a GPU would benefit from GLES depends on how efficient its shader execution is.
-
- Posts: 2119
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: Testing a new rendering backend (New tests needed)
Most likely the reason for low framerate with deferred rendering is due to the VRAM speed. Deferred rendering requires a lot of VRAM throughput, so older (and integrated) GPUs with slower VRAM can get terrible performance with deferred.Rachael wrote:My hypothesis is that the shader processor is the limiting factor. When I run other GL programs, if I use forward rendering instead of deferred rendering, I get FPS speeds magnitudes higher than equivalent scenes on my GTX 860M (which is astonishing since the 860M is 5 years newer). However, once I activate deferred rendering, the FPS plummets to 1/10th what it was in the exact same scene, where the 860M would run at about equivalent speed to what it did for forward rendering with the same settings in the same scene as was tested with the old Radeon.
Since this is an integrated GPU, it's running at DDR3 or DDR4 speeds, so nowhere near the speed of real VRAM. And it has to go through the auxiliary chips, and has to share the RAM throughput with the CPU itself... That's very bad for performance. (SSAO tends to cause causes performance issues on such GPUs for the same reason)
-
- Posts: 13793
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: Testing a new rendering backend (New tests needed)
Neither the 860M nor the HD4850 are integrated GPU's. The 860M however is a laptop GPU, the HD4850 is not.
-
- Posts: 2119
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: Testing a new rendering backend (New tests needed)
Ah, I thought the HD4850 was an integrated Intel GPU (I only saw "So, about the HD 4850". Curse similar naming schemes). Looking it up, it's still an old GPU, though, and from before deferred started being a thing in games, so that's definitely gonna be getting slowed down by VRAM throughput.Rachael wrote:Neither the 860M nor the HD4850 are integrated GPU's. The 860M however is a laptop GPU, the HD4850 is not.
-
- Posts: 13793
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: Testing a new rendering backend (New tests needed)
Yeah, that makes sense.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Testing a new rendering backend (New tests needed)
Precisely that. If a card has weak performance but unified shader architecture with well implemented branching it is less likely to benefit from GLES.Phredreeke wrote:From my understanding, performance is a red herring here. Whether a GPU would benefit from GLES depends on how efficient its shader execution is.
With the 4850 the problem seems to be the VRAM indeed. The main difference between LZDoom and GZDoom is that the latter renders the scene to an offscreen buffer and then again to the screen. It's not deferred rendering but apparently that intermediate step is too costly on it or hits some emulation path.
-
-
- Posts: 3134
- Joined: Sat May 28, 2016 1:01 pm
Re: Testing a new rendering backend (New tests needed)
If vram/fillrate is the problem then performance could be improved by using rgba8 for the offscreen buffers instead of rgba16f. The catch is a reduced visual quality as the 16 bpc buffers allows the postprocess present shader to dither the final result. The bloom pass also needs the higher dynamic range enabled by the half-floats. A simpler present shader could also be used if that's what makes it run slow on low end software.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Testing a new rendering backend (New tests needed)
All that may be worth investigating. If we could get GZDoom to run well on that old ATI card a big reason for a low end alternative would just go away.
But let's not forget that older GZDoom's never had more to begin with - and who cares about postprocessing effects on a card where running them would make things only slower? If an RGBA8 buffer means disabling some of them, so be it.
But supporting this card well is a lot more important than having it run on ancient toasters.
But let's not forget that older GZDoom's never had more to begin with - and who cares about postprocessing effects on a card where running them would make things only slower? If an RGBA8 buffer means disabling some of them, so be it.
But supporting this card well is a lot more important than having it run on ancient toasters.
-
- Posts: 13793
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: Testing a new rendering backend (New tests needed)
I don't know if I did this right, for reference here is the patch for what I did:
Spoiler:The benchmark test from those changes netted this result:
Spoiler:Unfortunately that's pretty much identical to the result from when the GL_RGBA16F buffers were in use. Maybe I didn't get the right lines?
-
-
- Posts: 3134
- Joined: Sat May 28, 2016 1:01 pm
Re: Testing a new rendering backend (New tests needed)
That patch should be correct. Seems cutting the buffer memory in half made no difference then. Try simplify the present shader instead (i.e. comment out all the gamma, brightness, etc.).
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Testing a new rendering backend (New tests needed)
I don't think it's the present shader. Most time is lost in the actual draw calls with the main shader.
-
- Posts: 107
- Joined: Sun Sep 22, 2019 7:06 am
- Graphics Processor: nVidia (Modern GZDoom)
Re: Testing a new rendering backend (New tests needed)
I have a quick question kind of related to this topic: How are the 'source/common' folder between Raze and GZDoom synchronised? Is it done manually? Do they ever become identical? I ask because even after a commit which looks like a sync there seems to be some small differences. I have copied over the rendering changes from GZDoom to Raze here: https://github.com/emileb/Raze/commits/master, which it how I noticed the differences.
Also another unrelated questions: I am looking at a (free) mobile port of Raze which lots of people keep asking be about, is it OK to call it 'Raze Touch'? No problem at all if you would rather it be called something else (maybe you want to avoid the chance of people raising mobile related bugs with you developers).
Cheers!
Also another unrelated questions: I am looking at a (free) mobile port of Raze which lots of people keep asking be about, is it OK to call it 'Raze Touch'? No problem at all if you would rather it be called something else (maybe you want to avoid the chance of people raising mobile related bugs with you developers).
Cheers!
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Testing a new rendering backend (New tests needed)
I occasionally manually sync the differences but it very frequently happens that I make further changes.
Currently it's mainly Raze that's ahead.
Currently it's mainly Raze that's ahead.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: Testing a new rendering backend (New tests needed)
@ Emile: If I were you, I'd probably just do what you did with Delta Touch, and name it something that's not related to the main PC port. :)
-
- Posts: 107
- Joined: Sun Sep 22, 2019 7:06 am
- Graphics Processor: nVidia (Modern GZDoom)
Re: Testing a new rendering backend (New tests needed)
OK thanks for the info.Graf Zahl wrote:I occasionally manually sync the differences but it very frequently happens that I make further changes.
Currently it's mainly Raze that's ahead.
Yep after sending that message I thought the same, it will add a lot of confusion otherwise.Nash wrote:@ Emile: If I were you, I'd probably just do what you did with Delta Touch, and name it something that's not related to the main PC port.