Installing latest Open Source ATI drivers under Ubuntu 8.04

[tormod]

desperate lol ! That would be back to square one However, this one was easier to fix. We now have a libxi that really includes XInput.h, rebuilt xserver, -evdev and -synaptics drivers. Seems to work fine.

The first -evdev I tried complained about CARD8, which is now defined in Xmd.h, so I patched -evdev to #include it. I could also upgrade x11proto-xext-dev to fix this the proper way, but since xext is on the bottom of the stack, I will not touch it right now. Just for information if someone compiles something and stumbles into this...

[gordboy]

Not A Good Experience

I just tried to install the new radeon driver etc on Hardy too. I used the xorg-edgers repo, and yes, I did read the usual disclaimer.

There are broken dependencies, with XInput.h causing problems, as it now exists in 2 packages at once. This left my system in an unusable state, as half of the packages were not installed. I had to manually restore all the packages to the state they were before. Woohoo, I love spending time fixing things that should never have been broken in the first place.

It is simply not good enough to say : We Don't Offer Any Guarantees Here. Nor is it good enough to say : Well Why Don't You At Least Use Intrepid. The fact of the matter is this - on this and other forums, people are being encouraged to help the testing and evaluation process, by trying things out and reporting any observations, or even, heaven forfend, bugs.

This is not going to be possible if the repos are in an inconsistent state. So what I suggest is this - either completely REMOVE the hardy packages/repo, or fix the inconsistencies.

There is also the grave matter of moving files between packages. This is simply unacceptable. While I don't expect perfection and flawless operation of new code, I surely don't expect the packages to break an entire system, by that cavalier and disgraceful practice. If there are any file conflicts between competing packages, then you are supposed to either make diversions, or make sure that no such conflicts exist in the first place.

I was lucky. I know how to admin my system, and can repair things if absolutely necessary. Which places me in a very small minority of Linux users. Other people will simply give up on Linux entirely, when faced with such difficulties.

On the plus side (!), it is good to see that the open source side of ATI things is really picking up speed. Let's not spoil things by making the whole development process look shoddy and feckless.

[val-gaav]

I was lucky. I know how to admin my system, and can repair things if absolutely necessary. Which places me in a very small minority of Linux users. Other people will simply give up on Linux entirely, when faced with such difficulties.

IMHO only this small minority (and I would argue it's not that small) should be using bleeding edge things. If you don't know how to repair your system then you shouldn't use anything beside the stable branch, that is unless you are willing to learn how to repair it.

[Porter]

I've got an odd one with the latest drm-modules and xorg-edgers updates on an ATI X1550 card. Everything works fine with the default settings (XAA), system is stable and runs as normal.

Enabling EXA in xorg.conf causes X to crash, however... but only AFTER booting up fully, displaying the desktop, loading menu bars, etc... it appears that everything is going to be fine and then boom, X crashes and Ubuntu does its typical over-and-over attempts to start X and fails.

Has anyone else run into this? I'm thinking it may be a specific userspace package of some kind that is crashing the party. I didn't see anything in the Sessions startup list that looked suspicious, though. I'm not running compiz.

[d2kx]

Does anyone else have the problem that (K)Ubuntu 8.10 doesn't stop requesting EDID information? My Xorg.0.log is getting longer and longer and longer, but the driver (self compiled RadeonHD 1.2.4 with EXA and DRI enabled) is running fine. I've got the same problem with Radeon 6.9.0 which is the default one I think...

[Kano]

You just found out, that Kubuntu 8.10 is calling xrandr every 10 s - when you use a CRT then it will even flicker every 10 s. Ubuntu 8.10 usually does not behave that way.

[oibaf]

tormod, I noticed that the latest xorg-server - 2:1.5.3+git20081216+server-1.5-branch.4970d757-0ubuntu0tormod1 for intrepid breaks Xv under compiz. Maybe there is a problem with the backported EXA patches included in the latest release?
EXA performance with this latest version appears also to be the same of the previous version.

Fedora also has backported EXA from 1.6. Patches can be found here:

http://cvs.fedora.redhat.com/viewvc/rpms/xorg-x11-server/F-10/

EDIT: sorry, ignore this post. I thought I was using EXA when in fact I still had enabled XAA . It works fine with EXA .

[gordboy]

Good Work

I've been playing with the latest "radeon" driver 6.10 on my x1650 under Hardy with xorg-edgers DRM/drivers/libs etc and it is very nice. 2D & 3D acceleration work fine and so does XV. Seems to be very stable, but there is one little quibble. The P word.

Performance. Hopefully this will pick up as all the main areas become glitch-free. And I do agree - get it right, then make it fast. I waited a *long* time for the CLGD-5434 cirrus driver to be stable and good, lets hope the radeon driver finally comes of age this year, and we can kiss another binary "blob" goodbye.

My criticisms of the xorg-edgers packaging process still apply since the conflict with x11proto-input-dev has not been fixed yet. But this is a small point I guess, since hardly anyone here actually does any X development work, and so wouldn't be affected ...

Well done to the primary developers. Job Well Done.

[bridgman]

What aspect of performance are you talking about ? If you're talking about 2D, then enabling EXA acceleration should help.

[gordboy]

Performance

I am the lead developer of an ALSA/openGL 3D audio spectrum analyzer, and I am constantly looking to push the frame rate and number of time slices to breaking point. The main graphics operations are drawing several tens of thousand vertical line segments per frame (and several tens of frames per second).

All of this frame drawing has to get done before the next audio buffer is ready to be read, to avoid drop-outs and ever-increasing glitchy badness. So when there is badness, this is down to doing "too many" graphics operations, in the available time.

The frames are drawn in one go, by the use of vertex arrays, and pre-scanning of the Y values, such that only the visible lines are actually drawn. The name of the game here is keeping the graphics time to a minimum. There are real-time constraints that limit how much can be done during each frame, before the ineluctible tick of the next buffer interrupt.

Although radeon 6.10 is nice and stable (for me, at any rate), I think we could see another 80-100% speed improvement here, compared to fglrx 8.09. Although I would use 6.10 over fglrx any day, because of all the stability issues.

I noticed that the Hyper-Z option in driconf is not there any more since I switched from the trusty old 9200se, presumably this is not needed for rv5XX.

Anyways, driver config -

Section "ServerFlags"
Option "AIGLX" "off"
Option "AllowEmptyInput" "off"
Option "AutoAddDevices" "off"
Option "AutoEnableDevices" "off"
EndSection

Section "Extensions"
Option "Composite" "disable"
EndSection

Section "Device"
Identifier "Videocard0"
Driver "radeon"
VendorName "ATI"
BoardName "ATI Radeon X1650"
Option "EnablePageFlip" "on"
Option "AccelMethod" "EXA"
Option "AccelDFS" "on"
Option "EXAVSync" "on"
EndSection

################################

With EXAVSync off, I can get another 3-5% frame-rate improvement before it gets glitchy and jumpy, so I elected to take the small hit, in return for the XV niceness.

One final point/question. And this is about realtime kernels and the dev.rtc.max-user-freq sysctl settings. I was wondering if there were trade-offs in having low-latency (and thus much more regular in the "ticking" sense, i.e. low variability of system call completions) audio - versus - graphics throughput/performance.