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