-
Vegas 12 Workstation Specs
-
In short, to compile all I’ve read the past couple days: speed/quality/price, pick any two.
-
[Pete Schaefers] “In short, to compile all I’ve read the past couple days: speed/quality/price, pick any two.”
by jove i think he’s got it! 😉
~jr
http://www.johnrofrano.com
http://www.vasst.com -
Given the choice, for video, I’d take the 4-channel bus (that’s the correct spelling, buy the way, not “buss”) and the 8GB. Naturally, you can upgrade at some point. But I have never needed more than 8GB for anything I’ve done in video, on my 6-core system, including animations with up to about 50 layers in Vegas. I have 16GB now, but that was prompted by some still photo stuff I was doing… 50+ shot composites in RAW from an 18Mpixel camera, that kind of thing.
-Dave
-
[Dave Haynie] “Naturally, you can upgrade at some point. “
Yea, with the point being that you can always upgrade the 8GB of 4 channel memory to 16GB but you can NEVER upgrade 2 channel memory to 4 channel. That’s why we both recommend that you go with the 4 channel bus.
~jr
http://www.johnrofrano.com
http://www.vasst.com -
My original question was memory access vs. memory size, as it applies to Vegas. And yes, you can upgrade memory size but not access path in a system, and I decided on a 4 busss 😉 system fairly soon for that reason and that, as expected, I could see that access path was important to video processing. (Dave is probably correct, https://www.worldwidewords.org/articles/omnibus.htm but “buss” is also widely used and acceptable.) The question was spawned in part by system options (some requiring more expensive ECC RAM for larger amounts of RAM in a 4 buss system), and in part to the i7-3770 (2 buss) CPU that many seem to be doing well with. As far as CPU I have decided on an E5-1620 or better (better meaning a 6 core).
Just curious, given that 4K video is ~about~ 9Mpx (1/2 that of 18Mpx) would you think 4K would also require greater than 8GB? I’ve never worked in 4K (yet, right…?)
-
The 4K resource-load question, of course, depends on the CODEC. You’re putting a heavier HDD load on your system when you up the bitrate, and a heavier CPU load when you increase the CODEC complexity. Memory plays a role in both cases, and hasn’t really been an issue, but with some of the fastest CPUs around, it starts to be.
And this is somewhat specific to media streaming. In lots of applications, the on-chip L1, L2, and L3 caches help a great deal. In rendering, they help a little for data, simply because decide isn’t a single step process, but the external memory bandwidth matters, particularly as you add cores. So without a specific answer, I’d err on the side of a better memory subsystem, all things being equal.
They aren’t necessarily equal, either. Intel’s four-bus chips tend to be higher spec than similar parts in two-bus layout.
The other thing: today, you’re probably going to edit 4K in either AVC (or something else already used for 2K/HD) or R3D, which is lots of data, relatively low CPU overhead. Remember, when we all moved from DV to HDV, we didn’t just get the 6x increase in video data to deal with, but the even larger increase in complexity going from intraframe-only DV (very similar to I-Frame only MPEG-2) to full IPB frame MPEG-2. Going to 4K, at least for the moment, we’re increasing the load by 4x. Probably not anything more, in the short term anyway.
As far as ECC (error checking and correcting) RAM, that’s always been kind of a debate. Back in the days of parity and expensive RAM, it didn’t make a great deal of sense; a system could tell you about a single bit failure, but couldn’t really do much about it other than faulting the process. Once you get to 64-bit words, an 8-bit ECC code for the full word width can use that same 1-bit per byte storage to actually correct any single bit failure (in the 64-bit word) and detect two. So it’s certainly more useful. I’ve yet to be convinced it makes any difference in practical workstation-class systems.
As for all that “buss” stuff… man, that’s fingernails on a chalkboard to my eyes… in fact, I’d prefer the fingernails on the chalkboard. YOU may find the spelling acceptable, but it’s simply incorrect. No room for debate here, you’re using the wrong word… unless you have a very unhealthy relationship with your hardware (you did also Google the actual meaning of the word “buss”, didn’t you?)
Don’t have to take my word for it, Google up any bus specification: PCI, S-100, PCIe, SPI, EISA, EV6, ISA, AMBA/AHB/AXI, I2C, RapidIO, PC/104, USB, VME, Firewire, SATA, PATA, Microchannel, NuBus, Thunderbolt, Wishbobe, or even the one I designed (and my only patent, so far): https://www.thule.no/haynie/zorroiii/docs/zorro3.pdf.
Maybe using the wrong word is “acceptable” on a video blog, but it’s not going to play within the electronics industry.
-Dave
-
Some say ECC is (slightly) slower, others claim that with larger amounts of RAM the error rate increases enough to make it worth the minor speed hit. Personally I think it’s splitting hairs for all but the very high end applications. The main issue for me is cost, and I don’t like being pushed toward ECC when (imo) it’s not necessary. On the other hand, given the choice where the price hit is not awful, I would opt for ECC.
If I followed your trail on the 4K type of source material you haven’t seen it be nearly the same RAM sucker as the latest high pixel DSLR stills. I lean toward quality first, quantity second… so a good CPU, 8GB (ECC if affordable), and 4-bus (for Dave 🙂 ). More RAM can always be added as necessary.
Back on the GPU question… In the Quadro line I have settled on the 2000, simply because the rendering performance gain with the 4000 didn’t seem that great. Alternately, if I really want bag-for-buck on speed (and don’t mind the possibly of some hassles) I would give the GTX-570 a shot. It has a decent track record (over the 6xx line) and many report that it works solidly. (nVidia and PNY both agree with this logic while politely making the Quadro the official recommendation.) So we’ll see…
And… I gotta say, I’ve never kissed my computer (I did see that usage, though I’ve never heard used), but if all goes well I might make an exception. 😉
-
[Pete Schaefers] “Some say ECC is (slightly) slower, others claim that with larger amounts of RAM the error rate increases enough to make it worth the minor speed hit. “
Both are technically correct. When the memory controller reads an ECC word, it naturally reads both the 64-bits of data and the 8-bit ECC code. It then has to calculate an ECC code from that 64-bits of data, compare that to the ECC code read, and apply the correction or signal the detected error as necessary. That takes at least an extra clock cycle.
However, it’s very rare in modern DRAM systems for a controller to do a single word read. Most reads are cache line prefetches — the whole cache line is read. This may be necessary, depending on the cache design, but it also exploits the fact of all DRAM that while an initial random access is relatively long, the next N cycles on the same memory page happen much, much faster. And the controller is pipelined, so while that first word is in the ECC processor, the next DRAM access has already started. For writes, the writes usually take place to cache and get flushed sometime later, so the effect of ECC on write cycles is not easily even measured. In practice, it’s not going to make much difference.
As for cost, there’s no inherent reason an ECC memory should be more than 9/8 as expensive as a normal memory. But with the crazy economies of scale in the PC business, ECC being less common may have a more dramatic effect on the prices — it’s been awhile since I looked for ECC or parity memory, personally. Yeah, there are some people worried about bit errors, and they do occur. On the other hand, they’re orders of magnitude less likely than programming errors, unless you have a faulty system (ECC can also hide the fact that you have a failing DRAM module… DRAM modules are very reliable, but they do occasionally fail).
[Pete Schaefers] “Back on the GPU question… In the Quadro line I have settled on the 2000, simply because the rendering performance gain with the 4000 didn’t seem that great. Alternately, if I really want bag-for-buck on speed (and don’t mind the possibly of some hassles) I would give the GTX-570 a shot. “
When Vegas first got serious GPU acceleration, over a year ago (V11), I bought both a nVidia GeForce GTX570 and an AMD Radeon HD6970, both about $300 each. I ran extensive benchmarks on the two, including a bunch of OpenCL benchmarks independent of Vegas. At least for that matchup (my only use for the good GPU was Vegas), the Radeon outperformed the nVidia on every benchmark… though the nVidia would probably have beaten the AMD on most gaming comparisons. That write-up is around the COW somewhere. I also found that, at the time, nVidia has a few bugs in their OpenCL implementation, though that’s likely been fixed.
Of course, if you’re not looking specifically at Vegas, there is still better support for CUDA than OpenCL.
-Dave
-
[Dave Haynie] “Of course, if you’re not looking specifically at Vegas, there is still better support for CUDA than OpenCL.”
IMHO, this should weight heavily in your choice of cards. Today you may just be using Vegas but tomorrow you might want to branch out into Motion Graphics and so you purchase Adobe After Effects only to learn that it only supports CUDA so you’ll need an NVIDIA card.
I didn’t benchmark with two cards like Dave did, but I did compare rendering with the CUDA option and OpenCL option and for my Quadro 4000, the CUDA option was much faster. I’m not sure how an AMD card would have done with OpenCL.
I applaud Sony for supporting open standards but video production is an ecosystem and everyone else in the ecosystem has settled on CUDA. That is something to consider.
~jr
http://www.johnrofrano.com
http://www.vasst.com -
[John Rofrano] “IMHO, this should weight heavily in your choice of cards. Today you may just be using Vegas but tomorrow you might want to branch out into Motion Graphics and so you purchase Adobe After Effects only to learn that it only supports CUDA so you’ll need an NVIDIA card.”
Adobe is moving to OpenCL, too. I say “moving”. Their “Mercury” video engine, for CS6, does both, though unlike Vegas, it’s currently doing both, not moved entirely to OpenCL yet. I’m not an Adobe person for video, so I don’t know, but I suspect this is a process, and you may still be better off with CUDA than OpenCL for Premiere.
The newer Mercury Graphics Engine, for Photoshop, is pure OpenCL. That seems to be where they’re headed.
Part of this shift is the obvious case that CUDA is proprietary. That may be fine when nVidia and AMD/ATi are the only choice, and it certainly was back when nVidia was inherently faster, and the only company really pushing for native GPU computing. But now there’s Intel doing GPUs that are actually capable of GPU computing, even if at lower performance levels than the others. But also developments like Intel’s “Phi” — that’s 60 x86(ish) cores on a single under-$2000 PCI Express card. And already supported by OpenCL.
[John Rofrano] ” didn’t benchmark with two cards like Dave did, but I did compare rendering with the CUDA option and OpenCL option and for my Quadro 4000, the CUDA option was much faster. I’m not sure how an AMD card would have done with OpenCL”
I would definitely expect the same benchmark to run a bit faster on CUDA than OpenCL on nVidia. For one, CUDA was designed based on how nVidia GPUs work. But also, OpenCL is built on top of CUDA… nVidia didn’t trash CUDA and start over with OpenCL, they just added to what they already had.
It may also be benchmark dependent. In my tests — admittedly just two hardware sample points in a very complex question — I got measurably better performance out of the AMD than the nVidia in Vegas. And yet, the nVidia has the edge in pretty much every gaming test done between the two. I was actually a bit surprised, given that AMD uses more, simpler processing elements versus nVidia (about 3:1 in this generation).. but nVidia seems to be moving more in that direction in their future chips.
I also found that the nVidia was using far more of the GPU, 70-80%, versus around 40-50% on the AMD. While that suggests the AMD was actually much faster, spec-wise, than the nVidia, it also kind of suggests it’s a harder architecture to use. That kind of suggests that, if you’re looking for performance at any price, a super-high-end nVidia might deliver more than a super-high-end AMD. I did not test this. I do have a pretty fast i7 Gen 3 at work, and a nVidia Pro 4000-series GPU.. maybe worth a benchmark at some point.
-Dave
Reply to this Discussion! Login or Sign Up