Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 38

Thread: RV600, OpenCL, ffmpeg and blender

  1. #11
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,379

    Default

    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

  2. #12
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,581

    Default

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

  3. #13
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,379

    Default

    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

  4. #14
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,581

    Default

    Quote 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).

  5. #15
    Join Date
    Jan 2009
    Location
    England
    Posts
    101

    Default

    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; 01-02-2009 at 06:43 PM.

  6. #16
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,581

    Default

    Quote 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; 01-02-2009 at 06:59 PM.

  7. #17
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,379

    Default

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

  8. #18
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,581

    Default

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

  9. #19
    Join Date
    Jan 2009
    Location
    England
    Posts
    101

    Default

    '...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?

  10. #20
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,581

    Default

    Quote Originally Posted by danboid View Post
    '...rest is up to the drivers...'

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •