On 03/02/16 17:01, Marek Olšák wrote:
On Wed, Feb 3, 2016 at 5:37 PM, Roland Scheidegger <srol...@vmware.com> wrote:
Am 03.02.2016 um 10:38 schrieb Michel Dänzer:
On 03.02.2016 18:29, Marek Olšák wrote:
On Wed, Feb 3, 2016 at 10:19 AM, Michel Dänzer <mic...@daenzer.net> wrote:
On 03.02.2016 05:15, Marek Olšák wrote:
On Sat, Jan 30, 2016 at 12:46 AM, Marek Olšák <mar...@gmail.com> wrote:
From: Marek Olšák <marek.ol...@amd.com>
Based on a gallivm patch by Ilia Mirkin.
+8 piglit regressions due to precision issues
You're saying this patch causes 8 piglit tests to fail? What are the
benefits we get in exchange for that?
The tests are too strict and llvmpipe allegedly fails them too.
Allegedly? You can easily test that. :)
That's not so easy. I'm not even entirely sure they are really too strict.
The glsl wording leaves something to be desired, with things such as
"rounding mode is undefined" but yet it requires at least some
operations to be "correctly rounded".
FWIW the arb_shader_packing tests require either round-to-nearest-even
or round-to-nearest-trunc (both with rounding not representable finite
values to infinity), whereas llvmpipe does just trunc (which comes with
round-to-max-finite). (There's also the question about fp16 denorms -
llvmpipe will flush them to zero for pack, but handle them on unpack,
again glsl doesn't really say anything about that...). However, I wasn't
brave enough to actually enable it for llvmpipe at least for now...
A simple test that checks if the results are within reasonable bounds
should be enough in my opinion. We can't change the behavior of the
hardware instructions anyway.
I totally agree.
I said similar things to Roland internally.
Even if with llvmpipe there's nothing we can't change, I don't think
it's worth our time fine tuning things that are poorly specced, or well
specced but loosely implemented in practice.
The piglit tests should foremost veryfy that things work reasonably.
And IF we really care for precise rounding, we should have a separate
test/subtest that checks just for that (so that nobody loses any sleep
if it fails.)
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
