[virglrenderer-devel] coherent memory access for virgl

[Erik Faye-Lund]

On ti., sep. 4, 2018 at 2:15 PM, Gerd Hoffmann <kraxel at redhat.com> 
wrote:
>   Hi,
> 
>>  > Also: how frequently will these objects be allocated/freed?
>>  >
>>  > I suspect GL_ARB_buffer_storage not so often.
>>  >
>>  > But vulkan?  It probably wants pretty much everything allocated 
>> that
>>  > way.  I expect it to be designed with the memory management 
>> capabilities
>>  > of modern GPUs in mind.  Don't know much about vulkan though ...
>> 
>>  It's a good practice to suballocate because allocation is considered
>>  expensive, but I guess that doesn't automatically mean that we can 
>> make
>>  allocations 10x slower...
> 
> So the mesa driver will ask for larger chunks and then hand out small
> allocations from that, right?  Would something like this be enough?
> 
>     struct virtio_gpu_resource_create_coherent {
> 	struct virtio_gpu_ctrl_hdr hdr;
> 	uint32_t resource_id;
> 	uint32_t flags;
> 	uint64_t offset; /* into pci bar */
> 	uint64_t size;
>     };
> 
> Or would we need the individual allocations be visible at virtio 
> level,
> so we can tell virglrenderer, with something like this:
> 
>     struct virtio_gpu_pool_create_coherent {
> 	struct virtio_gpu_ctrl_hdr hdr;
> 	uint32_t pool_id;
> 	uint32_t flags;
> 	uint64_t offset; /* into pci bar */
> 	uint64_t size;
>     };
> 
>     struct virtio_gpu_resource_create_coherent {
> 	struct virtio_gpu_ctrl_hdr hdr;
> 	uint32_t pool_id;
> 	uint32_t resource_id;
> 	uint64_t offset; /* into pool */
> 	uint64_t size;
>     };
> 
> Who will do the actual allocations?  I expect we need new 
> virglrenderer
> functions for that?
> 

So, I think there's a potential issue with the sub-allocating approach:

Section 10.3.6 ("Robust Buffer Access") of the OpenGL 4.3 specification
defines that contexts that are created with robust buffer access enabled
can rely on zero being returned for out-of-bounds accesses. However, if
we sub-allocate, we would end up with the wrong definition of what
out-of-bounds is, and return the values of neighboring sub-allocated
buffers instead.

This is assuming we would implement sub-allocation by creating one big
host-buffer and manipulating offsets to make them look like distinct
allocations. I'm not aware of any other way of implementing
sub-allocations for buffer objects in OpenGL...

So I suspect that for robust buffer access, we'll probably have to
allocate a lot of these buffers. It's a bit sad, but it's not the
use-case that needs to be the most performant either. robust buffer
access is there to trade performance for security...

>>  > I can look into this once I'm done with the vacation backlog.
>> 
>>  Do you want any help with prototyping this?
> 
> So far I have just a single patch adding a (not yet used) pci bar.
> 
> https://git.kraxel.org/cgit/qemu/log/?h=sirius/virtio-gpu-hostmap
> 
> Before continuing I need a more clear picture how the allocation
> workflow is going to work (see questions above), for both
> GL_ARB_buffer_storage and vulkan.  So, yes, help with that is welcome.

For Vulkan, things are luckily much easier, because memory-properties
and sub-allocation is a part of the API. We would simply expose a
fixed-size heap that has the coherent-bit set, and I think everything
will "just work".

We also played around with the idea that it might be possible to use
the vulkan memory allocator on the host, and use resource sharing
extensions to map these into the opengl-host. Sadly, I can't find any
Vulkan/OpenGL extensions that allow sharing buffers, only images...