[vbox-dev] Monitor count limitations

Klaus Espenlaub klaus.espenlaub at oracle.com
Wed Aug 27 17:11:41 UTC 2014

On 27.08.2014 18:38, Rūdolfs Bundulis wrote:
> Hi Klaus,
> Thanks again for the fast response. Well, this is a university research
> project to build monitor walls without the underlying hardware, so I
> guess its reasonable that I am breaking some limits that should be
> normal in a normal use case.

As long as you're only going for high monitor counts, that's nothing 

> Regarding 3D, when I installed guest additions I checked the Direct3D
> box but I dont have the "Enable 3D acceleration" checkbox checked in
> the VirtualBox manager. Should I reinstall the guest additions without
> Direct3D?

Strange... I wonder why the GUI is so eager with insanely high VRAM 
proposals. It should only care about the checkbox, because if that's not 
set then there is no 3D, period.

 From what I remember, the "rule of thumb" for the absolute minimum VRAM 
size (in bytes) is (x*y*4+4096+1048576)*count. At least it was accurate 
with the X11 driver, and the GUI seems to agree. It seems the XPDM 
driver needs twice that much (because Windows needs one offscreen 
surface), and with the WDDM driver it needs thrice that much (two 
offscreen surfaces).

Which guest OS are you using? Which driver did you install (for those 
OSes which allow selecting)?

> And more important, is it actually possible to fit 25 full hd
> (1920x1080) framebuffers in the video ram if it is only 256mb inside
> virtualbox? I could try to recompile from sources with lets say 1GB if
> redefining the video memory macro does not break other stuff.

Barely... the above formula gives 223MB already, and if the Windows 
driver really need the mentioned amount of offscreen memory you'd run 
out of VRAM. I'd use VBoxHeadless to try this out actually, because it 
doesn't have any of those annoying safeguards to protect users from 
shooting themselves in the foot.

Increasing the VRAM size by recompiling will cause trouble, as it would 
need drastic changes to the memory layout (PCI memory hole, ...), and 
I'm quite sure that we looked at it and considered it too much effort. 
Everything is doable in the end, that's the good and bad thing about 
software :)


> Best Regards,
> Rudolfs Bundulis
> From: Klaus Espenlaub
> Sent: 2014.08.27. 19:05
> To: vbox-dev at virtualbox.org
> Subject: Re: [vbox-dev] Monitor count limitations
> Hi Rūdolfs,
> On 27.08.2014 16:49, Rūdolfs Bundulis wrote:
>> Hi,
>> I've run into some more issues with high monitor count on VirtualBox.
>> Basically when selecting 25 displays it complains that at least 600
>> something MB of VRAM is needed, but while the arrows in the display
>> number box allow to select more than 8 monitors, seems that i can't go
>> above 256 mb in VRAM. Is this a hard limitation? Since the COM API also
>> does not allow me to set more than that.
> Sounds like you have 3D enabled - then the GUI does a little too simple
> maths, extrapolating the necessary space beyond sanity. It's only a
> proposal, not a hard "must have". Don't think anyone tried to go to such
> extremes, because it's just nonsense to expect even basic 3D able to
> cope with so many screens.
> If you disable 3D then the requirements should be a lot lower, in the
> order of what's needed to represent the pixels.
> Yes, there is currently a hard limit of 256 MiB VRAM, and we didn't find
> cases where it was absolutely necessary to have more.
> Klaus
>> Best Regards,
>> Rudolfs Bundulis
>> 2014-06-18 13:41 GMT+03:00 Rūdolfs Bundulis <rudolfs.bundulis at gmail.com
>> <mailto:rudolfs.bundulis at gmail.com>>:
>>      Hi Klaus,
>>      Thanks a lot for the clarification. I thought the same that it was
>>      just a sanity limit, but in my case this is really needed. Then I
>>      guess will be able to do the same with the COM API, thanks a lot again.
>>      2014-06-18 13:13 GMT+03:00 Klaus Espenlaub
>>      <klaus.espenlaub at oracle.com <mailto:klaus.espenlaub at oracle.com>>:
>>          Hi Rūdolfs,
>>          On 18.06.2014 11:48, Rūdolfs Bundulis wrote:
>>           > Hi,
>>           >
>>           > I'm developing a system that needs to run a headless VM with
>>          a large
>>           > number of attached monitors - currently the GUI has the limit
>>          to set
>>           > maximum monitor count to 8, I didn't check the COM API myself
>>          but I
>>           > suspect that it will not allow me to set the count greater
>>          than 8, while
>>           > browsing the VirtualBox sources show that the internal C macro is
>>           > defined to 64:
>>           >
>>           > /* this should be in sync with monitorCount <xsd:maxInclusive
>>           > value="8"/> in
>>          src/VBox/Main/xml/VirtualBox-settings-common.xsd */
>>           > #define VBOX_VIDEO_MAX_SCREENS 64
>>          Looks to me that this comment is simply outdated. Nothing more,
>>          nothing
>>          less.
>>          Many limits can be listed with "VBoxManage list
>>          systemproperties", and
>>          it shows 64.
>>           > Is there really a need to limit the count to 8? If I change
>>          the xml
>>           > schema file and increase the count from 8 to 64 and recompile
>>          would
>>           > there be any actual limitations in the VirtualBox core?
>>          There is a constant conflict in the GUI between sanity (i.e.
>>          protecting
>>          users against their stupidity - you can't believe how many people
>>          believe that more is better, even if it's a giant waste of resources
>>          instead) and allowing expert users to go to the extreme. There are
>>          extremely few people out there who ever need to deal with more
>>          than 8
>>          monitors.
>>          In my quick test I could use the GUI to select 20 monitors -
>>          sure, the
>>          slider doesn't allow that, but one can enter the number or use the
>>          up/down arrows. This needs 256MB of VRAM, which this high number
>>          automatically unlocks.
>>          Klaus

More information about the vbox-dev mailing list