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

[Nathan Gauër]

Hello,

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.

Step 1: Vulkan support check
============================

A suggestions from Dave Airlie:
-> no Vulkan support on hosts without Vulkan

Thus, first step is to add a way for the guest to check if there is
any Vulkan support. This could be done adding a Vulkan_supported flag
in the virgl_caps_v2.

addition:
- a caps bit in virgl_caps_v2

Step 2: Device query
====================

We need to expose some devices to the application.
What we could do is to add a virgl command to let the host register
devices he wants to share.
The guest would then query a mapping to devices properties.
It could be a null terminated struct list, mapped in the guest.
Thus, when an application asks to enumerate device infos, the ICD
would fill a struct using the mapped informations.

addition:
- a command in the virgl API: virgl_vulkan_register_device by ex,
which would take the vendorID and deviceID of the device to expose.

- a command for the guest to request a device-info mapping.
same as the enumerate command, the guest would first call it with
NULL. Get the size, and then, recall it with the needed allocated space.
The tracking would be kept in the VIRGL_CONTEXT like a resource.

Step 3: Logical Devices & Objects
=================================

Maybe we could keep the 'instance' abstraction on the guest. However,
it might be great to keep track of the logical devices on the host.
(As we do for 3D contexts)
Thus, add a command to create a logical device in virgl to keep track
of the objects. (Similar to CCMD 3D context)

Then, we'd need to allocate/bind several type of objects. Which will
all be related to the created logical device. This will sounds similar
to the existing VIRGL_CCMD_* functions.

For the Map/Unmap commands:
The VK command vkMapMemory gives us a pointer and we could share this
mapping to the guest.
(depending of the outcome of the on-going discussion to allow guest to
use host mapped memory for resource transfer)

Question, do we want to use the idea of creating a resource in virgl,
then attach it to a subcontext ?

addition:
- a command in virgl API: 'virgl_vulkan_submit_cmd' by ex.
- sub-commands to create/bind objects
- sub-commands or command to map/unmap memory


Well, this already looks like a lot of work to do it properly.
If you have any idea/comment/something, I would love to hear it.

best regards,

-- 
Nathan Gauër