[virglrenderer-devel] coherent memory access for virgl

[Tomeu Vizoso]

On 08/07/2018 12:23 PM, Gerd Hoffmann wrote:
>    Hi,
> 
> [ just back from summer vacation ]
> [ adding paolo to Cc: ]
> 
> On Tue, Jul 31, 2018 at 06:28:23AM +1000, Dave Airlie wrote:
>> I think we've pretty much nailed GL4.3 + GLES3.1/2 in terms of
>> features, which leads us to the next big milestones.
>>
>> a) GL 4.4 - specifically GL_ARB_buffer_storage
>> b) vulkan.
>>
>> Both of these are going to require coherent memory access from the
>> guest to resources on the host.
> 
> [ ... ]
> 
>> I expect we need to use a PCI BAR for this behaviour,
> 
> Layering violation.
> 
> But given that virtio is designed to have the guest allocate the buffers
> and it simply has no methods to allow the guest access host-allocated
> ressources that is still the best option we have I guess.
> 
> Paolo?  Any better suggestions?
> 
>> I'm not sure how
>> large or many objects implementations expect to be able to map
>> consistent and persistent
>> at the same time, so having a restricted BAR side could be quite
>> limiting here, I suppose we could make a 64-bit BAR and have it quite
>> large in order to accomodate
>> this.
> 
> 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...

> Beside that I expect once we have that people will find other uses for
> it.  Using it for dumb drm buffers to avoid memcpy for display updates
> for example.
> 
>> However if we have a BAR space we will need to memory manage it
>> and add eviction of objects in it (they can always be paged back on on
>> next access).
> 
> Yes.  I see basically two ways to do that:
> 
>    (1) Use qemu memory regions for objects.  Easy to implement.  But any
>        object allocation will result in a kvm slots update then (object
>        releases can be done lazy to batch them), so I suspect it is not
>        the best choice performance-wise.
>    (2) Grab a block of qemu process address space as backing storage for
>        the bar, then manage it with mmap(MAP_FIXED, ...).
> 
> Comments?  Other suggestions?

Both options sound good to me.

>> Anyone got any better/worse/pitfalls. I'm also not sure if I'm the
>> best person to work on this, so if someone is really interested and
>> has bandwidth I think it would
>> definitely be a thing to get moving on.
> 
> I can look into this once I'm done with the vacation backlog.

Do you want any help with prototyping this?

Regards,

Tomeu