Bug 107117

Hi, i managed to reproduce this bug using your solution. 
I have suggested simple solution for that:
https://patchwork.freedesktop.org/patch/237490/

Does this bug require a piglit test, to prevent similar regressions in the future?

(In reply to Mark Janes from comment #2)
> Does this bug require a piglit test, to prevent similar regressions in the
> future?

Yes, we should either improve the current TFP test to also test GL_RECTANGLE or turn the test provided here into a piglit test.  Oliver, would it be ok to include that code in piglit under a BSD license?

(In reply to Jason Ekstrand from comment #3)
> (In reply to Mark Janes from comment #2)
> > Does this bug require a piglit test, to prevent similar regressions in the
> > future?
> 
> Yes, we should either improve the current TFP test to also test GL_RECTANGLE
> or turn the test provided here into a piglit test.  Oliver, would it be ok
> to include that code in piglit under a BSD license?

Sure, no problem with me, but it would probably require a bit of cleanup, it's just a quick (and ugly) hack to demonstrate the issue.

However, I still see the issue even after applying https://patchwork.freedesktop.org/patch/237490/

Reading the patch, I think I understand better, this patch is to fix the assertion failure I met during the “git bisect” trying to identify the commit hat first caused the rendering issue, it's not about fixing the the actual problem with rendering

Created attachment 140540 [details]
Simple reproducer

Created attachment 140541 [details] [review]
Piglit patch to add GL_TEXTURE_RECTANGLE support to the tfp test

I modified the current piglit TFP test to also test texture rectangle and it works if you remove the assert in intel_mipmap_tree.c.  Clearly, this isn't just a GL_TEXTURE_RECTANGLE issue.

Created attachment 140557 [details]
results from piglit patch on Mesa 17.2.8 and Mesa 18.2.0-devel

(In reply to Jason Ekstrand from comment #7)
> Created attachment 140541 [details] [review] [review]
> Piglit patch to add GL_TEXTURE_RECTANGLE support to the tfp test
> 
> I modified the current piglit TFP test to also test texture rectangle and it
> works if you remove the assert in intel_mipmap_tree.c.  Clearly, this isn't
> just a GL_TEXTURE_RECTANGLE issue.

Hi I have tested your piglit patch and second version of "Simple reproducer" from Olivier Fourdan on:

   OpenGL vendor string: Intel Open Source Technology Center
   OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2) 
   OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.8

and 
 
   OpenGL vendor string: Intel Open Source Technology Center
   OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2) 
   OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.0-devel (git-04fff21c62)
   with my patch which just fixes unnecessary assert for GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE targets mismatch.


I could not reproduce the "rendering" issue on  Mesa 17.2.8 and on 18.2.0-devel versions. I received the identical correct result on both Mesas. So I think that the "rendering" issue was fixed somewhere between 18.1 and 18.2.0-devel however Mesa 18.2.0-devel still contains the "assertion" issue which should be fixed by my patch. 

Note: The first version of "Simple reproducer" from Olivier Fourdan was producing black screen on both Mesa 17.2.8 and on 18.2.0-devel for me so I fixed it and it stop to reproduce the "rendering" issue on both Mesas just "assertion" issue is reproduced.

Сould somebody also check if this "rendering" issue is still reproducable on Mesa 18.2.0-devel?

(In reply to Olivier Fourdan from comment #6)
> Created attachment 140540 [details]
> Simple reproducer

Hi Oliver. I checked attached by you file on manjaro (xfce exactly) - mesa release versions 18.0.4, 18.1.0 and 18.1.3
In all of them I saw red square.
could it be CPU specific issue? I have 2 SKL's (ubuntu and manjaro) and on both 18.1.0 mesa draws red square.

(In reply to Denis from comment #9)
> (In reply to Olivier Fourdan from comment #6)
> > Created attachment 140540 [details]
> > Simple reproducer
> 
> Hi Oliver. I checked attached by you file on manjaro (xfce exactly) - mesa
> release versions 18.0.4, 18.1.0 and 18.1.3
> In all of them I saw red square.

But TFP is used (optionally) only in xfce from git master, so unless you run the current (unreleased) version of xfce and force GL rendering, you won't see this bug.

> could it be CPU specific issue? I have 2 SKL's (ubuntu and manjaro) and on
> both 18.1.0 mesa draws red square.

Could be, I had also reports from other xfce users who were facing this bug.

(In reply to asimiklit from comment #8)
> [...]
> Сould somebody also check if this "rendering" issue is still reproducable on
> Mesa 18.2.0-devel?

FWIW, I could reproduce with master (from July 10), so either this is CPU/GPU related or it got fixed very recently. I shall retry as soon as I get back to my computer, and report back.

>But TFP is used (optionally) only in xfce from git master, so unless you run the current (unreleased) version of xfce and force GL rendering, you won't see this bug.

In my understanding, attached file should be more then enough for issue reproducing, yes?

>Could be, I had also reports from other xfce users who were facing this bug.
Could you please give information about your hardware? I ran the test on 3 different CPU's - SKL, KBL and SNB.

(In reply to Denis from comment #12)
> In my understanding, attached file should be more then enough for issue
> reproducing, yes?

Yes, absolutely.

> Could you please give information about your hardware? I ran the test on 3
> different CPU's - SKL, KBL and SNB.

Sure:

00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b) (prog-if 00 [VGA controller])
	Subsystem: Lenovo Device 220c
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 46
	Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
	Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at 3000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee00018  Data: 0000
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [a4] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: i915
	Kernel modules: i915

Humm, now I wonder, could this be related to the modesettings DDX and glamor somehow?

I tried with the intel DDX instead of the modesettings DDX and the test succeeds on the same hardware... What DDX are you using?

Olivier, could you please advice, how to verify the driver in use? I checked via Synaptic, searching "xf86-video" - and in results (marked as Installed) I didn't see modesetting.

simpler search also doesn't display anything related to modesetting:


den@den-Latitude-E5470:~$ locate xf86-video
/usr/lib/xserver-xorg-video-intel-hwe-16.04/xf86-video-intel-backlight-helper
/usr/share/apport/package-hooks/source_xf86-video-displaylink.py
/usr/share/apport/package-hooks/source_xf86-video-msm.py
/usr/share/apport/package-hooks/source_xf86-video-omapfb.py
/usr/share/polkit-1/actions/org.x.xf86-video-intel.backlight-helper.policy

(In reply to Denis from comment #15)
> Olivier, could you please advice, how to verify the driver in use?

The DDX can be seen in the Xorg logs, either in "~/.local/share/xorg/Xorg.*.log" or in "/var/log/Xorg.*.log" depending on your system.

There, you should see either "modeset" or "intel" depending on which DDX you've selected in your xorg.conf (or xorg.conf.d/).

e.g. for modesetting:

   (II) modesetting: Driver for Modesetting Kernel Drivers: kms
   (II) modeset(0): using drv /dev/dri/card0

for intel:

   (II) intel: Driver for Intel(R) Iris(TM) Graphics
   (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics
   (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20180308
   (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 4400

Point is, something has changed in Mesa 18.1 which causes attachment 140540 [details] to render a white window with the Xorg modesetting driver with glamor but not with the intel DDX, at least on my hardware (using Fedora 28 here with xserver-1.20)... Many distributions have switched to the modesetting driver by default with Intel hardware.

thanks for highlighting this. Checked my Xorg log and below the part related to modeseting:

According to it, I have modesetting driver, and still don't reproduce the issue. Possibly I will try to do same operation - exchange modesetting driver with intel and check test again.


[620297.866] (II) LoadModule: "modesetting"
[620297.867] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[620297.867] (II) Module modesetting: vendor="X.Org Foundation"
[620297.867] 	compiled for 1.19.5, module version = 1.19.5
[620297.867] 	Module class: X.Org Video Driver
[620297.867] 	ABI class: X.Org Video Driver, version 23.0
[620297.867] (II) LoadModule: "fbdev"
[620297.868] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[620297.868] (II) Module fbdev: vendor="X.Org Foundation"
[620297.868] 	compiled for 1.19.3, module version = 0.4.4
[620297.868] 	Module class: X.Org Video Driver
[620297.868] 	ABI class: X.Org Video Driver, version 23.0
[620297.868] (II) LoadModule: "vesa"
[620297.869] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[620297.869] (II) Module vesa: vendor="X.Org Foundation"
[620297.870] 	compiled for 1.19.3, module version = 2.3.4
[620297.870] 	Module class: X.Org Video Driver
[620297.870] 	ABI class: X.Org Video Driver, version 23.0
[620297.870] (II) modesetting: Driver for Modesetting Kernel Drivers: kms

hmm, in your first comment you marked this:
>Additional information:
> * Using texture type GL_TEXTURE_RECTANGLE_ARB

And what I found out in my case - that after running test I see this:
>Using texture type GL_TEXTURE_2D
That's possible reason why test is passing in my case. Investigating, why it takes this texture type.

(In reply to Denis from comment #17)
> [...]
> According to it, I have modesetting driver, and still don't reproduce the
> issue.

Yes, but you're using xserver-1.19.5, not 1.20.

This is where it gets even more interesting, I cannot reproduce with modesettings/glamor from xserver-1.19 either.

I understand this is getting confusing, considering the number of possibilities and packages/configuration involved. I don't want to confuse things even more...

Yet, this is what I've been able to come up with, so far:

                                | Mesa-18.0.x | Mesa-18.1.x | Mesa (git)  |
--------------------------------+-------------+-------------+-------------+
xserver-1.19 + modesettings DDX |      OK     |      OK     |      OK     |
--------------------------------+-------------+-------------+-------------+
xserver-1.19 + intel DDX        |      OK     |      OK     |      OK     |
--------------------------------+-------------+-------------+-------------+
xserver-1.20 + modesettings DDX |      OK     |     FAIL    |     FAIL    |
--------------------------------+-------------+-------------+-------------+
xserver-1.20 + intel DDX        |      OK     |      OK     |      OK     |
--------------------------------+-------------+-------------+-------------+

Olivier, could you please share info, how did you build xserver 1.20?
I used this manual http://www.linuxfromscratch.org/blfs/view/svn/x/xorg-server.html

and my machine stuck on welcome screen after building and installing. Had to reinstall Ubuntu after (rollback via chroot didn't help second time).

I still want to reproduce the same conditions on my local machine.

(In reply to Denis from comment #20)
> [...]
> 
> I still want to reproduce the same conditions on my local machine.

My advise would be to never replace the binaries from your distribution with ones you've compiled, but to install in a completely separate directory tree. 

If that helps, this issue was first reported (downstream in xfce) by Debian buster/sid users after the switch to Mesa 18.1.1

  https://bugzilla.xfce.org/show_bug.cgi?id=14475#c17
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901789

Some more info, this is related to the use of "glamor"...

xserver-1.20 + modesettings DDX + glamor : FAILS
xserver-1.20 + modesettings DDX + w/o glamor : OK

That explains why intel DDX works, it doesn't use glamor.

Same with Wayland, weston started with "--use-pixman" (which disables acceleration in Xwayland as well) works, whereas weston with Xwayland and glamor acceleration fails as well as Xorg with modesettings and glamor acceleration.

Now, I don't know if the issue is actually in glamor or in mesa...

So, as this is also reproducible with an example from khronos.org with Xwayland, I bisected the Xserver and was able to pinpoint the first bad commit in glamor.

I filed https://bugs.freedesktop.org/show_bug.cgi?id=107287 for glamor.

Quick follow up, investigating bug 107287 (affecting Xwayland which also uses glamor), it became apparent that the issue was more or less related to the introduction of multiple planes and format modifier support in both Mesa and the Xserver.

So I reran a new bisection (now avoiding the assert) and this time was able to find the first bad commit:

069fdd5f9facbd72fb6a289696c7b74e3237e70f is the first bad commit
commit 069fdd5f9facbd72fb6a289696c7b74e3237e70f
Author: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Date:   Fri Jul 7 02:54:26 2017 -0400

    egl/x11: Support DRI3 v1.1
    
    Add support for DRI3 v1.1, which allows pixmaps to be backed by
    multi-planar buffers, or those with format modifiers. This is both
    for allocating render buffers, as well as EGLImage imports from a
    native pixmap (EGL_NATIVE_PIXMAP_KHR).
    
    Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
    Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    Reviewed-by: Daniel Stone <daniels@collabora.com>

:040000 040000 24a88d838ccccdcd3aadb977d50c3fa59b9373bc 938aabed7e3e5a41fd0e3167a6afdceac69a37fd M	src


This explains why this requires both Mesa >= 18.1 and xserver >= 1.20 (as format modifiers support landed on both versions) and also why this affects only intel (as no other driver implement format modifiers yet, afaik).

Created attachment 140735 [details]
Simple reproducer

An even simpler reproducer based on https://www.khronos.org/opengl/wiki/Programming_OpenGL_in_Linux:_Using_texture_from_pixmap_extension

Only change there is the use of GLX_DOUBLEBUFFER to trigger the issue

Ok, some progress...

→ The rendering fails because dri3_alloc_render_buffer() fails.

→ dri3_alloc_render_buffer() fails because xcb_dri3_get_supported_modifiers_reply() returns NULL.

→ xcb_dri3_get_supported_modifiers_reply() return NULL because proc_dri3_get_supported_modifiers() fails.

→ proc_dri3_get_supported_modifiers() fails because dixLookupWindow() fails.

→ dixLookupWindow() fails because Mesa passed a pixmap and not a window (draw->drawable is a pixmap, not a window)

Created attachment 140813 [details] [review]
[PATCH] dri3: Do not get supported modifiers on pixmaps

This patch fixes the issue for me.

Also sent to mesa-devel, patch at https://patchwork.freedesktop.org/series/47217/

Created attachment 140817 [details] [review]
[PATCH v2] dri3: For 1.2, use root window instead of pixmap drawable

Created attachment 140818 [details] [review]
[PATCH v3] dri3: For 1.2, use root window instead of pixmap drawable

Patch works well for me. Looks like bug can be closed.