Bug 4254 - DRI and mergedfb doesn't work together like they should.
Summary: DRI and mergedfb doesn't work together like they should.
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-26 04:08 UTC by Samuli Suominen
Modified: 2007-02-22 14:27 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Samuli Suominen 2005-08-26 04:08:45 UTC
Seems like you can't use Direct Rendering at same time with mergedfb 2560x1024 
dualhead, since even "man radeon" says "The maximum framebuffer size that the 3D
engine can handle is 2048x2048."

But the fact is, I can do 3D on 2560x1024 on 9200 Pro card but First Monitor
gets all blurry like it was 60hz and is going to explode at any time. What I 
expected, of course, is 3D not to work in part of area.. and 2D would still
be good. With 2048x768 it's all good.

So, I played around and switched my cables around and did: Option 
"MergedXineramaCRT2IsScreen0" "true" and I got what I expected.. 3D in
2048 area, and part of screen works only as 2D. But now, the area where
3D is not working.. is in _first_ display and that just.. doesn't work.

DRI at full area + mergedfb + 2048x768 = works
DRI at full area + mergedfb + 2560x1024 = works, but first display gets blurry
DRI only at 2048 + mergedfb + 2560x1024 = works, but only with 
MergedXineramaCRT2IsScreen0 (and cables flipped around), and then the part where 
3D doesn't work is in primary display.. that doesn't work for me, and probably 
not for anyone.

I'm using 9200 Pro card, on X.org 7.0rc0, Mesa 6.3.2+CVS, DRM CVS, Linux 2.6.13-
rc7, Gentoo, 32bit system..
Comment 1 Alex Deucher 2005-08-26 06:04:37 UTC
(In reply to comment #0)
> Seems like you can't use Direct Rendering at same time with mergedfb 2560x1024 
> dualhead, since even "man radeon" says "The maximum framebuffer size that the 3D
> engine can handle is 2048x2048."
> 
> But the fact is, I can do 3D on 2560x1024 on 9200 Pro card but First Monitor
> gets all blurry like it was 60hz and is going to explode at any time. What I 
> expected, of course, is 3D not to work in part of area.. and 2D would still
> be good. With 2048x768 it's all good.

I suspect this is a bandwidth issue.  2560x1024 coupled with 3D operations is a
lot of data to push.  You might try setting the "displaypriority" option to "HIGH".

> 
> So, I played around and switched my cables around and did: Option 
> "MergedXineramaCRT2IsScreen0" "true" and I got what I expected.. 3D in
> 2048 area, and part of screen works only as 2D. But now, the area where
> 3D is not working.. is in _first_ display and that just.. doesn't work.
> 
> DRI at full area + mergedfb + 2048x768 = works
> DRI at full area + mergedfb + 2560x1024 = works, but first display gets blurry
> DRI only at 2048 + mergedfb + 2560x1024 = works, but only with 
> MergedXineramaCRT2IsScreen0 (and cables flipped around), and then the part where 
> 3D doesn't work is in primary display.. that doesn't work for me, and probably 
> not for anyone.
> 

MergedXineramaCRT2IsScreen0 just switches which screen is advertised as "screen
0" by the builtin pseudo-xinerama extension.  It doesn't actually change the
orientation of the crtcs.  You probably don't want that option.  If you want to
reverse the heads, you should change the "CRT2Position" option between "RightOf"
or "LeftOf" (or "Above" and "Below" depending on your set up).  Try that and I
supect you will get what you want.

> I'm using 9200 Pro card, on X.org 7.0rc0, Mesa 6.3.2+CVS, DRM CVS, Linux 2.6.13-
> rc7, Gentoo, 32bit system..
Comment 2 Samuli Suominen 2005-08-26 11:50:05 UTC
> I suspect this is a bandwidth issue.  2560x1024 coupled with 3D operations is 
> a lot of data to push.  You might try setting the "displaypriority" option to 
> "HIGH".

I've tried BIOS and HIGH.. unfortunately nothing changed.

> MergedXineramaCRT2IsScreen0 just switches which screen is advertised as 
> "screen 0" by the builtin pseudo-xinerama extension.  It doesn't actually 
> change the orientation of the crtcs.  You probably don't want that option. 

True, but i've just noticed it helped while experimenting with Options.

> If you want to reverse the heads, you should change the "CRT2Position" option 
> between "RightOf" or "LeftOf" (or "Above" and "Below" depending on your set 
> up).  Try that and I supect you will get what you want.

Yes, i'm using that kind of setup. 

Section "Device"
    Identifier                            "r200"
    Driver                                "radeon"
    Option "AGPMode"                      "8" # tried also dropping to 4.
    Option "BusType"                      "AGP" # correct.
    Option "EnablePageFlip"               "on" # tried also without this.
    Option "MonitorLayout"                "CRT, CRT" # they are both CRTs.
    Option "MergedFB"                     "true"
    Option "CRT2HSync"                    "24-64" # these are 100% correct.
    Option "CRT2VRefresh"                 "47-105"
    Option "CRT2Position"                 "LeftOf" # like you suggested.
    Option "MetaModes"                    "1024x768-1024x768"
    BusID  "PCI:1:0:0"
    Screen 0
EndSection

But if I do 1280x1024-1280x1024 it does that.. blurry on CRT1.
Comment 3 Samuli Suominen 2005-08-27 09:14:41 UTC
Ok, I tested with Option NonRectangular combination of 1280x1024 and 640x480
so that total amount of size is only 1720x1024 and it's still blurry. I don't
get this at all, I can't use 1280x1024 at my first monitor at all same time with
DRI,
without image getting messed up. Since my information have been so scrambled,
I'd just better close this bug and get another pair of monitors to test with..
so this won't take anyone elses time? I'm clueless.
Comment 4 Bill Crawford 2005-09-03 09:01:36 UTC
Just out of curiosity, would there be any way to merge framebuffers vertically
(to fit e.g. a 1600x1200 and a 1024x768 within the 2048 square limit for the 3d
accel engine) but still have the mouse behave like they're side by side?
Comment 5 Alex Deucher 2005-09-03 15:32:05 UTC
(In reply to comment #4)
> Just out of curiosity, would there be any way to merge framebuffers vertically
> (to fit e.g. a 1600x1200 and a 1024x768 within the 2048 square limit for the 3d
> accel engine) but still have the mouse behave like they're side by side?

Not really.  The whole reason mergedfb works is because it's one big
framebuffer.  if you switched it around like that it would be basically
equivalent to regular multi-head.  You have to adjust the drawing engine and
screen offsets to make it work as if the screens were side by side, in which
case you wouldn't really have one big framebuffer anymore.
Comment 6 Olav Reinert 2006-06-08 10:30:20 UTC
(In reply to comment #3)
> Ok, I tested with Option NonRectangular combination of 1280x1024 and 640x480
> so that total amount of size is only 1720x1024 and it's still blurry. I don't
> get this at all, I can't use 1280x1024 at my first monitor at all same time
> with DRI, without image getting messed up.

I have used radeon MergedFB without problems for a long time under SUSE 10.0 
(X.org < 6.8.2). My graphics card is a RADEON 9200 SE with a 1600x1200 monitor 
on a DVI output (primary) and a 1280x1024 monitor on a VGA output (secondary).

When I upgraded to SUSE 10.1 (X.org 6.9.0) MergedFB was broken, with similar 
symptoms to this bug report (blurry image on secondary / VGA output). Not only 
was the secondary image blurred, it was also the wrong resolution, like a 
deformed clone of 
Comment 7 Olav Reinert 2006-06-08 10:40:07 UTC
(In reply to comment #3)
> Ok, I tested with Option NonRectangular combination of 1280x1024 and 640x480
> so that total amount of size is only 1720x1024 and it's still blurry. I don't
> get this at all, I can't use 1280x1024 at my first monitor at all same time
> with DRI, without image getting messed up.

I have used radeon MergedFB without problems for a long time under SUSE 10.0 
(X.org < 6.8.2). My graphics card is a RADEON 9200 SE with a 1600x1200 monitor 
on a DVI output (primary) and a 1280x1024 monitor on a VGA output (secondary). 
Hence, virtual X resolution is set to 2880x1200.

When I upgraded to SUSE 10.1 (X.org 6.9.0) MergedFB was broken, with similar 
symptoms to this bug report (blurry image on secondary / VGA output). Not only 
was the secondary image blurred, it was also the wrong resolution, like a 
deformed clone of the primary output.

I found a workaround: Define Option "MetaModes" "1600x1200 
1600x1200-1280x1024", and when the X server starts press (CTRL ALT Keypad+) to 
switch to the next resolution, and everything is fine. Somehow X fails to 
initialise the VGA output properly, I think.

Similarly, when switching to a virtual terminal (e.g., CTRL ALT F2) and back to 
X (CTRL ALT F7), the secondary video output is also blurred. Pressing (CTRL ALT 
Keypad-) and (CTRL ALT Keypad+) brings the display back to normal.

(PS: DRI output seems to work fine in this setup, glxgears reports about 1300 
FPS. When the window with the gears is dragged to the right beyond ca. 2/3 of 
the horizontal desktop area, they disappear, consistent with the 2048x2048 
limit on 3D rendering. Dragging the window back left brings the gears back.)
Comment 8 Timo Jyrinki 2007-02-22 14:27:46 UTC
Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status.

Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.


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.