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?
Announcement
Collapse
No announcement yet.
AMD: GPU Specifications Without NDAs!
Collapse
X
-
Originally posted by Thetargos View PostNow, 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?
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.
Comment
-
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)
Comment
-
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)Last edited by Regenwald; 11 September 2007, 04:19 PM.
Comment
-
Originally posted by Thetargos View PostOnly in this case, it would be a hardware patent, as even if it is an algorithm, it has a hardware component where it runs.
Comment
-
Originally posted by Svartalf View PostThe 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.Last edited by Thetargos; 12 September 2007, 02:15 AM.
Comment
-
Originally posted by Thetargos View PostSo 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.
Comment
-
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.
Comment
-
Originally posted by Thetargos View PostSo 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.
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.
Comment
Comment