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

Tue Dec 4 09:35:58 UTC 2018

On Tue, 2018-12-04 at 07:54 +0100, Mathias Fröhlich wrote:
> 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.
> 

One more breadcrumb:

Gert informed me (through other channels) that he had isolated this
issue to only trigger for indirect draws.

That might clear up a bit why this seems to happen in so few
applications; there's probably some combination of input layouts that
together with indirect draws become a very rare combination.

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

I'm not quite sure I follow here. What's n and m in this case (I seem
to see three definitions of n, where two are similar, and none of m)?

But looking through both virgl and virglrenderer, I can't spot anything
obviously wrong with the way inputs are being set up...

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

I don't have Serious Sam 3 running myself. Gert?

> 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
> 
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev