[Mesa-dev] [Piglit] [PATCH] Add (un)packHalf tests which don't fail on GCN
Roland Scheidegger
sroland at vmware.com
Fri Feb 5 01:35:48 UTC 2016
Am 05.02.2016 um 01:55 schrieb Matt Turner:
> On Thu, Feb 4, 2016 at 10:50 AM, Marek Olšák <maraeo at gmail.com> wrote:
>> From: Marek Olšák <marek.olsak at amd.com>
>>
>> This is a subset of the generated tests which are known to fail
>> on everything except CPU emulation (AFAIK).
>> ---
>
> This is really awful. Committing a generated test, but with unknown
> bits chopped out is gross.
>
> If it were me, I'd want to understand why my hardware behaved
> differently -- not just hack up *different* tests and claim victory.
>
> FWIW, the generated tests pass on all Intel hardware exposing
> ARB_shading_language_packing. Gen7+ has native half-float support, and
> Gen6 uses the lowering code in lower_packing_builtins.cpp to turn the
> built-ins into a pile of instructions.
I don't think that's surprising. The glsl lowering code (and the core
mesa half float conversion code) were written to match intel hw as far
as I know. And the tests were later written to match those rounding
semantics :-). But, the test passes on nvidia blob as well, so it's not
quite that unreasonable. It would be nice though if the test could tell
if it's failing because it doesn't work at all or because some rounding
is a bit different (which may or may not be allowed by glsl, maybe
someone can figure that out...).
Roland
>
> If you can identify how AMD hardware behaves differently and can prove
> that the generator needs to be relaxed or something, that's cool. But
> as is, I hate this patch.
>
> I can't find anything in the AMD docs (I looked at GCN3) about
> half-precision support, so I can't check my theory that AMD hardware
> rounds towards zero instead of to-nearest/even like Intel.
> _______________________________________________
> Piglit mailing list
> Piglit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/piglit
>
More information about the mesa-dev
mailing list