[Mesa-dev] [PATCH] mesa/main: Fix unpack_R5G6B5_UNORM.

[Roland Scheidegger]

Am 08.10.2014 um 07:11 schrieb Jason Ekstrand:
> 
> On Oct 8, 2014 6:36 AM, "Iago Toral" <itoral at igalia.com 
> <mailto:itoral at igalia.com>> wrote:
>> 
>> El 2014-10-07 21:46, Jason Ekstrand escribió:
>> 
>>> On Oct 7, 2014 12:04 PM, "Iago Toral Quiroga" <itoral at igalia.com
> <mailto:itoral at igalia.com>>
>>> wrote:
>>>> 
>>>> There is a comment warning about the fact that this is not
>>>> doing
>>> what we
>>>> expect, so fix it. This should be doing the same as
>>> unpack_B5G6R5_UNORM
>>>> but swapping B and R. ---
>>>> 
>>>> Jason started some work to auto-generate the format_pack.c and 
>>>> format_unpack.c files which I think has this fixed. I am
>>>> continuing
>>> his
>>>> work on this at the moment, but I guess it might make sense to
>>>> fix
>>> this in
>>>> the current code too while that work is on-going.
>>> 
>>> Not much time to reply right now, but I seem to recall there
>>> being a bit more to fix here.  What about packing and swrast's
>>> texel fetch implementation.  Are those OK for this format?
>>> 
>>>> No piglit regressions observed.
>>> 
>>> 
>>> On what drivers?  It might be good to test on swrast and
>>> llvmpipe. I'm not super-concerned there but we should at least
>>> try not to break it. --Jason
>> 
>> 
>> That was on Intel, but you are right, at least classic swrast has
>> some
> regressions with this.
>> 
>> For reference, I did not see any regressions on Gallium Softpipe
>> but I
> could only run a small subset of tests with this driver (-t texture
> -t color -t format)  or otherwise it would hog my CPU and eventually
> crash my system. Could not test with llvmpipe, for some reason, even
> when I am bulding with llvm and I see the llvmpipe sources being
> built Mesa insists in using the softpipe driver at runtime...
> 
> I can give you the configure flags for testing llvmpipe if you'd
> like. Yes, doing a full piglit run on llvmpipe or swrast requires a
> pretty beefy desktop and still takes quite a while.
> 
>> Since there are regressions on swrast at least I guess we should
>> just
> drop this patch until we have a proper fix for all drivers.
> 
> I'm not as worried about llvmpipe because it fails about half the
> tests it attempts anyway.  I would like to know what's going on with
> swrast though.
llvmpipe's result in the area of texture fetch should be near perfect
(at least if you've got a sse41 capable cpu), I'm not aware of any major
bugs there. It does, however, do some not quite conformant optimizations
by default (nothing which graphics hw at some point didn't already
do...). So, to get these perfect results, you'd need to set
GALLIVM_DEBUG=no_brilinear,no_quad_lod,no_rho_approx.
no_brilinear does not clamp lod to one mipmap if the lod is close enough
to that mipmap.
no_quad_lod does not do per quad lod if that's not conformant (ok for
ordinary implicit derivatives, not ok for explicit derivatives,
per-pixel lod bias etc.)
no_rho_approx will use suggested formula for rho calculation, though
OpenGL still explicitly permits using the simpler formula (swrast has
both formulas too though the simple one is ifdefed out).

On top of that, I believe there are some failures due to precision
issues with small (< 8 bits) numbers as the rescaling isn't perfect in
all places (IIRC we got a bunch more failures when the formula for
signed numbers was switched). However, this ought to be always just
precision, nothing like switched channels of course.

Roland