[Mesa-dev] llvmpipe vs fbo-alphatest-formats

[Jose Fonseca]

----- 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