AMD: GPU Specifications Without NDAs!

[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.