[vbox-dev] D3D support in custom frontend

Mon Jan 26 12:26:04 GMT 2015

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/dbcf349d/attachment.html>