ATI graphics acceleration [SOLVED]

[eman_resu]

I have a ATI Radeon Mobility M6 or something. It's a Dell Latitude C610. My card is not supported by the drivers on the "Howto for fglrx" thread. At least I don't think so. I'm trying to get games to work. I checked if I have direct rendering:

glxinfo | grep direct
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
OpenGL renderer string: Mesa GLX Indirect


I've searched Google for video in linux on a Latitude C610 and found this from an Ubuntu forum: "if im not mistaken, fglrx doesnt work with ati mobility 9000 m6 ly - so heres my xorg ( i have the same laptop as you ) just change module part and device part (the part with identifier: ati etc etc) and u should have some hardware acceleration. once u change your /etc/X11/xorg.conf type glxinfo | grep direct and see if it says direct rendering: yes.
if it says yes u should have decent 3d hardware acceleration, however, for much better perfomance you should install the dri files from the dri website. i messed up my laptop trying so im satisfied for now."

http://ubuntuforums.org/showthread.php?t=80723

I'm not sure if I should try this. It's from 2005 so I don't know if there's a better way of doing this now. Also, I don't know what he's talking about with dri, so any help with that would be appreciated, if I actually need to do that.

I guess I should post my xorg.conf?

# Xorg configuration created by pyxf86config

Section "ServerLayout"
Identifier "Default Layout"
Screen 0 "Screen0" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Synaptics" "CorePointer"
EndSection

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "us+inet"
EndSection

Section "InputDevice"
Identifier "Synaptics"
Driver "synaptics"
Option "Device" "/dev/input/mice"
Option "Protocol" "auto-dev"
Option "Emulate3Buttons" "yes"
Option "SHMConfig" "on"
EndSection

Section "Device"
Identifier "Videocard0"
Driver "radeon"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection


Thanks for any help.

[Hlingler]

It does certainly look like your chipset/card is not supported by the proprietary ATI driver. DRI="Direct Rendering Infrastructure" meaning 3D/hardware-accelerated graphical rendering protocol. See WikiPedia for the gory technical details. Also, open a terminal and type/read:
man ati
And:
man radeon
'man radeon' seems to suggest that it is (or might be):SUPPORTED HARDWARE
The radeon driver supports PCI and AGP video cards based on the following ATI chips
R100 Radeon 7200
RV100 Radeon 7000(VE), M6, RN50/ES1000To find out exactly what chipset/card you have, open a terminal and become root user, then command:
lspci -v
Look for the group of entries flagged "VGA" and post results, just the relevant chipset/card identifier if you can find it, attach the whole output if you can't.

If you changed that 'Driver' line in your xorg.conf, I'm pretty sure that this is wrong. Driver "ati" is actually a driver "wrapper" for all ATI chipsets/cards that will auto-probe the hardware and load the appropriate 2D and 3D drivers and the driver kernel module. I'm not sure from looking at the DRI documentation whether or not your chipset/card is supported: http://dri.freedesktop.org/wiki/ATIRadeon. But you also must have xorg.conf set up correctly.

Try the following:
> In xorg.conf, replace "radeon" with "ati"
> Determine your available video RAM (VRAM):cat /var/log/Xorg.0.log|grep -i ramOr if that fails to reveal it:cat /var/log/Xorg.0.log|grep -i memoryPost results. Your maximum screen resolution and color depth will be determined accordingly. You almost certainly need the 24 bpp color depth for games and other goodies, so you might need to reduce your default screen resolution - we'll see when we know how much VRAM is available.

> As an example, here's my xorg.conf for an ATI Rage Pro Turbo AGP 2X:Section "ServerLayout"
Identifier "single head configuration"
Screen 0 "Screen0" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
EndSection

Section "Files"
ModulePath "/usr/lib/xorg/modules"
ModulePath "/usr/lib/xorg/modules/drivers"
ModulePath "/usr/lib/xorg/modules/extensions"
ModulePath "/usr/lib/xorg/modules/fonts"
ModulePath "/usr/lib/xorg/modules/input"
ModulePath "/usr/lib/xorg/modules/linux"
ModulePath "/usr/lib/xorg/modules/multimedia"
EndSection

Section "Module"
Load "extmod"
Load "dbe"
Load "glx"
Load "freetype"
Load "type1"
Load "record"
Load "dri"
Load "int10"
Load "ddc"
Load "vbe"
EndSection

Section "ServerFlags"
Option "AIGLX" "off"
Option "Xinerama" "0"
EndSection

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection

Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/input/mice"
EndSection

Section "Monitor"
Identifier "Monitor0"
Option "dpms"
EndSection

Section "Device"
Identifier "Videocard0"
Driver "ati"
Option "AGPMode" "2"
Option "AGPMem" "32768"
Option "HWCursor" "off"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
Monitor "Monitor0"
DefaultDepth 16
SubSection "Display"
Viewport 0 0
Depth 16
Modes "832x624" "800x600" "720x400" "640x480" "640x400" "640x350"
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
Modes "800x600"
EndSubSection
EndSection

Section "DRI"
Mode 0666
EndSection BACK UP your xorg.conf, then add/append/correct the sections in red to yours. Note that some of the other entries are specific to my setup (esp. color depth) so don't try to duplicate them....

> After doing all the above, logout of the desktop and re-start the X-server with the changes (ALT-CTL-Backspace). Login and check things out. If Xorg won't start, get to a virtual terminal (ALT-CTL-F[1-6] any F1 through F6 will do) and restore the backed-up xorg.conf then restartx.

> Attach or pastebin the entire contents of /var/log/Xorg.0.log after all of the above.

> If you end up getting this working, install package driconf to get a minimal GUI to use to setup whatever available options that card supports.

V

[Hlingler]

Yeah, I just double-checked, and I'm even more certain that 'Driver "radeon" ' is wrong. From 'man ati':DESCRIPTION
ati is an Xorg wrapper driver for ATI video cards. It autodetects whether your hardware has a Radeon, Rage 128, or Mach64 or earlier class
of chipset, and loads the radeon(4), r128(4), or mach64 driver as appropriate.

SUPPORTED HARDWARE
The ati driver supports Radeon, Rage 128, and Mach64 and earlier chipsets by loading those drivers. See those manpages for specific cards
supported.Package xorg-x11-drv-ati contains all the relevant 2D driver files:[vince@localhost ~]$ rpm -ql xorg-x11-drv-ati
/usr/lib/xorg/modules/drivers/ati_drv.so
/usr/lib/xorg/modules/drivers/mach64_drv.so
/usr/lib/xorg/modules/drivers/r128_drv.so
/usr/lib/xorg/modules/drivers/radeon_drv.so
/usr/lib/xorg/modules/multimedia/theatre200_drv.so
/usr/lib/xorg/modules/multimedia/theatre_detect_drv.so
/usr/lib/xorg/modules/multimedia/theatre_drv.so
/usr/share/doc/xorg-x11-drv-ati-6.8.0
/usr/share/doc/xorg-x11-drv-ati-6.8.0/README.ati
/usr/share/doc/xorg-x11-drv-ati-6.8.0/README.r128
/usr/share/hwdata/videoaliases/ati.xinf
/usr/share/hwdata/videoaliases/r128.xinf
/usr/share/hwdata/videoaliases/radeon.xinf
/usr/share/man/man4/ati.4.gz
/usr/share/man/man4/r128.4.gz
/usr/share/man/man4/radeon.4.gz
[vince@localhost ~]$There is no package 'xorg-x11-drv-radeon'. The 3D driver is part of package mesa-libGL:[vince@localhost ~]$ rpm -ql mesa-libGL
/usr/lib/dri
/usr/lib/dri/i810_dri.so
/usr/lib/dri/i915_dri.so
/usr/lib/dri/i915tex_dri.so
/usr/lib/dri/i965_dri.so
/usr/lib/dri/mach64_dri.so
/usr/lib/dri/mga_dri.so
/usr/lib/dri/r128_dri.so
/usr/lib/dri/r200_dri.so
/usr/lib/dri/r300_dri.so
/usr/lib/dri/radeon_dri.so
/usr/lib/dri/savage_dri.so
/usr/lib/dri/tdfx_dri.so
/usr/lib/dri/unichrome_dri.so
/usr/lib/libGL.so.1
/usr/lib/libGL.so.1.2
[vince@localhost ~]$And the kernel driver module comes with each kernel:[vince@localhost ~]$ ls -lh /lib/modules/2.6.24.5-85.fc8/kernel/drivers/char/drm/
total 708K
-rw-r--r-- 1 root root 82K 2008-04-19 13:15 drm.ko
-rw-r--r-- 1 root root 23K 2008-04-19 13:15 i810.ko
-rw-r--r-- 1 root root 29K 2008-04-19 13:15 i830.ko
-rw-r--r-- 1 root root 29K 2008-04-19 13:15 i915.ko
-rw-r--r-- 1 root root 65K 2008-04-19 13:15 mga.ko
-rw-r--r-- 1 root root 187K 2008-04-19 13:15 nouveau.ko
-rw-r--r-- 1 root root 45K 2008-04-19 13:15 r128.ko
-rw-r--r-- 1 root root 116K 2008-04-19 13:15 radeon.ko
-rw-r--r-- 1 root root 36K 2008-04-19 13:15 savage.ko
-rw-r--r-- 1 root root 12K 2008-04-19 13:15 sis.ko
-rw-r--r-- 1 root root 7.6K 2008-04-19 13:15 tdfx.ko
-rw-r--r-- 1 root root 42K 2008-04-19 13:15 via.ko
[vince@micron-pc-rb Sat May 10 22:10:39 ~]$Try the above steps, if your chipset/card is supported by the 3D driver, it's just a matter of getting/tweaking the right settings. If not....

V

[eman_resu]

I just changed the xorg.conf file like you said and am about to restart. I was just about to type that terminal says the lspci command wasn't found but I logged into root to save the xorg.conf changes and:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY (p
rog-if 00 [VGA controller])
Subsystem: Dell Unknown device 00e3
Flags: bus master, VGA palette snoop, stepping, 66MHz, medium devsel, la
tency 32, IRQ 11
Memory at e0000000 (32-bit, prefetchable) [size=128M]
I/O ports at c000 [size=256]
Memory at fcff0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
Kernel modules: radeonfb


Also:

cat /var/log/Xorg.0.log|grep -i ram
(**) RADEON(0): Depth 24, (--) framebuffer bpp 32
(--) RADEON(0): Linear framebuffer at 0x00000000e0000000
(II) RADEON(0): Detected total video RAM=16384K, accessible=65536K (PCI BAR=131072K)
(--) RADEON(0): Mapped VideoRAM: 16384 kByte (64 bit DDR SDRAM)
(II) RADEON(0): PLL parameters: rf=2700 rd=60 min=12000 max=35000; xclk=16600
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"(II) Module already built-in
(II) Initializing built-in extension XINERAMA


After the restart I'll attempt to figure out what your second post means. Also, how to I get the code to show up in the little boxes in the posts?

And thanks for your help.

[Hlingler]

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY (p
rog-if 00 [VGA controller])
Subsystem: Dell Unknown device 00e3
Flags: bus master, VGA palette snoop, stepping, 66MHz, medium devsel, la
tency 32, IRQ 11
Memory at e0000000 (32-bit, prefetchable) [size=128M]
I/O ports at c000 [size=256]
Memory at fcff0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
Kernel modules: radeonfbNow we know what chipset/card we're dealing with....cat /var/log/Xorg.0.log|grep -i ram
(**) RADEON(0): Depth 24, (--) framebuffer bpp 32
(--) RADEON(0): Linear framebuffer at 0x00000000e0000000
(II) RADEON(0): Detected total video RAM=16384K, accessible=65536K (PCI BAR=131072K)
(--) RADEON(0): Mapped VideoRAM: 16384 kByte (64 bit DDR SDRAM)
(II) RADEON(0): PLL parameters: rf=2700 rd=60 min=12000 max=35000; xclk=16600
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"(II) Module already built-in
(II) Initializing built-in extension XINERAMAAt 16 MB VRAM, you're going to be pushing this old hardware to get decent graphical performance, but I was able to get a 1024x768 @ 16 bpp desktop with an even older ATI Rage Pro AIW AGP 2X with only 8 MB VRAM, so you should be able to get 24 bpp at the same resolution. Again, DRI depends on whther or not the 3D driver supports that card....After the restart I'll attempt to figure out what your second post means. Also, how to I get the code to show up in the little boxes in the posts?Don't use the "Quick Post" box, use the "Quote" or "Reply Post" buttons to get the full VBulletin posting page with all the code/quote/url/font and other mark-up stuff.

[eman_resu]

Well, I'm in Windows now. I restarted and it won't go to the graphic login thing. It asks me my login and then password and then nothing. I can type stuff but I don't know what to type.

[Hlingler]

Well, I'm in Windows now. I restarted and it won't go to the graphic login thing. It asks me my login and then password and then nothing. I can type stuff but I don't know what to type.Login to the terminal as root user and restore the back-up xorg.conf file:mv /etc/X11/xorg.conf /etc/X11/xorg.conf.screwed-up
mv <enter-path-to-back-up-xorg.conf-file> /etc/X11/xorg.confIf you re-booted to Windows and/or otherwise can't get to a terminal, you'll have to boot into text-mode: stop the GRUB bootloader at the blue screen and press "e" to edit the boot parameters; use the arrow keys to move to the "kernel" line, go to the end, and add a space and then a 3, then press enter to boot to text-mode only. Then follow the above steps to restore the other xorg.conf. Then re-boot or restartx.

V

[eman_resu]

I guess I'm going to try to restore my backed up xorg.conf file. I was reading some beginners terminal command crap but I don't think I remember exactly how to do this. If I do I'll be surprised.

[eman_resu]

I'm back in linux. Do you want me to post the /var/log/Xorg.0.log thing? It's pretty long.

[Hlingler]

I'm back in linux. Do you want me to post the /var/log/Xorg.0.log thing? It's pretty long.No, use the "Reply Post" or "Reply Topic" and attach the file to the post using the "manage Attachments" button (page down to find it).

Sorry about the crash. I'll try to help you sort this out.

V

[eman_resu]

No need to apologize.

I had to rename var/log/Xorg.0.log to .conf because the manage attachments thing said it was an invalid file type.

Thanks again for all the help.

[Hlingler]

Everything looks really great, the card is detected properly, direct rendering is enabled and everything, it all looking fantastic, then here's the fatal error:(II) RADEON(0): Output LVDS using initial mode 1400x1050
[...]
(EE) RADEON(0): Static buffer allocation failed. Disabling DRI.
(EE) RADEON(0): At least 19800 kB of video memory needed at this resolution and depth.You do not have enough VRAM to run the default resolution, so you need to reduce that. Try specifying 1280x800, it's available and should brong you down under 16 MB VRAM used. Is that good enough?Section "Screen"
Identifier "Screen0"
Device "Videocard0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1280x800" "1152x864" "1280x768" "1280x720" "1024x768" ""800x600" ""640x480"
EndSubSection
EndSection

[eman_resu]

Didn't work. After I tried what you typed it didn't work so I tried just have 1280x800, which didn't work, then tried getting rid of the 1280x800 part, thinking maybe that was too big, which also didn't work. I attached the log file, again renamed as a .conf file, and the xorg.conf file.

[Hlingler]

Didn't work. After I tried what you typed it didn't work so I tried just have 1280x800, which didn't work, then tried getting rid of the 1280x800 part, thinking maybe that was too big, which also didn't work. I attached the log file, again renamed as a .conf file, and the xorg.conf file.This Xorg.0.log is basically identical to the first one. Xorg and/or the driver(s) are not paying attention to your settings and continue to try to use the 1400x1050 resolution. Xorg is this way and it is extremely annoying: unlike the "other" OS, Xorg defaults to the highest available resolution and color depth, even if it results in a failed X-session. That is what is happening here.

I'm looking through 'man radeon' for the over-ride option/switch - I suggest that you do the same.

V

P.S. On the box I'm typing from, nvidia Riva/TNT2 I got 3D/DRI with proprietary driver at 1024x768 @ 24 bpp and 32 MB VRAM which is the max available for this hardware, but the monitor can do much better.... I had the same thing happen but simply edited the "modes" line and it works, don't know why yours isn't....

EDIT: I think I see part of the problem at least: no monitor is specified, so maybe it's taking matters into it's own hands.... Add a monitor section to xorg.conf to appease it:Section "Monitor"
Identifier "Monitor0"
EndSection

[...]

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
Monitor "Monitor0"
DefaultDepth 24
[...]

[Hlingler]

Instead of trying to manually edit/fix this stuff, try using the "Display Manager" GUI. I don't like it either as it can wreck a good xorg.conf quickly, but give it a shot: find "Display Manager" (aka system-config-display) in the menus, open it, and use it to set resolution to a lower value (suggest 1280x800).

V

EDIT: You can also use "Display Manager" to try to refine your monitor identification.

EDIT #2: If all else fails, try adding these options in xorg.conf 'Device' section:
Option "DDCMode" "off"
Force to use the modes queried from the connected monitor.
The default is off. Ignore the default, specify and force it off.

Option "IgnoreEDID" "true"
Do not use EDID data for mode validation, but DDC is still used for monitor detection. This is different from NoDDC option.
The default value is off. Reverse the default, force it off.

[eman_resu]

I changed it to 1280x800 in Display Manager and it worked, I'm in 1280x800. But direct rendering still isn't working.

[Hlingler]

I changed it to 1280x800 in Display Manager and it worked, I'm in 1280x800. But direct rendering still isn't working.??? It should be! Everything except the resolution was 100% copacetic. I bet "Display Manager" wrecked the other settings.... *sigh*

Please attach current Xorg.0.log

And xorg.conf

V

[eman_resu]

Here's the files.

[Hlingler]

Yeah, "Display Manager" blew away the existing xorg.conf and re-wrote it with only the modeline changes.

I edited it manually. Try the attached xorg.conf

V

[eman_resu]

Didn't work.

[Hlingler]

OK, this time the Xorg.0.log is a little different: it shows compliance with the 1280x800 initial resolution - so I'm guessing that you have a successful GUI/desktop session, but not DRI? Because Xorg and it's spawn still insist on trying to map enough VRAM for 1400x1050, which you simply don't have, so the same error eventually occurs.

Try the attached xorg.conf - I applied those two over-ride options, see if they work.

All of your Xorg.0.logs show that Direct Rendering is working. That is good. It's up to you, but this is clearly just a matter of finding the correct settings in xorg.conf to force this recalcitrant software into compliance. I wish I knew exactly what those are, but I don't. And it's too late here tonite for me to continue now. If this xorg.conf doesn't work, please post back if you wish to continue to attempt to fix this, and I (or someone else) will get back to you later.

Good Luck,
V

[eman_resu]

That didn't work either. Thanks a lot for your help. I'll look around google for a few hours but I think I have to work in the morning. I attached the log file.

[Hlingler]

Yeah, I wasn't paying attention: it's that funky display connection you've got, "LVDS" whatever that is - it's definitely not "standard", but I'm not very familiar with laptops. Reading up a little on the available documentation, this is from 'man radeon':Option "LVDSProbePLL" "boolean"
When BIOS panel informations aren’t available (like on PowerBooks), it may still be necessary to use the firmware provided PLL values
for the panel or flickering will happen. This option will force probing of the current value programmed in the chip when X is launched
in that case. This is only useful for LVDS panels (laptop internal panels). The default is on.Based on what I see in your Xorg.0.log, the 1400x1050 mode keeps getting auto-added to the list of modes, screwing up the VRAM. So: please remove those other two special options I added to xorg.conf (since they obviously don't work they're pointless and just clutter things up) and add the following option to section 'Device':Option "LVDSProbePLL" "off"Then re-startx. If that doesn't work, there are still many other options I found, but I suggest trying them one at a time until the right one(s) is found....

And again, it's up to you, but I'm certain that this is fixable - direct rendering is clearly working right up until the point where the VRAM error forces it off.

V

[eman_resu]

I guess I messed up last night on overwrote my backup with one of the modified xorg.conf files. So now it won't boot to X server, I'm in Windows now. I have xorg.conf~ in there, which looks like the original, also I have it posted in the first post. I don't know what the ~ means. I think I'm going to try just moving that to /etc/X11 and renaming it. Then I'll try your post.

[Hlingler]

Here's your last xorg.conf with the latest changes/fixes I described in my last post.

V

[eman_resu]

That didn't work.

[Hlingler]

Well, poo, no it didn't: your last Xorg.0.log shows that Xorg blew right past that option and once again probed the display. Try this instead:Option "PanelSize" "string"
Should only be used when driver cannot detect the correct panel size. Apply to both desktop (TMDS) and laptop (LVDS) digital panels.
When a valid panel size is specified, the timings collected from DDC and BIOS will not be used. If you have a panel with timings dif-
ferent from that of a standard VESA mode, you have to provide this information through the Modeline.
For example, Option "PanelSize" "1400x1050"
The default value is none.So try:Option "PanelSize" "1280x800"V

[eman_resu]

Did not work.

[Hlingler]

AHHRRRRGGGGG!

OK, I spotted this in Xorg.0.log:(II) RADEON(0): Max desktop size set to 1600x1200
(II) RADEON(0): For a larger or smaller max desktop size, add a Virtual line to your xorg.conf
(II) RADEON(0): If you are having trouble with 3D, reduce the desktop size by adjusting the Virtual line to your xorg.confSo, let's try that; add the line in red to your xorg.conf:Section "Screen"
Identifier "Screen0"
Device "Videocard0"
Monitor "Monitor0"
Virtual 1280 800
DefaultDepth 24

[eman_resu]

Didn't work.

[Hlingler]

These are the two things that keep popping up that are the roadblocks:(WW) RADEON(0): LVDS Info:
XRes: 1400, YRes: 1050, DotClock: 108000
HBlank: 448, HOverPlus: 160, HSyncWidth: 112
VBlank: 42, VOverPlus: 0, VSyncWidth: 3
[...]
(II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0
(II) RADEON(0): Detected non-DDC Monitor Type: 0
(II) RADEON(0): EDID for output DVI-0
(II) RADEON(0): Detected non-DDC Monitor Type: 2
in RADEONProbeOutputModes
(II) RADEON(0): Added native panel mode: 1400x1050
(II) RADEON(0): Adding Screen mode: 1280x800
(II) RADEON(0): Adding Screen mode: 1280x768
(II) RADEON(0): Adding Screen mode: 1280x720
(II) RADEON(0): Adding Screen mode: 1152x864
(II) RADEON(0): Adding Screen mode: 1024x768
(II) RADEON(0): Adding Screen mode: 800x600
(II) RADEON(0): Adding Screen mode: 640x480
[...]But I can't figure out how to suppress this. I'll have to do some more checking in the manuals to find other options. Just to let you know how hard that is, here's my favorite part of 'man xorg.conf':VIDEOADAPTOR SECTION
Nobody wants to say how this works. Maybe nobody knows ...In the meantime, it says: "Detected non-DDC Monitor Type: 2 in RADEONProbeOutputModes", but that option isn't listed in the manuals. Try adding it to section 'Device' anyway:Option "RADEONProbeOutputModes" "off"If that doesn't help, I'll post back when I find something else useful to try....

V

[eman_resu]

That didn't work. I attached the log file and the xorg.conf file, with all the additions I want to make sure I didn't add something wrong or something.

Again, thanks for all the help. Sorry I can't be of more help to solve my own problem. I keep reading the log file, thinking that eventually, with enough reading, it will make sense to me. I'll keep reading that and man files and google. If I find anything that sounds useful I'll post it. Thanks again, I wasn't expecting this much help, especially considering you get nothing in return.

[Hlingler]

Your xorg.conf file looks fine to me.

Actually, I do get something out of this: I learn. This subject just happens to be of interest to me (not sure why...).

...And so far, I've learned that Xorg and the drivers have blown right by every option we've tried without even an acknowledging comment that the options were ever read, or warning(s) that the options were ignored - which is what should at least have happened. I do not know why that is. At this point, I hesitate to suggest any more attempts, since all of the obvious options have been tried without effect, and the rest might just send you on wild chases. It is frustrating to see something this close to working, yet not.

At least one thing so far has helped, as I understand it: you can now (re)start the machine or (re)start X into graphical mode due to the changes we've made to the default mode, is that correct? Also, just to be sure, you are re-starting the X-server (ALT-CTL-Backspace) to apply the changes after each change/revision to the xorg.conf file, correct?

I will attempt to post to the DRI user's mailing list at SourceForge.net to inquire about this issue. I joined it to get help on my old ATI Rage Pro (mach64) card, and did get the pointer to the last missing piece of the puzzle that allowed me to get DRI working. So I hope that it can help here. Unfortunately, for some reason I can't seem to log in at the moment.

I'll post back if/when I find something else useful to suggest. In the meantime, if there's anyone else who can help, I hope that they jump in here.

Regards,
V

[eman_resu]

Yes, I am in Graphical mode. The changed config files wouldn't let me boot into graphical mode. I think I am still using the original config file, which never had a problem getting into graphical mode, it just couldn't get direct rendering. I attached my current config file. The only times I couldn't get into graphical mode was when I was trying one of the modified config files.

Yes, I am restarting X with CTRL + ALT + Backspace. Anytime I tried that with any of the modified config files it would go into text mode, and then I'd restart the computer to make sure it wouldn't go into graphical mode, then, while in text mode, switch the modified xorg.conf with the original one I backed up, then restart with graphical mode working, then come back here to post the results and the attached log file.

I was thinking maybe a I messed something up in the install or some time after that when I was mindlessly clicking around. I don't remember messing with and video related anything, but I guess it's possible. I checked if I had direct rendering with the live cd, thinking that if I did mess up anything that would be a good way to test how it was originally without have to reinstall, but no direct rendering with that either.

Also, I found some possibly useful links. I guess others have gotten direct rendering working with this exact video card.

Little more information on the card, might be helpful:
http://www.thinkwiki.org/wiki/ATI_Mobility_Radeon_7000

I'm not sure if this is helpful or even relevant. It's a little too complicated for me completely understand:
http://www.gentoo.org/doc/en/dri-howto.xml

This guy got it working on Debian:
http://somewhere.fscked.org/laptop/#video

[ajamison]

u can allways try the drivers from Livna once they get them ironed out I tried them and it says missing a main file so I am usin radeon which i believe is not DRI

[Hlingler]

Well, poo. I thought that at least you could boot/re-startx into graphical mode.

As I mentioned earlier, you could install package driconf (standard Fedora repos: yum install driconf) to get a GUI utility to play with all these xorg.conf settings rather than manually editing them - it will only show those options that are available with the "radeon" DRI driver, but it may not work at all if DRI is not enabled (which it is not). You could try whatever available options or combinations you like if it does work. There are a couple of other tempting-looking options on a couple of those links, but at this point, I see no reason why they should work any better - the logfiles show that the software is apparently not even reading the options, much less using them.

One other thing to consider is BIOS settings: are there any that might affect the video configuration? Take a look, if so, try to find out what they do and adjust them if it might help. I know that setting the AGP aperture on mine is possible, and there is no harm in increasing it, but I don't see why that should help in this case - the problem lies with the funky display type "LVDS" and config.

And again, this chipset/card is simply not supported by the ATI proprietary driver, so installing any other driver(s) will be of no benefit. For the record, there are two drivers named "radeon" involved here: /usr/lib/xorg/modules/drivers/radeon_drv.so is the 2D Xorg driver, and /usr/lib/dri/radeon_dri.so is the Mesa 3D/DRI driver. Both "radeon" drivers support this chipset. And both are working fine up until the point where the VRAM limit shuts it all down.

V

EDIT: It just occurred to me that, if you're saving these Xorg.0.log files after getting back to a working desktop, then we're not seeing the logs of the failed startx (because it's immediately over-written by the log of the new session), but rather the current successful session.... Please make sure that you save/back-up the Xorg.0.logs from the CLI before re-starting X-server.

[eman_resu]

I'll try the driconf thing. I don't really mind editing the xorg.conf but I'm envisioning a little check box that says "Enable DRI".

I just went and checked the bios. I found these video options:

Video Controller: ATI Mobility Radeon
Video Memory: 16 MB.

Then this:

Primary Video: Dock video card
The other option was System.

It was on dock video card so I changed it to system. I was hoping that was the problem so I restarted with one of the xorg.conf files, but had the same results as I did every other time -X wouldn't start.

I never thought of the Xorg.0.log problem. I can try all the other xorg.conf files and save all the log files before switching the xorg.conf file and post them. That sounds really tedious so I'll wait to see what you suggest. For now I'll try the last one you uploaded and post the log file. And what does CLI mean? I'm assuming it's a name for the text mode.

Today I'm taking a break from researching this. From all Linux related guides/help. I'm sure I'll end up reading up on something later today but I'm really trying not to. I'm going to try and kill some time and watch the most mindless show TV has to offer. Luckily, Family Guy is frequently replayed on like 8 networks.

[eman_resu]

I switched the xorg.conf files and restarted X and saved the log file then switched the xorg.conf file and started X. I attached the log file, which is much shorter and says there's problems. I also attached the xorg.conf file I used. It was the last one you uploaded.

Sorry about not knowing about the log file saving thing. I should of thought of that.

[Hlingler]

I'll try the driconf thing. I don't really mind editing the xorg.conf but I'm envisioning a little check box that says "Enable DRI".Actually, that's not far off: http://dri.freedesktop.org/wiki/DriConf
http://people.freedesktop.org/~fxkuehl/driconf/driconf.png
For my ATI Rage Pro (mach64) chip, there are in fact just two options: "on" and "off". :)

I just went and checked the bios. I found these video options:

Video Controller: ATI Mobility Radeon
Video Memory: 16 MB.

Then this:

Primary Video: Dock video card
The other option was System.

It was on dock video card so I changed it to system. I was hoping that was the problem so I restarted with one of the xorg.conf files, but had the same results as I did every other time -X wouldn't start.Not familiar with those things, but doesn't look relevant and apparently didn't help. However, your latest Xorg.0.log is very short and revealing: Xorg and/or the driver(s) choked violently before terminating on the very same "Virtual" option that they previously said to add - maybe it was in the wrong 'Section', I'll have to re-check. It may be necessary to re-try some of those other options too, just to see what (if any) reaction the software puked out....I never thought of the Xorg.0.log problem. I can try all the other xorg.conf files and save all the log files before switching the xorg.conf file and post them. That sounds really tedious so I'll wait to see what you suggest. For now I'll try the last one you uploaded and post the log file. And what does CLI mean? I'm assuming it's a name for the text mode.Yes, "CLI"="command-line", the text-prompt, terminal, console, whatever. And that explains why all the logfiles look identical. :rolleyes: It seems that Xorg does in fact back up the logfile of the session immediately preceding the running session:[Vince@localhost ~]$ ls -lht /var/log/Xorg.*
-rw-r--r-- 1 root root 24K 2008-05-14 23:01 /var/log/Xorg.0.log
-rw-r--r-- 1 root root 24K 2008-05-13 13:29 /var/log/Xorg.0.log.old
-rw-r--r-- 1 root root 24K 2008-04-17 22:26 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 24K 2008-04-13 21:22 /var/log/Xorg.1.log.old
-rw-r--r-- 1 root root 1.2K 2007-06-30 19:20 /var/log/Xorg.3.log
-rw-r--r-- 1 root root 1.2K 2007-06-30 19:19 /var/log/Xorg.2.log
-rw-r--r-- 1 root root 24K 2007-05-28 08:54 /var/log/Xorg.20.log
-rw-r--r-- 1 root root 24K 2007-05-28 08:50 /var/log/Xorg.20.log.old
-rw-r--r-- 1 root root 1.3K 2006-12-11 04:17 /var/log/Xorg.setup.log
[Vince@localhost ~]$The *.1.log* file(s) then would be for a second desktop session, and so on. It's not documented anywhere, but looks like maybe within the last year-ish this feature was added. You can test, or just assume that the logfile will be auto-backed up as /var/log/Xorg.0.log.old, so you won't have to goof around trying to save something that's already saved....Today I'm taking a break from researching this. From all Linux related guides/help. I'm sure I'll end up reading up on something later today but I'm really trying not to. I'm going to try and kill some time and watch the most mindless show TV has to offer. Luckily, Family Guy is frequently replayed on like 8 networks.That sounds like a plan.... :D

V

EDIT: Looks like your not the first one on the planet to have this axact problem: http://www.linuxquestions.org/questions/linux-laptop-and-handheld-25/fedora-core-3-radeon-mobility-m6-no-opengl-292363/
But that was about three years ago - the 'radeon' driver has improved quite a bit since then. And I sent a post to the DRI User's mailing list at SourceForge.net - hope someone responds. Ciao.

[Hlingler]

OK, Here's the SourceForge post: https://sourceforge.net/mailarchive/forum.php?thread_name=380336.49467.qm%40web37003.m ail.mud.yahoo.com&forum_name=dri-users

Already got a response: https://sourceforge.net/mailarchive/forum.php?thread_name=a728f9f90805160539w6a4f9ees7 8d92a0fe0043b0f%40mail.gmail.com&forum_name=dri-users

Try what the dude says: reduce default color depth to 16, see if that gets DRI working. 16 bpp will not be good enough to run some games and other stuff that requires 24 bpp color, but hey, if it gets DRI working, that's progress....Section "Screen"
Identifier "Screen0"
Device "Videocard0"
DefaultDepth 16
SubSection "Display"
Viewport 0 0
Depth 16
Modes "1280x800" "1280x768" "1280x720" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
EndSectionI should have suggested this, but as far as I can tell, you don't have enough VRAM for 16 bpp either, but hey, maybe that'll work....

If that works (or not), next try the other idea: adjust the front and back buffers by adding 'Option "DepthBits" "16" ' and put the "Virtual" option where he shows:Section "Device"
Identifier "Videocard0"
Driver "radeon"
Option "DepthBits" "16"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
DefaultDepth 24
SubSection "Display"
Virtual 1024 768
Viewport 0 0
Depth 24
Modes "1024x768" "800x600" "640x480"
EndSubSection
EndSectionNote that last idea reduces display resolution to 1024x768, which I personally find to be adequate. The "DepthBits" option is in 'man radeon' but I never saw it. :rolleyes:

Good Luck,
V

[ajamison]

u can bump the modes up to your monitor's highest resolution using the same formate 'resolution here'

Replace resolution here with an actual resolution range such as 1440x900

[eman_resu]

[root@localhost andrew]# glxinfo | grep direct
libGL warning: 3D driver claims to not support visual 0x23
libGL warning: 3D driver claims to not support visual 0x24
libGL warning: 3D driver claims to not support visual 0x25
libGL warning: 3D driver claims to not support visual 0x26
libGL warning: 3D driver claims to not support visual 0x27
libGL warning: 3D driver claims to not support visual 0x28
libGL warning: 3D driver claims to not support visual 0x29
libGL warning: 3D driver claims to not support visual 0x2a
libGL warning: 3D driver claims to not support visual 0x2b
libGL warning: 3D driver claims to not support visual 0x2c
libGL warning: 3D driver claims to not support visual 0x2d
libGL warning: 3D driver claims to not support visual 0x2e
libGL warning: 3D driver claims to not support visual 0x2f
libGL warning: 3D driver claims to not support visual 0x30
libGL warning: 3D driver claims to not support visual 0x31
libGL warning: 3D driver claims to not support visual 0x32
direct rendering: Yes


I skipped to the last suggestion of the post. I attached my current xorg.conf and the log file. I added those things to the original xorg.conf, the only one I could get into X with. It worked. I edited it and restarted it and it worked. It was nice. I haven't tried any games or anything yet but it's nice to see the Yes. I don't know what that other stuff means but I'm currently paying no attention to it. Thanks for all the help. Thanks a lot.

I do have some questions though. Is there any thing else I should do to get everything working as best it can. I don't have the best card so I want to make sure it's working at the best of its ability. Also, should any of the other stuff from all the other xorg.conf files be used? Like all the added sections and additions. And the libGL warnings, are those bad?

Now, I'm going to try and play a game. Oh, while reading up on all this I read about some fancy stuff you can do only if you have direct rendering. Weird stuff with desktop switching and stuff. Can I do any of this? If not I won't be disappointed, none of it really seemed necessary or even useful, but if I can I'd like to try it. And again, thanks. A lot. If I didn't hate emoticons so much I'd probably use a thumbs up, or maybe even a happy face.


direct rendering: Yes

[Hlingler]

Awesome I'll make sure to thank that Alex guy on the SF mailing list. I guess I had the "Virtual" in the wrong place the first time....

Yeah, I waited on the performance tweaks, but yes there's some options - for that wait until later I gotta run right now or just try them yourself with 'driconf' (P.S. run driconf the first time as root user to generate default config files)....

No, none of the other options we tried will help performance, I don't think, but you can play with 'driconf' to check out various combos.... just BACK UP the current working xorg.conf B4 doing anything else.

Right: ignore the stupid warnings for now it's probably because of color depth or some other tweak - I saw those same on one of the links I checked.

Right: you got DRI you can do anything that your PC can handle - maybe even Compiz-Fusion but it needs 64 MB VRAM minimum I bet your PC would just lock up at 16 MB VRAM or run in slow-motion. But normal compositing should work - my Rage Pro can do that!

Glad that finally worked more later....

V

[ajamison]

so DRI works with the Open source driver?

Good news
especialy for the folks in F9 waiting for the respective close source drivers

[eman_resu]

Yeah. I just tested this with a game. Nexuiz, I think it was called? I don't know, I read about it somewhere. I had it on the lowest of the lowest settings. It ran, which it wouldn't before, but I had 5 FPS. Everyone else that was playing seemed surprised by my low FPS, but I was just happy I could play it. I still got to play around with the video options in that game though. From what I read a lot of the options are intended for really good computers, but I'll read up on it a little and see what happens. But yeah, direct rendering works.. And for now I'll just enjoy the victory. I didn't do much but I'm enjoying it none the less. And maybe I can take up sleeping again.

I don't know what Compiz-Fusion is, but it sounds cool, and I read it a lot in the forums.
The first thing I did after posting was back up the xorg.conf file. I emailed it to myself in case everything on my computer dies.

And thanks again.

[Hlingler]

Well, hoo-ray! Or: Good Grief! That was like pulling teeth, eh!? :)

You have Direct Rendering at 24 bpp color depth - it doesn't get any better than that. You are now limited only by your hardware's capability to process data: i.e., CPU speed is fixed, and I see 16 MB VRAM backed up by 64 MB AGP aperture (AGP aperture=system RAM reserved for video) out of 128 MB total system RAM, correct? You can increase AGP aperture in BIOS to any value you want, there is no harm in setting it higher (but it's pointless to set it higher than total available system RAM). I'd leave it alone.

To get some idea of performance, run: glxgears. It's not a benchmark tool, but should give you some idea of how the following options affect performance. Run with no other load on system, do not hide/cover/minimize gear box, let run for 30-60 seconds, observe output in 5-sec chunks.

OK, performance tweaks: try these, I recommend one at a time starting at top of list, I'll just list them, see 'man radeon' for the full poop:Section "Device"
Identifier "Videocard0"
Driver "radeon"
Option "DepthBits" "16"
Option "DisplayPriority" "HIGH"
Option "EnablePageFlip" "on"
Option "SubPixelOrder" "NONE"
Option "AccelMethod" "EXA"
EndSectionWARNING: that last one is "experimental acceleration" mode and may bork the whole GUI, cause premature male pattern balding, nuclear meltdowns, and/or increase global warming. If it works, however, it should be much faster than default XAA acceleration. Use only if you feel brave....

If you're happy with 1024x768, leave that alone. If you really want to try, you can try increasing it one step at a time (see previous posts for list/order). Reducing color depth to 16 bpp will exactly double your FPS (because 24 bpp is actually 32 bpp masked as 24) *if* you can get away with 16 bpp on some games - some stuff may not work or look good at 16 bpp. Dropping to 16 bpp will not affect DRI.

If I see anything else after I re-read 'man xorg.conf', or otherwise that might improve performance, I'll post back.

Enjoy!
V

P.S. There is an *extremely dangerous* option called "AGPFastWrite" that can speed up performance, however, both the chipset and AGP Bridge (on the mobo) must support this feature - if not, well, it's not pretty. Your card almost certainly does not support it. Don't try it. Output of: lspci -vv will tell if supported or not (both chipset and bridge).

[Hlingler]

so DRI works with the Open source driver?

Good news especialy for the folks in F9 waiting for the respective close source driversBingo! Now you know why this topic interests me....

V

[eman_resu]

I ran glxgears. I'll try those tweaks and post which ones work and the glxgears output with those. Heres the glxgears stuff without the additions:

[andrew@localhost ~]$ glxgears
libGL warning: 3D driver claims to not support visual 0x23
libGL warning: 3D driver claims to not support visual 0x24
libGL warning: 3D driver claims to not support visual 0x25
libGL warning: 3D driver claims to not support visual 0x26
libGL warning: 3D driver claims to not support visual 0x27
libGL warning: 3D driver claims to not support visual 0x28
libGL warning: 3D driver claims to not support visual 0x29
libGL warning: 3D driver claims to not support visual 0x2a
libGL warning: 3D driver claims to not support visual 0x2b
libGL warning: 3D driver claims to not support visual 0x2c
libGL warning: 3D driver claims to not support visual 0x2d
libGL warning: 3D driver claims to not support visual 0x2e
libGL warning: 3D driver claims to not support visual 0x2f
libGL warning: 3D driver claims to not support visual 0x30
libGL warning: 3D driver claims to not support visual 0x31
libGL warning: 3D driver claims to not support visual 0x32
2750 frames in 5.0 seconds = 549.830 FPS
2746 frames in 5.0 seconds = 549.197 FPS
2751 frames in 5.0 seconds = 550.011 FPS
2750 frames in 5.0 seconds = 549.937 FPS
2751 frames in 5.0 seconds = 550.082 FPS
2750 frames in 5.0 seconds = 549.995 FPS
2750 frames in 5.0 seconds = 549.998 FPS
2743 frames in 5.0 seconds = 548.583 FPS
2750 frames in 5.0 seconds = 549.831 FPS
2748 frames in 5.0 seconds = 549.595 FPS
2748 frames in 5.0 seconds = 549.107 FPS
2754 frames in 5.0 seconds = 550.799 FPS
2748 frames in 5.0 seconds = 549.547 FPS
2742 frames in 5.0 seconds = 548.396 FPS
2748 frames in 5.0 seconds = 549.475 FPS
2747 frames in 5.0 seconds = 549.391 FPS
2748 frames in 5.0 seconds = 549.415 FPS
2748 frames in 5.0 seconds = 549.414 FPS
2748 frames in 5.0 seconds = 549.415 FPS
2745 frames in 5.0 seconds = 548.985 FPS
2744 frames in 5.0 seconds = 548.627 FPS
2748 frames in 5.0 seconds = 549.589 FPS
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 185156 requests (130063 known processed) with 0 events remaining.
[andrew@localhost ~]$


Oh, and system RAM. I'm not sure how much I have. After a little research I found that most older computers have 128. I know I have 1024 mb. of RAM. I had 512 when I started the thread but got another 512 a few days ago. I don't know how to find out how much system RAM I have but I'll look into it. RIght now I'm eager to test those additions to xorg.conf.

And when you say "extremely dangerous" what exactly do you mean? Like really don't try it, or if it doesn't work I just got to replace the xorg.conf with the backed up xorg.conf and everything is good again.

[eman_resu]

I added the first 3:
Option "DisplayPriority" "HIGH"
Option "EnablePageFlip" "on"
Option "SubPixelOrder" "NONE"


[andrew@localhost ~]$ glxgears
libGL warning: 3D driver claims to not support visual 0x23
libGL warning: 3D driver claims to not support visual 0x24
libGL warning: 3D driver claims to not support visual 0x25
libGL warning: 3D driver claims to not support visual 0x26
libGL warning: 3D driver claims to not support visual 0x27
libGL warning: 3D driver claims to not support visual 0x28
libGL warning: 3D driver claims to not support visual 0x29
libGL warning: 3D driver claims to not support visual 0x2a
libGL warning: 3D driver claims to not support visual 0x2b
libGL warning: 3D driver claims to not support visual 0x2c
libGL warning: 3D driver claims to not support visual 0x2d
libGL warning: 3D driver claims to not support visual 0x2e
libGL warning: 3D driver claims to not support visual 0x2f
libGL warning: 3D driver claims to not support visual 0x30
libGL warning: 3D driver claims to not support visual 0x31
libGL warning: 3D driver claims to not support visual 0x32
2936 frames in 5.0 seconds = 587.063 FPS
3230 frames in 5.0 seconds = 645.896 FPS
3237 frames in 5.0 seconds = 647.238 FPS
3250 frames in 5.0 seconds = 649.811 FPS
3247 frames in 5.0 seconds = 649.223 FPS
3249 frames in 5.0 seconds = 649.782 FPS
3243 frames in 5.0 seconds = 648.439 FPS
3245 frames in 5.0 seconds = 648.998 FPS
3246 frames in 5.0 seconds = 649.192 FPS
3245 frames in 5.0 seconds = 648.995 FPS
3247 frames in 5.0 seconds = 649.216 FPS
3247 frames in 5.0 seconds = 649.220 FPS
3240 frames in 5.0 seconds = 647.820 FPS
3245 frames in 5.0 seconds = 648.460 FPS
3244 frames in 5.0 seconds = 648.732 FPS
3246 frames in 5.0 seconds = 649.198 FPS
3244 frames in 5.0 seconds = 648.799 FPS
3245 frames in 5.0 seconds = 648.993 FPS
3242 frames in 5.0 seconds = 648.273 FPS
3243 frames in 5.0 seconds = 648.598 FPS
3246 frames in 5.0 seconds = 649.020 FPS
3245 frames in 5.0 seconds = 648.988 FPS
3247 frames in 5.0 seconds = 649.232 FPS
3245 frames in 5.0 seconds = 648.990 FPS
3239 frames in 5.0 seconds = 647.616 FPS
3229 frames in 5.0 seconds = 645.651 FPS
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 252550 requests (195081 known processed) with 0 events remaining.
[andrew@localhost ~]$


I'm still getting about 7 FPS in that Nexuiz game. I tried playing it in Windows, to see if that was the best I could get. I got 2 errors then when it did work I got 5 FPS. Then it went down then it turned red and said 5 SPF. SPF? Does that mean seconds per frame? I didn't know that could happen. Then an error happened and it died. That's with nothing running in the background and the firewall off.

I'm going to try to figure out how to use Wine and play something I know works well on this computer to see how that works out.

[Hlingler]

Looks like a fairly significant increase to me: from ~550 FPS to ~650 FPS with just those three options - that's about a 20% increase (and 5=>7 in Nexuiz is also about +20%, although that probably seems insignificant when you're playing it). Yes, 'FPS'=frames per second. Actually, I'm impressed that you got such a large increase.

I remember reading that if your hardware doesn't support AGP Fast Writes, you can damage it by trying to use it - that's what I meant by "extremely dangerous".

If you're getting about the same performance in FPS, in the same game, in both Fedora and Windows, then I'd say you've probably got just about the best you're going to be able to get at this time with the 'radeon' driver. The developers at DRI are making improvements every day, so maybe the next release (F9 with Xorg-1.4) will be a little better. If you like, try the 'EXA' acceleration option - the worst that can happen is a game crash, X-server crash, or X simply fails to start, or whatever, and you'll have to revert back to default 'XAA' accelertaion. "EXA' is supposed to be faster than 'XAA" acceleration.

Since you have 1024 MB system RAM, you can also try increasing the AGP aperture in the BIOS settings. I don't know if the driver will recognize the larger aperture, though, but if it does, that should help. That's system RAM reserved for video. Try any increase that the BIOS will allow, up to half of system RAM (currently 64 MB, try =>512 MB).

Wine is a completely different ball game - it's still far from optimal as a compatability layer for running Win* apps in Linux, but you can of course see what happens - check the WineHQ web site "Application DataBase" for more info on setup and tweaks, or search this forums. By the way, Nexuiz is one of the newer and more graphically demanding games, so I would not expect good performance with it.

I can find no other settings at this time that might help performance. If/when I do, I'll post a note. In the meantime, enjoy - this is indeed a "Good Thing". :)

V

EDIT: OK, here's a few more options that you can try if you like that may help (or break the GUI...). They're in my xorg.conf for my ATI Rage Pro chipset. Again, I suggest one at a time so that you can assess their impact - good or bad. I can't find these listed in the manuals, so I'll explain them:Section "Server Flags"
Option "AIGLX" "off"
EndSectionAdd the whole new section anywhere in the file. AIGLX is described in the man pages. It's enabled by default. It forces all rendering to go through X-server rather than actually directly to hardware. Try turning it off.Section "Device"
Identifier "Videocard0"
Driver "radeon"
Option "DepthBits" "16"
Option "DisplayPriority" "HIGH"
Option "EnablePageFlip" "on"
Option "SubPixelOrder" "NONE"
Option "AccelMethod" "EXA"
Option "nolinear"
Option "shadowfb" "on"
Option "backingstore" "on"
EndSectionOption "nolinear" allows a non-linear framebuffer - i.e., it does not have to exist in a single contiguous chunk, but can be separated into more than one chunk(s). Might help VRAM memory mapping by allowing stuff to be moved around easier. Option "shadowfb" is probably useless since Fedora uses a non-standard framebuffer that does not support certain things, but hey, give it a go - it won't hurt nothin'. Option "backingstore" is another memory-related tweak that works for me. It's off by default - turn it on.

In addition to sufficient CPU/GPU processing power and VRAM/system RAM, the critical requirement for all the goodies like Compiz-Fusion compositing Window Manager etc. is the OpenGL extension: GLX_EXT_texture_from_pixmap. If you got it, good. Even my Rage Pro does:[vince@localhost ~]$ glxinfo|grep render
direct rendering: Yes
OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX
[vince@localhost ~]$ glxinfo|grep -i pixmap
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
[Vince@localhost ~]$Just for giggles, I tried C-F on that Rage Pro - but with only 4 MB VRAM, it locked up instantly. :D I think that the VRAM and AGP simply filled up instantly and so nothing else could be drawn - required a hard re-boot - it was frozen solid. :D Oh, well... otherwise, it would have worked.

At this point, I really have exhausted all ideas for further performance tweaks (or otherwise). Try those if you want, see what happens, and try enabing whatever compositing effects your desktop has (shadows, window translucency, etc.) to see if it works. Good Luck. Enjoy. Ciao.

[Hlingler]

From http://www.gentoo.org/doc/en/dri-howto.xml:5. Tweak your performance

Get the most out of direct rendering

A few options may increase performance by up to 30 percent (or more) over the default. Set them in /etc/X11/xorg.conf. However, you will first need to check that your motherboard and video card support these options.

First, let's see if your video card can support fast writes. We'll do this by closely inspecting the output from lspci. Specifically, we are looking at the "VGA compatible controller" information.

Code Listing 5.1: Video card check
# lspci -vv
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA])
. . .
Capabilities: [58] AGP version 2.0
Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4

While quite a lot of information is produced, we are looking for FW in the "Status" subsection of the AGP "Capabilities" section. If FW+ is present in the "Status" line, it means the card supports fast writes. We can now check if the motherboard supports fast writes.
Important: If you do not see FW+, but instead see FW-, you cannot enable fast writes in xorg.conf. Your card does not support fast writes.

Now let's make sure the motherboard supports fast writes as well. This time, look at the "Host bridge" section of your lspci output.

Code Listing 5.2: Motherboard check
# lspci -vv
00:00.0 Host bridge: Intel Corporation 82830 830 Chipset Host Bridge (rev 02)
. . .
Capabilities: [a0] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4

Again, examine the "Status" subsection of your AGP "Capabilities" section. Look for FW. If you see FW+, your motherboard supports fast writes.
Important: Remember, both your video card information and your motherboard information must show the same FW capability. If either device shows FW- in "Status", you cannot enable fast writes in xorg.conf.

Assuming that all has gone well and both your motherboard and video card support fast writes, let's enable this option in /etc/X11/xorg.conf and get the best performance out of your hardware.

Code Listing 5.3: xorg.confSection "Device"
...
Option "AGPFastWrite" "True"
(This had no measurable effect, but it may increase instability of your computer.)
(You may also need to set it in your BIOS.)
Option "EnablePageFlip" "True"
(This improved FPS from 618 to 702. It also is "risky" but few people have reported problems.)
...
EndSectionNote that lspci must be run as root user to get all available info. This guy had exactly the same card as you, so maybe yours does support fast writes - give this a look, and try it out if supported by your hardware. But he said: no noticable performance gain.

V

[eman_resu]

I tried some of those other options you posted. None of them caused any problems but they also didn't seem to make much of a difference, and the EXA thing actually brought me down 20 FPS., so I switched it back. Also, I checked and my card doesn't support fast writes. I get FW-. And I know FPS means frames per second, I was getting SPF, as in seconds per frame, I've never seen that before so I wasn't sure if it was seconds per frame. And I checked my bios for the system RAM thing. It's set to 1024 mb. and it doesn't look like I can change it.

So I think my xorg.conf editing is done. Thanks for all the help. Next I got to deal with partitioning problems and figuring out how to tri-boot, if that's a word. But, that's a different topic and a different thread.

Again, thanks for the help.