if you're on a budget you can also hook up two consumer SSDs to
some SATAIII ports and raid them... you can get 500GB of
insanely fast local for under 300bucks this way (and 1TB for
about 600).
i've got over 900MB/sec sequential read/writes with with two
Agility3 240GB as RAID0 on a the i7
Awesome, I guess that will be my next test then ;)
Thanks Chris!
On Sat, Mar 30, 2013 at 9:47 AM, chris ze.m...@gmx.net wrote:
if you're on a budget you can also hook up two consumer SSDs to some
SATAIII ports and raid them... you can get 500GB of insanely fast local for
under 300bucks
Why non-sandforce for compressed data?
Sent from my iPhone
On 30 Mar 2013, at 12:53, Diogo Girondi diogogiro...@gmail.com wrote:
Awesome, I guess that will be my next test then ;)
Thanks Chris!
On Sat, Mar 30, 2013 at 9:47 AM, chris ze.m...@gmx.net wrote:
if you're on a budget
Sand force chips compress data for faster transfer rates. So for some reason
which is beyond my understanding ;) they don't deal so good with video files.
I have 3 ssd drives. An intel 520. A crusial m4. And a Samsung pro. They are
all approved by blackmagic as suitable for uncompressed and
And the sand force chips has a name for being unreliable
--
Matan Arbel
Motion/Graphic Designer
matanarbel.com
On Mar 30, 2013, at 4:32 PM, Simon Blackledge
simon.blackle...@spacedigital.co.uk wrote:
Why non-sandforce for compressed data?
On 3/30/13 at 2:32 PM, (Simon Blackledge) wrote:
Why non-sandforce for compressed data?
the sandforce controller does on-the-fly real-time compression
of data when reading/writing to disk. this doesn't allow you to
store more total data (ie capacity doesn't increase), but the
I/O can be
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.
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
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,
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.
RGB encoded instead of YUV which tend to be smaller. That ~720MB/s I got
from Blackmagic's Disk Speed test. On the tests I did so far one stream of
2K full-app 12bit dpx files playback at a flat 24fps without a glitch. In
theory it should be able to handle two streams of 2K full-app 10bit dpx
@support.thefoundry.co.uk
*Subject:* Re: [Nuke-users] FusionI/O and Nuke
Setting your disk cache and your local cache to the card makes nuke
very fast. Mostly dpx files.
I've done just that, but it hasn't made any difference over using a 10K
raptor drive, at least for local caching. I'll monitor
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
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
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
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 michaeld...@gmail.com wrote:
Hi Deke,
That all makes sense, I figured I should try
and
decompression on a single thread.
DPX should cook though.
-Nathan
From: Michael Garrett
Sent: Wednesday, March 27, 2013 9:27 PM
To: Nuke user discussion
Subject: Re: [Nuke-users] FusionI/O and Nuke
Setting your disk cache and your local cache to the card makes nuke very fast.
Mostly dpx files.
I've
17 matches
Mail list logo
