Bug 18914

Summary: do_blit_bitmap(called by intelBitmap) uses dimensions of display window for rendering on fbos
Product: Mesa Reporter: Pierre Willenbrock <pierre>
Component: Drivers/DRI/i965Assignee: Eric Anholt <eric>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium    
Version: git   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Make do_blit_bitmap fall back to software rendering on fbos
Trying to fix do_blit_bitmap
Make do_blit_bitmap fall back to software rendering on fbos

Description Pierre Willenbrock 2008-12-06 05:54:29 UTC
Created attachment 20853 [details] [review]
Make do_blit_bitmap fall back to software rendering on fbos

The fbo_firecube demo does not render a single frame for me, leading to a lockup of the graphics pipeline. 

This is on a GM965, without DRI2, using EXA acceleration and an opengl compositor. Mesa, drm, xf86-video-intel is latest git.

Debugging with a single glBitmap call instead of all the glutBitmapCharacter calls, i noticed that the rendering wraps around on the fbo surface, with clipping happening somewhere in the middle of the surface. Making the bitmap cross the top surface border at some x-positions leads to the pipeline lockup.

Adding some debug output to do_blit_bitmap(intel_pixel_bitmap.c:158) revealed that the x_off, y_off are non-zero and the width, height used for clipping do not match the size of the fbo. These turn out to be the offsets and sizes of the main fbo_firecube window.

Making do_blit_bitmap fall back to software rendering leads to a working fbo_firecube. 

I did first report this as a comment in bug #16521, but it seems to be about a different problem.
Comment 1 Pierre Willenbrock 2008-12-06 06:01:48 UTC
Created attachment 20854 [details] [review]
Trying to fix do_blit_bitmap

This makes fbo_firecube work for about 10 frames. Reducing the amount of text outputted to the fbo(leaving out some of the longer lines) can make it work completely.
Comment 2 Pierre Willenbrock 2008-12-06 06:05:29 UTC
Created attachment 20855 [details] [review]
Make do_blit_bitmap fall back to software rendering on fbos

This did not even compile. sorry for the noise.
Comment 3 Eric Anholt 2008-12-06 23:06:24 UTC
Accelerated fix posted to mesa mailing list.  Got a chance to review?
Comment 4 Gordon Jin 2008-12-07 01:44:03 UTC
Pierre, thanks for following up the patch.
Comment 5 Pierre Willenbrock 2008-12-07 06:38:54 UTC
(In reply to comment #3)
> Accelerated fix posted to mesa mailing list.  Got a chance to review?

The code looks good. Good to know that ctx->DrawBuffer is updated for all render targets. The rendering looks visually correct.

But i still get the graphics lockup after a few 10 frames. This lockup shows for the fbo_firecube demo without DRI2 and for the fire demo with DRI2, while fire without DRI2 works.

The lockup goes away for fbo_firecube(without DRI2) when called with INTEL_DEBUG=sync or by reducing the number of characters printed to 16(thus reducing the number of glBitmap calls).

I did not test the last things for fire with DRI2, thinking that should be very similar to fbo_firecube without DRI2.
Comment 6 Eric Anholt 2008-12-08 11:10:04 UTC
commit cb433d91c6e198b7c77f747f1a38803532bc9be9
Author: Eric Anholt <eric@anholt.net>
Date:   Sat Dec 6 14:21:12 2008 -0800

    intel: Fix glBitmap blit acceleration for FBO destinations.
    
    Bug #18914.  Fixes fbo_firecube hang due to drawing outside the FBO bounds.
    Thanks to Pierre Willenbrock for debugging the issue.

With this fbo_firecube was stable on my G45, which I haven't seen before.
Comment 7 Adam Jackson 2009-08-24 12:31:11 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.