[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98964

GitLab Migration User  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|NEW |RESOLVED

--- Comment #15 from GitLab Migration User  ---
-- 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98964

--- Comment #14 from Emil Velikov  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98964

--- Comment #13 from Zoltán Böszörményi  ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98964

--- Comment #12 from Zoltán Böszörményi  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98964

--- Comment #11 from Emil Velikov  ---
(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.


-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98964

--- Comment #10 from Zoltán Böszörményi  ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98964

--- Comment #9 from Zoltán Böszörményi  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98964

--- Comment #8 from Emil Velikov  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98964

--- Comment #7 from Emil Velikov  ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98964

--- Comment #6 from Zoltán Böszörményi  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98964

Matt Turner  changed:

   What|Removed |Added

  Component|Drivers/DRI/i965|Drivers/DRI/i915
 QA Contact|intel-3d-bugs at lists.freedes |dri-devel at 
lists.freedesktop
   |ktop.org|.org
   Assignee|intel-3d-bugs at lists.freedes |dri-devel at 
lists.freedesktop
   |ktop.org|.org

--- Comment #5 from Matt Turner  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98964

Zoltán Böszörményi  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|Drivers/DRI/i965
 QA Contact|dri-devel at lists.freedesktop |intel-3d-bugs at 
lists.freedes
   |.org|ktop.org
   Assignee|dri-devel at lists.freedesktop |intel-3d-bugs at 
lists.freedes
   |.org|ktop.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

[bugzilla-dae...@freedesktop.org]

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 at lists.freedesktop.org
  Reporter: zboszor at pr.hu
QA Contact: dri-devel at 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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: