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.
R?dolfs,
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
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
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,
Post by RÅ«dolfs BundulisHi,
I've run into some more issues with high monitor count on
VirtualBox.
Post by RÅ«dolfs BundulisBasically when selecting 25 displays it complains that at least
600
Post by RÅ«dolfs Bundulissomething MB of VRAM is needed, but while the arrows in the
display
Post by RÅ«dolfs Bundulisnumber box allow to select more than 8 monitors, seems that i
can't go
Post by RÅ«dolfs Bundulisabove 256 mb in VRAM. Is this a hard limitation? Since the COM
API also
Post by RÅ«dolfs Bundulisdoes 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
Post by RÅ«dolfs BundulisBest 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>
Post by RÅ«dolfs Bundulis<mailto:rudolfs.bundulis at gmail.com
Hi Klaus,
Thanks a lot for the clarification. I thought the same that
it was
Post by RÅ«dolfs Bundulisjust a sanity limit, but in my case this is really needed.
Then I
Post by RÅ«dolfs Bundulisguess will be able to do the same with the COM API, thanks
a lot again.
Post by RÅ«dolfs Bundulis2014-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
Post by RÅ«dolfs BundulisHi R?dolfs,
Post by RÅ«dolfs BundulisHi,
I'm developing a system that needs to run a headless
VM with
Post by RÅ«dolfs Bundulisa large
Post by RÅ«dolfs Bundulisnumber of attached monitors - currently the GUI has
the limit
Post by RÅ«dolfs Bundulisto set
Post by RÅ«dolfs Bundulismaximum monitor count to 8, I didn't check the COM
API myself
Post by RÅ«dolfs Bundulisbut I
Post by RÅ«dolfs Bundulissuspect that it will not allow me to set the count
greater
Post by RÅ«dolfs Bundulisthan 8, while
Post by RÅ«dolfs Bundulisbrowsing the VirtualBox sources show that the
internal C macro is
<xsd:maxInclusive
Post by RÅ«dolfs Bundulissrc/VBox/Main/xml/VirtualBox-settings-common.xsd */
Post by RÅ«dolfs Bundulis#define VBOX_VIDEO_MAX_SCREENS 64
Looks to me that this comment is simply outdated.
Nothing more,
Post by RÅ«dolfs Bundulisnothing
less.
Many limits can be listed with "VBoxManage list
systemproperties", and
it shows 64.
Post by RÅ«dolfs BundulisIs there really a need to limit the count to 8? If I
change
Post by RÅ«dolfs Bundulisthe xml
Post by RÅ«dolfs Bundulisschema file and increase the count from 8 to 64 and
recompile
Post by RÅ«dolfs Bunduliswould
Post by RÅ«dolfs Bundulisthere be any actual limitations in the VirtualBox
core?
Post by RÅ«dolfs BundulisThere is a constant conflict in the GUI between sanity
(i.e.
Post by RÅ«dolfs Bundulisprotecting
users against their stupidity - you can't believe how
many people
Post by RÅ«dolfs Bundulisbelieve that more is better, even if it's a giant waste
of resources
Post by RÅ«dolfs Bundulisinstead) and allowing expert users to go to the
extreme. There are
Post by RÅ«dolfs Bundulisextremely few people out there who ever need to deal
with more
Post by RÅ«dolfs Bundulisthan 8
monitors.
In my quick test I could use the GUI to select 20
monitors -
Post by RÅ«dolfs Bundulissure, the
slider doesn't allow that, but one can enter the number
or use the
Post by RÅ«dolfs Bundulisup/down arrows. This needs 256MB of VRAM, which this
high number
Post by RÅ«dolfs Bundulisautomatically unlocks.
Klaus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140828/5f49487c/attachment-0001.html