Bugzilla – Bug 45558
cannot render on a drawable of size equal the max framebuffer size
Last modified: 2012-03-02 17:31:52 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.
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.
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.
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.
Author: Alban Browaeys <firstname.lastname@example.org>
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]
Reviewed-by: Eric Anholt <email@example.com>
NOTE: This is a candidate for release branches.