llvmpipe: Fix random number generation for unit tests
authorRoland Scheidegger <sroland@vmware.com>
Mon, 7 May 2018 19:04:27 +0000 (21:04 +0200)
committerRoland Scheidegger <sroland@vmware.com>
Mon, 14 May 2018 01:14:00 +0000 (03:14 +0200)
commitcf3fb42fb5eb6130693a4be0a7b5ea06b184ce2d
tree976915fb72eaf8f699b88db45f25a2dfe9662636
parent5978d54a09e6ad151c0bd365de0e2c82bbf493d1
llvmpipe: Fix random number generation for unit tests

We were never producing negative numbers for signed types.
Also fix only producing half the valid range for uint32, and
properly clamp signed values.

Because this now also properly tests snorm with actually negative
values, need to increase eps for such conversions. I believe these
cannot actually be hit in ordinary operation (e.g. if a snorm texture
is sampled and output to snorm RT, it will still go through snorm->float
and float->snorm conversion), so don't bother to do anything to fix
the bad accuracy (might be quite complex).
Basically, the issue is for something like snorm16->snorm8 that in the
end this will just use a 8 bit arithmetic right shift.
But the math behind it says we should actually do a division by 32767 / 127, which
is ~258, not 256. So the result can be one bit off (values have too large
magnitude), and furthermore, the shift has incorrect rounding (always rounds
down). For positive numbers, these errors have different direction, but
for negative ones they have the same, hence for some values the error will
be 2 bit in the end.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106232
src/gallium/drivers/llvmpipe/lp_test_conv.c
src/gallium/drivers/llvmpipe/lp_test_main.c