AMD Documentation Drop Next Week

[Michael]

After you finish that you guys should write a "How to make your own 3d Radeon Driver For Dummies" book. I predict it being a best seller.

When they are "finished", there will be a working driver with 2D, 3D, and video playback support. I am not sure how many users at that point would then be interested in writing their "own" driver, plus even with the documentation in hand it still would be very time intensive and require much work.... and lead to fragmentation.

[lucky_]

All of this sounds very sweet, in a few months here will be no reason to buy nvidia for linux desktop.
There is now some reason to delay some shopping, just to wait for the best AMD stuff.
Does anyone have any estimation of how long it could take ?
Few months can be 6 months or 2 years...

Anyway thanks to AMD and to M. Bridgman for his insider point of view, it very nice to see a company involving with the community.

[EmbraceUnity]

All of this sounds very sweet, in a few months here will be no reason to buy nvidia for linux desktop.
There is now some reason to delay some shopping, just to wait for the best AMD stuff.
Does anyone have any estimation of how long it could take ?
Few months can be 6 months or 2 years...

Anyway thanks to AMD and to M. Bridgman for his insider point of view, it very nice to see a company involving with the community.

I was so impressed with AMD recently thanks to what I've seen here that I have invested a bit in the company. Assuming they maintain their interest in Open Source, my next board will definitely be AMD.

[Dandel]

I am looking forward to this dump, because it will not only effect linux but other free operating systems to get better 3d support with newer radeon video cards.

[koolmanoncampus]

When they are "finished", there will be a working driver with 2D, 3D, and video playback support. I am not sure how many users at that point would then be interested in writing their "own" driver, plus even with the documentation in hand it still would be very time intensive and require much work.... and lead to fragmentation.

Naturally... My comment was intended with a pinch of sarcasm.

[Michael]

Naturally... My comment was intended with a pinch of sarcasm.

Ah, okay

[bridgman]

This was something we discussed at the start of the project. The conclusion was that (a) since we didn't have all the information in one place, it would probably make more sense to write the document *after* the first driver was written, and (b) as Michael said, once we had the driver the need for the document was questionable.

On the other hand, documentation *could* help new developers to get started working on graphics drivers, but that would be a very different document from one which showed how to take advantage of every aspect of the chip. Right now the graphics driver world seems pretty scary to anyone not already working on drivers, and it would be good if we could do something to "lower the bar" for new people getting started.

My current belief is that a really small driver (smaller and less functional than radeonhd, designed only for experimentation not day-to-day use) might be a better use of time than a standalone document -- what do you think ?

[duby229]

This was something we discussed at the start of the project. The conclusion was that (a) since we didn't have all the information in one place, it would probably make more sense to write the document *after* the first driver was written, and (b) as Michael said, once we had the driver the need for the document was questionable.

On the other hand, documentation *could* help new developers to get started working on graphics drivers, but that would be a very different document from one which showed how to take advantage of every aspect of the chip. Right now the graphics driver world seems pretty scary to anyone not already working on drivers, and it would be good if we could do something to "lower the bar" for new people getting started.

My current belief is that a really small driver (smaller and less functional than radeonhd, designed only for experimentation not day-to-day use) might be a better use of time than a standalone document -- what do you think ?

Mind you, I'm not a programmer, but my take on this would be something along the lines of "what's good for the goose is prolly good for the gander, but not necessarily good for anything else"

I know its a cliche, however it fits in this case. You are already planning on releasing a minimal driver as an example in the next documentation drop. That should be good enough to fill the role of helping new developers get used to driver structure and general design. However a very minimal driver will absolutely not help new developers get anywhere beyond noobs. It'll gve them a taste but that is all it will be able to do.

In the end I believe that nothing less then a small example driver --with-- accompanying documentation will be acceptable. In this case the documentation should --not-- be a direct correlation with the driver, because the driver should be commented appropriately. Instead t should be written independently, but with the same goal as the example driver. So in the end the example driver and the documentation will be two different implementations of the same thing. This I can promise you will be far more effective then either one of these options alone. I believe they are both equally needed.

[bridgman]

No argument there. Only question is whether the documentation should be standalone or embedded in the code. My experience has been that really well documented code is more useful than separate doc & code, but that's just personal experience not fact.

[Michael]

My experience has been that really well documented code is more useful than separate doc & code, but that's just personal experience not fact.

I'd agree with that too.