PDA

View Full Version : Resetting uniforms during active shader program: Good practice?



saski
07-07-2017, 07:50 AM
Hello,

I was wondering if it is good or bad practice to reset a uniform multiple times in an active shader program. Reason is that I have to change certain behaviours on my fragment shader because my geometry as different properties. Passing along a flag to my shader with
glExt_glUniform1i apparently works but perf shows many gpu stalls especially on nvidia devices.

I've also played around with coherent mapped UBOs but that didn't work at all because of synchronization issues between the cpu and gpu and I havent figured out how to efficiently do the synchronization inbetween swaps.

Would it be better to rebind the shader using
glUseProgram every time I have to change a uniform instead of passing uniforms along multiple times? What is more expensive in terms of stalls and performance drops?

Any ideas?

Dark Photon
07-08-2017, 02:41 PM
I was wondering if it is good or bad practice to reset a uniform multiple times in an active shader program.

This is fine, and in most cases should be fairly cheap for ordinary uniforms (e.g. scalars, vectors, etc.)


What is more expensive in terms of stalls and performance drops?

I think we're going to need more detail on what you're doing to be able to offer targeted advice.

The answer to the "what is more expensive" question is going to depend on the hardware, the driver, and the app (i.e. how the driver is being used). However, in general, changing the bound program is one of the most expensive things you'd typically do in a frame (not as expensive as changing the bound render target though). So I wouldn't add any more program binds than you absolutely have to have.

I'm not sure what stage you're at, but I think the first thing is determining what you're most bottlenecked on. Grab your favorite profiler. Measure your frame time, and try disabling things (render passes, shader binds, texture binds, uniform updates, etc.). What nets you the biggest change in your frame time? Look careful at things you're doing a lot of, and consider whether there's an efficient way to do it with fewer calls and updates.

In terms of relative cost, since you mentioned NVidia, see pg 48 here:

* Beyond Porting (https://www.slideshare.net/CassEveritt/beyond-porting) (2014)