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

[Mathias Fröhlich]

Good Morning,

Again sorry, but since I only work here in the spare time, I did not find
enough to respond earlier.

On Tuesday, 4 December 2018 10:35:58 CET Erik Faye-Lund wrote:
> > 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.

That does not directly ring a bell for me, but At least that narrows down
the issue somehow.
Gert, do you know, indirect draws with the
struct Draw{Arrays,Elements}IndirectCommand
in user space memory or in a buffer object?

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

Ok, thanks for looking. I meant with M:N a layout something like

pipe_vertex_elements:
{ vertex_buffer_index = 0, src_offset = 0, ...},
{ vertex_buffer_index = 0, src_offset = 12, ...},
{ vertex_buffer_index = 1, src_offset = 0, ...},
{ vertex_buffer_index = 1, src_offset = 8, ...}

pipe_vertex_buffer:
{ buffer_offset = 0, buffer.resource = .... },
{ buffer_offset = 0, buffer.resource = .... }

Finally this is a 4:2 mapping.

The previous code did only produce either a N:1 mapping like

pipe_vertex_elements:
{ vertex_buffer_index = 0, src_offset = 0, ...},
{ vertex_buffer_index = 0, src_offset = 12, ...},
{ vertex_buffer_index = 0, src_offset = 24, ...},
{ vertex_buffer_index = 0, src_offset = 36, ...}

pipe_vertex_buffer:
{ buffer_offset = 0, buffer.resource = .... }

this one, if there was a single buffer object used that allows this kind of layout.
So there are *all* pipe_vertex_elements refering to a single pipe_vertex_buffer.

Or a N:N mapping like 

pipe_vertex_elements:
{ vertex_buffer_index = 0, src_offset = 0, ...},
{ vertex_buffer_index = 1, src_offset = 0, ...},
{ vertex_buffer_index = 2, src_offset = 0, ...},
{ vertex_buffer_index = 3, src_offset = 0, ...}

pipe_vertex_buffer:
{ buffer_offset = 0, buffer.resource = .... },
{ buffer_offset = 12, buffer.resource = .... },
{ buffer_offset = 36, buffer.resource = .... },
{ buffer_offset = 24, buffer.resource = .... }

where you have one pipe_vertex_buffer per pipe_vertex_element.

So, If the backing driver somehow 'knew' that we could only get N:1
or N:N and not something like the 4:2 example above, we could easily
fail with the change you found.

best

Mathias