[virglrenderer-devel] coherent memory access for virgl

[Gerd Hoffmann]

  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 ...

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?

> 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.

cheers,
  Gerd