[vbox-dev] OpenGL service screen redirection

[Rūdolfs Bundulis]

Hi Vitali,

great, thanks for the confirmations, this should be enough for me to try
out this, see if one GPU can actually pull off rendering at that resolution
and then further investigate what I can to accelerate Direct3D. Thanks for
the information and your time.

Best Regards,
Rudolfs Bundulis

2015-04-08 14:01 GMT+03:00 Vitali Pelenjow <Vitali.Pelenjow at oracle.com>:

> On 4/8/2015 12:56 PM, Rūdolfs Bundulis wrote:
>
>> Hi Vitali,
>>
>> >> the OpenGL output redirect was created only for VRDP 3D support.
>> Currently it is internal and can use only 1 redirect.
>>
>> I got the same impression from the sources. But if I am running a custom
>> frontend and disable VRDP (or to be more exact, do not allow to enable it),
>> and perform this call and occupy the single allowed redirect, then I should
>> be fine right?
>>
> Right.
>
>
>> >> The output redirect provides a bitmap of 3D frame when it is
>> displayed. If you have a 3D application in a window then you'll get
>> >> only content of the window.
>>
>> If I understand correctly then CRORGeometry gives me the window
>> dimensions so as far as I see there should be no issues with blitting it
>> over the contents of VRAM.
>>
> Correct.
>
>
>> >> As an alternative you could also use the screenshot API to get the
>> image. In this case you can choose the update interval and get the entire
>> screen.
>> Since I already have the VRAM contents from the IFramebuffer, asking for
>> the whole screen in parallel would be an overkill, and I also like the the
>> IFramebuffer methods provide the updated rectangle coordinates, that helps
>> me further down the pipeline with color conversion and encoding. If I get
>> the whole screen (which in my case is 9600x5400) that again downgrades the
>> performance.
>>
>> Please correct me if I'm getting something very wrong, but as far as I
>> see, combining the IFramebuffer updates and the frame callback from the
>> OpenGL service should do what I need since then I just update a region
>> inside the whole large screen with the 3D frame when it's done.
>>
> Yes, that is how VRDP 3D redirection works.
>
> Vitali.
>
>
>> Best Regards,
>> Rudolfs Bundulis
>>
>> 2015-04-08 13:41 GMT+03:00 Vitali Pelenjow <Vitali.Pelenjow at oracle.com
>> <mailto:Vitali.Pelenjow at oracle.com>>:
>>
>>
>>     Hi Rudolfs,
>>
>>     the OpenGL output redirect was created only for VRDP 3D support.
>>     Currently it is internal and can use only 1 redirect.
>>     The output redirect provides a bitmap of 3D frame when it is
>>     displayed. If you have a 3D application in a window then you'll get
>>     only content of the window.
>>
>>     As an alternative you could also use the screenshot API to get the
>>     image. In this case you can choose the update interval and get the
>>     entire screen.
>>
>>     Vitali.
>>
>>
>>     On 4/8/2015 9:50 AM, Rūdolfs Bundulis wrote:
>>
>>         Hi,
>>
>>         I am finally starting to look into 3D acceleration for my
>>         headless frontend and the first thing I wanted to try is the
>>         OpenGL output redirection to a frambuffer. Looking at the code
>>         I came down to the following question - what is the correct
>>         way to hook into the OpenGL service? Looking
>>         ConsoleVRDPServer.cpp it seems very straightforward -
>>         ConsoleVRDPServer::remote3DRedirect basically just does one
>>         HGSMI call SHCRGL_HOST_FN_SET_OUTPUT_REDIRECT but as far as I
>>         understand they are done through internal functions that are
>>         not exported by any of the dlls so I cannot hook into that,
>>         correct? The shared OpenGL dll exports a function
>>         crVBoxServerOutputRedirectSet where I can pass the same
>>         callbacks, so I assume I should use that, correct?
>>
>>         Best Regards,
>>         Rudolfs Bundulis
>>
>>
>>
>>         _______________________________________________
>>         vbox-dev mailing list
>>         vbox-dev at virtualbox.org <mailto: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/20150408/589ca0d6/attachment.html>