[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