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

Can we please please please have some NVIDIA/ADOBE/RED love?

O

Obin Olson

Well-known member
Joined
Dec 28, 2006
Messages
2,004
Reaction score
0
Points
0
Website
www.dv3productions.com
Guys, I love the gear. really. I truly from the bottom of my SOUL LOVE LOVE LOVE the gear.


But I NEED NEED NEED realtime debayer in Premiere. ON my laptop. It's power is just being wasted....everytime I open and edit 4k or 5k redcode. WASTED.

I have the GPU power.

The disks are fast enough.


please. it's been YEARS guys.
 
Not sure what you are asking for.... Except maybe enabling r3d to harness the power of current GPUs for accelerating the debayering process?...
 
Exactly. take the load off the poor cpu. Allow full debayer on the gpu.

Adobe says they can do it...waiting on Red to allow them access.
 
It certainly would be nice! GPUs have plenty of processing power these days!
 
I've seen many posts (not that I can find them now) from Graeme and Deanan stating that the GPU sucks for the redcode decode. Something about it being the wavelet+debayer and texture memory or something.

You'd think that there was a way by now, somehow. If they got it working on a TESLA, it would be nice, because those economies of scale could apply to Red users as well.

Where did you see the info from Adobe, or was it just a conversation?
 
this is a topic that has been brought up a lot, and more frequently lately. fact of the matter is, you want better r3d decode, you need a rocket in your pipeline. r3d is copyrighted, and encrypted. subtract adobe and nvidia from the equation.

nvidia just makes powerful gpu's, and open up drivers with companies that wanna maximize those gpu's for their own software.

adobe is one of those companies, and is known for their cuda support extensively.

but it's all about RED opening up their codec so third party vendors to decode/debayer through the gpu. so this should really just be more of a cry to RED than anything else. but it's their right to refuse to do this. processor and rocket debayers offer a certain level of quality control. if you look at other raw formats that do gpu debayer, every piece of software that does dailies can vary slightly to drastically depending on how they optimized the sdk. one system could be making the footage a little softer, another could be making it too sharp. one might not be retaining all the information it's supposed to.

and I can feel for RED wanting to protect their images. it's also a whole new line of support, a new video card comes out or new cuda drivers that break r3d decoding. it goes to the software companies to have to fix, the companies have to go to RED. but when you stick with a rocket or cpu, they can figure out these issues much faster because it's THEIR pipeline, and they have it in house all the time.

in a ideal world of course i would love to get rid of my red rocket, and pump out footage through a upcoming k5000 or something. but everybody needs to realize what a can of worms it is to open up gpu debayering.
 
Hehe... You actually do get real-time debayer! ;) The bottleneck is with the wavelet decompression and contrary to popular belief, current GPUs just suck at decoding wavelet structures. Hopefully newer GPUs coming down the pipe will bring more to the table here. The upcoming Kepler K20 based nVidia Quadro and Tesla cards, as well as Intel's MIC (formerly known as Knight's Corner), show the most promise in this regard. It's a bit too early to tell... And none of those are making their way to a laptop anytime soon.

Just pretend its 1996 and you're editing HD... Then you'll suddenly be ecstatic about the performance we're getting with 4K/5K footage. ;) In just a few more years, when CPU cores have doubled in power and there are 24 to 32 cores on a CPU die, RAM runs casually at 3.2GHz in 6-channel arrangements and all that, we'll be cutting away with 4K~6K footage as if it were 1080p ProRes. Sometimes we just have to be patient and wait for one technology to catch up to another.

Adobe says they can do the debayer operations on the CPU, not the decompression. Nobody is doing complex wavelet decodes at 4K+ resolution on a currently available GPU at real-time speeds. It's just not something that works that way. Opening up more access to the debayer process would greatly streamline Adobe's process -- current GPUs actually LOVE pixel operations like debayer algorithms. RED continues to maintain control here because they only want people doing it their way, with their algorithms. They could license their algorithms and all that, but they're still open to a sort of interpretation and it becomes a sharing of IP that RED may not want to open themselves to. I do think some of this will happen as GPUs continue to progress, we're just not quite there yet.

For now, decoding complex wavelet structures is actually better and faster via brute-force across multiple CPUs.
 
Jeff Kilgroe said:
...current GPUs just suck at decoding wavelet structures...
Click to expand...

They are obviously the experts, but from the outside, it looks as if progress is being made. A simple Google search returned gobs of stuff about wavelet decompression on gpu... like this one http://iwi.eldoc.ub.rug.nl/FILES/root/2009/ProcISPAvdLaan/2009ProcISPAvdLaan.pdf where they are getting a 5x speed improvement.

There is obviously something about the process that isn't obvious without expert knowledge, and I'm pretty darn sure that the folks at RED aren't lazy.

I can see the value in opening the codec to get outside ideas, but I see why they are protecting it, given the redRay factor.
 
Here's my question. Why do you need full res playback of r3d's on a laptop? Your screen cant even begin to take full advantage of the resolution. I think the fact that you can even run a native workflow (and get real time playback, albiet lower res) on something like a MBPr is incredible.
Do you need faster encode times out of Premiere for dailies? For final deliverables? Are you monitoring out on a 4K display?
I have noticed that creating Rocketless dailies out of Resolve Lite (regardless of debayer settings) takes half the time that the same debayer would out of Redcine. It seems that Resolve is utilizing the GPU to do so?
I havent done a test to compare rendering out a final product in Premiere vs Resolve, (IMHO you should be running all your native files through something anyways to leverage all that RAW data :) and resolve is FREE!!!)
but I would assume that resolve its faster as well.
Im not saying I dont want REAL TIME FULL RES EVERYTHING on a laptop. That would rock.
But right now its fast enough to get the job done pretty efficiently with a minimal amount of gear. And that also rocks!
 
Jeff Kilgroe said:
Hehe... You actually do get real-time debayer! ;) The bottleneck is with the wavelet decompression and contrary to popular belief, current GPUs just suck at decoding wavelet structures. Hopefully newer GPUs coming down the pipe will bring more to the table here. The upcoming Kepler K20 based nVidia Quadro and Tesla cards, as well as Intel's MIC (formerly known as Knight's Corner), show the most promise in this regard. It's a bit too early to tell... And none of those are making their way to a laptop anytime soon.

Just pretend its 1996 and you're editing HD... Then you'll suddenly be ecstatic about the performance we're getting with 4K/5K footage. ;) In just a few more years, when CPU cores have doubled in power and there are 24 to 32 cores on a CPU die, RAM runs casually at 3.2GHz in 6-channel arrangements and all that, we'll be cutting away with 4K~6K footage as if it were 1080p ProRes. Sometimes we just have to be patient and wait for one technology to catch up to another.

Adobe says they can do the debayer operations on the CPU, not the decompression. Nobody is doing complex wavelet decodes at 4K+ resolution on a currently available GPU at real-time speeds. It's just not something that works that way. Opening up more access to the debayer process would greatly streamline Adobe's process -- current GPUs actually LOVE pixel operations like debayer algorithms. RED continues to maintain control here because they only want people doing it their way, with their algorithms. They could license their algorithms and all that, but they're still open to a sort of interpretation and it becomes a sharing of IP that RED may not want to open themselves to. I do think some of this will happen as GPUs continue to progress, we're just not quite there yet.

For now, decoding complex wavelet structures is actually better and faster via brute-force across multiple CPUs.
Click to expand...
What's ARRI's format coded with? I posted a link a while back to a pdf from ARRI talking about their new GPU enabled API.

The folks at Eyeon told me the ARRI API was in beta when I asked them why Fusion couldn't use the GPU with R3D files.

Once the API is GPU enabled, all the software from all the companies that use the API get GPU enabled.

I don't know? Even if a GPU core is poorly suited for the purpose, modern video cards have so many cores that it could be done.

I used to write code in assembly language, and I just don't buy the excuses that it can't be done.

But, I guess we'll have to wait for the competition to spur RED to action, even though offering a GPU-enabled API now would reduce the 'cost of entry' and probably sell more RED cameras.

BTW - R3D encoding is similar to the wavelet encoding of JPEG2000.

Just google a bit for jpeg2000 and GPU, there are a number of solutions. This one encodes (which is usually harder than decoding) http://cuj2k.sourceforge.net/
 
Last edited:
talked to david newman about this (cineform.....wavelet)
he indicated there was no advantage to gpu wavelet decoding at this time
 
Zach Gray said:
They are obviously the experts, but from the outside, it looks as if progress is being made. A simple Google search returned gobs of stuff about wavelet decompression on gpu... like this one http://iwi.eldoc.ub.rug.nl/FILES/root/2009/ProcISPAvdLaan/2009ProcISPAvdLaan.pdf where they are getting a 5x speed improvement.

There is obviously something about the process that isn't obvious without expert knowledge, and I'm pretty darn sure that the folks at RED aren't lazy.

I can see the value in opening the codec to get outside ideas, but I see why they are protecting it, given the redRay factor.
Click to expand...

Ummm... They're getting a 5.4X speed increase over slow crap. So what? It's a straight-forward single layer wavelet transformation on 8bit 1080p video. They're spending more GPU compute cycles on motion compensation and other tasks than on the wavelet processing.

Les C. said:
What's ARRI's format coded with? I posted a link a while back to a pdf from ARRI talking about their new GPU enabled API.
Click to expand...

ARRI RAW is uncompressed. It does not have the massive computational requirement that REDCODE files do with the wavelet decodes. It comes with compromises as well -- massively larger data sizes, the need for an external data recorder to actually swallow the data at 3K, they don't even offer 4K, 5K, etc.. They have enabled GPU acceleration for debayer operations and a few other things within their beta SDK recently. This is something I wish RED would do, however it really makes little difference at the end of the day in terms of overall performance at this level in the image decode process. It's more of a convenience gesture for developers. Every little bit helps though.

I don't know? Even if a GPU core is poorly suited for the purpose, modern video cards have so many cores that it could be done.
Click to expand...

Wavelet algorithms are not something that you can simply throw tons of relatively low-powered processors at. Upcoming GPUs and compute cards, like the Intel MIC I keep mentioning, are far better suited to this sort of application, so I remain hopeful that something is coming soon. But current GPUs in the form of nVidia Fermi, currently available Kepler, and what AMD/ATI is pushing, are all ill-suited for actually providing an advantage here over CPUs when it comes to the number of layers and resolutions / frame rates required for 4K/5K R3D.

I used to write code in assembly language, and I just don't buy the excuses that it can't be done.
Click to expand...

It can be done. It has been done. The currently available GPUs just are not as magical as everyone wants to believe. There is no advantage with them over what we get out of current CPUs. And there's plenty of things to keep the GPU busy in the pipeline, things that the GPU is actually good at.

BTW - R3D encoding is similar to the wavelet encoding of JPEG2000.

Just google a bit for jpeg2000 and GPU, there are a number of solutions. This one encodes (which is usually harder than decoding) http://cuj2k.sourceforge.net/
Click to expand...

Yes, it is similar to JPG2K. And no one out there is pushing 12MP+ images through complex, multi-layer wavelet transformations in real-time frame rates on a GPU. No one. The hardware just isn't a good fit for the task.

Debayer processing, on the other hand, is a task that current GPUs are very good at. And while it won't eliminate the actual bottle neck in R3D processing, it would be nice to see some GPU acceleration for the debayer portion in the R3D SDK. If it were to happen now, it would be limited even in that regard. As is ARRI's implementation. Even amongst CUDA and OpenCL libraries, there are still differences in precision and how that precision is handled amongst the different makes and models of GPUs out there. Both API's have made major strides in the last 18 months or so to overcome this, however there are still some issues. More so with CUDA, which is somewhat surprising since it's the proprietary API. A big reason why applications like Resolve, Premiere, etc.. tend to have lists of supported GPUs and the need to profile the GPUs before adding them into the supported hardware pool. On one system you may not see any issues. Across multiple systems rendering on the same footage with different GPUs, you can. And there are times when a non-profiled GPU may even exhibit undesirable results.
 
Jeff Kilgroe said:
Yes, it is similar to JPG2K.
Click to expand...

Before the encrypted REDCode it wasn't just similar it *was* jp2k compatible. The secret sauce was in the pre-processing and jp2k encoding optimization.
 
I heard Iridas has GPU debayer going in Speed grade but Red shut them down pronto.
I think its a protecting sales of the Red Rocket type deal.

Check out how fast Colorfront OnSet Dailies can debayer Arri Raw...
 
roryhinds said:
I heard Iridas has GPU debayer going in Speed grade but Red shut them down pronto.
I think its a protecting sales of the Red Rocket type deal.

Check out how fast Colorfront OnSet Dailies can debayer Arri Raw...
Click to expand...

Read above... ARRI RAW is not bottlenecked by the wavelet compression. Debayer / demosaic operations are fast to begin with and GPUs handle them quite well. The reason RED shut down Iridas was because they were doing their own debayer algorithms on R3D footage. Back in the day, before RED made R3D's a more encrypted format. And it was no more real-time than anything else at the time. Actually similar in performance to the original REDCINE. It was real-time on a fast quad-core machine doing one stream of 4K at half-rez low quality. RED doesn't allow others to circumvent the SDK and their debayer process -- it's about quality control and the consistent results. ARRI doesn't allow it, either. Iridas had to play by the rules and use the RED SDK. A few companies back then jumped the gun and Jim had to ask them nicely to please be patient and wait for the SDK to release. Companies like Iridas and Cineform were doing it -- Cineform demoed their solution at NAB 2008. This is ancient news too, that was 4 years ago now. There is currently beta GPU support in the ARRI SDK... Hopefully RED follows suit, but it's not going to offer the huge speed boost people are wanting. When people think of R3D playback and slow speeds, they think it's the debayer process, it's not, it's the wavelet decompression. Two different steps in extracting the image frames, and two very different types of processing are needed.

The RED Rocket is purpose-built for wavelet decoding and it does very well at that... Doesn't do much of anything else particularly well. And at this point, I think it's overpriced given how commonplace it's become within R3D workflow circles.

If R3D files were not wavelet-compressed, they would be several times larger and the only real bottleneck would be if you had slow drives that couldn't keep up. But 5KFF at 24fps would be about 650MB/s.

ARRIRAW on the Alexa Studio full 4:3 mode is roughly 290MB/s. No compression to deal with. CPU/GPU processing demands are minimal. ...But it's only 3K. The camera is bulkier, especially with the external recorder, very few people actually shoot ARRI RAW. The post controls are pretty week. Last I checked, ARRI only gave us 2 or 3 sliders to work with in processing the RAW itself.
 
To be honest, with the latest Adobe upgrade to CS6, my dual Xeon with GTX-580 will play Premiere real-time at 1/2 resolution for 4K quad recorded at 6:1 compression. All the cores are at 100%.

I can replace my Xeons with faster versions that would double my speed (giving me hopefully real-time at full resolution), and there are even faster Xeons that won't fit on my motherboard.

This GPU discussion may be becoming a moot point as processor speed (or rather processor/system/RAM efficiency) increases as well as the # of cores multiply like rabbits.

It's been a very long time since I thought about assembly language, but ... it only takes a few microprocessor instructions to be able to perform any task on a computer. The more powerful instructions can be built from the simpler ones, and that's the way it's been done at times in microcode on the CPU.

With enough CUDA cores thrown at a task, I can't help but think you could build a HAL eventually (or certainly a phone's mapping service that doesn't direct you to quicksand).

But ... unless market pressures prompt RED to jump on the GPU bandwagon, whatever RED will do regarding GPU's is anybody's guess?

Until then, get a lot of processors with lots of cores - and forget worrying about GPU acceleration, as only RED can add it to their API.

If ARRI comes out with a 6K - it will have to have a lot of compression to get that file size down, most likely wavelet as that's the direction modern video compression has been heading for a while, and then we'll see if GPU wavelet decoding is possible at all - and if RED jumps in with their own to be competitive.
 
Prior to a build (was it 16), many companies had realtime displayed publicly, including but not only Assimilate.

After that, I have seen it in "back-room" builds also after 2008, and the explanation that it hasn't been publicly accessible has been lack of sanctioning by RED.

Actually realtime 1/2 4k ran pretty smoothly on my mac back then.
And after the change: No longer.

According to my selective memory, the guys over at Cineform displayed theyr alternate way of debayering and de-compressing.
RED wasn't particularily enthused by that, and made that route a no-go. and it has been ever since.

If I should guess, it isn't overheaded to sell Rockets, but to keep control with the format and the resulting images. Which in itself was good initially, as it was a new thingy.

When Cineform did their trick, Jim and Graeme was all over the place displaying how bad it was for the images.
Cineform improved
And then it was shot down.

The discussion ran high but eventually ended, as there wasn't anything real to discuss anymore.

After having been in this RED boat pretty much from before the start, it is obvious that on some controversial issues, decissions have been made, and then we move foreward.

You know what?
Whether I have agreed with those decissions or not.
THAT is probably what have made move... :)
 
It would be nice to atleast get the gpu helping.....all that power gone to waste.
 
You must log in or register to reply here.
Back
Top