AMD: GPU Specifications Without NDAs!

[phoronix]

Phoronix: AMD: GPU Specifications Without NDAs!

This morning at the X Developer Summit in the United Kingdom, Matthew Tippett and John Bridgman of AMD have announced that they will be releasing their ATI GPU specifications without any Non-Disclosure Agreements needed by the developers! In other words, their GPU specifications will be given to developers in the open. Therefore you shouldn't need to worry about another R200 incident taking place.

http://www.phoronix.com/scan.php?page=news_item&px=NjA0Ng

[yoshi314]

*sigh of relief* :]

i was getting paranoid there with those nda words floating around.

[oliver]

One reaction could be "it's about friggin' time" or "this is how it supposed to be anyhow"

I prefer, That is so awesome!

Hopefully people will start building nice drivers now too.

I guess it's time to be happy I stuck with ATi/AMD through all these years.

[yoshi314]

I guess it's time to be happy I stuck with ATi/AMD through all these years.not just yet. we don't have our hands either on 8.41 or new opensource driver or amd specs, do we?

[Svartalf]

not just yet. we don't have our hands either on 8.41 or new opensource driver or amd specs, do we?

Indeed... While I'm really upbeat about what I'm being told right at the moment, the reality is, until they deliver, it's just more promises- I'm willing to wait and see because of the nature of the promises being made, but in the end, it's just that...promises.

[oliver]

If I was pessimistic all this time I would have switched to Intel/Nvidia ages ago, now wouldn't I?

I'm a (maybe foolish) hopeful person.

And if AMD doesn't deliver? not the .41 and not the .42, then what would keep Micheal (or others of course) from 'leaking' the beta driver? If they'd screw us over that massively, then it would only be 'right' to leak it I think.

[d2kx]

Let's see what nVidia does.

[oliver]

Ever since nVidia said publicly (don't ask for link, I tried to find it again, but couldn't it was an old article, thing geforce2 eta) that they where opposed to OSS, I have been opposed nVidia.

You may claim that they offer OSS drivers for some of their chipsets, but I don't think they are theirs (I don't check it that regularly). They used to offer their own binary only net driver for example for a while, and now point to the forcedeth driver, which is reversed engineerd. So for me, nVidia, no thank you. Of course companies can always change their views.

[TechMage89]

This is superb! Now I just have to learn how to develop drivers...

[immudium]

That's great and I look forward to ATI's continued improvement on Linux. Nonetheless, in the short term, there's not a lot to be all that excited about really. NVidia has always been good to the Linux community. They adopted and integrated the XOrg compositing extensions to support Compiz and Beryl pretty damn quickly. Does AMD even have anything in that area at all yet? Even in the new "improved" 8.41 driver? Not that I've heard of. Again exciting stuff, but my excitement is pretty tempered by the current state of affairs. I fairly recently got a new dual core machine at work and to my horror it had an ATI card in it. Well I immediately had to go beg and plead to the IT gods for an NVidia card so that I could get my Beryl rocking again. Well turns out the IT guy even apologized to me about putting in an ATI/AMD card and he's a Windows guy. So apparently it sucks there too. I wouldn't know. As long as NVidia delivers the goods, I'll let them beat me with their closed source dead fish for as long as they want.

[Thetargos]

Now, what would the scope of the specs be? What about any third party IP they may have in the hardware? Are they releasing the specs for those parts too?

[Svartalf]

Now, what would the scope of the specs be? What about any third party IP they may have in the hardware? Are they releasing the specs for those parts too?

The reality is that the only real 3rd party info would be for texture compression algorithms, things like Macrovision encoding (or, more appropriately, how to send TV video without it turned on...), and so forth. It's my understanding that they own the rest and the biggest reason that they don't want to open source the current driver is more due to the amount of effort and money spent on developing the blasted thing and that they DO still have some edge and technology that has NOTHING to do with the GPU itself, but the magic to make it go "fastest". It's my understanding that this is the main reason for most of the players in the game not playing nice with us- they think they have a proprietary edge on everyone else.

It's folly, in my not so humble opinion, but it's the current reality and I'm not going to mouth off TOO much about it, so long as they hand out the needed info on how to basically drive the things to us without encumberances.

[Thetargos]

AFAIK there is no only the texture compression algorithms (someone please convince VIA to open S3TC!!), but also MPEG engines, z-compression and a bunch of other "algorithms" applied to the hardware (or the excuse from the R200 days was something along those lines). At the very least I'm pretty certain that there would be a patent issue with the Motion Picture Experts Group if the hardware specs for on-hardware decoding were open sourced, unless AMD has worked it out with them and is acting as proxy (an the AMD-ATI implementation is unique enough). Not that the specs for the format aren't "open", they are (AFAIK), but you require licensing for implementing decoding-encoding "mchanisms" (either hardware of software I'd assume?)... For the Z compression mechanisms and algorithms, I'm not sure if during the days of the introduction of "HyperZ" (key component that didn't make it into the R200 driver), ATI acquired the full rights over the technology and as such AMD is able to open them now, or what... That was the point to my question.

Edit

It would be nicer if they'd besides opened up Macrovision (or at least provided a proprietary driver for it, which I don't know if the current [new] fglrx driver supports of if past versions supported, been off the ATI hook for almost 4 years now)

[Regenwald]

can anybody mention how many slower the new driver will ever be? is it possible to replace some of these algorithms? besides, a russian hacker don't care for patents (prejudice^^), perhaps some of them are able to get them to work :) (think about the codec situation). additionally, softwarepatents still only exists in the usa and japan (good old europe don't have them, luckily)

[Thetargos]

Only in this case, it would be a hardware patent, as even if it is an algorithm, it has a hardware component where it runs.

[Svartalf]

Only in this case, it would be a hardware patent, as even if it is an algorithm, it has a hardware component where it runs.

The big deal would be any software components that would, like in the case of the S3TC situation, would be used to produce the preferred format from other formats- this is the main problem with the DRI drivers when it's distilled down to it's basics. You don't need to worry about the patents if the game uses the already compressed texture sets- the vendor already HAS paid your royalties for that part. It's when you want to use OpenGL to compress the textures for you (Common trick to get the compressed textures, have your driver compress them for you...) is when the S3TC patent becomes a problem for an Open Source driver.

[Thetargos]

The big deal would be any software components that would, like in the case of the S3TC situation, would be used to produce the preferred format from other formats- this is the main problem with the DRI drivers when it's distilled down to it's basics. You don't need to worry about the patents if the game uses the already compressed texture sets- the vendor already HAS paid your royalties for that part. It's when you want to use OpenGL to compress the textures for you (Common trick to get the compressed textures, have your driver compress them for you...) is when the S3TC patent becomes a problem for an Open Source driver.

So if I understand you correctly (and this is in fact an issue that really matters to me) is that if the textures are already compressed (like those present in UT'99) in the right format, the hardware will all the same decompress them, despite of the driver (provided the driver knows how to interpret these textures)? can the DRI R200/300 drivers do this?; however if the application requires that the driver (either in the CPU or GPU, but before the textures hit the VRAM) do the compression (dynamic compression?) through the use of the GL_EXT_texture_compression_s3tc | GL_S3_s3tc, is that there'd be a patent issue? Talking about the specific case of S3TC here, dunno if it applies to other portions like Z-compression and/or MPEG decoding or textured video.

[glisse]

So if I understand you correctly (and this is in fact an issue that really matters to me) is that if the textures are already compressed (like those present in UT'99) in the right format, the hardware will all the same decompress them, despite of the driver (provided the driver knows how to interpret these textures)? can the DRI R200/300 drivers do this?; however if the application requires that the driver (either in the CPU or GPU, but before the textures hit the VRAM) do the compression (dynamic compression?) through the use of the GL_EXT_texture_compression_s3tc | GL_S3_s3tc, is that there'd be a patent issue? Talking about the specific case of S3TC here, dunno if it applies to other portions like Z-compression and/or MPEG decoding or textured video.

The patent of S3TC is on the algorithm which do the compression and decompression. I believe this summer someone finished a compressor/decompressor not using the same algorithm so free from the patent issue, so we should see S3TC support soon. Otherwise you can send S3TC texture already compressed to the card even on R300 but you won't be able to fallback to software, anyway you don't want.

[Malikith]

Well either way, this is a huge help. Will we ever be able to use open source drivers to play games like Doom 3 at decent quality levels? I think so. I don't think we'll ever get as fast as say a proprietary driver. But it will surely avoid the bugs of one and be solid and reliable.

Mesa will only continue to get better, alternatives to things such as S3TC are coming along by the sounds of it. I am willing to bet we'll be able to play Doom 3 at maybe 1024x768 at medium/high at decent speeds in about a year or two on a open source driver.

[Svartalf]

So if I understand you correctly (and this is in fact an issue that really matters to me) is that if the textures are already compressed (like those present in UT'99) in the right format, the hardware will all the same decompress them, despite of the driver (provided the driver knows how to interpret these textures)? can the DRI R200/300 drivers do this?; however if the application requires that the driver (either in the CPU or GPU, but before the textures hit the VRAM) do the compression (dynamic compression?) through the use of the GL_EXT_texture_compression_s3tc | GL_S3_s3tc, is that there'd be a patent issue? Talking about the specific case of S3TC here, dunno if it applies to other portions like Z-compression and/or MPEG decoding or textured video.

Yes, if the textures are already compressed, you can supply them to the card as compressed, using a different OpenGL call. Typically, this is what is done if the card advertises that it supports that compression. If you do this, you don't trip yourself up on the patent as the royalties, etc. have already been paid by the hardware vendor. The same applies for the other issues of concern to you. In the case of S3TC, you just can't compress them from the regular API edge (supplying uncompressed textures to the card and telling it that it's internal representation is compressed with S3TC...) as this would require stepping on the patent until recent times.

It's not patents preventing the uses of this stuff or technical information being released. It's companies listening to their patent attorney and feeding the general public a line about that. The only thing that would have IP encumbrances would be the proprietary driver- that might well have some 3rd party stuff in it that precludes opening it. That's okay, though, give us enough time- we'll have comparable performance without all that stuff in ours if they give us what they're telling us they're giving.

[Thetargos]

And now (like pretty much every year ever since 3dfx disappeared) I have to wonder: Why didn't FXTC made into widespread adoption? Supposedly it had better compression ratio than S3TC and [MUCH] better quality, it was made open from the get go, and alas, didn't pickup steam. I know of no other cards that support it, other than the V100 Voodoo 4-5 cards of late '99 early 2000.

[zorn169]

Why didn't FXTC made into widespread adoption?
I remember reading that there were possible patent problems with it. It's just a shame that possible patent problems were enough to scare people out of supporting it.