Direct Rendering Infrastructure

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #4 from glisse@...  2007-10-02 08:15 PST -------
I believe r300 should be able to do 3d rendering in buffer with width up
to 4096. To test this please remove all "+ R300_CLIPRECT_OFFSET" which
should help and fix problem you see. Please report if so.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #5 from glisse@...  2007-10-02 08:16 PST -------
Forgot to say that you need to remove this in r300_cmdbuf.c in drm.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #6 from glisse@...  2007-10-02 08:27 PST -------
After plugin hw and testing myself rendering doesn't work properly without this 
offset. Investigation on why this is needed would help to remove this and so
move the limit to 4096.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #7 from smickus@...  2007-10-03 12:34 PST -------
AFAIK there's hardware limitation for opengl context, viewport to the
framebuffer is up to 2560x2560 for r300 family. Is saw that discussed in
various places, for example:
http://www.mail-archive.com/dri-devel@...>

AFAICT, R300_CLIPRECT_OFFSET is needed because top left corner of framebuffer
is at (1440, 1440) as described in r300_reg.h file.

So I think it's not a solution or am I wrong.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #8 from glisse@...  2007-10-04 08:01 PST -------
I believe this 2560 limitation come from cliprect offset a 1440 and
according to ATI driver viewport should be able to reach 4096x4096 on
r300/r400, so this 1440 offset is likely due to somethings that we
don't want. Getting rid of this 1440 offset should enable us to render
up to 4096x4096 which will be enought for most (all) people.

Then if you want to go above this limitation you will need to
implement heavy change in mesa/xserver/drm/dri ...


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #9 from smickus@...  2007-10-05 10:53 PST -------
It looks like you are right, becouse I could get opengl working up to ~2650
pixels.
So anyone knows why we need this magic with R300_CLIPRECT_OFFSET in
r300_cmdbuf.c in drm?


------- Comment #10 from smickus@...  2007-10-19 06:31 PST -------
Thanks for holp, but with my limited knowledge about inner workings of r300 drm
module I failed to solve problem with R300_CLIPRECT_OFFSET and cliprect,
scissoring working. So without any further help I'm not able to solve this
problem. I hope someone else will step in with more knowledge and will solve
this limitation in the future. Thanks


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #11 from glisse@...  2007-10-22 04:47 PST -------
This need a bit of RE or testing, i will try to upload a test program
so others can play with that and try to find out why this offset is
needed.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #12 from smickus@...  2007-10-23 03:12 PST -------
I will gladly do any testing needed.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #13 from mblaesing@...  2007-11-07 12:52 PST -------
I'll also help with testing - give me test programms and info you need and I
try to provide it.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #14 from mblaesing@...  2007-12-13 12:09 PST -------
Another idea, when seeing the current development towards a zaphod branch of
the x.org driver. There we get two head, that work - as far as I understand -
more or less independend from each other. So will there be a seperate limit (
per head or is there only 3d acceleration on one of the heads?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #15 from glisse@...  2007-12-14 03:32 PST -------
After investigation this 2650 limit is hw (tried with fglrx which got
same symptom) so there is no easy way to work around it. I will likely
close this bug as won't fix.

For reference the solution would be to break rendering into several pass
ie tile the rendering buffer to follow 2650 limit. Such solution is hard
and painfull (from a quick overview) to implement with current mesa
infrastructure.

Other solution is that user like compiz broke rendering in small tile
which support hw rendering limit but this would require a massive change
to compiz and likely need to rewrite all plugin.

I will change the reported viewport size in coming day to reflect this
hw limit.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #16 from mblaesing@...  2007-12-26 07:48 PST -------
I'm not sure whether I understand this correctly. If it would be just a matter
of multiple tiles to be rendered, then I don't understand, why the glxgears
application does not work behind the magical barrier. I would already be happy,
if each 3D application could be as large as 1680x1050 and your explanation
sounds as if this should be the case. But it isn't, as you can see in the
rendering of glxgears on the barrier.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #17 from sroland@...  2007-12-28 13:04 PST -------
(In reply to comment #16)
> I would already be happy,
> if each 3D application could be as large as 1680x1050 and your explanation
> sounds as if this should be the case. But it isn't, as you can see in the
> rendering of glxgears on the barrier.
I haven't looked at this for r300, but this should work if/when the driver will
use private backbuffers (since currently with the shared backbuffer the
backbuffer always has the same size as the full framebuffer).


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=8357





------- Comment #18 from mblaesing@...  2008-01-07 05:02 PST -------
A question remains: Is the r300 mesa/dri driver responsible for using private
backbuffers or the ddx? If the former is true, then - should I close this bug
and open another one for this specific problem or should I change the title of
the bug, so that it better reflects the now current problem?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.freedesktop.org/show_bug.cgi?id=3D8357


Matthias Bl=C3=A4sing <mblaesing@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




--- Comment #19 from Matthias Bl=C3=A4sing <mblaesing@...>  2008-01-16 0=
8:24:37 PST ---
Ok - I'll close this bug as WONTFIX and open an new report against mesa to
enable  private backbuffers.


--=20
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the assignee for the bug.=