[Intel-gfx] [PATCH 3/3] i965: check scratch page in a locked fashion on each ioctl

[Joonas Lahtinen]

On Tue, 2017-12-05 at 10:41 +0000, Rogovin, Kevin wrote:
> Thanks, I will make a v2 and post it shortly to correct for my
> terribly embarrassing omission caused by even more terribly
> embarrassing ignorance.

To avoid v3, do concept the code around suggested existing
I915_GEM_CONTEXT_GETPARAM and I915_GEM_CONTEXT_SETPARAM ioctls. Just
add a new parameter I915_CONTEXT_PARAM_SCRATCH_PAGE. The interface
should become pretty bullet-proof that way.

Regards, Joonas

> 
> -Kevin
> 
> -----Original Message-----
> From: Chris Wilson [mailto:chris at chris-wilson.co.uk] 
> Sent: Tuesday, December 5, 2017 12:39 PM
> To: Rogovin, Kevin <kevin.rogovin at intel.com>; intel-gfx at lists.freedes
> ktop.org
> Subject: RE: [Intel-gfx] [PATCH 3/3] i965: check scratch page in a
> locked fashion on each ioctl
> 
> Quoting Rogovin, Kevin (2017-12-05 10:30:04)
> > Hi,
> > 
> > > Per context, then you can remove the locking. It's fitting since
> > > the scratch page is per-context anyway.
> > 
> >  The scratch page is per context? This I did not know, I thought it
> > was per PPGTT. If that is the case, then my proposed interface to
> > get/set the scratch page contents is wrong because it does not pass
> > the HW context id.
> 
> Yes, it per-vm, which is per-ctx on everything you want to
> investigate on. gen4-7 it is a global GTT with a global scratch, and
> just a mutex inside one process is not going to give you atomicity.
> -Chris
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation