[Pixman] [RFC PATCH] solid-test: Allow for big-endian targets

[Pekka Paalanen]

On Thu, 28 May 2015 16:08:55 -0300
Fernando Seiti Furusato <ferseiti at linux.vnet.ibm.com> wrote:

> Hi Ben.
> 
> On 05/28/2015 01:57 PM, Fernando Seiti Furusato wrote:
> > Hello Ben.
> >
> > On 05/27/2015 09:40 AM, Ben Avison wrote:
> >> On Tue, 26 May 2015 19:16:32 +0100, I wrote:
> >>
> >>> +        color.alpha = prng_rand_n (UINT16_MAX);
> >>> +        color.red   = prng_rand_n (UINT16_MAX);
> >>> +        color.green = prng_rand_n (UINT16_MAX);
> >>> +        color.blue  = prng_rand_n (UINT16_MAX);
> >>
> >> Oops, those should have been UINT16_MAX + 1; the argument is used as a
> >> modulo not as a bitmask. The corresponding checksum is then 0xC30FD380
> >> for me on ARM and x86 (both little-endian of course).
> >
> > I am sorry, I did not receive the original message you sent.
> > Luckily I looked in the archive and saw it in the same thread.
> > I will be looking into this, thanks for contacting me.
> 
> I have just tested that patch with these last adjustments you sent afterwards.
> The solid-test passed on all of the 3: ppc64le, ppc64 and powerpc.

Ok, cool.

But, I'm still a little confused as to why the patch makes a
difference. Sure, it changes the byte ordering when assigning random
values, but the values are still equally random, right?

Could it perhaps be related to pre-multiplication?

I think pixman_color needs to be pre-multiplied just like all other
alpha formats, which means that the above way to randomize values into
a pixman_color can produce "luminous" (or invalid?) colors.

Would that raise undefined behaviour, or should we expect Pixman to
handle also those cases always the same?

Maybe the iteration count (500000 in fuzzer_test_main call) should also
be increased? See
http://lists.freedesktop.org/archives/pixman/2014-April/003229.html
for a comment about testing overall:

	"The case of over_n_8888_8888_ca failure is a bit special. The
	problem is that just trying the seeds from 1 to 2000000 in the
	blitters-test does not provide enough coverage to catch all the
	bugs. That's why it was missed by 'make check'."

I suppose it's possible there is an actual bug in ppc64 fast paths and
it just hasn't been hit until now? There is test/fuzzer-find-diff.pl
that can be used to find out the particular iteration that fails.


Thanks,
pq