FORUMS: list search recent posts

Another cache post. Wait… it's not as bad as usual…

COW Forums : DaVinci Resolve

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
jake blackstone
Another cache post. Wait… it's not as bad as usual…
on Jan 30, 2014 at 9:41:43 am

I tried to use cache again (Resolve 10.1) and to my amazement, closing project doesn't kill cached render any longer. Sure, for some reason a few events lose cache, but most of the timeline is still there no matter how many times I restart the Resolve or select a different project. Actually, while using two different projects now (one Alexa and one Red) I can switch back and forth between them and cache is still there. I even cached a full quality Red debayer and now I get perfect full quality playback. Unfortunately, bypassing a single node causes loss of cache for that shot, but the full bypass keeps the cache(?) Had anyone seen this? I had seen a while ago a note about persistent cache, but it didn't work for me then, at least not as good as now. What I'd like to know is, how does one purges the cache? Because now with persistent cache it doesn't get automatically deleted, when you quit the project and there is no clear way, other than looking inside each folder to know which folder works with which project. I'd like to see some mechanism inside each project for managing cache.


Return to posts index

Margus Voll
Re: Another cache post. Wait… it's not as bad as usual…
on Jan 30, 2014 at 2:14:56 pm

So it seems almost good then :)

--

Margus

http://iconstudios.eu
https://vimeo.com/iconstudioseu/videos

DaVinci 10, OSX 10.8.5
MacPro 5.1 2x2,93 24GB
GUI 4000 / GPU GTX 780
DL 4K
Eizo Color
Scope Box
Full Ligthspace CMS


Return to posts index

Sascha Haber
Re: Another cache post. Wait… it's not as bad as usual…
on Jan 30, 2014 at 3:50:26 pm

Not at all.
Try to middle click from another grade, try lifting one from the Timeline, or changing its length.
And now try to make a change on a Red clip that is used several times, but uses local gradings.
All these action invalidate the cache.
Furthermore it only seems to work on material brought into the timeline as single clips, when you are grading from a full clip cut by and EDL its much severe.
I think the main problem with it is that it doesnt really look a the local media created during caching.
At least the functions that make it go back to the source are way off....for now.
But they know already ...lets wait and see :)

A slice of color...

Resolve 10.1.0.021
Colorist / VFX / Aerial footage nerd
http://vimeo.com/saschahaber


Return to posts index


jake blackstone
Re: Another cache post. Wait�¢ï¿½�¦ it's not as bad as usual�¢ï¿½�¦
on Jan 30, 2014 at 9:49:06 pm
Last Edited By jake blackstone on Jan 30, 2014 at 9:56:31 pm

Well, as I said in the name of the post "It's not add bad as usual". I din't say, it's all fixed:-)
Let's examine the improvements in cache implementation since we all started to complain.
1. Cache now persistent, unlike before. Now cache doesn't get erased every time you quit the project. Although, as I already had said, Resolve randomly "forgets" some cached events. And the question is how to manage the no longer needed cache still needs to be addressed.
2. Now you can toggle "all bypass" without invalidating the cache. I'm still mystified why doing the same with a single node causes the opposite.
So now, for short form projects, like commercials with Red material, I can invoke a full debayer quality, enable the "cache all" and invite clients to have a drink. In a short period of time I can playback the commercial in full quality with all effects in real time with no dropped frames. If the client wants a fix, I still can do it without re-rendering the whole thing.
Is the caching in it's present form perfect? Not by a long shot. Can I use it now in somer instances, Heck yeh!
The reason for my original post was the idea, that finally I can see the forward movement on the cache front. Said that, there is still a LOT of work needs to be done before caching can be used as it's intended.
And now, how about some progress on the panel re-mapping? :-)


Return to posts index

Chris Hall
Re: Another cache post. Wait… it's not as bad as usual…
on Jan 30, 2014 at 4:46:03 pm

I noticed those improvements, but my cache still renders incorrect black levels when you play through a clip to cache it (instead of waiting for the render to happen in the background?). Anyone else still having that issue?

Chris Hall
Colorist - Prehistoric Digital
Santa Monica, CA


Return to posts index

Paul Provost
Re: Another cache post. Wait… it's not as bad as usual…
on Jan 30, 2014 at 6:09:18 pm

Been sort of working for a while now, but yeah needs work. Hopefully the now upcoming r3d cuda debayer sdk is sooner than later as I usually use cache on red jobs, and this update may help make caching unnecessary.

http://www.4Kfinish.com | owner-colorist | Los Angeles, CA
http://www.facebook.com/4kFinish
Twitter 4kfinish


Return to posts index


Robert Ruffo
Re: Another cache post. Wait… it's not as bad as usual…
on Feb 1, 2014 at 12:16:10 am

Not sure Cuda debayer will play nice with software like Resolve which is already taxing the GPU.

I would suggest a Freeze option - Freeze debayer, Freeze Until this Node, etc - would render DPZ of all until that time, and grey out the nodes that we require a re-render fi unfrozen. Would be great for OFX and noise reduction too - and we would learn the habit of noise reducing early in the chain.

A smart implementation would render out the alpha as well, but a reasonable restriction would be that alpha is unavailable until that node, and/or that the node chosen for "Freeze Until This Node" cannot contain an alpha output, just color. Freeze could also restrict to freezing everything (as last node output is color by definition) and it would save an alpha DPX seperately if "add alpha output" was present, and freeze both, to keep things simple, or maybe just Freeze doe snot work if "Add alpha output" has been used (still OK in most cases).

Then the user could add more nodes, and "grade over" the high bit DPXs, and only the changes within those nodes would need to operate in real time.


Return to posts index

Sascha Haber
Re: Another cache post. Wait… it's not as bad as usual…
on Feb 3, 2014 at 11:10:45 am

Ok, I made some tests and installed 10.1.1 but the situation is still the same.

1. The cache works much better now...yes...but ONLY on single media shots.
2. When using one large video file or instances of RED, it treats all separated clips as one, so if you change the grading on one element by middle click from the gallery, all clips get invalidated.
3. Lifting and moving cached elements works (if they are singled) Trimming does not work
4. Inserting media invalidates the cahce downstream

Lots do do still, but fine for a playback session :)

A slice of color...

Resolve 10.1.0.021
Colorist / VFX / Aerial footage nerd
http://vimeo.com/saschahaber


Return to posts index

Marc Wielage
Re: Another cache post. Wait… it's not as bad as usual…
on Apr 8, 2014 at 10:24:03 pm

I think we should officially call the new cache feature in Resolve 11 "The Blackstone Cache."


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]