AMD Releases Open-Source R600/700 3D Code

[energyman]

so what? are people watching blueray disks on their low level linux boxes? when you have the money to spent on a blueray player, you also have the money to buy a cpu with more than a 1ghz.

And tv?
'normal' digital tv is SD anyway - and handled easily by every cpu produced in the last 10 years.
And hd tv? Well - what about a decoder card? You need it anyway, so you can spent the few bucks more for one with hardware decoding, or on a better cpu.

In the mean time - 3d is something you can't go around with a better cpu. And 2d is far from perfect either. 2d is certainly more used than hd video watching.

So again, vocal minority.

[popper]

Nitpick old Mpeg2 SD and CIF type low bitrate encodes can be decoded by......K6-2 400 etc.

a K6-2 400 or 500MHz that i have cant decode PAL SD 50i thats broadcast at greater than 1.3Mbit/s on the DVB-T mpeg2 streams.

20Mbit HD 720P/1080i/P is totally another matter....

[energyman]

> Just to be clear, we're dealing with finite resources here
> so the question is not "would it be nice to have MPEG2 accel ?"
> it's "should the community work on MPEG2 accel instead of
> H.264/VC-1 accel ?".

Mpeg2 accel is needed NOW. NTSC goes away in 6 weeks. ATSC is
Mpeg2, and many people don't have CPUs fast enough to decode HD
in real time, and some people probably don't have CPUs fast enough
for SD.

mpeg2 decoding can be easily done by a K6-2 400 - that is a 10 year old cpu....

[bridgman]

OK, now *that* is a useful answer.

BTW I mentioned that I don't watch TV only because someone posted that "obviously you watch TV so...". My personal habits should not be driving development decisions anyways

Serious question though -- do you really believe that people who rely on their analog TV today for critical information are going to go out and buy a tuner card for their too-slow-to-decode-MPEG2 Linux PC and have that as their only option, ie they would not pick up a cheap set-top box to convert from ATSC to NTSC ? I can imagine maybe 10 people falling into that scenario, not tens of thousands.

Anyone who already had an ATSC tuner card but could not decode the signals would have upgraded their PCs already or would not be relying on it. I have a tough time believing that they are sitting at home hoping that we will implement MPEG2 acceleration before Feb 11, or am I being too cynical here ?

[Dieter]

> Just to be clear, we're dealing with finite resources here
> so the question is not "would it be nice to have MPEG2 accel ?"
> it's "should the community work on MPEG2 accel instead of
> H.264/VC-1 accel ?".

Mpeg2 accel is needed NOW. NTSC goes away in 6 weeks. ATSC is
Mpeg2, and many people don't have CPUs fast enough to decode HD
in real time, and some people probably don't have CPUs fast enough
for SD.

IIRC you wrote that you don't watch tv and perhaps you don't think it
is important. But TV is more than just entertainment. It is an
important part of the modern communications infrastructure. Many
people depend on TV to get news about time critical problems, both
natural (snow, ice, wind, earthquake, tsunami, volcano, tornado,
hurricane, land slides, forest fires, floods, etc.) and man made
(9-11, etc.). Is the tap water safe to drink? Am I supposed to
try and get to school/work? Is transportation working, or have
they closed the highways, and canceled the trains and planes?

> If you were combining the families, what would the sequence be ?

Mpeg2 accel is needed NOW.

I've been asking about Mpeg2 accel for months (years in some forums).
It is H.264/VC-1 accel that would be "nice to have", but that is
entertainment, not critical news. Same for 3D. 3D is "nice to have",
but is not needed to get critical news.

[popper]

hmm , perhaps , but non the less "a vocal minority" that puts in their picket every time theres a new use for their minority interest.

and lets face it, theres far more people into video than any 3D linux use, sure linux 3D is cool, but it does nothing for your Co-Location ISP usage,HW assisted decoding/transcoding, and other related NON 3D processing etc will find its way into the data center for home/SOHO use to name but one example.

[energyman]

people dont want a poll this late in the game, they want and NEED a real subset AVC decode and related libray ASAP, perhaps as a tempory stop gap measure until it all settles down later if needs be, PLUS development headers and DOCUMENTATION, and sample full working code showing anyone how to use it ASAP/TODAY.

no, people want 3D perfornance first. As shown here:

http://www.phoronix.com/scan.php?page=article&item=lgs_2008_results&num=5

so all that crying about video decoding is just a vocal minority - like always.

[bridgman]

its been said that "the API is the least of the problems" and thats true to some degree, but Bridgeman has stated he beleaves theres enough data documentation out there right now.

presumably that means theres enough information right now for someone here ? to take parts of the ATI/AMD API(s) and make an equivenent VDPAU ?

The thread where I posted that was about XvMC. What I said was that there was enough information out there to implement XvMC. The information released is also sufficient to accelerate the back half of H.264/VC-1 decode (from inverse quantization onwards, with the rest being done on CPU. There's a good chance that frames using spatial prediction would need to have more of the work done on CPU.

The unfortunate thing is that they didn't also ship any development headers with the driver, with the result that the binary libraries were available, but there was no SDK or information available to media player developers to actually utilize the libraries. So XvBA currently remains a white elephant.

No, it remains an unannounced feature which some clever people have started picking apart and talking about already.

remember also that its 4 months since the library(s) have been available, so alpha/beta test code at the very least must exist on the ATI devs machines to show off this new libray use, but still NO docs are available that i know of, to explain how you might use this library or its official API for hardware assist video decoding etc, WHY AS THAT?

Because we haven't released it yet as far as I know.

[popper]

Just to be clear, we're dealing with finite resources here so the question is not "would it be nice to have MPEG2 accel ?" (even I can answer that one ) it's "should the community work on MPEG2 accel instead of H.264/VC-1 accel ?", ie which should be worked on first ?



The GPU programming is pretty much the same for the two families, so sequence of implementation would be the same for both. If you were combining the families, what would the sequence be ?



Agreed, but that is another example of a workload which needs specialized hardware and is difficult to parallelize

Oh,theres your problem , your thinking taking your workload and trying to parallelize it, you should be thinking micro-kernel and multitasking in the same vain as Carl Sassenrath of the original home mutitasking Amiga OS and rebol http://en.wikipedia.org/wiki/REBOL TCP/IP GUI scripting fame.

actually, rebol GUI scripting would be a very good thing to use for any cross platform GUI HW assisted front end, and Carl's old AOS multitasking kernel Co-Processing ideas would work great for todays Gfx cards,plus a simple JIT backend/frontend perhaps, go ask him over on rebol.org

[popper]

people dont want a poll this late in the game, they want and NEED a real subset AVC decode and related libray ASAP, perhaps as a tempory stop gap measure until it all settles down later if needs be, PLUS development headers and DOCUMENTATION, and sample full working code showing anyone how to use it ASAP/TODAY.

some basic benchmark code/charts for each proposed code example might be nice to, so you can decide at a glance which routine or usage suits your requirements for code review and insertion into the likes of FFMPEG etc..

its been said that "the API is the least of the problems" and thats true to some degree, but Bridgeman has stated he beleaves theres enough data documentation out there right now.

presumably that means theres enough information right now for someone here ? to take parts of the ATI/AMD API(s) and make an equivenent VDPAU ?

call it an alpha AVIVO.lib for AVC,vc1,Dirac, and even mpeg2 if its only another entry point in the lib API.

remember, the actual ATI hardware can officially decode all but one of these already ,some video Dev here reading must be capable of running up a quick HW assist AVC decode library based on the ATI API in the same vain as VDPAU being used right now in ffmpeg code in a few days and posting it here ?

there MUST be some test API code sat on the ATI/AMD devs PCs Bridgeman is in contact with and can get their permissioon to use and contribute an hour or so for outside use, to learn from, and use in a basic alpha state open avivo libary.

as Prototyped outlined here

http://episteme.arstechnica.com/eve/forums/a/tpc/f/96509133/m/467009165931

"....
In September, ATI released their Catalyst 8.9 driver with X Video Bitstream Acceleration (XvBA) libraries that could be enabled using tools that shipped with the driver, and then last month, the 8.10 driver enabled the UVD2 video acceleration by default.

The unfortunate thing is that they didn't also ship any development headers with the driver, with the result that the binary libraries were available, but there was no SDK or information available to media player developers to actually utilize the libraries. So XvBA currently remains a white elephant.
..."


for PR purposes and to try and make outsiders equate the ATI/AMD library to VDPAU subset library, i think it should be called AVIVO.lib not XvBA , X-Video Bitstream Acceleration (XvBA), were people are confusing it with the old X-Video Motion Compensation (XvMC)


remember also that its 4 months since the library(s) have been available, so alpha/beta test code at the very least must exist on the ATI devs machines to show off this new libray use, but still NO docs are available that i know of, to explain how you might use this library or its official API for hardware assist video decoding etc, WHY AS THAT?
a poll is wasting peoples times, were are these X-Video Motion Compensation (XvMC) docs so FFMPEG people and the like MIGHT stand a chance to get some parity with the current HW assist VDPAU FFMPEG code diffs....

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

"...
From Wikipedia, the free encyclopedia
(Redirected from XvBA)
Jump to: navigation, search
X-Video Bitstream Acceleration (XvBA), designed by AMD for its ATI Radeon GPU, is an extension of the X video extension (Xv) for the X Window System on Linux operating-systems[1].

XvBA API allows video programs to offload portions of the video decoding process to the GPU video-hardware. Currently, the portions designed to be offloaded by XvBA onto the GPU are motion compensation (mo comp) and inverse discrete cosine transform (iDCT), and VLD (Variable-Length Decoding) for MPEG-2, MPEG-4 AVC (H.264) and VC-1 encoded video.

XvBA is the Linux equivalent of the Microsoft's DirectX Video Acceleration (DxVA) API for Windows.[2]

...
"

seeing as it seems to be the fashion, and the fact ATI/AMD sold them to us as giving you access to some form of hardware assisted video decode/playback etc with a driver update, i have several X1550,HD3650 and looking to get some HD4xxx soon if something HW assisted code comes home sometime seen, or something else to start advocating werever we go....


as it happens, the lads HD3650 has a large 1gig memory on it, i wonder if pre-loading/pipeing some video through a FIFO to the cards internal memory might improve any future HW assisted processing!