[Mesa-dev] [Bug 36282] 34a5d3b9f4740601708c82093e2114356d749e65: glxgears segfaults when compiled with shared glapi
https://bugs.freedesktop.org/show_bug.cgi?id=36282 --- Comment #26 from almos 2011-04-30 01:01:02 PDT --- Here's some update on this. I found another application that segfaults: neverball. I also found that setting LD_LIBRARY_PATH=/home/almos/sources/mesa/lib solves the problem (as I mentioned earlier, I used to set LIBGL_DRIVERS_PATH only), which might indicate that it's indeed caused by libGL.so mismatch, but I still don't understand why only these two segfault. BTW I also did a bisect, and I can confirm that revision 34a5d3b9f4740601708c82093e2114356d749e65 is the first bad commit. I'm not sure about that glapi thing, though. I compile Mesa with: ./autogen.sh --with-state-trackers=dri,glx,egl --enable-debug --with-dri-drivers= --prefix=/usr --enable-texture-float and I have no libglapi.so anywhere. What does that do anyways? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36609] 45920d2ecb38b14fdda5253fecce996570c22863 breaks sauerbraten on r300g
https://bugs.freedesktop.org/show_bug.cgi?id=36609 --- Comment #1 from almos 2011-04-30 04:55:50 PDT --- This also affects ut2004. Some examples: one triangle is missing from the health vials, on AS-Convoy the sky is missing a triangle and half of the floor of the boarding platform is missing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g on rv635 and broken mipmaps
I can confirm this breakage on rv670 too. It may be related to all chips < RV710 (just a guess). The bug report: https://bugs.freedesktop.org/show_bug.cgi?id=35312 I compile mesa with attached patch since then, but that flush should indeed be implicit, not explicit. 2011/4/30 Mathias Fröhlich : > > Hi, > > Since the lazy gpu flush changes for r600g about two weeks ago, I get broken > mipmaps on my notebooks rv635. > I am not sure if my analysis is right, but it appears to me that flushing the > destination caches like it is done in r600_context_flush_dest_caches is not > sufficient for my rv635. Since then, I need the attached patch to get correct > automatically generated mipmaps. > The important callpath for my observed breakage is when > r600_context_flush_dest_caches is called from r600_set_framebuffer_state, > which > is called on each new mipmap level. With the attached change it is sufficient > for flushing the previously rendered level that is used as a sampler source > for > rendering the next level. Without that flush, I get garbage in the smaller > mipmap levels. > > So, I know that this patch is not applicable, since it does not account for > sufficient cs space for this additional flush. Also it is probably too croase > in > face of the finegrained bo flush logic. > Also I cannot hear so much people screaming, so I guess the rv635 is about the > only chip that suffers from this problem. > But I failed to find that finegrained bo flush with the apropriate flush > flags that > makes mipmaps work again. > > May be this does ring some bell which flush is missing? > If not, does somebody have any clue which chips do suffer from this prolem? > > Greetings > > Mathias > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36282] 34a5d3b9f4740601708c82093e2114356d749e65: glxgears segfaults when compiled with shared glapi
https://bugs.freedesktop.org/show_bug.cgi?id=36282 Chistopher Krakowiak changed: What|Removed |Added CC||krzysztof.krakowiak@gmail.c ||om --- Comment #27 from Chistopher Krakowiak 2011-04-30 06:28:09 PDT --- *** Bug 36708 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g on rv635 and broken mipmaps
On Saturday 30 April 2011, Mathias Fröhlich wrote: > Hi, > > Since the lazy gpu flush changes for r600g about two weeks ago, I get broken > mipmaps on my notebooks rv635. > I am not sure if my analysis is right, but it appears to me that flushing the > destination caches like it is done in r600_context_flush_dest_caches is not > sufficient for my rv635. Since then, I need the attached patch to get correct > automatically generated mipmaps. > The important callpath for my observed breakage is when > r600_context_flush_dest_caches is called from r600_set_framebuffer_state, > which > is called on each new mipmap level. With the attached change it is sufficient > for flushing the previously rendered level that is used as a sampler source > for > rendering the next level. Without that flush, I get garbage in the smaller > mipmap levels. > > So, I know that this patch is not applicable, since it does not account for > sufficient cs space for this additional flush. Also it is probably too croase > in > face of the finegrained bo flush logic. Actually I think it should be fine, since this event type is about the destination and smx caches if I'm reading the documentation right. There's also a small margin in the dwords reserved for context_flush; it only uses 10 of the 16 dwords reserved for it. > Also I cannot hear so much people screaming, so I guess the rv635 is about > the > only chip that suffers from this problem. > But I failed to find that finegrained bo flush with the apropriate flush > flags that > makes mipmaps work again. > > May be this does ring some bell which flush is missing? > If not, does somebody have any clue which chips do suffer from this prolem? I think it's rv6xx that's a bit special. There is a also a bug report about random GPU lockups with those chipsets since the cache flush changes: https://bugs.freedesktop.org/show_bug.cgi?id=36525 I thought adding this event write might fix that, but apparently it didn't. My patch wrote the packet before flushing the buffers though. Have you or anyone else with an rv6xx seen anything like this? Regards, Fredrik ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g on rv635 and broken mipmaps
On Saturday 30 April 2011, Gustaw Smolarczyk wrote: > I can confirm this breakage on rv670 too. It may be related to all > chips < RV710 (just a guess). > The bug report: > https://bugs.freedesktop.org/show_bug.cgi?id=35312 > > I compile mesa with attached patch since then, but that flush should > indeed be implicit, not explicit. This bug report predates the cache flush changes though, but it's great if this patch fixes it properly. Regards, Fredrik ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 36282] 34a5d3b9f4740601708c82093e2114356d749e65: glxgears segfaults when compiled with shared glapi
https://bugs.freedesktop.org/show_bug.cgi?id=36282 --- Comment #28 from Alexandre Demers 2011-04-30 07:56:27 PDT --- (In reply to comment #26) > Here's some update on this. I found another application that segfaults: > neverball. I also found that setting > LD_LIBRARY_PATH=/home/almos/sources/mesa/lib solves the problem (as I > mentioned > earlier, I used to set LIBGL_DRIVERS_PATH only), which might indicate that > it's > indeed caused by libGL.so mismatch, but I still don't understand why only > these > two segfault. BTW I also did a bisect, and I can confirm that revision > 34a5d3b9f4740601708c82093e2114356d749e65 is the first bad commit. > > I'm not sure about that glapi thing, though. I compile Mesa with: > ./autogen.sh --with-state-trackers=dri,glx,egl --enable-debug > --with-dri-drivers= --prefix=/usr --enable-texture-float > and I have no libglapi.so anywhere. What does that do anyways? --enable-shared-glapi creates another library (libglapi.so). This library contains de shared code between OpenGL (let'S say desktop), OpenGL ES and maybe even OpenVG, instead of having duplicated code in each GL implementation. However, in my case, it doesn't have to do with a library left somewhere. As I tested and showed, everything is pointing to the right ones. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
