Bug 45558 - cannot render on a drawable of size equal the max framebuffer size
Summary: cannot render on a drawable of size equal the max framebuffer size
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i830 (show other bugs)
Version: git
Hardware: All All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-02 10:36 UTC by Alban Browaeys
Modified: 2012-03-02 17:31 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
do not drift one pixel above what we want - x2, y2 are exclusive max (2.80 KB, patch)
2012-02-02 10:36 UTC, Alban Browaeys
Details | Splinter Review
testcase for max not rendering (3.06 KB, text/plain)
2012-02-02 10:40 UTC, Alban Browaeys
Details

Description Alban Browaeys 2012-02-02 10:36:45 UTC
Created attachment 56550 [details] [review]
do not drift one pixel above what we want - x2, y2 are exclusive max

The xorg drawable sizes are exclusive as I have learned on xorg-devel irc channel by MrCooper.
This means that width = x2 - x1 , x2 behing exclusive and thus in the places the code does DrawBuffer->Width + x1 to get the right coordinate when we get a coordinate one pixel above what we want (ie we send x2 which is exclusive).

This patch fixes a few places were the gen2 865g are affected by this bug. That is gnome-shell renders badly due to cogl using atlas a power of two of the resolution (which is good but this leads to 2048 which is the framebuffer max size on gen2).

I will also attach the testcase I used which is dumb but reproduce the same issue as gnome-shell /cogl. Ie a drawable attached to the context as read and draw buffer the size equal to framebuffer max size , ie 2048, on 865g gen2.
Comment 1 Alban Browaeys 2012-02-02 10:40:03 UTC
Created attachment 56551 [details]
testcase for max not rendering

This testcase is made from a mesa demo. The issue is that with WindowSize 2048 (width and height - and width or height) where the max framebuffer size is 2048 the render fails.
Comment 2 Alban Browaeys 2012-02-05 14:50:24 UTC
To clarify I meant src/mesa/drivers/dri/i915/intel_context.c:	 ctx->Const.MaxRenderbufferSize = 2048;
not framebuffer size. That is the drawable size attached to the gl context. It is 2048 for less or equal to gen 3.
So the test should be right for gen3 too.
Comment 3 Eric Anholt 2012-03-02 17:31:52 UTC
The BLT ranges are exclusive -- it's only the drawrect that has that oddness.  I pushed that part of the patch, and it does almost entirely fix gnome-shell rendering.

commit 7d13a6e64bf88566875a8f68e0aac9b937e30feb
Author: Alban Browaeys <prahal@yahoo.com>
Date:   Thu Feb 2 19:20:22 2012 +0100

    dri/i915: Fix off-by-one in i830 clip region size.
    
    The hardware, like i915, uses an inclusive bounds on min and max for
    the drawing rectangle, but we were providing a number for exclusive.
    The number of bits used by the hardware only covers this value going
    up to the maximum size, so when we programmed 2048 as the maximum
    inclusive X, it saw a maximum X of 0 and clipped all rendering.  This
    caused rendering failures in gnome-shell.
    
    Fixes piglit fbo-maxsize.
    
    v2: dropped changes to the blitter, which does use an exclusive x2, y2.
        [change by anholt]
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45558
    Reviewed-by: Eric Anholt <eric@anholt.net>
    NOTE: This is a candidate for release branches.


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.