Testing a new rendering backend (New tests needed)

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

[phantombeta]

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)

[Rachael]

Neither the 860M nor the HD4850 are integrated GPU's. The 860M however is a laptop GPU, the HD4850 is not.

[phantombeta]

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.

[Rachael]

Yeah, that makes sense.

[Graf Zahl]

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]

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.

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

[Rachael]

I don't know if I did this right, for reference here is the patch for what I did:

---

Code: Select all • Expand view

diff --git a/src/common/rendering/gl/gl_renderbuffers.cpp b/src/common/rendering/gl/gl_renderbuffers.cpp
index a1d8899bb1..042e8c1828 100644
--- a/src/common/rendering/gl/gl_renderbuffers.cpp
+++ b/src/common/rendering/gl/gl_renderbuffers.cpp
@@ -194,7 +194,8 @@ void FGLRenderBuffers::CreateScene(int width, int height, int samples, bool need
    {
       if (needsSceneTextures)
       {
-         mSceneMultisampleTex = Create2DMultisampleTexture("SceneMultisample", GL_RGBA16F, width, height, samples, false);
+         //mSceneMultisampleTex = Create2DMultisampleTexture("SceneMultisample", GL_RGBA16F, width, height, samples, false);
+         mSceneMultisampleTex = Create2DMultisampleTexture("SceneMultisample", GL_RGBA8, width, height, samples, false);
          mSceneDepthStencilTex = Create2DMultisampleTexture("SceneDepthStencil", GL_DEPTH24_STENCIL8, width, height, samples, false);
          mSceneFogTex = Create2DMultisampleTexture("SceneFog", GL_RGBA8, width, height, samples, false);
          mSceneNormalTex = Create2DMultisampleTexture("SceneNormal", GL_RGB10_A2, width, height, samples, false);
@@ -203,7 +204,8 @@ void FGLRenderBuffers::CreateScene(int width, int height, int samples, bool need
       }
       else
       {
-         mSceneMultisampleBuf = CreateRenderBuffer("SceneMultisample", GL_RGBA16F, width, height, samples);
+         //mSceneMultisampleBuf = CreateRenderBuffer("SceneMultisample", GL_RGBA16F, width, height, samples);
+         mSceneMultisampleBuf = CreateRenderBuffer("SceneMultisample", GL_RGBA8, width, height, samples);
          mSceneDepthStencilBuf = CreateRenderBuffer("SceneDepthStencil", GL_DEPTH24_STENCIL8, width, height, samples);
          mSceneFB = CreateFrameBuffer("SceneFB", mSceneMultisampleBuf, mSceneDepthStencilBuf);
          mSceneDataFB = CreateFrameBuffer("SceneGBufferFB", mSceneMultisampleBuf, mSceneDepthStencilBuf);
@@ -241,7 +243,8 @@ void FGLRenderBuffers::CreatePipeline(int width, int height)
 
    for (int i = 0; i < NumPipelineTextures; i++)
    {
-      mPipelineTexture[i] = Create2DTexture("PipelineTexture", GL_RGBA16F, width, height);
+      //mPipelineTexture[i] = Create2DTexture("PipelineTexture", GL_RGBA16F, width, height);
+      mPipelineTexture[i] = Create2DTexture("PipelineTexture", GL_RGBA8, width, height);
       mPipelineFB[i] = CreateFrameBuffer("PipelineFB", mPipelineTexture[i]);
    }
 }
@@ -265,7 +268,8 @@ void FGLRenderBuffers::CreateEyeBuffers(int eye)
 
    while (mEyeFBs.Size() <= unsigned(eye))
    {
-      PPGLTexture texture = Create2DTexture("EyeTexture", GL_RGBA16F, mWidth, mHeight);
+      //PPGLTexture texture = Create2DTexture("EyeTexture", GL_RGBA16F, mWidth, mHeight);
+      PPGLTexture texture = Create2DTexture("EyeTexture", GL_RGBA8, mWidth, mHeight);
       mEyeTextures.Push(texture);
       mEyeFBs.Push(CreateFrameBuffer("EyeFB", texture));
    }


The benchmark test from those changes netted this result:

---

Code: Select all • Expand view

Map map01: "Hydroelectric Plant",
x = 4670.0000, y = 5980.0000, z = 476.0000, angle = 89.8956, pitch = 0.5219
8 fps

Walls: 14595 (0 splits, 2007 t-splits, 36300 vertices)
Flats: 989 (989 primitives, 226446 vertices)
Sprites: 832, Decals=0, Portals: 1, Command buffers: 0
BSP = 4.907, Clip=7.244
W: Render=81.784, Setup=6.386
F: Render=2.692, Setup=0.352
S: Render=2.899, Setup=0.561
2D: 0.264 Finish3D: 23.946
Main thread total=12.159, Main thread waiting=0.008 Worker thread total=12.141, Worker thread waiting=4.842
All=101.162, Render=87.574, Setup=12.194, Portal=0.129, Drawcalls=75.455, Postprocess=0.120, Finish=0.662
DLight - Walls: 0 processed, 0 rendered - Flats: 0 processed, 0 rendered



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]

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

[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]

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!

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

[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]

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.

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