Announcement

Collapse
No announcement yet.

OpenCL 1.1 Specification Released

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by xeros View Post
    Yes, there is. CPU could be relieved by the GPU and in the time when most people do multitasking on their PCs the video decoding is not the only task to do for CPU and multiple CPU cores does not help in any case.
    I agree the CPU is relieved of the load if the GPU is doing the decoding. But that is not the point. The GPU is just another processor. And if nearly all CPU:s are strong enough to decode video and still have a lot of horsepower left for other tasks. Why put a lot of effort in moving the decoding into the GPU? I could see the gain if it was a trivial effort and for small devices. But not for modern desktops and laptops..

    May be its just cool to do stuff on the GPU.

    Comment


    • #22
      Originally posted by BigFatGangsta View Post
      I agree the CPU is relieved of the load if the GPU is doing the decoding. But that is not the point. The GPU is just another processor. And if nearly all CPU:s are strong enough to decode video and still have a lot of horsepower left for other tasks. Why put a lot of effort in moving the decoding into the GPU? I could see the gain if it was a trivial effort and for small devices. But not for modern desktops and laptops..

      May be its just cool to do stuff on the GPU.
      The architecture of GPUs often lend themselves to various tasks (such as video decoding) with far less power than a CPU. This is quite important in laptops, HTPCs (less fan noise), mobile devices, etc.

      Comment


      • #23
        Originally posted by mirv View Post
        The architecture of GPUs often lend themselves to various tasks (such as video decoding) with far less power than a CPU. This is quite important in laptops, HTPCs (less fan noise), mobile devices, etc.
        Ok, so it does consume less power when doing video decoding on GPU. Now Im happy and see why its worth the trouble. Thanks!

        Comment


        • #24
          Originally posted by cb88 View Post
          think that is only partly true... since if for instance openCL requires features in the hardware driver that no other state tracker has needed yet that would still have to be implemented in the driver so drivers still have to be worked on independantly to some degree though probably not nearly as much as before.... thats just how it seems to me.
          Yeah OK, but that wasn't my point. My point was that once all the work on the functionality of (the) OpenCL (state tracker) is done, that work doesn't have to be done all over again for each and every driver.

          I read about it before on the Phoronix forums. For example; nasty race conditions =x

          Comment


          • #25
            Originally posted by bridgman View Post
            I haven't actually seen any shader-assisted H.264 decode implementations in public yet, have you ?

            It's very common to use shaders for render aka presentation (scaling, colour space conversion, post processing etc...) but I haven't seen anything that does MC, deblock and loop filtering on shaders and everything further upstream on CPU.
            I was looking around yesterday afternoon for stuff like this, and found this thread on the XBMC forums about a GSoC project which a few other guys are picking up:

            http://forum.xbmc.org/showthread.php?t=33802

            It's not done yet, and it's using an older version of the ffmpeg source, but they do have the beginnings of a OpenGL+GLSL H.264 implementation. I haven't read the whole thing yet, but on the last page (10 as of yesterday, I think), there's a link to a github.com repository which has compiling code, although I think it currently freezes when playing videos.

            Would this be something like what you were describing?

            Comment


            • #26
              Yep, that looks like the kind of thing I'm talking about. The problem seems to be that most of these decoders are implemented as summer projects and the work takes longer than a summer

              The basic ideas seem pretty straightforward :

              - bitstream decode, entropy decode and modified IDCT on CPU (the H.264 version of IDCT is cheap to execute)
              - intra-prediction on CPU, at least for I-frames

              ** move data to video memory on GPU ***

              - motion comp (aka inter-frame prediction) on GPU
              - blend with residuals on GPU
              - deblock filter on GPU
              - all decoded frames stored on GPU

              I don't remember if B and P frames also use intra prediction or just inter prediction (mo comp) - if they do then that's probably going to be the nastiest part of the implementation.
              Test signature

              Comment


              • #27
                D'oh !!

                Good point, I'll check into that. Thanks !
                Test signature

                Comment


                • #28
                  Yeah, like that...

                  ... although I have more hair.
                  Test signature

                  Comment


                  • #29
                    s/gogogogogo/nononono/

                    There was a discussion going on about whether hardware-based decoding (eg UVD) produced higher quality than CPU-based decoding. My position was that the quality would generally be the same, and that it was processing further downstream (but before Xv/GL) that made the difference.

                    Put differently, I was saying that the apparent quality difference between UVD decode and CPU decode was that the proprietary drivers, which typically had the serious post-processing, also used hardware decode since it was available to the developers.

                    The post processing is considered "secret sauce" and it's highly unlikely we would open up that code. On the other hand, implementing it just requires video knowledge not any more hardware knowledge than we have already released, so there's no reason something similar could not be implemented in the open drivers.
                    Test signature

                    Comment


                    • #30
                      Anyways, bottom line here is that running an r600 against a UVD-based GPU (say an rv670 to keep everything else reasonably close) on Windows *might* be an interesting way to see whether UVD actually contributes to video quality the way that some people are suggesting.
                      Test signature

                      Comment

                      Working...
                      X