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

[Mathias Fröhlich]

Hey,

On Monday, 3 December 2018 12:15:17 CET Erik Faye-Lund wrote:
> 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.

Good to know, I don't actually know how wide virgl is already in use.
I was surprised to find a direct knob already in fedoras version of libvirt.
And I am now disappointed that after upgrading to the newest fedora on the
bottom side it just crashes somewhere. I thought may be I can reproduce that
with something newer that I need anyhow in the not so distant future ...

So, I am currently again without a basic virgl system.

> > 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?

Sounds to me like that, or even worse something with the supertuxkart.
I have not yet understood what they are doing in detail with the VAO's.
But I was slightly looking into the direction of mmapping the buffer objects
and not flushing them correctly. That could potentially also lead to
such failures. Especially since some people observe and some not.
Not finally finished with investigating, but up to now I did not see something
wrong there.


> > 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.

That was my expectation as well as it took so long to find something.
But still, not impossible that something is wrong.

> 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?

One observation that I saw with supertuxkart.
They really have a VAO that ends up with two effective bindings used
by 3 and 2 vertex attributes. That is the old gallium array translation code
did produce 5 vertex_element struct entries and each of that has a
vertex_buffer struct assigned. The minimal pipe_vertex_buffer translation
only happened in the old code if it could be reduced to a single vertex buffer entry.
Now the code produces that 3 pipe_vertex_element referencing 1
pipe_vertex_buffer and 2 pipe_vertex_element referencing an other
pipe_vertex_buffer. Which should be more optimal now but is it possible
that virgl somewhere down the road only handles the n elements to one buffer
and the n element to n buffer case. So the question is is there a bug in the n elements
to 1 < m < n buffer case?
Do you know what I mean with the effective binding?

May be you can observe the same type of VAO in Serious Sam 3?

Well I have confidence that this triggers something. At least debugging into
the upper parts in mesa then into i965 showed nothing unexpected.

best

Mathias