AMD Preparing For Another GPU Documentation Release

[Svartalf]

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.

This is interesting. Does the AIW hardware do video stabilization or is it much like the sync, etc. hardware on something like a VCR or DVD recorder? If it doesn't have any stabilization hardware, I'd love to know what "additional" stuff they've got in there in over and above Macrovision.

If there's nothing magic in that regard, then you guys technically have nothing to worry about as the capture hardware will simply fubar up on the signal just like any other standard recording device would. Now, the same can't be said about the video output hardware, but the reality is that all one has to do is put in a VGA to composite device in the mix to sidestep the restrictions there as you're not able to realistically expect someone to not hook a projection monitor or a scanline converter on the analog out port or the DVI port to get a raw feed (And this doesn't even begin to touch on what one can do if they've got a DV bridge on a 1394 bus leg...).

As it stands, we didn't seem to have any restrictions at Coollogic on using composite out from the Allwell (Tvia 2xxx and 5xxx VGA) or the ECS designed (Hardware never released, devices used either an SiS 300 variant GPU or a Savage4 variant GPU...) set-top boxes, nor were there any requirements for us to do so at that time- for us the composite/SVGA was hot and used instead of the VGA port the moment you hooked it up to a TV. It could be that it was because we were more operating in the internet appliance space and only peripherally providing things like video feeds from off the Internet via RealPlayer and Flash...

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.

Heh... Well, one can just simply bring up whether those agreements are relevant in this day and age (as they're kind of moot from one end to another...); but I won't press on that subject. I know better than that. I'll be emailing you shortly- kind of busy with trying to sort out IP assignment issues with a prospective employer (Heh... They want everything and I'm trying to get them to back down from that position as I do things that have nothing to do with their lines of business and I don't want them IP-grabbing things on me...), trying to sort out said employer as a client's problems, and trying to sort out an issue with Bandits:Phoenix Rising on the LGP version of the title.

[bridgman]

This is interesting. Does the AIW hardware do video stabilization or is it much like the sync, etc. hardware on something like a VCR or DVD recorder? If it doesn't have any stabilization hardware, I'd love to know what "additional" stuff they've got in there in over and above Macrovision.

My understanding is that we can capture protected video quite reliably. With great power comes great responsibility.

If there's nothing magic in that regard, then you guys technically have nothing to worry about as the capture hardware will simply fubar up on the signal just like any other standard recording device would. Now, the same can't be said about the video output hardware, but the reality is that all one has to do is put in a VGA to composite device in the mix to sidestep the restrictions there as you're not able to realistically expect someone to not hook a projection monitor or a scanline converter on the analog out port or the DVI port to get a raw feed (And this doesn't even begin to touch on what one can do if they've got a DV bridge on a 1394 bus leg...).

I don't think we fubar up. That's the problem. We have to make it stupid in the driver.

As it stands, we didn't seem to have any restrictions at Coollogic on using composite out from the Allwell (Tvia 2xxx and 5xxx VGA) or the ECS designed (Hardware never released, devices used either an SiS 300 variant GPU or a Savage4 variant GPU...) set-top boxes, nor were there any requirements for us to do so at that time- for us the composite/SVGA was hot and used instead of the VGA port the moment you hooked it up to a TV. It could be that it was because we were more operating in the internet appliance space and only peripherally providing things like video feeds from off the Internet via RealPlayer and Flash...

Were you protecting the outputs from the set top box using a licensed copy protection technology ? If not, then no restrictions on what you do with protected inputs AFAIK. Having said that, we're rapidly approaching the limits of what I am sure of right now so I'm gonna ask if we can stay away from copy protection legalities for a few more months

[Svartalf]

My understanding is that we can capture protected video quite reliably. With great power comes great responsibility.

Nice. Shame the media companies have to be stupid about this. The truth be known, most of it is akin to locking excrement up inside of a safe within a safe...

I don't think we fubar up. That's the problem. We have to make it stupid in the driver.

Great. Just great.

Were you protecting the outputs from the set top box using a licensed copy protection technology ? If not, then no restrictions on what you do with protected inputs AFAIK.

Now, that's just perverse. No, the stuff was un-"protected" the moment you put it into composite out mode. We didn't have any Macrovision turned on in anything we had running on those set-tops- no licenses involved in that regard. Nobody was requiring us to put copy-protection on anything we were doing. Could be because nobody saw us on their radar to turn around and mug us over it.

Having said that, we're rapidly approaching the limits of what I am sure of right now so I'm gonna ask if we can stay away from copy protection legalities for a few more months

Consider it dropped for now. I now know more about the issue- while I don't like what I've found out, it's not your fault, and I can live with what I've been told for now. I want 3D support that works first and foremost. That's a lot higher up on my list of desires.

[Extreme Coder]

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.

Well, I think you're a bit mistaken in that, since my X1200 (which is an X1250 without HDMI) works out of the box with Mandriva, without me doing a single thing. IDK about other distros though.

[yoshi314]

which is an X1250 without HDMI

hdmi might make a big difference. besides x1250 != x1200.

[Extreme Coder]

hdmi might make a big difference. besides x1250 != x1200.

http://en.wikipedia.org/wiki/AMD_690_chipset_series

All chipsets in the series (excluding RD690 and RX690) features an Integrated Graphics Processor (IGP) which is incorporated into the northbridge of Radeon X700-level on an 80 nm fabrication process. The IGP contains 4 pipelines, 2 vertex shaders capable of Shader Model version 2.0 with DirectX 9b compatibility but not compatible with DirectX 10. It uses shared system memory under UMA. The IGP also includes AVIVO capabilities used in Radeon X1000 series, for hardware decoding of videos with recommended video playback of resolution up to 720p/1080i.

The X1250 and the X1200 are from the same chipset family, and like I said, the X1200 is an X1250 without the additional video features:

690G
For 690G, the IGP was named as "Radeon X1250" operating at 400MHz IGP clock frequency, with HDMI and dual link DVI-D output with HDCP support and TDMS support for HDMI output. The chipset also support dual VGA and DVI or DVI and HDMI output simultaneously, to achieve a maximum of three monitor output, called "SurroundView", and up to four independent displays with an additional video card.

The 690G chipset also support a maximum of 24 additional PCI Express lanes and a PCI Express x16 lanes expansion slot, and the chipset mixed audio and video signals and output through the HDMI interface. The mobile version of the chipset is the M690 chipset (codenamed RS690M). [9]


690V
For 690V, "Radeon X1200" was the name of the IGP, with clock frequency of 350MHz. The major differences between the 690G and 690V chipsets is that the 690V chipset lacks support for TMDS output and no HDMI output, therefore limited to VGA or LVDS output only. The mobile version of the chipset is the M690V chipset (codenamed RS690MC). [9]

[bridgman]

http://en.wikipedia.org/wiki/AMD_690_chipset_series

The X1250 and the X1200 are from the same chipset family, and like I said, the X1200 is an X1250 without the additional video features:

What he said. My understanding is that the core is the same on 1200, 1250, 1270 but the features (and possibly clocks, not sure) are different.

690T = X1270
690 / 690M = X1250
690V / C / MC = X1200

It looks like there are only two device IDs in use, however, so it's pretty hard for the driver to accurately identify which variant is running and put up the proper name. I don't think it matters, though, since the BIOS is different for each system and the driver navigates the BIOS to find which clocks, features, and outputs to use.

[Dieter]

> I hadn't really thought about Rage parts --
> honestly we weren't planning on going back *that* far.

What do you mean "going back *that* far" ?
Boards with Rage parts are still being sold.
Please support parts that are still being sold!

> I'm pretty sure MPEG will get covered,

Thank you!

[chrisr]

That sounds about right

As a Mesa developer recently told me:

Feel free to open an enhancement bug for reading/writing depth with hyperz, but don't expect anyone to fix it...

This kind of nonsense means that Mesa's HyperZ support cannot be enabled by default.

[Svartalf]

This kind of nonsense means that Mesa's HyperZ support cannot be enabled by default.

No, that means that it's very, very difficult to RE the feature in question- and if they had the info, it'd probably be a different story. There's a reason why people have been complaining about some of the omitted stuff from the R100/R200 documentation releases- and there was little good reason for the omissions in most cases.