If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

AMD team is on good track. They publish their drivers for new hardware, earlier and earlier with each generation. (7xxx was victim of new architecture and 8xxx which could be served in time!)

So for 9xxx there will be good support BEFORE release. That mean many thing:
1) AMD folks will have more time, since they will not have to start work on next gen hw, right away.
2) AMD folks will have more time, since they will not have to deal with hw bugs on their own, since Catalyst team will be also interested in resolving them.
3) AMD folks will be "more productive", since they will release code in smaller packages, but for longer time spans. (Now its big pushes for each hw)
4) AMD folks will be "more productive", since they priority number one "get pre-release support done!" will take less time, leaving them more time on pushing new OpenGL stuff.
5) AMD folks will be "more productive", since they will be able to molest their legal department more often for permission to release various bits and pieces.

Hmm. Its time to see how my 5720M is doing with r600g

PS Do not school Michael for his messy understanding of the state of radeonSI. Grab PTS and upload some test results to OpenBenchmarking.org. And send him links :P (Or share on MESA mailing list, since he have some automated spiders tracking such stuff )

Comment

I do not question AMD mesa/gallium developer abilities, I don't think anybody here can say they do not do stelar work. R600g is already a very good driver, probably as good as or even better than intel's, IP issues aside.

The problem lies exactly in the IP issues. I question AMD management's commitment to the open drivers and linux support in general (specially in the consumer space), and how far are they prepared to go to provide proper consumer ready, feature complete bug free linux support of their products. Currently, my understanding is that it is pretty much up to the mesa/gallium devs to write some magical code that is able to perform as desired without revealing any compromising IP. Maybe they will be able to do that, maybe not. Maybe this can only be properly resolved by some other route, such renegociating the license contract with whatever third party IP provider they have, buying said IP, buying the IP holder or release it and risk going to court. But that is outside of the scope of the devs.

Some of these options are probably completely absurd. But the worse possible alternative is that all of them are, and that only leaves avoid using such IP in future generations, but that will not help current cards. The most we can expect is fomr them is to honestly confirm that features X, Y and Z canot be supported for generations xxx-xxx due to such IP licensing issues. That has been pretty much done for UVD for example.

What astonishes me is that according to brigdman AMD sees mesa/gallium as the way to go to support consumer GPUs, so fglrx is only a temporary solution, but at the same time, they cannot honestly say that we will be able to see a mesa/gallium feature complete driver in the next 5 yearss. fglrx shouldn't be expected to properly work also (also not feature complete). So what we conclude from that is that for AMD's management, consumer GPU linux support is not even an afterthought. They are pretty much betting all their coins on windows (in the consumer space). That has been a safe bet for the last 25 years, but I personaly do not see a future where windows continues to be only consumer operating system with a decent marketshare. To me, the mobile revolution is much more than simply smartphones and tablets, it is about these quirky, goodlooking and userfriendly OSes that are light, portable and flexible enough to be in every device, providing you with as much information and as much configurability as possible to extract the most from our devices. This resembles a lot AMD's vision of "surround computing", but it is hardly compatible with MS business. Android is what it is today because people are releasing consoles, watches, robots, toaters, fridges, god knows what running the OS, MS cannot compete with that. Will they have some space in next 5-10 years? Sure! Will windows still be the dominant OS? well, hard to say...

The problem lies exactly in the IP issues. I question AMD management's commitment to the open drivers and linux support in general (specially in the consumer space), and how far are they prepared to go to provide proper consumer ready, feature complete bug free linux support of their products. Currently, my understanding is that it is pretty much up to the mesa/gallium devs to write some magical code that is able to perform as desired without revealing any compromising IP. Maybe they will be able to do that, maybe not. Maybe this can only be properly resolved by some other route, such renegociating the license contract with whatever third party IP provider they have, buying said IP, buying the IP holder or release it and risk going to court. But that is outside of the scope of the devs.

One more time -- our commitment is to support community development of open source drivers, and we are going further than that by hiring some really good developers to work on the drivers full time. We are not committing to do all of the open source driver development ourselves and never have.

Some of these options are probably completely absurd. But the worse possible alternative is that all of them are, and that only leaves avoid using such IP in future generations, but that will not help current cards. The most we can expect is fomr them is to honestly confirm that features X, Y and Z canot be supported for generations xxx-xxx due to such IP licensing issues. That has been pretty much done for UVD for example.

That is not what we said at all. What we said was (a) we were not including a commitment for *any* UVD support in the initial announcement, (b) that we would work internally to see what could be done, and (c) that where we did find obstacles with releasing programming info for current hardware we would raise the issues internally and see if we could find ways to lift those restrictions in future designs.

Comment

The problem lies exactly in the IP issues. I question AMD management's commitment to the open drivers and linux support in general (specially in the consumer space), and how far are they prepared to go to provide proper consumer ready, feature complete bug free linux support of their products.

That is a super nice dream for any software. And one which will never come true.

Comment

Just curious: Are you looking to increase the number of driver developers?

Well, not to dampen anyone's spirits, but considering the recent financial problems at AMD we should count ourselves lucky that none of the ones that they do have already ever seemed to have been considered to be shaved, if you know what I mean.

Comment

Dunno. I have to find time to fit a bigger power supply in my work system before I can plug in the Tahiti board. On a positive note I have system, power supply, screwdriver, bandages and Tahiti board all ready to go.

Is "3D workstation" only the firegl "professional" graphics cards? Can a notebook with enduro be a workstation too?

I believe we are selling high-end APUs and high-end laptop chips into the 3D workstation market as well. One of the interesting things that came out of the move to unified shaders is that midrange GPUs can crunch typical workstation loads very quickly with the right driver optimizations.