Siarhei Siamashka <[email protected]> writes: > > Reviews appreciated. I'd also appreciate if people can test that it > > still compiles and works on ARM as I had to make some changes blindly > > there. > > It compiles fine, but requires a minor fix for ARM NEON. These two lines need > a 'PIXMAN_a8' -> 'PIXMAN_solid' change: > > + { PIXMAN_OP_OVER, PIXMAN_a8r8g8b8, PIXMAN_a8, PIXMAN_a8r8g8b8, > neon_composite_over_8888_n_8888, 0 }, > + { PIXMAN_OP_OVER, PIXMAN_a8r8g8b8, PIXMAN_a8, PIXMAN_x8r8g8b8, > neon_composite_over_8888_n_8888, 0 }, > > This was spotted by just patch review.
Thanks - I have fixed this and pushed the patch. > But it's also worth mentioning that > using 'blitters-test', the problem gets only detected on 3280827th iteration. > And the test is currently set to run 2000000 iterations by default. Just the > probability of getting right operation and right formats for source, mask and > destination all at the same time is a bit too low. > Tweaking probabilities for more uniform coverage may help a bit. Increasing > the number of iterations that are run by default may also be useful. But > still, an overnight run makes sense to spot some of the more rare problems. Yeah, we should probably at have at least two CRC32 values, one for the 2 million case, and one for a 100 million case that could run overnight. It might also be interesting to have many more than two values, and store them in a table where each row would contain both CRC and seed for 2 million iterations, for 4 million, for 6 million and so on. The test could then pick a range to run at random, which would substantially increase the coverage. Soren _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
