Page 3 of 7 FirstFirst 12345 ... LastLast
Results 21 to 30 of 65

Thread: Unreleased ATI Catalyst Driver Appears In Ubuntu

  1. #21
    Join Date
    Mar 2007
    Location
    DG, IL, USA
    Posts
    192

    Default

    Quote Originally Posted by bridgman View Post
    As far as I know all those distros have access to pre-release drivers already through the beta program.

    None of those distros *ship* binary drivers though, do they ? I think that's the essential difference here.
    Mandriva usually provides several flavors of One cd's for beginners with the option to install live and configure their cards with the proprietary drivers.They also provide the same option for Powerpack subscribers..

    Since cooker is using both kernel 2.6.29 and Xorg 1.6 I doubt any of next months releases will ship with an ATI(proprietary) driver..Most likely it will be available a day or 2 after AMD officially releases the 9.4's as an update.I've seen the kernel patches in Phorogit..

    Legacy owners shouldn't be too bad off with the open driver..on my x800pro I was able to run UT2k4 and get over 30fps on some maps as long as they had fog like Tokera Forest.. other maps were fairly dismal at 10 fps and under.

    I'm just happy to know that at least internally someone's is testing it out at Mandriva. I'd hate to have to wait until June or so to enjoy whats shaping up to be a good release.
    Those who would give up Essential Liberty to purchase a little Temporary Safety,deserve neither Liberty nor Safety.
    Ben Franklin 1755

  2. #22
    Join Date
    Mar 2009
    Posts
    51

    Default

    This driver is performing well, I think this is the best ATI driver I have used so far. Hope this is a sing of improvement from the decision of dropping old chips support from the catalyst driver. At least we don't need the symlink to /usr/lib64 anymore. And my performance have improved considerably. For the first time I'll say, good job AMD, and keep improving, please try hard to.

  3. #23
    Join Date
    Mar 2009
    Posts
    11

    Default

    I made an ebuild in the gentoo-quebec overlay for Gentoo Linux.

    This stuff compile and install but I have not tested them because i'm at work.

  4. #24
    Join Date
    Mar 2009
    Posts
    5

    Default

    Quote Originally Posted by bridgman View Post
    As far as I know all those distros have access to pre-release drivers already through the beta program.

    None of those distros *ship* binary drivers though, do they ? I think that's the essential difference here.
    This driver was not announced on the beta program, it just appeared in Ubuntu's repositories, just like the previous Ubuntu release when xorg-server 1.5 was shipped.
    Besides not getting drivers via the beta program, there's an agreement you'll have to sign to join this program. The agreement contains something about not leaking prerelease drivers.

    Archlinux used to ship binary drivers for both Nvidia and AMD, but as AMD doesn't take distributions other than Ubuntu serious, we decided to drop it.

  5. #25
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,283

    Default

    Ahh, sorry... we were talking about two slightly different things. I didn't consider this specific driver a pre-release since AFAIK it was targetted for Jaunty rather than being a beta release of a regular Catalyst driver. We do the same with some OEMs when they pre-load Linux on their products, when their schedules don't quite line up withour regular release schedules.

    I agree that is a semantic nuance, but it is what I was thinking when I made that last post.

    Also, Ubuntu is a relatively recent addition to the list of distros we work with. Until a year or so ago we primarily worked (in the sense of trying to coordinate release planning) with RHEL and SLES/SLED, since those were the primary distros used by our workstation customers. We are gradually expanding that list based on customer feedback.
    Last edited by bridgman; 03-20-2009 at 08:50 AM.

  6. #26
    Join Date
    Mar 2009
    Posts
    51

    Default

    This is just a joke, nvidia doesn't even work side by side with any distribution (maybe they do, but doesn't come to the case) and their drivers works flawlessly in every distribution there is. Even if I go out and create a distribution right now, there is a 95% chance the nvidia driver will work. There is a far wider difference in commitment to the community and quality of releases.

    The day we see AMD is serious about Linux in general and not about only less than 5 distributions, then I will personally add the drivers officially to Arch Linux.

  7. #27
    Join Date
    Jul 2008
    Posts
    314

    Default

    Well, you can't blame the dev team stuck with the resources they have for trying.

    I don't think the binary blob will ever be good enough for Arch, so hopefully realising that, and encouraging people to use the OSS driver, will help make the binary blob obsolete sooner

  8. #28
    Join Date
    Mar 2009
    Posts
    51

    Default

    Quote Originally Posted by grantek View Post
    Well, you can't blame the dev team stuck with the resources they have for trying.

    I don't think the binary blob will ever be good enough for Arch, so hopefully realizing that, and encouraging people to use the OSS driver, will help make the binary blob obsolete sooner
    I blame AMD. Is not an Arch Linux situation is a situation of all the other distributions but the ones supported which are less than 5. And we have done that already, the trashy driver got removed from the official repositories, OSS drivers, are encouraged above all right now.

    AMD have to provide quality drivers to their customers, period. Don't get me wrong I am a fan of AMD processors and I buy nothing more but AMD processors. I have a lot of them around, and all my machines runs on them.

  9. #29
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,283

    Default

    I guess I don't really understand why this has to be a blame-fest in the first place. We've made no secret about being focused almost entirely on enterprise distros until fairly recently, or that we were going to be *gradually* ramping up support for consumer users and faster-moving distros. Ubuntu was next on our list because it is pretty popular both for end users and for OEM customers who preload Linux on their products. We see the preload business as being an important one not just for our own business but for the growth of Linux in general - maybe that makes us evil again, I don't know.

    I have to beg out of any arguments about symlinks; I don't like them myself, but I didn't think they were regarded as such a terrible thing in the Linux world. Again, maybe I'm missing something. Either way, if you want to make a statement and say "we don't like having to symlink and we're going to stop packaging your driver until you give us a better solution for non-multilib 64-bit" that's absolutely your call.

    I have a tough time with some of the comments about "no idea about what is coming"; I'm on the beta mailing list and every week I see new alpha and beta drops which tell you what will be coming down the pipe a month or two in the future. Are you saying that's not giving you enough advance warning ? Today's beta gave a pretty good idea about the features which will be released a month or so from now, for example.

    As far as server 1.6 support and your decision to go ahead without waiting for Catalyst drivers, I don't see what the fuss is about. It's your call as distro developers to decide what to include, and if one of our drivers happens to be the last thing stopping you from releasing 1.6 into test then it makes perfect sense to go ahead without us (assuming it's not just a few days). I just don't understand why it has to be a big spectacle -- I would have just said "hey folks, we're going to release server 1.6 for test and not wait for the Catalyst driver this time, we think that's better".

    I know that it was awkward for fast-moving distros having to deal with just the binary drivers, and that's one of the reasons we started investing in open source drivers again. I hope the situation is a lot easier for distro packagers this year -- we have working open source drivers for all of our shipping chips, and those drivers are often being used to develop the next round of kernel and x server releases. You have to admit there have been a lot of improvements on the fglrx side as well -- the long delays from new GPU release to fglrx support are gone completely, and we're supporting new X server releases a lot more quickly as well.

    We haven't quite caught up yet, so when a scheduled distro release happens just before we're ready with general support we do try to work directly with the distro to get a driver in which at least has been tested on that one distro. Hopefully a few months from now that won't be necessary either, and that should start to improve the fglrx schedule fit with rolling release distros as well.

    Anyways, I hope this all gets worked out. If you can look at the other improvements we have been making over the last few months and honestly say that a non-symlink solution for your 64-bit distro was a higher priority for our average user, please let me know and I'll try to change our planning process accordingly. We are trying to roll out the improvements that affect the largest number of users first but that really isn't intended as a snub against Arch or any other distro, and I'm sorry if it seems that way to you or anyone else on your team.
    Last edited by bridgman; 03-21-2009 at 12:24 AM.

  10. #30
    Join Date
    Mar 2009
    Posts
    27

    Default

    Oh, there is AMD developer in this thread
    If you are writing about fglrx prorities, i want to add my two cents to discussion.
    This priorities and way you work on fglrx drivers (dont misunderstand me, i think that you guys made great progress within last few months). You repair bugs one by one, when there is somewhere one large bug causing other bugs, or piece of driver needs complete rewrite. Thats somewhat silly. because now you work in this way: there was shi*ty video tearing problem year ago, so within a year you repaired one hundred video bugs, removing one hundred video tearing types (it looks so from perspective of end user, which checks all changes between driver releases), and users are still suffering from 101 video tearing type. When you should completly rewrite video part of drivers, you could do this in few months and it would be bug free, with less work from your side. The same problem is with distro support. You add support for different distros or even distro versions one by one, where you could do standards compilant driver, and update it only to new kernels and xorg versions.

    Last thing i want to mention, when you are already reading this forum, is linux technologies compatability. Linux comes with many great technologies like Mesa, KMS, Gallium3d, Xv, etc. This should be absolutely priority for fglrx drivers to be compatabile with them, and not make own workarouns and solutions (like libGL now). Thats really pain in the a** for end users and propably also developers of gfx software, when users of all gfx cards use one libGL.so, except Ati users which use another libGL.so. Even xorg.conf handling in fglrx isnt really compilant with other drivers, there are problems with simplest things like setting vrefresh,.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •