Hi Rudolfs, As far as I can understand, returning NULL WinID might cause the behaviour you are observing on Windows host (please note, I have not tried that locally, take it like a gesture). Seems, you also already have 3D host service running. Can you try to provide valid WinID to Main/src-client stuff as an experiment and see if things changed?
Regarding to GAs, I am afraid you’ll have a BSOD in guest once you attempt to boot VM with debug GAs installed. We currently have some debug R0 assertion there. Vadim > On 26 Jan 2015, at 13:12, Rūdolfs Bundulis <[email protected]> wrote: > > Hi Vadim, > > thanks for the pointers, I'll look up the code, I was already afraid that > something is simply missing. > > To describe what I am doing: > I am running a research project in University of Latvia where we are trying > to use VirtualBox for large scale high resolution display wall construction - > basically we run VirtualBox with a custom frontend that takes the video data > from the VRAM, encodes it and streams over to a display wall, currently we've > been able to run a 9600x5400 surface with Windows XPDM (we set this > resolution as a hint and then internally split it to 5*5 1920x1080 displays) > , which is really impressive, so thanks again for the great software. In > terms of resolution I guess this is as far as the existing 256MB VRAM limit > in VirtualBox can go (at least according to the calculations for framebuffer > needs provided by Klaus Erspenlaub and mentioned in your code). Since the > resolution limit is reached we are trying to address two more issues - 3D > support and a weird unaligned stack crash in VBoxREM.dll with more than 1 CPU > shared to the machine (for the second issue I need to do some more research > as to where it is coming from before I ask any help here). As for the 3D - > we'd basically want our software to function in the same way the VirtualBox > QT client does, but currently it does not. Thanks for the pointer about the > HGCM/OpenGL service, I'll check out that code and see what I can adapt. > > Our software basically uses the VirtualBox COM interface to create the needed > machine, set the number of displays/resolutions, injects the IFramebuffer > instances and powers up the machine via the IConsole interface. So I examined > all the IFramebuffer implementations in VirtualBox frontends, and didn't see > anything very special in the 3D related callbacks there. As for the log - I > tried to compare the log of a session from our software with a session from > the same machine under QT fronted where the 3D acceleration works. Basically > there were no errors and differences, in both cases the logs contained the > lines about OpenGL support (i guess this comes from the OpenGL capability > test exe), I'll send both logs as soon as I get back to that machine but I > doubt they'll give much help, since they don't have any errors, and in both > of them the guest additions log line states that acceleration is supported. > Basically the only thing that differs is that the D3D/OpenGL (we've tried > both API's, since the test application is built on Unity it is trivial to > force either mode) device creation fails on our frontend. That is why I asked > about the get_WinId, I examined the miniport driver code and as far as I > understood it uses the window id value to create a swap chain. Out frontend > does not have an actual window, so I am always returning NULL, can this cause > an error? I also saw that the miniport driver has a lot of WARN macros, is > the output visible anywhere? I tried using DebugView but that didn't help? > Should I try building a debug version of guest additions to get some log > information? > > Best Regards, > Rudolfs Bundulis > > 2015-01-26 10:34 GMT+02:00 Vadim Galitsyn <[email protected] > <mailto:[email protected]>>: > Hi Rudolfs, > > In order to provide 3D acceleration, VBox HGCM/OpenGL host service should be > running. It is currently a part of VirtualBoxVM process (ShCrOpenGL thread). > In order to provide 3D acceleration support for your frontend, I am afraid, > you need to adapt stuff from this thread for your code. And I am afraid this > might be not that easy (there is a bit of magic when VBox GUI conversates w/ > 3D stuff). Please refer to src/VBox/HostServices/SharedOpenGL and > src/VBox/GuestHost/OpenGL sources. > > Btw, if you describe a little bit more why do you need this and what you > already have done, maybe I could explain you more things/steps you need to do > in order to reach the goal. VBox.log also might be helpful. > > Vadim > > > > On 24 Jan 2015, at 14:14, Rūdolfs Bundulis <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi, > > > > I'm having a bit of a hard time understanding why my custom framebuffer > > cannot use the 3D acceleration feature. I have a Windows 7 guest machine > > (3D acceleration enabled, guest additions installed) and a Unity demo > > application. Under the default QT GUI the application launches fine, while > > under my frontend Unity is not able to create the D3D device. First I > > though that this could be due to incorrect implementation of IFramebuffer, > > but when I looked at UIFrameBuffer::Notify3DEvent(ULONG uType, BYTE *pData) > > in UIFrameBuffer.cpp there wasn't any special magic there. Are there any > > hints to guide me towards understanding the cause of this? Is there any > > tracing facilities for the guest miniport driver? Also, I don't have a > > window handle for my frontend since there is no actual window. If I am > > returning 0 in get_WinId in my framebuffer can that mess things up? > > > > Best Regards, > > Rudolfs Bundulis > > _______________________________________________ > > vbox-dev mailing list > > [email protected] <mailto:[email protected]> > > https://www.virtualbox.org/mailman/listinfo/vbox-dev > > <https://www.virtualbox.org/mailman/listinfo/vbox-dev> > >
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
