Slashdot Mirror
Hardware-Based Video Acceleration Coming To Linux
sammydee writes "Phoronix reports that GPU based video decoding acceleration will be implemented in Gallium3d sometime this year. Drivers currently using Gallium3d include the open source nouveau driver for NVIDIA cards and experimental Intel GMA drivers. This is definitely good news for anybody who has ever tried to play high-definition 1080p content on any CPU older than about a year."
I suppose I'm both ignorant and stupid, having been out of the build-your-own-box scene for more than five years now, because whenever I stroll past the video card section at best buy I swear I read things like, "LIGHTNING FAST DVD PLAYBACK AND VIDEO DECODING!" I had no idea video decoding was still CPU dependent. Give the governor harumph, I guess.
A-Bomb
... you mean we can do all the fancy stuff windows can, and better. But playing videos efficiently was the one thing we couldn't do? We had fancy GUI effects long before windows, we had efficient RAM usage, great file systems, but we had trouble playing a fucking video?
Wow, wish I'd known.
first 1080p post?
The answer to all your problems
Gallium 3D will provide a unified API exposing standard hardware functions such as shader units found on modern hardware. Thus, 3D APIs such as OpenGL 1.x/2.x, OpenGL 3.x, OpenVG, GPGPU infrastructure or even Direct3D (as found in the Wine compatibility layer) will need only a single back-end, called state tracker, targeting Gallium 3D API.
Nearly-as-important things like Folding!
My turnips listen for the soft cry of your love
nVidia's binary drivers and X.org's Intel drivers have had XvMC support for well over a year. I've been using both card successfully with Xine and accelerated 1080p video. I think the news here is that the nouveau project is catching up, but that's hardly clear from the article.
Interested in open source engine management for your Subaru?
This is apparently a google summer of code project.
While I am hopeful, let's not write this one on stone until it's released.
Help! I'm a slashdot refugee.
This is definitely good news for anybody who has ever tried to play high definition 1080p content on any CPU older than about a year.
Actually, one of the most preeminent examples of HW decoding of video nowadays is the Intel Atom processor, not really old processors.
Video accel. is inside the chipset for this one.
And yes, it is available in Linux, you will probably be able to watch h264 movies in your new EEEPC
how long until
Xine has supported hardware accelerated DVD video (MPEG1/2) decoding using EM8300 based cards like Sigma Design's Holywood+ and Creative's DXR3, since about 2000.
(But that was done using an ad-hoc module inside Xine, not using generic APIs like XvMC or the future Gallium3d video)
The Gallium3D Video API is a good news, because it'll probably be able to address shortcommings that XvMC has.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Hardware Accelerated High Definition Pr0n vids Coming To Linux
But they're video card manufacturers, not OS providers. It's not anti-competitive in the slightest. Sour eggs, perhaps? :)
VGA was probably the most open video standard for hardware programming. Once you know what all the different registers were for, you could do all sorts of fun things, like having paged framebuffers, one super big 256-color framebuffer larger than the actual screen size, or reprogram the hardware video font.
That's probably what they fear - having lots of people trying out different ideas, rather than having one company (Microsoft) deciding their future for them.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
IIRC XvMC is only MPEG2 and not AVC (=x264?), VC-1, more common HD codecs.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
XvMC does only accelerate MPEG-2, and not many use it, because the de-interlacing you can get sucks. And for MPEG-2, you usually don't need hardware acceleration anyway.
nVidia, like ATI, are moving away from video overlays and have some pretty nice GPU-based video decoding built into their cards using the GPU (most of it probably implemented as shader programs).
But you can't use any of that with linux, you are basically down to hardware video scaling, which the newest cards no longer really support.
It is high time for a new, industry standard API for video. I hope that's what they are doing.
Last time I was trying to play HD video on my Ubuntu - with both Xine and Mplayer - I hadn't noticed that there was performance problem related to lack of HW acceleration. (I didn't tried VLC - it can't even playback smoothly HD video on Windows where such acceleration is already available.)
While CPU load was remaining low (~25% on dual core CPU), 720p video still was playing with terrible jitter. In Mplayer few minutes later A/V sync (as usually) went south. Xine started dropping frames. All that while nor CPU load, nor kernel times where displaying any anomaly.
I'd say that problem lies elsewhere and HW accel (though welcome) might not solve the video playback problems.
P.S. At least when there would be HW accel, it would be easier to bash the server/hpc/oracle folks who now monopolize completely LKML. Probably then they would start paying attention to desktop Linux needs. Quoter of the attention they spent discussion fresh Oracle benchmarks would be more than enough.
P.P.S. Tests (actually I was just trying to watch my anime on Linux) where done on AMD 4200+ X2 + nVidia gf7800gt (evil proprietary drivers are installed) + RAM 2GB DDR CL2.
All hope abandon ye who enter here.
I have an Opteron 165 processor that was released more than 2 years ago. There are articles going back to February 2006 on this chip. Its not even the fastest chip of that time. And it has handled every 1080p file I have thrown at it in software.
My thoughts on this are that if you want to watch 1080p on your computer, you probably have a fast enough processor by now anyway. If its an HTPC, the power you save on the CPU is just going to be redistributed to the GPU. If you want to play HD content on EEEPC type devices, you're probably better off transcoding since the screen is so small anyway and the storage options aren't enormous. Lastly, Mom-n-Gradma type computers generally have a reasonably fast CPU, but no GPU worth mentioning. If they should ever want to handle HD their computer probably can handle it.
I think the time for hardware accelerated 1080p has already passed, much like the time for DVD accelerators passed fairly quickly.
Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
There, fixed that for you. nVidia not releasing specs means you have to use their drivers. Intel not releasing specs for x86 would mean you can't do anything with it, fullstop. Yes, some OSes end up in a similar situation, but I don't see the Amiga OS crew complaining.
More on topic, it sounds promising. If only I didn't have a Radeon X800. Maybe when I make my Myth TV box I'll get an nVidia.
There, fixed that for you. nVidia not releasing specs means you have to use their drivers. Intel not releasing specs for x86 would mean you can't do anything with it, fullstop. Yes, some OSes end up in a similar situation, but I don't see the Amiga OS crew complaining.
More on topic, it sounds promising. If only I didn't have a Radeon X800. Maybe when I make my Myth TV box I'll get an nVidia.
I'm just trying to convey that the wrapping layer is OS-specific. You can't use nVidia's Linux drivers on OpenBSD or NetBSD. I should have a little bit more clearer: Just imagine how the world would have been if Intel just released x86 processors without specifying its instruction set but providing wrappers for only Windows. Then there would have been no other x86 OSs on earth since it would have been impossible for other OS-writers to create x86 OSs, no matter how competent programmers they are.
The largest prime factor of my UID is 263267.
Both of these are relatively new projects. From what I've seen, neither has any sort of releases or snapshots, you build from a checkout.
Any idea when I might be able to get a Jocular Jaguar (or Kooky Kangaroo or Languid Lemur) LiveCD and have them part of the base install? Or for that matter, have 'emerge --sync && ARCH="x86" USE="gallium3d" emerge nouveau' install them as "stable".
The living have better things to do than to continue hating the dead.
I'm not sure, but I've heard that a lack of hardware video acceleration is one of the factors which currently limits the capabilities of the PS3 as a linux machine (along with memory support and lack of emulators for the cpu architecture). This article gives me a bit of hope that we might see advances in the capabilities of the PS3 under Linux. ( http://ubuntuforums.org/showthread.php?t=624865 )
True, to a degree. There would have be other OSes, because some crazy (and talented) people would decide they wanted to spend their time reverse engineering it and making their own wrapper, just like people do for the graphics drivers. It would admittedly be a lot further behind, though.
Nope. OpenBSD users, or indeed anyone, do not have a right to use the hardware. I can see what you're getting at, but there is no reason for nVidia to open anything up. "Because it'd be cool" is not a good enough reason.
No. OpenBSD users do indeed have a RIGHT to use the hardware. They have
the same right to use it as anyone else. Any product should be fit and
suitable. If it's a product that is sold with the intent that consumers
will be doing their own systems integration then full documentation
should not even be a question.
If there's a retail box, there should be a programming manual as detailed
and complete as any as you would be able to get for a microprocessor.
A Pirate and a Puritan look the same on a balance sheet.
I though it was only a few days ago that /. reported that gallium is in short supply. Now we're blowing our precious reserves on frivolous video decoding.
Have some respect for Mother Earth...
Nullius in verba
Er, Via's nano-ITX offerings with a C3 processor, CN400, and VT1625 has been capable of this for at least two years now. The OpenChrome project provides for the accelleration: hardware MPEG2 decoding with XvMC. glxgears does about 500 fps on an 800 Mhz fanless cpu, closer to 700 on a 1.0 GHz CPU.
Been running this for a couple of years now in a Silverstone LC08 case.
In Liberty, Rene
Modern CPU's are more than fast enough to do 1080p h264 decoding. 2 years ago hardware decode would of helped, now it's a moot point.
I want to see hardware acceleration of encoding from my graphics board. Encoding multi-pass h264 using ffmpeg with the quality options just freaking takes forever!
For the record, mplayer on my EeePC 900 has no problem decoding H264 at standard def PAL rates (720x576 at 25fps), which is a good match for the 600 line display that the machine actually has ...
AMD/ATI has supposedly released enough docs to implement XvMC. When can we expect to see working code?
For playback of a 1080 DivX file, I only needed 512 megs of RAM, windows XP, and a 2.0 GHz single core Athlon64. That was well more than three years ago. Actually my old 1.8GHz P4 handles it, with just a tiny bit of stuttering when seeking in VLC.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
When nVidia advertises their GPUs, they call the hardware as "GPUs" and not "GPUs that work only with Windows, Linux, FreeBSD and solaris". When it is advertised in such way, the GPU has to work as a GPU with all OSs on earth, and that's possible if and only if complete programming documentation is provided. So, nVidia should either 1. Provide all programming documentation, or 2. Mention explicitly in the advertisement that their hardware is not for people who want complete freedom of choice of OS.
The largest prime factor of my UID is 263267.
The h264 and ogg files play with lots of interruptions in the video (but not the audio). The avi plays smoothly with some tearing.
This cpu is currently OCed to 2363MHz and the avi still shows some tearing. vlc seems to perform slightly better than totem-gstreamer using the latest blob from nvidia.
db
I am literally 3000 tokens away from the chaotic crossbow --Stephen
Part of the problem with hardware accelerated video decoding on Linux is that because Windows uses the accelerated video decoding to play back DRM protected media, the hardware companies cannot reveal how the video decoding part works (since it would presumably allow someone to grab the unencrypted-but-compressed video for various DRM protected video files by writing a windows driver or something)
However, the hardware could have been designed to merely decrypt, decode, check HDCP, and play, all in one. That is, one merely sends the A/V transport/container stream, in its encrypted form if not originally in the clear, to the video card (once it is set to operate in this mode). The video card will decrypt (if it has the appropriately licensed built-in key to enable this) the encrypted bits of the stream, do the (now clear) codec decoding (by whatever codec is involved), check to make sure the connection is to a proper HDCP device (which turns on re-encryption of the uncompressed HDMI stream, which the display device decrypts, so people can't tap into that), and then send the video over to the display. If it is encrypted and if a copy protection flag is set, it would disable any video or audio read-back capability (so the driver can't get a copy of what was decrypted either before or after decoding). While those of us that hate DRM (myself included) would despise the fact that this lets DRM work better, at least it CAN work in BSD and Linux because all the CPU software has to do is just replicate the stream up to the video card as-is (no decrypting, no decoding, etc). It keeps all the naughty DRM in the hardware (and also the patent licensing on the DRM and codecs). The BSD and Linux system can be entirely home-compiled from source with hacks and still let this work.
Actually, it might have been even better if the transport decrypt/decode was done in the monitor, or at least the decode part of this, which would have kept the bit rate over the HDMI manageable, even when we migrate to the Super Ultra Cinema format running at 5120x2160p120 (64:27 aspect ratio, which is the same 4x/3x ratio over 16:9 as 16:9 is over 4:3, and is almost exactly what cinema wide movies do now) in a couple decades. Even dual-link DVI couldn't handle this in uncompressed form. So they would need a whole new display interconnect or just need to retrofit compression into the existing one.
now we need to go OSS in diesel cars
Standards are a totally different issue. Today, the GPUs are not even documented, let alone standardization of the programming.
An open standard allowed hardware vendors to hide their custom techniques behind a standard interface (memory mapped register sets/texture framebuffers.
Third party board developers do get access to the specifications. I know a few companies who have built embedded systems using these chips.
Exactly!! But isn't that punishable? Isn't that anti-competitive to dictate people's choice of OS even when the GPU's behaviour has nothing to do with which OS it is running on??
Absolutely. That's what I dislike about Microsoft - they sit between the hardware vendors, and the application developers, and insist on particular API's being used, which will either change rapidly, or be built on top of legacy 8086 programming standards.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
nice. now I'm gonna find where you live, rape your whole family, an' slow roast 'em. Stupid git!
I know full well that tobacco is bad for you, so I smoke weed with crack