Bug report in SolveSpace itself: https://github.com/solvespace/solvespace/issues/358 The issue is that after upgrading from 18.1.5 to 18.2.1 (also tried 18.3 git after that with the same result) on Ubuntu 18.10 I have an issue in SolveSpace that prevents view from being rendered until window is resized. It worked in 18.1.5 as packaged in Ubuntu 18.10 and works with `LIBGL_ALWAYS_SOFTWARE=1 solvespace` under 18.3 git. So this seems to indicate a regression in i965 somewhere between 18.1.5 and 18.2.1. I'm currently using iGPU on Core i7 8700k: nazar-pc@nazar-pc ~> glxinfo | grep OpenGL OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.0-devel OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 18.3.0-devel OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.3.0-devel OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions:
Maintainer of SolveSpace here. I've been seeing numerous mystifying issues with i965 graphics with SolveSpace, including rendering issues and massive video memory leaks (dozens of MB per frame), all of which are not present with LIBGL_ALWAYS_SOFTWARE=true; there are no GL errors and no GL object leaks as far as I can tell by calling glGetError() appropriately and analyzing traces with apitrace. I would be very happy if anyone gave me any pointers at all for resolving these issues.
Hello, Nazar and Peter. Could you, please make a trace of issue with utility apitrace and upload it here?
Sorry, no need in trace at this moment. Bisected: commit aefac10fecc9ec70feb5923ce3200902f67182ba Author: Michel Dänzer <michel.daenzer@amd.com> Date: Tue Sep 4 12:18:19 2018 +0200 loader/dri3: Only wait for back buffer fences in dri3_get_buffer We don't need to wait before drawing to the fake front buffer, as front buffer rendering by definition is allowed to produce artifacts. Fixes hangs in some cases when re-using the fake front buffer, due to it still being busy (i.e. in use for presentation). Cc: mesa-stable@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/106404 Bugzilla: https://bugs.freedesktop.org/107757 Tested-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Potential fix: https://patchwork.freedesktop.org/patch/254198/
Fix sent out for review: https://patchwork.freedesktop.org/patch/254393/
Sergii, is there an easy way to exercise this code path with a piglit test?
(In reply to Michel Dänzer from comment #5) > Fix sent out for review: https://patchwork.freedesktop.org/patch/254393/ Hi, I just tested this patch with mesa-18.1.9 on Gentoo Linux with i965 and SolveSpace now works correctly. Thanks
Hello, Mark. | Sergii, is there an easy way to exercise this code path with a piglit test? Yes, will try to look but after 'dying light'....
Thanks for the report, fixed in Git master: Commit: c20ba1be1843d035f36e9794bee7aea9abfc2f8b URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=c20ba1be1843d035f36e9794bee7aea9abfc2f8b Author: Michel Dänzer <michel.daenzer@amd.com> Date: Mon Oct 1 18:43:46 2018 +0200 loader/dri3: Also wait for front buffer fence if we triggered it
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.