Welcome to our community

Be a part of something great, join today!

  • 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 :)

Geforce GTX Titan Black

Stefan Viklund

Well-known member
Joined
Aug 4, 2012
Messages
57
Reaction score
0
Points
6
Location
Sthlm - Swdn
Hi!
Has anyone used/tested this: Geforce GTX Titan Black to work with R3D's?
http://www.geforce.co.uk/hardware/desktop-gpus/geforce-gtx-titan-black
Just released I think!

I'm patiently waiting to build a hardcore Hackintosh and for motherboards who support a decent amount of RAM, dual 6 or 12 core processors AND that's equipped with Thunderbolt ports.
A market that has been as dead as death, but I hear rumors now that nice things are on the way… Thunderbolt is such a disgusting teaser!

And I'm curious what Titan Black can provide to the machine I'm planning to build, as it seems like a little monster. I think two would be awesome!
Is a Rocket card still necessary? I'm shooting/editing 5K Epic now, but what about 6K Dragon?

Any thoughts on this?

Best regards / Stefan
 
would be interesting to see some real world scenarios...

With Resolve 10 and 2x Titan in a HP Z820 we didn't got the shader utilisation higher than 50%... seems that the system is suffering from memory IO bottelecks and needs further optimisation...

Nvidia itself says the Titans could perform 10 times better in some scenarios if they wheren't IO limited between main memory and video card memory...

and as long as RED wavelet decompression is completely software (Resolve 10 on HP Z820 dual Xenon with 2x Titan clip playback 1/2 5K with some color nodes results in 100% CPU utilisation but only 10% on each Titan...) it doesn't help to add another high performace GPU to the system...

--> it sems to be really hard to do high performave wavelet decompression on GPU but we use Fraunhofer easyDCP Player+ and it is playing back 4K digital cinema packages with no CPU load - so it seems to be possible...
 
Last edited:
would be interesting to see some real world scenarios...

With Resolve 10 and 2x Titan in a HP Z820 we didn't got the shader utilisation higher than 50%... seems that the system is suffering from memory IO bottelecks and needs further optimisation...

Nvidia itself says the Titans could perform 10 times better in some scenarios if they wheren't IO limited between main memory and video card memory...

and as long as RED wavelet decompression is completely software (Resolve 10 on HP Z820 dual Xenon with 2x Titan clip playback 1/2 5K with some color nodes results in 100% CPU utilisation but only 10% on each Titan...) it doesn't help to add another high performace GPU to the system...

--> it sems to be really hard to do high performave wavelet decompression on GPU but we use Frunhofer easyDCP Player+ and it is playing back 4K digital cinema packages with no CPU load - so it seems to be possible...

Which xeon cpu? I get realtime 5k playback with 128gb RAM - 2x 2960v2 - 1x GTX590 when R3Ds are stored on a ramdisk (by SoftPerfect, free program) at all compression ratios in RCX
 
Last edited:
dual quad core Xeons 2.8GHz - have to take a look for the exact model - machine is in the other office - I assume the CPU is just too slow for the wavelet decompression and so the GPU doesn't have anything to do - esp. as Resolve 10 currently doesn't use the new GPU debayer feature from RED...

so at the end of the day all the computing intensive stuff still relies on the CPU... (don't think that pure debayer will saturate a Titan as long as the wavelet decompression is done by the CPU's - or am I wrong? :-)

I would assume it's not needed to copy R3D's to a ram disc - I can easily load them from my NAS and still get fluid playback or fast rendering... ram disc would be right for DPX 4K ;-)
 
I can't fathom why RCX would need multiple Titans to do the ultra simple debayer that Red uses .
Cineform does real time debayer on CPU when they play back Cineform RAW .

Has anyone tested the Maxwell stuff out to see how well it plays with RCX, BTW ?
 
I can't fathom why RCX would need multiple Titans to do the ultra simple debayer that Red uses .
Cineform does real time debayer on CPU when they play back Cineform RAW .

It's not the debayer process, it's the decompression that is taking all the horsepower. The layered and inherently encrypted wavelet structure that RED is using takes monster CPU horsepower to decode. The two advantages are the encryption and the ability to be mathematically lossless at the lowest selection of compression ratios. Something the other guys can't do. We all know what the disadvantage is -- speed. Some people consider the encryption and inability for third parties to create their own processing and debayer operations to also be a disadvantage, but for now I don't see it that way. With RED holding all the cards there, we can expect consistent results across an entire workflow, regardless of which software tools are brought in to do the R3D processing.

In short, wavelet decompression has long been something that GPUs did not do well at. Only recently have GPUs matured to a level where they can handle such a thing. It takes two decently powered GPUs or a single GPU on the level of a Titan to decode 5K+ in real-time. Or it takes a fair number of CPU cores to do the same. REDCINE-X isn't well multithreaded at all, it has been built to utilize the Rocket or other peripheral acceleration, now GPUs, to do the decoding. Somewhat of a shame… Just think how awesome RC-X could be if it not only had its current GPU/ Rocket abilities and also had the ability to scale to 16, 24, etc.. threads as well.

Premiere and Resolve are now getting Rocket-X and GPU abilities as RED is starting to roll out the new SDK components, these softwares scale well across multiple threads/CPUs already. They should do well here. One thing that does pose a bit of a problem is the GPU acceleration and incorporating that into software pipelines that already make heavy use of GPUs for other purposes -- such as in Resolve. So it's not going to be a change that just happens overnight by dropping in the new RED SDK.
 
Due to some recent unfortunate non-RED experience, I cannot but just HAIL the thing that RED has taken control/responsibility for the debayer...
 
Jeff,
The GPU versions of RCX still use the Kakadu Jpeg 2000 decoder which is CPU based. OpenCL is doing a very simple debayer.

Gunleik,
You like the color aliasing on OLPFed Dragon ? That is the simple debayer at work. Hail ?

It's not the debayer process, it's the decompression that is taking all the horsepower. The layered and inherently encrypted wavelet structure that RED is using takes monster CPU horsepower to decode. The two advantages are the encryption and the ability to be mathematically lossless at the lowest selection of compression ratios. Something the other guys can't do. We all know what the disadvantage is -- speed. Some people consider the encryption and inability for third parties to create their own processing and debayer operations to also be a disadvantage, but for now I don't see it that way. With RED holding all the cards there, we can expect consistent results across an entire workflow, regardless of which software tools are brought in to do the R3D processing.

In short, wavelet decompression has long been something that GPUs did not do well at. Only recently have GPUs matured to a level where they can handle such a thing. It takes two decently powered GPUs or a single GPU on the level of a Titan to decode 5K+ in real-time. Or it takes a fair number of CPU cores to do the same. REDCINE-X isn't well multithreaded at all, it has been built to utilize the Rocket or other peripheral acceleration, now GPUs, to do the decoding. Somewhat of a shame… Just think how awesome RC-X could be if it not only had its current GPU/ Rocket abilities and also had the ability to scale to 16, 24, etc.. threads as well.

Premiere and Resolve are now getting Rocket-X and GPU abilities as RED is starting to roll out the new SDK components, these softwares scale well across multiple threads/CPUs already. They should do well here. One thing that does pose a bit of a problem is the GPU acceleration and incorporating that into software pipelines that already make heavy use of GPUs for other purposes -- such as in Resolve. So it's not going to be a change that just happens overnight by dropping in the new RED SDK.
 
Jpeg 2000 has allot of processing to it since they did not optimize the code for just acquisition or delivery. This translates into significant processing time especially at the resolutions Red is using.
 
Back
Top