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

[Siarhei Siamashka]

On Fri, 29 May 2015 13:08:49 +0300
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> 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?

Yes, the process of generating pseudo-random numbers is equally
random either way. Just the results and the CRC32 end up different
because random numbers land in different slots and are used for
different things. It is somewhat similar to using a different seed.

For example, if you are generating an a8r8g8b8 pixel and want it
to be the same on big and little endian systems, it needs to be
generated as a 32-bit pseudo-random number and not as an array
of 8-bit values. This way red pixels remain red, opaque pixels
remain opaque, etc.

Either the process of generating random images needs to take care
of the endian differences, or we can have separate CRC32 checksums
for big and little endian systems. Currently pixman prefers the
former approach.

> 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.

The bugs can be never ruled out completely, but in this case it is
unlikely.

-- 
Best regards,
Siarhei Siamashka