Open ATI R600/700 3D Graphics For Christmas?

[Forge]

Still it would be far better to have an open development policy. This behind closed doors crap is not cool. Though it's better then nothing, so I'll just keep my objections to a minimum.

The problem is that it's 'behind closed doors crap' or nothing. AMD isn't going to just post everything and trust that everyone will let them slowly whittle it down to the stuff that can be disseminated.

Or did you think that GPU design was not also 'behind closed doors'? Do you think AMD should also open the tape masks for R800/R900 for public review??

If so, you're a fool. There's idealism and there's reality. We'd all love to make the two one, but it takes a very long time and you can never do it 100%.

[bridgman]

Normally we go for open. In this case we had a chicken-and-egg problem, where the raw info we started with was not specific enough to create a package we could review and release with any confidence that it could actually be used to create a working driver. The only practical option we had was to start trying to write a driver and use the results of that work to figure out which information was required -- and now we're going through the process of releasing *that* information. Note that many of the active 3d developers in the community have access to the repository already, so the work is much less "behind closed doors" than it might seem.

All of the other work (eg modesetting support for 46xx, 43xx etc..) is still happening in the open.

[»John«]

Can you give some details about your system ? Distro, GPU, bus etc ?

For what it's worth, the IP review for releasing info is happening in parallel with development of the open source 3d engine code in the driver - one is not delaying the other, at least not for a few more weeks.

So far I've only been using ubuntu but I'm certainly gonna try other distros with good reputation at least in virtual machine. I've completely ditched all M$ $hitware from all my PCs and living happily without it.

My new machine's specs are as follows:

• AMD Athlon X2 4600+ EE (ADO4600CZ(DO)BOX)
• GIGABYTE GA-MA790X-DS4
• SAPPHIRE Radeon HD 3870 with 512MB GDDR4

Thank you for your interest and keep up the good work supporting FOSS - I'm delighted to hear we'll get what we need to get it right soon enough (assuming of course it's really soon), especially considering I recommended one of my best friends to buy pretty much the same machine (only with 5000+ CPU & Radeon HD 4870) for exactly the same purposes and there's just no way in hell I'll let him go through the same mess.

And by the way, nVidia's blob that's once been belauded to the skies is probably starting to suck exactly the same way fglrx does - another one of my friends just got herself a brand new laptop and I wished you've seen the mess it's drawing on lower half of the screen during shutdown (not to mention it prevents the actual shutdown so she has to do it manually).

[duby229]

Normally we go for open. In this case we had a chicken-and-egg problem, where the raw info we started with was not specific enough to create a package we could review and release with any confidence that it could actually be used to create a working driver. The only practical option we had was to start trying to write a driver and use the results of that work to figure out which information was required -- and now we're going through the process of releasing *that* information. Note that many of the active 3d developers in the community have access to the repository already, so the work is much less "behind closed doors" than it might seem.

All of the other work (eg modesetting support for 46xx, 43xx etc..) is still happening in the open.

I've heard the argument, and I understand it. I don't really agree with it, but I do understand it. Hopefully this will be a lesson well learned for future releases. Given the amount of time wasted on R600 support, maybe the documentation that is being developed right now for R800 and beyond will be more open source friendly from the get go.

I think I have a grasp (maybe not a tight grasp) on the time and shear manpower involved with designing microprocessing architectures. I can fully appreciate the effort involved. And despite my outspoken nature, I really do appreciate most of it. Even some that I dont agree with. Still something (whether late or not) is better then nothing at all.

So thank you a whole hell of a lot. You guys involved are freakin awesome.

[Forge]

Given the amount of time wasted on R600 support, maybe the documentation that is being developed right now for R800 and beyond will be more open source friendly from the get go.

I may not understand a lot more than anyone else here, but it's my understanding that the docs are less of a problem than the design. You can go through and censor out the actual sensitive IP pretty quickly, it's carefully trimming away anything that *isn't* the sensitive DRM junk, yet would give big clues to how the DRM junk interacts, or things that give too much information that could be used to bypass/disable the DRM junk.

So anyways, my variation on your wish, which bridgman and I were talking about, is that future designs will more carefully segregate the sensitive we-don't-really-care-about-it DRM stuff from the open-able we-very-much-want-it general 2D/3D/Video bits.

[bridgman]

Exactly. The challenge for now (and probably for at least another year) is that tightly integrating DRM and processing hardware results in the most efficient and power-saving design, but also results in a design which is extremely difficult to document for the open source development community without putting the company at risk.

The long term solution is to (where possible) tweak the hardware design to make it easier to access the processing hardware without having to know anything about the DRM-related bits. The short term solution is the slow and painful process we are following today. Note that there are limits to this -- if the ideal design from an open source perspective required a 10% higher cost or consumed 10% more power in normal operation it would be a pretty tough sell and I doubt it would happen.

Given the amount of time wasted on R600 support, maybe the documentation that is being developed right now for R800 and beyond will be more open source friendly from the get go.

The good news is that we didn't actually waste much time, but we did have to follow sequence of activities which resulted in a long period of time when nothing outwardly visible seemed to be happening. The total time from starting work on 6xx/7xx 3D to having working code in user's hands will probably be 1.5 to 2x as long as it was for R5xx (the 5xx 3D work ran from maybe Jan 08 to June 08, or 6 months, with docs coming out in Feb) but that is driven primarily by the higher complexity of the new hardware and the fact that so much has changed. The 5xx was much easier by comparison, since a lot of the hardware was programmed the same way as 3xx/4xx.

I'm not including the fact that we are doing 6xx and 7xx simultaneously as a cause for delay since we also provided a bunch of 3xx/4xx info during the 5xx effort -- in fact working on 7xx at the same time helped because we were able to talk to the hardware guys about a hardware generation which was still being designed and exercised on the emulators. A lot of the design work on 6xx was done perhaps 3 years ago which is a long time in the graphics business. Going forward, we will be starting to work on open source support for future hardware generations at the same time that the hardware and closed source drivers are being worked on, so it should be much easier to get accurate and timely information. That's the plan, anyways

[Ze..]

Exactly. The challenge for now (and probably for at least another year) is that tightly integrating DRM and processing hardware results in the most efficient and power-saving design, but also results in a design which is extremely difficult to document for the open source development community without putting the company at risk.

The long term solution is to (where possible) tweak the hardware design to make it easier to access the processing hardware without having to know anything about the DRM-related bits. The short term solution is the slow and painful process we are following today. Note that there are limits to this -- if the ideal design from an open source perspective required a 10% higher cost or consumed 10% more power in normal operation it would be a pretty tough sell and I doubt it would happen.

It seems to me the ideal solution would be for everybody to realise that DRM is a dead end when it comes to preventing the owner of the hardware from accessing anything on it. There is a strong theoretical basis that DRM simply isn't ever going to work. It's akin to giving someone a locked box and then taping the key on the underside of the box.

I don't see that happening for a while though. I'm guessing future hardware designs with include a better MMU. So you have various protected modes of memory.

The good news is that we didn't actually waste much time, but we did have to follow sequence of activities which resulted in a long period of time when nothing outwardly visible seemed to be happening.

There is an opportunity cost though. You could've cost yourself some developers that would've contributed to the driver that aren't affilliated with you or your partners.

Going forward, we will be starting to work on open source support for future hardware generations at the same time that the hardware and closed source drivers are being worked on, so it should be much easier to get accurate and timely information. That's the plan, anyways

I think that's a good idea. I do wonder if graphics card designs will start to stabilise since the various programmable parts have gone generic. I wonder how much of the underlying model is going to change in 8xx and simply not be a raising of the number of the various units.

[duby229]

There is an opportunity cost though. You could've cost yourself some developers that would've contributed to the driver that aren't affilliated with you or your partners.

Lots of them actually. Even those folks that arent familiar with graphics architecture can point out structural flaws, and syntax errors, and bad variable types, and poorly implemented functions, and etc, etc, etc...... The list goes on and on and on...

The driver that is being developed now certainly is taking longer, and will be inferior because of this closed door crap.

Thats the point that I was trying to make.

[elanthis]

It seems to me the ideal solution would be for everybody to realise that DRM is a dead end when it comes to preventing the owner of the hardware from accessing anything on it.

Except that it's not. It doesn't matter if a handful of talented inviduals can hack it and a small portion of the computer users out there know this and can Google for the hacks to download and use. The vast, vast majority of users are totally clueless that there is a way around it, and so they are quite successfully controlled by DRM.

Just like a dead lock on your door. If I want into your house, I _will_ get in, and there's not a lock in the world that will stop be. The vast majority of small-time criminals aren't going to bother with your locked door, though, because they don't know how or don't want to risk getting caught.

[/quote]There is an opportunity cost though. You could've cost yourself some developers that would've contributed to the driver that aren't affilliated with you or your partners.[/quote]

Maybe. How many contributors does the Intel driver have outside of those with relevant corporate sponsors? How many did the older ATI driver have?

I doubt that the AMD folks even _want_ random people trying to contribute at the moment. As I understand, the vast majority of the code is example code and experimental stuff. It's not code that's meant to be the foundation of a real driver. The kind of "easy contributions" that you can actually hope to get would be absolutely nothing but a burden.


My question is why the DRM components needs to be hidden at all. The TPM modules that are being built into CPUs are fully documented and still fulfill their purpose quite well. Much like good encryption works perfectly even when the bad guys know the algorithm and components. I would've thought that the DRM components are mostly made up of data submission interfaces. I just don't understand why the DRM hardware is not in itself Open Source friendly. Isn't the whole purpose of putting this stuff in hardware supposed to be that the OS can just send the raw, still-encrypted data to the hardware and let the hardware do all the magic? Or is the OS itself expected to keep secrets from the user?

[duby229]

I doubt that the AMD folks even _want_ random people trying to contribute at the moment. As I understand, the vast majority of the code is example code and experimental stuff. It's not code that's meant to be the foundation of a real driver. The kind of "easy contributions" that you can actually hope to get would be absolutely nothing but a burden.

Would be nothing but a burden!!! are you Fing kidding me????