[virglrenderer-devel] GSoC Intro: Vulkan-ize virgl

[Dave Airlie]

On 16 May 2018 at 06:23, Nathan Gauër <nathan.gauer at lse.epita.fr> wrote:
> On 15/05/2018 20:24, Chad Versace wrote:
>> On Thu 10 May 2018, Nathan Gauër wrote:
>>> Hello,
>>
>> Hi Nathan, I've also recently begun thinking about Vulkanizing virgl,
>> but am still becoming familiar with how virgl works for OpenGL.
>>
>>> I'm Nathan Gauër, a french student in computer science. For this
>>> year's Google Summer of Code, I've been selected to work on the Vulkan
>>> support for Virgl3D. My mentor is Marc-André Lureau.
>>
>>>      This project is kind of huge, and will require some changes in the
>>> Vulkan API. I'm not as familiar as you are with the API, thus, I would
>>> like to share my first ideas here.
>>
>> Yes, very huge :)
>>
>>> Question, do we want to use the idea of creating a resource in virgl,
>>> then attach it to a subcontext ?
>>
>> Could you explain this problem? I don't understand proposed idea of
>> attaching a resource to a subcontext.
>
> Hi,
>
> I might have written a weird sentence. It was more about what should
> we reuse, and should we split.
>
> As far as I understood, to create a 3D object linked to some data, we
> need to:
> - create a resource with a specific binding/target
> - attach it to a vgl-context
> - create a 3D object specific to a subcontext
> - attach this object to a resource
> - for data transfer, we have either the inline-write
>   or by sharing an IOV, and memcopying it to an OpenGL issued buffer
>
> (Minus shaders with TGSI tokens written directly in the 3D command)
>
> Thus, to add Vulkan objects, we could expand the existing
> object/resource creation functions.
> Maybe by adding new resource targets, and scrambling **a bit** the 3d
> object creation function.
>
> Or we could split the code a bit:
> - keep the resource + transfer part (modulo targets & bindings)
> - add a new part for VK 3D commands, detached from the OpenGL part.

I think we have to take a step back to involve vulkan in the virgl
pipeline here.

I think step one is to let qemu use vulkan instead of EGL, then use
Vulkan for memory/object allocation then interop GL with that.

The reason why is that GL can import Vulkan memory objects, but
Vulkan can't currently do the same for GL objects, (we might be
able to use some of the dma-buf extensions  to do it), but I think
using the VK memory objects should be sufficient, that we'd create
a memory object and import it into GL texture objects.

This design point is the one that has stalled most of my thoughts on
vulkan/virgl,
as virgl is really based on the guest objects are stored in host textures,
but how do you deal with that if you want host vulkan to interoperate,

Dave.