Bug 26678 - [i915 i965 bisected] Many piglit/glean cases regressed
Summary: [i915 i965 bisected] Many piglit/glean cases regressed
Status: VERIFIED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915 (show other bugs)
Version: git
Hardware: Other Linux (All)
: highest major
Assignee: Kristian Høgsberg
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-20 23:02 UTC by Shuang He
Modified: 2010-03-18 18:30 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Shuang He 2010-02-20 23:02:06 UTC
System Environment:
--------------------------
Libdrm:         (master)a5c8f55397377994ceeb76ed0ff148ff89eb3a1b
Mesa:           (master)1613735d08eacc4b3d21694e5010587357525ecc
Xf86_video_intel:              
(master)1c3aaad09d6ef207fba748ad4ef4575a26ab2e5c
Xserver:                (master)a34812b09000db2ff2a1dc6182602839123edd4e
Kernel:       (drm-intel-next)d62a57e2ee7be1f7e86047faee6ca5ba7720182f


Bug detailed description:
-------------------------
This issue happens on G45.

Many piglit cases regressed, like:
general/bgra-vert-attrib-pointer
general/bgra-sec-color-pointer
general/depth-clamp-range
general/depth-range-clear
general/occlusion_query
general/pbo-drawpixels
general/scissor-clear
general/scissor-copypixels
general/scissor-depth-clear
general/scissor-stencil-clear

Many glean cases regressed, like:
basicPerf
makeCurrent
occluQry
orthoPosRandTris
orthoPosRandRects
orthoPosTinyQuads
orthoPosHLines
orthoPosVLines
orthoPosPoints
readPixSanity
texCombine4
texEnv


bisect show following commit brings in this issue:
commit d449627829e1a4a3250a1a723af2f4e3cd5fd194
Author: Kristian Høgsberg <krh@bitplanet.net>
Date:   Wed Feb 17 21:17:55 2010 -0500

    intel: Implement the DRI2 invalidate function properly

    This uses a stamp mechanisms to mark the DRI drawable as invalid.
    Instead of immediately updating the buffers we just bump the drawable
    stamp and call out to DRI2GetBuffers "later".

    "Later" used to be at LOCK_HARDWARE time, and this patch brings back
    callouts at the points where we used to call LOCK_HARDWARE.  A new function,
    intel_prepare_render(), is called where we used to call LOCK_HARDWARE,
    and if the buffers are invalid, we call out to DRI2GetBuffers there.

    This lets us invalidate buffers only when notified instead of on
    every glViewport() call.  If the loader calls the DRI invalidate
    entrypoint, we disable viewport triggered buffer invalidation.

    Additionally, we can clean up the old viewport mechanism a bit,
    since we can just invalidate the buffers and not worry about
    reentrancy and whatnot.
Comment 1 Shuang He 2010-02-22 00:50:54 UTC
this issue also impact same glean cases on 945GM
Comment 2 Shuang He 2010-02-25 18:27:28 UTC
glean/occluQry, glean/texCombine4, glean/texEnv still fails
Comment 3 Kristian Høgsberg 2010-03-17 19:55:51 UTC
Is this just a dupe of bug #26676?
Comment 4 Shuang He 2010-03-18 18:30:07 UTC
Most of those test cases restored their results, so I'd mark this bug as fix then.
Thanks for krh.
Comment 5 Shuang He 2010-03-18 18:30:17 UTC
verified on G45 and 945GM against:
Libdrm  (master)df9737094ee821289fbf8a0297d34b77587878a4
Mesa    (master)9d48a621d2a0e55a76a2cfd0aea3b773e907ed50
Xserver         (master)67a8c659f25218904bae64aac6e98e326c90330b
Xf86_video_intel        (master)3d4b3f257fbbb69c6f236d9803abe54a90d7d434
Kernel  (drm-intel-next)338d762fc2dc2c1493813123fc4cea998bb3e683


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.