On Thu, Dec 04, 2014 at 09:13:21AM +0000, Chris Wilson wrote: > On Wed, Dec 03, 2014 at 11:49:07AM -0800, Jesse Barnes wrote: > > This simplifies the sync code quite a bit. I don't think we'll be able > > to get away with using the core fence code's seqno support, since we'll > > be moving away from simple seqno comparisions with the scheduler and > > preemption, but the additional code is pretty minimal anyway, and lets > > us add additional debugging as needed, so it's probably fine to keep > > either way. > > > > We still need to add support for other rings here; we ought to be able > > to do that with the timeline field of the ioctl (which will include > > other "rings" like the display flip queue for example). > > I am ambivalent about this. I don't think migrating i915_request over to > use the heavyweight fence primitives is a good idea, so see little value > in embedding the struct fence inside i915_request vs a small bookkeeping > struct referencing i915_request. Which part of struct fence is too heavyweight? And I guess we could always add a slab or some cache if the allocation overhead is too much. I really like this conceptually so if there's a concern with overhead I want solid data for it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
