Hi, any hints on how to understand if a Windows 7 guest OS uses XPDM or WDDM driver? I would be interrested to see if with XPDM I can actually reduce the needed memory for the surfaces.
2014-08-28 23:03 GMT+03:00 Rūdolfs Bundulis <[email protected]>: > Btw, here is a little demo of the 16 * 720p wall driven by virtualbox > > https://www.youtube.com/watch?v=eFAATNofjHA&feature=youtu.be > > > 2014-08-28 23:03 GMT+03:00 Rūdolfs Bundulis <[email protected]>: > > Hi Klaus, >> >> > Was the available monitor hardware limiting you to 16? Because with >> 720p and the XPDM driver (which is usable with Win7, and I think still the >> default if you don't enable 3D in the guest additions installer) you should >> be able to run > with 5x5, too. Needs "only" 226MB for the framebuffers. >> >> Well, that is the thing, I don't have the 3D checkbox checked, guest >> Windows does not allow to enable Aero (so I can assume WDDM is not used?) >> but the memory bar still warns me when I go above 8 monitors (seems that it >> always calculates 3 surfaces. Is there any way to check if XPDM or WDDM is >> actually being used? I could then confirm and fallback to XPDM if that >> gives me more screens. What I saw in practice is that 7 monitors booted >> fine in Full HD, when I ran 8 my hint to use 1920x1080 was ignored and all >> 8 monitors got 1600x1200 resolution, increasing above 10 pushes the >> resolution down to 1400 x 1050 and so on until when booting with 25 Windows >> reports only one display at 800x600 (I guess it is simply an overkill for >> the VRAM). If I could verify if WDDM/XPDM is being used it would become >> more clear if I can go higher. >> >> > Another option might be using 15 or 16bpp in the guest *and* on the >> host (otherwise color format conversion is necessary, and this kills >> performance as VirtualBox uses the CPU for that). The GUI again is >> pessimistic and always ? > expects 24bpp (4 bytes, the packed format again >> is unbearably slow as it needs conversion), but the virtualizer would work >> just fine. This would fit into 248MB with 5x5 @1920x1080. Yes, the reduced >> color resolution sucks, it usually results in heavy color banding. >> >> One of the guys involved on our side also suggested this, but we are >> perofming live video encoding from the framebuffer, 32bpp is great since >> that can be fed directly to the encoder, anything else will have to be >> repacked which would not be feasable. Not sure, but since Xubuntu ran >> really slow, I have a theory that the offscreen surfaces could actually be >> very useful, since if X11 syncs every draw with the primary surface and >> locks it, and my software also needs to lock the surface for to at least >> copy the data, this could be the reason why Xubuntu performs poorly. >> >> > Oh sure, we know that VirtualBox can do amazing things (in some areas >> going far beyond what any virtualizer out there can do), and often shows >> its great scalability in setups which are a little outside the norm :) >> >> Yeah, I am really impressed, when I started my PhD work I was a lot in >> the dark, wanted to write virtual video card drivers etc., but this is >> flexible scalable and great, of course if the VRAM limit can be broken. >> Well I'll lurk around the sources and try to get a grasp of the VRAM >> things, maybe it is possible to do something there. Thanks a lot for all >> the input. >> >> >> 2014-08-28 22:12 GMT+03:00 Klaus Espenlaub <[email protected]>: >> >> Rūdolfs, >>> >>> >>> On 28.08.2014 18:15, Rūdolfs Bundulis wrote: >>> >>>> Hi Klaus, >>>> >>>> I'll mail directly to you this time, since this is not regarding the >>>> original issue. >>>> >>> >>> Actually if you'd stay on the list then you'd have a chance of getting >>> more than one team member's knowledge... I'm not really a graphics expert. >>> >>> >>> I ran some tests today, and it seems that at least on >>>> Windows 7 16 monitors on 1280x720 (720p) work fine. Using our software I >>>> streamed that to a 4x4 22" monitor wall and that looked really >>>> impressive. >>>> >>> >>> Was the available monitor hardware limiting you to 16? Because with 720p >>> and the XPDM driver (which is usable with Win7, and I think still the >>> default if you don't enable 3D in the guest additions installer) you should >>> be able to run with 5x5, too. Needs "only" 226MB for the framebuffers. >>> >>> Another option might be using 15 or 16bpp in the guest *and* on the host >>> (otherwise color format conversion is necessary, and this kills performance >>> as VirtualBox uses the CPU for that). The GUI again is pessimistic and >>> always expects 24bpp (4 bytes, the packed format again is unbearably slow >>> as it needs conversion), but the virtualizer would work just fine. This >>> would fit into 248MB with 5x5 @1920x1080. Yes, the reduced color resolution >>> sucks, it usually results in heavy color banding. >>> >>> >>> Also tried Xubuntu 14.04 on same configuration but for >>>> somewhat reason (X11) it was lagging terribly. The question that arose >>>> was, could you at least provide some base info (as far as it does not >>>> take too much of your time) what needs to be patched to increase the >>>> VRAM size? >>>> >>> >>> The easy part is VGA_VRAM_MAX in src/VBox/Devices/Graphics/DevVGA.h and >>> VRAMSize in src/VBox/Main/xml/VirtualBox-settings.xsd. Not sure if >>> there are a few more "256 MB" definitions somewhere. >>> >>> I bet you'll run into trouble with PCI resource allocation (in our case >>> done in the code before the VM starts, not in the BIOS like with >>> conventional PCs), because the bigger area will not fit into the PCI hole >>> (which is actually normal, I think real systems start with a partial >>> mapping of the VRAM there, and the graphics driver then relocates it to a >>> free area past 4GB, at least with 64 bit OSes which can deal properly with >>> the then necessary 64 bit PCI resources). >>> >>> Similarly I guess the BIOS e820 memory map will most likely be broken. >>> >>> Many real graphics cards can work with a partially mapped VRAM, giving >>> access only to 256MB at a time. This would need big changes to our virtual >>> graphics card and the guest additions driver, but would minimize the need >>> to change other places. >>> >>> >>> Our research time consists of quite skilled developers so if >>>> it is not a man-year we would be interrested at least to look into it, >>>> since the 16@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 <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> >>>> On 27.08.2014 <tel:27.08.2014> 18:38, Rūdolfs Bundulis wrote: >>>> > Hi Klaus, >>>> > >>>> > Thanks again for the fast response. Well, this is a university >>>> research >>>> > project to build monitor walls without the underlying hardware, >>>> so I >>>> > guess its reasonable that I am breaking some limits that should >>>> be >>>> > normal in a normal use case. >>>> >>>> As long as you're only going for high monitor counts, that's nothing >>>> unexpected. >>>> >>>> > Regarding 3D, when I installed guest additions I checked the >>>> Direct3D >>>> > box but I dont have the "Enable 3D acceleration" checkbox >>>> checked in >>>> > the VirtualBox manager. Should I reinstall the guest additions >>>> without >>>> > Direct3D? >>>> >>>> Strange... I wonder why the GUI is so eager with insanely high VRAM >>>> proposals. It should only care about the checkbox, because if >>>> that's not >>>> set then there is no 3D, period. >>>> >>>> From what I remember, the "rule of thumb" for the absolute minimum >>>> VRAM >>>> size (in bytes) is (x*y*4+4096+1048576)*count. At least it was >>>> accurate >>>> with the X11 driver, and the GUI seems to agree. It seems the XPDM >>>> driver needs twice that much (because Windows needs one offscreen >>>> surface), and with the WDDM driver it needs thrice that much (two >>>> offscreen surfaces). >>>> >>>> Which guest OS are you using? Which driver did you install (for >>>> those >>>> OSes which allow selecting)? >>>> >>>> > And more important, is it actually possible to fit 25 full hd >>>> > (1920x1080) framebuffers in the video ram if it is only 256mb >>>> inside >>>> > virtualbox? I could try to recompile from sources with lets say >>>> 1GB if >>>> > redefining the video memory macro does not break other stuff. >>>> >>>> Barely... the above formula gives 223MB already, and if the Windows >>>> driver really need the mentioned amount of offscreen memory you'd >>>> run >>>> out of VRAM. I'd use VBoxHeadless to try this out actually, because >>>> it >>>> doesn't have any of those annoying safeguards to protect users from >>>> shooting themselves in the foot. >>>> >>>> Increasing the VRAM size by recompiling will cause trouble, as it >>>> would >>>> need drastic changes to the memory layout (PCI memory hole, ...), >>>> and >>>> I'm quite sure that we looked at it and considered it too much >>>> effort. >>>> Everything is doable in the end, that's the good and bad thing about >>>> software :) >>>> >>>> Klaus >>>> >>>> > Best Regards, >>>> > Rudolfs Bundulis >>>> > From: Klaus Espenlaub >>>> > Sent: 2014.08.27 <tel:2014.08.27>. 19:05 >>>> > To: [email protected] <mailto:[email protected]> >>>> >>>> > Subject: Re: [vbox-dev] Monitor count limitations >>>> > Hi Rūdolfs, >>>> > >>>> > On 27.08.2014 <tel:27.08.2014> 16:49, Rūdolfs Bundulis wrote: >>>> >> Hi, >>>> >> >>>> >> I've run into some more issues with high monitor count on >>>> VirtualBox. >>>> >> Basically when selecting 25 displays it complains that at least >>>> 600 >>>> >> something MB of VRAM is needed, but while the arrows in the >>>> display >>>> >> number box allow to select more than 8 monitors, seems that i >>>> can't go >>>> >> above 256 mb in VRAM. Is this a hard limitation? Since the COM >>>> API also >>>> >> does not allow me to set more than that. >>>> > >>>> > Sounds like you have 3D enabled - then the GUI does a little too >>>> simple >>>> > maths, extrapolating the necessary space beyond sanity. It's >>>> only a >>>> > proposal, not a hard "must have". Don't think anyone tried to go >>>> to such >>>> > extremes, because it's just nonsense to expect even basic 3D >>>> able to >>>> > cope with so many screens. >>>> > >>>> > If you disable 3D then the requirements should be a lot lower, >>>> in the >>>> > order of what's needed to represent the pixels. >>>> > >>>> > Yes, there is currently a hard limit of 256 MiB VRAM, and we >>>> didn't find >>>> > cases where it was absolutely necessary to have more. >>>> > >>>> > Klaus >>>> >> Best Regards, >>>> >> Rudolfs Bundulis >>>> >> >>>> >> >>>> >> 2014-06-18 13:41 GMT+03:00 Rūdolfs Bundulis >>>> <[email protected] <mailto:[email protected]> >>>> >> <mailto:[email protected] >>>> >>>> <mailto:[email protected]>>>: >>>> >> >>>> >> 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 >>>> >> <[email protected] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] >>>> >>>> <mailto:[email protected]>>>: >>>> >> >>>> >> Hi Rūdolfs, >>>> >> >>>> >> On 18.06.2014 11:48, Rūdolfs Bundulis wrote: >>>> >> > Hi, >>>> >> > >>>> >> > I'm developing a system that needs to run a headless >>>> VM with >>>> >> a large >>>> >> > number of attached monitors - currently the GUI has >>>> the limit >>>> >> to set >>>> >> > maximum monitor count to 8, I didn't check the COM >>>> API myself >>>> >> but I >>>> >> > suspect that it will not allow me to set the count >>>> greater >>>> >> than 8, while >>>> >> > browsing the VirtualBox sources show that the >>>> internal C macro is >>>> >> > defined to 64: >>>> >> > >>>> >> > /* this should be in sync with monitorCount >>>> <xsd:maxInclusive >>>> >> > value="8"/> in >>>> >> src/VBox/Main/xml/VirtualBox-settings-common.xsd */ >>>> >> > #define VBOX_VIDEO_MAX_SCREENS 64 >>>> >> >>>> >> Looks to me that this comment is simply outdated. >>>> Nothing more, >>>> >> nothing >>>> >> less. >>>> >> >>>> >> Many limits can be listed with "VBoxManage list >>>> >> systemproperties", and >>>> >> it shows 64. >>>> >> >>>> >> > Is there really a need to limit the count to 8? If I >>>> change >>>> >> the xml >>>> >> > schema file and increase the count from 8 to 64 and >>>> recompile >>>> >> would >>>> >> > there be any actual limitations in the VirtualBox >>>> core? >>>> >> >>>> >> There is a constant conflict in the GUI between sanity >>>> (i.e. >>>> >> protecting >>>> >> users against their stupidity - you can't believe how >>>> many people >>>> >> believe that more is better, even if it's a giant waste >>>> of resources >>>> >> instead) and allowing expert users to go to the >>>> extreme. There are >>>> >> extremely few people out there who ever need to deal >>>> with more >>>> >> than 8 >>>> >> monitors. >>>> >> >>>> >> In my quick test I could use the GUI to select 20 >>>> monitors - >>>> >> sure, the >>>> >> slider doesn't allow that, but one can enter the number >>>> or use the >>>> >> up/down arrows. This needs 256MB of VRAM, which this >>>> high number >>>> >> automatically unlocks. >>>> >> >>>> >> Klaus >>>> >> >>>> > >>>> >>>> >> >
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
