AMD Preparing For Another GPU Documentation Release

[bridgman]

I will be setting up a mailing list for questions, probably in a week or two. The plan is to reply directly to the emails plus put the generally useful answers into some kind of faq/wiki and make that public. For now you can email me directly - john dot (my user name) at amd.com but I can't promise quick answers for a couple more weeks.

Michael asked about All-in-Wonder documentation. The answer there for now is "we don't know yet". There are two main issues :

1. AIW boards have third party parts (tuners, sometimes decoders) and we don't have rights to redistribute the programming info. In principle this is simple -- talk to the third party vendors to see if they will either publish the info or give us the right to publish it -- but very time-consuming in practice.

2. AIWs (actually anything with video capture) get into some messy legal areas since (a) we are required to detect copy protected content and not transcode it or output it in a recordable form, (b) the information required to do that detection has to be kept secret.

I know what you're thinking -- "we just want to watch TV, nobody pirates VHS tapes any more" -- but the same hardware is used for both and AFAIK we still have contractual obligations to "protect the protection".

Bottom line is we're going to look into it but right now I don't have an answer for #2. I don't see us spending much time on this until after 3d and video playback.

[Berniyh]

I will be setting up a mailing list for questions, probably in a week or two. The plan is to reply directly to the emails plus put the generally useful answers into some kind of faq/wiki and make that public. For now you can email me directly - john dot (my user name) at amd.com but I can't promise quick answers for a couple more weeks.

Bottom line is we're going to look into it but right now I don't have an answer for #2. I don't see us spending much time on this until after 3d and video playback.

Great. I think you're doing it the right way. Don't do it all at once, the result would either be not very good or it would just take to long.

I've got one question for that mailing list. Will that just be about the open source drivers and/or the documentation (release) or will that also cover the fglrx driver (I don't guess it will be a support list for the fglrx driver.)?

Another thing is, I've got the feeling that the bugzilla page could need some serious clean up. As far as I can tell, there are a lot of dups and just about anything is marked critical or blocker.
Maybe you could need some help, I don't mean me, but I'm sure, there are a some guys who know about this hardware and the drivers, that could help out.

[bridgman]

The mailing list will just be developer support for folks working on open source drivers.

We are looking at ways to make Bugzilla (and user support in general) more effective.

[Berniyh]

The mailing list will just be developer support for folks working on open source drivers.

We are looking at ways to make Bugzilla (and user support in general) more effective.

Thanks, that was just the info, that I wanted.

As for Bugzilla, I think that one thing would maybe help sorting a lot of the dups out.
In some Bugzilla setups you get a "Most dups ranking" or something like that, when you want to submit a bug. I guess that would already help a lot, since there are a few bugs (for example VT switching), that have a lot of dups.

[Svartalf]

Uh, you mean the X200M is faster?

No. For fragment shading operations the X200M is moderately faster and definitely much more flexible as the fragment processing is all shader based. However, there is no vertex shader functionality on the GPU to speak of on an X200M- meaning that the CPU has to take up the slack on transform, clipping, and lighting operations. This means that, for any OpenGL 1.5 title that is not using any Fragment Shaders to speak of, the Radeon Mobility 9000 running the DRI open source drivers will out perform the X200M performing on the fglrx drivers. Without TCL hardware of some sort, the X200m is at a disadvantage- if we had HyperZ and a few other things supported on the R200 chips, it'd be at an ever bigger one.

[Svartalf]

I hadn't really thought about Rage parts -- honestly we weren't planning on going back *that* far. We can probably try to answer developer questions on those but I don't think we would do any kind of documentation package.

Well, I've still got the "sanitized" RagePRO spec docs in hand, and I think I might still have the Rage128 equivalents from when I was working on the UtahGLX project. I do believe that the work to clear any IP leakage issues was already taken care of on those documents and all we'd need to do is probably work out a release from NDA on either myself or one of the other DRI or UtahGLX developers on that score. I'd be more than happy to discuss it with AMD management if they're amenable to it.

I'm sure that questions being answered would be very welcome if that's as far as the management are willing to go on that one. We'd like more, but...

[Svartalf]

1. AIW boards have third party parts (tuners, sometimes decoders) and we don't have rights to redistribute the programming info. In principle this is simple -- talk to the third party vendors to see if they will either publish the info or give us the right to publish it -- but very time-consuming in practice.

I believe most of the tuners ever used by ATI are already covered- especially if the AIW's used the same tuner parts that were in the ATI tuner cards. I know that they pretty much worked when I used them as proof of concept devices on set-top boxes for PIP on an internet appliance Linux distribution developed by Coollogic back in 2000-2001 timeframe.

2. AIWs (actually anything with video capture) get into some messy legal areas since (a) we are required to detect copy protected content and not transcode it or output it in a recordable form, (b) the information required to do that detection has to be kept secret.

Considering that Macrovision's been busted by things like Sima's video stabilizer device (which is a legit device, but has the unintended extra ability to scrub Macrovision from the video signal...) I'd say that most of this sort of stuff is actually rather moot (most of it was snake oil, just like any other DRM scheme that's come down the pike to date...)

If all that needs must be done is omit the Macrovision control info, then just do that. Frame capture's frame capture. Considering that we already HAVE video capture elsewhere and the suppliers that provided us resources, etc. didn't seem to have the problem you're claiming, I fail to see where AMD/ATI would be any different- but then it's a position of ignorance, I'll admit, that I'm coming from on this one.

[bridgman]

Well, I've still got the "sanitized" RagePRO spec docs in hand, and I think I might still have the Rage128 equivalents from when I was working on the UtahGLX project. I do believe that the work to clear any IP leakage issues was already taken care of on those documents and all we'd need to do is probably work out a release from NDA on either myself or one of the other DRI or UtahGLX developers on that score. I'd be more than happy to discuss it with AMD management if they're amenable to it.

Interesting. I joined ATI near the end of R128 development so I'm still learning what happened before that. If you could email me at the address above that at your convenience that would be great.

[bridgman]

I believe most of the tuners ever used by ATI are already covered- especially if the AIW's used the same tuner parts that were in the ATI tuner cards. I know that they pretty much worked when I used them as proof of concept devices on set-top boxes for PIP on an internet appliance Linux distribution developed by Coollogic back in 2000-2001 timeframe.

That's good to know. We definitely changed tuners a few times on the later AIWs to save space and power, but if the earlier ones are understood that's a good start.

Considering that Macrovision's been busted by things like Sima's video stabilizer device (which is a legit device, but has the unintended extra ability to scrub Macrovision from the video signal...) I'd say that most of this sort of stuff is actually rather moot (most of it was snake oil, just like any other DRM scheme that's come down the pike to date...)

Practically I agree this is totally moot. Legally, this is as big an issue as ever. AFAIK we aren't supposed to help make anything like a "video stabilizer", which is exactly what an AIW without detection of copy protected inputs would be.

If all that needs must be done is omit the Macrovision control info, then just do that. Frame capture's frame capture. Considering that we already HAVE video capture elsewhere and the suppliers that provided us resources, etc. didn't seem to have the problem you're claiming, I fail to see where AMD/ATI would be any different- but then it's a position of ignorance, I'll admit, that I'm coming from on this one.

My understanding is that the restrictions come from the agreements which govern output protection. If we only made tuner cards and not graphics cards we wouldn't need to sign the same agreements... at least that's what I was told last time I looked into this.

[The_Monkey_King]

I know ATI has been through some serious changes lately and now their whole product line as well as development has been changed from strictly ATI to now the leadership and direction of AMD.

That being said, I see perfect opportunity in the Linux landscape for major gains over nVidia and even Intel. Specifically having a rock solid driver and kernal base will go a long way to selling systems for the consumer market. I cannot recommend any new ATI/AMD all-in-one boards for the DIY crowd because I myself cannot get the x1250 to be identified and run properly using any Linux distro. It does work on Windows platforms nicely however.

(Side note: the latest Windows driver -7.10- unfortunately misreports the x1250 as an x1200. I sent an email through the Catalyst Crew feedback.)

I know the business model right now may not have the capex or opex to spend this year (already spent and closed), but waiting for driver development to be where it should be now, both at ATI and with Novell is too long for some of us trying to build systems now.

My question is this: how long does AMD expect this will take to have driver development match that of Microsoft's drivers? And, do they expect there to be parity? I understand if no one in AMD needs to have Linux drivers equal to the Microsoft development; it is a business decision.