[vbox-dev] D3D support in custom frontend

Mon Jan 26 13:25:03 GMT 2015

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 <vadim.galitsyn at oracle.com>:

> 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 <rudolfs.bundulis at gmail.com>
> 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 <vadim.galitsyn at oracle.com>:
>
>> 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 <rudolfs.bundulis at gmail.com>
>> 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 <vadim.galitsyn at oracle.com>:
>>
>>> 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 <rudolfs.bundulis at gmail.com>
>>> 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 <vadim.galitsyn at oracle.com>:
>>>
>>>> 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 <
>>>> rudolfs.bundulis at gmail.com> 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
>>>> > 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/20150126/5cfb591c/attachment.html>