On Fre, 2013-01-11 at 11:53 -0200, Adhemerval Zanella wrote: > > I'm trying to make llvmpipe work correctly on PowerPC64. The llvm MCJIT > backend > works pretty well now, so now I'm focused on the llvmpipe code. I already > sent a few > patches to address the existing testcases (lp_test_arit, lp_test_blend, > lp_test_conv, > lp_test_format, lp_test_printf). However I found out that the lp_test_format > is not coded right to take care of the endianess of the architecture, so I > had to > revert some changes of my two of my patches that do byte-swap in some format > handling > (the byte-swap in lp_bld_format_aos_array.c and lp_bld_format_aos.c). I'll > work on > patch to revert the patch and fix the testcase.
Fix according to what? :) There is no explicit definition of the byte order of PIPE_FORMAT_*, and the current code is inconsistent about it I think. I'm afraid we need to start at basics like that and work our way up from there. https://bugs.freedesktop.org/show_bug.cgi?id=43698 has a possible start for this for r300g assuming PIPE_FORMAT_* are always little endian. But I suspect it can't be that simple either, e.g. vertex elements probably need to use the CPU native byte order, as that's what e.g. GL apps write to VBOs. Maybe we'll need variants of at least some formats for both byte orders. I haven't looked into this for llvmpipe in any detail. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
