Page 14 of 14 FirstFirst ... 4121314
Results 131 to 140 of 140

Thread: ATI dropping support for <R600 - wtf!?

  1. #131
    Join Date
    Dec 2007
    Location
    Merida
    Posts
    1,098

    Default

    Recently I have been forced to use my old x800gto. Open source drivers work marvelously. For stuff that the regular user does on a daily basis they're more than enough. Movies, DE effects, games (most of then, and most certainly not WINE games), all function reasonably well. The advances being worked on will only make them better (3D speed, more complete support for newer chips, etc.). I can imagine most users or pre r600 cards being very happy with open source drivers.
    For me the only real advantage of fglrx is 3D optimization. Speed in 3D applications is always a good thing, and the more you have the better, and if this is of importance to you chances are you have a rather new card, which are in turn supported by fglrx. I really don't see what the big fuss is about, specially on the Linux side.

  2. #132
    Join Date
    May 2007
    Posts
    352

    Default

    Frankly, even though I don't typically use the fglrx drivers, I am disappointed in this move. For example, at the present moment doom3 is only playable with the arb render path with the open souce drivers and, even then, the performance is horrible compared to fglrx. quake4 is unplayable with the open source drivers due to a lack of support for decompressing s3tc textures on the card. libtxc_dxtn is available ( http://homepage.hispeed.ch/rscheideg...3tc_index.html ) but has issues with multitexturing on the r300 driver and makes nearly every texture in the game flicker. ut2004 also gains a huge speedboost from that library, but experiences the same problem.

    While I have no problems with AMD creating a legacy driver package that gets updated to support new servers and kernels, I think it's quite foolish to stop supporting them in the binary drivers altogether. Any users of those games on r300-r500 hardware (which are perfectly capable of playing those games on fglrx with good quality and performance) will be left in the cold when it comes time to upgrade their X server or kernel.

    Once those items get ironed out in the open source drivers, and the remaining issues such as power-management get resolved, I'm all for dropping the from catalyst.

    Adam

  3. #133
    Join Date
    Jan 2008
    Location
    Radoboj, Croatia
    Posts
    155

    Default

    Quote Originally Posted by Melcar View Post
    For me the only real advantage of fglrx is 3D optimization. Speed in 3D applications is always a good thing, and the more you have the better, and if this is of importance to you chances are you have a rather new card, which are in turn supported by fglrx. I really don't see what the big fuss is about, specially on the Linux side.
    3D optimization AND power management! And I think the power management is the most important feature that R300-R500 laptop users will miss until FOSS drivers start supporting it. I kind a expect this by June in Fedora 11, but I'm a bit too optimistic person .

    And about 3D optimization - I'm a bit sad I wouldn't be able to play Scorched 3D on my Radeon 9550R (R300 card) for a while - but I'm planning to solve this by not upgrading to Jackalope or Koala. Eventually I'm planning to put openSuSe 11.2 in November or December on that computer and by this time FOSS drivers will be using Gallium3D and will be more optimized for 3D than are today.

  4. #134
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,282

    Default

    OK, maybe I'm missing something here, but...

    We *are* moving the older GPUs into a legacy branch, which means you go from monthly releases to quarterly at best. That part is no different from what any other vendor does. Given that, the earliest date for the first quarterly release would be some time in June, with the next one happening some time in September (for example). Our decision was not based on the state of the open source drivers today, but our best guess about which approach will work out best at the time when the legacy driver updates would happen (let's stay with June 09 and Sept 09 for argument).

    That's the time frame I'm talking about when I say that the open source approach is likely to seem like the right decision, *not* today.

    The relative state of the open source and fglrx drivers *today* is only really relevent to the extent that the current state and current work-in-progress allow you to predict how the two approaches will compare later in the year.
    Last edited by bridgman; 03-08-2009 at 04:10 PM.

  5. #135
    Join Date
    May 2007
    Posts
    352

    Default

    Quote Originally Posted by bridgman View Post
    OK, maybe I'm missing something here, but...

    We *are* moving the older GPUs into a legacy branch, which means you go from monthly releases to quarterly at best.
    This is what the phoronix article says. Please correct me if it's wrong:

    AMD will be moving the R300/400/500 support to just a single legacy driver, but this branch will not be maintained. In fact, do not really look for legacy driver updates after April, as AMD does not intend to add support for newer kernel / X.Org server releases to this driver.
    Having a legacy branch that is never updated to support newer kernels and X servers is not much different from dropping support entirely.

    If you are thinking that the open source approach will be best approach come June or September, does that mean there are plans to tackle the s3tc issue in that time frame?

    Is there some sort of development roadmap that users can look at? Over the past few years, I've seen lots of "It'll be done when it's done" answers to questions about time frames for support of specific functionality. Does this mean that there are now official time frames for certain features? While the developers will sometimes give you best guess estimates, they are often off by months/years. Are you really that confident that the r300 driver will be up to par with fglrx in terms of 3D performance and power management sometime between June and September?

    Adam

  6. #136
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,282

    Default

    Quote Originally Posted by adamk View Post
    Having a legacy branch that is never updated to support newer kernels and X servers is not much different from dropping support entirely.
    Michael is writing from a purely Linux point of view. We have a single source tree which is used to support a number of OSes. The entire tree is being moved into a legacy branch, including the Linux code. Right now we only plan to make Windows releases off that branch AFAIK.

    Strictly speaking the common code in that branch *will* be updated but since we don't plan to make Linux releases off the branch it's easier to say "won't be updated" (or it just gets too hard to explain ).

    Quote Originally Posted by adamk View Post
    If you are thinking that the open source approach will be best approach come June or September, does that mean there are plans to tackle the s3tc issue in that time frame?
    It's odd, but s3tc has never really come up in discussion. Let me look into it. I think you're saying that the app is expecting the driver to *compress* textures, not just decompress them ? Presumably these are dynamically drawn textures, since static textures would be stored compressed in the first place, wouldn't they ?

    Quote Originally Posted by adamk View Post
    Is there some sort of development roadmap that users can look at? Over the past few years, I've seen lots of "It'll be done when it's done" answers to questions about time frames for support of specific functionality. Does this mean that there are now official time frames for certain features? While the developers will sometimes give you best guess estimates, they are often off by months/years.
    I don't listen to best-guess estimates any more

    The sequence of events is pretty well defined right now, since the remaining integration tasks pretty much have to happen in a certain sequence, so that's the sequence in which each of the new initiatives will transition from "science project" to "real". KMS/GEM/TTM first, then DRI2/RDR, then power management and Gallium3D work can happen in parallel.

    No official dates, but we don't release official dates for new features in fglrx either.

    Quote Originally Posted by adamk View Post
    Are you really that confident that the r300 driver will be up to par with fglrx in terms of 3D performance and power management sometime between June and September?
    Nope, not at all.

    I am fairly confident that ON BALANCE the open source drivers will make a larger chunk of our user base happy than fglrx would with reasonable legacy updates.

    Improvements to 3D require big changes but a lot of that work is well underway. For me the big milestone was seeing Gallium3D merged into master; I agree that's a totally arbitrary and fudgeable milestone but I do have a lot of confidence in the people behind the decision.

    Power management is easier by comparison, since the required info has already been released and the major obstacle is waiting for churn in the kernel to settle down so power management code can be built on top of all the other new stuff.
    Last edited by bridgman; 03-08-2009 at 05:08 PM.

  7. #137
    Join Date
    Oct 2007
    Posts
    16

    Default

    Will you round up to the nearest 100?
    r580 is close enough to r600 right?


    Yeah I know, no such luck.
    My main concern is if I'll be able to use Windows 7 when it's released.
    Last edited by MikeEx; 03-09-2009 at 08:42 PM.

  8. #138
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,282

    Default

    You should be fine for Windows 7 -- Win 7 will use existing Vista drivers (the WDDM 1.0 interface).

    Native drivers for Win7 (WDDM 1.1) require DX10-capable hardware, ie R600 or higher.

    No rounding allowed there AFAIK.
    Last edited by bridgman; 03-10-2009 at 12:31 AM.

  9. #139
    Join Date
    Jan 2009
    Posts
    66

    Default

    This also means that upcoming Windows 7 users... won't be able to use the R300-R500 GPU's ... at all. There might be a basic driver provided by Microsoft, but they won't be getting updates. There will be no driver path.
    Win7 users with legacy cards will still receive quarterly driver updates.
    They won't miss anything (Aero,DirectX 9Ex) with these drivers.
    Last edited by tuxdriver; 03-10-2009 at 03:24 AM.

  10. #140
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,282

    Default

    Yep, and Microsoft is committed to making sure that existing Vista drivers work well with Win7.

    The native driver interface for Win7 requires DX10-capable hardware, so we won't be making Win7 native drivers for 5xx and older GPUs.

Posting Permissions

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