Hi Vitali, this was what I was looking for, much appreciated :)
Best Regards, Rudolfs Bundulis 2015-01-26 14:59 GMT+02:00 Vadim Galitsyn <[email protected]>: > Hi Rudolfs, > > you could add LogRel() messages and they should appear in release log > (VBox.log file) once VBox has been built w/ corresponding flag. Note, that > this only works for guest R0 code (miniport). Adding LogRel() to R3 code > (display driver) will not result in extra messages in log. > > Please consider to add VBOX_WITH_R0_LOGGING=1 into LocalConfig.kmk in > order to enable LogRel()’s. > > Vadim > > On 26 Jan 2015, at 15:26, Rūdolfs Bundulis <[email protected]> > wrote: > > 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
