StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>This question is essentially unanswerable for two reasons:</p> <ol> <li><p>There are several ways of "reconstructing position from depth", with different performance characteristics.</p></li> <li><p>It is <em>very</em> hardware-dependent.</p></li> </ol> <p>The last point is important. You're essentially comparing the performance of a texture fetch of a <code>GL_RGBA16F</code> (at a minimum) to the performance of a <code>GL_DEPTH24_STENCIL8</code> fetch followed by some ALU computations. Basically, you're asking if the cost of fetching an addition 32-bits per fragment (the difference between the 24x8 fetch and the RGBA16F fetch) is equivalent to the ALU computations.</p> <p>That's going to change with various things. The performance of fetching memory, texture cache sizes, and so forth will all have an effect on texture fetch performance. And the speed of ALUs depends on how many are going to be in-flight at once (ie: number of shading units), as well as clock speeds and so forth.</p> <p>In short, there are far too many variables here to <em>know</em> an answer a priori.</p> <p>That being said, consider history.</p> <p>In the earliest days of shaders, back in the GeForce 3 days, people would need to re-normalize a normal passed from the vertex shader. They did this by using a <em>cubemap</em>, not by doing math computations on the normal. Why? Because it was faster.</p> <p>Today, there's pretty much <em>no</em> common programmable GPU hardware, in the desktop or mobile spaces, where a cubemap texture fetch is faster than a dot-product, reciprocal square-root, and a vector multiply. Computational performance in the long-run outstrips memory access performance.</p> <p>So I'd suggest going with history and finding a <a href="https://www.opengl.org/wiki/Compute_eye_space_from_window_space" rel="nofollow">quick means of computing it in your shader</a>.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload