[vbox-dev] Monitor count limitations

Rūdolfs Bundulis rudolfs.bundulis at gmail.com
Mon Sep 1 22:37:22 UTC 2014


Also, about what was mentioned about the *2 and *3 multipliers, it seems
that if the HGSMI is enabled in the build then any Windows machine from
Vista and up would need *3 memory irrelevant of the driver type, right?

   if (strGuestOSTypeId.startsWith("Windows"))
    {
       /* Windows guests need offscreen VRAM too for graphics acceleration
features: */
#ifdef VBOX_WITH_CRHGSMI
       if (isWddmCompatibleOsType(strGuestOSTypeId))
       {
           /* wddm mode, there are two surfaces for each screen: shadow &
primary */
           needMBytes *= 3;
       }
       else
#endif /* VBOX_WITH_CRHGSMI */
       {
           needMBytes *= 2;
       }
    }


2014-09-01 22:23 GMT+03:00 Rūdolfs Bundulis <rudolfs.bundulis at gmail.com>:

> Hi,
>
> any hints on how to understand if a Windows 7 guest OS uses XPDM or WDDM
> driver? I would be interrested to see if with XPDM I can actually reduce
> the needed memory for the surfaces.
>
>
> 2014-08-28 23:03 GMT+03:00 Rūdolfs Bundulis <rudolfs.bundulis at gmail.com>:
>
>> 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/20140902/4572f17a/attachment-0001.html 


More information about the vbox-dev mailing list