And with 2.99.917, DRI3 enabled and all the Present fixes I posted to the xorg-devel ml?

(In reply to Chris Wilson from comment #1)
> And with 2.99.917, DRI3 enabled and all the Present fixes I posted to the
> xorg-devel ml?

Not sure. I just tested with a Fedora 22 LiveCD which has:
xorg-x11-drv-intel version 2.99.917-6.20150211.fc22

But the bug is still there.


Could you tell me where I can get those fixes you committed? Maybe I'll find time to test them on my openSUSE 13.2 Linux.
Alternatively it would be great, if you could test Ksnapshot on your machine (if you have an Intel graphic).


I'll also ask "valdikss" from the other bugreport. He seems to be using Fedora and might has updated to 2.99.917-10.20150526.fc22

https://apps.fedoraproject.org/packages/xorg-x11-drv-intel

Starting from 2.99.917-9.20150520, Fedora removed the --with-default-dri=3, so DRI3 is disabled again, unless explicitly enabled in xorg.conf.

I just built a git snapshot on F21, and I can confirm the bug is still there.
But I don't know which Present fixes from xorg-devel matter, and I'm not sure I can test them on F21 (xorg 1.16.3).

Hmm, I tested on F21 last night using git + DRI3, and ksnaphot was fine, so I was preparing a F22 live image for testing.

Let's narrow down the reproduction steps then. How do you have kwin configured? How do you trigger the bug with ksnapshot? (fullscreen, window, etc)

(In reply to Chris Wilson from comment #4)
> Let's narrow down the reproduction steps then. How do you have kwin
> configured?
Compositing type : OpenGL 2.0
Tearing Prevention : Full scene repaints
IIRC with this config and DRI3, kwin uses the GLX_EXT_buffer_age extension (this is why I enable DRI3, else I have to choose between tear-free and performance when I use two screens).

>How do you trigger the bug with ksnapshot? (fullscreen, window, etc)
I just launch ksnapshot, and I see its window in the preview (it shouldn't, since it takes the snapshot before showing its window). Then if I use the "take a new snapshot" button, the new preview looks fine, but if I send it to kolourpaint for example, I see the "send to" menu open.

Oh, captures itself. For some reason I was looking for black... Ok, that makes the bug more likely to be about IncludeInferiors handling

Actually, it won't be IncludeInferiors but the synchronisation between unmapping the window and the contents in the framebuffer. This is going to be fun.

(In reply to Loïc Yhuel from comment #5)
> (In reply to Chris Wilson from comment #4)
> > Let's narrow down the reproduction steps then. How do you have kwin
> > configured?
> Compositing type : OpenGL 2.0
> Tearing Prevention : Full scene repaints
> IIRC with this config and DRI3, kwin uses the GLX_EXT_buffer_age extension
> (this is why I enable DRI3, else I have to choose between tear-free and
> performance when I use two screens).

Note that there a few caveats here. GLX_EXT_buffer_age in the client without support in mesa means that damage is not propagated back to the display server so that if you are using vnc, or udl, or something else like that it only sees full screen repaints and is so much slower than expected.

The other caveat is that DRI3 does not support single CRTC flipping like DRI2. That is you cannot have a single fullscreen application on one CRTC updating independently with the second screen (e.g. having a game/video on the primary monitor whilst reading email on the second). In this case DRI3 forces both screens to flip (and the compositor to repaint as required to correct damage), whereas ideally we would only update the single active CRTC and not touch the idle CRTC/buffer at all.

Ok, there is an interesting quirk in ksnapshot:

000:<:0732: 40: Request(1): CreateWindow depth=0x00 window=0x02e00145 parent=0x000000a4 x=-10000 y=-10000 width=683 height=307 border-width=0 class=CopyFromParent(0x0000) visual=CopyFromParent(0x00000000) value-list={background-pixel=0x00ffffff border-pixel=0x00000000}
...
000:<:075c:  8: Request(8): MapWindow window=0x02e00145
000:>:075d: Event MapNotify(19) event=0x02e00145 window=0x02e00145 override-redirect=true(0x01)
000:>:075d: Event Expose(12) window=0x02e00145 x=0 y=0 width=683 height=307 count=0x0000
...
000:<:0765: 16: Request(53): CreatePixmap depth=0x18 pid=0x02e00148 drawable=0x0
00000a4 width=1366 height=768
000:<:0766: 20: RENDER-Request(138,4): CreatePicture pid=0x02e00149 drawable=0x0
2e00148 format=0x0000002a values={}
000:<:0767: 16: Request(55): CreateGC cid=0x02e0014a drawable=0x02e00148 values=
{}
000:<:0768: 16: Request(56): ChangeGC gc=0x02e0014a values={subwindow-mode=Inclu
deInferiors(0x01)}
000:<:0769: 28: Request(62): CopyArea src-drawable=0x000000a4 dst-drawable=0x02e
00148 gc=0x02e0014a src-x=0 src-y=0 dst-x=0 dst-y=0 width=1366 height=768
000:<:076a:  8: Request(60): FreeGC gc=0x02e0014a
000:<:076b:  8: Request(27): UngrabPointer time=0x0094b535
000:<:076c:  8: Request(10): UnmapWindow window=0x02e00145

So ksnapshot does actually copy the screen while it itself is mapped (and visible). However, at the time of its screengrab, it hasn't rendered so it will effectively be transparent.

So the problem is that image does somehow contain rendering from the future.

Hmm, 

[  9745.803] sna_pixmap_make_cow: moo! attaching clone to pixmap=6954 (source=966, handle=221)

pixmap=6954 is, if you haven't guess it, ksnapshot's screengrab. So we are deferring the copy here - but since the source is actually a foriegn DRI3 buffer, kwin renders into it unbeknownst to us.

commit ada30742ec115a44445e24c1775583b2684d94a4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jun 5 16:44:18 2015 +0100

    sna: Add COW source pixmap to flushing list
    
    In the case of an exported pixmap, e.g. with DRI3, it is possible for
    the client to render into the pixmap whilst we are unaware. To serialise
    the xserver and the client, we flush all operations on exported pixmaps
    before talking to the client. In the case of COW however, we did not
    flush the copy-on-write when transferring control to the client, and
    thereby we could capture the modified contents.
    
    Bugzilla: https://bugs.kde.org/show_bug.cgi?id=340202
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90836
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

In case anyone is wondering, it also fixed this ksnapshot problem that happened with dri3 + opengl compositing with "fullscreen repaint" vsync (but not without vsync):
https://www.youtube.com/watch?v=ZZSXg9GXt8A

Thanks for the fix.

(In reply to Chris Wilson from comment #9)
Great, I can confirm the issue is fixed :)

(In reply to Chris Wilson from comment #8)
> (In reply to Loïc Yhuel from comment #5)
> > (In reply to Chris Wilson from comment #4)
> > > Let's narrow down the reproduction steps then. How do you have kwin
> > > configured?
> > Compositing type : OpenGL 2.0
> > Tearing Prevention : Full scene repaints
> > IIRC with this config and DRI3, kwin uses the GLX_EXT_buffer_age extension
> > (this is why I enable DRI3, else I have to choose between tear-free and
> > performance when I use two screens).
> 
> Note that there a few caveats here. GLX_EXT_buffer_age in the client without
> support in mesa means that damage is not propagated back to the display
> server so that if you are using vnc, or udl, or something else like that it
> only sees full screen repaints and is so much slower than expected.
With Wayland, there would be EGL_EXT_swap_buffers_with_damage, I guess something like this could be useful on GLX.
 
> The other caveat is that DRI3 does not support single CRTC flipping like
> DRI2. That is you cannot have a single fullscreen application on one CRTC
> updating independently with the second screen (e.g. having a game/video on
> the primary monitor whilst reading email on the second). In this case DRI3
> forces both screens to flip (and the compositor to repaint as required to
> correct damage), whereas ideally we would only update the single active CRTC
> and not touch the idle CRTC/buffer at all.
I don't think kwin supports flipping a single CRTC, else I wouldn't see any performance difference in animations on the primary monitor when I plug the second one.

Anyway, I need to set kwin to "full scene repaints" to avoid tearing, with DRI3 it does in fact partial repaints using GLX_EXT_buffer_age, which is faster than real full screen repaints with DRI2.

(In reply to Loïc Yhuel from comment #11)
> (In reply to Chris Wilson from comment #9)
> Great, I can confirm the issue is fixed :)
> 
> (In reply to Chris Wilson from comment #8)
> > (In reply to Loïc Yhuel from comment #5)
> > > (In reply to Chris Wilson from comment #4)
> > > > Let's narrow down the reproduction steps then. How do you have kwin
> > > > configured?
> > > Compositing type : OpenGL 2.0
> > > Tearing Prevention : Full scene repaints
> > > IIRC with this config and DRI3, kwin uses the GLX_EXT_buffer_age extension
> > > (this is why I enable DRI3, else I have to choose between tear-free and
> > > performance when I use two screens).
> > 
> > Note that there a few caveats here. GLX_EXT_buffer_age in the client without
> > support in mesa means that damage is not propagated back to the display
> > server so that if you are using vnc, or udl, or something else like that it
> > only sees full screen repaints and is so much slower than expected.
> With Wayland, there would be EGL_EXT_swap_buffers_with_damage, I guess
> something like this could be useful on GLX.

And even trivial to implement. 

> > The other caveat is that DRI3 does not support single CRTC flipping like
> > DRI2. That is you cannot have a single fullscreen application on one CRTC
> > updating independently with the second screen (e.g. having a game/video on
> > the primary monitor whilst reading email on the second). In this case DRI3
> > forces both screens to flip (and the compositor to repaint as required to
> > correct damage), whereas ideally we would only update the single active CRTC
> > and not touch the idle CRTC/buffer at all.
> I don't think kwin supports flipping a single CRTC, else I wouldn't see any
> performance difference in animations on the primary monitor when I plug the
> second one.

All that is required is for the compositor to unredirect the single-monitor "fullscreen" app.

> Anyway, I need to set kwin to "full scene repaints" to avoid tearing, with
> DRI3 it does in fact partial repaints using GLX_EXT_buffer_age, which is
> faster than real full screen repaints with DRI2.

Yes. As above, GLX_EXT_buffer_age can easily be done with DRI2 as well. I am just warning that GLX_EXT_buffer_age without a "GLX_MESA_swap_with_damage" extension has performance issues with PRIME setups or other extended desktop techniques(like VNC, screen capture).

(In reply to Christoph Haag from comment #10)
> In case anyone is wondering, it also fixed this ksnapshot problem that
> happened with dri3 + opengl compositing with "fullscreen repaint" vsync (but
> not without vsync):
> https://www.youtube.com/watch?v=ZZSXg9GXt8A
> 
> Thanks for the fix.

Ooops, false alarm. This still happens. Probably wasn't directly related. Sometimes it works though, which is why I thought it was fixed.

(In reply to Christoph Haag from comment #13)
> (In reply to Christoph Haag from comment #10)
> > In case anyone is wondering, it also fixed this ksnapshot problem that
> > happened with dri3 + opengl compositing with "fullscreen repaint" vsync (but
> > not without vsync):
> > https://www.youtube.com/watch?v=ZZSXg9GXt8A
> > 
> > Thanks for the fix.
> 
> Ooops, false alarm. This still happens. Probably wasn't directly related.
> Sometimes it works though, which is why I thought it was fixed.

So it's clearly not fixed?
If yes, please change the bug status back to reopened!