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

[Mathias Fröhlich]

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.

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.

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?

best

Mathias