AMD 8.42.3 Driver Released -- The Baby Is Born!

[Berniyh]

i've always had them but i still used to get that problem. now i'm curently trying that hwcursor with opengloverlay on and it seems to go on quite well. the problem is that i have problems running xv on xine or mplayer and some files turn to opengl, thus verrrrrrryyyyy sloooooooow...

If the OpenGLOverlay would be the problem that would be very odd, because it is only used for multimedia apps and I've not run any multimedia apps today so far.

[givemesugarr]

If the OpenGLOverlay would be the problem that would be very odd, because it is only used for multimedia apps and I've not run any multimedia apps today so far.

i didn't say that that is the problem. i've only said that i'm using the opengloverlay set to on and the hwcursor to on and till now (3 hours and 47minutes i didn't have any sign of that annoying stuff). i've also been using firefox for the same time and still haven't had that issue. there's a great possibility that this is only some coincidence, but it still may be not. or it may be that i've just upgraded to firefox 2.0.0.8 from 2.0.0.6 (i've only had that issue after some right clicking in firefox not from other apps so it can also be some gtk+-kde or gtk+ bidings problem since firefox is a gtk+ app). i don't know yet if this is the solution. you can give it a try if you want and see what happens.

[EnderWiggin]

I've been having some mixed success with the driver. It's been awhile since I ran XGL, but I am fairly certain that XGL was faster and smoother than the AIGLX implementation on this driver. I have had some luck with various tweaks to the driver options in xorg.conf, but I don't know all the available options to try. Does anyone know where to find ALL of the xorg.conf params that would affect this device. I want to see how much tuning I can to and to what help they would be.

I think this driver is exactly where most of us expected it to be. Moreover, it is about the level it should be at considering the maturity of this new code base from ATI. It did deliver on the AIGLX extensions and some other performance improvements as promised, but as with any new release of this size, there are integration bugs (some significant). Even the Linux kernel follows this release methodology, where some releases are marked as "stable" releases which have less new content and have been tested thoroughly. These are then maintained separately from the mainline until the next stable release with bug fixes back ported where necessary. I believe 2.6.20 was the last "stable" release, where 2.6.21-2.6.23 all delivered significant content updates (new scheduler, new allocator, tickless kernel, etc.) each with their host of associated bugs. So to that end, I think ATI did the right thing releasing the driver now. As with all "early adopters", it's up to us to find the pain points and pass that feedback back to ATI so that 8.43 will be better. Realistically, I doubt this new code base will be stable until 8.45 or 8.46.

If we want to hold ATI to a monthly release cycle, we have to expect some significant bumps in the road. If we want every release to be perfectly stable while also delivering new content, then we would have to accept longer release cycles that give ATI more time to test internally. I think that ATI's methodology is very in line with modern development practice. The only think they could add would be to mark some releases as stable and back port bug fixes, but that requires resources which are likely already committed to driver development. Hopefully in the future they will adopt this paradigm.

ATI's commitment to Linux seems genuine but their ability to test and develop drivers is always going to be limited to resource availability and funding. Whining or complaining that the driver isn't what you expected won't help with either and will only frustrate everyone else on the list.

[givemesugarr]

Does anyone know where to find ALL of the xorg.conf params that would affect this device. I want to see how much tuning I can to and to what help they would be.

i'm also looking out for them. i recall to have seen some setting for igp boards that let the driver get a different ammount of vram (as in the windows catalyst where i can chose an amount from 1/2 to 2 times the original reported vram) and i'd be interested in finding it since i've seen that fglrx says that my aperture is limited to 256MB of vram, that is 2x the actual memory. if i can use more memory i should have a better experience, or at least i think so.
i've tried to set it to 256 on windows and it ran smoother and i could adjust a little better the video settings.

(**) fglrx(0): ATI GART size: 256 MB
(II) fglrx(0): [pcie] 258048 kB allocated with handle 0xdeadbeef
(II) fglrx(0): [drm] DRM buffer queue setup: nbufs = 100 bufsize = 65536

[Cerebral]

Realistically, I doubt this new code base will be stable until 8.45 or 8.46.

In which case the driver should come with a note that it is unstable. The kernel guys tell us which are stable releases - why can't AMD? They did it well enough with 8.41. Actually, I'm also curious, like many in this thread, why there hasn't BEEN a direct announcement by AMD on their site yet.

If we want to hold ATI to a monthly release cycle, we have to expect some significant bumps in the road.

AMD set that release cycle for themselves, and we have to suffer by expecting them to hold up their end of the bargain? If they want to devote more time to each release, then they should, and say that's what they're doing, plain and simple. We're not holding them to anything they haven't decided for themselves.

I think that ATI's methodology is very in line with modern development practice.

Releasing code with clear memory issues (glibc double-free?) isn't very much in line with that.

ATI's commitment to Linux seems genuine but their ability to test and develop drivers is always going to be limited to resource availability and funding.

I find it hard to believe AMD would have trouble getting the resources - they make the cards, and likely test their windows drivers on them all. Funding I'd believe - they might not have the money in the budget to invest the man-hours, who knows?

Whining or complaining that the driver isn't what you expected won't help with either and will only frustrate everyone else on the list.

While I've been generally disagreeable in this reply, I do agree with this statement. However, I don't think it's wrong for people to expect no on-screen corruption, no memory errors, or a driver that at least works, even if performance sucks.

8.42 has on-screen corruption, glibc double-free stack traces spewing out, and for some people just doesn't plain work at all. I have to disable Composite or my computer locks up when I try to quit X with this version. That's why it's been disappointing, especially given the hype that's been generating around this release.

Regardless, and call me a hopeless hopeful if you will, I still have faith in 8.43.

[Berniyh]

i didn't say that that is the problem. i've only said that i'm using the opengloverlay set to on and the hwcursor to on and till now (3 hours and 47minutes i didn't have any sign of that annoying stuff). i've also been using firefox for the same time and still haven't had that issue. there's a great possibility that this is only some coincidence, but it still may be not. or it may be that i've just upgraded to firefox 2.0.0.8 from 2.0.0.6 (i've only had that issue after some right clicking in firefox not from other apps so it can also be some gtk+-kde or gtk+ bidings problem since firefox is a gtk+ app). i don't know yet if this is the solution. you can give it a try if you want and see what happens.

No, it certainly isn't the solution.
HWCursor doesn't help for me, because that is standard (I'm always using HWCursor.).
Yesterday I also had a time of several hours, where this garbage didn't appear, so you can't really be sure unless it didn't appear for let's say 2 days or so.

BTW, this is not a problem of some software (KDE, Firefox or whatever).
This is a problem of the driver, because if you make a screenshot, it is not there.

[Berniyh]

i'm also looking out for them. i recall to have seen some setting for igp boards that let the driver get a different ammount of vram (as in the windows catalyst where i can chose an amount from 1/2 to 2 times the original reported vram) and i'd be interested in finding it since i've seen that fglrx says that my aperture is limited to 256MB of vram, that is 2x the actual memory. if i can use more memory i should have a better experience, or at least i think so.
i've tried to set it to 256 on windows and it ran smoother and i could adjust a little better the video settings.

A lot of options can be found here:
http://debian.wgdd.de/temp/fglrx_man/fglrx.4x.html

[Fenix-TX]

Did you make sure to uninstall the xgl server? In gutsy after you install it the package starts automatically with gnome.

Ohh!! I didn't know that!!! That waas the problem. Thanks!!!!

EDITED: Wow! This driver is very very great!

[rapsure]

The bugs in the 8.42.3 driver are as follows for an ATI RADEON X800XL video card: No XV by default, unstable (computer locks up daily on the driver), Vesa console doesn't work and results in a black screen for the terminal. DVI output will cause the system to freeze. The driver does have features, but the R300 driver isn't very far off. My computer has been locking up daily with the fglrx 8.42.3 driver.

For the opensource Radeon driver there needs to be about five opengl extensions added to make the game ET:QW work. After that Render accel needs to implemented for a fast 2D desktop. Oh, and the opensource driver supports XV, and system stability, and isn't fussy with the Vesa console nor with the DVI output. For anything older than a Radeon X850 the radeon driver will work, and give decent performance, and the one thing I like a lot, stability.

[Trek1701]

Hi again,

On my last two posts I spoke about the "white screen" problem. I get this with both compiz and beryl.

Looking At beryl, the default is "--use-tfp" (Pixmap Texture) then I've changed to "--use-copy" and the white screen problem vanished but the effects got really slow.

So, I'm having a problem in texture from pixmap. I really have no idea on what does it mean.