| Summary: | [i965 Bisected]Piglit/glx_glx-make-glxdrawable-current fails | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | lu hua <huax.lu> |
| Component: | Drivers/DRI/i965 | Assignee: | Kristian Høgsberg <krh> |
| Status: | VERIFIED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | major | ||
| Priority: | high | CC: | anasuyax.r.nannuri, antonis+freedesktop.org, freedesktop, giuliocamuffo, idr, itoral, mgraesslin, nucrap, pierluigi.fiorini, scampa.giovanni, ullysses.a.eoff |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Patch | ||
|
Description
lu hua
2014-01-24 02:08:02 UTC
If a regression bisects to a commit by an Intel employee, please assign the bug to that person. Otherwise they may not notice the bug. Does this problem still occur? It should have been fixed by these commits: commit f658150639c36eda351590e757247c56507f494f Author: Kristian Høgsberg <krh@bitplanet.net> Date: Wed Feb 5 11:43:58 2014 -0800 glx: Pass NULL DRI drawables into the DRI driver for None GLX drawables GLX_ARB_create_context allows making a GLX context current with None drawable and readables, but this was never implemented correctly in GLX. We would create a __DRIdrawable for the None GLX drawable and pass that to the DRI driver and that would somehow work. Now it's somehow broken. The way this should have worked is that we pass a NULL DRI drawable to the DRI driver when the GLX user calls glXMakeContextCurrent() with None for drawable and readables. https://bugs.freedesktop.org/show_bug.cgi?id=74143 Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> commit 44338cd826623ae0675861015a56c528261f3fd3 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Wed Feb 5 10:59:02 2014 -0800 i965: Move intel_prepare_render() above first buffer access The driver is supposed to ensure buffers before any drawing operation, but in do_blit_drawpixels() and do_blit_copypixels() we inspect the buffer format before calling intel_prepare_render(). That was covered up by the unconditional call to intel_prepare_render() in intelMakeCurrent(), but we now only do this on the initial intelMakeCurrent call for a context (to get the size for the initial viewport values). https://bugs.freedesktop.org/show_bug.cgi?id=74083 Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Tested-by: Alexander Monakov <amonakov@gmail.com> It still fails on Mesa master branch(commit 18caef953f2de134077bfa6e46f8616f68ff1b1b) It also fails on Mesa 10.1 branch. I am unable to reproduce this failure using either master (with 18caef9) or with 10.1 on either the Fedora 18 or Fedora 20 xserver. Are you able to reproduce this bug with a window manager running? (In reply to comment #4) > I am unable to reproduce this failure using either master (with 18caef9) or > with 10.1 on either the Fedora 18 or Fedora 20 xserver. > > Are you able to reproduce this bug with a window manager running? It still fails on Mesa master branch(fc25956badb8e19) and 10.1 branch. We run it on Fedora 19. Created attachment 95650 [details] [review] Patch The problem seems to live in the fact that we check whether we have a viewport set to decide if we need to generate buffers for the drawable. This is not a valid solution for the scenario in which we switch drawables for the same context, since the viewport will be initialized the first time that we call MakeCurrent with one of the drawables. Thus, switching to a different drawable after the first MakeCurrent will not produce buffers for the new drawable, leading to the problem. The patch reverts the behavior to the original solution with a small change to support single buffer drawables (which was the reason the bad commit was introduced). Basically, it checks if we have a render buffer for the drawable, but instead of checking the BACK_LEFT buffer which only works for double buffer drawables we check the FRONT_LEFT buffer, which should work for both single buffer and double buffer drawables. (In reply to comment #6) > Created attachment 95650 [details] [review] [review] > Patch > Fixed by this patch. (In reply to comment #6) > Created attachment 95650 [details] [review] [review] > Patch > > The problem seems to live in the fact that we check whether we have a > viewport set to decide if we need to generate buffers for the drawable. This > is not a valid solution for the scenario in which we switch drawables for > the same context, since the viewport will be initialized the first time that > we call MakeCurrent with one of the drawables. Thus, switching to a > different drawable after the first MakeCurrent will not produce buffers for > the new drawable, leading to the problem. > > The patch reverts the behavior to the original solution with a small change > to support single buffer drawables (which was the reason the bad commit was > introduced). Basically, it checks if we have a render buffer for the > drawable, but instead of checking the BACK_LEFT buffer which only works for > double buffer drawables we check the FRONT_LEFT buffer, which should work > for both single buffer and double buffer drawables. We don't want to revert the behaviour. The initial patch removed a call to intel_prepare_render() in intelMakeCurrent(). We're supposed to call intel_prepare_render() any time we're about to touch the buffers, but the up-front call to intel_prepare_render() in intelMakeCurrent covered up a few places where we forgot. The fix now isn't to put back the up-front intel_prepare_render() call but to add it in the rendering paths that are missing it. Also, for reference, we need the buffer size for the initial value of the context viewport. So the first time a context is made current, we call intel_prepare_render() to get the buffers so we can see what size they are. When the same context is later made current with a different drawable, we have a value for the viewport and we're not supposed to change it, so there's no point in getting buffers. *** Bug 75797 has been marked as a duplicate of this bug. *** *** Bug 77083 has been marked as a duplicate of this bug. *** *** Bug 76761 has been marked as a duplicate of this bug. *** *** Bug 74689 has been marked as a duplicate of this bug. *** Any news? It still happens and renders the Hawaii desktop environment unusable... Test on (master)32c55448602f8ed764005e72682f5f3979763321, It still fails.
output:
Probe color at (1,1)
Expected: 0.000000 1.000000 0.000000
Observed: -9767039900831907594645915144552448.000000 0.000000 0.000000
PIGLIT: {'result': 'fail' }
*** Bug 79448 has been marked as a duplicate of this bug. *** This bug is a pretty much a game-stopper for anyone on integrated Intel cards that would like to upgrade to Plasma 5 (myself included). Has any progress been made on this issue or is the latest comment from lu hua in June still the current state? Please disregard my previous comment. I have received confirmation from else where the issue is resolved in Git. this was fixed by commit 7928b94 Verified.Fixed. |
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.