[PATCH 4/4 v6] drm/virtio: enqueue virtio_gpu_create_context after the first 3D ioctl

Emil Velikov emil.l.velikov at gmail.com
Mon Feb 24 13:23:50 UTC 2020


On Mon, 24 Feb 2020 at 11:06, Gerd Hoffmann <kraxel at redhat.com> wrote:
>
> On Fri, Feb 21, 2020 at 04:54:02PM -0800, Gurchetan Singh wrote:
> > On Fri, Feb 21, 2020 at 3:06 PM Chia-I Wu <olvaffe at gmail.com> wrote:
> > >
> > > On Wed, Feb 19, 2020 at 2:34 PM Gurchetan Singh
> > > <gurchetansingh at chromium.org> wrote:
> > > >
> > > > For old userspace, initialization will still be implicit.
> > > >
> > > > For backwards compatibility, enqueue virtio_gpu_cmd_context_create after
> > > > the first 3D ioctl.
> > > >
> > > > v3: staticify virtio_gpu_create_context
> > > >     remove notify to batch vm-exit
> > > > v6: Remove nested 3D checks (emil.velikov):
> > > >       - unify 3D check in resource create
> > > >       - VIRTIO_GPU_CMD_GET_CAPSET is listed as a 2D ioctl, added a
> > > >         3D check there.
> > > I missed this change.  Why do we need a context to get capsets?  Is
> > > this a workaround or something?
> >
> > No, don't need a context to get a capset.  The patch tries to create a
> > context when a 3D userspace first talks to the host, not when a 3D
> > userspace first needs a context ID.  If the latter is preferred, we
> > can do that too.
>
> I think it makes sense to exclude the capset ioctls here.
>
> Possibly they are used for non-3d-related capabilities at some
> point in the future.
>
> Also userspace gets capsets while checking device capabilities
> and possibly does so before deciding how to drive the device.
>
Virglrenderer creates the internal/base GL* context during
virgl_renderer_init().
Based upon which the caps are populated.

Personally I don't have a preference for/against dropping the
virtio_gpu_create_context().
Yet it does seems safe to omit.

HTH
Emil


More information about the dri-devel mailing list