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
Created attachment 7078 [details]
Created attachment 7079 [details]
glxgears rendering on border
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.
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.
Forgot to say that you need to remove this in r300_cmdbuf.c in drm.
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.
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:
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.
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 ...
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?
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
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
I will gladly do any testing needed.
I'll also help with testing - give me test programms and info you need and I try to provide it.
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?
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
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
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.
(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).
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?
Ok - I'll close this bug as WONTFIX and open an new report against mesa to enable private backbuffers.
on Feb 25, 2017 at 13:34:18.
(provided by the Example extension).