Dave Haynie
Forum Replies Created
-
[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
-
[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
-
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
-
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
-
[Stephen Mann] “I beg to differ – it is not a design flaw, as it was not designed to sync with video.”
Well, as a professional electrical engineer, I still disagree. It’s not that some of these devices were not designed to sync to video (and certainly, while DSLRs are new, pretty much every other kind of video camera pre-dates the advent of high quality digital recorders), it’s that they were not designed to sync. Period. A Zoom H4 can’t be expected to sync with another Zoom H4 any better than your it will your camcorder.
As additional evidence for this being a design flaw, I present exhibit A: camcorders. They pretty much do sync, one to another, without any need (or usually, provision) for a bit-clock input. Not forever, sure, but until SDHC cards, the question was only of staying in sync for 83 minutes or less.
As exhibit B, I present “other digital field recorders”. My first recorder, the very first Tascam D1, has an accurate clock; never had a problem with it syncing with any of my three pro-class camcorders or my 60D, or the Zoom H4n. This came out in early 2008, before any DSLR was on the market…. I used it initially as a field recording adjunct to my Sony MD recorder. The Marantz 660 (wasn’t that the original point), released in 2007, also had good accuracy.
And there’s exhibit C: the MD recorder. These also synched to video just dandy.
No one’s expecting these to sync for 24-hours at a time. But as I pointed out, the difference between the quality of sync of most of these devices, and the few that don’t sync, amounts to about $0.30 per unit. That tells me those who have that problem didn’t understand the problem they were trying to solve, and that has nothing to do with video sync. That makes it a design flaw.
But hey, you’re welcome to disagree, and I won’t yammer on about it anymore.
-Dave
-
Sure, for voice “dictation” devices, the clock’s not that critical. But I don’t think anyone’s using these for video. The digital field recorders (Zoom, Tascam, Marantz, etc) were designed for audio recording: better-than-CD quality for music, etc.
Sync issues have been known for decades in the digital pro audio world. The fact that some of this kind of device didn’t even try to use accurate clocks IS a design flaw.
-Dave
-
[Colin Morris] ” I will sometimes have to nudge the entire audio recorder track in relation to the camera mic track, but it is not drifting-just more like manual delay compensation.”
That’s the synchronization part — the job PluralEyes does for you. That’s normal, and it’s always an issue when you start multiple things at different times. The deal with drift is that you sync at one place, but the recordings “walk away” from one another. Using the worst quality quartz crystal I have ever used on a product (100ppm), that means you really wouldn’t see meaningful sync loss under about 30 minutes.
The great thing about PluralEyes (and similar) is when you have, say, a couple of audio recordings, maybe three camcorders going, each with many clips as they’re moved about, started and stopped, etc. That’s a good bit of work to sync by hand… nicer to just press a button and have it all locked together. When it works, which for me is pretty much always.
I use one digital recorder, usually, for the time base… it runs through the entire event. Both my Tascam D1 and Zoom H4n keep good sync, but it’s pretty well documented that earlier Zooms, like the Zoom H4, had lousy timing. That seems to be on the order of 500ppm, which would imply it’s using a high quality ceramic resonator rather than low quality crystal. The price differences are not much… in quantities of 25K or so, you could pay $0.60 for a 10ppm crystal, $0.40 for a 100ppm crystal, or $0.10 for that ceramic resonator.
The HD7s don’t record seamlessly? That’s a shame, most newer devices don’t drop a bit between 4GB files, though I have yet to find a camcorder or HDSLR fully supporting 64-bit file systems. Once you have SDXC card, the 64-bit exFAT file system is required, even if you’re only dropping 4GB files.
-Dave
-
I think that’s the other thing — good design. I have mixed camcorder brands, camcorders and HDSLRs, etc. on multi-cam shoots, and never had a problem with video clips walking away from each other.
But this was a problem with audio recorders. That was due to bad design. Seems to mostly be fixed in the latest crop of devices.
-Dave
-
[Stephen Mann] “Or that they buy all their crystals from the same source.”
Unlikely. But I do believe that any camcorder company would understand the need for accurate timing, since pro video is always using multiple cameras that need to be synched. These things don’t always carry over between divisions, but even if not, it’s probably more natural for a Sony guy making a digital field recorder to think “video”, given that Sony IS one of the big four in pro camcorders, compared to the guy at Samson making the first Zoom recorder. The Zoom guys DID get the message, as my more detailed discussion above points out.
Yeah, it CAN be luck, between two devices. Once you have three or four that remain in sync, and it’s NOT by design… well, if you’re that lucky, I hope you bought a PowerBall ticket last night 🙂
-Dave
-
[jack wormell] “The bit rate is 8000, CBR, multi-pass. Is this insane?”
8000kb/s (8Mb/s) should be achievable by any DVD player. Have you tried a different video player? VLC has some I/O problems that have never been resolved. It’s good enough off an HDD to generally work, but there are better. If you have Windows 7, even Windows Media Player will work better (as well as using a DXVA 2.0 accelerated AVC decoder).
There’s really no such thing as CBR multi-pass. Not sure which software would even allow that. CBR means “Constant Bit Rate”… it’s always doing the same bitrate. The reason to run a multi-pass encoding is to allow the encoder to learn about the entire video, to better plan out a variable bitrate encoding.
Also, what kind of PC is being used? Given that you have CBR encoding, there’s actually no possibility for a bit-rate spike as there might be with VBR. That doesn’t mean the decoding job your CPU is doing will be constant work, only that the data coming in is always the same bitrate. VLC doesn’t use much if any GPU acceleration, which means you probably need a decent two-core processor to smoothly decode AVC in high definition.
-Dave