[Dave Haynie]

A couple of things. Like some others here, I have used Vegas since the early days… Vegas Pro, before video. There was a time when it was the most solid piece of software I used, period… even including $10,000+ electronics CAD packages (several).

It’s not quite that stable anymore. But I also haven’t found all that many problems. The one I did find with Vegas 10 was that nested projects got flakey. Sometimes very flakey. I had a project saved off that basically crashed on load 9 out of 10 times… I wound up rendering out the subprojects (to 4:2:2 Cineform, which they finally got working in Vegas 10e), and all was right and good again.

While I will admit that to being a huge pain in the butt, it’s also true that I was making too many demands on subprojects. No, they shouldn’t crash. But once I added up my subprojects, I was over 50 layers of video, greenscreens, animated PNGs, etc. I certainly had no business expecting it to take up just little memory (particularly given that I never resize my graphics, and usually author my animations in 1080/60p, even if I eventually render them out to something lesser). And yet, it was photo work that got me to add that second 8GB.

So anyway, I just finished two pretty similar animation projects, the last one on Vegas 11. I actually felt a little vindicated on the Vegas 11 upgrade, despite the fact that I KNOW it’s an x.0 release and I should have been cautious when it was real work … and I had about 24 hours to edit, after the live part of the video was shot. One bug in one plug-in, that was about it.. and editing with GPU acceleration did make a difference. But I got it in on time: https://youtu.be/QYoszzMuaJE

What uprezed 4:2:2 format are you using? I have found DNxHD to be very slow given what it’s doing… that’s an Avid problem, not a Vegas problem. Cineform seems stable, though Vegas 10 broke it in amazing and stupid ways for releases up to 10c or 10d. I fault Sony less for trying something new (apparently they use a Cineform proprietary API to talk to the CODEC), and more for not offing me a get-out-of-jail-free card (a setup option to just use Video for Windows).

It can also always be greener on the other side, too. My daughter runs a Mac for High School (Communication Academy, going on to study Broadcasting and Digital Media in college next year). It’s a dual core i5-based Macbook Pro, much faster than my 4 year old HP Core2 laptop. Which can absolutely edit AVCHD with Vegas.. I’ve even edited 1080/60p on it, though I wouldn’t pick any laptop as my preferred editing platform.

Anyway, she shot some video on two of my cameras of her college trips, and wanted it on the Mac for editing purposes. No problems… I was pretty sure the AVCHD might be an issue (Final Cut Pro will probably insist on converting it to ProRes, which is of course fits the same niche as DNxHD or Cineform), so I rendered out 1/4 res AVC/MP4 (the MP4 wrapper is very similar to the Quicktime wrapper, should be a no-brainer on a Mac). Well… guess my surprise when Final Cut Express was driven to its knees by 960×540, base-level profile AVC/MP4! Way too slow for anyone to edit it.

Thus my discovery of Apple’s suggestion for editing: “iFrame”.. which is just that, all I-Frame AVC. At 960×540. And yeah, that was just dandy as an editing format. But seriously… people edit professionally on this platform? Particularly when you consider the only non-laptop Mac Apple makes is the tower-PC style MacPro, starting at $2500… ouch. And that one’s over a year old since the last update.

So it’s not just Vegas. But it sounds like you’ve not had the best experience possible, for sure. Most of us here will claim it’s usually much, much better.

-Dave

[Dave Haynie]

Sure sounds like a fast system, when things line up. I tried the same experiment: 10 minutes of AVCHD, direct from the camcorder (Panasonic HMC40, PH-mode, 1080/60i), rendered to the Main Concept Widescreen NTSC DVD template. This is rendering from my 3TB D: drive to my 1.5TB C: drive. This is actually the first time I ran Vegas 11.425… used the original extensively over the last few weeks. DRAM Preview is 1GB, tested with 64-bit Vegas, Windows 7 SP1.

Vegas 11 w/GPU, proj: HD 1080-60i, quality=good, pixel=8-bit.
time = 7:23 CPU = 65% GPU = choppy (peak at 31%)

Vegas 11 w/GPU, proj: HD 1080-60i, quality=best, pixel=32-bit(vl)
time = 7:02 CPU = 65% GPU = 38%

Vegas 11 w/GPU, proj: NTSC WS DVD, quality=best, pixel=8-bit
time = 8:13 CPU = 65% GPU = choppy (peak at 26%)

Vegas 11 no GPU, proj: HD 1080-60i, quality=good, pixel=8-bit
time = 7:39 CPU = 92%

Vegas 11 no GPU, proj: HD 1080-60i, quality=best, pixel=32-bit(vl)
time = 15:02 CPU = 98%

Vegas 11 no GPU, proj: NTSC WS DVD, quality=best, pixel=8-bit
time = 9:43 CPU = 95%

Vegas 10 no GPU, proj: HD 1080-60i, quality=good, pixel=8-bit
time = 7:26, CPU = 85%

Vegas 10 no GPU, proj: HD 1080-60i, quality=best, pixel=32-bit(vl)
time = 26:30, CPU = 50%

Vegas 10, no GPU, proj: NTSC WS DVD, quality=best, pixel=8-bit
time == 22:31, CPU = 40%

My PC Specs:
CPU: AMD 1090T @ 3.2 GHz
GPU: AMD Radeon HD6970
RAM: 16GB DDR3 Kingston HyperX PC3-12800
Boot Drive: 1.5TB Seagate 7200RPM
Storage: 3TB Internal, 2TB in drive slot, 8TB Drobo

-Dave

[Dave Haynie]

Oh, I don’t doubt it’s more broken now.. that seems to be the trend. Thing is, that might ultimately be a good thing. Fringy errors are easy to ignore.. and yeah, I told myself “just use MXF” when I couldn’t render in Main Concept beyond 50Mb/s (which, honestly, is the right answer more of the time, unless you had 4:2:2 or 4:4:4 in M.C.). But of it’s getting worse, perhaps Sony can’t ignore the problem. It would be sweet if they fixed Main Concept MPEG-2 (and I believe the AVC CODEC has the same issues), better yet if they fixed Vegas to correctly interface to these CODECs and report the errors they encounter.

-Dave

[Dave Haynie]

Did you view them in the Quicktime player on Windows and on the Mac, or some other programs? Same result? Be sure it’s a real sync loss, and not just the Mac having trouble playing AVC in realtime.

I just helped my daughter get some camcorder footage into her Mac (a loner at the High School), and while this is a dual core i5-based Macbook Pro, I was kind of floored at how much trouble it had dealing with H.264/MP4. Not only couldn’t she edit the originals (AVCHD from HMC40 in PH-mode… these preview full speed on my PC in Vegas), but I rendered 1/4 resolution H.264/MP4, and we couldn’t even edit that. This was with Final Cut Express. Previews basically played audio but video looked like a very bad slide show. These did play properly in Quicktime, however.

I ultimately created clips in something closely resembling Apple’s iFrame… 1/4 HD (960×540), I-Frame only, 20Mb/s. This edited just dandy on the Macbook Pro… heck, it would probably edit just dandy on my smartphone. These were batch converted with TMPGenc

She was happy with the quality, even though it’s “ED” rather than HD. Turns out, for the past few years, she’s been capturing to Apple-flavored DV (DV in a Quicktime wrapper) by playing HD video from her Panasonic SD9 into one of the school’s DV cameras… ouch! But it worked on the school’s Macs.

What’s up with AVC on the Mac, indeed?

-Dave

[Dave Haynie]

There’s been something broken in Main Concept MPEG-2 all along. Like, going way, way back. It got worse in Vegas 11.

The usual symptom is that it just stops rendering — you get an “unknown” error (eg, Sony isn’t passing the error codes from the rendering engine up to the user interface). This was guaranteed to happen if you set the bitrate too high.

So in Vegas 10, I had a number of presets for MPEG-2 rendering to higher quality, high bitrate MPEG-2… usually for intermediate files, rendering a finished product in another program, etc. These all ran at 50Mb/s… and every one of them fails with this error in Vegas 11.371. I was able to drop down to VBR averging at 35Mb/s and peaks of 50Mb/s with some early success, but that one failed on me, same way, last week.

Sony + Main Concept need to [a] fix this, and [b] actually report the error that’s seen by the Main Concept rendering engine. Some of this is understandable; it’s obvious that Sony licensed a new version of the Main Concept engines — they’re OpenCL accelerated. But for whatever reason, we’re seeing a bug or other issue in these that didn’t show up with the same parameters under Vegas 10 and earlier. Given that this is really a long-standing bug, they really could so us all a favor and fix both the bug itself (Main Concept) and the reporting mechanism (Sony).

-Dave

[Dave Haynie]

I shoot 1080/60i, 24p, 60p, and 720/60p with Panasonics (HMC40 and TM700) and more recently, with the Canon 60D.

For a layer or two, Vegas 10 is just dandy on my PC (AMD 1090T x6@3.2GHz, 16GB DRAM, AMD Radeon HD 6970 GPU), Vegas 11 generally a bit faster with the GPU acceleration. For anything more complex, I might convert to Cineform for editing. Though I’ve also used Sony MXF 4:2:2 at 50Mb/s, which is a built-in format on Vegas (Cineform Neo is a $100 extra). Another option is Avid DNxHD, which looks very nice, runs a bit larger than Cineform, but doesn’t render terribly fast.

-Dave

[Dave Haynie]

It’s not really an emulator. It’s an implementation of OpenCL that runs on the CPU, rather than running on the GPU. Sure, the CPU isn’t going to run as fast as a GPU. But it’s not emulating a GPU, it’s a legit OpenCL device.

Whether that’s useful or not, I’m not sure. I would think that basic titling functions would run just dandy with no GPU. But then again, if the NewBlue plug-in actually requires an OpenCL device, sounds like they really expect it to be needed. So maybe it’s just not too useful without the actual GPU.

-Dave

[Dave Haynie]

A couple of things… probably TMI, but the take-away: GPU isn’t always faster.

I’ve seen the Sony AVC option vanish in VP11 a couple of times. Usually ending VP11 and then starting it up again solves the problem.

Depending on your CPU and GPU, some things can actually run slower with the GPU enabled. The problem seems to be that in GPU mode, you’re going to get your work scheduled on the GPU, but there may not be enough work for the CPU to do. And in fact, oddly enough, on most GPU renders I’ve benchmarked, I see both CPU and GPU doing lots of waiting for things. Maybe it’s just my PCIe bus speed, I don’t know (planning to look into that, I’m still tweaking my system up to optimize for VP11). No matter what you do, there’s going to be a bottleneck somewhere in the system — we’re just used to it being the CPU most of the time.

Some real numbers for ya. Rendering to Main Concept MPEG-2 from a pretty straight forward AVCHD edit with just some contrast correction, I found Vegas 11 to be 20% SLOWER than Vegas 10 with GPU enabled. In this setup, I also found that preview was slower.. I saw 40fps with GPU, 57fps without (720p60 “PH” mode AVCHD source, HMC40 camcorder). However, compared to Vegas 10, the non-GPU Vegas 11 did 9% faster renders to MPEG-2.

On the other hand, rendering to AVC, I found Vegas 11 to run 13% faster than Vegas 10 without GPU, 26% faster with GPU, from the same project. Go figure.

Now, my system has an AMD1090T processor — a really fast i7 might peak at better than twice as fast. On the other hand, my GPU is an AMD HD6970, which I have found to be faster at just about everything, on my system, than the nVidia GTX570 I’ve also been testing. If you have a slower GPU and faster CPU, I think you’ll definitely find a larger number of senarios that render faster with the CPU only.

Best results so far as with lots of PNGs and less video. The published Sony VP11 Benchmark rendered to Sony AVC 118% faster on the HD6970, 52% faster on the GTX570, than non-GPU Vegas 11. Oddly, I saw an average CPU use of 58% and GPU use of 30% for the HD6970 render, 75% CPU and 50% GPU for the nVidia render… still trying to figure that one out.

-Dave

[Dave Haynie]

It’s not all that difficult to understand… just a good bit to take in all at once. I know the whole story, which I now relate…

Back in the early 1980s, a computer graphics display was basically just a chunk of visible memory. The CPU changed around some bytes in memory, you would see the changes on-screen.

As graphics got more complex, folks started to notice that CPUs weren’t all that good at manipulating graphics in certain ways. First on expensive CAD workstations, then on the Amiga series of computers, and ultimately everywhere, graphics chips got some of their own processing. The first of these were 2D operations: line drawing in hardware, bit-blitting (manipulation of 2, 3, or 4 different graphics planes in various ways), etc. While no one yet called these “GPUs”, that’s what they would eventually be dubbed: Graphics Processing Units.

Again first on workstations, such as those from Silicon Graphics Inc (SGI), designers started thinking about 3D graphics as well as 2D. In fact, it was in 1992 that SGI released a software function library called the Open Graphics Library (OpenGL). This allows a program to do 2D and 3D graphics operations without regard to the hardware. And it allows hardware to greatly accelerate these operations, making them many times faster than a CPU can do that same work.

Curiously, most of the companies that did 2D well on the PC failed to make the transition to 3D. The first really successful 3D graphics chips in PCs were the VooDoo series, from a company called 3dfx. These were only for game play, they didn’t do really high quality graphics, and they didn’t have 2D features.

There was a ton of competition for 3D, and the winners out of the 1990s are the same we know today: ATi (now part of AMD) and nVidia. In fact, it was nVidia that actually popularized the term “GPU”. And not coincidently, the complexity of GPUs has grown to rival that of CPUs, which does tend to limit the number of companies that can be successful at maintaining both performance and cost.

Originally, Graphics Processing Units had a pretty fixed internal architecture, which mirrored the graphics pipelines used in 3D graphics APIs, as defined by both OpenGL and Microsoft’s more recent Direct3D. And while there is still a good bit of hardware in a modern GPU that’s dedicated to graphics, some of these steps have been increasingly replaced by programmable “stream processors”, computational elements that can be programmed to do a variety of different computations.

This has lead to the idea of General Purpose GPU (GPGPU) computing. In short, if the GPU can be programmed to do 3D graphics 25x faster than my CPU, or decode MPEG-4 10x faster, why not use that power for other kinds of computing? Modern nVidia GPUs have up to 512 computing cores, modern AMD/ATi GPUs have over 1500 computing cores. This is fairly cheap processing power compared to the CPU, when it works well for the problem at-hand.

And so we have used these. Early attempts at this were actually coded directly “to the metal” on a GPU. The problem, of course, is that ATi and nVidia update their GPUs one a year or so, and you don’t want to have to rewrite your applications each time. Both companies realized this fairly early on, and so they devised libraries that would allow a program to use a GPU without knowning every detail of that GPU.

So nVidia launched a library called ompute Unified Device Architecture, or CUDA. This isn’t really just a library, it’s actually a whole methodology. You write a CUDA program using a specially designed C-compiler from nVidia. And as some here have seen, CUDA has evolved… there are two major revisions, 1.x and 2.x, which define some large scale features of the GPUs, but even things like how much of the C language you can use.

ATi/AMD started out with programming framework called Stream, which included their own GPGPU system, dubbed “Close to Metal”.. sometimes applications for this just said they supported “Streams”. But pretty early on, they adpoted the Open Compute Language (OpenCL) as their interface. OpenCL is also supported by a custom C compiler, but it’s architecture-independent. OpenCL runs on AMD processors, it’s supported within nVidia’s CUDA interface, and it’s even supported on x86 processors via libraries from Intel, AMD, and IBM. OpenCL is managed by the not-for-profit Khronos Group.

A third GPGPU interface is Microsoft’s Direct Compute API. This is included in any implementation of DirectX 11, but also runs on DirectX 10 era graphics processors. Microsoft doesn’t seem to have a great deal of support for this yet, but it’s another version of the same kind of thing: doing traditional CPU work much faster on a GPU.

All of these aim to let programmers use the GPU for “general purpose” work — the kind of stuff you do with a CPU, rather than something specific to graphics. That’s a good idea, as I’ll illustrate below: GPUs are wicked harcore performers.

A modern CPU is fast largely because it has multiple cores. My AMD 1090T has six CPU cores, and if you write you program to split a job up into six independent execution threads, it can actually go six times faster (competition for resources, like memory, may make it slower in practice, though with video rendering, we’re usually pretty close to maximum). An Intel i7 has up to six “hyperthreaded” cores… each core can appear as two separate CPUs, but it’s really one CPU with a double set of registers. With careful programming, the i7 can seem like 12 cores, but if things aren’t optimized, the hyperthreading gets even more complex. Looking at numbers, the peak performance of my AMD 1090T system is about 44 GFLOPS (billion floating point operations per second). The Core i7 980XE can deliver a peak of 109 GFLOPS.

The Sony PS3 is fast in part because it has one dual-core PowerPC CPU, but six 128-bit Stream Processing Engines (SPEs…actually seven, but one is disabled to increase yield). Each SPE can crank out 25.6 GFLOPS, so that’s 153.6 GFLOPS (billion floating point operations per second)… not bad for a $200 game console (of course, it has a GPU that can go even faster, for GPU-related work). But actually taking advantage of these SPEs is an even more complex problem. The programmer doesn’t have to worry too much about scheduling work to each core on a PC’s CPU. But they have to very carefully schedule work between the PS3’s SPEs to maximize performance.

GPUs are crazy fast, at least in theory. I’m back to using the AMD HD6970 in my system. This GPU is capable of a peak computation of 2.7 TFLOPS (trillion floating point operations per second)… yowza! But it’s using 1536 stream processors to deliver this performance. If you could figure out to use all of that, that’s almost 25x faster than the i7, over 17x the performance of a PS3, and a whopping 61x faster than my system’s CPU. The problem, of course, is tapping that performance.

-Dave

[Dave Haynie]

I think you mis-understood my point.

Anything that’s asking for OpenCL isn’t really asking for a GPU, it’s asking for an OpenCL device. Yes, that’s usually a GPU. But AMD has an OpenCL driver that runs, much slower, on your CPU.

Certainly many things that require OpenCL are likely to want the performance of a GPU. It’s understandable… my CPU has six processing cores, my GPU has more than 1500 — it’s bound to do some kinds of processing much faster. But I rather doubt that everything the NewBlue Titler does is absolutely dependent on GPU performance.

Anyway, the AMD OpenCL SDK supports both x86 CPU (AMD or Intel) and AMD GPUs. Get it here

-Dave