[vbox-dev] Monitor count limitations
Rūdolfs Bundulis
rudolfs.bundulis at gmail.com
Wed Aug 27 17:54:07 GMT 2014
Hi,
I just checked that the Xubuntu machine does not complain about VRAM if 25
monitors are set and it show that the required amount of VRAM is 223 just
as you said. So that means that I get a warning for Windows7 since the
offscreen surfaces are calculated in.
Best Regards,
Rudolfs Bundulis
2014-08-27 20:46 GMT+03:00 Rūdolfs Bundulis <rudolfs.bundulis at gmail.com>:
> Hi,
>
> > Which guest OS are you using? Which driver did you install (for those
> > OSes which allow selecting)?
> I am running Windows 7, but I seems that I also have a Xubuntu 14 machine
> and I could set up a Windows XP machine to see if that fits better. I
> installed the default guest additions package on both Windows 7 and
> Xubuntu, on Windows7 i checked the Direct3D checkbox.
>
> > 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.
>
> Ok that could explain why I don't get the full hd resolutions, I could be
> just simply running out of VRAM. VboxHeadless wont help, I already have a
> console app that starts the VM using the COM API and injects implementation
> for the IFramebuffer interfaces in each monitor and I capture the display
> surfaces. So it seems that 25 full hd displays on Windows is not possible.
>
> Best Regards,
> Rudolfs Bundulis
>
>
>
> 2014-08-27 20:11 GMT+03:00 Klaus Espenlaub <klaus.espenlaub at oracle.com>:
>
> 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
>> unexpected.
>>
>> > 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 :)
>>
>> Klaus
>>
>> > 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
>> >>
>> >
>>
>> _______________________________________________
>> vbox-dev mailing list
>> vbox-dev at virtualbox.org
>> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140827/93af7313/attachment.html>
More information about the vbox-dev
mailing list