----- Original Message -----
> >
> > was doing some piglit comparisons between softpipe and llvmpipe and
> > noticed the fbo-alphatest-formats test fails on llvmpipe for all
> > the
> > I8 formats.
> >
> > Now I looked at the code generated for
> > lp_tile_soa.c:lp_tile_i8_unorm_unswizzle_4ub and it references
> > a[i+0]
> > and a[i+1], if I change it to reference r[i + 0] and r[i + 1] the
> > tests all pass, I suspect of course this code is reading off the
> > end
> > of the array for an I8_UNORM, but I'm not really sure what it
> > expects
> > to happen in this case.

I don't think it is overflowing, but it's generating the I8 values from 
incoming fragments's alpha channel, instead of red.  The swizzled rendertargets 
have the all four channels (and they all have independent values), even on 
formats where the swizzles are replicated.

And it looks like the expectation is that the resulting I8 values should match 
the fragment's red value, and not alpha. I've checked the GL 2.1 and it is 
indeed so (see "
Table 3.15: Conversion from RGBA and depth pixel components to internal 
texture, table, or filter components.").

> > Maybe someone can take a look and let me know what the intentions
> > were
> > originally.
> >
> 
> Okay this fixes it here, and even seems reasonable to me.

Yes. Great catch Dave.

This should also fix to L8 rendering.  But I belive that in the commit message, 
you mean "i8" and not "l8".

Please add a comment about why order matters in the inv_swizzle() function, for 
future reference.



This also reminds me that we're needlessly (and maybe wrongly) blending 
replicated channels (e.g., in I8 we are blending G, B, and A channels 
unnecessarily, furthermore, with different values from R channel). This could 
be improved.  However the current plan is to drop swizzled rendertargets all 
together, as the simpler/faster blending doesn't seem to compensate over the 
the added pressure on the processor caches that the swizzled copies imply.


Jose


_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to