Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Nvidia Tesla K20X is offical

too bad the tesla card won't do anything to speed up R3D debayering :-(
 
Hummmm.... We need compilers that can work on GPGPU to massively speed up compilation times (lol).
 
Maz Mawlawi said:
too bad the tesla card won't do anything to speed up R3D debayering :-(
Click to expand...

This is where Intel's Xeon Phi is more promising as the cores use exactly the same x86 architecture as CPUs. Anything that runs on your CPU has the potential to run massively faster under Xeon Phi. I am guessing the main challenge is to get it to scale to 60 cores. All that said, I think it will be a few years before mainstream applications like Premiere or Resolve can truly maximise Xeon Phi's potential. For now it is designed for server / HPC applications running Linux.

Tesla K20X looks great. Here's hoping for Quadro and GeForce variants next year. I suspect a single one of these will be good enough to drive real-time 4K grading on Resolve.
 
This is a misconception... Its not the debayer that uses the processors with R3D's... its the wavelet compression... which is why the Rocket is a "must have" as it is the only card with access to Red's API for decoding the compression. (source the uber smart Jeff Kilgore)
 
Tim Whitcomb said:
This is a misconception... Its not the debayer that uses the processors with R3D's... its the wavelet compression... which is why the Rocket is a "must have" as it is the only card with access to Red's API for decoding the compression. (source the uber smart Jeff Kilgore)
Click to expand...

I think by "debayer" or "decode" people mean the entire process for getting R3D to run. If we were to be pedantic, sure, there are different sub-processes. The debayer uses the CPU as well as far as I know (this is the first I am hearing that it doesn't) but it is relatively light compared to decompression, which uses up most CPU cycles. The entire R3D decode process, including decompression, has the potential to be massively accelerated by Xeon Phi, far in excess of a Rocket.

Whether it happens is up to RED.
 
Seeing how we can buy two Xeon Phi cards for the price of one Rocket...

Anyway, I feel the Intel MIC (Xeon Phi) architecture is far more promising here. It can execute standard x86 instructions as well as OpenCL and it doesn't have the same precision limitations that the Kepler cards do. To me, the Xeon Phi seems to be the next logical step forward for R3D decoding, short of RED introducing a much lower-priced solution based on custom ASICs. And there's a good chance they may do just that. After all, it seems they may have their own hardware to utilize now with the near release of the REDRAY system. Either way, I don't see how integrating Xeon Phi support into upcoming SDK builds could be a bad thing. nVidia Kepler, even the K20X has inflated specs. Preliminary reports are that it's barely any faster for double-precision operations than a current Tesla C2075. So, I'm not too eager to run out and spend $2700 for what amounts to little to no gain at this point, not to mention software needing to be tweaked for the new architecture and all that.

If I were building a new workstation and needed a Tesla card for it, I would probably get the K20X as it will improve with time and it's the new product. It does have much better I/O abilities and faster onboard RAM than the prior Fermi-based C2075, even though it's greater number of cores don't (yet) account for much more processing.
 
Put an order in a couple weeks ago. ETA December.
 
R3D hardware acceleration is restricted to the Redrocket because that is Red's policy. It is possible to do wavelet decoding / encoding on a GPU, and has already been done with R3D in Speedgrade in the very early days of the camera, but Red disallowed it so it was pulled.

I totally get Red wanting to control the quality of their process (for instance Arriraw decoder is Arri SDK in Scratch and custom non-sdk in Resolve, Scratch is noticeably better) - but I believe it is time for Red to open up the SDK to alternative hardware accelerators like GPU and Xeon Phi. It's already unrealistic to put 2 Redrockets in most well outfitted grading workstations that already have too few PCI slots even with an expander chassis, and without that there's no realtime debayer of 5K+ redcode.

JT
 
Not that it really means anything necessarily, but the new Titan supercomputer (officially currently the fastest in the world) is using these GPUs. They went from using Fermi GPUs with a few CPUs in Jaguar, to pairing a K20 with *every* CPU and changed the computer's name to Titan.

http://www.anandtech.com/show/6421/...99k-amd-x86-cores-and-186k-nvidia-gpu-cores/2

I would assume that, on that scale, there is certainly practical reasons to do so, moreso than just "but it has the mostest CUDA cores".
 
John Tissavary said:
R3D hardware acceleration is restricted to the Redrocket because that is Red's policy. It is possible to do wavelet decoding / encoding on a GPU, and has already been done with R3D in Speedgrade in the very early days of the camera, but Red disallowed it so it was pulled.
Click to expand...

Actually the wavelet decode was still being done on the CPU by both Iridas and Cineform at the time when they reverse-engineered the R3D codec back then. The GPU was used for the debayer process, which is trivial work for a GPU, something it's actually meant for -- pixel transformations.

That said, R3D back then and R3D now are almost two entirely different things. There is a lot more processing required for the later builds of the coded and much more data to be wrangled on EPIC and Scarlet with 16bit container depth and 5K resolution possible. My current best workstations make short work of old R3D clips I bring out of storage. It's the newer 5K ones that put a strain on the system, and the Rocket. Actually, my latest Xeon boxes decode 5K at full resolution as well as a Rocket card does. So for doing typical transcode workflows where one Rocket would suffice and we can do it on a tower workstation, the need for a Rocket is somewhat moot. Throw the Rocket in there though and you get the best of both.

There's a huge misconception about wavelets and GPUs. Yes, it has been done, but it has not been very efficient in terms of multi-layered wavelet structures. Hopefully this is finally changing for the better. These latest compute cards in the form of the Intel MIC architecture and the K110 (Tesla K20, upcoming Quadro K6000, K7000) are far better suited to this sort of computational task. Hopefully we will see proper R3D wavelet decode support for these GPUs in the near future. It's at a point where it actually makes sense now. CUDA and OpenCL have also progressed to a point where consistent results can be had on complex operations like this across varying GPU platforms. That has been a problem in the past and required developers to profile and support different GPU families in different ways and the same results for render output and other operations couldn't be guaranteed between GPU families. That is finally changing for the better as well.

I'm betting on Xeon Phi here though. It seems to be the most logical and capable of this new round of compute cards. At least as far as wavelet decoding is concerned. For additional OpenGL acceleration and realtime visualization operations, the Tesla K20X probably has the edge.
 
You must log in or register to reply here.
Back
Top