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

Nathan Gauër nathan.gauer at lse.epita.fr
Tue May 15 20:23:35 UTC 2018


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.

-- 
Nathan Gauër


More information about the virglrenderer-devel mailing list