Two instances of BCC7 uprez in V10 = crashes!

Laurence wrote on 7/13/2012, 5:51 PM
Today I experienced multiple crashes in V10 of the exact same nature as I usually get in V11. What caused this might provide a little light on what is making V11 crash. I was uprezzing a video file to HD, and then uprezzing another with BCC7 uprez in order to overlay part of one clip over the rest of the other. With two instances of BCC7 uprez I was getting exactly the same sort of crashes that I have been experiencing in V11. When I deleted the second uprez layer the problems stopped.

This leads me to believe that what might be happening in V11 is that Vegas and it's plugins are fighting over the GPU resources, and that when several things are competing for the GPU, that that is what is causing the crashes. This would explain why mostly people with New Blue FX plugins are experiencing this, and why for some of us who use multiple plugins regularly the problems are constant, and for some of us who use minimal plugins, the problems are almost non-existent.

If this theory is correct, what might be happening is that in V10, it would take two instances of GPU accelerated plugins to cause the problem, but in V11, the acceleration of Vegas and the GPU accelerated plugin might already be enough to cause the crashes.

I still get crashes even when GPU acceleration is turned off in V11, but it may not be totally turning off.

All this could be a result of certain graphics drivers not being up to multitasking and not totally Vegas's fault.

Just a thought, not a certain theory by any means.

Comments

LoTN wrote on 7/14/2012, 4:17 PM
Hello Laurence,

When using V10 without any GPU I was getting crashes and freezes with BCC7.

Fact is that both BCC7 and the Vegas OFX host need a code review, optimisation and debugging. Callbacks raise memory violations, GUI and arg passing is so slooooow. Yet another example of the C++ legends and myths: OOP can be as bad as crappy C code but with the object paradigm complexity added over the top (overload ops, etc...).

My observations tell me that the x86 version is much stable but the smaller address space available for the process may prevent the use of plugins like timeflow. As you may expect, x64 is even worse.

In my humble opinion, GPU is not the root cause of what exists since the introduction of OFX. When using OFX, V10 is so "touchy" that I was often reverting to V9 when possible. GPU just worsens existing problems that lie into the grown old Vegas code.
farss wrote on 7/14/2012, 8:22 PM
"GPU just worsens existing problems that lie into the grown old Vegas code."

The VFW interface that still lies at the core of Vegas is so old the wonder is V11
works at all.


Bob.

Grazie wrote on 7/15/2012, 12:36 AM
Isn't there ANYBODY picking up what appears to be fundamental to all this?? - This is an NLE, I'd have thought that this is kinda "core" high level impact for a coding NLE projects would be writ large?

I am NOT a programmer, but that doesn't mean I can't see an "elephant in the room" - with OR without donning my Rose Tinted Glasses!

I enjoy working in Vegas Pro. And I also enjoy seeing the developments Vegas is attempting to go through. On my side I've invested in "the" PC as laid down by the specifications GRID. That doesn't also mean I'll put up with falsehoods, if that's what they are.

If what is being suggested then some copious amounts of "wake-up" coffee need to be brewed, consumed and quickly.

Grazie

LoTN wrote on 7/15/2012, 3:39 PM
farss:
The VFW interface that still lies at the core of Vegas is so old the wonder is V11 works at all.

VFW interface is just API function calls, this has little to do with the core code of Vegas even if it has been declared obsolete for a decade and frozen since that time. File I/O inherited from *nix and C are also used by Vegas while their specs are from the 70s. I'm sorry, there's no wonder.

Take any complex software that is thought, then designed and written during year Y, make it evolve into a rapidly changing world (OS, APIs, technical, etc..), at Y+10, or later, or a little before, the dev engineers will see the limit of the model and architecture they devised during its infancy. This is a very well known problem in software life cycle management. One day, the management will have to discuss the benefits and ROI of a complete or partial rewrite because bloated code maintenance costs are too high.

Some may argue that the use of OOP can dramatically settle that issue if using well designed classes and their associated methods to successfully achieve one of coder's Grail: complete code factorization. The usual practice tells the opposite because this is counter productive when performance and ease of maintenance comes into the math (same applies to RDBMS and Normal Forms from 4th to upper). Even today, there is inline assembly within C code and this observation is not based on some kernel parts.


grazie,

I am speaking about the innards of the beast, not how it looks, what it does or how its features have evolved. I have a serious doubt about the Sonic Foundry dev team having anticipated the integration of OpenMP or OpenCL into the core code of Vegas when they wrote it. Over the years, code gets old and this may raise difficulties when integrating new technologies.

V10+OFX has stability issues, adding new features to code that already crashes cannot fix it, it's even more problematic when it is related to parallel programming. During 3 decades of IT engineering, I never saw such a miracle but I may be wrong.