What is the performance hit in Virtualbox?

[shawnlau]

I've recently been experimenting with VirtualBox and Ubuntu. I'm running Virtualbox on a Windows 7 computer, i7 quad core , 8 gigs of ram, 1 gb Radeon 5770 HD video card.

I typically set up my virtual computer with 5.5 gigs of ram and 128 mb of video ram (max?). I've found some very nice Linux video editing software. Now I'm wondering if it wouldn't be worthwhile to set up a Linux partition and run a dual boot system. I started looking around for information on this, and believe it or not it led me back here. "Before doing a dual boot try Viritualbox etc.."

Would I see a significant boost in performance if I ran Ubuntu from a Linux partition as opposed to a virtualbox? I am almost positive there would have to be some, but would it be noticeable in video editing and rendering? Also how much would disk access improve?

Also, I've set the virtual computer to have 4 cpu's. I should do that for a quad core , eh?

[Sasquatch]

You can't really express overhead in numbers, as it depends on the hardware, the purpose of the VM and some other variables. As for your video editing, it really depends if the software makes use of all the hardware, video card included. A VM does not have access to the video hardware.

The advise you got for running it through VB is essentially to learn Linux, how it works and such. This may be slower, but it prevents you to break your current set up. You also get a good feel for the software and it's potential (speed and all). I doubt you would see a great difference in speed when the software is all CPU based. You will notice great differences when it takes advantage of your video card. That will come later, when you learn more about the software (if it can at all and such).

With a quad core system, it's best to leave one for the Host, so the max you give is 3. If you don't, then the VM may overtake your Host and lock it. This does mean that the software is unable to utilize the full system if it's multi-core capable. It's worth it though, as it prevents hard lockups.

[shawnlau]

You can't really express overhead in numbers, as it depends on the hardware, the purpose of the VM and some other variables. As for your video editing, it really depends if the software makes use of all the hardware, video card included. A VM does not have access to the video hardware.

The advise you got for running it through VB is essentially to learn Linux, how it works and such. This may be slower, but it prevents you to break your current set up. You also get a good feel for the software and it's potential (speed and all). I doubt you would see a great difference in speed when the software is all CPU based. You will notice great differences when it takes advantage of your video card. That will come later, when you learn more about the software (if it can at all and such).

With a quad core system, it's best to leave one for the Host, so the max you give is 3. If you don't, then the VM may overtake your Host and lock it. This does mean that the software is unable to utilize the full system if it's multi-core capable. It's worth it though, as it prevents hard lockups.

Thanks for the information.

[crash0veride]

A VM does not have access to the video hardware

With the GA loaded in a VBox guest, the underlying GFX HW is being multiplexed and OpenGL is HW accelerated within the guest.

[sej7278]

With the GA loaded in a VBox guest, the underlying GFX HW is being multiplexed and OpenGL is HW accelerated within the guest.

yeah good luck with that on linux guests - 2d is not accelerated at all and 3d in 90% of distro's isn't either.

for video work i'd definitely say dual boot, as you'll get decent graphics performance, and more importantly decent disk performance, which you don't really get with virtualbox.

plus, no firewire support.....

[crash0veride]

yeah good luck with that on linux guests - 2d is not accelerated at all and 3d in 90% of distro's isn't either

2D is handled differently in Linux than windows (directdraw). VBox does not need to support 2D on Linux and need only support 3D for a reason.

In Linux if your application makes a 2D OGL instruction call and your X-server is hooking in mesa (EG: no Nvidia, AMD fglrx driver, etc driver) things are then being software rendered as expected (CPU not GPU)
Same applies should you make a 3D OGL instruction call and mesa supports CPU rendering of that function.

However should you then have an accelerated driver loaded (Enter Nvidia or AMD fglrx driver) and your application makes either a 2D OR 3D OGL instruction call then GLX is utilized and the function is then hardware accelerated via the driver.
In the case of VBox this would occur via the vboxvideo paravirtual driver, with the end rendering device being your underlying GFX HW and driver on your host.

With the vboxvideo driver however it does support at current OGL 2.1+. What this translates to is that so long as your application is making calls compliant to that OGL spec they will be hardware accelerated. If you are for instance making a OGL 3.x instruction call it will either not be executed (if no SW render support) or will be software rendered (if SW render support).

The gist of this boiled down in a more simple form is that 2D/3D in linux as pertains to VBox means that your 2D OGL calls are only HW accelerated when using VBox 3D, EG: vboxvideo. The VBox 2D feature is for windows guests and directdraw acceleration (not direct3d).

I have numerous workstations here in my development labs with our Linux Operating system and which contain muitple Nvida/AMD boards. These workstations are running multiple Linux guests in which we are virtualizing and running our 2D/3D OGL accelerated medical applications

At the end of the day the best thing you can do is run your application and determine if this particular sceanario suits your intended use case, and performance targets.

[sej7278]

so despite the fact that virtualbox says 2d acceleration is for windows guests only, and under most linux guests even compiz doesn't work - that 2d and 3d are actually hardware accelerated?

[crash0veride]

Provided that you are using vboxvideo and the vbox chromium implementation AND your application code is making OGL instruction calls that are handled by the implementation yes.

Take for example GL_EXT_framebuffer_object (see attached vbglxinfo) --> (http://www.opengl.org/wiki/GL_EXT_framebuffer_object)

Note that if the application code were to create a FBO (I am pretty sure compiz uses FBO for some of it's visual effects) and use for example GL_TEXTURE_2D that call would have then been caught by GLX --> vboxvideo and handed off to the underlying host GFX and driver for rendering.

I our case medical images for example are mostly all 2D in nature and generally 8bit signed short data. In our case we render that data using GL_ARB_fragment_shader to render it.

So the gist here is that if the application makes the appropriate hardware accelerated 2D or 3D instruction calls then it should be hardware accelerated by the VirtualBox paravirtual video driver.

A caveat to the above is even when an OGL call is made for which should have been accelerated but was not there is some method to that madness. That comes in the form OGL extension deprecation. Even if you use for example GL_EXT_draw_range_elements --> (http://www.opengl.org/registry/specs/EX ... ements.txt) it instead hits the hosts CPU instead of the hosts GPU. Why this happens is the fact that the extension was deprecated, and was replaced by a newer method in forward versions of OGL. Nvidia and AMD (mostly... don't get me going down that path) continue to support older OGL functionality. This is done to optimize drivers and rendering piplines of newer hardware. When a function is treated as such it is instead software emulated and the call is executed on the cpu instead.

One way we check all this is with profiling tools from Nvidia or AMD wherein we can step through the application code during runtime and see what is/is not being hardware acceleration. We see what gets executed by the GPU and what gets executed by the CPU.

[Sasquatch]

Nice discussion there, but what matters for video encoding is not 3D acceleration or 2D acceleration. What matters is hardware decoding of HD video. nVidia calls it VDPAU. No idea what ATi calls it, but the idea is the same. Currently, a VM, even a Windows one with 2D acceleration, is unable to transfer the HD video decoding to the video hardware.
If the VM is somehow able to use hardware decoding features of the video hardware, there is a major bug in VB for it's checks, because my video card is unable to use VDPAU (too old), yet I can enable 3D and 2D acceleration. I have no idea if it actually works (the 2D thing), but that's beside the point.

So enough talk about OpenGL inside a VM, that's not the goal of the TS here.

[crash0veride]

Without going to gross detail, OpenGL is relevent here as Nvidia VDPAU uses OpenGL under the hood to accomplish it's hardware accelerated rendering.
VDPAU methods such as:
vdp_use_output_surface_as_texture
vdp_render_output_surface_into_pixmap
Those for example under the hood will use a OGL 3.x vertex/fragment shader to actually acomplish the rendering. As such you are correct in the fact that vboxvideo OGL layer does not support what VDPAU requires.

ATI's implementation is called Avivo, and will have the same issues as Nvidia.

[shawnlau]

Without going to gross detail, OpenGL is relevent here as Nvidia VDPAU uses OpenGL under the hood to accomplish it's hardware accelerated rendering.
VDPAU methods such as:
vdp_use_output_surface_as_texture
vdp_render_output_surface_into_pixmap
Those for example under the hood will use a OGL 3.x vertex/fragment shader to actually acomplish the rendering. As such you are correct in the fact that vboxvideo OGL layer does not support what VDPAU requires.

ATI's implementation is called Avivo, and will have the same issues as Nvidia.

So if one is using a lot of effects in editing they are going to notice the performance hits as opposed to those who cut, pasting, and dubbing?

[crash0veride]

Provided those filters or effects are actually making use of GPU hardware acceleration you would then see some measure of performance penalty. In the absence of proper GPU acceleration it would revert to software rendering. Correct me if I am wrong but I am not aware of a heck of lot of video encoders or effect filters that actually use the GPU during encoding/editing, etc. This functionality is more focused in on the area of accelerating playback. Example: playback of HD video (EG: h.264, flash, etc). There is some of the newer stuff using CUDA or OpenCL, but there we have a whole different ball game.

I use x264 and avisynth in VBox VM's and have done a bit of performance comparision as it pertains to encode operations and the perfomance penalty for Native vs Virtual was less than 1% difference.