[vbox-dev] Monitor count limitations
Rūdolfs Bundulis
rudolfs.bundulis at gmail.com
Thu Aug 28 20:03:01 GMT 2014
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/5f49487c/attachment.html>
More information about the vbox-dev
mailing list