Slashdot Mirror

← Back to Stories (view on slashdot.org)

Transcoding in 1/5 the Time with Help from the GPU

Posted by CmdrTaco on from the cycles-are-cycles dept.

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."

22 of 221 comments (clear)

  1. This would be great for MythTV.. Linux support?? by tji · · Score: 4, Insightful


    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.

  2. Slashdotted! by Anonymous Coward · · Score: 4, Funny

    I wonder if http://www.gpgpu.org/ could offload some of the Slashdot effect to their GPU?

  3. What I want to see. by Anonymous Coward · · Score: 5, Interesting

    Maybe others have had this idea. Maybe it's too expensive or just not practical. Imagine using PCI cards with a handful of FPGAs on board to provide reconfigurable heavy number crunching abilities to specific applications. Processes designed to use them will use one or more FPGAs if they are available, else they'll fall back to using the main CPU in "software mode."

  4. Re:This would be great for MythTV.. Linux support? by ceoyoyo · · Score: 5, Interesting

    This should be written in Shader Language (or whatever it's called these days) which is portable between cards. There's no reason NOT to release this on any platform. Since it only runs on the latest ATI cards it probably uses some feature that nVidia will have in it's next batch of cards as well. If ATI doesn't release it for Linux and the Mac hopefully it won't be that difficult to duplicate their efforts. After all, shader programs are uploaded to the video driver as plain text.... ;)

  5. Re:I'm rarely impressed... by drinkypoo · · Score: 4, Interesting

    I'd like to see it but I wonder what the quality is going to be like as compared to the best current encoders. I mean you can already see a big difference between cinema craft and j. random mpeg2 encoder...

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  6. But is it worth it? by Anonymous Coward · · Score: 3, Interesting

    the X1800XT ties almost exactly with the 7800GTX @ stock of 430 core in most gaming benchmarks.

    with nVIDIA's 512mb implementation of the G70 core touted to be at 550mhz core, it should theoretically thrash the living daylights out of the X1800XT.

    http://theinquirer.net/?article=27400

    the decision is between aVIVO's encode and transcode abilities for h.264, or superior performance by nVIDIAs offering?

  7. Crippled? by bigberk · · Score: 4, Funny

    But will the outputs have to be certified by Hollywood or the media industry? You know, because the only reason for processing audio or video is to steal profits from Sony, BMG, Warner, ... and renegade hacker tactics like A/D conversion should be legislated back to the hell they came from

  8. GPU or CPU? by The+Bubble · · Score: 3, Interesting

    Video cards with GPU's used to be a "cheap" way to increase the graphic processing power of your computer by adding a chip who's sole purpose was to process graphics (and geometry, with the advent of 3d-acellerators).

    Now that GPU's are becomming more and more programmable, and more and more general~purpose, what, really, is the difference between a GPU and a standard CPU? What is the benefit to having a 3d~acellerator over having a dual~CPU system with one CPU dedicated to graphic processing?

    1. Re:GPU or CPU? by gr8_phk · · Score: 3, Insightful
      "what, really, is the difference between a GPU and a standard CPU? What is the benefit to having a 3d~acellerator over having a dual~CPU system with one CPU dedicated to graphic processing?"

      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.

    2. Re:GPU or CPU? by SlayerDave · · Score: 4, Insightful
      You're hallucinating, buddy. Let me count the ways.

      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?

    3. Re:GPU or CPU? by gr8_phk · · Score: 3, Insightful
      "Which approach is going to be most effective but economical for rendering fields of grasses or detailed jungles? How about a snowstorm with snow that gets denser and fog like into the distance? Sand dunes that give way and slide underfoot? Water that breaks around objects and coats them in a wet sheen?"

      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.

  9. Re:I'm rarely impressed... by Dr.+Spork · · Score: 3, Informative

    You don't get it. ATI is not releasing a new encoder. The test used standard codecs, which do the very same work when assisted by the GPU, only 5X faster.

  10. Re:GPU advantages over CPU? by tomstdenis · · Score: 4, Informative

    GPUs are massively parallel DSP engines. That makes them ideally suited for the task. They can do things like "let's multiply 8 different floats in parallel at once". Which is useful when doing transforms like the iDCT or DCT which are capable of taking advantge of the parallelism.

    But don't take that out of context. Ask a GPU to compile the linux kernel [which is possible] and an AMD64 will spank it something nasty. *GENERAL* purpose processors are slower at these very dedicated tasks but at the same time capable of doing quite a bit with reasonable performance.

    By the same token, a custom circuit can compute AES in 11 cycles [1 if pipelined] at 300Mhz which when you scale to 2.2Ghz [for your typical AMD64] amounts to ~80 cycles. AES on the AMD64 takes 260 cycles. But, ask that circuit to compute SHA-1 and it can't. Or ask it render a dialog box, etc...

    Tom

    --
    Someday, I'll have a real sig.
  11. Re:Already available.. by tomstdenis · · Score: 3, Interesting

    FPGAs aren't always slower than what you can do in silicon. AES [sorry I have a crypto background] takes 1 cycle per round in most designs. You can probably clock it around 30-40Mhz if your interface isn't too stupid. AES on a PPC probably takes the same time as a MIPs which is about 1000-1200 cycles.

    Your clock advantage is about 10x [say] that is typical 400Mhz PPC vs. 40Mhz FPGA ... so that 1000 cycles is 100 FPGA cycles. But an AES block takes 11 FPGA cycles [plus load/unload time] so say about 16 cycles. Discounting bus activity [which would affect your software AES anyways] you're still ahead by ~80 FPGA cycles [800 PPC cycles].

    Though the more common use for an FPGA aside from co-processing is just to make a flexible interface to hardware. E.g. want something to drive your USB, LCD and other periphs without paying to go to ASIC? Drop an FPGA in the thing. I assure you controlling a USB or LCD device is much more efficient in an FPGA than in software on a PPC.

    Tom

    --
    Someday, I'll have a real sig.
  12. Using their own codecs by no_such_user · · Score: 4, Insightful

    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.

  13. lessons of "array processors" from 1980s by peter303 · · Score: 3, Informative

    In the scientific computing world there have been several episodes where someone comes up with a attached processor an order of magnitude faster than a general purpose CPU and try to get the market to use it. Each generation improved the programming interface eventually using some subset of C (now Cg) combined with a preprogrammed routine library.

    All these companies died mainly because the commodity computer makers could pump out new generations about three times faster and eventually catch up. And the general purpose software was always easier to maintain than the special purpose software. Perhaps graphics card software will buck this trend because its a much larger market than specialty scientific computing. The NVIDAS and ATIs can ship new hardware generations as fast as the Intels and AMDs.

    1. Re:lessons of "array processors" from 1980s by TheRaven64 · · Score: 3, Interesting
      A lot of the improvements in CPU performance recently have come from vector units. On OS X, things like the AAC encoder make heavy use of AltiVec - to the degree that ripping CDs on my PowerBook is limited by the speed of the CD drive, not the CPU.

      A GPU is, effectively, a very wide vector unit (1024-bits is not uncommon). What happens when CPUs all include 2048-bit general purpose vector units? What happens when they include a couple on each core in a 128-core package? Sure, a dedicated GPU will still be faster - but it won't be enough faster that people will care. For comparison, take a look at Chromium. Chromium is a software OpenGL implementation that runs on clusters. Even with relatively small clusters, it can compete fairly well with modern GPUs - now imagine what will happen when every machine has a few dozen cores in their CPU.

      --
      I am TheRaven on Soylent News
  14. Apple's core image by acomj · · Score: 3, Informative

    some of Apple's apis (core video/core image/core audio) use the gpu when it detects a supported card, otherwise it just uses the cpu, seemlessly and without fuss. So this isn't new.

    http://www.apple.com/macosx/features/coreimage/

  15. Linux Support by Yerase · · Score: 3, Informative

    There's no reason there couldn't be Linux Support. At the IEEE Viz05 Conference there was a nice talk from the guys operating www.gpgpu.org about cross-platform support, and there's a couple of new languages coming out that act as wrappers for Cg/HLSL/OpenGL on both ATI & NVidia, & Windows & Linux... Check out Sh (http://libsh.sourceforge.net/ and Brook (http://brook.sourceforge.net./ Once their algorithm is discovered (Yipee for Reverse engineering), it won't be long.

  16. Re:This would be great for MythTV.. Linux support? by thatshortkid · · Score: 5, Interesting

    wow, for once there's a slashdot article i have insight on! (whether it's modded that way remains to be seen.... ;) )

    i would actually be shocked if there weren't linux support. the ability to do what they want only need to be in the drivers. i've been doing a gpgpu feasability study as an internship and did an mpi video compressor (based on ffmpeg) in school. using a gpu for compression/transcoding is a project i was thinking of starting once i finally had some free time since it seems built for it. something like 24 instances running at once at a ridiculous amount of flops (puts a lot of cpus to shame, actually). if you have a simd project with 4D or under vectors, this is the way to go.

    like i said, it really depends on the drivers. as long as they support some of the latest opengl extensions, you're good to go. languages like Cg and BrookGPU, as well as other shader languages, are cross-platform. they can also be used with directx, but fuck that. i prefer Cg, but ymmv. actually, the project might not be that hard, just needs enought people porting the algorithms to something like Cg.

    that said, don't expect this to be great unless your video card is pci-express. the agp bus is heavily asymmetric towards data going out to the gpu. as more people start getting the fatter, more symmetric pipes of pci-e, look for more gpgpu projects to take off.

    --
    The IRS is the one organization that you don't want to fuck with. Remember, these are the guys who took down Al Capone.
  17. Apple foes this now. by ChrisA90278 · · Score: 3, Insightful

    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".

  18. Re:There's a CPU in my keyboard too... by Saffaya · · Score: 5, Interesting

    Though I am sure you wrote that as a pure joke, this has already been done long ago. During the fierce competion on the demo scene between the ATARI ST and the Amiga, crews were exploiting every speck of power they could from their machine. The ATARI ST being a general purpose machine compared to the Amiga (which had very advanced sound and graphical custom processors), the programmers who wanted to pull off the same graphical effects went as far as using the processor managing the keyboard (a 68xx 8bit motorola chip) for added computational power.