ATI dropping support for <R600 - wtf!? [Archive] - Page 2

Saist

03-07-2009, 09:58 PM

Yes, but the point is that ATi has never fully supported any card released.

Why should I not believe that in three years ATi will also drop driver support for R600, R700, and R800 to focus more resources on R900 without ever fully supporting the former?

um. I'm not even sure where to start with how wrong this idea is. Apparently I haven't gotten the message across.

Stop the generic F.U.D.

Stop the wholesale "fully supported" F.U.D.

Start listing exactly what is wrong.

Start listing what distribution you are using.

Start listing what kernel version you are using.

Start listing what X.org version you are using.

Start listing the exact link to the ATi bugzilla where you filed a bug report on the problem.

Start listing the steps you took to duplicate the problem.

Start detailing how you, personally, got involved to solve the problem.

Otherwise your arguments are hollow. There is no reason to believe you. There is no evidence to support what you say. I'm to the point that I am going to personally start picking people out and ripping their posts to shred.

The F.U.D. stops here. It stops now. Either get involved with the driver development, or get lost.

And from your post, you need to get lost.

duby229

03-07-2009, 10:10 PM

.....

See now that is going a bit too far. It's OK to be an advocate of something. I openly advocate open source, but to say that your going to rip peoples posts to shreds is a little schizo.

Qaridarium

03-08-2009, 01:10 AM

The F.U.D. stops here. It stops now. Either get involved with the driver development, or get lost.
And from your post, you need to get lost.

FUD :-) Drop R300 and R500 is a good starting point to make a good driver for HD2000,HD3000,HD4000.

the biggest FUD is thats the 9-4 has no R300 and R500 part in it!

fglrx -8.60 (9-4 alpfa) has R300 and R500 Parts!

but yes up to the cat 9-6 its deaktivatet!

but i think the R300 parts is Hackable .---

so you can hack the 9-4 for a R300 but its Pointless.

becourse 9-6 has R300 parts aktivatet!

deanjo

03-08-2009, 01:44 AM

FUD :-) Drop R300 and R500 is a good starting point to make a good driver for HD2000,HD3000,HD4000.

the biggest FUD is thats the 9-4 has no R300 and R500 part in it!

fglrx -8.60 (9-4 alpfa) has R300 and R500 Parts!

but yes up to the cat 9-6 its deaktivatet!

but i think the R300 parts is Hackable .---

so you can hack the 9-4 for a R300 but its Pointless.

becourse 9-6 has R300 parts aktivatet!

So was it just you or your whole family that took the short bus?

Mr_Ed

03-08-2009, 05:14 AM

Hi,

My RADEON 9600 XT/TVD has no tuner, but it does have view/capture capabilities through the provided s-video/composite video connectors.

In the past I was able to view video from a hooked-up video or camcorder device in linux using xawtv with the xvport parameter.

The current open source driver does not seem to support this anymore although I see entries in the xorg.log like below:

(II) RADEON(0): Cannot access BIOS or it is not valid.
If your card is TV-in capable you will need to specify options RageTheatreCrystal, RageTheatreTunerPort,
RageTheatreSVideoPort and TunerType in /etc/X11/xorg.conf.
(!!) RADEON(0): For information on using the multimedia capabilities
of this adapter, please see http://gatos.sf.net.

Can I enable the xvport options again by setting one of these parameters?

Is there some documentation available about these parameters?

regards,

E.

Wyatt

03-08-2009, 06:39 AM

See now that is going a bit too far. It's OK to be an advocate of something. I openly advocate open source, but to say that your going to rip peoples posts to shreds is a little schizo.

No...I think that's actually a fairly natural reaction to people behaving like thoughtless malcontent mouthpieces across multiple threads. Regardless of whether you consider yourself part of our little "open source community," if you're using it, you're in. In this community, it tends to be the case that if you are not part of the solution, you give up your right to seriously complain.

Geek technocracy? Yeah, we founded it. Never going to take off and get mainstream? Many of us hoped it wouldn't. Insular? You betcha. Obstinate? Oooh baby.

But, that's pretty much how it is. Is it really so surprising that when someone tries to beat the "system" we tell them to beat feet, be patient, or make themselves useful?

Mr_Ed

03-08-2009, 07:03 AM

Yes, but the point is that ATi has never fully supported any card released.

Why should I not believe that in three years ATi will also drop driver support for R600, R700, and R800 to focus more resources on R900 without ever fully supporting the former?

As far as I know, they will continue their efforts they put in the open source driver dev.

And I don't know if you tried that one already, but I did and I must say that it has made great improvements.

The open source driver already delivers EXA instead of XAA.
Although it is still slower then the fglrx, it is able to deliver tearing free xvideo in a composited desktop environment.

Lets hope that this progress will continue in the future.

yotambien

03-08-2009, 07:05 AM

No...I think that's actually a fairly natural reaction to people behaving like thoughtless malcontent mouthpieces across multiple threads.

Indeed. I personally don't have any problem with people disagreeing as much as they want as long as their arguments are remotely based on something else than pure ignorance. But lately these guys have managed to convert Phoronix in the bastard child of the Ubuntu forums.

Stormking

03-08-2009, 07:32 AM

The F.U.D. stops here. It stops now. Either get involved with the driver development, or get lost.
Who are you to give commands like this? Owner of this board? Leader of the world? I think you take yourself way to serious. I think the people who have been betrayed by ATI, constantly - and now one last, big time - have the right to express their anger. Are you such an ATI fanboy that criticism to their decisions is a personal offense for you?

So please lay out in detail, how dropping the support for R300 - R500 is not a step backward - maybe temporary, but still - for owners of this hardware. How shall I see this as a positive thing? Tell me, please!

DoDoENT

03-08-2009, 08:11 AM

I think the people who have been betrayed by ATI, constantly - and now one last, big time - have the right to express their anger. Are you such an ATI fanboy that criticism to their decisions is a personal offense for you?
What do you think ATi betrayed anyone? They're still giving a support for their cards, although through open source driver.

So please lay out in detail, how dropping the support for R300 - R500 is not a step backward - maybe temporary, but still - for owners of this hardware. How shall I see this as a positive thing? Tell me, please!
Maybe it is a step backward for people who use bleeding edge distributions which ship with the newest XServer that is not supported for R300-R500 cards with fglrx. But those people are used to having a buggy software and don't complain, but try to fix the thing. OTOH, people that prefer more stable distributions can use fglrx 9-3 for a long period of time (think of Ubuntu LTS or Debian), and within that period, open source drivers will evolve into a quality software. So, this ATi's move might be a step backward for you only if you choose to step backward (by installing the newest distributions).

DirtyHairy

03-08-2009, 08:47 AM

Watch out, angry ATI customers, forum trolls, linux ecosystem parasites, creatures of the night - Saib the Ripper is out there to tear your posts to shreds :)

Honestly, that's a bit too much fanatism, is it? As for constructive criticism, saib, please reread my posts carefully and then detail me in what ways the issues I have had with the closed source drivers are mere trolling, related to my setup (gentoo stable, no funky stuff) or incompetence (been using linux for nearly 7 years and consider myself an experienced user whoe DOES contribute back in the form of help in forums, bug reports and occasional patches). Also detail me in what way the opensource driver in its current states improves the status of my hardware over fglrx NOW, not in one year. And, while your're at it, please elaborate on in what way you are supporting the "linux ecosystem" and which ecological niche you are living in: bug reports? maintaining packages? developing code? writing patches? documentation?

Stormking

03-08-2009, 09:43 AM

And, while your're at it, please elaborate on in what way you are supporting the "linux ecosystem" and which ecological niche you are living in: bug reports? maintaining packages? developing code? writing patches? documentation?
Eating critics. Alive.

cutterjohn

03-08-2009, 10:32 AM

Just to be clear here; for Windows we are doing exactly the same as NVidia; shifting to a legacy branch and then updating the drivers on a slower schedule. For Linux, we have already decent open source drivers (an option not available to NVidia today) and most people switching to the open source drivers have ended up preferring them, so we're focusing on continuing to improve the open source drivers rather than maintaining a legacy branch of fglrx.Ah, the way that I had originally read other reports was that ALL development for older GPUs was halted, including Windows. This is somewhat better.

Not too sure about the OSS drivers myself, as I coerced Ubuntu 8.10 64b to install on the GT725(4850 mobility radeon), and it was like a blast from the past:
text installer

X.org failed to start(some sort of EDID problem as it was using VESA driver or trying to)

manual network config (had to, as the catalyst package required dpkg-dev)

built catalyst package for ubuntu 8.10

Then there was X.org happiness sort of. (Google Earth flickers like mad whenever the windows are updated, opengl windows leave their content behind when moved until dropped, etc.)

bridgman

03-08-2009, 10:37 AM

So please lay out in detail, how dropping the support for R300 - R500 is not a step backward - maybe temporary, but still - for owners of this hardware. How shall I see this as a positive thing? Tell me, please!

Just to be clear, we're changing support level for all OSes, not just Linux. There's no new OS support for Windows either, although in fairness the impact on Windows users is less because Windows tends to keep ABI compliance and also releases new OS upgrades at a much slower rate.

We're not trying to paint this as something positive for users of the GPUs whos support levels were reduced, but I also think you'll find it's much less negative than you think. One recurring message through your posts is that providing support via the open source drivers is somehow cheating because of community involvement, and that we should be forced to do all the work ourselves -- do I have that right ?

Obviously people with 6xx/7xx GPUs might be happy because the folks working on their parts will have more time, but I realize that doesn't do anything for you.

We could task resources to keeping fglrx running on newer X, kernel and distro versions rather than working on open source drivers but in all seriousness I don't think that would make more than a couple of people happy. I think most users of 3xx-5xx parts are looking for ongoing improvement in new features (EXA, DRI2, KMS for suspend/resume etc..), not just compatibility with new distros and occasional bug fixes. The open source drivers can deliver that, but a legacy fglrx branch can not unless we double the team size (again).

DirtyHairy

03-08-2009, 11:22 AM

One recurring message through your posts is that providing support via the open source drivers is somehow cheating because of community involvement, and that we should be forced to do all the work ourselves -- do I have that right ?I don't think the reasoning behind this is so strange or difficult: if you tell me that ATI/AMD is actively working on code being pushed into the opensource repositories to ensure that the hardware dropped from fglrx will be supported to the level fglrx promised (perhaps modulo some 3D performance which I believe you is unavoidable) independently of how much other parties not payed by ATI get involved, then I happily stand corrected and retract my criticism on that. However, if this is not the case, then, at least for me, the ugly aftertaste is the impression that ATI/AMD is offloading the responsibility of creating a proper driver to other parties, something which is not what I would call proper support even if it eventually leads to working hardware and happy users.

It's not a matter of doing all the work yourself, but of not relying on the assumption that others will eventually do it.

Stormking

03-08-2009, 11:42 AM

Just to be clear, we're changing support level for all OSes, not just Linux. There's no new OS support for Windows either, although in fairness the impact on Windows users is less because Windows tends to keep ABI compliance and also releases new OS upgrades at a much slower rate.
And also, I assume, the Windows driver worked, for the last years. If it had been as buggy as the linux version, there would be no more ATI.

One recurring message through your posts is that providing support via the open source drivers is somehow cheating because of community involvement, and that we should be forced to do all the work ourselves -- do I have that right ?
No, you got that wrong. If there was an open source driver with support for the core features and decent OpenGL performance, *NOW* - I would not say a word.

For five years, I got promises. About how the driver will be better, soon. Month after month after month. Well, it wasn't. As I said before, something was always broken. I still don't understand how you could break XV-on-TV-Out and not fix it for 18 months. I just don't get how something like this is even possible. Right now, your driver is broken, again. Doesn't work at all. The fifth release in a row!!!

And now? More promises. About how great the open source driver will be some time in the future. I don't care about a year from now. I want to use my laptop, *NOW*. I haven't been able to do that (to the full extent) for the greater part of its lifetime. In a year or two (when I assume the OSS driver will be feature complete, optimized and stable) I will very likely not use this hardware, anymore.

In Short: I just want to be able to use my damn laptop at one point, before it's completely obsolete. And I don't care where the driver comes from, if it's provided by the hardware manufacturer (seems logical to me), by the open source community (not their responsibility but if it works I'm okay with that) or if it falls from the sky. I even would have paid extra money if in return I would have got a working, stable and fast driver. I come from AmigaOS, I once was used to pay for hardware drivers (CybergraphX, TurboPrint, ScanQuix etc.)

duby229

03-08-2009, 11:48 AM

I don't think the reasoning behind this is so strange or difficult: if you tell me that ATI/AMD is actively working on code being pushed into the opensource repositories to ensure that the hardware dropped from fglrx will be supported to the level fglrx promised (perhaps modulo some 3D performance which I believe you is unavoidable) independently of how much other parties not payed by ATI get involved, then I happily stand corrected and retract my criticism on that. However, if this is not the case, then, at least for me, the ugly aftertaste is the impression that ATI/AMD is offloading the responsibility of creating a proper driver to other parties, something which is not what I would call proper support even if it eventually leads to working hardware and happy users.

It's not a matter of doing all the work yourself, but of not relying on the assumption that others will eventually do it.

I think you need to read up on what open source actually means. Get on google and ask it a few basic questions like how does the development process work? How do the number of user correlate to the number of developers? What does "Free" actually mean? etc etc etc

ATi's reasoning doesnt really matter. The facts are that the open source drivers user base is about to increase substantially. This increase of users will inevitably lead to an increase of developers. The only question remains is how do the project leads organize the manpower. That is really the only issue that ATi needs to concern itself with. That is the reality behind open source development. Projects with a large user base also have large developer base. ATi's only concern should be how best to increase the size of the user base, and how to organize the manpower in the developer base.

This is the fundamental logic behind open source that makes it work so well. You need to learn some fundamentals.

bridgman

03-08-2009, 12:14 PM

For five years, I got promises. About how the driver will be better, soon. Month after month after month.

This is the part I just don`t get. I have gone through every single press release, interview and on or off-record employee comment I could find on the internet and haven`t found *anything* like that. There is the occasional announcement talking about open source drivers or workstation drivers but that`s all I have been able to find.

And now? More promises. About how great the open source driver will be some time in the future. I don't care about a year from now. I want to use my laptop, *NOW*. I haven't been able to do that (to the full extent) for the greater part of its lifetime. In a year or two (when I assume the OSS driver will be feature complete, optimized and stable) I will very likely not use this hardware, anymore.

Yeah, this is the heart of it. Your laptop. Designed for Windows, tested by the OEM on Windows, bugs fixed for Windows before shipment. Desktops are fairly generic and (with the exception of AGP and high memory) different users tend to see similar results. Laptops are much more heavily customized, and the reason they work so well with Windows is that all of the qualification and platform-specific driver code is worked out with the OEM before the laptop ships.

That doesn`t happen with Linux, and (with the exception of a few OEM preloads) may never happen. The reason so many people are beating on you about getting more involved with the development effort is that so far this has been the only way to make up for the fact that platform integration is still done pretty much completely on Windows and MacOS, not Linux.

If you want the same kind of platform-specific diagnosis and fixing that goes along with a Windows or MacOS system (and the much larger market share), then either OEMs are going to have to be convinced that shipping with pre-loaded Linux (along with all the associated qualification testing) is a good investment, or *someone* with your specific system and priorities is going to have to get involved personally, using the open source drivers.

Don`t wait a couple of years. Make a list of what doesn`t work on your laptop today with the open source drivers and I think you`ll find that the issues are either already fixed, are in the pipe for fairly short term resolution, or need fixes specific to your platform which are only going to happen with your involvement.

Stormking

03-08-2009, 12:24 PM

Yeah, this is the heart of it. Your laptop. Designed for Windows, tested by the OEM on Windows, bugs fixed for Windows before shipment. Desktops are fairly generic and (with the exception of AGP and high memory) different users tend to see similar results. Laptops are much more heavily customized, and the reason they work so well with Windows is that all of the qualification and platform-specific driver code is worked out with the OEM before the laptop ships.
First of all, before I bought that damn thing, I checked every feature I wanted to use for the availability of linux drivers. I had positive experiences with NVIDIAs closed source drivers for linux. Not in a dream I would have thought that those of its direct competitioner ATI could be so crappy.

Then: I know that it is possible for my card to work under Linux. All the features I want to use worked at some point. Just not all of them with the same driver version. And there were driver version that even did it all (the one before 8.22.x). But one can't stay with an old kernel, forever.

DirtyHairy

03-08-2009, 12:25 PM

I think you need to read up on what open source actually means.Well, my arrogant friend, I presume I pretty well know what opensource means; however, we seem to disagree on the question whose responsibility the development of driver code for hardware advertised as "supported on linux" is. If you find that this question is covered by the definition of opensource or the legal content of different opensource licenses, feel free to drop a link.

Oh, by the way: in which mode are you going to contribute to the development of the opensource drivers?

Stormking

03-08-2009, 12:31 PM

Don`t wait a couple of years. Make a list of what doesn`t work on your laptop today with the open source drivers and I think you`ll find that the issues are either already fixed, are in the pipe for fairly short term resolution, or need fixes specific to your platform which are only going to happen with your involvement.
I think we already met in the X-randomly-freezes-thread in the FOSS driver subsection of this forum.

Also, one of the most important drawbacks of the FOSS driver is the OpenGL performance. 60 - 70% of the closed source driver's performance is not an acceptable replacement for the "loss" of it.

bridgman

03-08-2009, 01:16 PM

OK, thanks; I'll go back and check that thread.

re: performance, the 60-70% number is an estimate averaged across applications and across GPU generations.

The simpler apps which get run the most under Linux will tend to run faster than the most demanding ones, since the hardest optimization work is usually related to bandwidth-constrained situations on specific applications.

Older GPUs will typically have less of a performance delta than newer GPUs, since the biggest benefit from a more advanced shader compiler comes with the superscalar shader core in 6xx and above. For 5xx and below, with vector pipes rather than superscalar pipes, the shader compiler in fglrx has much less opportunity to optimize. A lot of the really slow performance in 3D on the open source drivers today is from software fallbacks related to missing GL 2.0 features, not the inherent performance of the driver stack.

Kano

03-08-2009, 01:42 PM

@bridgman

The Win drivers will be updated still every 3rd month (that's what was written in a news article in german), will the Linux drivers get then updates again too?

bridgman

03-08-2009, 01:55 PM

No, we're going to be doing ongoing support for Linux via the open source drivers rather than quarterly updates of fglrx.

The rationale is that most of the people using fglrx on older GPUs in a consumer environment are looking for additional features and functionality, not just minor bug fixes and keeping it working on new X, kernel and distro releases. Given that, going with the open source drivers seems like the right approach.

DoDoENT

03-08-2009, 02:04 PM

duby229

03-08-2009, 02:20 PM

Well, my arrogant friend, I presume I pretty well know what opensource means; however, we seem to disagree on the question whose responsibility the development of driver code for hardware advertised as "supported on linux" is. If you find that this question is covered by the definition of opensource or the legal content of different opensource licenses, feel free to drop a link.

Oh, by the way: in which mode are you going to contribute to the development of the opensource drivers?

The hubris of the misinformed....

You can call me arrogant all you want, but it still doesnt change the fact that it doesnt matter what AMD promised. AMD could promise the earth and the moon and it doesnt matter. The simple matter of fact is that as of this announcement the open source driver --WILL-- improve far beyond what it otherwise would have. I've already explained this, but I'll explain it again if I must. The power behind an open source development model is simply put: The size of it's user base. The bigger the user base is the more potential developers that project will have. And that really is the bottom line. What AMD has done here is they have dramatically increased the size of the open source drivers user base. And what they'll need to do in the future is better organize the manpower in the developer base. And that is nothing but good.

You attack AMD for not supporting there drivers, but the reality is that what they have done is actually much better then just that. Simply supporting the hardware isnt enough.

bridgman

03-08-2009, 02:26 PM

So, no Windows 7 for my laptop? :eek:

The Windows developers have a different view of ABI compatibility from what I can see. Vista could load XP drivers (albeit with limited functionality AFAIK), and my understanding is that Win7 will work with existing Vista drivers.

What you won't get with older GPUs is the newer WDDM 1.1 driver model, which support some additional features such as using DX10 for DWM. You will get Vista-level functionality and morewith Vista drivers, including Aero Glass.

If a new Windows release causes an existing binary driver to stop working, the Windows devs tend to treat that as *their* problem and their responsibility to fix. If a new Linux kernel or X server causes an existing binary driver to stop working, it's regarded as a driver problem (or "a good start", depending on the developer :D).

Perversely, that makes graphics driver maintenance for Linux even *more* expensive than the same level of support for Windows.

While building Windows 7, Microsoft is attempting to resolve scenarios that managed to successfully handicap Windows Vista in terms of compatibility. In this context, in order not to break devices that currently work with its precursor, Windows 7 will come to the table, from the get-go, with support for all Vista-certified drivers. Compatibility with devices designed for Vista ensures that users will have a seamless upgrade/migration experience. Grant George, the VP of Test for the Windows Experience, revealed that Microsoft had full compatibility with Vista-certified drivers for Windows 7 as a primary goal.

http://news.softpedia.com/news/The-Windows-7-Ballet-with-Drivers-and-Compatibility-102076.shtml

Melcar

03-08-2009, 02:29 PM

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.

adamk

03-08-2009, 02:42 PM

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/rscheidegger/dri_experimental/s3tc_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

DoDoENT

03-08-2009, 02:43 PM

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.

bridgman

03-08-2009, 03:05 PM

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.

adamk

03-08-2009, 03:18 PM

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

bridgman

03-08-2009, 03:50 PM

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 ;)).

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 ?

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 :D

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.

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.