On Mon, Feb 24, 2020 at 5:24 AM Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: > > On Mon, 24 Feb 2020 at 11:06, Gerd Hoffmann <kraxel@xxxxxxxxxx> 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@xxxxxxxxx> wrote: > > > > > > > > On Wed, Feb 19, 2020 at 2:34 PM Gurchetan Singh > > > > <gurchetansingh@xxxxxxxxxxxx> 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. Yeah, it should be safe to omit. The userspace might want to decide the "context type" based on the capsets. It should also be better to omit. > > HTH > Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
