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

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

Postby Phredreeke » Sat Apr 03, 2021 11:44 am

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
Phredreeke
 
Joined: 10 Apr 2018
Discord: phredreeke#6500

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

Postby phantombeta » Sat Apr 03, 2021 12:10 pm

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
phantombeta
Tired of being treated like trash by control freaks
 
Joined: 02 May 2013

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

Postby Rachael » Sat Apr 03, 2021 12:24 pm

Neither the 860M nor the HD4850 are integrated GPU's. The 860M however is a laptop GPU, the HD4850 is not.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby phantombeta » Sat Apr 03, 2021 12:29 pm

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
phantombeta
Tired of being treated like trash by control freaks
 
Joined: 02 May 2013

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

Postby Rachael » Sat Apr 03, 2021 12:31 pm

Yeah, that makes sense.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby Graf Zahl » Sat Apr 03, 2021 12:52 pm

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby dpJudas » Sat Apr 03, 2021 3:34 pm

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.
dpJudas
 
 
 
Joined: 28 May 2016

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

Postby Graf Zahl » Sat Apr 03, 2021 3:54 pm

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
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby Rachael » Sun Apr 04, 2021 3:47 am

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?
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby dpJudas » Sun Apr 04, 2021 12:02 pm

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.).
dpJudas
 
 
 
Joined: 28 May 2016

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

Postby Graf Zahl » Sun Apr 04, 2021 12:31 pm

I don't think it's the present shader. Most time is lost in the actual draw calls with the main shader.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby emile_b » Mon May 17, 2021 4:57 am

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!
emile_b
 
Joined: 22 Sep 2019
Operating System: Windows 10/8.1/8/201x 64-bit
Graphics Processor: nVidia (Modern GZDoom)

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

Postby Graf Zahl » Mon May 17, 2021 5:11 am

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
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby Nash » Mon May 17, 2021 6:36 am

@ 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. :)
User avatar
Nash
Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

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

Postby emile_b » Mon May 17, 2021 6:43 am

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.
emile_b
 
Joined: 22 Sep 2019
Operating System: Windows 10/8.1/8/201x 64-bit
Graphics Processor: nVidia (Modern GZDoom)

PreviousNext

Return to Developer Blog

Who is online

Users browsing this forum: No registered users and 0 guests