Bug 44433

Summary: [GL 3.0] Many oglc pbo subcases regressed
Product: Mesa Reporter: fangxun <xunx.fang>
Component: Drivers/DRI/i965Assignee: Ian Romanick <idr>
Status: VERIFIED FIXED QA Contact:
Severity: major    
Priority: high CC: eric
Version: git   
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 42993    

Description fangxun 2012-01-03 18:23:00 UTC
System Environment:
--------------------------
Arch:           i386
Platform:       huronriver
Libdrm:		(master)2.4.29-17-ga9dd34a7ee9d03d357e15f045ab85a12f6f6e4b8
Mesa:		(master)b5fd0e04a70d37a1bef9144096890e7940f9a200
Xserver:   (master)xorg-server-1.11.99.901
Xf86_video_intel (master)2.17.0-262-g770a953ff03bb8328c3f29e274d225528840f30c
Kernel:  (drm-intel-next)097354eb14fa94d31a09c64d640643f58e4a5a9a

Bug detailed description:
------------------------- 
The regression happens on SandyBridge and IvyBridge. It is caused by MESA_GL_VERSION_OVERRIDE=3.0.

Reproduce steps:
----------------
1. start X
2. ./oglconform -z -s -suite all -v 2 -test pbo basic.accessTypeParamTest
Comment 1 fangxun 2012-01-10 23:24:36 UTC
These cases regressed due to below commit.

commit deb6dd6b4df7324b4b240799029a80db65b89d96
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Jan 4 18:02:49 2012 -0800

    i965: Turn on ARB_depth_buffer_float by default.

    Everything about this that we have tests for works except for the
    deprecated metaops.  The conclusion we came to on IRC sounded like we
    were OK with turning it on as long as core functionality works.  The
    remaining failures (copypixels, drawpixels) should just be a matter of
    finishing the MapRenderbuffer for them.

    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Comment 2 Ian Romanick 2012-01-17 16:27:52 UTC
It doesn't look like this actually has anything to do with ARB_depth_float.  My guess is that the test just exercises some different functionality once 3.0 is available.
Comment 3 Ian Romanick 2012-01-17 16:31:26 UTC
I've sent a patch to the mesa-dev mailing list that should fix this issue.

http://lists.freedesktop.org/archives/mesa-dev/2012-January/017691.html
Comment 4 Ian Romanick 2012-01-24 15:38:46 UTC
Fixed on 8.0 branch by:

commit 0362995e5abd7527e587ed97d2132af29e307a3c
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Tue Jan 17 16:24:05 2012 -0800

    mesa: Set default access flags based on the run-time API
    
    The default access flags for OpenGL ES (via GL_OES_map_buffer) and
    desktop OpenGL are different.  The code previously tried to handle
    this, but the decision was made at compile time.  Since the same
    driver binary can be used for both OpenGL ES and desktop OpenGL, the
    decision must be made at run-time.
    
    This should fix bug #44433.  It appears that the test case does
    various map and unmap operations and inspects the state of the buffer
    object around each.  When it sees that GL_BUFFER_ACCESS does not match
    its expectations, it fails.
    
    NOTE: This is a candidate for release branches.
    
    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44433
    (cherry picked from commit f0ea46790f8f4df9a39b0cfab5c5f1bf02c136fc)
Comment 5 Ian Romanick 2012-01-24 15:41:24 UTC
(In reply to comment #4)
> Fixed on 8.0 branch by:
> commit 0362995e5abd7527e587ed97d2132af29e307a3c

That should be 30e9bfd84ad64655a5ed0d1f84f5877cb3ae1b5a

> Author: Ian Romanick <ian.d.romanick@intel.com>
> Date:   Tue Jan 17 16:24:05 2012 -0800
> 
>     mesa: Set default access flags based on the run-time API
> 
>     The default access flags for OpenGL ES (via GL_OES_map_buffer) and
>     desktop OpenGL are different.  The code previously tried to handle
>     this, but the decision was made at compile time.  Since the same
>     driver binary can be used for both OpenGL ES and desktop OpenGL, the
>     decision must be made at run-time.
> 
>     This should fix bug #44433.  It appears that the test case does
>     various map and unmap operations and inspects the state of the buffer
>     object around each.  When it sees that GL_BUFFER_ACCESS does not match
>     its expectations, it fails.
> 
>     NOTE: This is a candidate for release branches.
> 
>     Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
>     Reviewed-by: Brian Paul <brianp@vmware.com>
>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44433
>     (cherry picked from commit f0ea46790f8f4df9a39b0cfab5c5f1bf02c136fc)
Comment 6 Ouping Zhang 2012-01-30 23:28:08 UTC
System Environment:
--------------------------
Libdrm:         (master)2.4.30-18-gb643b0713aefdc0611e47654e88263b53b0de6f5
Mesa:           (8.0)caebd7929dca802ece8ef36b0f85094d66133b57
Xserver:                (server-1.11-branch)xorg-server-1.11.3
Xf86_video_intel:               (master)2.17.0-599-gca252e5b51d7b2f5a7b2c2e0d8fdb024b08096db

verify with mesa 8.0 branch, these cases passed on huronriver.
such as:
(GL21)pbo(basic.accessTypeParamTest)
(GL21)pbo(drawPixels.1PBOBufferSubData)
(GL21)pbo(texImage.1PBOBufferSubData)
(GL21)pbo(vboAndFBO.readFromAFBO)
......

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.