AMD Continues Updating Its R500 Documentation

[V!NCENT]

@MostAwesomeDude,
Would a 9800pro (older r3x0) be useful?

[Temar]

http://www.x.org/wiki/CorbinSimpson lists the cards I have.

You got a lot of old crap :-)

Feel free to send me cards I don't have, but I make no guarantees about what I do with them. :3

Are you interested in Nvidia cards, too? I got a Nvidia 7xxx and a 8xxx. Maybe a 9xxx, too if I can find it. And if you are lucky I might even find some old crap cards in my drawer from different vendors (mostly Nvidia) :-)

[Dieter]

> Depends on what you mean by complete.

Complete meaning that everything we might want/need to know about how
to use the chip is documented and available on the web with no NDA.

datasheet: pinout, Voltages (min, max, etc.), timing diagrams, etc.
the usual EE stuff.

programming: how to use *all* the features.

> DSPs would be OK for implementing codec du jour except there aren't any
> DSPs in a typical PC system while there are usually is a pile of shader engines.

My (feeble) understanding is that DSPs would be better than shaders due to
(1) integer vs floating point, (2) they would use less power and (3) maybe
be less expensive. (There is also the FPGA approach, but FPGAs are expensive
and power hungry.) E.g. if you are starting from scratch designing a
programmable video decoder, DSP would be the best way to go? Less
expensive and lower power consumption than decoding using a CPU or using
a GPU's shaders?

[nanonyme]

For clarity, we didn't promise to separate out DRM from decode, just to make sure the issue of useability with open source drivers *was* on the table with future designs and that we did proceed *if* the impact on cost & performance was not prohitive.

In other words we promised to *try*, no more.

Fair enough, simply putting the matter on the table during planning meetings is already a good thing.

[agd5f]

For reference, the xvmc/vaapi decode support in the intel driver is shader-based (at least for pre GMA 4500HD asics).

[whizse]

In all seriousness, I was referring to the idea that there might be GPUs out there that have full-on MPEG-4 decoding onboard, that are fully supported by some open driver. </thatsthejoke>

Intel, I guess, for G45 and up, but I haven't tried it myself yet.

Not sure how they handled the whole DRM situation though...

[agd5f]

On cards prior to r6xx, video decode was done using the 3D engine (there was no UVD on those asics), so the hardware is capable and the documentation is available.

[MostAwesomeDude]

What do you need and in which country do you live in?

http://www.x.org/wiki/CorbinSimpson lists the cards I have. Feel free to send me cards I don't have, but I make no guarantees about what I do with them. :3

In all seriousness, I was referring to the idea that there might be GPUs out there that have full-on MPEG-4 decoding onboard, that are fully supported by some open driver. </thatsthejoke>

Does this documentation mean we're a step closer to getting FSAA support in the open source drivers?

Yes! Somebody read the article!

I have a series of patches that does MSAA on r300-r500 for Gallium, and I'll merge that as soon as it works correctly. Also, SSAA will be trivial in Gallium; somebody just has to write up a bit of glue and add support for the SSAA extension in GL. (And also maaaaybe extend DRI/GLX. Ugh.) FSAA might be tricker, depending on exactly how the HW works. Supposedly, it's in r300-r500, but I haven't quite confirmed. Come to think of it, I'm not sure if the code I have right now is MSAA or FSAA. Figures.

[bridgman]

Depends on what you mean by complete. I don't think we have any more documentation in the pipe for 5xx and earlier so I guess you could say it's complete now.

The new documentation should halp with implementation of MSAA.

DSPs would be OK for implementing codec du jour except there aren't any DSPs in a typical PC system while there are usually is a pile of shader engines.

[Dieter]

> One advantage to shader based video decode is that it can be
> extended to support lots of new formats pretty easily while
> fixed function hardware is generally limited to a specific set.

I suspect it will be a long time before broadcasters switch from
mpeg2 transport stream, given the huge installed base of hardware
mpeg2ts decoders. Are they even allowed to use a different codec
or do they need permission from the FCC (or equivalent)?

Similar issue for DVD and BluRay.

Most web sites don't care about standards, so those with T1 lines
can deal with the codec du jour.

For programming up the codec du jour, wouldn't DSP be a better
way to go than shaders?

But to get back on topic, when can we expect the documentation to be complete?