Bugzilla – Bug 135708
FireGL: 3D/Xgl issues with big-desktop [was] Problem with ATI FireGL X1 and SaX2
Last modified: 2007-01-16 19:32:18 UTC
I have an ATI Fire GL X1 and two 1600x1200 LCD displays. I'm trying to run in Xinerama, or BigDesktop mode. Based on these instructions: http://www.suse.de/~sndirsch/ati-installer-HOWTO.html I did the following: # sh ati-driver-installer-8.19.10-i386.run --buildpkg SuSE/SUSE101-IA32 # rpm -Uvh fglrx_6_9_0_SUSE101-8.19.10-1.i386.rpm # sax2 -r -m 0=fglrx -b /usr/share/doc/packages/fglrx/sax2-profile I see this output, but SaX does not start: SaX: initializing please wait... SaX: your current configuration will not be read in SaX: no X-Server is running SaX: will start own server if needed SPP: prepare device [0] profile: FireGL SPP: calling device [0] profile script: Radeon_DualHead_DriverOptions SPP: prepare device [0] profile: Radeon_DualHead_DriverOptions SPP: including prepared profile(s)... ServerLayput -> all -> Screen -> 0 -> top = ^ line <6>: syntax error: invalid KEY in LValue specification or invalid assignment: expected LValue=RValue with L Value=KEY sequence and RValue=STRING ServerLayout -> all -> Screen -> 0 -> bottom = ^ line <7>: syntax error: invalid KEY in LValue specification or invalid assignment: expected LValue=RValue with L Value=KEY sequence and RValue=STRING ServerLayout -> all -> Screen -> 0 -> left = ^ line <8>: syntax error: invalid KEY in LValue specification or invalid assignment: expected LValue=RValue with L Value=KEY sequence and RValue=STRING ServerLayout -> all -> Screen -> 0 -> right = ^ line <9>: syntax error: invalid KEY in LValue specification or invalid assignment: expected LValue=RValue with L Value=KEY sequence and RValue=STRING SPP: prepare device [0] profile: sax2-profile SPP: profile will add new section(s) -> moving: 1 SPP: including prepared profile(s)... SaX: startup
Could you also attach /var/log/SaX.log? Thanks.
Created attachment 58880 [details] SaX.log
# Single Head profile for ATI ("fglrx") driver # -------------------------------------------- # # Usage: sax2 -m 0=fglrx -b /usr/share/doc/packages/fglrx/sax2-profile # # Use the "fglrxconfig" program for setting up a Multihead # configuration with the ATI ("fglrx") driver. # Remove device/desktop for Screen 1, which might have been applied by # the Radeon Multihead profile before. Needs to be done, since we # don't want to create a configuration mix with radeon/fglrx drivers, # which simply doesn't work. Device -> [X+1] = [REMOVE] Screen -> [X+1] = [REMOVE] Monitor -> [X+1] = [REMOVE] ServerLayout -> all -> Screen -> 1 = [REMOVE] ServerLayput -> all -> Screen -> 0 -> top = ServerLayout -> all -> Screen -> 0 -> bottom = ServerLayout -> all -> Screen -> 0 -> left = ServerLayout -> all -> Screen -> 0 -> right = Screen->[X]->DefaultDepth = 24 Module->[X]->Load = dbe,type1,freetype,extmod,glx,v4l,dri Device->[X]->Raw->11->Option = "UseInternalAGPGART" "no" Device->[X]->Raw->12->Option = "mtrr" "off" Device->[X]->Raw->13->Option = "VideoOverlay" "on" Device->[X]->Raw->14->Option = "OpenGLOverlay" "off"
> ServerLayput -> all -> Screen -> 0 -> top = > ServerLayout -> all -> Screen -> 0 -> bottom = > ServerLayout -> all -> Screen -> 0 -> left = > ServerLayout -> all -> Screen -> 0 -> right = Looks strange. I wonder if I did sth. stupid. Marcus?
The new parser does not allow setting empty values. That's why it complains. The currently used FireGL profile doesn't include such settings ?
Correct. But FGLRX_SingleHead still does. I'm not sure if sax2-profile is still required for the new SaX2 in 10.1. Probably not. I can adjust the documentation. What would be the correct profile for Bart?
I would like to remove the FGLRX_SingleHead profile because I think it is useless. We are using a dynamic Radeon profile as driver profile. The profile will check if the fglrx driver is installed and if yes it will be used. Additionally the GUI provides the possibility to activate the MergedFB (big display) mode. So all you need to do with the new version is: install fglrx driver call sax2 -r hopefully :-)) Please refer to the following FTP URL to get the latest version: ftp://ftp.berlios.de/pub/sax/head-build/suse-10.1/ if you don't mind drop me a note if it works for you Thanks
In case your chipset is not yet known by SaX2 you need to use sax2 -m 0=fglrx
I've fixed the documentation (README.SUSE) now for the next ATI driver release. Marcus will remove the FGLRX_SingleHead profile. Assuming as fixed.
I keep hearing about this "MergedFB" mode, but have yet to see any evidence of it. Sax only lets me choose between clone or xinerama. Xinerama is not compatible with 3d accelleration, from what I understand. How do I use MergedFB so that I can have 3d with dual heads?
"Xinerama" via MergedFB *does* support 3D acceleration. AFAIK SaX2 no longer supports non-mergedfb "Xinerama" modes.
Oh. Xinerama _is_ MergedFB. OK. I tried both 'sax2 -r' and 'sax2 -m 0=fglrx'. I select Xinerama, and check "Enable 3d". I do get a working 2d Xinerama, but no 3d. The fglrx kernel mod is loaded, and I am able to get a semi-working dual head, 3d config file with fglrxconfig. Any idea how to get 3d working?
Created attachment 59007 [details] Sax generated config file
Created attachment 59008 [details] config file generated with fglrxconfig 3d almost works with this config. If I run glxgears, I get a blank square window. If I stretch this window horizontally a lot, I finally see the gears in the far left of the stretched window.
#12/13: You need to disable Composite. DRI is disabled by the fglrx driver when Composite is enabled. #14: we cannot fix any ATI driver bugs. 3D in Xinerama/MergedFB mode with fglrx driver works on my X850 XT board.
Created attachment 59019 [details] glxgears With composite disabled, 3d sort of works. This is what glxgears looks like. Note that the gears are not actually in the visible window.
Created attachment 59020 [details] gears, stretched. If I stretch the window, the gears appear on the far left.
Created attachment 59021 [details] Similarly, fgl_glxgears is not centered in the window.
Created attachment 59022 [details] stretched fgl_glxgears But when stretched, the fgl_glxgears also appear on the far left. This makes 3d apps quite unusable. I think this is related to Xinerama. With single head this problem goes away. Any ideas?
For future reference, the solution is to add Option "EnablePrivateBackZ" "yes" to the device section. I found this here: http://gentoo-wiki.com/HOWTO_Dual_Monitors#ATI_Big_Desktop.2C_Xinerama.2C_ATI-drivers_and_DRI
Now just one more problem. 3d only works as root. As a non-root user, I see libGL error: failed to open DRM: Operation not permitted libGL error: reverting to (slow) indirect rendering I fixed this with 'chmod og+rw /dev/dri/card0' Is this the proper fix?
Marcus, could you add Option "EnablePrivateBackZ" "yes" to FireGL profile, please? > I fixed this with 'chmod og+rw /dev/dri/card0' > Is this the proper fix? The right fix is to add the user to the video group. This is documented since several years in our administration manual (3D chapter), but I no longer believe that anyone has ever read this chapter.
What's wrong with giving non-root users access to /dev/dri/card0 by default (at least on non-server installs)?
Marcus, see comment #23.
Thanks, I fixed it: - do not activate composite on fglrx - include option EnablePrivateBackZ please check out the new version from here: ftp://ftp.berlios.de/pub/sax/head-build/suse-10.1/ Regards Marcus
I also noticed that there are several options that are duplicated in the Device section (See attachment in #13). "UseFastTLS" for example, and some others as well. Probably not a big deal, but could use some cleanup.
yes I know this has been fixed as well today :-) you can check that by testing the packages from the given FTP location
The packages from the URL in #27 work nicely, generating a working xorg.conf for dual head +3d.... nice. :) Thanks.
WRT comment #23, adding the user to the video group does not work. It seems like it should: # ls -l crw-rw---- 1 root video 226, 0 Nov 30 11:38 card0 # grep bart /etc/group video:x:33:bart And yet, the 'bart' user cannot do 3d until I do 'chmod og+rw card0'
Verifiy that the user already belongs to the group video with "id". You might need to relogin.
id says I am in the video group. Sometimes it works, sometimes it needs a 'chmod og+rw card0'. Probably a bug in the proprietary driver.
> Sometimes it works, sometimes it needs a 'chmod og+rw card0'. Never heard of such a problem.
Due to bug #159343, Option "EnablePrivateBackZ" "yes" was removed from xorg.conf for ATI cards. This means that 3d no longer works on my FireGL X1 dual DVI system. Please put Option "EnablePrivateBackZ" "yes" back and fix Xgl to work with Option "EnablePrivateBackZ" "yes"
> Please put > Option "EnablePrivateBackZ" "yes" Needs to be fixed in the ATI driver. > back and fix Xgl to work with > Option "EnablePrivateBackZ" "yes" No.
> > Please put > > Option "EnablePrivateBackZ" "yes" > Needs to be fixed in the ATI driver. Just to make sure. I didn't suggest to make it the default for the driver. This will break Xgl again ...
Just to clarify, the problem is that without the Option "EnablePrivateBackZ" "yes" All 3d apps look like comment #16, comment #17, comment #18, and comment #19. When first launched, the window is empty. The app window needs to be stretched horizontally a great deal for the real 3d app to appear. Initially it is to the left -- outside the app window. Adding Option "EnablePrivateBackZ" "yes" fixes this problem, but apparently breaks Xgl.
This problem is still present in SLED-10-Beta10 with the new 8.24.8 fglrx driver. I still have to add Option "EnablePrivateBackZ" "yes"
ATI: any progress on your side?
Bart, could you test again with 8.26.18? If this doesn't help, contact me for a beta driver. Thanks.
8.26.18 still requires EnablePrivateBackZ = "yes"
I've changed the subject as this bug has mutated. If I understand it correctly we currently need EnablePrivateBackZ to get 3D to work with dual head. On the other hand this option doesn't work with Xgl. Xgl without 3D support is not a solution either. Therefore for now we should enable this option for MergedFB and disable it for all other cases. It needs to be found out why MergedFB requires this option and if the driver can be fixed to not require it. Anatoli: Is ATi able to reproduce the problem? Matthias: Do you know why this option does not work in connection with Xgl?
I don't think this are questions for Bart ...
To the best of my knowledge only Bart needs EnablePrivateBackZ. There seem to be some guys outside of Novell having the same issue, but other than that fglrx seems to work fine w/o even in Multihead environments. IMHO in the current state we should *not* enable PrivateBackZ in any case.
> To the best of my knowledge only Bart needs EnablePrivateBackZ. d'oh! Really? Are others running dual DVI, and they don't have this problem? Is it specific to my card perhaps?
I will add some comments on this. Changing title to use the ATI specific term. The systems affected are the R3xx and R4xx family of products (FireGL X,Z series, certain FireGL v series, Radeon 9x00, Radeon Xy00, if and only if you are using a combined desktop larger than 2560 pixels in any dimensions. This is a current driver limitation. This only affects big-desktop and does not affect true dual head. This will also affect XGL. EnablePrivateBackZ alleviates part of the problem by masking the 'offset' issue. You still will have rendering stopping at the 2560 pixel mark. This may be a sufficient workaround for the moment - I use it on my Mobility FireGL V3200. X1k products and the remaining FireGL products do not have this limitation. Bart, can you try 1280x1024 on both screens and report if the problem still exists?
Matthew, thank you for pointing this out! Your statement explains why we don't see this problem more often. As 2560 is a bit unusual for a hardware limitation (no power of 2), I didn't think of this. It doesn't explain why we have troubles running Xgl with EnablePrivateBackZ, but that is a different topic.
> Bart, can you try 1280x1024 on both screens and report if the problem still > exists? Bart, could you retest, also with a current driver release (8.33.6)?
I'm running 8.33.6. If I set up 1280x1024 on both screens, 3d works without the EnablePrivateBackZ option. I did not go so far as to test Xgl, but fgl_glxgears runs fine on all parts of the desktop without EnablePrivateBackZ. With 1600x1200 on both screens, EnablePrivateBackZ is still required for 3d to work, and the 2560 pixel limitation is still present.
Ok. As Matthew explained in Comment #49 this issue is a hardware implementation. Closing as WONTFIX.