Re: [RFC 1/8] drm/i915: Have globally unique context ids, as opposed to drm file specific

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, Jul 15, 2015 at 11:31:32AM +0100, Chris Wilson wrote:
> On Wed, Jul 15, 2015 at 10:54:28AM +0100, Chris Wilson wrote:
> > On Wed, Jul 15, 2015 at 02:16:56PM +0530, sourab.gupta@intel.com wrote:
> > > From: Sourab Gupta <sourab.gupta@intel.com>
> > > 
> > > Currently the context ids are specific to a drm file instance, as opposed
> > > to being globally unique. There are some usecases, which may require
> > > globally unique context ids. For e.g. a system level GPU profiler tool may
> > > lean upon the context ids to associate the performance snapshots with
> > > individual contexts. If the context ids are unique, it may do so without
> > > relying on any additional information such as pid and drm fd.
> > > 
> > > This patch proposes an implementation of globally unique context ids, by
> > > conceptually moving the idr table for holding the context ids, into device
> > > private structure instead of file private structure. The case of default
> > > context id for drm file (which is given by id=0) is handled by storing the
> > > same in file private during context creation, and retrieving as and when
> > > required.
> > > 
> > > This patch is proposed an an enabler for the patches following in the
> > > series. In particular, I'm looking for feedback on the pros and cons of
> > > having a globally unique context id, and any specific inputs on this
> > > particular implementation. This implementation can be improved upon, if
> > > agreed upon conceptually.
> > 
> > Simpler: use a cyclic idr for global context ids. The importance here is
> > that for the common case we have a more friendly per-file small lookup
> > table and reporting, also the code should be more understandable with a
> > separate user_handle and guid.
> 
> I should emphasize that we really do want to keep user_handle inside a
> per-file namespace.

Yeah agreed, if we need some global internal ID because we need it in the
hw somewhere then that should be tracked in a separate hw_id field, and
allocated from a separate idr. That would also allow us to correctly
implement any restrictions the hw has (iirc we don't have the full 32bit
for ctx id, but not sure).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx