Well it'snt as easy as that. I think that what ever is the pitch (8192 is hw limit
on r300/r400 hw i think) the rendering will be broken above 2650 pixels so to
work around this you would have to allocate several small render buffer and then
blit then in a bigger one (pitch now becoming the upper limit).

I haven't time to checkout that render if broken what ever we do above 2650, to
check this disable cliprect and clip things in drm at top of r300_cmd.c and try
with a big enough window if things appear properly above 2650 then we might have
somethings but this would imply a security risk at it would mean we need to 
disable clipping which we would hate to do.

Private render buffer are needed if we want to have the split solution but i think
this should be done in a driver independent way.

As a side note iirc fglrx is broken too and can't render above 2650.

(In reply to comment #1)
> Well it'snt as easy as that. I think that what ever is the pitch (8192 is hw
> limit
> on r300/r400 hw i think) the rendering will be broken above 2650 pixels so to
> work around this you would have to allocate several small render buffer and
> then
> blit then in a bigger one (pitch now becoming the upper limit).
If you really have private render buffers, those will be as big as needed and not bigger, so pitch shouldn't be above 2560 (I think this was the correct number?) if your rendering area (I assume this really means the size of your window in which 3d rendering happens) isn't larger. Blitter can copy to the larger real framebuffer just fine (up to 8k).

With the upcoming DRI2 rework, every driver will use private renderbuffers, and doing it before then isn't very practical.

(In reply to comment #2)

> If you really have private render buffers, those will be as big as needed and
> not bigger, so pitch shouldn't be above 2560 (I think this was the correct
> number?) if your rendering area (I assume this really means the size of your
> window in which 3d rendering happens) isn't larger. Blitter can copy to the
> larger real framebuffer just fine (up to 8k).
> 

If you want compiz on dual 23" screen you need a viewport bigger than 2560
(at least from 23" native resolution 1920*2=3840) so the rendering area is
bigger than 2560.

Anyway after thinking a bit to that, the work around might be easier.
Basicly you have your big private 3840*1200 render buffer (2x23" case)
then you do rendering to first 2560*1200 (set pitch to 3840) then add
add a screen translation of -2560 to rendering command and a clip above
3840 and finaly do rendering but add 2560 to render buffer offset.
This should work. It needs to be tested but i believe this should work
properly. Drawback of this solution is that it's specific to radeon
and might not work with other hw.

The common solution would be to split the viewport in tile no bigger
than hw reported limit and ask a blitter to blit to the final buffer.
This is based on the assumption that 3d max pitch < 2d max pitch which
might not be the case on all cards. Anyway we can't work around the
maximum 2d hw pitch (maximum scan out buffer pitch).

So i got mixed feeling on this, especially as working around glviewport
limit isn't enough for the biggest user i see (compiz) as you also
need to work around 2d texture size limit and working around this one
sounds really tricky.

Closing as FIXED, to the extent that it can be fixed. :3