On Wed, Mar 11, 2020 at 04:36:16PM -0700, Gurchetan Singh wrote: > On Wed, Mar 11, 2020 at 3:36 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > > Hi, > > > > > I should've been more clear -- this is an internal cleanup/preparation > > and > > > the per-context changes are invisible to host userspace. > > > > Ok, it wasn't clear that you don't flip the switch yet. In general the > > commit messages could be a bit more verbose ... > > > > I'm wondering though why we need the new fence_id in the first place. > > Isn't it enough to have per-context (instead of global) last_seq? > > > > Heh, that was to leave open the possibility of multiple timelines per > context. Roughly speaking, > > V2 -- multiple processes > V3 -- multiple processes and multiple threads (due to VK multi-threaded > command buffers) > > I think we all agree on V2. It seems we still have to discuss V3 > (multi-queue, thread pools, a fence context associated with each thread) a > bit more before we start landing pieces. While thinking about the whole thing a bit more ... Do we need virtio_gpu_ctrl_hdr->fence_id at all? At virtio level it is pretty simple: The host completes the SUBMIT_3D virtio command when it finished rendering, period. On the guest side we don't need the fence_id. The completion callback gets passed the virtio_gpu_vbuffer, so it can figure which command did actually complete without looking at virtio_gpu_ctrl_hdr->fence_id. On the host side we depend on the fence_id right now, but only because that is the way the virgl_renderer_callbacks->write_fence interface is designed. We have to change that anyway for per-context (or whatever) fences, so it should not be a problem to drop the fence_id dependency too and just pass around an opaque pointer instead. cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
