I am not sure. If the hardware is doing the render, then wouldn't the quality be based on the hardware?

There is a difference in the quality of video display cards, depending upon the chipset, hardware and quality of manufacturing, so I would think the same about a video card being used for rendering. Or else, why would there be such a difference in price?

Just asking though, because I really dont' know.

Dave T2

I don't have any real world experience of this however I cannot see any reason why it will be any different.
A lot of CGI apps use the GPU and the quality is dependant on the quality of the algorithms implemented in the GPU. They also offer the option of using software only rendering for the final render. These apps are nothing like Vegas, they're using the power of the GPU to do tasks like rasterising, shading etc, etc. They're using what the GPU is mainly focussed on, playing games or rendering 3D solids.

Vegas is using the processing power of the GPU as a general purpose number cruncher through OpenCL, much of the power of the GPU is not used, not the fault of how SCS have used it, just that there's not much use for a shader etc when working with video. Various other apps make use of the GPU in this way such as Folding At Home etc. Because the same code is running in different silicon should mean there is zero difference in the quality of the rendered output. The only thing I'm less confident about saying this for is the new NB Titler, quite a few 3D text apps and plugins do use the GPU to rasterize 3D text, add textures etc.

Bob.

So OpenCL allows you to use the graphics card as a number cruncher. (here again, not arguing but discussing). I see that some video cards have several cores vs. your normal cpu which has maybe 4 or 8 cores. Is OpenCL stricting using those cores for the math, or are there preset functions in the cores that are graphic oriented that the computer is using.

Just trying to understand.

Dave T2

"Is OpenCL stricting using those cores for the math, or are there preset functions in the cores that are graphic oriented that the computer is using."

As far as I know the answer is maths only..
OpenCL is Open Compute Language.
You want graphics functions then you use OpenGL, you want audio functions you use OpenAL.
From the Kronos website:

OpenCL (Open Computing Language) is the first open, royalty-free standard for general-purpose parallel programming of heterogeneous systems. OpenCL provides a uniform programming environment for software developers to write efficient, portable code for high-performance compute servers, desktop computer systems and handheld devices using a diverse mix of multi-core CPUs, GPUs, Cell-type architectures and other parallel processors such as DSPs.

By comparison OpenGL has this to say for itself from the OpenGL.org website::

OpenGL is the premier environment for developing portable, interactive 2D and 3D graphics applications. Since its introduction in 1992, OpenGL has become the industry's most widely used and supported 2D and 3D graphics application programming interface (API), bringing thousands of applications to a wide variety of computer platforms. OpenGL fosters innovation and speeds application development by incorporating a broad set of rendering, texture mapping, special effects, and other powerful visualization functions. Developers can leverage the power of OpenGL across all popular desktop and workstation platforms, ensuring wide application deployment.

Bob.

So in theory, a device could be made for rendering that was not actually a graphics card. It would just need to be OpenCL and have numerous cores. right?

Or a processor could do this if designed for this?

Dave T2

No AFAIK, as it remains digital, and (eg) 3+3=6 no matter which calculator you use. Unless the alogithmns are totally different, instead of essentially same code but different compiler.


geoff

I think the OP's question is quite valid, and I think it is quite possible that there could be a difference in quality.

Think about all the other threads, in this forum and elsewhere, about the quality of one DV or MPEG-2 or AVC encoder vs. another one. With the same content and the same bitrate, each encoder can produce fantastically different quality results.

The underlying assumption in the previous posts is that Vegas is just passing the same code to the GPU that it passes to the CPU and simply asking the engine to turn the crank. However, since the instruction sets are quite different, it is possible that there might be differences in the algorithms. This in turn might result in different quality.

The easiest way to figure this out is to do a test. Render using a format that definitely uses the GPU (e.g., AVC). Use a low to medium bitrate. Pick some video that has lots of motion and lots of contrast. My favorite is a basketball game. The camera panning across all those lines on the court, coupled with the players and the ball moving does a great job of stressing the motion part of an encoder. It would also be useful to encode some blue sky, especially if the bitrate is low. This often causes long GOP encodes to block and strobe.

Put the results back on the Vegas timeline and go back and forth (A/B) between the two encodes, while looking on a really large monitor. You can also do a difference square between the two tracks, but I've never found that useful for much of anything, even though others often recommend this to find differences.

Or a processor could do this if designed for this?

Oh, the processor can do it already. See Intel OpenCL and AMD OpenCL for their respective processors.

The problem is, Vegas only supports OpenCL on GPU devices. It could support the CPU devices but does not. On my computer I have the NVIDIA, Intel and AMD OpenCL installed, but Vegas only shows the NVIDIA in the options (other software gives me a choice). I’m sure it would also show the AMD OpenCL if I had an ATI GPU, which I do not have. And I have no idea why they chose not to support the CPU OpenCL when it is installed on the system. It does not matter much to me since I have a GPU, but I’m sure it would be nice for people who do not have a supported GPU in their system.

From the software programming perspective, it makes no difference whether there is a GPU or a CPU version of OpenCL. Of course, the CPU version is slower than the GPU version. But it supports all processor cores. Perhaps people who would like Vegas to support the CPU OpenCL should let SCS know in no uncertain terms that they want Vegas to support the CPU versions of OpenCL, too.

That said, it is conceivable that Vegas does support it but only shows the GPU if you have a GPU. Since I have a GPU, I have no way of testing that possibility. You may want to download the Intel OpenCL if you have an Intel CPU, or the AMD version if you have an AMD CPU, and see if Vegas allows you to choose it in the Options dialog (and let us know either way). If not, as I said, ask SCS to support it.

No AFAIK, as it remains digital, and (eg) 3+3=6 no matter which calculator you use.

If you stick to integers, that is true. If you go to floating point math, not all GPUs are as precise as your CPU. And when it comes to things like sines and cosines, they are really not very good at all.

There is only so much you can put on silicon of a certain size. If you have just 4 cores, you can have all the precision you need. If you have hundreds of cores, something has to go. The Intel (and AMD) CPUs internally use 80 bits of precision in their floating point calculations. They then round off the result to 32 bits or 64 bits of precision, so any round off-error only happens at the end of the calculations.

GPUs originally only supported 16 bits of FP precision. The newer ones support 32 bits, and some even 64 bits, though many actually calculate in 32 bits and then copy the result to a 64-bit register. None use 80 bits internally. So, the round-off error happens with each operation and, therefore, the final result is not as precise as with the CPU.

Now, in video editing this probably does not matter that much as, ultimately, we convert the results to integers, so the difference may be minimal, and visually undetectable anyway.

The Fermi GPUs are much more precise than the original Tesla devices (which may be why Vegas does not support them). But they are still not as precise as the CPU. But, as I said, chances are you will not be able to tell the difference visually. Especially if you use lossy codecs, such as MPEG or MP4, where you throw a lot of the precision away anyway.

@ RedPrince

I install the Intel openCL on a laptop computer w/o compatible GPU.
Video processing in preference can't turn be on BUT for rendering mainconcept, under system tab, "check GPU", OpenCL available.
Unfortunaltely, it doesn't work. I have the "unknown reason" error when I start rendering...
More interesting: Sony AVC and Sony MXF both disappear of the render option...
After uninstalling the Intel openCL, sony AVC & Sony MXF were back on the render option.

Johnmeyer probably expressed it better that I could.

When I encode to Mainconcept MPEG software, I am getting a "formula" to create an MPEG. IF I use Pegasys TMPGEnc to encode, I get a different "formula". So if I use a video card to encode the MPEG, is it using any of the formulas built into the videocard? Remembering that video cards have MPEG encoders/decoders built-in in order to allow better playback speeds and capabilities.

Again, I am asking because I know there is a difference in video devices such as Blackmagic and Aja Kona cards. Early Avids used proprietary hardware to allow them to play back uncompressed video on extremely slow Mac and PC computers. The hardware, in these examples completely control the quality of the video.

So I guess I am trying to figure out what role does the video card play in the rendering process. If it is just providing math functions, then how can they make a video card with 256 cores for computing cheaper than a processor with 4 or 8 if the quality of the processing is equal?

Thanks again for responses. Always willing to learn and figure out where my money is best spent.

Dave T2

Okay I will take a crack at this.

Stream processors in GPUs are relatively simple processors that perform a single operation to a stream of data without needing to communicate or synchronize with other stream processors. They are useful for computing where the data is computed in parallel, like video where one pixels's value doesn't generally depend on another.

CPU's are a more general type of computation unit that can not only carry out a variety of instructions but communicate with each other and handle inter-dependencies among data. Out of order instructions, branch predictions, etc...

Imagine you needed to perform 50 billion adds, then divides, then multiplies, then subtracts. And you had 1000 people to help you. You could break up your stream processors (people) into one group of 250 to do the adds, one group of 250 to do the divides, one group to to multiplies and one group for the subtracts. Since all of the operations can commence in parallel you can "stream" 250 operations in parallel at a time and since each person (stream processor) is only doing one compute they could do it very quickly. You would have 250 way parallel data crunching with 4 deep computing streams. The stream processors can be quickly programmed by the software using them to arrange them into an efficient way to handle the data at hand.

On the other hand imagine you have to do certain math to those numbers but the results of one were needed for another somewhere else in the list and all those dependencies changed all the time. Then you need a smart central "brain" to store values, remember where they were, pull them up when needed (registers), try to guess what operation should be done next (branch prediction), communicate with the other brains (CPU's) and coordinate the work, etc.. much more complicated problem requiring much smarter CPUs.

Finally the reason the GPU and CPU encode should be the same if the software driving them is the same is that the work being done is the same in both cases, only the manner it is being carried out differs. Hardware encoders by definition are programmed to ONLY do a couple specific functions. They are generally very fast at what they do but can't be altered much.

@GJeffrey:

Thanks for checking it and reporting back. Now we know that, sadly, Vegas does not support the CPU OpenCL at this time.

"How is the Quality of the rendering compared to software only render? I can't imagine that all video cards are equal in their hardware, but I haven't seen anyone mention quality, just speed."

FWIW, my understanding is that with something like OpenCL, ideally you're just using additional hardware resources to do the same computations, i.e. do the same encode with a dual core, 4 core, 8 core CPU etc. & the results should be identical -- you just get them faster. When the goal is to increase speed as much as possible however, you wind up compromising... Often the basic code is biased towards speed vs. quality, whether you're talking graphics drivers or the encoder. Further, graphics cards have their own optimizations, depending on brand/model, & if the [OpenCL] code takes advantage of those you're likely to see the effects of shortcuts made for greater speed.

Long story short, what that translates into is GPU assisted quality varies depending on the team(s) that coded the app & the team that coded the graphics drivers, & how many compromises each made. Actual test comparisons are few & far between, but there was one linked from the videohelp home page that's instructive... they didn't use the apps for encoding that I [& maybe most here] would use, but it shows how features might be enabled or not, & the resulting quality loss.

Also bear in mind that there are quite a few inefficiencies that can limit OpenCL hardware assist, from disk read/write times to bus bandwidth issues to just plain transferring data from the app running in PC hardware to the graphics hardware & back. Of the encoders I regularly use, those with the most GPU usage also show the least CPU %, so a good deal of what I gain from the GPU I lose from not fully utilizing the CPU. In theory I think win8 will be better at that sort of thing with better memory etc. mgmt.

As far as different graphics hardware goes, if for example an app just uses OpenCL for crunching numbers, then cards with more powerful GPUs &/or greater bandwidth win. If/when apps use card optimizations, higher priced cards generally have more available, so more are used -- that would tend to increase speed, but not necessarily quality.

"So if I use a video card to encode the MPEG, is it using any of the formulas built into the videocard? Remembering that video cards have MPEG encoders/decoders built-in in order to allow better playback speeds and capabilities."

Well yes, video cards do have hardware in them to decode / encode video. nVidia has its "Purevideo" for example. OpenCL cannot access that hardware, Vegas does not use it, OpenGL the same. Nothing "open" is at all likely to use it because it is nVidia specific.

"If it is just providing math functions, then how can they make a video card with 256 cores for computing cheaper than a processor with 4 or 8 if the quality of the processing is equal?"

The only time the "quality" of the processing is different when it comes to computation function is when there's a flaw in the silicon. That has happened, Intel made a boo boo in the silicon of the 486 and some financial institutions lost large sums of money because of it. The only exception to this general rule occurs in restaurants where Bistromathematics is used to compute the bill :)

Of course as John Meyer points out different encoders and decoders may have different quality outcomes. This is because they use different algorithms, may or may not implement all of the codec specs, may ditch quality for speed, a whole raft of reasons.
Some may also use hardware acceleration, something that Vegas does not support despite a decade of user requests for it to do so. The "GPU acceleration" implemented in V11 is not "hardware acceleration" as the term is used in this industry. Hardware acceleration is nVidia's PureVideo, Matrox's various boxes and what exists on Black Magic Designs cards that can do real time compositing of overlays. Vegas does not use any of this.

"If it is just providing math functions, then how can they make a video card with 256 cores for computing cheaper than a processor with 4 or 8 if the quality of the processing is equal?"

There's a MASSIVE difference between the cores on the GPU and the CPU plus a MASSIVE difference between the functional units around the cores in the silicon.

The use of the word "quality" with the word "computation" is absurd unless you want to wander off into the realm of metaphysics or philosophy and even there most would consider it absurd. Computation goes to logic and reason and this universe would be in serious trouble if there was varying levels of quality attached to logic.


Where there is a quality issue is with mechanisms used to solve vast and complex problems e.g. weather prediction. This is the realm of computer modelling. In general the maths is quite simple, you just need to do the same simple caculations an almost infinite number of times to predict what the weather will do in the next second and 3,600 infinite times to predict what it will do in the next hour. Clearly this isn't much use, using the entire computational power of the planet for a decade to predict the weather in the next hour will give an accurate answer that is useless. By reducing the accuracy, by using larger chunks in the model less calculations are required. Also because the same simple maths is repeated millions of time the calculations are very amenable to being split over computational units. A system with a million simple cores can be bought to bear on the problem. Because that system can get the computations done in a more timely manner smaller chunks can be used, a more accurate prediction can be made and it can be correctly said that the model is more accurate and one could say it has higher quality. Still, each one of the trillions of computations gives the same answer, 2+2 still gives 4.

Bob.