I know the one you're talking about, it looks really good...nice to hear the benchmark you're confirming. This is a loaner for the company I'm working at but if I personally wanted something like this I would look at what you have. To be honest, local files on a 6Gb/sec SSD would also be nice.
When you say RGB are you talking about Nuke's native caching format, . ie. sgi .RGB? On 29 March 2013 19:38, Diogo Girondi <[email protected]> wrote: > There is a cheaper alternative from OCW that costs around 1.3k for 960GB. > I'm testing it and so far so good, approx 720MB/s sustainable on my tests. > Enough for one stream of 2K full-app 12bit RGB. > > It's not as fast as most of FusionIO boards but for it's price I'm happy > with it. > > > On Fri, Mar 29, 2013 at 5:46 PM, Simon Blackledge < > [email protected]> wrote: > >> Tested one in a z820 with Resolve and it was crazy fast. Made everything >> very fluid using dpx and I/o for cache and storage. Didn't get chance to >> try nuke but it was mighty impressive if not a touch small at 340GB. >> >> >> >> Sent from my iPhone >> >> On 29 Mar 2013, at 19:48, Michael Garrett <[email protected]> wrote: >> >> I just checked 10 bit log dpx files, it is flying! Just some basic >> operations afterwards, blur, grade, roto shape premulted, transform, plus. >> Also I tried a gpu accelerated denoise. Pretty impressive. Maybe we all >> need to go back to 10 bit log files for storage :) 16 bit dpx was also very >> fast. >> >> >> I >> >> >> On 27 March 2013 23:52, Michael Bogen <[email protected]> wrote: >> >>> Setting your disk cache and your local cache to the card makes nuke very >>> fast. Mostly dpx files. Thanks Deke for the tip about the Exr. >>> >>> michaelb >>> mbfx.me >>> >>> >>> On Mar 27, 2013, at 7:16 PM, Michael Garrett <[email protected]> >>> wrote: >>> >>> Hi Deke, >>> >>> That all makes sense, I figured I should try Cineon/DPX out of curiosity >>> for the exact reasons you state, although it's not part of our pipeline. >>> It'll be interesting to compare notes about the card performance as a >>> whole, though. >>> >>> I wonder if it's possible to at some point get exr's to decompress on >>> the gpu? >>> >>> Michael >>> >>> >>> On 27 March 2013 18:47, Deke Kincaid <[email protected]> wrote: >>> >>>> Hi Michael >>>> >>>> I'm actually testing this right now as Fusionio just gave us a bunch of >>>> them. Early tests reveal that with dpx it's awesome but with openexr zip >>>> compressed file it it is spending more time with compression, not sure if >>>> it is cpu bound or what(needs more study but its slower). Openexr >>>> uncompressed files though are considerably superfast but of course the >>>> issue is that it is 18 meg a frame. These are single layer rgba exr files. >>>> >>>> ----- >>>> Deke Kincaid >>>> Creative Specialist >>>> The Foundry >>>> Mobile: (310) 883 4313 >>>> Tel: (310) 399 4555 - Fax: (310) 450 4516 >>>> >>>> The Foundry Visionmongers Ltd. >>>> Registered in England and Wales No: 4642027 >>>> >>>> >>>> On Wed, Mar 27, 2013 at 3:26 PM, Michael Garrett <[email protected] >>>> > wrote: >>>> >>>>> I'm evaluating one of these at the moment and am interested to know if >>>>> others have got it working with Nuke nicely, meaning, have you been able >>>>> to >>>>> really utilise the insane bandwidth of this card to massively accelerate >>>>> any part of your day to day compositing? >>>>> >>>>> So far, I've found it has no benefit when localising all Reads in a >>>>> somewhat heavy comp, or even playing back a sequence of exr's or deep >>>>> files, compared to localised sequences on a 10K Raptor drive also in my >>>>> workstation - hopefully I'm missing something big though, this is day one >>>>> after all. >>>>> >>>>> There may be real tangible benefits to putting the Nuke cache on it >>>>> though - I'll see how it goes. >>>>> >>>>> I'm also guessing that as gpu processing becomes more prevalent in >>>>> Nuke that we will see a real speed advantage handing data from a card like >>>>> this straight to the gpu. >>>>> >>>>> Thanks, >>>>> Michael >>>>> >>>>> _______________________________________________ >>>>> Nuke-users mailing list >>>>> [email protected], http://forums.thefoundry.co.uk/ >>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Nuke-users mailing list >>>> [email protected], http://forums.thefoundry.co.uk/ >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
