[vbox-dev] Monitor count limitations
Rūdolfs Bundulis
rudolfs.bundulis at gmail.com
Thu Aug 28 20:03:58 GMT 2014
Btw, here is a little demo of the 16 * 720p wall driven by virtualbox
https://www.youtube.com/watch?v=eFAATNofjHA&feature=youtu.be
2014-08-28 23:03 GMT+03:00 Rūdolfs Bundulis <rudolfs.bundulis at gmail.com>:
> Hi Klaus,
>
> > Was the available monitor hardware limiting you to 16? Because with 720p
> and the XPDM driver (which is usable with Win7, and I think still the
> default if you don't enable 3D in the guest additions installer) you should
> be able to run > with 5x5, too. Needs "only" 226MB for the framebuffers.
>
> Well, that is the thing, I don't have the 3D checkbox checked, guest
> Windows does not allow to enable Aero (so I can assume WDDM is not used?)
> but the memory bar still warns me when I go above 8 monitors (seems that it
> always calculates 3 surfaces. Is there any way to check if XPDM or WDDM is
> actually being used? I could then confirm and fallback to XPDM if that
> gives me more screens. What I saw in practice is that 7 monitors booted
> fine in Full HD, when I ran 8 my hint to use 1920x1080 was ignored and all
> 8 monitors got 1600x1200 resolution, increasing above 10 pushes the
> resolution down to 1400 x 1050 and so on until when booting with 25 Windows
> reports only one display at 800x600 (I guess it is simply an overkill for
> the VRAM). If I could verify if WDDM/XPDM is being used it would become
> more clear if I can go higher.
>
> > Another option might be using 15 or 16bpp in the guest *and* on the host
> (otherwise color format conversion is necessary, and this kills performance
> as VirtualBox uses the CPU for that). The GUI again is pessimistic and
> always ? > expects 24bpp (4 bytes, the packed format again is unbearably
> slow as it needs conversion), but the virtualizer would work just fine.
> This would fit into 248MB with 5x5 @1920x1080. Yes, the reduced color
> resolution sucks, it usually results in heavy color banding.
>
> One of the guys involved on our side also suggested this, but we are
> perofming live video encoding from the framebuffer, 32bpp is great since
> that can be fed directly to the encoder, anything else will have to be
> repacked which would not be feasable. Not sure, but since Xubuntu ran
> really slow, I have a theory that the offscreen surfaces could actually be
> very useful, since if X11 syncs every draw with the primary surface and
> locks it, and my software also needs to lock the surface for to at least
> copy the data, this could be the reason why Xubuntu performs poorly.
>
> > Oh sure, we know that VirtualBox can do amazing things (in some areas
> going far beyond what any virtualizer out there can do), and often shows
> its great scalability in setups which are a little outside the norm :)
>
> Yeah, I am really impressed, when I started my PhD work I was a lot in the
> dark, wanted to write virtual video card drivers etc., but this is flexible
> scalable and great, of course if the VRAM limit can be broken. Well I'll
> lurk around the sources and try to get a grasp of the VRAM things, maybe it
> is possible to do something there. Thanks a lot for all the input.
>
>
> 2014-08-28 22:12 GMT+03:00 Klaus Espenlaub <klaus.espenlaub at oracle.com>:
>
> Rūdolfs,
>>
>>
>> On 28.08.2014 18:15, Rūdolfs Bundulis wrote:
>>
>>> Hi Klaus,
>>>
>>> I'll mail directly to you this time, since this is not regarding the
>>> original issue.
>>>
>>
>> Actually if you'd stay on the list then you'd have a chance of getting
>> more than one team member's knowledge... I'm not really a graphics expert.
>>
>>
>> I ran some tests today, and it seems that at least on
>>> Windows 7 16 monitors on 1280x720 (720p) work fine. Using our software I
>>> streamed that to a 4x4 22" monitor wall and that looked really
>>> impressive.
>>>
>>
>> Was the available monitor hardware limiting you to 16? Because with 720p
>> and the XPDM driver (which is usable with Win7, and I think still the
>> default if you don't enable 3D in the guest additions installer) you should
>> be able to run with 5x5, too. Needs "only" 226MB for the framebuffers.
>>
>> Another option might be using 15 or 16bpp in the guest *and* on the host
>> (otherwise color format conversion is necessary, and this kills performance
>> as VirtualBox uses the CPU for that). The GUI again is pessimistic and
>> always expects 24bpp (4 bytes, the packed format again is unbearably slow
>> as it needs conversion), but the virtualizer would work just fine. This
>> would fit into 248MB with 5x5 @1920x1080. Yes, the reduced color resolution
>> sucks, it usually results in heavy color banding.
>>
>>
>> Also tried Xubuntu 14.04 on same configuration but for
>>> somewhat reason (X11) it was lagging terribly. The question that arose
>>> was, could you at least provide some base info (as far as it does not
>>> take too much of your time) what needs to be patched to increase the
>>> VRAM size?
>>>
>>
>> The easy part is VGA_VRAM_MAX in src/VBox/Devices/Graphics/DevVGA.h and
>> VRAMSize in src/VBox/Main/xml/VirtualBox-settings.xsd. Not sure if there
>> are a few more "256 MB" definitions somewhere.
>>
>> I bet you'll run into trouble with PCI resource allocation (in our case
>> done in the code before the VM starts, not in the BIOS like with
>> conventional PCs), because the bigger area will not fit into the PCI hole
>> (which is actually normal, I think real systems start with a partial
>> mapping of the VRAM there, and the graphics driver then relocates it to a
>> free area past 4GB, at least with 64 bit OSes which can deal properly with
>> the then necessary 64 bit PCI resources).
>>
>> Similarly I guess the BIOS e820 memory map will most likely be broken.
>>
>> Many real graphics cards can work with a partially mapped VRAM, giving
>> access only to 256MB at a time. This would need big changes to our virtual
>> graphics card and the guest additions driver, but would minimize the need
>> to change other places.
>>
>>
>> Our research time consists of quite skilled developers so if
>>> it is not a man-year we would be interrested at least to look into it,
>>> since the 16 at 720p demo was impressive and seems that this technology has
>>> a future, and currently the biggest limitation is the vram limit in
>>> VirtualBox. Hope I'm not too intrusive, simply we were all quite
>>> astonished how this leverages the independence from actual hardware in
>>> display wall construction, so we are all keen to achieve at least a
>>> 16x1080p implementation.
>>>
>>
>> Oh sure, we know that VirtualBox can do amazing things (in some areas
>> going far beyond what any virtualizer out there can do), and often shows
>> its great scalability in setups which are a little outside the norm :)
>>
>> We added support for 64 screens in the days when no one could afford a
>> full HD screen, and actually the majority of users had only 1024x768, and
>> users were willing to use 16bpp... it blew the mind of quite a few users
>> that they could hook up a collection of RDP clients, each providing a
>> couple of monitors, and get a big video wall this way.
>>
>> Regards,
>> Klaus
>>
>>
>>
>>> Best Regards,
>>> Rudolfs Bundulis
>>>
>>>
>>> 2014-08-27 20:11 GMT+03:00 Klaus Espenlaub <klaus.espenlaub at oracle.com
>>> <mailto:klaus.espenlaub at oracle.com>>:
>>>
>>>
>>> On 27.08.2014 <tel: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 <tel:2014.08.27>. 19:05
>>> > To: vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
>>>
>>> > Subject: Re: [vbox-dev] Monitor count limitations
>>> > Hi Rūdolfs,
>>> >
>>> > On 27.08.2014 <tel: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>
>>> >> <mailto: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>
>>> <mailto: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
>>> >>
>>> >
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140828/b0e615f2/attachment.html>
More information about the vbox-dev
mailing list