Bug 98964

More info:

Kernel 4.8.11

# lspci
00:00.0 Host bridge: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx DMI Bridge (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)
00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 2 (rev 02)
00:1c.3 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 4 (rev 02)
00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] (rev 02)
00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 02)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)

This Intel GPU needs MESA_GL_VERSION_OVERRIDE=1.4
Otherwise Chromium becomes a snail for rendering as it tries to use OpenGL 2.1.

Atom [DN][45]xx sounds like Pineview (gen3) which is covered by the i915 or i915g driver. Which would also explain the 1.4 override.

First we need to figure out which driver you're using. What's the output of 
$ glxinfo | grep -i opengl

# DISPLAY=:0 glxinfo | grep -i opengl
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Pineview 
OpenGL version string: 1.4 Mesa 13.0.2
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 13.0.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:

Also there is no i915g driver, so it's i915.

# ls -l /usr/lib/dri/
total 16632
-rwxr-xr-x 1 root root 9853136 nov   29 05:31 gallium_dri.so
lrwxrwxrwx 1 root root      19 nov   29 07:53 i915_dri.so -> mesa_dri_drivers.so
lrwxrwxrwx 1 root root      19 nov   29 07:49 i965_dri.so -> mesa_dri_drivers.so
lrwxrwxrwx 1 root root      14 nov   29 07:52 kms_swrast_dri.so -> gallium_dri.so
-rwxr-xr-x 1 root root 7173168 nov   29 05:31 mesa_dri_drivers.so
lrwxrwxrwx 1 root root      14 nov   29 07:51 nouveau_dri.so -> gallium_dri.so
lrwxrwxrwx 1 root root      19 nov   29 07:53 nouveau_vieux_dri.so -> mesa_dri_drivers.so
lrwxrwxrwx 1 root root      19 nov   29 07:52 r200_dri.so -> mesa_dri_drivers.so
lrwxrwxrwx 1 root root      14 nov   29 07:53 r300_dri.so -> gallium_dri.so
lrwxrwxrwx 1 root root      14 nov   29 07:53 r600_dri.so -> gallium_dri.so
lrwxrwxrwx 1 root root      19 nov   29 07:52 radeon_dri.so -> mesa_dri_drivers.so
lrwxrwxrwx 1 root root      14 nov   29 07:52 radeonsi_dri.so -> gallium_dri.so
lrwxrwxrwx 1 root root      14 nov   29 07:54 swrast_dri.so -> gallium_dri.so
lrwxrwxrwx 1 root root      14 nov   29 07:49 vmwgfx_dri.so -> gallium_dri.so

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.

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.

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

(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.

(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.

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?

(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>

(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.

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

(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.

-- 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.