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@xxxxxxxxxxxxxxxxxx] > Sent: Tuesday, December 5, 2017 12:39 PM > To: Rogovin, Kevin <kevin.rogovin@xxxxxxxxx>; intel-gfx@lists.freedes > ktop.org > Subject: RE: [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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
