Bug 98252

Summary: [IVB] DRI3 - Opening an image with mpv -vo opengl only draws part of the image
Product: Mesa Reporter: Tod Jackson <tod.jackson>
Component: Drivers/DRI/i965Assignee: Intel 3D Bugs Mailing List <intel-3d-bugs>
Status: RESOLVED WORKSFORME QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium CC: martin.peres
Version: 12.0   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: dmesg
screenshot
Xorg.0.log

Description Tod Jackson 2016-10-14 09:16:01 UTC
Created attachment 127293 [details]
dmesg

For a few years I've observed an issue with DRI3 loading images (any format) with mpv -vo opengl where only maybe 10-20% of the top left corner is drawn, and the rest is black. If it's a playlist then the second and subsequent images are drawn correctly, after the initial window was already created.

It's present with xf86-video-intel and modesetting, and is fixed with LIBGL_DRI3_DISABLE=1. 

There are similar issues reported such as "blank, black elements" or "gtk corruption" but these seem to have been reported fixed on some hardware or just hard to reproduce, I guess. Since I seem to have some insomnia I've decided to finally report this. ;)

I'll attach a few relevant things in a moment. Also, sorry if I've miscategorized this.
Comment 1 Tod Jackson 2016-10-14 09:18:41 UTC
Created attachment 127294 [details]
screenshot

Apparently it just draws it partially transparent, not black.
Comment 2 Tod Jackson 2016-10-14 09:19:42 UTC
Created attachment 127295 [details]
Xorg.0.log
Comment 3 Matt Turner 2016-11-03 18:52:15 UTC
I use mpv all the time (on HSW) with DRI3 and I've never seen this.

Does it work any better with mesa-13.0.0? Mark the bug as REOPENED if you can reproduce and RESOLVED/* if you cannot reproduce.
Comment 4 Tod Jackson 2016-11-04 05:26:59 UTC
I tested with Mesa 13.1.0-devel (git-8015746) and I can still reproduce. However I found something interesting: it happens with my usual setup, ratpoison WM, as well as the window manager cwm, however I don't observe it with fluxbox.

So... I'm not sure whose bug it is.
Comment 5 Tod Jackson 2016-11-05 00:22:36 UTC
I could have sworn I tested this...  mpv --force-window=immediate is a workaround too.
Comment 6 Tod Jackson 2016-11-21 01:07:52 UTC
Chris' experimental patch here
https://bugs.freedesktop.org/show_bug.cgi?id=97914#c32
regarding a separate but seemingly related issue causes mpv to exhibit the same behavior with DRI2. A clue?

mpv -vo opengl -no-config -force-window=immediate -hwdec=no example.png again sort of works around the problem, but that breaks fullscreen since it forces a 640x480 window.
Comment 7 Juha-Pekka Heikkilä 2016-12-18 20:27:18 UTC
I was able to reproduce this on IVB laptop with few days old Mesa master but only with Ratpoison wm w/ DRI3. I see also Firefox on Ratpoison w/ DRI3 sometimes get wrong window size but not always, that look like race condition to me. Ratpoison always resizes window on program start and way Firefox behave make me think this is problem on composite messages sent by Ratpoison with those resizes.
Comment 8 Tod Jackson 2017-03-20 18:21:38 UTC
Seems to be fixed on intel and modesetting! No idea which package though.

mpv git-80b89cef61
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.0.1
xf86-video-intel 1:2.99.917+767+g7e9e92c8
xorg-server 1.19.3
Comment 9 Tod Jackson 2017-03-25 15:41:59 UTC
Fixed in mpv sometime after version 0.23 ... So I'll close this.

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.