gl_Position.z isn't bound by any range. It doesn't have to be clipped
(it can be clamped instead), but if it's clipped, the value outside of
the range still affects the whole primitive that can be at least
partially visible.
Marek
On Sat, Jan 17, 2015 at 5:07 PM, Thomas Helland
I see why you are worried, and I agree 100%.
This just reinforces my impression that expanding this pass does
not give adequate return on investment.
If we had even better coverage we just might get some advantage,
but even then I have a bad feeling about this.
Do you have any suggestions for
Well, max(x, 0) has no effect on NaNs. According to the GLSL
specification, max() should return x if either argument is NaN. So the
correct way to convert NaN to 0 is:
max(0, y)
That implies that min and max aren't commutative if NaNs are supported.
Marek
On Fri, Jan 9, 2015 at 4:15 AM, Connor
Also, you seem to be assuming that IEEE and D3D10 versions of the
min() and max() are the same, which is not true. Both GLSL and D3D10
versions should work according to IEEE754, yet they are different. The
GLSL versions use conditional assignments, which is the same as C. The
D3D10 versions are
On Sun, Jan 11, 2015 at 6:57 AM, Marek Olšák mar...@gmail.com wrote:
Well, max(x, 0) has no effect on NaNs. According to the GLSL
specification, max() should return x if either argument is NaN. So the
correct way to convert NaN to 0 is:
max(0, y)
That implies that min and max aren't
On Sat, Jan 3, 2015 at 2:18 PM, Thomas Helland
thomashellan...@gmail.com wrote:
Also handle undefined behaviour for sqrt(x) where x 0
and rsq(x) where x = 0.
This gives us some reduction in instruction count on three
Dungeon Defenders shaders as they are doing: max(exp(x), 0)
So initially
Also handle undefined behaviour for sqrt(x) where x 0
and rsq(x) where x = 0.
This gives us some reduction in instruction count on three
Dungeon Defenders shaders as they are doing: max(exp(x), 0)
v2: Change to use new IS_CONSTANT() macro
Fix high unintenionally not being returned
Add
