In investigating bug 83570 I noticed that for shader code such as uniform bool u_debug; if(!u_debug) { //do some stuff } else { //do some other stuff } both the if and else are executing. Seems like a pretty trivial optimization...is there a reason it doesn't optimize out the excluded branch, or is it just "yet to be done"?
Are you talking about specific drivers? Doesn't look like a mesa core problem to me, since if it's a uniform glsl can't do anything, and drivers will have to handle that appropriately (typically hw either has if/else constructs with implicit built-in mask evaluation so there's jump addresses specified there (intel hd graphics seems to work like that) or the jump is done explicitly (radeon gcn seems to do that). If you're talking llvmpipe, you would be right it always evaluates all branches, no matter the current condition mask (which, in case the branch condition is based only on uniforms, indeed means one part of the branch will always be executed for nothing), and simply masks out the values for the not taken branch part when storing the values. This is probably both due to simplicity and historical reasons (don't forget early programmable hw did not always have true branches neither). It is something I was thinking about, I think there'd definitely be benefits but I never looked at it closely enough to know how much work it would be. For starters, you'd need to put the code in the branches into different basic blocks, and get all the things right related to it. In some cases it could possibly be a loss due to missing some optimizations (if both branches need to be evaluated - I don't think you'd want to do this just in case of uniform branch condition, though this might be a start).
Sorry - I'm talking about llvmpipe (Speaking of...what is the right bug component to choose for llvmpipe)? Seems not too simple to fix, but on the other hand some low hanging fruit (conceptually) to significantly improve performance.
(In reply to comment #2) > Sorry - I'm talking about llvmpipe (Speaking of...what is the right bug > component to choose for llvmpipe)? There isn't any, so typically it's other. > > Seems not too simple to fix, but on the other hand some low hanging fruit > (conceptually) to significantly improve performance. Don't forget llvmpipe is mostly useful for running simple things, like for instance desktop compositing, where the shaders might not even have any control flow. I agree it should help with more complex shaders, but optimizing for that just wasn't that important - developer time isn't unlimited. But feel free to give it a try :-).
This doesn't seem like a real bug, just a lack of optimization. I'm gong to close this. Feel free to re-open if you disagree.
Well it was already classified as an enhancement, so technically it's still open (I actually wrote some code to fix this but it's not fully fleshed out and never finished it).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.