Am 09.08.2015 um 12:11 schrieb Oded Gabbay:
> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
>> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay <oded.gab...@gmail.com> wrote:
>>> On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand <ja...@jlekstrand.net>
>>> wrote:
>>>
>>> If I understand your patch, instead of using the endian-dependent
>>> defines, you use the LE defines all the time when converting
>>> pipe<-->mesa formats
>>>
>>> I'm not saying its wrong, but these endian-dependent defines, e.g.
>>> PIPE_FORMAT_ARGB8888_UNORM, are used in more places in the gallium
>>> code than in the above two functions. Why change only here and not in
>>> all places, i.e removing them ?
>>>
>>> Also, this fixes only llvmpipe/softpipe. It doesn't fix sw_rast. That
>>> is still broken
>>
>> The fact that sw_rast is broken bothers me. The sw_rast code doesn't
>> leave core mesa so it shouldn't be affected by any gallium changes.
>> From that perspective, this makes sense. However, sw_rast should be
>> using the auto-generated packing/unpacking functions in core mesa.
>> Did sw_rast work prior to the readpixels changes? It's possible it
>> was already broken.
>>
> I didn't check sw_rast status before readpixels changes.
> However, from looking at the automatic pack/unpack functions, it seems
> strange to me they don't take into account the endianness.
> e.g on ppc64 machine, in file format_pack.c, there is the following function:
>
> static inline void
> pack_ubyte_a8b8g8r8_unorm(const GLubyte src[4], void *dst)
> {
> uint8_t a = _mesa_unorm_to_unorm(src[3], 8, 8);
> uint8_t b = _mesa_unorm_to_unorm(src[2], 8, 8);
> uint8_t g = _mesa_unorm_to_unorm(src[1], 8, 8);
> uint8_t r = _mesa_unorm_to_unorm(src[0], 8, 8);
>
> uint32_t d = 0;
> d |= PACK(a, 0, 8);
> d |= PACK(b, 8, 8);
> d |= PACK(g, 16, 8);
> d |= PACK(r, 24, 8);
> (*(uint32_t *) dst) = d;
> }
Aside from the endianness issues, it actually looks like this does some
totally unnecessary math for 8bit unorm to 8bit unorm "conversion". Odd...
Roland
> PACK is defined as:
> #define PACK(SRC, OFFSET, BITS) (((SRC) & MAX_UINT(BITS)) << (OFFSET))
>
> So, we see that 'R' is written to the most-significant byte of the
> dword and 'A' is written to the least-significant byte of the dword,
> although in BE, that should be reversed, since this is abgr format,
> not rgba.
>
> It's enough to see that the implementation of this function is the
> same for LE and BE to suspect the code, unless I'm missing something.
>
>
>>> I tested this patch on llvmpipe, combined with the previous patch you
>>> sent on POWER8 machine running ppc64 (BE)
>>> First of all, as I said above, it fixes the piglit sanity test.
>>> Second, it seems that it improves piglit gpu.py results much more than
>>> my patch. "Only" 1368 tests failed, vs. a bit more than 2000 with my
>>> patch. Still a lot higher than the ~600 tests that fail on ppc64le
>>
>> I'm not surprised that it didn't get to zero regressions vs. ppc64le.
>> This patch was just kind of thrown together and I didn't check all of
>> the formats. Also, as per my conversation with rolland, I may be
>> misunderstanding the PIPE_FORMAT enums.
>>
>> Really, this is a problem that is going to have to be chased by
>> someone other than me. I have no BE hardware, so I can't really chase
>> it down. I I also have very limited gallium knowledge so I'm probably
>> not the best person to start chasing it through gallium. All I've
>> done so far is throw darts at the wall. I'm sure this patch is
>> incomplete and, to be honest, I didn't even compile-test it as I don't
>> usually build gallium. What i do know is that, for the most part, the
>> core mesa code is consistent with itself as far as endianness goes.
>
> So I'm not married to my patch, and your 2 patches seem to do a better
> job (although sw-rast is still broken, but that's another issue and
> frankly, it is of less importance for me atm), and I accept your
> arguments for your solution. I would suggest that you upstream your
> patches as a start and I will continue from there, based on my
> schedule.
>
>>
>> If you want to see what a given format means in a more explicit
>> fashion, just look at the auto-generated format_pack.c and
>> format_unpack.c files. gallium has similar auto-generated format
>> packing functions. If you can digest what each of them means on BE,
>> then it should be pretty obvious how to match things up.
>> --Jason
> As I pointed above, I think the auto-generated code is not
> endian-aware, which is a problem, IMO.
>
>>
>> P.S. Thanks for bringing this up and taking the time to look into it.
>> Mesa claims to work on BE but, as you've clearly demonstrated, it's
>> completely broken. I'm sure we'd all like to see it working again.
>
> Although I'm focused more on ppc64le, I will probably be able to
> squeeze some fixes in for ppc64, and fortunately I have the H/W to
> check it. I appreciate your help and will be glad if you could take a
> look at future patches I will send on the subject.
>
> Oded
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
