SDK Paperwork Submitted.. nothing for weeks?

[JonathanF]

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

[Patrick Tresch]

I wish you all the best for your project.

Patrick

[JonathanF]

I wish you all the best for your project.
Patrick

I take it that's something you'd like to see to? I have a guy that's been doing GPU development on my staff who's been at it for 10 years. I'm hoping he can knock something out in not too much time.

:J

[Patrick Tresch]

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

[JonathanF]

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.

[Tim Whitcomb]

it's going to be tits...

wow, I havent heard that phrase since HS 1982... thought it had long passed into urban legend... far out.

[Lucas Wilson]

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.

Why would you need dual 4G? Redcode is under 50MB/s sustained read.

Lucas
-----
ASSIMILATE, inc.
LA, CA, USA

[JonathanF]

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 Tresch]

Did they release SDK for Linux yet?

Patrick

[JonathanF]

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

[Patrick Tresch]

Look at their webpage :

http://www.red.com/developer

Which Platforms
Intel Mac Windows x86 Linux (Not yet available)

I don't know much about SDK but think it could be the response...?

Patrick