Testing a new rendering backend (New tests needed)

Here, developers communicate stuff that does not go onto the main News section or the front page of the site.
[Dev Blog] [Development Builds] [Git Change Log] [GZDoom Github Repo]

Moderator: GZDoom Developers

User avatar
Phredreeke
Posts: 309
Joined: Tue Apr 10, 2018 8:14 am

Re: Testing a new rendering backend (New tests needed)

Post by Phredreeke »

From my understanding, performance is a red herring here. Whether a GPU would benefit from GLES depends on how efficient its shader execution is.
User avatar
phantombeta
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)

Post by phantombeta »

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.
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.
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)
User avatar
Rachael
Posts: 13793
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Testing a new rendering backend (New tests needed)

Post by Rachael »

Neither the 860M nor the HD4850 are integrated GPU's. The 860M however is a laptop GPU, the HD4850 is not.
User avatar
phantombeta
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)

Post by phantombeta »

Rachael wrote:Neither the 860M nor the HD4850 are integrated GPU's. The 860M however is a laptop GPU, the HD4850 is not.
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.
User avatar
Rachael
Posts: 13793
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Testing a new rendering backend (New tests needed)

Post by Rachael »

Yeah, that makes sense.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
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)

Post by Graf Zahl »

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.
Precisely that. If a card has weak performance but unified shader architecture with well implemented branching it is less likely to benefit from GLES.
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.
dpJudas
 
 
Posts: 3134
Joined: Sat May 28, 2016 1:01 pm

Re: Testing a new rendering backend (New tests needed)

Post by dpJudas »

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
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)

Post by Graf Zahl »

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.
User avatar
Rachael
Posts: 13793
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Testing a new rendering backend (New tests needed)

Post by Rachael »

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?
dpJudas
 
 
Posts: 3134
Joined: Sat May 28, 2016 1:01 pm

Re: Testing a new rendering backend (New tests needed)

Post by dpJudas »

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.).
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
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)

Post by Graf Zahl »

I don't think it's the present shader. Most time is lost in the actual draw calls with the main shader.
emile_b
Posts: 107
Joined: Sun Sep 22, 2019 7:06 am
Graphics Processor: nVidia (Modern GZDoom)

Re: Testing a new rendering backend (New tests needed)

Post by emile_b »

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!
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
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)

Post by Graf Zahl »

I occasionally manually sync the differences but it very frequently happens that I make further changes.
Currently it's mainly Raze that's ahead.
User avatar
Nash
 
 
Posts: 17465
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: Testing a new rendering backend (New tests needed)

Post by Nash »

@ 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. :)
emile_b
Posts: 107
Joined: Sun Sep 22, 2019 7:06 am
Graphics Processor: nVidia (Modern GZDoom)

Re: Testing a new rendering backend (New tests needed)

Post by emile_b »

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.
OK thanks for the info.
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. :)
Yep after sending that message I thought the same, it will add a lot of confusion otherwise.

Return to “Developer Blog”