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