Bug 101558 - [regression][bisected] MPV playing video via opengl "randomly" results in only part of the window / screen being rendered with Mesa GIT.
Summary: [regression][bisected] MPV playing video via opengl "randomly" results in onl...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Kenneth Graunke
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-22 15:51 UTC by Matti Hämäläinen
Modified: 2017-07-20 23:13 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Attachments
Screenshot of bugged rendering. (389.83 KB, image/jpeg)
2017-06-22 15:51 UTC, Matti Hämäläinen 		Details
View All

Description Matti Hämäläinen 2017-06-22 15:51:21 UTC 
Created attachment 132141 [details]
Screenshot of bugged rendering.

Mesa GIT commit b7153c3e9f9d2d430b0338313587a00e531e4800 "i965: Call intel_prepare_render() from intel_update_state()" causes a regression with MPV OpenGL video output at least on Haswell, resulting occasionally in partially rendered window (or screen, in case of fullscreen). The problem tends to persist, e.g. seeking or such does not get rid of it. Restarting MPV may sometimes result in correct rendering, but switching to fullscreen may result in broken rendering again.

Reverting the commit on top of Mesa GIT head "fixes" the problem, but is probably not a good solution as the change is supposed to fix other issues.

Screenshot of buggy rendering attached.

-- Linux distribution: Debian GNU/Linux 9.0 (stretch)
-- System architecture: amd64
   Foreign architectures: i386
-- Machine: Asus H97M-PLUS, Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
-- Kernel version: 4.9.33-grsec
-- Chipset: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
-- Display connector(s): HDMI (2560x1440)
-- Window manager: WindowMaker 0.95.7-8
-- xf86-video-intel: GIT 
-- X server: Xorg 2:1.19.3-1
-- libpixman: 0.34.0-1
-- libdrm version: GIT b9549c954e190010a79e6691983b6ae16eac83d5
Comment 1 Kenneth Graunke 2017-06-23 00:54:54 UTC 
Thanks ccr!  I can reproduce this on Skylake - apparently one of the 3DSTATE_DRAWING_RECTANGLE packets is being dropped - not sure why yet.

It looks like no state flags are being set when we get new buffers from DRI2/DRI3, which is surprising to say the least.

I'll look into this.
Comment 2 Tomasz Figa 2017-07-11 08:05:23 UTC 
Hi Kenneth,

Have you by any chance managed to find anything interesting on this?

FYI, we are also seeing some bugs triggered to adding this call. Namely Android CTS failures due to glReadPixels failing, see https://bugs.freedesktop.org/show_bug.cgi?id=101704.

Thanks,
Tomasz
Comment 3 Kenneth Graunke 2017-07-20 23:13:02 UTC 
Should be fixed:

commit 8696c3e997d23f65ade53df8f7efcfb21a99fb3d
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Wed Jul 19 21:29:51 2017 -0700

    Revert "i965: Call intel_prepare_render() from intel_update_state()"
    
    This reverts commit b7153c3e9f9d2d430b0338313587a00e531e4800.
    
    The point of that commit was to ensure intel_prepare_render() occurred
    before color resolves on the current framebuffer.  In 0673bbfd9ba16be8
    (i965: Move surface resolves back to draw/dispatch time), Jason moved
    brw_predraw_resolve_framebuffer back to draw time, which is already
    after a intel_prepare_render() call.  So, this is no longer necessary.
    
    Furthermore, it caused problems.  "mpv" would only display a small
    corner of movies, and Android started failing camera CTS tests.
    
    This is because intel_prepare_render() ended up handling DRI2 events
    which caused the drawable to be resized at an inopportune time, flagging
    ctx->NewState |= _NEW_BUFFERS, but at a point where we've already copied
    ctx->NewState, and failed to notice the newly set flag.
    
    The lack of _NEW_BUFFERS caused us to skip 3DSTATE_DRAWING_RECTANGLE,
    so the drawing ended up being clipped to an outdated framebuffer size.
    
    Just drop the hack and go back to handling this at the proper time.
    
    Thanks to Matti Hämäläinen (ccr), Tomasz Figa (tfiga), and Tapani Palli
    for reporting these issues.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101558
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101704
    Tested-by: Tapani Pälli <tapani.palli@intel.com>

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.