[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 #30 from Roland Scheidegger <sroland at vmware.com> ---
(In reply to Rob Clark from comment #26)
> (In reply to Ben Crocker from comment #25)
> >
> > Regarding Ray's specific comment about getting scalar fetch to work
> > with "sufficient twiddling," I think it's perfectly acceptable to
> > introduce extra operations, as long as we restrict the extra
> > operations to the big-endian path.  PPC64 (LE or BE) is fast enough so
> > that any performance impact will be negligible; S390 is less fast, but
> > I imagine production machines with more memory than the one we
> > experimented on here are fast enough.
> 
> drive-by comment.. unless llvm is just rubbish at optimization, I don't
> think saving a few operations in the front-end IR building should be that
> important, even for LE.
Well, yes and no. Yes, if it makes things conceptually simpler (which probably
isn't really the case here).
I'm not sure how good llvm is there with the ppc backend. But for x86, no you
can't assume optimization will take care of everything neatly, in particular
for load/shuffle combinations. If you look at it, there is in fact lots of hack
code around gathering of values (on x86), simply because llvm can't do some
kind of optimizations (in particular, it can't do any optimizations crossing
scalar/vector boundaries, so if you zero-extend values after a scalar load or
after assembling into vectors makes a large difference in generated code
quality, or if you use a int load llvm will not consider using float shuffles
afterwards even if it means using 3 shuffle instructions instead of just 1 and
so on (llvm has no real model of domain transition penalty costs, which don't
exist in these cases on most cpus), albeit that latter problem has been fixed
with llvm 4.0).
However, I would not expect these particular bits to be a problem on non-x86
cpus. I think int/float issues are x86 specific (other simd instructions sets
afaik don't tend to have different int/float load/store, shuffle or even logic
op operations). So, going for the conceptually simplest solution should be
alright (albeit for instance the scalar/vector "optimization barrier" is
probably going to affect all backends).

>  But we have shader-db so it should be possible to
> prove/disprove that theory.  (Not sure if llvmpipe is instrumented for
> shader-db but if not that should be easy to solve.)
Yeah I suppose should really do that at some point...

-- 
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/20170530/c32d521c/attachment.html>