Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: glsl/parallax: ifless reflection mapping 馃 #192

Closed
wants to merge 3 commits into from

Conversation

Projects
None yet
3 participants
@illwieckz
Copy link
Member

commented Mar 26, 2019

@gimhael or @cmf028, if if in glsl is very most costly than operations, why is this giving me no one extra fps at all?

What if I unroll the loops?

Note that I have an R9 390X, which is a beast, and maybe that beast is modern enough to handle if properly?

@illwieckz illwieckz changed the title WIP: glsl/parallax: ifless reflection mapping WIP: glsl/parallax: ifless reflection mapping 馃 Mar 26, 2019

@illwieckz illwieckz force-pushed the illwieckz:ifless branch from 428e342 to 90515cc Mar 26, 2019

@illwieckz

This comment has been minimized.

Copy link
Member Author

commented Mar 26, 2019

well, I unrolled the loops and I got no one extra fps鈥 馃槙

@illwieckz illwieckz force-pushed the illwieckz:ifless branch 3 times, most recently from f5b1fac to 70e5409 Mar 26, 2019

@slipher

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

With regard to the for-loop change, this is the same as what the compiler probably does internally. The before/after generated code could very well be identical.

@gimhael

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

It is quite normal that a shader optimization doesn't directly lead to a measurable FPS increase. The GPU processes the draw calls in a pipeline of several steps, and as in real life, the slowest step determines the overall speed of the pipeline.
If e.g. the fragment shader already produces more data than the ROPs can handle, then making the fragment shader even faster will not help overall performance. (The ROPs are the units that render the fragment shader outputs into the framebuffer.)

@illwieckz

This comment has been minimized.

Copy link
Member Author

commented Mar 26, 2019

The thing is that using an obviously quicker algorithm in that place without modifying anything else (like in #193) multiplies fps by 3鈥 This look to be the slowest step everything is waiting for. 炉\_(銉)_/炉

Without this code at all, a given solarium scene with an active flamethrower produces 200fps, with that code on lightmap and real time light the scene produces 30fps. With that code on lightmap and quicker code from #193 on real time light the scene produces 90fps. Everything else is an unmodified black box at this point. Everything looks to be waiting on this鈥

@illwieckz illwieckz force-pushed the illwieckz:ifless branch from 70e5409 to 46f67a3 Mar 27, 2019

@illwieckz illwieckz force-pushed the illwieckz:ifless branch from 46f67a3 to dca3c68 Mar 27, 2019

@slipher

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

The point is not that that a conditional is inherently bad, it's that in general you have to execute all possible code paths. So if you have if(...) { A } else { B } then the time to execute will be A + B (while it would be at most max(A, B) on a single processor). Or if you try to speed up a loop by having an early exit condition, it won't help because you have to wait for the maximum possible number of iterations for it to finish.

Doing a substitution like cond ? x : y -> cond * x + !cond * y is a bad idea because such things should be left to the compiler. It will have the knowledge of which way is efficient to achieve the goal.

@illwieckz

This comment has been minimized.

Copy link
Member Author

commented Mar 28, 2019

Oh thank you, that was the answer I was looking for. Well, I don't know why but my first assumption was wrong, it's not that conditions are inherently more costly than operations, it's conditions does not help to avoid operations.

So if I'm right, conditions are not bad in a way branching would be very costly by itself and must be avoided because of that branching cost itself, but conditions are bad in the way that all the code within the condition block is run even if the condition is false, the result just being discarded.

So in that way, avoiding the condition by making sure an operation is done in any way is not able to help, first I'm not replacing a costly operation by a non-costly one, second I just make sure that the code is always run to fix the fact the code is always run.

Doing what I did may even be able to slow down the compute if the compute trick that is meant to produce the same result without usage of if is slower than the compute within the if block itself.

Note: in that case I noticed no difference, on both R9 390X and Haswell.

So, I got my answer, thank you very much. Closing it.

@illwieckz illwieckz closed this Mar 28, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.