[Mesa-dev] [Bug 100613] Regression in Mesa 17 on s390x (zSystems)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=100613

--- Comment #23 from Roland Scheidegger <sroland at vmware.com> ---
(In reply to Ray Strode from comment #20)
> in this layout, vec_nr needs to be 0, then 1, then 1 to get the correct
> values, which is achieved with 
> 
> vec_nr = (fetch_width - (chan_desc.shift + chan_desc.size)) / type.width);
> 
> Of course, I think we want to unconditionally (on big endian) use: 
> 
> vec_nr = (format_desc->block.bits - (chan_desc.shift + chan_desc.size)) /
> type.width;
Well, it doesn't really matter I suppose. Albeit it's probably easier to
understand if the first elements end up in the first vector.

> instead, which leaves vec_nr as 0, then 0, then 1.  In order for that to
> work, it requires dst[0]837060
>  to look like:
> 
> dst[0] = [ [y1  x1]  [y2  x1]  [y1  x2]  [y1  x2] ]
>  
> We almost get there by using vector_justify = TRUE. it leaves us with:
> 
> packed[0] = [ x1  y1  z1 pad  x1  y2  z2 pad ]
> packed[1] = [ x2  y1  z3 pad  x2  y1  z3 pad ]
> 
> dst[0] = [ [x1  y1] [x1  y2] [x2  y1] [x2  y1] ]
> 
> So, when vector_justify is TRUE, we end up with almost what we want.  Just
> the x and y coordinates are sitting in each 32 bit word in reverse. (i'm
> omitting dst[1] for brevity, but it works out to byteswap those, too).  This
> is why adding the u_format.csv big endian entry for the very odd looking
> swizzle format yxz1 worked.  It's letting the chan swizzle at the end do the
> swapping for us.  I don't think it's a good idea to rely on that though. So
> I guess in the cases we do a scalar fetch we need to justify and swap ?
> 
> I guess it's somewhat analogous to say
> 
> short foo[2] = [ 0x1111, 0x2222 ];
> int32_t bar = *(int32_t *) foo
> 
> where you normally would need to swap on bigendian if you want to keep
> 0x1111 first/least significant.

Yes, that would make sense. Albeit we really want to do something which makes
sense (so, we don't want to do some load where the cpu has to do extra work
just so it ends up in a wrong order we will need to swizzle some more), which I
can't quite tell. But if things are simpler with always using scalar loads for
instance, could just do that on BE.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170505/5bbbe70d/attachment.html>