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

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.

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

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)

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

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.

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

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.

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

Sat Apr 03, 2021 12:31 pm

Yeah, that makes sense.

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

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.

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

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.

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

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.

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

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?

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

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.).

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

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.

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

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!

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

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.

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

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. :)

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

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.