[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 #3 from Roland Scheidegger <sroland at vmware.com> ---
(In reply to Stefan Dirsch from comment #2)
> Roland, thanks a lot for your prompt reply! Very much appreciated! 
> 
> Seems Richard meanwhile switched companies from IBM to ARM meanwhile. I
> found him on Linkedin. Possibly he's now working on aarch64 (LE). So I'm
> afraid he has no longer access to BE machines any longer.
> 
> Unfortunately I'm not familiar with llvmpipe at all. Would it be an option
> not to change the code there for BE, if developers have no access to such
> machines? Reverse-applying the commit is going to break sooner or later I'm
> sure.
That'll be theoretically possible but I can't say I particularly like that
solution. It doesn't make much sense that the fetch paths for BE and LE are
completely distinct...
Chances are it will break sooner or later anyway - this code really desperately
wants someone who is willing to test it and keep it working on BE.
(That it took 3 months until someone notices it's broken isn't a good sign...)
Otherwise there's probably a build change down the road which just disables
build on BE...

> 
> Of course I'm willing to test any proposed change/patch on s390x, but I'm
> not a Mesa/llvmwpipe developer per se.
> 
> Unfortunately llvmpipe is needed on s390x, since it has become a requirement
> for modern desktops like gdm/gnome-shell. :-(
All the more reason why someone might want to look into it...


> I can't say how fundamental the issue is. gdm and gnome-shell just show a
> black screen. :-( 
I don't know what vertex formats these use, but yes bogus vertex fetch will
make for a very bad experience (it's nearly a miracle glxgears still manages to
draw something in fact I like that new look better :-)).

I've taken a closer look now, and I can see some reasons why it doesn't work.
That said, I never really understood the vector_justify logic, which just looks
odd to me. But in the end the gather really is different for AoS and SoA (and I
didn't understand the differences there neither wrt vector_justify).

So, looking at R32G32B32F format (which glxgears uses) (for this format SoA vs.
AoS should not actually make that much of a difference, since it doesn't
require any actual conversion):
The old code would have called lp_build_fetch_rgba_aos() 4 times - which would
have resulted in 4 lp_build_gather with vector_justify set to TRUE, block_bits
96 and dst type of 1x128bit. The gather would have fetched 96 bits, do a ZEXT
and then (due to vector_justify - this is the stuff guarded with
PIPE_ARCH_BIG_ENDIAN in lp_bld_gather.c) do a left shift of 32 for some reason
I don't quite get (I thought it shouldn't make a difference with those array
formats if they are fetched on BE or LE but it looks like I'm wrong). The
values then would have gone through lp_build_format_swizzle_aos() (and I have
no idea if that swizzle looks different on BE) before finally getting
transposed to SoA.
The new code will now use one lp_build_fetch_rgba_soa() call. This will still
end up with 4 gathers, but in the soa path which always use vector_justify of
false (why? I have no idea but this was like that before), so you don't get the
left shift of 32. Oh and the values will be fetched as 3x32bit instead of a
96bit int (this particular change was one of the changes preceding this commit,
so you could verify independently if it breaks stuff, some piglit texture
format tests for instance could show that - unfortunately lp_test_format only
does (scalar) rgba_aos fetch, so not exactly helpful for that, but you really
want rgba SoA fetches working in general, regardless of vertex fetch), if that
makes any difference (again, I have no idea really) (it will do pad_vector, so
use a shuffle to extend the 3x32bit values to 4x32bit instead of using ZExt to
1x128bit, but I'm not worried about that particular bit). The values will then
be transposed and finally going into lp_build_format_swizzle_soa().
So, my guess is maybe things would work a bit better if you'd hack up the
vector_justify parameter to lp_build_gather() in lp_build_fetch_rgba_soa().
However, this near certainly breaks all the other callers of
lp_build_fetch_rgba_soa(), which is used for just about all texture formats
except the rgba8 ones, so glxgears and desktop compositors might still run but
probably not much else, you don't want to do that...

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