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

SDK Paperwork Submitted.. nothing for weeks?

J

JonathanF

Well-known member
Joined
Nov 29, 2008
Messages
286
Reaction score
0
Points
0
Location
Working in LA, NY, London or Vancouver
Website
www.veritefeatures.com
Not REALLY a complaint, but there didn't seem to be any other place to put this...

We submitted our paperwork for the SDK from the field weeks ago and our PA watched the paperwork go through the fax and I have the printout from successful transmission in the folder with the signed copy. I'm wondering what's become of it? It's been way more then a month now.

Rumors abound about some new stuff coming and we would have LOVED to have seen v1 of the SDK so we could comment as we're PARTICULARLY interested in decoding the r3d files on the GPU so we can get improved laptop performance in the field as we usually travel with a big LCD for checking the plates and with the new nVidia graphics on the MacBook Pro's it seems a no brainer.

So, two questions.

Did our SDK paperwork get lost in the shuffle?

Will you guys be adding anything that would allow those seeded developers the ability to offload r3d decoding to the gpu? Seems like the way forward.

J
 
The SDK was for a long time a problem. Now I (and many others :-) )would like RED opens the SDK to the industry leaders to allow also GPU debayer. Realtime 4k fullres debayer would be a reality. But this won't happen any time soon... Hope I'm wrong..

If you would develop a GPU taking care of the debayer I definitly would be interested :-)

Greatings from Switzerland.

Patrick
 
I know a bunch of people who would love this as well. I just don't want to go buying windows based tools to get decent performance. In fact, I'd like to see Lustre support GPU debayer on linux.

But we have a lot of proprietary tools we want to have support real time R3D playback and it's going to take the GPU to get it there. I want to do rough graded dailies (or weeklies or whatever) without having to do ANY conversion on our Linux playback systems in the theatre.. They are now using 10 bit output and when we upgrade the projector it's going to be tits.. would be really good to see R3D come right off the SAN and into the projector. Thing is.. the machine that's driving it is running linux... so the SDK is our only hope without putting some daft wintel thing in there.

With dual 4Gbit fiber to the SAN it should be a reality for sure.. we just need the SDK (and enough info to do the development for the GPU) to make it so.
 
luki,

We don't need 8Gb or even half the pipe we have running in there, that's just the point, our SAN bandwidth to the projector connected machine has dual 4Gb to facilitate DPX playback. I could do R3D over ethernet. I guess I wasn't clear enough.

With R3D you just need to get the compressed data decoded, and watching the CPU's on anything that's doing that now it's pretty clear it's decompressing the R3D that's the bottleneck, not IO. In the old SGI days when doing sequence playback we used to use DirectIO over HIPPI and we never compressed the frames because decompressing the frames was the bottleneck in getting the image to graphics not IO. You could watch the cpus in grosview (remember that Deanan) and with compressed tiffs (LZW or otherwise) you'd peg them to the moon, and then with uncompressed, assuming you had the bandwidth, the playback was smooth as cream. It was never about processor speed, you just needed enough pipe and disk spindles. But alas, the world has changed.

While we're kinda in that situation now, modern graphics hardware steps in to provide a solution for highly compressed datastreams. Instead of passing the work off the to the CPU you just decode it on the GPU.

We already have a player that supports ITX luts in hardware, so stitching R3D decoding support into that (with the ability to read and apply the RSX look files) is an obvious solution for our needs.

Our tools are _all_ written for linux and all the tools we have in house for managing color, calibration, machine configuration, etc. are all based around a facility toolset that's on linux with only peripheral support for macs. We'd rather just get R3D (our new favorite source format) working within the context of our existing pipeline and not have to go looking for solutions on other platforms.

We have our own development staff and we may as well take advantage of that.

Now I did not start this thread to get into a discussion about our SAN. I was looking for an answer from Red on whether our SKD paperwork had been lost, but I hope that makes the specifics of our situation a little clearer.

:J
 
Patrick,

As the only issue here is a file format the SDK is, in a very basic sense, platform independent.

I don't think there's anything being done on either the Mac or Windows that would preclude doing the same on Linux. Only question is if some vendors are going to get better access to certain things than others. I would certainly hope that's not the case.

:J
 
You must log in or register to reply here.
Back
Top