Linked by lemur2 on Wed 18th May 2011 13:58 UTC
Linux Efforts to implement NVIDIA's Video Decode and Presentation API for Unix (VDPAU) on the open source Radeon Gallium3D drivers (for AMD/ATI chipsets) are reportedly just beginning to work. Being Gallium3D-based means this new VDPAU state tracker is using GPU shaders and not the dedicated Unified Video Decoding (UVD) engine found on modern Radeon HD graphics processors, but using shaders is still a big performance win for HD video playback compared to pegging the CPU constantly. Also, MPEG-2 is the only codec known to work at this time. Once the basic state tracker functionality works, support for other video codecs, such as VP8 and H264, should be relatively easy to add.
Thread beginning with comment 473566
To read all comments associated with this story, please click here.
Nice work..
by fithisux on Wed 18th May 2011 15:13 UTC
fithisux
Member since:
2006-01-22

but I feel that developers waste their efforts. What we need is standardized hardware. This effort is good only for linux and it hides the fact that there are only 2 players in the GPU industry. In my understanding we need a hardware interface like USB/USB mass storage for example in order to make use of accelerator cards and leave once and for all the hardware dark ages. Even in cloud computing people are trying to avoid vendor lockin. The above work is linux/ati-nvidia lockin and though I love linux this is not something I am very happy. We need standardized accelerator cards that could work out of the box with every OS that chooses to support them. Kudos to developers but it is not how things are supposed to work. Unfortunately I see the same attitude in ZiiLabs and VIA. Where are the standard bodies?

Reply Score: 3

RE: Nice work..
by No it isnt on Wed 18th May 2011 18:09 in reply to "Nice work.."
No it isnt Member since:
2005-11-14

As if that is ever going to happen.

Reply Parent Score: 2

RE: Nice work..
by Neolander on Wed 18th May 2011 19:07 in reply to "Nice work.."
Neolander Member since:
2010-03-08

The standard bodies have tried to do something...

http://en.wikipedia.org/wiki/VBE#VBE.2FAccelerator_Functions_.28VBE...

...it failed miserably.

Reply Parent Score: 2

RE[2]: Nice work..
by WereCatf on Wed 18th May 2011 20:12 in reply to "RE: Nice work.."
WereCatf Member since:
2006-02-15

The standard bodies have tried to do something...

http://en.wikipedia.org/wiki/VBE#VBE.2FAccelerator_Functions_.28VBE...

...it failed miserably.


It was a good idea, and back in '96 it was quite advanced too, but it simply wasn't flexible enough and thus didn't gain enough traction. I actually had a card with a subset of VBE implemented and was toying around with it for a while, just out of curiosity.

Sadly hardware vendors have absolutely no interest in implementing a modern version of such; user lock-in is so much more profitable.

Reply Parent Score: 3

RE: Nice work..
by galvanash on Wed 18th May 2011 19:40 in reply to "Nice work.."
galvanash Member since:
2006-01-25

In my understanding we need a hardware interface like USB/USB mass storage for example in order to make use of accelerator cards and leave once and for all the hardware dark ages.


USB hardware is ridiculously simple and has an incredibly limited scope compared to what a GPU does. It was also built on the back of the standards that came before it (UART) and has had over 30 years to mature. The main thing that makes USB appropriate for hardware standardization is that it has a very simple and narrow external interface to software - it does nothing more than move bytes back and forth.

Pointing at USB as an example is silly - a GPU is at least a few orders of magnitude more complex on the outside (let alone internally).

We had standardized graphics hardware once, remember VESA BIOS Modes? There are only about 20 or so actual functions available in VBE 3.0 - its useful to a point, but it only implements a very tiny subset of what a video card can actually do even in the basic world of 2D. Regardless, the vast majority of real world video drivers did not use VESA BIOS, it was ok as a fallback when nothing else was available but it was much slower than using drivers written against native hardware functionality. And it never even thought about dealing with 3D...

Even fixed function 3D is insanely complex. 3D with unified shaders is even more complex, but at least the external facing stuff is gradually converging on like-minded interfaces. Regardless, we haven't even reached a point where the basic rendering method used by 3D hardware has converged - you have some cards that use tile-based rendering, some that use z-occlusion, some have even proposed doing ray-tracing. Some development is better done using immediate mode APIs, others deferred rendering. I have no idea how you could possibly standardize all this in hardware when there are so many non-trivial differences that have to be exposed to make writing a functional API layer workable.

The above work is linux/ati-nvidia lockin and though I love linux this is not something I am very happy.


VDPAU is a vendor lockin? How? Sure Nvidia originally wrote it, but it is wide open. SG supported it in their Chrome GPUs (for what that is worth), so other 3rd parties could have done it. It is no longer an Nvidia API - it is a Linux API. All Intel, ATI, etc. need to do to support it is write support for it in their drivers.

We need standardized accelerator cards that could work out of the box with every OS that chooses to support them.


We have that now with OpenGL, and it doesn't require standardized hardware. If you specifically mean video decode acceleration remember we are talking about GPUs - there is no standard for that because the video card for the most part doesn't actually implement anything that looks like video decode acceleration... VDPAU (ideally) uses general purpose shader features on the GPU to do its work - there is not "special" hardware and therefore no "special" hardware interfaces.

If you want fixed function video decode accelerators there are many available, and standardizing those might even make sense - but that has nothing to do with VDPAU or GPUs in general.

Edited 2011-05-18 19:42 UTC

Reply Parent Score: 8

RE: Nice work..
by mat69 on Wed 18th May 2011 21:32 in reply to "Nice work.."
mat69 Member since:
2006-03-29

Only two players for GPUs? I wonder what these should be ...
I guess you meant just AMD and Nvidia, though you are totally wrong on that. There are a lot more players and some major like Intel.
And yeah the "crappy" Intel GPUs are good enough to accelarate videos.

Btw. Gallium3D is cross plattform, so not just Linux.

Reply Parent Score: 3

RE[2]: Nice work..
by twitterfire on Wed 18th May 2011 23:56 in reply to "RE: Nice work.."
twitterfire Member since:
2008-09-11

Only two players for GPUs? I wonder what these should be ...
I guess you meant just AMD and Nvidia, though you are totally wrong on that. There are a lot more players and some major like Intel.
And yeah the "crappy" Intel GPUs are good enough to accelarate videos.

Btw. Gallium3D is cross plattform, so not just Linux.


What he meant is there are only two manufacturers who matter.

Reply Parent Score: 2

RE: Nice work..
by twitterfire on Wed 18th May 2011 23:54 in reply to "Nice work.."
twitterfire Member since:
2008-09-11

but I feel that developers waste their efforts. What we need is standardized hardware. This effort is good only for linux and it hides the fact that there are only 2 players in the GPU industry. In my understanding we need a hardware interface like USB/USB mass storage for example in order to make use of accelerator cards and leave once and for all the hardware dark ages. Even in cloud computing people are trying to avoid vendor lockin. The above work is linux/ati-nvidia lockin and though I love linux this is not something I am very happy. We need standardized accelerator cards that could work out of the box with every OS that chooses to support them. Kudos to developers but it is not how things are supposed to work. Unfortunately I see the same attitude in ZiiLabs and VIA. Where are the standard bodies?


The easiest thing will be to make part of the drivers contained in firmware and provide a standard interface to any OS. Like an EFI or "BIOS" for graphic cards.

Reply Parent Score: 2

RE[2]: Nice work..
by f0dder on Thu 19th May 2011 13:28 in reply to "RE: Nice work.."
f0dder Member since:
2009-08-05

You'd still have to standardize on an interface to this, though - which would either kill innovation, or require updates frequently enough that you end up not having much of a standard anyway.

Reply Parent Score: 1

RE: Nice work..
by smitty on Thu 19th May 2011 01:46 in reply to "Nice work.."
smitty Member since:
2005-10-13

This effort is good only for linux and it hides the fact that there are only 2 players in the GPU industry.

The above work is linux/ati-nvidia lockin and though I love linux this is not something I am very happy.

This should work for any hardware that has a gallium driver for it, and that framework was carefully designed to be portable across hardware and operating systems. Although at the moment, Linux + ATI/NVidia is pretty accurate.

Reply Parent Score: 3

RE: Nice work..
by t3RRa on Thu 19th May 2011 03:39 in reply to "Nice work.."
t3RRa Member since:
2005-11-22

In my understanding we need a hardware interface like USB/USB mass storage for example in order to make use of accelerator cards and leave once and for all the hardware dark ages.

USB Mass Storage is AFAIK in a simple term a proxy between USB and PATA/SATA. It is transferring merely an already-standardized protocol of hard drives. Do you install different driver for each different hard drive? I do not think.

Let's see all of USB devices. Unless it has some standard protocol for that part of devices, each has it's own driver to work properly.

Therefore, as someone else pointed out, you have come up with inappropriate example.

Actually, OpenGL should be the de-facto standard but except for Microsoft devices (Windows machines and Xbox) and some(few) devices with own proprietary API, OpenGl is actually the standard to tinker with Graphics for most of computer devices.

Unfortunately, this post is about video decoding but about graphics driver so ... may I vote you down as off-topic ? :p

Reply Parent Score: 2

RE: Nice work..
by f0dder on Thu 19th May 2011 13:23 in reply to "Nice work.."
f0dder Member since:
2009-08-05

Please, no.

We wouldn't have the kick-ass GPUs we have today if a hardware compatibility requirement had been enforced.

Yes, it would make the life of hobbyist OS developers easier, but it would be at the expense of the majority, who'd rather have *fast* hardware acceleration than simply have access to basic functionality across a wide range of devices.

I'd rather have two major vendors with decent products than a whole bunch of vendors with semi-sucky products, like we had back in the dark old DOS days.

Reply Parent Score: 0

RE[2]: Nice work..
by Neolander on Thu 19th May 2011 13:50 in reply to "RE: Nice work.."
Neolander Member since:
2010-03-08

On the OS-software interface side, OpenGL and DirectX are standardized, with relatively infrequent changes.

Why couldn't this happen on the hardware-OS interface side ?

It's not as if GPU vendors innovate so much that they need new standards all the time anyway. From time to time we see a new feature like unified shaders or tesselation, but most of the time it's really just stacking more and more shaders on a single chip and making them run faster.

Edited 2011-05-19 13:50 UTC

Reply Parent Score: 3