Bug 22538 - Frontbuffer issue ? - blender dropdown menus not rendered
Summary: Frontbuffer issue ? - blender dropdown menus not rendered
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Ian Romanick
QA Contact:
URL:
Whiteboard:
Keywords:
: 22994 22998 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-06-29 11:33 UTC by Alban Browaeys
Modified: 2009-08-24 12:32 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Alban Browaeys 2009-06-29 11:33:32 UTC
As told on right sidebar of blender site :
http://www.blender.org/download/get-blender/
"Users with Intel on-board graphics: some graphics operations (menus or border select) don't show due to driver bug."

and in latest comments in:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/353763

Though the frontbuffer fixes in :
http://bugs.freedesktop.org/show_bug.cgi?id=22288
are already applied on my setup:
xserver (debian unstable) - dbac41b624e4aa86a6a184b7ebb52bfdd367bbf0 upstream
x11proto-dri2 - 66c56ab10d917e3f47f93178d7eac6430970d3c4
drm (master) 790097c51330090b2b7b90429b9ab8ddf259fd8e
mesa (master) 94008088c1e6758a44a2f48c5a94db1f072d255a
xf86 video intel f53b3239dbc0ed723774e386e07ac9d8ce96bb89

blender 2.49 debian sid (non static mesa) 



Weird thing is if I enable two displays and start blender with -W (non windowed mode) ... it tries to span the two displays and fails to render properly . What s interesting is that in this case I can actually see the menu entries (though the menu borders are not rendered and a lot of artifacts happens).
Comment 1 Ian Romanick 2009-06-29 18:44:39 UTC
I committed a fix last week to mesa_7_5_branch that fixes and additional front-buffer rendering issue.  It might fix this problem as well.

commit 2d86503471cb8691ce266342810237fc1b15a7b2
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Fri Jun 26 13:30:16 2009 -0700

    intel / DRI2: Additional flush of fake front-buffer to real front-buffer
    
    To maintain correctness, the server will copy the real front-buffer to
    a newly allocated fake front-buffer in DRI2GetBuffersWithFormat.
    However, if the DRI2GetBuffersWithFormat is triggered by glViewport,
    this will copy stale data into the new buffer.  Fix this by flushing
    the current fake front-buffer to the real front-buffer in
    intel_viewport.
    
    Fixes bug #22288.
Comment 2 Ian Romanick 2009-06-29 18:45:35 UTC

*** This bug has been marked as a duplicate of bug 21774 ***
Comment 3 Ian Romanick 2009-06-29 18:48:12 UTC
I'll pay more attention next time.
Comment 4 roberth 2009-06-30 15:23:51 UTC
(In reply to comment #1)
> I committed a fix last week to mesa_7_5_branch that fixes and additional
> front-buffer rendering issue.  It might fix this problem as well.
> 
> commit 2d86503471cb8691ce266342810237fc1b15a7b2
> Author: Ian Romanick <ian.d.romanick@intel.com>
> Date:   Fri Jun 26 13:30:16 2009 -0700
> 
>     intel / DRI2: Additional flush of fake front-buffer to real front-buffer
> 
>     To maintain correctness, the server will copy the real front-buffer to
>     a newly allocated fake front-buffer in DRI2GetBuffersWithFormat.
>     However, if the DRI2GetBuffersWithFormat is triggered by glViewport,
>     this will copy stale data into the new buffer.  Fix this by flushing
>     the current fake front-buffer to the real front-buffer in
>     intel_viewport.
> 
>     Fixes bug #22288.
> 


It didn't fix it here, but I am not the original reporter and am on mesa 7.6 up to the "i915: Fix assertion failure on remapping a non-BO-backed VBO." commit (57a06d3a48c9af1067ec05e3ad96c58f4b9b99be on 06-30 which includes your above mentioned commit). Dropdown menus still dont render unless I use a static mesa blender version or LIBGL_ALWAYS_SOFTWARE=1. This is on a 945GME with -intel xserver and mesa all built from master today and the problem has existed since at least april. This is a backtrace from crashes that used to happen when clicking on a dropdown with texture tiling turned on if it helps any. That issue is fixed now but I dont know if it would help narrow down where the problem might be happening.

http://sarvatt.com/downloads/blender_bt.txt
Comment 5 Gordon Jin 2009-07-28 02:23:48 UTC
*** Bug 22998 has been marked as a duplicate of this bug. ***
Comment 6 Gordon Jin 2009-07-28 02:24:20 UTC
*** Bug 22994 has been marked as a duplicate of this bug. ***
Comment 7 Jonas Thiem 2009-07-29 06:31:28 UTC
https://bugs.freedesktop.org/show_bug.cgi?id=21774 which is supposed to be a duplicate of this bug, seems to address a different bug than https://bugs.freedesktop.org/show_bug.cgi?id=22998 which is also supposed to be a bug of this one.
The first one with ID 21774 says that menus are black or white, but #22998 says that they are not drawn at all (no refresh/change of the screen). And some user having the black/white issue in #21774 says it's also present in xf86-video-intel/2.7.99.901, but #22998 explicitly states that the problem was introduces by xf86-video-intel/2.7.99.902.
So I'd rather assume that #21774 and #22998 are different issues so they cannot be both duplicates of this bug? Although the user comments seem often to mix up both issues.
Comment 8 Eric Anholt 2009-08-03 14:42:42 UTC
commit fd65418f600874b05f902b622078b40bc1abb24a
Author: Eric Anholt <eric@anholt.net>
Date:   Mon Aug 3 14:27:41 2009 -0700

    intel: Fix inverted test for disabling flushing of front buffer output.
    
    The comment disagreed with the code, and nicely drew my eyes to what was
    going wrong.
    
    Bug #21774 (blender)
    Bug #21788 (readpix)
Comment 9 Adam Jackson 2009-08-24 12:32:39 UTC
Mass version move, cvs -> git


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.