Bug 18914 - do_blit_bitmap(called by intelBitmap) uses dimensions of display window for rendering on fbos
Summary: do_blit_bitmap(called by intelBitmap) uses dimensions of display window for r...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: All All
: medium normal
Assignee: Eric Anholt
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-06 05:54 UTC by Pierre Willenbrock
Modified: 2009-08-24 12:31 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
Make do_blit_bitmap fall back to software rendering on fbos (713 bytes, patch)
2008-12-06 05:54 UTC, Pierre Willenbrock 		Details | Splinter Review
Trying to fix do_blit_bitmap (8.09 KB, patch)
2008-12-06 06:01 UTC, Pierre Willenbrock 		Details | Splinter Review
Make do_blit_bitmap fall back to software rendering on fbos (1012 bytes, patch)
2008-12-06 06:05 UTC, Pierre Willenbrock 		Details | Splinter Review
Show Obsolete (1) View All

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.