Bug 8357 - Rendering with r300 right of 2650px width is disstorted
Summary: Rendering with r300 right of 2650px width is disstorted
Status: RESOLVED WONTFIX
Alias: None
Product: DRI
Classification: Unclassified
Component: General (show other bugs)
Version: XOrg git
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-19 11:56 UTC by Matthias Bläsing
Modified: 2008-01-16 08:24 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
blender_rendering (420.71 KB, image/png)
2006-09-19 11:58 UTC, Matthias Bläsing
no flags Details
glxgears rendering on border (20.49 KB, image/png)
2006-09-19 11:59 UTC, Matthias Bläsing
no flags Details

Description Matthias Bläsing 2006-09-19 11:56:50 UTC
I run a dualhead setup with a desktop of 3080x1050 (thats the biggest setup, I
run also smaller setups).

This is the card in the notebook:
ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]

In Bug 8299 i mentioned, that the rendering of blender is disstored (see first
attachment). It can easily be reproduced when runnig glxgears - just move it
over or onto the invisible border (see second attachment).

Aapo Tahkola gives in comment #10 of Bug 8299 some hints which might be good
starting points.
Comment 1 Matthias Bläsing 2006-09-19 11:58:45 UTC
Created attachment 7078 [details]
blender_rendering
Comment 2 Matthias Bläsing 2006-09-19 11:59:26 UTC
Created attachment 7079 [details]
glxgears rendering on border
Comment 3 Stanislovas Mickus 2007-10-01 11:40:53 UTC
Hello,
I would like to solve this problem. Although I'm not experienced in 3D drivers and xorg server programming, I'm willing to invest time to solve it.
I need assistance and information on what needs to be done to accomplish this. I read various thoughts about solutions. 
One of them is mentioned in a link above. That is, playing with cliprects and radeon registers (R300_SE_VPORT_XOFFSET,R300_SE_VPORT_YOFFSET, R300_RB3D_COLOROFFSET0, R300_RB3D_DEPTHOFFSET).
Other idea is splitting 3d context into more contexts and offsetting them with RE_TOP_LEFT register if its possible.
It would be nice to here opinion of people who have some knowledge on this topic.

Thanks
Comment 4 Jerome Glisse 2007-10-02 08:15:35 UTC
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.
Comment 5 Jerome Glisse 2007-10-02 08:16:08 UTC
Forgot to say that you need to remove this in r300_cmdbuf.c in drm.
Comment 6 Jerome Glisse 2007-10-02 08:27:14 UTC
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.
Comment 7 Stanislovas Mickus 2007-10-03 12:34:31 UTC
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@lists.sourceforge.net/msg11469.html

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.
Comment 8 Jerome Glisse 2007-10-04 08:01:00 UTC
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 ...
Comment 9 Stanislovas Mickus 2007-10-05 10:53:15 UTC
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 Stanislovas Mickus 2007-10-19 06:31:50 UTC
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
Comment 11 Jerome Glisse 2007-10-22 04:47:37 UTC
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.
Comment 12 Stanislovas Mickus 2007-10-23 03:12:04 UTC
I will gladly do any testing needed.
Comment 13 Matthias Bläsing 2007-11-07 12:52:13 UTC
I'll also help with testing - give me test programms and info you need and I try to provide it.
Comment 14 Matthias Bläsing 2007-12-13 12:09:39 UTC
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?
Comment 15 Jerome Glisse 2007-12-14 03:32:39 UTC
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.
Comment 16 Matthias Bläsing 2007-12-26 07:48:52 UTC
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.
Comment 17 Roland Scheidegger 2007-12-28 13:04:40 UTC
(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).

Comment 18 Matthias Bläsing 2008-01-07 05:02:59 UTC
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?
Comment 19 Matthias Bläsing 2008-01-16 08:24:37 UTC
Ok - I'll close this bug as WONTFIX and open an new report against mesa to enable  private backbuffers.


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.