On Mon, Oct 1, 2018 at 3:04 PM Jordan Crouse <jcrouse@xxxxxxxxxxxxxx> wrote: > > On Mon, Oct 01, 2018 at 06:01:33PM +0530, Sharat Masetty wrote: > > Track the GPU fences created at submit time with idr instead of the ring > > the sequence number. This helps with easily changing the underlying > > fence to something we don't truly own, like the scheduler fence. > > > > Also move the GPU fence allocation to msm_gpu_submit() and have > > the function return the fence. This suits well when integrating with the > > GPU scheduler. > > > > Additionally remove the non-interruptible wait variant from msm_wait_fence() > > as it is not used. > > So basically this is just propping up the msm_wait_fence ioctl a bit more? > At what point should we just deprecate that bad boy and move on with our lives? > As I mentioned on IRC, wait_fence ioctl is still in use, so unfortunately I don't think we can just deprecate it. I guess it is worth some profiling, and if this shows up as enough overhead to care about perhaps we can introduce a submit ioctl flag to disable "old" fences. Personally, my guestimate about what we want to do for performance from a kernel standpoint is more towards introducing 64b reloc's (rather than using 2x 32b relocs), or possibly skip straight ahead to something like i915's softpin.. there are a couple other things that I'd started on a few months back to reduce userspace draw-overhead that I think I need to pick back up, but reloc overhead is something near the top of the list. (Reloc and submit overhead is partially mitigated with freedreno, since the way the driver is structured it gets pushed off to a background thread, but still I think there is some room for improvement.) BR, -R
