VirtualBox with OpenCL Runtime CPU only?

Get answers to your questions about color grading, editing and finishing with DaVinci Resolve.
  • Author
  • Message


  • Posts: 2
  • Joined: Mon Mar 05, 2018 8:48 pm
  • Real Name: Allen Stevens

VirtualBox with OpenCL Runtime CPU only?

PostMon Mar 05, 2018 9:39 pm

A bit of a strange question... I suppose.
I have a pretty beef machine 32g, intel 8700k, Nvidia 1080.

My wife wants to do some video editing, but it takes her hours and hours, and I don't want to tie up my machine.

So I thought, hey why not just install virtualbox, put resolve on that, and we're good to go...

# Thus begins my journey.

So I get it installed, I get the OpenCL run-time installed from Intel, I can even run several OpenCL tests.

I also have integrated graphics, as well as my NVidia... I'm 100% confident it would work fine on my 'actual' machine. But getting it to run on a virtual box, so i can just leave that running and have my wife attach to it, to do processing. :( No CL hardware, blah blah blah

Same ol' story, even if I can get Intel drivers on, CPU-Z sees the support, etc etc. I have all the virtualization support enabled. I ran some OpenCL hardware support tests, that see the CPU and say it's supported. But Resolve will not see the CPU as a valid 'video card' for openCL support.

Any super secret nerd knobs that I can turn, to get this thing running with the OpenCL run-time?

If it runs like garbage, I can just abandon my efforts and try something else. But I really just wanna to see if I can get it running at all.
User avatar

Cary Knoop

  • Posts: 317
  • Joined: Sun Mar 12, 2017 6:35 pm
  • Location: Newark, CA USA

Re: VirtualBox with OpenCL Runtime CPU only?

PostTue Mar 06, 2018 12:30 am

I would not do it, too many potential issues and gotchas.

But if you want to try it did you try PCI Passthrough enabled?


  • Posts: 2
  • Joined: Mon Mar 05, 2018 8:48 pm
  • Real Name: Allen Stevens

Re: VirtualBox with OpenCL Runtime CPU only?

PostTue Mar 06, 2018 1:06 am

PCI passthru isn't supported on windows boxes with virtualbox that I can tell.

That said, I did some some instructions on getting that working on linux, and ensured all my bios settings were ready for it.

I'll kick open another linux box, and attempt that next.

But, no, have not tried it on windows, because I can't get it to go.
User avatar

David Franzo

  • Posts: 181
  • Joined: Wed Jun 26, 2013 4:08 am
  • Location: New York

Re: VirtualBox with OpenCL Runtime CPU only?

PostFri Mar 09, 2018 8:11 pm

So she will be using a remote desktop console to control the VM running on another computer? You would still need to run an SDI and audio cable to wherever she is sitting, and even if you get OpenCL working I doubt the performance would be lag-free with smooth playback. You also need to be able to attach a physical storage device to the VM, which takes a lot of effort to do in VirtualBox as you need to use the CLI and a bit of coding to allow for it.

Martin Schitter

  • Posts: 575
  • Joined: Tue Apr 28, 2015 10:41 pm

Re: VirtualBox with OpenCL Runtime CPU only?

PostSat Mar 10, 2018 3:04 am

i'm not sure, if i really got the original question?
are you more interested in a kind of remote access to your workstation ('so i can just leave that running and have my wife attach to it, to do processing') or did you indeed ask about virtualization requirements on the same machine?

concerning remote access, i woudn't expect satisfaying results. video editing is a task, which definitely doesn't work very well over any kind of remote desktop sharing solution. even the best accelerated approaches, which at least transfer e.g. a youtube video in a browser in a special way, to optimize the compression for movie related parts of the screen and support the necessary remote audio and USB access, are not suitable for NLE work. the latencies are much to high for any serious creative work.

if you just need a one way connection to pipe video streams over your local computer network in reasonable quality instead typical AV cabling, to make use of it somewhere else as live video input or just as remote display on another machine close to yours, that's a different story. this kind of tasks can be realized quite easy e.g. by utilizing NDI.

virtualization an the same local machine is again a different topic. there are two different main obstacles to solve in this case: a.) you have to support all the needed drawing capabilities resp. APIs on the virtualized guest system and b.) you often need more capable direct GPGPU access for realtime video processing.

a.) doesn't sound exceptional, but even this elementary support isn't always given. e.g. using microsofts remote desktop protocol to display the actual output of your virtual machine or a second graphical desktop of your native system, usually doesn't initialize/share the necessary OpenGL drawing contexts utilized by many video applications. virtualbox, although its otherwise a very nice and user friendly cross platform solution, has only minimal support for this kind of elementary graphic API simulation resp. 2D/3D output acceleration. i don't know, if it's really enough, to satisfy resolves requirements? it's in fact a very challenging topic. but for example the developers of LookingGlass could recently demonstrate, that drawing over this kind of indirection on the hosts display of the virtualization can be actually realized with less latency than on a physical connected screen direct attached a GPU utilized by the guest operating system. although this may look more important to stupid hardcore gamers than for serious work on a first sight, it also affects important questions, which are unavoidable also in case of more general sandboxing and security related needs.

b.) more effective GPU sharing is still in a very unsatisfying and fragmented shape. there are interesting rudiments available, like nvidias vGPU -- which only works for their quite expensive data center products -- or intels GVT, but nothing works really satisfying according to my experience. it's really a pity, because this deficiencies accompanied they whole success and massive practical spread of virtualization techniques over the last decade in a significant limiting way. it's still not solved, although hardware and paravirtualized solutions get more and more replaced by less resource hungry types of application level virtualization resp. containers. on this level it has become much easier to share GPUs (e.g. by using nvidia-docker) between rather isolated instances of the same kind of operating system much easier. but i don't think, this will help you in your particular case.

PCI-forwarding resp. pass trough of an additional physical GPU to a virtual machine, is perhaps the most satisfaying solution. it's not a kind of virtualization in the strict sense, but it really works well with nearly any hardware and cross operating system combination, as long as you use an adequate powerful virtualization software. but even in this case you have to be aware of some nasty technical details. you usually have to blacklist the particular video card on the host side, because it may become initialized and blocked by the host operating system otherwise. and another requirement concerns the way, how the operating system boots on the host and guest side. you usually have to utilize more recent EFI boot conventions, because otherwise you'll get again into troubles because of some legacy BIOS video access mysteries. this is especially important for resolve, because its really unbelievable old fashioned and inferior resolve linux installation disk does only support the insufficient legacy BIOS boot variant, although real CentOS installation media of course supports both alternatives from time out of mind for good reasons.

but you also asked about software based GPU emulation. yes, that's indeed another possiblity. there are some software solutions, like pocl around, which can handle this kind of emulation and translations between different typical GPU accelerated access conventions. in practice. it often makes more sense, to utilize just their translation capabilities or use them only for compatibility checks, because pure CPU emulation of GPU features are hardly performance wise satisfactory, but beside this restraints, they are quite powerful and feature complete. there are also interesting solutions around, which are more focused on remote GPU access and clustering of GPGPU resources. although, you may not have the necessary high-end connection infrastructure in your private house, it's indeed one of the techniques, to push the actual limits in video processing to further limits. rCUDA is a well know solution of this kind (and if i'm not wrong, they even demonstrated their impressive computing capabilities for the particular case of video processing together with SGO and mellanox a few years ago).

sure -- here in this forum resp. in a rather conservative ambient dominated by traditional broadcast engineers, you will just arouse laughter, if you speak about this kind of more innovative use of nowadays computing capabilities. but video production and it's software is only a quite small and objective unimportant territory in a bigger scale of applied informatics. if you look around, whats going on in the neighborhood -- e.g. in the field of machine learning (where they often process huge amounts of data in pipelines that look strikingly similar to typical video related stuff; it's just more associated to the abstract newspeak term 'tensors' by most of us, not with simple arrays of pixel data) --, this kind of clustering and highly optimized shared GPU access has become quite common.

Return to DaVinci Resolve

Who is online

Users browsing this forum: Dermot Shane, Michael Kropfberger, Philippe GALLE and 19 guests