I have a question...

I'm a long term C++/OpenGL programmer but I know nothing about driver development, where would be a good place to start so I could perhaps help out in future? I mean, what could I do to help in the short term and how can I learn about graphics driver development to help in the long term?

Try to look on the Internet, Google always help me. use filters.

If the specs are under NDA for a select few, what is the best way for the part-time tinkerers to help out?

Report specific bugs with specific test cases?

well the thing is most bugs can be fixed without specs, so for a part-timer or someone interested in starting in driver development, finding a bug that looks minor and trying to fix it yourself is the best way too start...

So does it mean that the r300 driver will also benefit from that? or only for specific new cards?

yes. initially new cards, but we are going to have access to ppl to ask questions about older drivers.

As the r500 and r300 3D cores are quite similiar, a new r5xx 3D driver would help fix the r300 3D driver...

What will happen to Jerômes driver?

And will you be able to release yours now?

More than likely we'll abandon avivo..

I won't release my driver code as it has been surpassed in most ways, but I will be able to port some of my code into the new driver if required.

Please excuse if it's considered a rude question, but should will we have something to play with (testers)? I have 1 ATI card right now, and will be ordering a much better one to get rid of the Nvidia I have in my computer once a testing driver becomes available that supports one of the newer cards.

Thanks for all your work on this, it's a dream come true.

There will be a 2D driver release next week that will set modes, not much more.

The thing is it'll take probably 6 months to get something really useful out, but testers can start on whatever ends up in the git tree when it gets published.

It is really a great news that AMD has finally listened to the Linux community and did the right step towards open development of the drivers. What I would like to know is if all this also includes graphics integrated into laptops. There are many laptops with chips like Radeon Xpress 200m and similar. Is this also going to help here? Do they also provide all specifications and support for integrated graphics chipsets? Can we expect any big improvements towards open source driver for laptops?

These are the same as legacy graphics chips really, so there will be benefits for them from this deal, but not manpower or the like, as in now we can ask questions and expect answers instead of just guessing how certain things are meant to work..

We can probably also get powerplay and such things implemented...

The open source Xpress 200m chip should mostly work (except compiz) due to work I've done lately before this stuff went ahead..

How does the fglrx driver fits with this new driver?

thanks

So the plans are:
r200 and r300 -> will be improved
r500 avivo -> will be rapleced with new framework gived by amd/ati

And i forgot to underline that last message was an question :)

as I'm getting a new laptop in October I'm not sure whether I should try to get one with Intel GMA or ATI xpress.
power saving and Xorg features are the most importants aspects to me.

So does this mean you can also release some of the information you've collected on how XvMC is done with ATI drivers?

Hi,

Don't you think that putting all community devs under the same NDA is potentially dangerous ? Imagine there's a feature they don't want to be implemented in the free driver, they could block all of you from doing or talking about such code and we have no one left (with the required experience).
I know you understand me pretty well because you've already been bitten by this.

Xav

If there's a feature they didn't want implemented, they'd just scrub it out of the docs. Macrovision springs to mind.

More broadly, if the NDA says "we'll document everything, and some of it you won't be allowed to implement", I just wouldn't sign it, and I suspect I'm not alone. NDAs are voluntary, you can choose to not enter them.

This is great news! Especially since its the first (and so far only) real fact that corroborates their claims.

I do wonder about the 3d though... If they release to linux full specs so that we can write our own GPL'ed driver, and maintain that relationship, then its reasonable to expect that fglrx will, even if well maintained, eventually become an inferior driver, no? I just don't see the point in maintaining it in the long run, unless they intend to keep certain chip features private or something. Do you think we'll get full 3D acceleration out of these chips when all is said and done? Or are we going to end up with an open but partially crippled due to undisclosed chip features 3D driver?

80% performance with few bugs and no guesswork would be far better than what we get now, but it would suck if they intentionally hold back the 20%.

The open driver may well surpass the closed one at some point in the future. If it does, then ATI may well choose to switch to it for their certified workstation drivers.

They're not holding back some magic feature from the docs that will make fglrx go faster or anything, the intent is not to "cripple" the open driver. They've just sunk a lot of engineering and testing effort into fglrx, and they have customers that rely on its feature set. They can't change that overnight.

Will you have access to information that would aid in adding xvmc support to older (r100/r200) Radeons? How about the 'pixel shader assisted video deblocker'?

Thanks,

IIRC, the R100 supported some form of pixel shaders, which were exposed via some ATI-specific GL extension a long time ago. Would this information allow access to those features, to gain some pixelshading functionality on the r100 chips? (I have a Radeon 7500, I'm being hopeful. :))

R100's "shaders" aren't fragment programs in the modern sense. It has a very capable texture combiner, but it's done with fixed silicon, not with a general-purpose instruction set. We've had the R100 docs for a long time now, if there was any way to do fragment programs on it we'd know.

Would you have access to their mobile chipset docs too? We could use some help with the w100 and w3220.

Matt

I don't know that that ever came up! We'll certainly ask.

Will something like (http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html) that become much more likely with this information?

That's sort of a null question. Much of that work isn't hardware-specific. It involves changing the way the driver does some things, but the actual hardware interaction is minimal. Kristian did that work on an i830, but he doesn't have the docs for that chip, nor did he need them.

In some sense, yes, we'll be able to do redirected direct rendering on R500 now, but that's just because we'll have a driver at all, not because we have the docs for the chip.

AMD has figured out that Linux users have learned that ATI hardware when used with open drivers is no functionally better than cheaper video cards. But this announcement is just another ATI lie of "ATI speak" that implies more than what they will really provided.

ATI has claimed for a long time to provide "specifications" to the "community." In reality, the provide part of the specification to a select few developers under NDA. The developers aren't permitted to share with others and ATI refuses to respond to queries from others for the specs since it was "already released." There is a pending request to ATI for specs that they will be "getting back to me" about sometime *AFTER 6 YEARS* have already passed.

ATI has never made it clear that by "having provided the specification" does not mean all of the specifications to support all of the marketed features of the video card. They even have claimed commitment to iDCT/MPEG decompression support for Linux with an "ATI kit" that they never followed through the commitment for. To date, there is no XVMC or similar API supported by either the open source drivers or binary drivers and the specifications to provide such support will "NEVER be released" according to ATI's own employee!

While increase in speed of CPUs has reduced the need for iDCT hardware for MPEG 480i/480p streams, for HD-DVD and BluRay playback, getting access to these specification is extremely helpful! But the bottom line is that ATI will continue with business as usual that Linux users will be charged a premium price for features that they will never get to take advantage of.

Giving AMD/ATI more undeserved marketing buzz when they continue to just imply things they won't provide just discourages people from seeking solutions which have a real commitment to the community. Each time ATI claims they will be (maybe... someday) providing something, the response from the community should be: PUT UP OR SHUT UP! In the mean time, we can't allow these announcements of misdirection to distract from a focus on a true Open Graphics Project.

ATi probably made a huge mistake and did some third-party licensing and now they can't release it.

Eventually people will realize that they can get better open-source driver performance.

One of the reasons ATi is doing this at all is because of companies like Dell. Dell's Ubuntu line is more or less cherry-picked hardware--they prefer FLOSS drivers because it allows their users maximum flexibility in upgrades.

Dell isn't picking ATi video. They offer Intel integrated video up until the very highest laptop which is an nVidia card.

AMD/ATi wants to do just enough to get a piece of that action.

Are there any chances to get compiz running on xpress 200 using r300 driver in the near future?

If I understand correctly, you'll start from scratch with a new driver for r5xx+ cards.

Since you now have the benefit of docs, hindsight and experience from the radeon/r200/r300 driver, would it be worthwhile to have a unified driver for r100/r200/r300/r4xx/r5xx hardware; I mean merge the existing ati drivers in the new one?

Since it is Dave Airlie and Adam Jackson talking about this I really do believe that this is going to happen and that it is good news. Most of my queries have been answered in earlier questions but I shall split up future questions in case some a contentious (so that you can at least answer some while leaving others).

Will the new drivers have hooks in them for binary only parts?

We don't know. They might. It depends.

The obvious example is copy protection. The MPAA is under this hilarious delusion that they can protect the bits all the way from the DVD to the screen. Part of that is setting up HDCP on the video cable. ATI probably can't tell us how that works, because if they did, we could just turn it off, and then OMG PIRACY. So what will likely happen there is the driver will just not do HDCP normally, and if you want to sell a fully licensed DVD player that runs linux, you'll just add that as a plugin.

You can either do this by maintaining the hooks in the open code, or by maintaining your own internal branch of the code that you only give to people who pay for it (ie, people building an appliance). Or maintain that in fglrx, I suppose. And, yeah, if the open source community decides they don't want that kind of closed hook in the open code, there's not a lot AMD can do about that, so option 1 might not be an option at all.

Again, the intention here is not to cripple the open drivers, or to require some magic closed blob to make things 30% faster. That doesn't help anyone, AMD included. They really do want to enable as much as they can in the open drivers to make their hardware look good. And, let's face it, copy protection makes their hardware - any hardware - look bad.

(This question was partially answered in http://airlied.livejournal.com/50187.html?thread=160523#t160523 )

In the past ATI has been burned by releasing specs and getting back drivers that didn't perform very quickly/lacked features (some will argue the old rage 128 drivers will never be completely fixed). Will the new open source drivers be very fast (or will they only strive for base level performance for open source software)? Is this likely given current expertise levels? Additionally will the features for using software with cutting edge 3D features (if things like Maya, id tech or Unreal Engine are ever ported to Linux again) be implemented in the short term (a year or less)?

One of the nice things about new GPU architectures is that they reduce to a compiler problem. It looks very likely that we'll soon be generating GL commands by using LLVM or similar as our compiler backend. So getting performance out of the card should be quite promising.

But this is a crystal ball question. It's impossible to say for certain that some feature will be implemented in six months. As with all the other drivers in Mesa, we endeavor to make them as fast and feature complete as we can. R500 is not going to be different in that regard.

Should people be ordering r5xx graphics with computers that are going into labs? Are new ATI/AMD cards now officially the "best" (regarding support) discrete graphics cards to buy en masse?

It's not particularly politic to talk about whose hardware is the "best", in this sense. That's an endorsement, it's advertising, and more importantly it's anti-advertising for anyone you don't say is the best. That's a matter for forums, not developers.

Will new, just-released ATI/AMD cards have "out of the box" (2D/3D/Video) in the last distro release in a year's time? If so what form will this take? Will it be compile your own drivers from a git tree or will compiled open source supporting the yet to be released card have already been shipped with the distro?

Speaking only for Fedora here, but.

We don't ship pre-release code. If it's not available in a public source repository somewhere, it's not something we can ship. If AMD wants to start delivering code drops ahead of product launch, they are more than welcome to do so. Whether, and how often, they do so is likely to be related to how big the changes are for the future hardware they're shipping. If it's a major generational change like R500, that's one thing, but if it's just adding PCI IDs and feature flags for products in the same line, that's another.

Fedora will make every effort to support all the hardware it can out of the box in each release, with the understanding that that requires open code first. We will work with AMD and other vendors to ensure that our schedules match as well as they can, but sometimes they won't. That's just the reality, and that's what 'yum update' is for.

Will the agpgart GPL/fglrx issue ( http://kernelslacker.livejournal.com/2006/08/13/ ) be resolved? Now that airlied is the agpgart maintainer will the code simply be dual licenced or the infringement investigated by the agpgart maintainer?

fglrx didn't include its own agpgart module for quite a while.

Have any other graphics card vendors started talking to you about releasing specs (I'm assuming that if they were you could talk about it of course)? I would have thought smaller players would have been especially keen (if only for things like video acceleration let alone 3D)...

I've talked with just about every graphics vendor at some point or another. I haven't heard anything new from any of them related to this announcement, but then, it's also been less than a week. Companies steer like boats, give it time. Every conversation I've had with a graphics vendor has been positive so far; I expect this will only continue.