Summary: | [GL 3.0] Many oglc pbo subcases regressed | ||
---|---|---|---|
Product: | Mesa | Reporter: | fangxun <xunx.fang> |
Component: | Drivers/DRI/i965 | Assignee: | 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
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> 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. 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 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) (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) 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.