Bug 110214 - Raven Ridge (2400G): xterm scrollback buffer disappears while Shift+PgUp and Shift+PgDn
Summary: Raven Ridge (2400G): xterm scrollback buffer disappears while Shift+PgUp and ...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-21 01:34 UTC by Diego Viola
Modified: 2019-08-08 13:49 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Screencast demonstrating the problem (1.40 MB, video/x-matroska)
2019-03-21 21:03 UTC, Diego Viola
Details
Xorg.0.log (30.73 KB, text/plain)
2019-03-21 21:05 UTC, Diego Viola
Details
glxinfo (144.72 KB, text/plain)
2019-03-21 21:06 UTC, Diego Viola
Details
dmesg (67.91 KB, text/plain)
2019-03-21 21:07 UTC, Diego Viola
Details
glxinfo from Ubuntu 19.04 beta (108.15 KB, text/plain)
2019-04-01 08:46 UTC, Diego Viola
Details
glxinfo from Ubuntu 18.04.2 (145.03 KB, text/plain)
2019-04-01 08:51 UTC, Diego Viola
Details
glxinfo from Fedora 29 (58.39 KB, text/plain)
2019-04-01 09:08 UTC, Diego Viola
Details
git bisect log (2.37 KB, text/plain)
2019-04-01 10:53 UTC, Diego Viola
Details
glxinfo with LLVM 8.0.0 (144.72 KB, text/plain)
2019-04-01 11:06 UTC, Diego Viola
Details
Xephyr.trace (2.35 MB, application/octet-stream)
2019-04-01 12:51 UTC, Diego Viola
Details
clinfo -A output (16.11 KB, text/plain)
2019-04-12 22:24 UTC, Diego Viola
Details
xterm exhibiting the bug (43.97 KB, image/png)
2019-04-20 23:10 UTC, Diego Viola
Details
Bug in Geany (135.11 KB, image/jpeg)
2019-05-07 16:45 UTC, komqinxit
Details
Geany without a bug (141.68 KB, image/jpeg)
2019-05-07 16:47 UTC, komqinxit
Details
Yet another workaround (patch) for xterm (509 bytes, text/plain)
2019-07-14 09:14 UTC, Diego Viola
Details
comparison screenshot (50.42 KB, image/png)
2019-08-05 11:12 UTC, Pierre-Eric Pelloux-Prayer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Diego Viola 2019-03-21 01:34:02 UTC
Whenever I run `dmesg' on a xterm that uses the following options:

xterm -fa "DejaVu Sans Mono:style=Book:antialias=true" -fs 9

and I scroll up with the keyboard (shift+page up) parts of the scrollback buffer disappears, making it difficult to read the output.

I've tested other terminals (urxvt and alacritty) and I cannot trigger the bug with these terminals, with xterm it happens only with xft and with the options I mentioned above.

Steps to reproduce:

- run `xterm -fa "DejaVu Sans Mono:style=Book:antialias=true" -fs 9'
- run `dmesg', hit enter and page up

You should notice parts of the buffer disappearing.

I use the modesetting DDX driver, I also tried the xf86-video-amdgpu DDX driver and I can reproduce it with both, however, when setting Option "Accel" "off" in /etc/X11/xorg.conf.d/20-amdgpu.conf I cannot reproduce it anymore.

Actual Results:

As mentioned, the scrollback buffer disappears when paging up with these xterm options that I mentioned above.

Expected Results:

xterm works normally with these options, with no scrollback buffer issues.

System details:

- Arch Linux (x86_64)
- linux 5.0.2-arch1-1-ARCH
- xorg-server 1.20.4-1
- i3-wm 4.16.1-1
- xterm 344-1
- mesa 19.0.0-1

My machine is a "AMD Ryzen 5 2400G with Radeon Vega Graphics" APU with integrated vega graphics.

$ lspci | grep VGA
07:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev c6)
Comment 1 Michel Dänzer 2019-03-21 09:27:32 UTC
Please attach the corresponding Xorg log file and output of glxinfo and dmesg.

I can't seem to reproduce this, and I'm not sure what exactly "parts of the scrollback buffer disappear" means. Maybe you can make a screencast or screenshots demonstrating the problem?

Anyway, this is more likely an issue between glamor and Mesa than in the kernel driver. Reassigning to Mesa for now, as glamor issues are no longer tracked here.
Comment 2 Diego Viola 2019-03-21 21:03:19 UTC
Created attachment 143749 [details]
Screencast demonstrating the problem
Comment 3 Diego Viola 2019-03-21 21:05:04 UTC
Created attachment 143750 [details]
Xorg.0.log
Comment 4 Diego Viola 2019-03-21 21:06:25 UTC
Created attachment 143751 [details]
glxinfo
Comment 5 Diego Viola 2019-03-21 21:07:16 UTC
Created attachment 143752 [details]
dmesg
Comment 6 Diego Viola 2019-03-22 03:17:37 UTC
(In reply to Michel Dänzer from comment #1)
> Please attach the corresponding Xorg log file and output of glxinfo and
> dmesg.

Done.

> 
> I can't seem to reproduce this, and I'm not sure what exactly "parts of the
> scrollback buffer disappear" means. Maybe you can make a screencast or
> screenshots demonstrating the problem?

By that I mean the actual text/output disappears after I do shift+page up, but it doesn't if I scroll with the mouse wheel or if I use the scrollbar.

I've attached a video demonstrating the issue, please let me know if you need more info.

Thanks.
Comment 7 Diego Viola 2019-03-22 03:24:20 UTC
(In reply to Diego Viola from comment #6)
> (In reply to Michel Dänzer from comment #1)
> > Please attach the corresponding Xorg log file and output of glxinfo and
> > dmesg.
> 
> Done.
> 
> > 
> > I can't seem to reproduce this, and I'm not sure what exactly "parts of the
> > scrollback buffer disappear" means. Maybe you can make a screencast or
> > screenshots demonstrating the problem?
> 
> By that I mean the actual text/output disappears after I do shift+page up,
> but it doesn't if I scroll with the mouse wheel or if I use the scrollbar.

That was wrong, using the scrollbar also causes the same effect as using shift+page up (disappearing text).
Comment 8 Diego Viola 2019-03-26 05:04:02 UTC
I've compiled mesa from git and the issue is still there, I also tried older releases like 18.3, 18.2 and the issue remains.
Comment 9 Diego Viola 2019-03-26 05:04:49 UTC
I also get the same issue if I run xterm from sway/weston (via xwayland).
Comment 10 Diego Viola 2019-03-26 05:13:01 UTC
My issue looks quite similar to this one:

https://bugs.openbsd.narkive.com/N7A1v1Cw/colored-text-disappears-in-xterm
Comment 11 Diego Viola 2019-03-26 23:32:38 UTC
Tried mesa git (19.1.0-devel) with LLVM 9.0.0 (SVN) and the issue still persists.
Comment 12 Diego Viola 2019-03-27 00:59:06 UTC
I also tried recompiling xorg-server (git and 1.20.0) and the problem still persists with those, I can't compile older releases anymore due to compile time errors.
Comment 13 Diego Viola 2019-03-27 03:04:27 UTC
I can also reproduce the issue with Xephyr -glamor.
Comment 14 Diego Viola 2019-03-27 10:19:04 UTC
I can't reproduce the issue if I startx with LIBGL_ALWAYS_SOFTWARE=1.
Comment 15 Michel Dänzer 2019-03-27 10:54:48 UTC
(In reply to Diego Viola from comment #14)
> I can't reproduce the issue if I startx with LIBGL_ALWAYS_SOFTWARE=1.

How exactly did you set that? Normally, I'd expect it to only affect clients, not the X server.

Are you using a compositing manager?
Comment 16 Diego Viola 2019-03-27 10:59:46 UTC
(In reply to Michel Dänzer from comment #15)
> (In reply to Diego Viola from comment #14)
> > I can't reproduce the issue if I startx with LIBGL_ALWAYS_SOFTWARE=1.
> 
> How exactly did you set that? Normally, I'd expect it to only affect
> clients, not the X server.
> 
> Are you using a compositing manager?

In my TT1:

export LIBGL_ALWAYS_SOFTWARE=1

then startx after that.

When I'm on X, I open an xterm and LIBGL_ALWAYS_SOFTWARE=1 will be set, glxinfo also reports llvmpipe.

I'm using i3-wm, no I don't use a compositing manager.
Comment 17 Diego Viola 2019-03-27 11:00:14 UTC
TTY1, sorry.
Comment 18 Diego Viola 2019-03-27 13:30:30 UTC
I tried running xcompmgr just to see if it makes a difference and it doesn't, I can still reproduce the bug when xcompmgr is running.
Comment 19 Michel Dänzer 2019-03-29 15:30:27 UTC
(In reply to Diego Viola from comment #12)
> I also tried recompiling xorg-server (git and 1.20.0) and the problem still
> persists with those, [...]

Did you build xserver with meson or autotools?
Comment 20 Diego Viola 2019-03-29 20:16:07 UTC
(In reply to Michel Dänzer from comment #19)
> (In reply to Diego Viola from comment #12)
> > I also tried recompiling xorg-server (git and 1.20.0) and the problem still
> > persists with those, [...]
> 
> Did you build xserver with meson or autotools?

autotools
Comment 21 Diego Viola 2019-03-29 20:42:39 UTC
BTW, I'm not sure if it's related, but I also started seeing some artifacts with GTK windows (GIMP and LibreOffice), items such as "Help" (in GtkMenuItem) will disappear, then they re-appear until I click in one of them.

The same is also true for the text in the menus itself.
Comment 22 Diego Viola 2019-03-29 21:02:18 UTC
s/until/when/
Comment 23 Diego Viola 2019-03-29 22:44:35 UTC
When starting X with LIBGL_ALWAYS_SOFTWARE=1 the rendering issues with GIMP also goes away.
Comment 24 Diego Viola 2019-03-30 05:03:08 UTC
I've bisected the issue with the GTK elements sometimes disappearing, and the commit that causes the issue is this one:

1b25d340b791ad8350bdfb27f1a91ac79fa17748 is the first bad commit

Sadly my xterm is still affected but I can confirm this commit causes the issue with the GTK windows, going back to the previous commit fixes the issue with the invisible element in GIMP.

Does it shed any light for my original issue (invisible output in xterm)?

Sorry for mixing things up.
Comment 25 Michel Dänzer 2019-03-30 10:53:07 UTC
Just to make sure, you always restart the X server between building a Mesa commit and testing xterm against it, right? And you're making sure that the X server picks up your self-built radeonsi_dri.so for glamor?

If so, since that commit doesn't seem to affect the xterm issue, let's assume for now that it's separate. Please file a new report about the GTK issue, also against radeonsi, with the information from git bisect.
Comment 26 Diego Viola 2019-03-30 12:07:47 UTC
(In reply to Michel Dänzer from comment #25)
> Just to make sure, you always restart the X server between building a Mesa
> commit and testing xterm against it, right? And you're making sure that the
> X server picks up your self-built radeonsi_dri.so for glamor?

Yes.

> 
> If so, since that commit doesn't seem to affect the xterm issue, let's
> assume for now that it's separate. Please file a new report about the GTK
> issue, also against radeonsi, with the information from git bisect.

OK.
Comment 27 Diego Viola 2019-03-30 12:32:15 UTC
Actually, about your question:

> And you're making sure that the X server picks up your self-built radeonsi_dri.so for glamor?

I'm compiling Mesa in my home directory with the following configure switches:

./autogen.sh --enable-gles1 --enable-gles2 --enable-glx-tls --with-egl-platforms=x11,drm,wayland --with-dri-drivers=radeon --with-gallium-drivers=radeonsi --enable-debug --enable-autotools
make -j8

export LD_LIBRARY_PATH=/home/diego/mesa/lib
export LIBGL_DRIVERS_PATH=/home/diego/mesa/lib/gallium

So I assume this should make the X server pick the radeonsi_dri.so from /home/diego/mesa/lib/gallium right?

I looked at the ~/.local/share/xorg/Xorg.0.log but it's not so clear:

[   437.304] (II) modeset(0): [DRI2]   DRI driver: radeonsi
[   437.307] (II) AIGLX: Loaded and initialized radeonsi

Is there a way to verify beyond this which radeonsi driver it's using?
Comment 28 Diego Viola 2019-03-30 15:25:41 UTC
I guess I'll need to install mesa system wide to be really sure, I'll do that and confirm.
Comment 29 Diego Viola 2019-03-30 18:22:23 UTC
OK, I was able to install Mesa system wide, glxinfo tells me this:

Mesa 19.0.0-devel (git-8daf5bb209)

Which is the commit prior to the bad commit I mentioned above.

Sadly xterm is still breaking as usual, the output disappears as I Shift+Page Up and nothing changed in that regard. :(
Comment 30 Diego Viola 2019-03-31 22:49:52 UTC
I can reproduce this on Fedora 29 (workstation), I don't think the problem is Arch Linux specific.

- XTerm(334)
- Linux 5.0.4-200.fc29.x86_64
- GNOME Version 3.30.2
- xorg-x11-server-Xorg-1.20.4-1.fc29.x86_64
Comment 31 Diego Viola 2019-03-31 22:59:27 UTC
I can't reproduce it on Ubuntu 18.04.2 or 19.04 beta.
Comment 32 Michel Dänzer 2019-04-01 08:12:36 UTC
(In reply to Diego Viola from comment #27)
> export LD_LIBRARY_PATH=/home/diego/mesa/lib
> export LIBGL_DRIVERS_PATH=/home/diego/mesa/lib/gallium
> 
> So I assume this should make the X server pick the radeonsi_dri.so from
> /home/diego/mesa/lib/gallium right?

Doubtful, environment variables from the user shell aren't propagated to the Xorg process for me (which makes it very mysterious how LIBGL_ALWAYS_SOFTWARE=1 could make any difference...).

> Is there a way to verify beyond this which radeonsi driver it's using?

sudo lsof | grep radeonsi_dri.so


(In reply to Diego Viola from comment #29)
> Mesa 19.0.0-devel (git-8daf5bb209)
> 
> Which is the commit prior to the bad commit I mentioned above.
> 
> Sadly xterm is still breaking as usual, the output disappears as I
> Shift+Page Up and nothing changed in that regard. :(

What if you install Mesa 18.3 system-wide?


(In reply to Diego Viola from comment #30)
> I can reproduce this on Fedora 29 (workstation), [...]
(In reply to Diego Viola from comment #31)
> I can't reproduce it on Ubuntu 18.04.2 or 19.04 beta.

Please attach the outputs of glxinfo from Fedora and Ubuntu.
Comment 33 Diego Viola 2019-04-01 08:46:24 UTC
Created attachment 143829 [details]
glxinfo from Ubuntu 19.04 beta
Comment 34 Diego Viola 2019-04-01 08:51:48 UTC
Created attachment 143830 [details]
glxinfo from Ubuntu 18.04.2
Comment 35 Diego Viola 2019-04-01 09:08:32 UTC
Created attachment 143831 [details]
glxinfo from Fedora 29
Comment 36 Diego Viola 2019-04-01 09:12:41 UTC
(In reply to Michel Dänzer from comment #32)
> (In reply to Diego Viola from comment #27)
> > export LD_LIBRARY_PATH=/home/diego/mesa/lib
> > export LIBGL_DRIVERS_PATH=/home/diego/mesa/lib/gallium
> > 
> > So I assume this should make the X server pick the radeonsi_dri.so from
> > /home/diego/mesa/lib/gallium right?
> 
> Doubtful, environment variables from the user shell aren't propagated to the
> Xorg process for me (which makes it very mysterious how
> LIBGL_ALWAYS_SOFTWARE=1 could make any difference...).
> 
> > Is there a way to verify beyond this which radeonsi driver it's using?
> 
> sudo lsof | grep radeonsi_dri.so

Thanks.

> 
> 
> (In reply to Diego Viola from comment #29)
> > Mesa 19.0.0-devel (git-8daf5bb209)
> > 
> > Which is the commit prior to the bad commit I mentioned above.
> > 
> > Sadly xterm is still breaking as usual, the output disappears as I
> > Shift+Page Up and nothing changed in that regard. :(
> 
> What if you install Mesa 18.3 system-wide?

I'll try that.

> 
> 
> (In reply to Diego Viola from comment #30)
> > I can reproduce this on Fedora 29 (workstation), [...]
> (In reply to Diego Viola from comment #31)
> > I can't reproduce it on Ubuntu 18.04.2 or 19.04 beta.
> 
> Please attach the outputs of glxinfo from Fedora and Ubuntu.

Done.
Comment 37 Michel Dänzer 2019-04-01 09:25:13 UTC
Hmm, Mesa was built against LLVM 7 in Arch & Fedora, against LLVM 8/9 in Ubuntu. Maybe this was an LLVM issue fixed in version 8?
Comment 38 Diego Viola 2019-04-01 09:41:28 UTC
(In reply to Michel Dänzer from comment #37)
> Hmm, Mesa was built against LLVM 7 in Arch & Fedora, against LLVM 8/9 in
> Ubuntu. Maybe this was an LLVM issue fixed in version 8?

Unfortunately that's not the issue, llvm-libs 8.0.0 just landed on Arch Linux [extra] repository and the issue still persists.
Comment 39 Michel Dänzer 2019-04-01 09:44:18 UTC
(In reply to Diego Viola from comment #38)
> Unfortunately that's not the issue, llvm-libs 8.0.0 just landed on Arch
> Linux [extra] repository and the issue still persists.

Has Mesa been rebuilt against the new LLVM? Check the glxinfo output.
Comment 40 Diego Viola 2019-04-01 10:11:22 UTC
Something really funny is going on.

I've compiled Mesa 18.3.0 and installed it system-wide and that works (xterm scrollback is fine with this).

I've compiled the latest Mesa git HEAD and installed that system-wide, this fails.

Bisect time.
Comment 41 Diego Viola 2019-04-01 10:53:13 UTC
$ git bisect good
6328536ff28ca26f2ad4e6f2c956c467acebda88 is the first bad commit
commit 6328536ff28ca26f2ad4e6f2c956c467acebda88
Author: Eric Anholt <eric@anholt.net>
Date:   Fri Nov 2 14:35:06 2018 -0700

    gbm: Introduce a helper function for printing GBM format names.
    
    This requires that the caller make a little (stack) allocation to store
    the string.
    
    v2: Use gbm_format_canonicalize (suggested by Daniel)
    
    Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
    Reviewed-by: Daniel Stone <daniels@collabora.com>

:040000 040000 033db8e2d54ead2f34691e6b8e234a06428381fd 50d5e1cbd57b488d0e24fd86787c611bf58bd588 M	src
Comment 42 Diego Viola 2019-04-01 10:53:47 UTC
Created attachment 143832 [details]
git bisect log
Comment 43 Daniel Stone 2019-04-01 10:54:42 UTC
(In reply to Diego Viola from comment #41)
> $ git bisect good
> 6328536ff28ca26f2ad4e6f2c956c467acebda88 is the first bad commit
> commit 6328536ff28ca26f2ad4e6f2c956c467acebda88
> Author: Eric Anholt <eric@anholt.net>
> Date:   Fri Nov 2 14:35:06 2018 -0700
> 
>     gbm: Introduce a helper function for printing GBM format names.
>     
>     This requires that the caller make a little (stack) allocation to store
>     the string.
>     
>     v2: Use gbm_format_canonicalize (suggested by Daniel)
>     
>     Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
>     Reviewed-by: Daniel Stone <daniels@collabora.com>
> 
> :040000 040000 033db8e2d54ead2f34691e6b8e234a06428381fd
> 50d5e1cbd57b488d0e24fd86787c611bf58bd588 M	src

I'm afraid this is a red herring: as you can see from looking at the commit, it simply adds new API with no actual user.
Comment 44 Diego Viola 2019-04-01 11:01:55 UTC
(In reply to Daniel Stone from comment #43)
> (In reply to Diego Viola from comment #41)
> > $ git bisect good
> > 6328536ff28ca26f2ad4e6f2c956c467acebda88 is the first bad commit
> > commit 6328536ff28ca26f2ad4e6f2c956c467acebda88
> > Author: Eric Anholt <eric@anholt.net>
> > Date:   Fri Nov 2 14:35:06 2018 -0700
> > 
> >     gbm: Introduce a helper function for printing GBM format names.
> >     
> >     This requires that the caller make a little (stack) allocation to store
> >     the string.
> >     
> >     v2: Use gbm_format_canonicalize (suggested by Daniel)
> >     
> >     Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
> >     Reviewed-by: Daniel Stone <daniels@collabora.com>
> > 
> > :040000 040000 033db8e2d54ead2f34691e6b8e234a06428381fd
> > 50d5e1cbd57b488d0e24fd86787c611bf58bd588 M	src
> 
> I'm afraid this is a red herring: as you can see from looking at the commit,
> it simply adds new API with no actual user.

Are you sure? I've compiled the previous commit and that makes it work.

commit ee7f848c000112a98e9614f42921b176be473792 (HEAD)

Should I restart the git bisect?
Comment 45 Diego Viola 2019-04-01 11:06:33 UTC
Created attachment 143833 [details]
glxinfo with LLVM 8.0.0

(In reply to Michel Dänzer from comment #39)
> (In reply to Diego Viola from comment #38)
> > Unfortunately that's not the issue, llvm-libs 8.0.0 just landed on Arch
> > Linux [extra] repository and the issue still persists.
> 
> Has Mesa been rebuilt against the new LLVM? Check the glxinfo output.

Here's the current glxinfo output with the stock mesa on Arch.
Comment 46 Diego Viola 2019-04-01 12:01:45 UTC
For some reason glxinfo reports mesa 19.0.0 (stock package on Arch) after I've installed mesa system-wide (18.3.0).

I didn't use a PKGBUILD and installed mesa by doing a `sudo make install'.

Maybe that's why the bisect went bad?

I know using a PKGBUILD is the right way to do it, but the last time I tried to use it I got some conflicts with libglvnd when I tried to replace the Arch Linux mesa package with the custom one.
Comment 47 Diego Viola 2019-04-01 12:24:45 UTC
OK, this one is also weird, I've compiled mesa-18.3.0 in my home directory, exported these two variables:

export LD_LIBRARY_PATH=/home/diego/mesa/lib
export LIBGL_DRIVERS_PATH=/home/diego/mesa/lib/gallium

I startx after that, glxinfo reports the right mesa version (18.3.0) and lsof says this:

$ sudo lsof | grep radeonsi_dri.so
[sudo] password for diego: 
Xorg      8082                  diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so
Xorg      8082 8083 Xorg:cs0    diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so
Xorg      8082 8084 Xorg:disk   diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so
Xorg      8082 8085 Xorg:sh0    diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so
Xorg      8082 8086 Xorg:sh1    diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so
Xorg      8082 8087 Xorg:sh2    diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so
Xorg      8082 8088 Xorg:sh3    diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so
Xorg      8082 8089 Xorg:sh4    diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so
Xorg      8082 8090 Xorg:sh5    diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so
Xorg      8082 8091 Xorg:shlo   diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so
Xorg      8082 8092 Xorg:shlo   diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so
Xorg      8082 8093 Xorg:shlo   diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so
Xorg      8082 8094 Xorg:shlo   diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so
Xorg      8082 8095 Xorg:gdrv   diego  mem       REG               0,22 84191168     322546 /home/diego/mesa/lib/gallium/radeonsi_dri.so

But then I cannot reproduce the bug anymore.

Any ideas?
Comment 48 Diego Viola 2019-04-01 12:51:15 UTC
Created attachment 143834 [details]
Xephyr.trace

Here is an apitrace to reproduce the bug, I used this:

export MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage"
apitrace trace /usr/bin/Xephyr -glamor :1 -screen 1024x768

As described here: https://github.com/apitrace/apitrace/wiki/Glamor

I can replay it with either of those commands:

eglretrace -w Xephyr.trace

or

glretrace -w Xephyr.trace

This was iive's suggestion (thanks).
Comment 49 Diego Viola 2019-04-01 12:59:05 UTC
apitrace replay -w Xephyr.trace also seems to work.
Comment 50 Diego Viola 2019-04-01 13:39:35 UTC
I can reproduce the issue with apitrace on Ubuntu 19.04.
Comment 51 Michel Dänzer 2019-04-01 14:33:30 UTC
(In reply to Diego Viola from comment #46)
> Maybe that's why the bisect went bad?

That's likely one reason at least. At this point it's probably best if you double-check everything before testing anything. :)

(In reply to Diego Viola from comment #47)
> But then I cannot reproduce the bug anymore.

The working hypothesis is that it's a Mesa regression between 18.3 and 19.0, so that makes sense?
Comment 52 Diego Viola 2019-04-01 16:05:25 UTC
(In reply to Michel Dänzer from comment #51)
> (In reply to Diego Viola from comment #46)
> > Maybe that's why the bisect went bad?
> 
> That's likely one reason at least. At this point it's probably best if you
> double-check everything before testing anything. :)

Sure, sorry about any possible false-positives that I might have provided by accident.

> 
> (In reply to Diego Viola from comment #47)
> > But then I cannot reproduce the bug anymore.
> 
> The working hypothesis is that it's a Mesa regression between 18.3 and 19.0,
> so that makes sense?

Yes, is there any more info that I can provide that you think would be useful?

Thanks.
Comment 53 Michel Dänzer 2019-04-01 16:09:59 UTC
It's probably worth trying git bisect again, double-checking at each step that you're testing the right thing.
Comment 54 Diego Viola 2019-04-01 16:31:25 UTC
(In reply to Michel Dänzer from comment #53)
> It's probably worth trying git bisect again, double-checking at each step
> that you're testing the right thing.

Sure, I think my attempt from #c47 should have allowed me to reproduce the problem, I wonder why that failed.

I will try again.
Comment 55 Diego Viola 2019-04-02 00:23:55 UTC
(In reply to Michel Dänzer from comment #53)
> It's probably worth trying git bisect again, double-checking at each step
> that you're testing the right thing.

I tried again and I can't get to replace the system mesa with my own build because of some conflicts with libglvnd, and when I compile mesa in my home directory and export LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH to my mesa build, glxinfo reports the right version of mesa and links to the libGL from my build, but lsof shows the libGL from libglvnd is being used.
Comment 56 Diego Viola 2019-04-02 00:38:58 UTC
Here's more or less what I'm currently seeing:

$ ldd /usr/bin/glxinfo | grep libGL
	libGL.so.1 => /home/diego/mesa/lib/libGL.so.1 (0x00007fbaac886000)
$ ls -l /home/diego/mesa/lib/libGL.so.1
lrwxrwxrwx 2 diego diego 14 Apr  2 00:03 /home/diego/mesa/lib/libGL.so.1 -> libGL.so.1.2.0
$ sudo lsof | grep libGL.so
[sudo] password for diego: 
Xorg       4873                  diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       4873 4874 Xorg:cs0    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       4873 4875 Xorg:disk   diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       4873 4876 Xorg:sh0    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       4873 4877 Xorg:sh1    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       4873 4878 Xorg:sh2    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       4873 4879 Xorg:sh3    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       4873 4880 Xorg:sh4    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       4873 4881 Xorg:sh5    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       4873 4882 Xorg:shlo   diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       4873 4883 Xorg:shlo   diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       4873 4884 Xorg:shlo   diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       4873 4885 Xorg:shlo   diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       4873 4886 Xorg:gdrv   diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520                  diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520 5521 Xorg:cs0    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520 5522 Xorg:disk   diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520 5523 Xorg:sh0    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520 5524 Xorg:sh1    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520 5525 Xorg:sh2    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520 5526 Xorg:sh3    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520 5527 Xorg:sh4    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520 5528 Xorg:sh5    diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520 5529 Xorg:shlo   diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520 5530 Xorg:shlo   diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520 5531 Xorg:shlo   diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520 5532 Xorg:shlo   diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
Xorg       5520 5533 Xorg:gdrv   diego  mem       REG               0,22   591624     438107 /usr/lib/libGL.so.1.7.0
$ pacman -Qo /usr/lib/libGL.so.1.7.0 
/usr/lib/libGL.so.1.7.0 is owned by libglvnd 1.1.1-1

This is after I startx with LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH pointing to my mesa build.
Comment 57 Diego Viola 2019-04-02 01:35:32 UTC
I contacted Thomas Dickey (maintainer of xterm) and he said this about the issue:

drivers, or Xorg in general -

for instance the parts painting by XCopyArea
(used by xterm and some other applications)
may not be getting repainting-events

https://lists.cairographics.org/archives/cairo/2015-May/026284.html

or buggy acceleration features

https://invisible-island.net/xterm/xterm.faq.html#compiz_bugs
Comment 58 Diego Viola 2019-04-02 04:00:09 UTC
I restarted the bisect and ended up at the same "bad commit":

6328536ff28ca26f2ad4e6f2c956c467acebda88 is the first bad commit

I wonder what I'm doing wrong...
Comment 59 Diego Viola 2019-04-02 04:33:00 UTC
If I do this:

$ git revert -n 6328536ff28ca26f2ad4e6f2c956c467acebda88
$ git revert -n 621b0fa8922ade0a8122b868177308e65e6d3595

Then xterm works fine and I still have direct rendering.
Comment 60 Diego Viola 2019-04-02 06:14:42 UTC
Used clang to compile the latest mesa git master and it made no difference.
Comment 61 Diego Viola 2019-04-03 08:19:04 UTC
I just want to retract myself from saying these commits caused the problem for me, sorry about that.

As suggested by MrCooper, I've compiled/installed mesa to /usr/local and added /usr/local/lib to /etc/ld.so.conf.d/mesa.conf to override the system mesa.

We found that xterm still has the issue with Mesa 18.3.0.
Comment 62 Diego Viola 2019-04-04 17:26:49 UTC
We found quite a few things during our research:

export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier"

This helps alleviate the problem (xterm does not have the issue with this), however, the problem is still present in Xephyr.

We tested Xephyr from the current git master down to Xephyr from xserver 1.16 and the problem is also present, however, setting the following environment variable:

export R600_DEBUG=nodpbb

Makes the issue disappear entirely.
Comment 63 Michel Dänzer 2019-04-05 08:49:02 UTC
(In reply to Diego Viola from comment #62)
> export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier"
> 
> This helps alleviate the problem (xterm does not have the issue with this),
> however, the problem is still present in Xephyr.

To clarify, you mean Xephyr from xserver 1.16 here (where glamor didn't make use of GL_NV_texture_barrier yet), disabling GL_NV_texture_barrier helps with current Xephyr, right?

It seems like DPBB needs to be disabled when glTextureBarrier(NV) is called, otherwise primitives may be reordered across the barrier. Does that make sense, Marek?
Comment 64 Diego Viola 2019-04-05 12:18:03 UTC
(In reply to Michel Dänzer from comment #63)
> (In reply to Diego Viola from comment #62)
> > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier"
> > 
> > This helps alleviate the problem (xterm does not have the issue with this),
> > however, the problem is still present in Xephyr.
> 
> To clarify, you mean Xephyr from xserver 1.16 here (where glamor didn't make
> use of GL_NV_texture_barrier yet), disabling GL_NV_texture_barrier helps
> with current Xephyr, right?

Yes, that's correct.

If I set `export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier"
` before running `startx`, xterm works fine either in X or Xephyr (from git master).

> 
> It seems like DPBB needs to be disabled when glTextureBarrier(NV) is called,
> otherwise primitives may be reordered across the barrier. Does that make
> sense, Marek?
Comment 65 Diego Viola 2019-04-05 12:36:58 UTC
Just to make it a bit more clear:

If I set that environment variable while I'm already on X:

export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier"

It has no effect on Xephyr (from current git master), i.e. xterm still shows the bug.

However, if I set before `startx`.

It works with both, X and Xephyr (from git master), i.e. xterm works fine.
Comment 66 Diego Viola 2019-04-05 12:43:33 UTC
(In reply to Diego Viola from comment #65)
> Just to make it a bit more clear:
> 
> If I set that environment variable while I'm already on X:
> 
> export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier"
> 
> It has no effect on Xephyr (from current git master), i.e. xterm still shows
> the bug.

xterm still shows the bug in Xephyr from git if that environment was set later (while X was running).

Works fine with both (Xephyr git and X) if the environment variable was set before startx.

Please let me know if you have more questions.
Comment 67 Marek Olšák 2019-04-05 14:22:49 UTC
(In reply to Michel Dänzer from comment #63)
> (In reply to Diego Viola from comment #62)
> > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier"
> > 
> > This helps alleviate the problem (xterm does not have the issue with this),
> > however, the problem is still present in Xephyr.
> 
> To clarify, you mean Xephyr from xserver 1.16 here (where glamor didn't make
> use of GL_NV_texture_barrier yet), disabling GL_NV_texture_barrier helps
> with current Xephyr, right?
> 
> It seems like DPBB needs to be disabled when glTextureBarrier(NV) is called,
> otherwise primitives may be reordered across the barrier. Does that make
> sense, Marek?

Primitives aren't reordered with DPBB. Primitives can't also survive a barrier with DPBB. DPBB has no effect on behavior, it just changes how PS wavefronts are formed.
Comment 68 Michel Dänzer 2019-04-05 14:59:09 UTC
(In reply to Diego Viola from comment #65)
> If I set that environment variable while I'm already on X:

By "X" I assume you mean Xorg here?

> export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier"
> 
> It has no effect on Xephyr (from current git master), i.e. xterm still shows
> the bug.

Did you set the variable before starting Xephyr though, so it was set in the Xephyr process? If yes, that makes things confusing again, just when it seemed like they were starting to make sense...
Comment 69 Michel Dänzer 2019-04-05 15:01:20 UTC
(In reply to Marek Olšák from comment #67)
> Primitives aren't reordered with DPBB. Primitives can't also survive a
> barrier with DPBB. DPBB has no effect on behavior, it just changes how PS
> wavefronts are formed.

Is there any way that could affect the glamor shader which samples from one area of a buffer and draws to another (non-overlapping) area of the same buffer?

What is the reason for radeonsi disabling DPBB for blits?
Comment 70 Diego Viola 2019-04-05 15:22:47 UTC
(In reply to Michel Dänzer from comment #68)
> (In reply to Diego Viola from comment #65)
> > If I set that environment variable while I'm already on X:
> 
> By "X" I assume you mean Xorg here?

Yes, Xorg.
Comment 71 Marek Olšák 2019-04-05 15:23:33 UTC
(In reply to Michel Dänzer from comment #69)
> (In reply to Marek Olšák from comment #67)
> > Primitives aren't reordered with DPBB. Primitives can't also survive a
> > barrier with DPBB. DPBB has no effect on behavior, it just changes how PS
> > wavefronts are formed.
> 
> Is there any way that could affect the glamor shader which samples from one
> area of a buffer and draws to another (non-overlapping) area of the same
> buffer?

As long as the blits are truly non-overlapping, DPBB doesn't affect it.

> 
> What is the reason for radeonsi disabling DPBB for blits?

because it's not useful for blits and it might add latency because of binning.
Comment 72 Diego Viola 2019-04-05 15:26:21 UTC
(In reply to Michel Dänzer from comment #51) 
> The working hypothesis is that it's a Mesa regression between 18.3 and 19.0,
> so that makes sense?

That was a mistake from my part, sorry.

Setting 'export MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage"' after startx still makes xterm work fine even after startx (from a running Xorg session).

Sorry for the confusion.
Comment 73 Diego Viola 2019-04-05 15:34:02 UTC
Sorry for the confusing comments.

export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" makes xterm always work with Xpehyr git, no matter if I set that variable before or after startx.
Comment 74 Diego Viola 2019-04-05 15:38:36 UTC
(In reply to Diego Viola from comment #65)
> Just to make it a bit more clear:
> 
> If I set that environment variable while I'm already on X:
> 
> export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier"
> 
> It has no effect on Xephyr (from current git master), i.e. xterm still shows
> the bug.

This comment is completely wrong, ignore it.
Comment 75 Diego Viola 2019-04-05 17:14:44 UTC
(In reply to Diego Viola from comment #72)
> (In reply to Michel Dänzer from comment #51) 
> > The working hypothesis is that it's a Mesa regression between 18.3 and 19.0,
> > so that makes sense?
> 
> That was a mistake from my part, sorry.
> 
> Setting 'export MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage"' after
> startx still makes xterm work fine even after startx (from a running Xorg
> session).
> 
> Sorry for the confusion.

Replied to the wrong comment, this was supposed to be a reply to #68.
Comment 76 Michel Dänzer 2019-04-08 09:09:50 UTC
(In reply to Diego Viola from comment #24)
> I've bisected the issue with the GTK elements sometimes disappearing, and
> the commit that causes the issue is this one:
> 
> 1b25d340b791ad8350bdfb27f1a91ac79fa17748 is the first bad commit

Can you double-check this with Xephyr, taking everything we've learned since then into account, and if the same commit is identified again, file a new report about it?
Comment 77 Diego Viola 2019-04-08 09:17:55 UTC
(In reply to Michel Dänzer from comment #76)
> (In reply to Diego Viola from comment #24)
> > I've bisected the issue with the GTK elements sometimes disappearing, and
> > the commit that causes the issue is this one:
> > 
> > 1b25d340b791ad8350bdfb27f1a91ac79fa17748 is the first bad commit
> 
> Can you double-check this with Xephyr, taking everything we've learned since
> then into account, and if the same commit is identified again, file a new
> report about it?

Sure thing.
Comment 78 Diego Viola 2019-04-12 22:24:22 UTC
Created attachment 143956 [details]
clinfo -A output
Comment 79 Diego Viola 2019-04-17 21:08:06 UTC
I found that a workaround for this issue is to add the following to my Xresources:

XTerm.vt100.scaleHeight: 0.9

The default is 1.0 (which creates the problem), a value of 1.5 also makes it work (although fonts look too wide then).

I found this information here:

https://savannah.nongnu.org/bugs/index.php?52165
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880407

Which might indicate this being a freetype problem?
Comment 80 Michel Dänzer 2019-04-18 08:22:10 UTC
(In reply to Diego Viola from comment #79)
> Which might indicate this being a freetype problem?

No. If it was a FreeType problem, R600_DEBUG=nodpbb or MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" couldn't work around it.

Changing the xterm configuration just happens to avoid the problem somehow.
Comment 81 Diego Viola 2019-04-18 17:59:17 UTC
(In reply to Michel Dänzer from comment #80)
> (In reply to Diego Viola from comment #79)
> > Which might indicate this being a freetype problem?
> 
> No. If it was a FreeType problem, R600_DEBUG=nodpbb or
> MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" couldn't work around it.
> 
> Changing the xterm configuration just happens to avoid the problem somehow.

Makes sense, thanks.
Comment 82 Diego Viola 2019-04-18 23:32:06 UTC
I found that I can't reproduce this bug with Xephyr -glamor_gles2 (git) but it still happens with -glamor.
Comment 83 Michel Dänzer 2019-04-19 09:43:10 UTC
(In reply to Diego Viola from comment #82)
> I found that I can't reproduce this bug with Xephyr -glamor_gles2 (git) but
> it still happens with -glamor.

Presumably the GL_NV_texture_barrier extension isn't available with GLES2, so this is the same as disabling that extension with OpenGL.
Comment 84 Diego Viola 2019-04-20 23:08:05 UTC
(In reply to Michel Dänzer from comment #83)
> (In reply to Diego Viola from comment #82)
> > I found that I can't reproduce this bug with Xephyr -glamor_gles2 (git) but
> > it still happens with -glamor.
> 
> Presumably the GL_NV_texture_barrier extension isn't available with GLES2,
> so this is the same as disabling that extension with OpenGL.

Makes sense, thanks.
Comment 85 Diego Viola 2019-04-20 23:10:33 UTC
Created attachment 144054 [details]
xterm exhibiting the bug

xterm exhibiting the bug after running "dmesg" and hitting Shift+PgUp.
Comment 86 Diego Viola 2019-04-28 19:57:29 UTC
I found another workaround.

Edit xterm's util.c and change line 2161:

unsigned int h = (unsigned) (nlines * FontHeight(screen));

to:

unsigned int h = (unsigned) (1000);

i.e. increasing the h variable to a large enough number makes it work for some reason.
Comment 87 komqinxit 2019-05-03 12:31:08 UTC
I have the same bug with xterm and shift+paging.

Another similar bug.
xfce4-terminal leaves a large black area at the bottom when it renders 'dmesg' or 'cat /etc/passwd'.

AMD Ryzen 3 2200G.
Arch Linux.
Mesa 19.0.3-1
Comment 88 Diego Viola 2019-05-05 07:49:56 UTC
(In reply to komqinxit from comment #87)
> Another similar bug.
> xfce4-terminal leaves a large black area at the bottom when it renders
> 'dmesg' or 'cat /etc/passwd'.
> 
> AMD Ryzen 3 2200G.
> Arch Linux.
> Mesa 19.0.3-1

I can reproduce this, it happens for me with xfce4-terminal and also gnome-terminal and most other VTE-based terminals.

I also noticed that setting R600_DEBUG=nodpbb and MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" does not seem to help.
Comment 89 komqinxit 2019-05-07 16:45:40 UTC
Created attachment 144187 [details]
Bug in Geany
Comment 90 komqinxit 2019-05-07 16:47:23 UTC
Created attachment 144188 [details]
Geany without a bug
Comment 91 komqinxit 2019-05-10 23:13:00 UTC
xfce4-terminal and Geany bugs seem to be this https://bugs.freedesktop.org/show_bug.cgi?id=110355 and solved with mesa 19.0.4.
Comment 92 Diego Viola 2019-05-11 20:38:41 UTC
(In reply to komqinxit from comment #91)
> xfce4-terminal and Geany bugs seem to be this
> https://bugs.freedesktop.org/show_bug.cgi?id=110355 and solved with mesa
> 19.0.4.

That's good to know, thanks.
Comment 93 Diego Viola 2019-05-21 18:00:41 UTC
I just tried to reproduce this issue (xterm bug) with sway today and noticed that I can't reproduce it under sway.

The bug can still be reproduced with weston and i3.

- sway 1.0-8
- xorg-server-xwayland 1.20.4-1
- mesa 19.0.4-1
Comment 94 Diego Viola 2019-06-19 05:11:27 UTC
This bug is still present with mesa 19.1.0-1.
Comment 95 Diego Viola 2019-07-13 00:57:30 UTC
Still a problem with linux 5.2.0-arch2-1-ARCH and mesa 19.1.2-1.
Comment 96 Diego Viola 2019-07-14 09:14:14 UTC
Created attachment 144786 [details]
Yet another workaround (patch) for xterm

Replacing FontHeight for VDrawable seems to help.
Comment 97 Diego Viola 2019-07-14 09:16:33 UTC
s/for/with/
Comment 98 Diego Viola 2019-07-15 01:00:58 UTC
(In reply to Diego Viola from comment #96)
> Created attachment 144786 [details]
> Yet another workaround (patch) for xterm
> 
> Replacing FontHeight for VDrawable seems to help.

VDrawable is just a big number, so same thing as Comment 86.

Nevermind.
Comment 99 Michel Dänzer 2019-08-02 16:30:55 UTC
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes for DPBB, might help for this as well.
Comment 100 Diego Viola 2019-08-03 02:11:45 UTC
(In reply to Michel Dänzer from comment #99)
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes
> for DPBB, might help for this as well.

Unfortunately it doesn't help, I compiled mesa to /usr/local (from his dpbb_fixes branch) but the issue is still there.
Comment 101 Pierre-Eric Pelloux-Prayer 2019-08-05 11:12:29 UTC
Created attachment 144948 [details]
comparison screenshot

It looks like a DPBB/scissor interation issue.

The screenshot on the left is a replay of a faulty trace with dpbb disabled.
On the right the same trace, at the same point but using dpbb.

The last executed commands are:
   glScissor(3, 3, 480, 144);
   glDrawArraysInstanced(GL_TRIANGLE_STRIP, 0, 4, 1);

As you can see, the purple area on the right doesn't honor the defined scissor area.
Comment 102 Pierre-Eric Pelloux-Prayer 2019-08-05 13:18:11 UTC
(In reply to Diego Viola from comment #100)
> (In reply to Michel Dänzer from comment #99)
> > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes
> > for DPBB, might help for this as well.
> 
> Unfortunately it doesn't help, I compiled mesa to /usr/local (from his
> dpbb_fixes branch) but the issue is still there.

I just pushed a new commit on the same MR (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554/diffs?commit_id=d25df1274ea48fa73b0d8b31558e2cebb0851015).

Could you test on your machine and let me know if it helps?
Comment 103 Diego Viola 2019-08-05 16:22:04 UTC
(In reply to Pierre-Eric Pelloux-Prayer from comment #102)
> (In reply to Diego Viola from comment #100)
> > (In reply to Michel Dänzer from comment #99)
> > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes
> > > for DPBB, might help for this as well.
> > 
> > Unfortunately it doesn't help, I compiled mesa to /usr/local (from his
> > dpbb_fixes branch) but the issue is still there.
> 
> I just pushed a new commit on the same MR
> (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554/
> diffs?commit_id=d25df1274ea48fa73b0d8b31558e2cebb0851015).
> 
> Could you test on your machine and let me know if it helps?

I can confirm that your new commit fixes the problem. Thank you very much! :D
Comment 104 Pierre-Eric Pelloux-Prayer 2019-08-07 08:15:23 UTC
(In reply to Diego Viola from comment #103)
> (In reply to Pierre-Eric Pelloux-Prayer from comment #102)
> > (In reply to Diego Viola from comment #100)
> > > (In reply to Michel Dänzer from comment #99)
> > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes
> > > > for DPBB, might help for this as well.
> > > 
> > > Unfortunately it doesn't help, I compiled mesa to /usr/local (from his
> > > dpbb_fixes branch) but the issue is still there.
> > 
> > I just pushed a new commit on the same MR
> > (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554/
> > diffs?commit_id=d25df1274ea48fa73b0d8b31558e2cebb0851015).
> > 
> > Could you test on your machine and let me know if it helps?
> 
> I can confirm that your new commit fixes the problem. Thank you very much! :D

Thanks for the confirmation.
I added a Tested-by tag to the commit.
Comment 105 Pierre-Eric Pelloux-Prayer 2019-08-07 21:44:38 UTC
The commit fixing this issue has changed a bit, it would be great if you could confirm the latest version of the MR works well for you.

Thanks!
Comment 106 Diego Viola 2019-08-07 22:55:33 UTC
(In reply to Pierre-Eric Pelloux-Prayer from comment #105)
> The commit fixing this issue has changed a bit, it would be great if you
> could confirm the latest version of the MR works well for you.
> 
> Thanks!

Yes, I can confirm it's working great with the latest version. Thank you!
Comment 107 Pierre-Eric Pelloux-Prayer 2019-08-08 13:49:02 UTC
The MR has been merged.

Thanks again for reporting the bug and helping fixing 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.