Slashdot Mirror
Transcoding in 1/5 the Time with Help from the GPU
mikemuch writes "ExtremeTech's Jason Cross got a lead about a technology ATI is developing called Avivo Transcode that will use ATI graphics cards to cut down the time it takes to transcode video by a factor of five. It's part of the general-purpose computation on GPU movement. The Aviva Transcode software can only work with ATI's latest 1000-series GPUs, and the company is working on profiles that will allow, for example, transcoding DVDs for Sony's PSP."
Added power to the user, just as those wacky halloween shenanigans occur to cripple hardware such as this to only pipe a tune when it's paid
My educated guess is, No, there won't be Linux support..
ATI was the leader in MPEG2 acceleration, enabling iDCT+MC offload to their video processor almost 10 years ago. How'd that go in terms of Linux support, you ask? Well, we're still waiting for that to be enabled in Linux.
Nvidia and S3/VIA/Unichrome have drivers that support XvMC, but ATI is notably absent from the game they created. So, I won't hold my breath on Linux support for this very cool feature.
With tech stuff these days, but this is awesome. A very clever use of technology just sitting in your computer and a huge timesaver. Anyone that does any transcoding will have immediate justification for laying out bucks for a premium video card.
"Eve of Destruction", it's not just for old hippies anymore...
I have seen a combo FPGA/PPC chip for embedded applications. The issue I see with this is how long would it be useful? FPGAs are slower then ASICs. Something like the Cell or a GPU will probably be faster than an FPGA. There are a few companies looking at "reconfigurable" computers. So far I have heard about any products from them yet.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
In a few years, there will be no real benefit to the GPU. Not too many people write optimized assembly level graphics code anymore, but it can be quite fast. Recall that Quake ran on a Pentium 90MHz with software rendering. It's only getting better since then. A second core that most apps don't know how to take advantage of will make this all the more obvious.
On another note, as polygon counts skyrocket they approach single pixel size. When that happens, the hardware pixel shaders - that GPUs have so many of - become irrelevant as the majority of the work moves up to the vertex unit. Actually at that point it makes a lot of sense to move to raytracing (something I have fast code for) which is also going to be quite possible in a few more years on the main CPU(s). Ray Tracing is one application that really shows why the GPU is NOT general purpose. You need data structures and pointers mixed with fast math - preferably double precision. You need recursive algorithms. You'll end up wanting a MMU. By the time you're done, the GPU really would need to be general purpose. The problem doesn't map to a GPU at all, and multicore CPUs are nearing the point where full screen, real time ray tracing will be possible. GPUs will not stand a chance.
I don't play the sort of games that need a graphics card over $200 to look good. I never even considered looking at the high end. However, this video encoding improvement will certainly make me do a double take. I was proud of my little CPU overclock that improves my encoding rate by 20%. But the article talks about improvements of over 500%! That's worth a couple of extra bucks.
Of course, by the time the software to do this actually becomes full-featured and useful, the price of the 1800 ATIs will hopefully drop a bit. Still, I have a feeling this will be my next GPU.
Unless nVidia can produce something equally impressive, of course!
It looks like they're using their own codec to produce MPEG-2 and MPEG-4 material. How would you get an existing, x86-only aware application to utilize the GPU, which is not x86 instruction compatible? It's a good bet that codecs will be rewritten to utilize the GPU once code becomes available from ATI, nVidia, etc.
I'd actually be willing to spend more than $50 on a video card if more multimedia apps took advantage of the GPU's capabilities.
Well, I'm assuming that the hope is that support for encoding/decoding h264 will be put into hardware going forward (meaning it will find its way into low-end cards as well). I know encoding h264 is the longest, most processor intensive task I do with a computer these days, and a hardware solution that would drop any time off that task would be appreciated.
That while few people will notice the difference between 150fps and 200fps, those numbers are more or less there to help you determine the lifespan of the card itself. While, for current games, both cards will perform extremely well, a 50fps difference means that on future games, the Nvidia card will be able to last longer and run with more graphics options enabled without bottoming out on fps.
While a select few individuals still always buy the latest and the greatest, the majority of buyers look at video cards as long term investments mainly because of the rediculously inflated prices in the GPU market. All that said, I think you have to look at the card's feature set and make a decision based on that. While, gaming wise, the Nvidia GPU may be superior, the dramatically increased transcoding times definitely make the ATI card a potentially attractive purchase to people who work a lot with video. Given the amazing rise in popularity of the Video Ipod and the existing PSP market, the number of people with interests in transcoding video is definitely on the rise, and ATI was smart in tapping that market now.
You are who you are, let no one tell you different. But, never close your mind to a new point of view.
5X faster than what? Because an Athlon X2 4800+ can transcode pretty damn fast.
I would rather some reality-based claims, such as "real-time encoding of 3 VGA streams into XVid". Give me a real reason to include an X1800 into my entertainment box.
Aple does this now. "Core Image" is built into the OS and all "correctly written" applications that need to do graphic use Core Image. Core Image wil use the GPU if one is available. This is a very good idea but the hardest part of getting this to work on a non-Apple platform will be standarizing the API so that we can use any GPU. OK X11 did this fr displays on UNIX ad we have OpenGL for 3D graphic so we can hope something will happen an API for GPU based image transfomation. The biggest use for this wil not be just simple transcoding but editing and dispay programs for still and moving images Think "gimp" and "cinelerra".
1. On another note, as polygon counts skyrocket they approach single pixel size
This is not happening. Not anywhere (except maybe production rendering). It is far too time-consuming, expensive, and labor-intensive to produce huge numbers of high-polygon-count models for games. Vertex pipes are currently under-utilized in most games and applications now. Efforts are underway to allow procedural geometry creation on the GPU to better fill the vertex pipe without requiring huge content creation efforts. See this paper for details.
2. A second core that most apps don't know how to take advantage of will make this all the more obvious.
This undercuts the argument you make in the next paragraph. Also, it's not true. Both the PS3 and XBOX 360 have multiple CPU cores. It's true that current-gen engines aren't optimized for this technology, but next-gen engines will be.
3. multicore CPUs are nearing the point where full screen, real time ray tracing will be possible. GPUs will not stand a chance.
This might be true, but so what? Ray tracing offers few advantages over the current-gen programmable pipeline. I can only think of 2 things that a ray-tracer can do that the programmable pipeline can't: multilevel reflections and refraction. BRDFs, soft shadows, self-shadowing, etc. can all be handled in the GPU these days. Now, you can get great results by coupling a ray-tracer with a global illumination system like photon mapping, but that technique is nowhere near real-time. Typical acceleration schemes for ray-tracing and photon mapping will not work well in dynamic environments, but the GPU could care less whether a polygon was somewhere else on the previous frame.
Hate to break it to you, but the GPU is here to stay. Why? GPUs are specialized for processing 4-vectors, not single floats (or doubles) like the CPU + FPU. True, there are CPU extensions for this, such as SSE and 3DNOW, but typical CPUs have a single SSE processor, compared to a current-gen GPU with 8 vertex pipes and 24 pixel pipes. Finally, do you really want to burden your extra CPU with rendering when it could be handling physics or AI?
Most of that stuff can be done with OpenGL/DirectX or ray tracing. Grasses are sometimes done in OpenGL with instancing small clumps. In RT you'd use proceedural geometry or instancing.
For the snow, both renderes would probably do similar techniques.
Sand dunes - either method needs an engine with deformable geometry - both can support that.
Water simulation is something I don't know much about. For the FFT methods of simulating waves it's possible that a GPU has an advantage. Once it start interacting with objects, I don't know how people handle that.
Your quesitons all point toward vast detailed worlds with lots of polygons. RT scales better with scene complexity. To get more traditional methods to work well, you get into fancy culling techniques (HZB comes to mind) and RT starts to look simpler - because it is.
When every machine has a few dozen cores in their CPU, every GPU will have a few hundred. That's just the way it will work. CPUs and GPUs are designed for different purposes. GPUs are fundamentally built for parallel processing - the more fragment processors and shaders, the better; they all work on independent tasks. CPUs work on tasks that are inherently serial. Hence, GPUs will always have a factor of 10-20 more "cores" or processing units than CPUs.