Implement PushBuffer

[VReaperV]

Requires #1683

Add PushBuffer, update uniforms to have an updateType. The CONST and FRAME uniforms are written into a uniform buffer after the map is loaded/at the start of a frame. This allows skipping some of the glUniform*() calls to decrease the amount of overhead.

This largely re-uses the existing functionality added for the material system.

This will also be needed for #1587

[slipher]

This can be rebased now.

[VReaperV]

This can be rebased now.

Done.

[slipher]

Some issues found with testing:

1. Fog is not rendered if material system is enabled.
2. In one scene from my test script the dynamic light from the Painsaw is not rendered. I can't observe this with manual testing so I'd have to investigate more to provide a reliable repro.

[slipher]

2. In one scene from my test script the dynamic light from the Painsaw is not rendered. I can't observe this with manual testing so I'd have to investigate more to provide a reliable repro.

Now I found a way. Set common.framerate.max 3 and fire the Painsaw once. On master you will see a frame with the realtime light rendered, but on this branch no. Maybe there is some issue with data being a frame out of date.

[VReaperV]

1. Fog is not rendered if material system is enabled.

Fixed.

[VReaperV]

Now I found a way. Set common.framerate.max 3 and fire the Painsaw once. On master you will see a frame with the realtime light rendered, but on this branch no. Maybe there is some issue with data being a frame out of date.

Also fixed.

[slipher]

I confirm the 2 previous bugs are fixed. But I get the depth fade issue from #1676 again with this branch when enabling material system. It happens with any depth fade regardless of alpha tests, polygon offset etc. The bug reappears as of the first usable commit Add the remaining code for the global UBO in PushBuffer. (The first four commits don't build; GLUniform._global -> _updateType builds but doesn't render anything.)

[VReaperV]

I confirm the 2 previous bugs are fixed. But I get the depth fade issue from #1676 again with this branch when enabling material system. It happens with any depth fade regardless of alpha tests, polygon offset etc. The bug reappears as of the first usable commit Add the remaining code for the global UBO in PushBuffer. (The first four commits don't build; GLUniform._global -> _updateType builds but doesn't render anything.)

The comment there says it was already broken on material system? On my end it was working fine so I can't confirm if there's any issue with it on master right now.

[slipher]

It was broken but #1704 fixed it. It works on master.

[VReaperV]

It was broken but #1704 fixed it. It works on master.

Not sure what the issue is. I can't reproduce it on my end, and there don't seem to be any depth writes after glTextureBarrier().

[slipher]

The depth texture is all garbage all the time, as if it's not hooked up properly. It's still garbage if I set r_materialSystemSkip 1. It's still garbage with r_drawWorld 0 and nothing being rendered.

By the way, I realized you can make a depth texture visualization with just a q3shader, no GLSL required:

depthvis {
    {
        map _white
        depthFade 600
        blendFunc GL_SRC_ALPHA GL_ZERO
    }
}

[slipher]

Forgot screenshot

[VReaperV]

Hmm, the only thing I could think of is it has something to do with the textures being bindless. This is on AMD + Mesa, right? It might have the same cause as the broken occlusion culling reported there ~1 year ago.

[slipher]

This is on AMD + Mesa, right?

Yes

It might have the same cause as the broken occlusion culling reported there ~1 year ago.

On master if I turn on occlusion culling, it segfaults immediately.

[VReaperV]

On master if I turn on occlusion culling, it segfaults immediately.

Is the segfault coming from daemon? I don't get any on master.

[slipher]

I have provided a stack trace in #1724

[slipher]

Hmm, the only thing I could think of is it has something to do with the textures being bindless.

That's true, just r_preferBindlessTextures is enough to trigger the bug.

[VReaperV]

Hmm, the only thing I could think of is it has something to do with the textures being bindless.

That's true, just r_preferBindlessTextures is enough to trigger the bug.

Even with the fix from #1725?

[VReaperV]

I also uncovered another issue: when disabling r_arb_direct_state_access (and hence push buffers), the GLSL does not compile.

Fixed.

[VReaperV]

I've removed the previous workaround commit since it's not working.

[VReaperV]

I've got confirmation that it works fine on AMD proprietary with r_readonlyDepthBuffer 1.

[slipher]

Besides the depth fade issues on AMD + Mesa, I get a couple problems with the current branch:

• Warn: GL_BindToTMU: NULL image
• Lighting is globally dimmer but with more saturated areas (as if tonemapping disabled maybe?)

The slipher/pushbuffer-rebase branch does not have those extra issues. I don't know if any changes were made since the rebase.

[VReaperV]

Besides the depth fade issues on AMD + Mesa, I get a couple problems with the current branch:

• Warn: GL_BindToTMU: NULL image
• Lighting is globally dimmer but with more saturated areas (as if tonemapping disabled maybe?)

The slipher/pushbuffer-rebase branch does not have those extra issues. I don't know if any changes were made since the rebase.

First issue fixed, but I'm not reproducing the second one on NV. If it still happens and slipher/pushbuffer-rebase still works correctly, then the latter can be merged instead. The only real difference I'm seeing is in how uniform padding is calculated for PushBuffer, and whether pushBuffer.frameUniformsSize includes padding, but the effect should be the same.

[slipher]

It has the same issue as #1480 where screenshots apparently read from the wrong framebuffer.

[VReaperV]

I see. That is therefore not really relevant to the pr.

[slipher]

How is it not relevant? Screenshots work correctly in master but don't work in this PR.

[VReaperV]

How is it not relevant? Screenshots work correctly in master but don't work in this PR.

I cannot reproduce that, the issue must be with whatever setup was used for testing.

[slipher]

Hmm, the screenshot wrong framebuffer bug seems to be vendor-specific in this PushBuffer PR. I get it with AMD+Linux but not Nvidia+Windows. Unlike #1480 where I get it with both.

[VReaperV]

Hmm, the screenshot wrong framebuffer bug seems to be vendor-specific in this PushBuffer PR. I get it with AMD+Linux but not Nvidia+Windows. Unlike #1480 where I get it with both.

Perhaps it's something similar to the read-only depth buffer issue, but for colour render targets.

[slipher]

I wrote some code, available on the slipher/screenshot-debug branch, to check which framebuffer is being read. In the cases were screenshots are bugged from both PRs, I get screenshot from framebuffer 1 (_main[0]) instead of the expected framebuffer 0. So it seems like a simple issue of failing to select the desired GL_READ_FRAMEBUFFER.

#1882 should fix the issue for this PR, which turned out to be a bug with read-only depth buffers. Wrong screenshots on #1480 must have some other cause.

[slipher]

I have prepared #1883 which can help with the test failures. With the addition of #1883 you just need to add MATERIAL_OR_PUSH to the constructor of each uniform class in gl_shader_test.cpp to get tests to pass.

[VReaperV]

That'd work, thx.

[slipher]

So now the MATERIAL_OR_PUSH argument just has to be added to the test uniform constructors for it to compile.

LGTM modulo comments