[Mesa-dev] [PATCH 04/11] st/mesa: Use Array._DrawVAO in st_atom_array.c.

[Erik Faye-Lund]

On Fri, 2018-11-30 at 07:06 +0100, Mathias Fröhlich wrote:
> Good Morning,
> 
> On Tuesday, 27 November 2018 10:17:07 CET Erik Faye-Lund wrote:
> > On Tue, 2018-11-27 at 07:11 +0100, Mathias Fröhlich wrote:
> > > Hi Erik,
> > > 
> > > > > On Monday, 26 November 2018 19:39:50 CET Erik Faye-Lund
> > > > > wrote:
> > > > > > I know this is *very* late notice, but this commit broke
> > > > > > Super
> > > > > > Tux
> > > > > > Kart
> > > > > > on VirGL. Both the player-models as as well as the level
> > > > > > data
> > > > > > renders
> > > > > > with gibberish vertex positions since this commit.
> > > > > > 
> > > > > > The fix that Rob Clark did on top does not fix the problem
> > > > > > (and
> > > > > > shouldn't have; VirGL doesn't use NIR).
> > > > > 
> > > > > Do you have any idea how I can reproduce that issue with the
> > > > > least
> > > > > effort?
> > > > > 
> > > > 
> > > > Sadly, no. I run a qemu VM where I run super tux cart. It's a
> > > > rather
> > > > convoluted setup, I'm afraid. If you're interested in that
> > > > Robert
> > > > Foss
> > > > has written an article about how to set something like this up
> > > > here:
> > > > https://memcpy.io/virtualizing-gpu-access.html
> > > > 
> > > > ...But I totally understand if this is asking a bit too much. I
> > > > can
> > > > help out with any information you need...
> > > 
> > > Thanks!
> > > That, just means that looking into has to wait at least until the
> > > weekend.
> > > Probably even later.
> > > 
> > > And thanks for looking up the constants.
> > > The effective binding computation depends on these and may change
> > > the set up combined buffer objects. So these are interesting to
> > > know.
> > > 
> > > I have been putting a lot of internal verification into the code
> > > paths
> > > especially _mesa_update_vao_derived_arrays contains a larger
> > > #ifndef NDEBUG part that may tell us if there is something
> > > unexpected.
> > > 
> > > I assume you did run also with asserts enabled in the build?
> > 
> > Yes, I ran with asserts on, and none triggered.
> 
> Ok, there should not be a problem.
> At least nothing that I anticipated goes wrong.
> 
> > > I can observe some flicker in supertuxcart on i965. The nvidia
> > > blob
> > > seems
> > > not to flicker here. Also when running through valgrind I don't
> > > get
> > > that flicker
> > > on i965. Is that flashing - initially looked like a lighting
> > > effect
> > > of the game to
> > > me - what you observe too?
> > 
> > No, the models are completely garbled. You can find some example
> > screenshots here:
> > 
> > https://gitlab.freedesktop.org/virgl/virglrenderer/issues/59
> > 
> > > Also what are the game options? Are shaders enabled in some way?
> > 
> > I'm playing with the default settings. I'm not sure what you mean
> > with
> > "are shaders enabled"; VirGL is a gallium-driver, everything uses
> > shaders.
> 
> Ok, that is about what I meant. Sometimes that goes back to a pre
> shader
> render engine behind the scenens.
> Yes, gallium is always shaders, but depending on the higher level
> render techinque used
> you may need different array setups with more or less vertex
> attributes. Thing
> of tangent space that you do not need for a simple renderer. So,
> finally that may
> influence the setup and trigger things. But what you report sounds
> pretty
> fundamental.

Yeah. An important thing to note is that virgl is pretty widely tested
by now, and we don't see this pop up in other places... And that sounds
a bit strange to me.

> The good side is that I set up at least what was easy to set up here,
> that is
> a fedora 29 using virgl on a fedora 28 host using an Intel skylake
> type GPU.
> 
> Linux 4.19.4-300.fc29.x86_64 #1 SMP Fri Nov 23 13:03:11 UTC 2018
> x86_64
> [info   ] IrrDriver: OpenGL version: 3.3
> [info   ] IrrDriver: OpenGL vendor: Red Hat
> [info   ] IrrDriver: OpenGL renderer: virgl
> [info   ] IrrDriver: OpenGL version string: 3.3 (Core Profile) Mesa
> 18.2.4
> 
> But, that just works. supertuxkart runs without any vertex corruption
> problems
> on that combination. The installed default rpm of mesa is not patched
> in any way
> that makes me suspicious regarding our problem. And git log mesa-
> 18.2.4 tells
> me that the patch you mention is included in 18.2.4.
> 
> Means either I do not yet reproduce the problem correctly on the
> application side.
> Well, seems like already the initial screen to configure the track
> and that
> should show problems, which run already fine on my combination.
> 
> Or we have a side effect somewhere in the complete chain down to the
> host system, which is triggered by that patch.
> 

Right. This is super-strange to me; we (Collabora) have multiple people
reproducing it independently (CC'ed Gert). What version of
virglrenderer are you using? Perhaps we have some misbehavior in newer
versions of it that was just masked without this patch?

> So, looking at that game directly on the host system, that one has
> flaws
> like the mentioned flashlight like frames that are probably missing
> some geometry in one way or the other.
> 
> Means here:
> game + mesa-18.0.5 + Skylake GT2 -> fail
> game + mesa-18.2.4 + virgl + mesa-18.0.5 + Skylake GT2 -> works
> 
> Hmm, one question, on the mentioned setup on virgl. How does
> glxgears render on that setup? Or alternatively how do other OpenGL
> applications different from supertuxkart on that setup?

glxgears renders just fine. We'er also passing pretty much all of the
OpenGL 4.3 CTS and most of piglit. Generally speaking, this doesn't
trigger.

I just got a notice that Serious Sam 3 has a similar problem (I haven't
tested this myself)... So perhaps there's some pattern that can be
found?

> 
> best
> 
> Mathias
> 
>