Announcement

Collapse
No announcement yet.

RV600, OpenCL, ffmpeg and blender

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

  • #11
    Not sure I agree there. If Gallium were present it would do filtering just fine; you would have to write your filters in TGSI rather than OpenCL but if you're running natively over Gallium then you're already using TGSI.

    A bigger issue is that non-Linux platforms will typically already have a fair amount of video filtering and processing happening in the playback stack (eg DXVA). That gets into difficult tradeoffs; Gallium3D is potentially portable across OSes but OpenCL *will* be ported across OSes so you're likely to be trading off better portability (OpenCL) against better integration and efficiency (Gallium3D or something else OS-specific).

    I'm glad I don't have to choose
    Test signature

    Comment


    • #12
      Originally posted by bridgman View Post
      Not sure I agree there. If Gallium were present it would do filtering just fine; you would have to write your filters in TGSI rather than OpenCL but if you're running natively over Gallium then you're already using TGSI.

      A bigger issue is that non-Linux platforms will typically already have a fair amount of video filtering and processing happening in the playback stack (eg DXVA). That gets into difficult tradeoffs; Gallium3D is potentially portable across OSes but OpenCL *will* be ported across OSes so you're likely to be trading off better portability (OpenCL) against better integration and efficiency (Gallium3D or something else OS-specific).

      I'm glad I don't have to choose
      Real time filtering and image enhancing, video stabilization , etc, for doing jobs such as improving flash video would be heard to do with TGSI. Using openCL would allow such processing to easily be done cross platform where such abilities are not even present in DXVA etc. You could also make the code pull double duty instead of coding one method for encoding and an another for decoding.

      Comment


      • #13
        We are getting further and further from the original question here. The OP asked about the kinds of things ffmpeg did today. If you're talking about the kind of generic processing which is not likely to already be implemented in the OS native video stack (and most of your examples fall into that category) then I agree OpenCL is a better choice.

        If you're trying to get me to argue that there is no place for OpenCL, you're talking to the wrong guy
        Test signature

        Comment


        • #14
          Originally posted by bridgman View Post
          We are getting further and further from the original question here. The OP asked about the kinds of things ffmpeg did today. If you're talking about the kind of generic processing which is not likely to already be implemented in the OS native video stack (and most of your examples fall into that category) then I agree OpenCL is a better choice.

          If you're trying to get me to argue that there is no place for OpenCL, you're talking to the wrong guy
          Oh, I'm not arguing that your saying that there is no place for openCL. The original post did ask about encoding though. I would just hate to see projects such as ffmpeg paint themselves into a corner by not making it as flexible as it could be. openCL can make a huge improvement to the playback experience if directed in the right direction. There is nothing stopping it for example to limit itself to just the video part of playback as well. openCL could be used for realtime audio DSP processing as well (such as realtime upmixing or stream processing the signal into a AC-3 or DTS while doing psychoacoustic enhancments using impulse files for example).

          Comment


          • #15
            What I want is GPU accelerated Fffmpeg (extra capitalised F intentional) so it looks like what I'm waiting for first is a working FOSS implementation of opencl.

            The logical birth place of such code would be from within mesa but I would've presumed that if they had announced such a project then someone here would know about it as I'm presuming at least one mesa dev will frequent these forums.

            Surely Apple have a working implementation of opencl (for OSX) already? Is that under NDA or a closed license?

            EDIT

            Formats I'd be looking to encode would inc DV, H.264, Dirac(Schroedinger), MPEG 2 and 4
            Last edited by danboid; 02 January 2009, 07:43 PM.

            Comment


            • #16
              Originally posted by danboid View Post
              What I want is GPU accelerated Fffmpeg (extra capitalised F intentional) so it looks like what I'm waiting for first is a working FOSS implementation of opencl.

              The logical birth place of such code would be from within mesa but I would've presumed that if they had announced such a project then someone here would know about it as I'm presuming at least one mesa dev will frequent these forums.

              Surely Apple have a working implementation of opencl (for OSX) already? Is that under NDA or a closed license?

              EDIT

              Formats I'd be looking to encode would inc DV, H.264, Dirac(Schroedinger), MPEG 2 and 4
              It's already open, http://www.khronos.org/registry/cl/. The rest is up to the drivers and applications coders.
              Last edited by deanjo; 02 January 2009, 07:59 PM.

              Comment


              • #17
                danboid might have been asking about the actual driver implementation rather than the standard; I imagine the initial implementations will all be proprietary ?
                Test signature

                Comment


                • #18
                  Originally posted by bridgman View Post
                  danboid might have been asking about the actual driver implementation rather than the standard; I imagine the initial implementations will all be proprietary ?
                  Given that development and testing has been done on a closed driver I would imagine that to be the case as well.

                  Comment


                  • #19
                    '...rest is up to the drivers...'

                    drivers?

                    Bridgman didn't you say that you've already started on opencl support but this will just be in the non-open fglrx driver and hence only available to fglrx users? So are you saying that we could potentially end up with 3 separate ATI opencl drivers for the 3 different ATI X drivers?

                    I'm a bit confused about opencl and dependencies I think. bridgman said it will need at least DRI and OGL(Mesa) seeing as its closely linked to OGL- far as I'm aware mesa-glx/dri etc libglu etc depend on a X server so we'll have to install X to use opencl even if its just a command line app?

                    Are we waiting for an opencl announcement of some sort from either one of the open source ATI drivers and/or mesa?

                    Comment


                    • #20
                      Originally posted by danboid View Post
                      '...rest is up to the drivers...'

                      drivers?
                      Yes, the drivers ultimately determine how to handle the openCL API.

                      Comment

                      Working...
                      X