Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums VEGAS Pro Beating a Dead Horse For Good Measure: OpenCL, CUDA, and GPUs in Sony Vegas

  • Sonic 67

    January 10, 2015 at 1:50 pm

    I just test a random file – render it with Sony encoder that supports OpenCL.
    During this rendering I used Windows Resource Monitor and GPUZ to monitor usage of various parts of my PC.

    1. HD7970 GPU utilization – maximum 24%, but it was variable (sometimes to zero). Average is maybe at 15%.
    With my previous nVidia GTX480 (modded as Quadro6000) card and MainConcept it was at 35-40%, but very constant during rendering.
    2. CPU – my Xeon 6 core with HT (12 logical) was used at 38%.
    3. Memory – from my 15GB DDR3, Vegas was using only 1.2GB (it can be selected to show in Resource Monitor)
    4. Disk utilization – below 0.5MB/s. My rendering HDD is a RAID5 from 3 HDD that can push 70-90 MB/s.

    I am puzzled of the bottleneck…

  • Kell Hymer

    January 11, 2015 at 12:45 am

    Sony once told me this is hard to diagnose and it is likely a bottleneck somewhere in the system. However, many of us have some wicked fast systems and simple Main Concept projects should not be too taxing. However, I used to have a GTX460 with my i7 3820 and I noticed that CPU only renders were faster than CPU + GPU renders! After some research, my best hypothesis was that my CPU was too fast….well, rather, the CPU could process the data faster by itself than the time it took it to process, determine what could be sent to the GPU, offload it from the cached memory, send it to the GPU cache and/or VRAM, the GPU process it, unload it from the GPU cacheand/or VRAM, send it back to the CPU memory cache, and then the CPU patch it into the appropriate place in the data stream. I think for some codecs, video that is not too compressed, or less complex projects, it is simply easier for the CPU to do it all. The GPU really helps when heavy processing is required on supported codecs. In such cases, the extra time required to transfer the data back and forth between the CPU and GPU is worth it because the CPU would require significantly longer to process it.

    I think it was on this thread that I mentioned OpenCL 2.0. I am very intruiged by OpenCL 2.0 because it allows for the CPU and GPU (or other acceleration hardware/cards) to share the same memory cache. So instead of transferring memory between RAM and caches, both can access the same cache. I do not know if the GPU would have to access the CPU cache or if both can use the GPU cache and RAM. Either way, both processors will be able to access the same data, process it, and spit it back out to the same data location simultaneously. At this time, only Quadros and Firepros support OpenCL 2.0. However, AMD just released a new driver supporting it. Sony confirmed that Vegas 12 does support OpenCL 2.0, but does not take advantage of the shared memory enhancement. OpenCL 2.0 is still very new and software developers are only experimenting with it. Additionally, the firmware for various hardware would almost certainly have to support this as well. As such, shared memory might not be around for some time in Sony Vegas and it will likely require much newer hardware yet to be released.

    Current System: Intel i7 4930K OC’d to 4.6 GHz| Asus P9X79 Deluxe | 32GB RAM | AMD R9-290X w/8GB RAM | OCZ Revo 480 GB PCI Express SSD | Windows 7 64 bit | Vegas Pro 12 (64)

  • Sonic 67

    January 11, 2015 at 1:53 am

    Haha Sony supports OpenCL 2.0 – translation it is “it will work because is backwards compatible”.

    About the transfers between GPU and CPU: I had modded a GTX480 into a Quadro 6000. That activated a hidden bi-directional DMA between system memory and card memory – as a gaming card it have it active only in one direction, from system to video memory. I think that helps with computing tasks slightly.

    However, even on pure CPU encoding, my CPU (6 cores, HT, with 12MB shared L3 cache on board) is utilized only at 50%. More strange, from my 12 virtual cores, two are “parked” constantly and another one toggles between “parked” and “in use”.

    I always thought that video encoding a highly parallel process and will scale perfectly. After all, you can process hundreds/thousands of segments at once, picked between I-frames (key frames).

  • Kell Hymer

    January 11, 2015 at 11:21 pm

    So how difficult was it to turn the GTX into a Quadro? I have seen a few things online but nothing that breaks it down to well.

    Current System: Intel i7 4930K OC’d to 4.6 GHz| Asus P9X79 Deluxe | 32GB RAM | AMD R9-290X w/8GB RAM | OCZ Revo 480 GB PCI Express SSD | Windows 7 64 bit | Vegas Pro 12 (64)

  • Sonic 67

    January 12, 2015 at 2:25 am

    Well, after a lot of reading, eventually I had it made. But GTX480 remain power supply hogs, needed a bigger power supply for it anyway.

    Also the GTX have only 1.5GB, not 6GB ECC like the real Quadro 6000, is not like memory will grow up magically 🙂

  • Dave Haynie

    January 19, 2015 at 5:37 am

    [mark thompson] “just adding my 2 cents. I’m not saying anything is wrong but I would shift the emphasis slightly.
    CUDA is an architecture. You program to it in C or CUDA C which is an extension to C/libraries for C. That enables you to program the CUDA based chips from NVIDEA. “

    CUDA is actually more like a language than anything else. Yes, you program it via a C API. That creates a functional graph, which will be compiled when loaded on any given nVidia GPU. You are creating a high level program when you write CUDA code. Yes, it is designed for nVidia GPUs… but their architecture has changed quite a bit over the years, while CUDA programs still run.

    [mark thompson] “OpenCL is a standard that implementers can use provide a common programming interface across multiple gpu architectures.
    In theory OpenCL should be a little less efficient than programming the chip’s native interface. There is no fundamental reason that you couldn’t provide an OpenCL interface on top of CUDA.”

    OpenCL works much the same way, only it’s completely architecture independent. Again, there’s a run-time compiler in your OpenCL subsystem and graphics driver that targets any OpenCL program to the device of choice. OpenCL runs on GPUs, naturally. You can also run it on a CPU (AMD offers an OpenCL driver for AMD CPUs). And non-GPU compute engines — Intel’s Phi board runs OpenCL. Xilinx and Altera have OpenCL compilers for their FPGAs.

    Both CUDA and OpenCL may be somewhat less efficient than programming “to the metal” on a GPU (keep in mind, CUDA isn’t directly programming a GPU either). Much like programming in C vs. assembler. On the other hand, modern CPUs are actually often more efficient when programmed in C or other HLLs, simply because a good compiler knows everything about the CPU architecture in use. It’s difficult to keep all of the various complexities of a modern CPU in one’s mind (virtual register allocation, performance of every instruction, prefetch efficiences for different instruction ordering, the various parallel integer, floating point, and special units in each CPU core that run concurrently, pipeline efficiencies and stalls, etc). CPUs are simpler processors, but more complex as a system. You can get very “low level” with CUDA, as there’s basically an assembly language mechanism available — and in fact, some developers have found that necessary to get the best performance out of Kepler processors.

    As far as CUDA vs. OpenCL, your mileage may vary. CUDA may in general be a little more tightly coupled to the hardware, but it’s also largely synchronous. OpenCL is largely asynchronous, which allows it to run faster on some algorithms. And while CUDA may outperform OpenCL on some things on nVidia, it’s really difficult to get an honest comparison. AMD has long had better OpenCL implementations, and nVidia intentionally cripples some OpenCL and CUDA operations on standard and Workstation cards, since their “Compute Engine” cards also use basically the same processors. So you can find some benchmarks in which the AMD is totally clobbering the nVidia — this has been the case with Bitcoin mining, for example (well, at least back when it made economic sense to mine Bitcoins on GPUs — and curiously, it was really hard to get a top AMD GPU card for a short time as a result).

    -Dave

  • Rob James

    March 29, 2015 at 3:31 am

    John, I know this is an old post, but my search results took me here. I am finally building a new system, and I would love your input on one of my components. Is the R9 290X still the way to go? As that’s the one I’ve ordered, but it’s not too late to change my mind. If you have any new suggestions I’m all ears?

    Rob,
    https://www.robjames.net

  • John Rofrano

    March 29, 2015 at 11:31 am

    [Rob James] ” Is the R9 290X still the way to go?”

    Yes, that seems to be the card that everyone is saying gives the best performance with Vegas Pro. I would buy one myself if they made a Mac version but they don’t make cards for my old 2010 Mac Pro anymore but from what others are saying, that’s still the card to get right now.

    ~jr

    http://www.johnrofrano.com
    http://www.vasst.com

Page 3 of 3

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy