Hi Vadim, ok clear, thanks for the info. We'll so far I haven't patched anything in the VBox code itself, as I said I have a custom frontend. Does that code help you in any way? I'll make a debug build and look for more messages and mail back if it gives any additional info, thanks for all the help so far. The main thing I wanted to understand was is there any way to see the output from the WARN macros in the miniport driver, and as far as I understand there is none.
Best Regards, Rudolfs Bundulis 2015-01-26 13:42 GMT+02:00 Vadim Galitsyn <[email protected]>: > Hi Rudolfs, > > Debug build of VBox itself would probably add a bit more messages to > VBox.log (and to debug log as well), but this definitely will not prevent > the fact that debug version of GAs cause BSOD. Is it possible if you share > a patch to OSE tree with your changes, so I could take a look at it later > this week (or another)? > > Vadim > > On 26 Jan 2015, at 14:00, Rūdolfs Bundulis <[email protected]> > wrote: > > Hi Vadim, > > Well since I also came to the the conclusion that the WinId could cause > this, I tried making a dummy window for each of the IFramebuffer instances, > but nothing changed. Though the windows do not have any logic in the > message loop, and I do not resize them when the resolutions change - maybe > this causes some errors. That is why I asked if any logs from the miniport > driver is available to see where does it actually crash. If I make a debug > VirtualBox build then would debug GAs work? > > Best Regards, > Rudolfs Bundulis > > 2015-01-26 12:50 GMT+02:00 Vadim Galitsyn <[email protected]>: > >> 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]>: >> >>> 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]> >>> 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] >>> > https://www.virtualbox.org/mailman/listinfo/vbox-dev >>> >>> >> >> > >
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
