On Tue, Mar 17, 2020 at 12:18:47PM -0500, Jason Ekstrand wrote: > On Tue, Mar 17, 2020 at 12:13 PM Jacob Lifshay <programmerjake@xxxxxxxxx> wrote: > > > > One related issue with explicit sync using sync_file is that combined > > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the > > rendering in userspace (like llvmpipe but for Vulkan and with extra > > instructions for GPU tasks) but need to synchronize with other > > drivers/processes is that there should be some way to create an > > explicit fence/semaphore from userspace and later signal it. This > > seems to conflict with the requirement for a sync_file to complete in > > finite time, since the user process could be stopped or killed. > > Yeah... That's going to be a problem. The only way I could see that > working is if you created a sync_file that had a timeout associated > with it. However, then you run into the issue where you may have > corruption if stuff doesn't complete on time. Then again, you're not > really dealing with an external unit and so the latency cost of going > across the window system protocol probably isn't massively different > from the latency cost of triggering the sync_file. Maybe the answer > there is to just do everything in-order and not worry about > synchronization? vgem does that already (fences with timeout). The corruption issue is also not new, if your shaders take forever real gpus will nick your rendering with a quick reset. Iirc someone (from cros google team maybe) was even looking into making llvmpipe run on top of vgem as a real dri/drm mesa driver. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
