Bug 79448 - Texture corruption when one context gets used on multiple windows
Summary: Texture corruption when one context gets used on multiple windows
Status: RESOLVED DUPLICATE of bug 74005
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 10.1
Hardware: Other All
: medium normal
Assignee: Kristian Høgsberg
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2014-05-30 09:44 UTC by Martin Flöser
Modified: 2014-06-18 17:19 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Apitrace showing the problem (62.55 KB, text/plain)
2014-05-30 09:44 UTC, Martin Flöser
corrupted texture (3.08 KB, image/png)
2014-05-30 09:45 UTC, Martin Flöser

Description Martin Flöser 2014-05-30 09:44:36 UTC
Created attachment 100153 [details]
Apitrace showing the problem

Downstream bug with a qml test: https://bugreports.qt-project.org/browse/QTBUG-39182

This happens if there are:
* one context
* at least two windows
* a texture used in each window
* texture loaded for each window in same frame

Attached is an apitrace run of the example and a corrupted texture.

If you need any more information from me, please let me know. This highly affects the upcoming Plasma release and we will try as best as possible to help fix this bug.
Comment 1 Martin Flöser 2014-05-30 09:45:32 UTC
Created attachment 100154 [details]
corrupted texture
Comment 2 David Edmundson 2014-06-12 11:57:06 UTC
This has now been 12 days without comment.

This bug is rather major as it makes a lot of displays unreadable and affects a lot of users.

Can you let us know if there is anything else we can provide to help?
Comment 3 Tapani Pälli 2014-06-18 12:11:29 UTC
I've bisected this, corruption (and some qapitrace crashes with this trace) start to happen afer following commit.

--- 8< ---
11baad35088dfd4bdabc1710df650dbfb413e7a3 is the first bad commit
commit 11baad35088dfd4bdabc1710df650dbfb413e7a3
Author: Kristian Høgsberg <krh@bitplanet.net>
Date:   Tue Jan 21 12:17:03 2014 -0800

    intel: Fix initial MakeCurrent for single-buffer drawables
    Commit 05da4a7a5e7d5bd988cb31f94ed8e1f053d9ee39 attempts to eliminate the
    call to intel_update_renderbuffer() in the case where we already have a
    drawbuffer for the drawable.  Unfortunately this only checks the
    back left renderbuffer, which breaks in case of single buffer drawables.
    This means that the initial viewport will not be set in that case.  Instead,
    we now check whether the initial viewport has not been set, in which case
    we call out to intel_update_renderbuffer().
    Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Comment 4 Tapani Pälli 2014-06-18 12:15:14 UTC
FYI there's bugs #74005 and #74083 that are related to this issue.
Comment 5 Tapani Pälli 2014-06-18 13:04:29 UTC
IMO the reason why this fails is that first makecurrent calls sets ctx.ViewportInitialized to true. Further makecurrent calls with different drawables do not trigger intel_prepare_render() call to get buffers.
Comment 6 Kristian Høgsberg 2014-06-18 17:19:59 UTC
Duplicate of 74005.  Fix for that pushed to master and scheduled for upcoming 10.1 and 10.2 releases.

*** This bug has been marked as a duplicate of bug 74005 ***

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.