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

[Pekka Paalanen]

On Fri, 29 May 2015 15:24:42 +0300
Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote:

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

D'oh!

Thank you. :-)

Ben, could you prep a final patch from this, complete with Fernando's
Tested-by and the list of archs where tested?

Thanks,
pq