Skip navigation
gagrinds
Currently Being Moderated

Why is Src and Dst memory not pinned?

Jan 9, 2014 11:34 AM

Tags: #gpu #cs6 #premiere_pro_sdk #cc7 #pinned_memory

I just completed my first video filter that is CUDA accelerated using the Premiere Pro SDK for CS6 and CC7.  If suitable CUDA hardware is available, it use it, but if not then it uses a multithreaded software implementation.  Both work extremely well.  However, the CUDA implementation could be a lot faster if the source and destination memory buffers were "pinned" memory.  Since they are not, I must copy the source and destination memory to a pinned buffer, and then asynchronously copy that to CUDA device memory and back.  The overhead to copy from the source/destination memory to pinned memory is significant.  Without the copy to pinned memory the CUDA on my laptop is fast enought to process 130 fps for a 1920 by 1080 HD video.  However with the pinned memory I only get about 45 fps.

 

If I do the exact same filter in DirectShow, the source and destination buffer pools are always pinned and the filter runs much faster than it does on Premiere Pro.  I noticed that the new GPU filter example uses and AE interface, but it does allow access to pinned memory.  However, I have not mastered the AE interface, and I am reluctant to giving up 13 years of learning curve on the Premiere SDK.

 

Is there any good reason why the source and destination buffer pool in the Premiere Pro SDK is not pinned memory?

 

Gene

 
Replies
  • Currently Being Moderated
    Jan 9, 2014 11:40 AM   in reply to gagrinds

    Hey Gene, pinned memory only applies to host memory. The CUDA memory that you are given through the GPU suite is device resident so pinning does not apply and you can perform GPU computation directly from it without transfer.

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 9, 2014 12:24 PM   in reply to gagrinds

    I'm not really sure I understand the question - where is the source/destination memory you mention coming from?

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 9, 2014 12:35 PM   in reply to gagrinds

    If you are getting data through "theData" then you aren't using the new GPU SDK. Please see GPUVideoFilter in the SDK samples.

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 9, 2014 12:58 PM   in reply to gagrinds

    We generally suggest building filters using the AE SDK, but the new GPU SDK supports extending effects using either the Premiere SDK or AE SDK.

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 13, 2014 5:56 PM   in reply to gagrinds

    Hey Gene,

     

    The ProcAmp sample in the SDK demonstrates GPU-accelerated rendering in PPro.  You can think of it as two effects folded into one: A CPU rendering path, and a GPU rendering path.  The CPU rendering path and parameter handling is implemented using the AE API, whereas the GPU rendering path uses the new GPU extensions.

     

    As Steve points out, the GPU extensions can be fitted to an AE effect, or a PPro-style effect.  So if you want to retrofit all your PPro-style effects to add GPU rendering, that is supported.  You'll want to look at SDK_ProcAmp_GPU.cpp to see how the GPU rendering is implemented.

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 14, 2014 11:18 AM   in reply to gagrinds

    The new interface is rather minimal, and is just an additional entry point for GPU rendering.  What ever API you choose to build on top of (either the AE effect API, or the PPro filter API) will still be used for things like parameter definitions and UI.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points