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@xxxxxxxxx wrote: > > > From: Sourab Gupta <sourab.gupta@xxxxxxxxx> > > > > > > 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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
