Closed GoogleCodeExporter closed 9 years ago
Original comment by alokp@chromium.org
on 9 Nov 2010 at 10:22
Should clamping be done in both GLSL and HLSL shaders? If so it would be best
to inject the clamping instructions into the AST itself so that it is
automatically handled by both translators.
Original comment by alokp@chromium.org
on 10 Nov 2010 at 4:04
It depends on whether HLSL has semantics that guarantee that out-of-range
accesses are safe. I know that DX10 class hardware handles out-of-range indices
during rendering of indexed geometry, but don't know about any rules covering
out-of-range uniform array accesses.
Agreed that it would probably be best and easiest to just do this at the AST
level. A first cut, at least, should certainly be done there.
We should only inject the clamp instructions when we can't prove that the
uniform array accesses are safe. Of course this is a harder problem, but at
least for simple indexing with just the loop index or a constant, we ought not
to inject unnecessary clamp instructions.
Original comment by kbr@chromium.org
on 10 Nov 2010 at 6:21
Direct3D 9 guarantees that when a vertex shader attempts to read an out of
range constant register, a (0, 0, 0, 0) vector is returned. Note that this
doesn't mean it clamps the index to the array size, but accesses are always
safe.
Personally I don't think clamping to the actual array size helps. Either way
the returned values are not what the shader programmer expects, no matter if
he's reading values from another array, or a null vector. If he expects
clamping behavior, he should explicitly do the clamping himself.
The GLSL ES spec states the following: "Reading from or writing to an array
with a non-constant index that is less than zero or greater than or equal to
the array's size results in undefined behavior. It is platform dependent how
bounded this undefined behavior may be. It is possible that it leads to
instability of the underlying system or corruption of memory. However, a
particular platform may bound the behavior such that this is not the case."
So just to be clear, out-of-range accesses in Direct3D are undefined but well
bounded. It will not cause instabilities or memory corruption.
Original comment by nicolas....@gmail.com
on 10 Nov 2010 at 10:44
> Personally I don't think clamping to the actual array size
> helps. Either way the returned values are not what the shader
> programmer expects, no matter if he's reading values from another
> array, or a null vector. If he expects clamping behavior, he
> should explicitly do the clamping himself.
>
> The GLSL ES spec states the following: "Reading from or writing
> to an array with a non-constant index that is less than zero or
> greater than or equal to the array's size results in undefined
> behavior. It is platform dependent how bounded this undefined
> behavior may be. It is possible that it leads to instability of
> the underlying system or corruption of memory. However, a
> particular platform may bound the behavior such that this is not
> the case."
It's not acceptable from the point of view of the WebGL API to potentially
allow random VRAM to be read or written, especially if the contents of that
VRAM might not have been written by the current application. For this reason
the clamping proposed here is essential.
It sounds like it's only needed for the GLSL backend. However, it would be most
easily done at the AST level, so perhaps a virtual function could be added that
can be overridden by TOutputGLSL / TOutputHLSL indicating whether the clamp
instructions are needed.
Original comment by kbr@chromium.org
on 10 Nov 2010 at 11:05
Original comment by kbr@chromium.org
on 7 Oct 2011 at 2:36
Changing this to Type-Defect; needs to be addressed.
Original comment by kbr@chromium.org
on 4 Oct 2012 at 8:27
Original comment by c...@chromium.org
on 7 Dec 2013 at 4:10
This was implemented by https://codereview.appspot.com/6999052
Original comment by c...@chromium.org
on 21 May 2014 at 2:48
Original issue reported on code.google.com by
kbr@chromium.org
on 30 Sep 2010 at 6:18