Discussion:
[vbox-dev] Monitor count limitations
Rūdolfs Bundulis
2014-06-18 09:48:47 UTC
Permalink
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

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140618/6cf189b0/attachment.html
Klaus Espenlaub
2014-06-18 10:13:43 UTC
Permalink
Hi R?dolfs,
Post by RÅ«dolfs Bundulis
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
/* 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.
Post by RÅ«dolfs Bundulis
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
Rūdolfs Bundulis
2014-08-27 14:49:52 UTC
Permalink
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.

Best Regards,
Rudolfs Bundulis
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.
Hi R?dolfs,
Post by Klaus Espenlaub
Post by RÅ«dolfs Bundulis
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
/* 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.
Post by RÅ«dolfs Bundulis
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/f4b5bdd8/attachment.html
Rūdolfs Bundulis
2014-08-27 16:03:34 UTC
Permalink
Hi,

After experimenting with different monitor amounts, I'm moving towards some
conclusions and would be glad to get some confirmation. It seems that even
if the displays require more memory than 256 MB the machine still launches
but seems that the hint to use 1920x1080 is ignored and 1152x862 is used.
So is it safe to assume that VirtualBox tries to find the maximum
resolution for which it can fit all the framebuffers for all the displays
in the video memory? If I launch a machine with 8 monitors then it seems to
handle full hd, when i increase the display number, it reduces the
resolution, on 25 monitors i get only one (assuming there is not enoguh
memory even for 800x600x25?). Is it possible to recompile virtual box from
source with increased video memory limit or are there other dependencies?

Best Regards,
Rudolfs Bundulis
Post by RÅ«dolfs Bundulis
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.
Best Regards,
Rudolfs Bundulis
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.
Hi R?dolfs,
Post by Klaus Espenlaub
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
browsing the VirtualBox sources show that the internal C macro is
/* 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.
Post by RÅ«dolfs Bundulis
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/7600affd/attachment.html
Klaus Espenlaub
2014-08-27 16:04:10 UTC
Permalink
Hi R?dolfs,
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
Best Regards,
Rudolfs Bundulis
2014-06-18 13:41 GMT+03:00 R?dolfs Bundulis <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
Hi R?dolfs,
Post by RÅ«dolfs Bundulis
Hi,
I'm developing a system that needs to run a headless VM with
a large
Post by RÅ«dolfs Bundulis
number of attached monitors - currently the GUI has the limit
to set
Post by RÅ«dolfs Bundulis
maximum monitor count to 8, I didn't check the COM API myself
but I
Post by RÅ«dolfs Bundulis
suspect that it will not allow me to set the count greater
than 8, while
Post by RÅ«dolfs Bundulis
browsing the VirtualBox sources show that the internal C macro is
/* this should be in sync with monitorCount <xsd:maxInclusive
value="8"/> in
src/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, nothing
less.
Many limits can be listed with "VBoxManage list
systemproperties", and
it shows 64.
Post by RÅ«dolfs Bundulis
Is there really a need to limit the count to 8? If I change
the xml
Post by RÅ«dolfs Bundulis
schema file and increase the count from 8 to 64 and recompile
would
Post by RÅ«dolfs Bundulis
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
Rūdolfs Bundulis
2014-08-27 16:38:05 UTC
Permalink
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.

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?

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.

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,
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
Best Regards,
Rudolfs Bundulis
2014-06-18 13:41 GMT+03:00 R?dolfs Bundulis <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
Hi R?dolfs,
Post by RÅ«dolfs Bundulis
Hi,
I'm developing a system that needs to run a headless VM with
a large
Post by RÅ«dolfs Bundulis
number of attached monitors - currently the GUI has the limit
to set
Post by RÅ«dolfs Bundulis
maximum monitor count to 8, I didn't check the COM API myself
but I
Post by RÅ«dolfs Bundulis
suspect that it will not allow me to set the count greater
than 8, while
Post by RÅ«dolfs Bundulis
browsing the VirtualBox sources show that the internal C macro is
/* this should be in sync with monitorCount <xsd:maxInclusive
value="8"/> in
src/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,
nothing
less.
Many limits can be listed with "VBoxManage list
systemproperties", and
it shows 64.
Post by RÅ«dolfs Bundulis
Is there really a need to limit the count to 8? If I change
the xml
Post by RÅ«dolfs Bundulis
schema file and increase the count from 8 to 64 and recompile
would
Post by RÅ«dolfs Bundulis
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
Klaus Espenlaub
2014-08-27 17:11:41 UTC
Permalink
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,
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
Best Regards,
Rudolfs Bundulis
2014-06-18 13:41 GMT+03:00 R?dolfs Bundulis <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
Hi R?dolfs,
Post by RÅ«dolfs Bundulis
Hi,
I'm developing a system that needs to run a headless VM with
a large
Post by RÅ«dolfs Bundulis
number of attached monitors - currently the GUI has the limit
to set
Post by RÅ«dolfs Bundulis
maximum monitor count to 8, I didn't check the COM API myself
but I
Post by RÅ«dolfs Bundulis
suspect that it will not allow me to set the count greater
than 8, while
Post by RÅ«dolfs Bundulis
browsing the VirtualBox sources show that the internal C macro is
/* this should be in sync with monitorCount <xsd:maxInclusive
value="8"/> in
src/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,
nothing
less.
Many limits can be listed with "VBoxManage list
systemproperties", and
it shows 64.
Post by RÅ«dolfs Bundulis
Is there really a need to limit the count to 8? If I change
the xml
Post by RÅ«dolfs Bundulis
schema file and increase the count from 8 to 64 and recompile
would
Post by RÅ«dolfs Bundulis
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
Rūdolfs Bundulis
2014-08-27 17:46:29 UTC
Permalink
Hi,
Post by Klaus Espenlaub
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.
Post by Klaus Espenlaub
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
Post by Klaus Espenlaub
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,
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
Best Regards,
Rudolfs Bundulis
2014-06-18 13:41 GMT+03:00 R?dolfs Bundulis <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.
Post by RÅ«dolfs Bundulis
2014-06-18 13:13 GMT+03:00 Klaus Espenlaub
Hi R?dolfs,
Post by RÅ«dolfs Bundulis
Hi,
I'm developing a system that needs to run a headless VM with
a large
Post by RÅ«dolfs Bundulis
number of attached monitors - currently the GUI has the
limit
Post by RÅ«dolfs Bundulis
to set
Post by RÅ«dolfs Bundulis
maximum monitor count to 8, I didn't check the COM API
myself
Post by RÅ«dolfs Bundulis
but I
Post by RÅ«dolfs Bundulis
suspect that it will not allow me to set the count greater
than 8, while
Post by RÅ«dolfs Bundulis
browsing the VirtualBox sources show that the internal C
macro is
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
/* this should be in sync with monitorCount
<xsd:maxInclusive
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
value="8"/> in
src/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,
nothing
less.
Many limits can be listed with "VBoxManage list
systemproperties", and
it shows 64.
Post by RÅ«dolfs Bundulis
Is there really a need to limit the count to 8? If I change
the xml
Post by RÅ«dolfs Bundulis
schema file and increase the count from 8 to 64 and
recompile
Post by RÅ«dolfs Bundulis
would
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
believe that more is better, even if it's a giant waste of
resources
Post by RÅ«dolfs Bundulis
instead) and allowing expert users to go to the extreme. There
are
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
up/down arrows. This needs 256MB of VRAM, which this high
number
Post by RÅ«dolfs Bundulis
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/0399aaf6/attachment-0001.html
Rūdolfs Bundulis
2014-08-27 17:54:07 UTC
Permalink
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
Post by RÅ«dolfs Bundulis
Hi,
Post by Klaus Espenlaub
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.
Post by Klaus Espenlaub
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
Post by Klaus Espenlaub
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,
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
Best Regards,
Rudolfs Bundulis
2014-06-18 13:41 GMT+03:00 R?dolfs Bundulis <
rudolfs.bundulis at gmail.com
Post by RÅ«dolfs Bundulis
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.
Post by RÅ«dolfs Bundulis
2014-06-18 13:13 GMT+03:00 Klaus Espenlaub
Hi R?dolfs,
Post by RÅ«dolfs Bundulis
Hi,
I'm developing a system that needs to run a headless VM
with
Post by RÅ«dolfs Bundulis
a large
Post by RÅ«dolfs Bundulis
number of attached monitors - currently the GUI has the
limit
Post by RÅ«dolfs Bundulis
to set
Post by RÅ«dolfs Bundulis
maximum monitor count to 8, I didn't check the COM API
myself
Post by RÅ«dolfs Bundulis
but I
Post by RÅ«dolfs Bundulis
suspect that it will not allow me to set the count greater
than 8, while
Post by RÅ«dolfs Bundulis
browsing the VirtualBox sources show that the internal C
macro is
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
/* this should be in sync with monitorCount
<xsd:maxInclusive
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
value="8"/> in
src/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 Bundulis
nothing
less.
Many limits can be listed with "VBoxManage list
systemproperties", and
it shows 64.
Post by RÅ«dolfs Bundulis
Is there really a need to limit the count to 8? If I change
the xml
Post by RÅ«dolfs Bundulis
schema file and increase the count from 8 to 64 and
recompile
Post by RÅ«dolfs Bundulis
would
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
believe that more is better, even if it's a giant waste of
resources
Post by RÅ«dolfs Bundulis
instead) and allowing expert users to go to the extreme.
There are
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
up/down arrows. This needs 256MB of VRAM, which this high
number
Post by RÅ«dolfs Bundulis
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
Rūdolfs Bundulis
2014-08-28 20:03:01 UTC
Permalink
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 Bundulis
Hi,
I've run into some more issues with high monitor count on
VirtualBox.
Post by RÅ«dolfs Bundulis
Basically when selecting 25 displays it complains that at least
600
Post by RÅ«dolfs Bundulis
something MB of VRAM is needed, but while the arrows in the
display
Post by RÅ«dolfs Bundulis
number box allow to select more than 8 monitors, seems that i
can't go
Post by RÅ«dolfs Bundulis
above 256 mb in VRAM. Is this a hard limitation? Since the COM
API also
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
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>
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 Bundulis
just a sanity limit, but in my case this is really needed.
Then I
Post by RÅ«dolfs Bundulis
guess will be able to do the same with the COM API, thanks
a lot again.
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
Hi R?dolfs,
Post by RÅ«dolfs Bundulis
Hi,
I'm developing a system that needs to run a headless
VM with
Post by RÅ«dolfs Bundulis
a large
Post by RÅ«dolfs Bundulis
number of attached monitors - currently the GUI has
the limit
Post by RÅ«dolfs Bundulis
to set
Post by RÅ«dolfs Bundulis
maximum monitor count to 8, I didn't check the COM
API myself
Post by RÅ«dolfs Bundulis
but I
Post by RÅ«dolfs Bundulis
suspect that it will not allow me to set the count
greater
Post by RÅ«dolfs Bundulis
than 8, while
Post by RÅ«dolfs Bundulis
browsing the VirtualBox sources show that the
internal C macro is
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
/* this should be in sync with monitorCount
<xsd:maxInclusive
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
value="8"/> in
src/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 Bundulis
nothing
less.
Many limits can be listed with "VBoxManage list
systemproperties", and
it shows 64.
Post by RÅ«dolfs Bundulis
Is there really a need to limit the count to 8? If I
change
Post by RÅ«dolfs Bundulis
the xml
Post by RÅ«dolfs Bundulis
schema file and increase the count from 8 to 64 and
recompile
Post by RÅ«dolfs Bundulis
would
Post by RÅ«dolfs Bundulis
there be any actual limitations in the VirtualBox
core?
Post by RÅ«dolfs Bundulis
There is a constant conflict in the GUI between sanity
(i.e.
Post by RÅ«dolfs Bundulis
protecting
users against their stupidity - you can't believe how
many people
Post by RÅ«dolfs Bundulis
believe that more is better, even if it's a giant waste
of resources
Post by RÅ«dolfs Bundulis
instead) and allowing expert users to go to the
extreme. There are
Post by RÅ«dolfs Bundulis
extremely few people out there who ever need to deal
with more
Post by RÅ«dolfs Bundulis
than 8
monitors.
In my quick test I could use the GUI to select 20
monitors -
Post by RÅ«dolfs Bundulis
sure, the
slider doesn't allow that, but one can enter the number
or use the
Post by RÅ«dolfs Bundulis
up/down arrows. This needs 256MB of VRAM, which this
high number
Post by RÅ«dolfs Bundulis
automatically unlocks.
Klaus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140828/5f49487c/attachment-0001.html
Rūdolfs Bundulis
2014-08-28 20:03:58 UTC
Permalink
Btw, here is a little demo of the 16 * 720p wall driven by virtualbox


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.
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 Bundulis
Hi,
I've run into some more issues with high monitor count on
VirtualBox.
Post by RÅ«dolfs Bundulis
Basically when selecting 25 displays it complains that at least
600
Post by RÅ«dolfs Bundulis
something MB of VRAM is needed, but while the arrows in the
display
Post by RÅ«dolfs Bundulis
number box allow to select more than 8 monitors, seems that i
can't go
Post by RÅ«dolfs Bundulis
above 256 mb in VRAM. Is this a hard limitation? Since the COM
API also
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
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>
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 Bundulis
just a sanity limit, but in my case this is really needed.
Then I
Post by RÅ«dolfs Bundulis
guess will be able to do the same with the COM API, thanks
a lot again.
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
Hi R?dolfs,
Post by RÅ«dolfs Bundulis
Hi,
I'm developing a system that needs to run a headless
VM with
Post by RÅ«dolfs Bundulis
a large
Post by RÅ«dolfs Bundulis
number of attached monitors - currently the GUI has
the limit
Post by RÅ«dolfs Bundulis
to set
Post by RÅ«dolfs Bundulis
maximum monitor count to 8, I didn't check the COM
API myself
Post by RÅ«dolfs Bundulis
but I
Post by RÅ«dolfs Bundulis
suspect that it will not allow me to set the count
greater
Post by RÅ«dolfs Bundulis
than 8, while
Post by RÅ«dolfs Bundulis
browsing the VirtualBox sources show that the
internal C macro is
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
/* this should be in sync with monitorCount
<xsd:maxInclusive
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
value="8"/> in
src/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 Bundulis
nothing
less.
Many limits can be listed with "VBoxManage list
systemproperties", and
it shows 64.
Post by RÅ«dolfs Bundulis
Is there really a need to limit the count to 8? If I
change
Post by RÅ«dolfs Bundulis
the xml
Post by RÅ«dolfs Bundulis
schema file and increase the count from 8 to 64 and
recompile
Post by RÅ«dolfs Bundulis
would
Post by RÅ«dolfs Bundulis
there be any actual limitations in the VirtualBox
core?
Post by RÅ«dolfs Bundulis
There is a constant conflict in the GUI between sanity
(i.e.
Post by RÅ«dolfs Bundulis
protecting
users against their stupidity - you can't believe how
many people
Post by RÅ«dolfs Bundulis
believe that more is better, even if it's a giant waste
of resources
Post by RÅ«dolfs Bundulis
instead) and allowing expert users to go to the
extreme. There are
Post by RÅ«dolfs Bundulis
extremely few people out there who ever need to deal
with more
Post by RÅ«dolfs Bundulis
than 8
monitors.
In my quick test I could use the GUI to select 20
monitors -
Post by RÅ«dolfs Bundulis
sure, the
slider doesn't allow that, but one can enter the number
or use the
Post by RÅ«dolfs Bundulis
up/down arrows. This needs 256MB of VRAM, which this
high number
Post by RÅ«dolfs Bundulis
automatically unlocks.
Klaus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140828/b0e615f2/attachment-0001.html
Rūdolfs Bundulis
2014-09-01 19:23:59 UTC
Permalink
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.
Post by RÅ«dolfs Bundulis
Btw, here is a little demo of the 16 * 720p wall driven by virtualbox
http://youtu.be/eFAATNofjHA
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
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 Bundulis
Hi,
I've run into some more issues with high monitor count on
VirtualBox.
Post by RÅ«dolfs Bundulis
Basically when selecting 25 displays it complains that at least
600
Post by RÅ«dolfs Bundulis
something MB of VRAM is needed, but while the arrows in the
display
Post by RÅ«dolfs Bundulis
number box allow to select more than 8 monitors, seems that i
can't go
Post by RÅ«dolfs Bundulis
above 256 mb in VRAM. Is this a hard limitation? Since the COM
API also
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
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>
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 Bundulis
just a sanity limit, but in my case this is really needed.
Then I
Post by RÅ«dolfs Bundulis
guess will be able to do the same with the COM API, thanks
a lot again.
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
Hi R?dolfs,
Post by RÅ«dolfs Bundulis
Hi,
I'm developing a system that needs to run a headless
VM with
Post by RÅ«dolfs Bundulis
a large
Post by RÅ«dolfs Bundulis
number of attached monitors - currently the GUI has
the limit
Post by RÅ«dolfs Bundulis
to set
Post by RÅ«dolfs Bundulis
maximum monitor count to 8, I didn't check the COM
API myself
Post by RÅ«dolfs Bundulis
but I
Post by RÅ«dolfs Bundulis
suspect that it will not allow me to set the count
greater
Post by RÅ«dolfs Bundulis
than 8, while
Post by RÅ«dolfs Bundulis
browsing the VirtualBox sources show that the
internal C macro is
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
/* this should be in sync with monitorCount
<xsd:maxInclusive
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
value="8"/> in
src/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 Bundulis
nothing
less.
Many limits can be listed with "VBoxManage list
systemproperties", and
it shows 64.
Post by RÅ«dolfs Bundulis
Is there really a need to limit the count to 8? If I
change
Post by RÅ«dolfs Bundulis
the xml
Post by RÅ«dolfs Bundulis
schema file and increase the count from 8 to 64 and
recompile
Post by RÅ«dolfs Bundulis
would
Post by RÅ«dolfs Bundulis
there be any actual limitations in the VirtualBox
core?
Post by RÅ«dolfs Bundulis
There is a constant conflict in the GUI between sanity
(i.e.
Post by RÅ«dolfs Bundulis
protecting
users against their stupidity - you can't believe how
many people
Post by RÅ«dolfs Bundulis
believe that more is better, even if it's a giant waste
of resources
Post by RÅ«dolfs Bundulis
instead) and allowing expert users to go to the
extreme. There are
Post by RÅ«dolfs Bundulis
extremely few people out there who ever need to deal
with more
Post by RÅ«dolfs Bundulis
than 8
monitors.
In my quick test I could use the GUI to select 20
monitors -
Post by RÅ«dolfs Bundulis
sure, the
slider doesn't allow that, but one can enter the number
or use the
Post by RÅ«dolfs Bundulis
up/down arrows. This needs 256MB of VRAM, which this
high number
Post by RÅ«dolfs Bundulis
automatically unlocks.
Klaus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140901/9b374eda/attachment-0001.html
Rūdolfs Bundulis
2014-09-01 22:06:38 UTC
Permalink
While browsing through the VirtualBox code I started to wonder - can HGSMI
help in any way help to solve the memory insufficiency? Intuitively it
seems that the adapter still needs enough VRAM memory to provide the actual
memory for the surfaces and that does not meddle with wether it is shared
or not, or is it not like that?
Post by RÅ«dolfs Bundulis
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.
Post by RÅ«dolfs Bundulis
Btw, here is a little demo of the 16 * 720p wall driven by virtualbox
http://youtu.be/eFAATNofjHA
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
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
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
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 Bundulis
Hi,
I've run into some more issues with high monitor count on
VirtualBox.
Post by RÅ«dolfs Bundulis
Basically when selecting 25 displays it complains that at
least 600
Post by RÅ«dolfs Bundulis
something MB of VRAM is needed, but while the arrows in the
display
Post by RÅ«dolfs Bundulis
number box allow to select more than 8 monitors, seems that i
can't go
Post by RÅ«dolfs Bundulis
above 256 mb in VRAM. Is this a hard limitation? Since the COM
API also
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
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>
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 Bundulis
just a sanity limit, but in my case this is really needed.
Then I
Post by RÅ«dolfs Bundulis
guess will be able to do the same with the COM API, thanks
a lot again.
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
Hi R?dolfs,
Post by RÅ«dolfs Bundulis
Hi,
I'm developing a system that needs to run a
headless
VM with
Post by RÅ«dolfs Bundulis
a large
Post by RÅ«dolfs Bundulis
number of attached monitors - currently the GUI has
the limit
Post by RÅ«dolfs Bundulis
to set
Post by RÅ«dolfs Bundulis
maximum monitor count to 8, I didn't check the COM
API myself
Post by RÅ«dolfs Bundulis
but I
Post by RÅ«dolfs Bundulis
suspect that it will not allow me to set the count
greater
Post by RÅ«dolfs Bundulis
than 8, while
Post by RÅ«dolfs Bundulis
browsing the VirtualBox sources show that the
internal C macro is
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
/* this should be in sync with monitorCount
<xsd:maxInclusive
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
value="8"/> in
src/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 Bundulis
nothing
less.
Many limits can be listed with "VBoxManage list
systemproperties", and
it shows 64.
Post by RÅ«dolfs Bundulis
Is there really a need to limit the count to 8? If
I
change
Post by RÅ«dolfs Bundulis
the xml
Post by RÅ«dolfs Bundulis
schema file and increase the count from 8 to 64 and
recompile
Post by RÅ«dolfs Bundulis
would
Post by RÅ«dolfs Bundulis
there be any actual limitations in the VirtualBox
core?
Post by RÅ«dolfs Bundulis
There is a constant conflict in the GUI between sanity
(i.e.
Post by RÅ«dolfs Bundulis
protecting
users against their stupidity - you can't believe how
many people
Post by RÅ«dolfs Bundulis
believe that more is better, even if it's a giant
waste
of resources
Post by RÅ«dolfs Bundulis
instead) and allowing expert users to go to the
extreme. There are
Post by RÅ«dolfs Bundulis
extremely few people out there who ever need to deal
with more
Post by RÅ«dolfs Bundulis
than 8
monitors.
In my quick test I could use the GUI to select 20
monitors -
Post by RÅ«dolfs Bundulis
sure, the
slider doesn't allow that, but one can enter the
number
or use the
Post by RÅ«dolfs Bundulis
up/down arrows. This needs 256MB of VRAM, which this
high number
Post by RÅ«dolfs Bundulis
automatically unlocks.
Klaus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140902/352957be/attachment-0001.html
Rūdolfs Bundulis
2014-09-01 22:37:22 UTC
Permalink
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;
}
}
Post by RÅ«dolfs Bundulis
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.
Post by RÅ«dolfs Bundulis
Btw, here is a little demo of the 16 * 720p wall driven by virtualbox
http://youtu.be/eFAATNofjHA
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
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
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
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 Bundulis
Hi,
I've run into some more issues with high monitor count on
VirtualBox.
Post by RÅ«dolfs Bundulis
Basically when selecting 25 displays it complains that at
least 600
Post by RÅ«dolfs Bundulis
something MB of VRAM is needed, but while the arrows in the
display
Post by RÅ«dolfs Bundulis
number box allow to select more than 8 monitors, seems that i
can't go
Post by RÅ«dolfs Bundulis
above 256 mb in VRAM. Is this a hard limitation? Since the COM
API also
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
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>
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 Bundulis
just a sanity limit, but in my case this is really needed.
Then I
Post by RÅ«dolfs Bundulis
guess will be able to do the same with the COM API, thanks
a lot again.
Post by RÅ«dolfs Bundulis
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
Post by RÅ«dolfs Bundulis
Hi R?dolfs,
Post by RÅ«dolfs Bundulis
Hi,
I'm developing a system that needs to run a
headless
VM with
Post by RÅ«dolfs Bundulis
a large
Post by RÅ«dolfs Bundulis
number of attached monitors - currently the GUI has
the limit
Post by RÅ«dolfs Bundulis
to set
Post by RÅ«dolfs Bundulis
maximum monitor count to 8, I didn't check the COM
API myself
Post by RÅ«dolfs Bundulis
but I
Post by RÅ«dolfs Bundulis
suspect that it will not allow me to set the count
greater
Post by RÅ«dolfs Bundulis
than 8, while
Post by RÅ«dolfs Bundulis
browsing the VirtualBox sources show that the
internal C macro is
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
/* this should be in sync with monitorCount
<xsd:maxInclusive
Post by RÅ«dolfs Bundulis
Post by RÅ«dolfs Bundulis
value="8"/> in
src/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 Bundulis
nothing
less.
Many limits can be listed with "VBoxManage list
systemproperties", and
it shows 64.
Post by RÅ«dolfs Bundulis
Is there really a need to limit the count to 8? If
I
change
Post by RÅ«dolfs Bundulis
the xml
Post by RÅ«dolfs Bundulis
schema file and increase the count from 8 to 64 and
recompile
Post by RÅ«dolfs Bundulis
would
Post by RÅ«dolfs Bundulis
there be any actual limitations in the VirtualBox
core?
Post by RÅ«dolfs Bundulis
There is a constant conflict in the GUI between sanity
(i.e.
Post by RÅ«dolfs Bundulis
protecting
users against their stupidity - you can't believe how
many people
Post by RÅ«dolfs Bundulis
believe that more is better, even if it's a giant
waste
of resources
Post by RÅ«dolfs Bundulis
instead) and allowing expert users to go to the
extreme. There are
Post by RÅ«dolfs Bundulis
extremely few people out there who ever need to deal
with more
Post by RÅ«dolfs Bundulis
than 8
monitors.
In my quick test I could use the GUI to select 20
monitors -
Post by RÅ«dolfs Bundulis
sure, the
slider doesn't allow that, but one can enter the
number
or use the
Post by RÅ«dolfs Bundulis
up/down arrows. This needs 256MB of VRAM, which this
high number
Post by RÅ«dolfs Bundulis
automatically unlocks.
Klaus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140902/4572f17a/attachment-0001.html
Vitali Pelenjow
2014-09-02 12:57:22 UTC
Permalink
Hi,
2014-09-01 22:23 GMT+03:00 R?dolfs Bundulis
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.
Look at the guest Computer/Properties/Device Manager/Display
Adapters/VirtualBox Graphics Adapter/Driver/Driver Details
XPDM files are VBoxVideo.sys and VBoxDisp.dll

XPDM requires less guest VRAM, it mostly needs VRAM for the screen
surface. With 256MB of VRAM it is able to support 24 or 25 monitors at
1920x1200x32 each.
One screen needs ~9MB, which gives a hard limit 256/9 ~= 28 screens. But
since some VRAM is needed for other purposes, it is better not to use
the maximum.
The performance will be probably a bit worse compared to the case when
each guest screen has enough VRAM for a full resolution offscreen surface.

I just tested a VBoxHeadless VM with 24 monitors at 1920x1200 and 256 MB
of guest VRAM and it seems to work fine.

Vitali
Rūdolfs Bundulis
2014-09-02 13:12:17 UTC
Permalink
Post by Vitali Pelenjow
Look at the guest Computer/Properties/Device Manager/Display
Adapters/VirtualBox Graphics Adapter/Driver/Driver Details
XPDM files are VBoxVideo.sys and VBoxDisp.dll
XPDM requires less guest VRAM, it mostly needs VRAM for the screen
surface. With 256MB of VRAM it is able to support 24 or 25 monitors at
1920x1200x32 each.
One screen needs ~9MB, which gives a hard limit 256/9 ~= 28 screens. But
since some VRAM is needed for other purposes, it is better not to use
the maximum.
The performance will be probably a bit worse compared to the case when
each guest screen has enough VRAM for a full resolution offscreen surface.
I just tested a VBoxHeadless VM with 24 monitors at 1920x1200 and 256 MB
of guest VRAM and it seems to work fine.
Thanks a lot, I'll try that out, I guess, since I checked the Direct3D
support in the guest additions I could be using WDDM, I'll verify it and if
so make a clean install and try XPDM. Since my current test wall is 5x5 25
would be great. I simply got confused when I found the code i pasted here
in a post above in the Qt GUI that does a hard multiplication with 3 to
calculate the needed video memory.

Rudolfs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140902/89a09b96/attachment.html
Klaus Espenlaub
2014-09-02 13:18:52 UTC
Permalink
BTW, the GUI uses the OS type to make its guesses and recommendations.
you can exploit that, because the OS type is not used for much besides
picking suitable defaults - so create the VM with the correct OS type,
and later re-declare it to be Linux. That way the GUI doesn't try to be
"helpful", and you should be able to reach the limits...
Post by Vitali Pelenjow
Look at the guest Computer/Properties/Device Manager/Display
Adapters/VirtualBox Graphics Adapter/Driver/Driver Details
XPDM files are VBoxVideo.sys and VBoxDisp.dll
XPDM requires less guest VRAM, it mostly needs VRAM for the screen
surface. With 256MB of VRAM it is able to support 24 or 25 monitors at
1920x1200x32 each.
One screen needs ~9MB, which gives a hard limit 256/9 ~= 28 screens. But
since some VRAM is needed for other purposes, it is better not to use
the maximum.
The performance will be probably a bit worse compared to the case when
each guest screen has enough VRAM for a full resolution offscreen surface.
I just tested a VBoxHeadless VM with 24 monitors at 1920x1200 and 256 MB
of guest VRAM and it seems to work fine.
Thanks a lot, I'll try that out, I guess, since I checked the Direct3D
support in the guest additions I could be using WDDM, I'll verify it and
if so make a clean install and try XPDM. Since my current test wall is
5x5 25 would be great. I simply got confused when I found the code i
pasted here in a post above in the Qt GUI that does a hard
multiplication with 3 to calculate the needed video memory.
Rudolfs
Rūdolfs Bundulis
2014-09-02 13:35:41 UTC
Permalink
Post by Klaus Espenlaub
BTW, the GUI uses the OS type to make its guesses and recommendations.
you can exploit that, because the OS type is not used for much besides
picking suitable defaults - so create the VM with the correct OS type,
and later re-declare it to be Linux. That way the GUI doesn't try to be
"helpful", and you should be able to reach the limits...
Well yeah I already got that, I mean even though the GUI is complaining
that the settings are invalid my application (which is much like
VBoxHeadless apart from the fact that it actually injects IFramebuffer
implementations in the IDisplay object) started fine, simply as I already
mentioned, when running more than 8 monitors, each of the IFramebuffer
objects was resized to 1400xsomething not 1920x1200, but that could be
because of the WDDM, Since now I know how to verify which driver is being
used I can verify if with XPDM I'm able to go above 8. I'll test that and
get back. Thanks for all the help, I really apprieciate it, hope the video
link gave some hint on what I'm trying to do.

Also, just to verify, does HGSMI play any role in how many buffers are
allocated?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140902/19c254ec/attachment.html
Vitali Pelenjow
2014-09-02 13:57:42 UTC
Permalink
Post by RÅ«dolfs Bundulis
Also, just to verify, does HGSMI play any role in how many buffers are
allocated?
Yes. However HGSMI is "The Interface" between the vitual graphics card
and the host and
therefore can not be disabled.

Moreover HGSMI does not affect the memory allocation much.
The monitor count is limited by the screen surface memory.

Vitali.
Rūdolfs Bundulis
2014-09-02 14:07:14 UTC
Permalink
Post by Vitali Pelenjow
Yes. However HGSMI is "The Interface" between the vitual graphics card
and the host and
therefore can not be disabled.
Moreover HGSMI does not affect the memory allocation much.
The monitor count is limited by the screen surface memory.
Thanks a lot for the explanation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140902/005642a4/attachment.html
Rūdolfs Bundulis
2014-09-03 09:01:43 UTC
Permalink
Hi,

I made a new Windows 7 machine and installed the guest additions without
the 3D support, verified that the XPDM files were installed and now the
machine booted to 1280x720 at all 25 monitors and my software acutally run
out of memory for the NV12/H264 buffers so I guess if I fix that I should
be able to go to 1920x1200, thanks for the pointers on XPDM, I'll fix
everything on my side with the memory and try again.
Post by Vitali Pelenjow
Yes. However HGSMI is "The Interface" between the vitual graphics card
Post by Vitali Pelenjow
and the host and
therefore can not be disabled.
Moreover HGSMI does not affect the memory allocation much.
The monitor count is limited by the screen surface memory.
Thanks a lot for the explanation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140903/2714ff7b/attachment.html
Rūdolfs Bundulis
2014-09-03 22:39:01 UTC
Permalink
Hi,
Post by Vitali Pelenjow
I just tested a VBoxHeadless VM with 24 monitors at 1920x1200 and 256 MB
of guest VRAM and it seems to work fine.
I fixed errors on my side, and still got the same (which is still much
better than with the WDDM driver) but it seems that you actually cannot run
that many monitors on full hd. I tried 25,24,20,16 and all these numbers
resized to 1280x720, didn't go much lower, but I will find the boundary. I
looked at VBoxHeadless, since it was mentioned that it did work, and I saw
that VBoxHeadless actually injects only one IFramebuffer instance. So can
that actually affect the behaivor? What happens if no IFramebuffer
implementation is provided for the a display? Does that count as a
disconnected video output or what?
Post by Vitali Pelenjow
Hi,
I made a new Windows 7 machine and installed the guest additions without
the 3D support, verified that the XPDM files were installed and now the
machine booted to 1280x720 at all 25 monitors and my software acutally run
out of memory for the NV12/H264 buffers so I guess if I fix that I should
be able to go to 1920x1200, thanks for the pointers on XPDM, I'll fix
everything on my side with the memory and try again.
Yes. However HGSMI is "The Interface" between the vitual graphics card
Post by RÅ«dolfs Bundulis
Post by Vitali Pelenjow
and the host and
therefore can not be disabled.
Moreover HGSMI does not affect the memory allocation much.
The monitor count is limited by the screen surface memory.
Thanks a lot for the explanation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140904/6677b050/attachment.html
Vitali Pelenjow
2014-09-03 23:00:14 UTC
Permalink
Actually VBoxHeadless sets framebuffers for each guest monitor (in VBox
4.3 or older).
Where exactly did you see that VBoxHeadless uses one IFramebuffer instance?

If no Framebuffer is assigned then graphics output from the VM does not
work.

I wonder why monitors in your guest resize to 1280x720.
Did you allow all modes in IFramebuffer::VideoModeSupported?
Can you run 1 monitor at 1920x1200?
How do you resize the guest monitors: from the guest or using VBoxManage
controlvm setvideomodehint?

BTW, you can send me source code of the framebuffer implementation and
code which sets framebuffers fro the VM.
I could take a look.

When I tested Win7 32 bit guest with VBoxHeadless and 24 monitors, I used
VBoxManage controlvm setvideomodehint to resize and enable them.

Vitali
Post by RÅ«dolfs Bundulis
Hi,
Post by Vitali Pelenjow
I just tested a VBoxHeadless VM with 24 monitors at 1920x1200 and 256 MB
of guest VRAM and it seems to work fine.
I fixed errors on my side, and still got the same (which is still much
better than with the WDDM driver) but it seems that you actually
cannot run that many monitors on full hd. I tried 25,24,20,16 and all
these numbers resized to 1280x720, didn't go much lower, but I will
find the boundary. I looked at VBoxHeadless, since it was mentioned
that it did work, and I saw that VBoxHeadless actually injects only
one IFramebuffer instance. So can that actually affect the behaivor?
What happens if no IFramebuffer implementation is provided for the a
display? Does that count as a disconnected video output or what?
2014-09-03 12:01 GMT+03:00 R?dolfs Bundulis
Hi,
I made a new Windows 7 machine and installed the guest additions
without the 3D support, verified that the XPDM files were
installed and now the machine booted to 1280x720 at all 25
monitors and my software acutally run out of memory for the
NV12/H264 buffers so I guess if I fix that I should be able to go
to 1920x1200, thanks for the pointers on XPDM, I'll fix everything
on my side with the memory and try again.
2014-09-02 17:07 GMT+03:00 R?dolfs Bundulis
Yes. However HGSMI is "The Interface" between the vitual
graphics card
and the host and
therefore can not be disabled.
Moreover HGSMI does not affect the memory allocation much.
The monitor count is limited by the screen surface memory.
Thanks a lot for the explanation.
_______________________________________________
vbox-dev mailing list
vbox-dev at virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
Rūdolfs Bundulis
2014-09-04 06:52:42 UTC
Permalink
Post by Vitali Pelenjow
Actually VBoxHeadless sets framebuffers for each guest monitor (in VBox
4.3 or older).
Where exactly did you see that VBoxHeadless uses one IFramebuffer instance?
If no Framebuffer is assigned then graphics output from the VM does not
work.
Sorry my bad, I guess I was working too late, I looked at:

if (RT_SUCCESS(rrc) && rcc == S_OK)
{
Log2(("VBoxHeadless: Registering framebuffer\n"));
pFramebuffer->AddRef();
display->SetFramebuffer(VBOX_VIDEO_PRIMARY_SCREEN, pFramebuffer);
}

when actually lower there is a loop that adds a framebuffer to all the
screens, my bad.
Post by Vitali Pelenjow
I wonder why monitors in your guest resize to 1280x720.
Did you allow all modes in IFramebuffer::VideoModeSupported?
Can you run 1 monitor at 1920x1200?
How do you resize the guest monitors: from the guest or using VBoxManage
controlvm setvideomodehint?
Yep, I allow all modes:

STDMETHODIMP
CVirtualBoxCaptureSourceOutput::raw_VideoModeSupported(/*[in]*/ unsigned
long aWidth, /*[in]*/ unsigned long aHeight, /*[in]*/ unsigned long aBpp,
/*[out,retval]*/ long * aSupported)
{
CHECK_PARAMETER(aSupported, E_POINTER);
*aSupported = true;
return S_OK;
}

And I try to force the desired resolution like this:

for (unsigned short nMonitorIndex = 0; nMonitorIndex < m_nMonitorCount;
++nMonitorIndex)
{
// Set full hd for all the screens
CHECK_HRESULT(m_pDisplay->SetVideoModeHint(nMonitorIndex, true, false, 0,
0, 1920, 1080, 32));
}

One monitor runs fine, 7 also work, I didn't have time now to find exact
boundary but I will do it. Bascially in all the configuriation the
VirtualBox logs shows the hint for 1920x1080 but a bit later just resizes
to 1280x720 and does not even try that. I'll mail you the source and logs
directly, thanks for the help.

Rudolfs
Post by Vitali Pelenjow
Actually VBoxHeadless sets framebuffers for each guest monitor (in VBox
4.3 or older).
Where exactly did you see that VBoxHeadless uses one IFramebuffer instance?
If no Framebuffer is assigned then graphics output from the VM does not
work.
I wonder why monitors in your guest resize to 1280x720.
Did you allow all modes in IFramebuffer::VideoModeSupported?
Can you run 1 monitor at 1920x1200?
How do you resize the guest monitors: from the guest or using VBoxManage
controlvm setvideomodehint?
BTW, you can send me source code of the framebuffer implementation and
code which sets framebuffers fro the VM.
I could take a look.
When I tested Win7 32 bit guest with VBoxHeadless and 24 monitors, I used
VBoxManage controlvm setvideomodehint to resize and enable them.
Vitali
Post by RÅ«dolfs Bundulis
Hi,
Post by Vitali Pelenjow
I just tested a VBoxHeadless VM with 24 monitors at 1920x1200 and 256 MB
of guest VRAM and it seems to work fine.
I fixed errors on my side, and still got the same (which is still much
better than with the WDDM driver) but it seems that you actually
cannot run that many monitors on full hd. I tried 25,24,20,16 and all
these numbers resized to 1280x720, didn't go much lower, but I will
find the boundary. I looked at VBoxHeadless, since it was mentioned
that it did work, and I saw that VBoxHeadless actually injects only
one IFramebuffer instance. So can that actually affect the behaivor?
What happens if no IFramebuffer implementation is provided for the a
display? Does that count as a disconnected video output or what?
2014-09-03 12:01 GMT+03:00 R?dolfs Bundulis
Hi,
I made a new Windows 7 machine and installed the guest additions
without the 3D support, verified that the XPDM files were
installed and now the machine booted to 1280x720 at all 25
monitors and my software acutally run out of memory for the
NV12/H264 buffers so I guess if I fix that I should be able to go
to 1920x1200, thanks for the pointers on XPDM, I'll fix everything
on my side with the memory and try again.
2014-09-02 17:07 GMT+03:00 R?dolfs Bundulis
Yes. However HGSMI is "The Interface" between the vitual
graphics card
and the host and
therefore can not be disabled.
Moreover HGSMI does not affect the memory allocation much.
The monitor count is limited by the screen surface memory.
Thanks a lot for the explanation.
_______________________________________________
vbox-dev mailing list
vbox-dev at virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
_______________________________________________
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/20140904/92c47e75/attachment.html
Vitali Pelenjow
2014-09-04 08:49:24 UTC
Permalink
Good to know that it works!

Thanks,
Vitali.
Hi Vitali,
no it does not. And I just found the issue, the H264 encoder was
actually stalling after the 1280x720 resize on all 25 monitors and
since I was checking this from home and I did not have access to the
actual wall, I did not see that. I fixed it an yeah, now I got all 25
to resize to full hd, after they were all resized to 1280x720. So with
XPDM the VRAM amount is sufficient for my needs. Seems that I'll have
to stack multiple GPU's or combine GPU/CPU encdoing to actually be
able to pull this amount of pixels off at 25fps. Sorry for that, I
hope I didn't take too much of your time with the verifications done
on your side and thank you both (you and Klaus) for the info - the
XPDM thing was very important, now I can run all the 5x5 wall with
full hd.
Best Regards,
Rudolfs Bundulis
2014-09-04 10:43 GMT+03:00 Vitali Pelenjow <Vitali.Pelenjow at oracle.com
Does the VM have 2d acceleration enabled (in the VM settings)?
Which version of VBox/guest addidions do you use?
Please also send me VBox.log of the VM with 25 monitors.
And the VM xml config file (VMNAME.vbox).
I tried with current VBox trunk. Used one of existing Win7 32 bit
VMs with XPDM driver.
I edited the .vbox xml config to set 256MB VRAM and 24 monitors.
Then started the VM with VBoxHeadless and on the host executed
a batch script with VBoxManage controlvm setvideomodehint for each
monitor.
Then connected to the VMs first monitor with a RDP client and
checked that
Display Properties in the guest show all 24 monitors at 1920x1200.
Vitali
Post by Vitali Pelenjow
I wonder why monitors in your guest resize to 1280x720.
Did you allow all modes in IFramebuffer::VideoModeSupported?
Can you run 1 monitor at 1920x1200?
How do you resize the guest monitors: from the guest or using
VBoxManage
Post by Vitali Pelenjow
controlvm setvideomodehint?
for (unsigned short nMonitorIndex = 0; nMonitorIndex <
m_nMonitorCount; ++nMonitorIndex)
{
// Set full hd for all the screens
CHECK_HRESULT(m_pDisplay->SetVideoModeHint(nMonitorIndex,
true, false, 0, 0, 1920, 1080, 32));
}
One monitor runs fine, 7 also work, I didn't have time now to
find exact boundary but I will do it. Bascially in all the
configuriation the VirtualBox logs shows the hint for
1920x1080 but a bit later just resizes to 1280x720 and does
not even try that. I'll mail you the source and logs directly,
thanks for the help.
Rūdolfs Bundulis
2014-09-04 09:04:19 UTC
Permalink
Post by Vitali Pelenjow
Good to know that it works!
Well, without the advices form you and Klaus I wouldn't have gone far, so
great thanks:) Btw, this is not that important, but since I plan to host
any OS with the wall, does OS X have any special tweaks like the windows
WDDM/XPDM that I should now about? So far I've checked Windows and XFCE and
they both worked fine, but Klaus arleady warned me that X11 is less
resource hungry than Windows. Does OS X fall into the same category as X11?
Post by Vitali Pelenjow
Good to know that it works!
Thanks,
Vitali.
Hi Vitali,
no it does not. And I just found the issue, the H264 encoder was actually
stalling after the 1280x720 resize on all 25 monitors and since I was
checking this from home and I did not have access to the actual wall, I did
not see that. I fixed it an yeah, now I got all 25 to resize to full hd,
after they were all resized to 1280x720. So with XPDM the VRAM amount is
sufficient for my needs. Seems that I'll have to stack multiple GPU's or
combine GPU/CPU encdoing to actually be able to pull this amount of pixels
off at 25fps. Sorry for that, I hope I didn't take too much of your time
with the verifications done on your side and thank you both (you and
Klaus) for the info - the XPDM thing was very important, now I can run all
the 5x5 wall with full hd.
Best Regards,
Rudolfs Bundulis
2014-09-04 10:43 GMT+03:00 Vitali Pelenjow <Vitali.Pelenjow at oracle.com
Does the VM have 2d acceleration enabled (in the VM settings)?
Which version of VBox/guest addidions do you use?
Please also send me VBox.log of the VM with 25 monitors.
And the VM xml config file (VMNAME.vbox).
I tried with current VBox trunk. Used one of existing Win7 32 bit
VMs with XPDM driver.
I edited the .vbox xml config to set 256MB VRAM and 24 monitors.
Then started the VM with VBoxHeadless and on the host executed
a batch script with VBoxManage controlvm setvideomodehint for each
monitor.
Then connected to the VMs first monitor with a RDP client and
checked that
Display Properties in the guest show all 24 monitors at 1920x1200.
Vitali
Post by Vitali Pelenjow
I wonder why monitors in your guest resize to 1280x720.
Did you allow all modes in IFramebuffer::VideoModeSupported?
Can you run 1 monitor at 1920x1200?
How do you resize the guest monitors: from the guest or using
VBoxManage
Post by Vitali Pelenjow
controlvm setvideomodehint?
for (unsigned short nMonitorIndex = 0; nMonitorIndex <
m_nMonitorCount; ++nMonitorIndex)
{
// Set full hd for all the screens
CHECK_HRESULT(m_pDisplay->SetVideoModeHint(nMonitorIndex,
true, false, 0, 0, 1920, 1080, 32));
}
One monitor runs fine, 7 also work, I didn't have time now to
find exact boundary but I will do it. Bascially in all the
configuriation the VirtualBox logs shows the hint for
1920x1080 but a bit later just resizes to 1280x720 and does
not even try that. I'll mail you the source and logs directly,
thanks for the help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140904/38be8db7/attachment-0001.html
Klaus Espenlaub
2014-09-04 09:23:45 UTC
Permalink
R?dolfs,
Post by RÅ«dolfs Bundulis
Post by Vitali Pelenjow
Good to know that it works!
Well, without the advices form you and Klaus I wouldn't have gone far,
so great thanks:) Btw, this is not that important, but since I plan to
host any OS with the wall, does OS X have any special tweaks like the
windows WDDM/XPDM that I should now about? So far I've checked Windows
and XFCE and they both worked fine, but Klaus arleady warned me that X11
is less resource hungry than Windows. Does OS X fall into the same
category as X11?
Today OS X in a VirtualBox VM is the very opposite of VRAM hungry. We
don't have any graphics driver for it, which means it runs using purely
the UEFI graphics support. To my knowledge this is limited to a single
screen.

We're planning to do an OS X graphics driver (as part of an eventually
complete set of guest additions), but as there doesn't seem to be any
potential paying customers it can't get a high priority.

Klaus
Post by RÅ«dolfs Bundulis
2014-09-04 11:49 GMT+03:00 Vitali Pelenjow <Vitali.Pelenjow at oracle.com
Good to know that it works!
Thanks,
Vitali.
Hi Vitali,
no it does not. And I just found the issue, the H264 encoder was
actually stalling after the 1280x720 resize on all 25 monitors
and since I was checking this from home and I did not have
access to the actual wall, I did not see that. I fixed it an
yeah, now I got all 25 to resize to full hd, after they were all
resized to 1280x720. So with XPDM the VRAM amount is sufficient
for my needs. Seems that I'll have to stack multiple GPU's or
combine GPU/CPU encdoing to actually be able to pull this amount
of pixels off at 25fps. Sorry for that, I hope I didn't take too
much of your time with the verifications done on your side and
thank you both (you and Klaus) for the info - the XPDM thing was
very important, now I can run all the 5x5 wall with full hd.
Best Regards,
Rudolfs Bundulis
2014-09-04 10:43 GMT+03:00 Vitali Pelenjow
<Vitali.Pelenjow at oracle.com <mailto:Vitali.Pelenjow at oracle.com>
<mailto:Vitali.Pelenjow at __oracle.com
Does the VM have 2d acceleration enabled (in the VM settings)?
Which version of VBox/guest addidions do you use?
Please also send me VBox.log of the VM with 25 monitors.
And the VM xml config file (VMNAME.vbox).
I tried with current VBox trunk. Used one of existing Win7 32 bit
VMs with XPDM driver.
I edited the .vbox xml config to set 256MB VRAM and 24 monitors.
Then started the VM with VBoxHeadless and on the host executed
a batch script with VBoxManage controlvm setvideomodehint for each
monitor.
Then connected to the VMs first monitor with a RDP client and
checked that
Display Properties in the guest show all 24 monitors at 1920x1200.
Vitali
Post by Vitali Pelenjow
I wonder why monitors in your guest resize to 1280x720.
Did you allow all modes in
IFramebuffer::__VideoModeSupported?
Post by Vitali Pelenjow
Can you run 1 monitor at 1920x1200?
How do you resize the guest monitors: from the guest
or using
VBoxManage
Post by Vitali Pelenjow
controlvm setvideomodehint?
for (unsigned short nMonitorIndex = 0; nMonitorIndex <
m_nMonitorCount; ++nMonitorIndex)
{
// Set full hd for all the screens
CHECK_HRESULT(m_pDisplay->__SetVideoModeHint(__nMonitorIndex,
true, false, 0, 0, 1920, 1080, 32));
}
One monitor runs fine, 7 also work, I didn't have time now to
find exact boundary but I will do it. Bascially in all the
configuriation the VirtualBox logs shows the hint for
1920x1080 but a bit later just resizes to 1280x720 and does
not even try that. I'll mail you the source and logs directly,
thanks for the help.
Rūdolfs Bundulis
2014-09-04 09:51:20 UTC
Permalink
Post by Klaus Espenlaub
Today OS X in a VirtualBox VM is the very opposite of VRAM hungry. We
don't have any graphics driver for it, which means it runs using purely
the UEFI graphics support. To my knowledge this is limited to a single
screen.
We're planning to do an OS X graphics driver (as part of an eventually
complete set of guest additions), but as there doesn't seem to be any
potential paying customers it can't get a high priority.
?
Hi,

ahh ok, I'll take that into account. Well still, for what I'm doing
VirtualBox is great. I looked at other VM's, and the best alternative I
found was using Spice with Xen, but I could not find direct memory access
in it like in VirtualBox, so that would introduce much latency.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140904/e1a8ead4/attachment.html
Loading...