https://bugs.freedesktop.org/show_bug.cgi?id=98964
Bug ID: 98964 Summary: Chromium complains about glXGetSyncValuesOML in 13.0.2 Product: Mesa Version: 13.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: zboszor@pr.hu QA Contact: dri-devel@lists.freedesktop.org
Hi,
I am running Chromium 52.0.2743.76 on Yocto with Mesa 13.0.2 / libdrm 2.4.73.
It occasionally complains about this:
[1347:1347:1202/032132:ERROR:sync_control_vsync_provider.cc(64)] glXGetSyncValuesOML should not return TRUE with a media stream counter of 0.
Conformance bug?
https://bugs.freedesktop.org/show_bug.cgi?id=98964
Zoltán Böszörményi zboszor@pr.hu changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|Drivers/Gallium/radeonsi |Drivers/DRI/i965 QA Contact|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes |.org |ktop.org Assignee|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes |.org |ktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=98964
Matt Turner mattst88@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|Drivers/DRI/i965 |Drivers/DRI/i915 QA Contact|intel-3d-bugs@lists.freedes |dri-devel@lists.freedesktop |ktop.org |.org Assignee|intel-3d-bugs@lists.freedes |dri-devel@lists.freedesktop |ktop.org |.org
--- Comment #5 from Matt Turner mattst88@gmail.com --- i915 is basically unmaintained.
If this is a regression and you can bisect it to find the commit that caused it, someone might be able to fix it.
Otherwise Chromium becomes a snail for rendering as it tries to use OpenGL 2.1.
That is good feedback. I'll send a patch to revert the 2.1 support.
https://bugs.freedesktop.org/show_bug.cgi?id=98964
--- Comment #6 from Zoltán Böszörményi zboszor@pr.hu --- I don't know if it's a regression or if it's in Mesa at all.
When did Chromium started to use the vertical sync?
49 and 51 didn't print this, but it's true that we used 12.0.x or 11.1.x for them.
On other machines with Intel J1900 CPU (i965) or AMD Kabini (radeonsi) this message is not printed by Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=98964
--- Comment #7 from Emil Velikov emil.l.velikov@gmail.com --- Zoltán - the "g" in "i915g" implies the driver type rather than the actual filename.
Humble (off topic) request: please look into the the Yocto recipe to create hard links for the files as opposed to symlinks. The latter can cause issues in many scenarios. Thanks
https://bugs.freedesktop.org/show_bug.cgi?id=98964
--- Comment #8 from Emil Velikov emil.l.velikov@gmail.com --- (In reply to Zoltán Böszörményi from comment #6)
When did Chromium started to use the vertical sync?
Don't any of us know this one. As Matt mentioned your help in tracking the issue down will be appreciated.
https://bugs.freedesktop.org/show_bug.cgi?id=98964
--- Comment #9 from Zoltán Böszörményi zboszor@pr.hu --- (In reply to Emil Velikov from comment #7)
Zoltán - the "g" in "i915g" implies the driver type rather than the actual filename.
I know, "g" is for Gallium. The symlink points to the classic i915 driver.
Humble (off topic) request: please look into the the Yocto recipe to create hard links for the files as opposed to symlinks. The latter can cause issues in many scenarios. Thanks
Although the OS is Yocto, the Mesa recipe is mostly mine including the patch to revert this horrible idea of hard links. Hard links are good until you package the drivers into separate subpackages as it breaks the hard links and creates separate files instead. I saved more than 50MB on a 2GB disk which is substantial for an embedded system where we need the disk space but it is very constrained.
Haven't seen any ill effect on our systems because of it. We use only single GPU machines, so it shouldn't make a difference in behaviour. Perhaps with PRIME it would but we don't use it.
https://bugs.freedesktop.org/show_bug.cgi?id=98964
--- Comment #10 from Zoltán Böszörményi zboszor@pr.hu --- This 3 year old bug ticket (around Chromium 30-35) talks about this problem:
https://bugs.chromium.org/p/chromium/issues/detail?id=231945
Turned off CRTC?
Does the CRTC considered "turned off" if we switch to the console with Ctrl-Alt-F2?
https://bugs.freedesktop.org/show_bug.cgi?id=98964
--- Comment #11 from Emil Velikov emil.l.velikov@gmail.com --- (In reply to Zoltán Böszörményi from comment #9)
Although the OS is Yocto, the Mesa recipe is mostly mine including the patch to revert this horrible idea of hard links. Hard links are good until you package the drivers into separate subpackages as it breaks the hard links and creates separate files instead. I saved more than 50MB on a 2GB disk which is substantial for an embedded system where we need the disk space but it is very constrained.
Haven't seen any ill effect on our systems because of it. We use only single GPU machines, so it shouldn't make a difference in behaviour. Perhaps with PRIME it would but we don't use it.
I'm getting really off topic with this:
Above all: yes using hard links is nasty.
If you're having a single (or multiple fixed) GPU system then building multiple drivers is a _very_ bad idea. If you're doing that for embedded systems then it gets even worse. Thus having separate $driver subpackages makes no sense :-(
Using symlinks is brittle (not PRIME related). So you really don't want to ship something based on it. </offtopic>
https://bugs.freedesktop.org/show_bug.cgi?id=98964
--- Comment #12 from Zoltán Böszörményi zboszor@pr.hu --- (In reply to Emil Velikov from comment #11)
Above all: yes using hard links is nasty.
Thanks for confirming. :-)
If you're having a single (or multiple fixed) GPU system then building multiple drivers is a _very_ bad idea. If you're doing that for embedded systems then it gets even worse. Thus having separate $driver subpackages makes no sense :-(
I never said it is the same machine all across the board. All of them are single GPU ones, but historically we have systems with: AMD RS780 NVIDIA (ION1, ION2 and some third one, for our workload, Nouveau is enough) AMD Kabini AMD Kaveri Intel D525 Most recently Intel J1900
The same OS must run on all of them, so it does make sense to build different drivers into Mesa but it was also a necessity to save space where we can. Hence the symlink solution. Custom made OS based on Yocto.
Even if the hardlinks are used, bitbake in Yocto has a separate packaging stage after "make install" that copies files instead of moving them so even a single subpackage containing all drivers would end up with broken hardlinks, thus requiring multiples of what is needed solely for the gallium_dri.so and mesa_dri_drivers.so megadrivers. Maybe the megadrivers idea is the elephant in the room. I know it was created for a miniscule performance gain.
https://bugs.freedesktop.org/show_bug.cgi?id=98964
--- Comment #13 from Zoltán Böszörményi zboszor@pr.hu --- More details from testing several scenarios:
1. When there is only a single X screen then this line does not appear in the logs. It does not matter if we have the default mirrored screen configuration and there is an external VGA monitor attached or not, or if the X Intel driver is configured in a way to light up only one CRTC.
2. When we use a configuration to create :0.0 and :0.1 with the latter appearing on the external VGA and Chromium is started on both :0.0 and :0.1, this glXGetSyncValuesOML complaint is coming from only the one on :0.1
This particular Pineview machine has pipe1 wired to the internal panel and pipe0 is on the external VGA.
xf86-video-intel is from GIT commit bde946054efbc1c7ae1483b84c3b4fa3c2c7e2ec SNA is used.
Xorg server version 1.18.4
https://bugs.freedesktop.org/show_bug.cgi?id=98964
--- Comment #14 from Emil Velikov emil.l.velikov@gmail.com --- (In reply to Zoltán Böszörményi from comment #12)
(In reply to Emil Velikov from comment #11)
Above all: yes using hard links is nasty.
Thanks for confirming. :-)
If you're having a single (or multiple fixed) GPU system then building multiple drivers is a _very_ bad idea. If you're doing that for embedded systems then it gets even worse. Thus having separate $driver subpackages makes no sense :-(
I never said it is the same machine all across the board. All of them are single GPU ones, but historically we have systems with: AMD RS780 NVIDIA (ION1, ION2 and some third one, for our workload, Nouveau is enough) AMD Kabini AMD Kaveri Intel D525 Most recently Intel J1900
The same OS must run on all of them, so it does make sense to build different drivers into Mesa but it was also a necessity to save space where we can. Hence the symlink solution. Custom made OS based on Yocto.
If it's an embedded solution you'd want to optimise for the particular hardware. Namely - compiler optimisations, slimmed down kernel, small drivers, static linking, LTO etc.
Sounds like you're aiming at embedded while doing things like a normal distro (barring that those actually ship all the drivers in one package).
Even if the hardlinks are used, bitbake in Yocto has a separate packaging stage after "make install" that copies files instead of moving them so even a single subpackage containing all drivers would end up with broken hardlinks, thus requiring multiples of what is needed solely for the gallium_dri.so and mesa_dri_drivers.so megadrivers.
Sounds like Yocto is broken (like many distros were). Lookup on cp's --preserve= options.
I fear I dealt more than enough off-topic. If you're interested in more poke me privately or via the mesa-dev mailing list.
https://bugs.freedesktop.org/show_bug.cgi?id=98964
GitLab Migration User gitlab-migration@fdo.invalid changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |MOVED Status|NEW |RESOLVED
--- Comment #15 from GitLab Migration User gitlab-migration@fdo.invalid --- -- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/774.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org