[virglrenderer-devel] multiprocess model and GL

[Gerd Hoffmann]

> > Because they're defined in different headers and used by different ioctls:
> >
> > execbuffer: https://github.com/freedesktop/virglrenderer/blob/master/src/virgl_protocol.h
> > resouce create v1:
> > https://github.com/freedesktop/virglrenderer/blob/master/src/virgl_hw.h
> >
> > (note the formats and binding types -- virglrenderer wouldn't work without it)
> >
> > So I wouldn't call the resource create v2 protocol as execbuffer.
> I will say virgl_hw.h is a part of the virgl_protocol.h.  Together,
> they define the virgl protocol.  If you look at the various _FORMAT
> fields in virgl_protocol.h, they refers to the formats defined in
> virgl_hw.h.
> 
> I think a more fair way to put this is that some of the virgl protocol
> details are leaked by drm_virtgpu_resource_create.

Indeed.  We have some funny hard-coded values in the kernel because of
that, when creating dumb resources via CREATE_3D, which don't make sense
at all unless you have a look at the virgl protocol.

> IMO, a reasonable
> way to plug the leak is to make sure the virgl protocol details are
> contained in EXECBUFFER in resource create v2.

Agreeing here.

I'm not fully though whenever execbuffer is the best option for gbm
allocations.  gbm is just an allocation thing, not a full rendering
protocol, so IMHO gbm objects are more like dumb object.  Specifically
you'll go create them outside a context and go bind them to a gl/vk
context later on to use them for rendering ...

cheers,
  Gerd