[Mesa-dev] [PATCH 3/3] i965/fs: Implement texelFetch() on Gen4.
Eric Anholt
eric at anholt.net
Mon Sep 19 13:14:23 PDT 2011
On Fri, 09 Sep 2011 20:18:02 -0700, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On 09/09/2011 10:07 AM, Eric Anholt wrote:
> > On Thu, 8 Sep 2011 15:49:23 -0700, Kenneth Graunke <kenneth at whitecape.org> wrote:
> >> + /* Initialize the rest of u/v/r with 0.0, for safety */
> >> + for (int i = ir->coordinate->type->vector_elements; i < 3; i++) {
> >> + emit(BRW_OPCODE_MOV, fs_reg(MRF, base_mrf + mlen + i * 2), fs_reg(0.0f));
> >> + }
> >> +
> >
> > Didn't we decide that it was not just "for safety", but that that text
> > about out of bounds returning 0 was what made that code required?
>
> I don't recall any text about "out of bounds returning 0." Perhaps you
> found something after our conversation? The closest I could find is in
> the "ld" Message Type table entry:
>
> "[Pre-DevIL] Errata: For the SIMD8 and SIMD4x2 forms of this message,
> the v parameter must be set to zero for non-array SURFTYPE_1D, and r
> must be set to zero for all SURFTYPE_1D and array SURFTYPE_2D surfaces."
I was thinking, from the same table:
"all address control modes are “zero” (a special mode in which any texel
off the map or outside the MIP range of the surface has a value of zero
in all channels, except for surface formats without an alpha channel,
which will return a value of one in the alpha channel)"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110919/0ea5aeb4/attachment-0001.pgp>
More information about the mesa-dev
mailing list