[Intel-gfx] [PATCH v5] drm/i915 : Added Programming of the MOCS

chris at chris-wilson.co.uk chris at chris-wilson.co.uk
Thu Jun 18 08:35:38 PDT 2015


On Thu, Jun 18, 2015 at 04:25:47PM +0100, Damien Lespiau wrote:
> >>On Thu, Jun 18, 2015 at 03:45:44PM +0100, Antoine, Peter wrote:
> >> So, intializing the other (non-render) MOCS in gen8_init_rcs_context()
> >> isn't the most logical thing to do I'm afraid. What happens if we
> >> suddenly decide that we don't want to fully initialize the default
> >> context at startup but initialize each ring on-demand for that context
> >> as well? We can end up in a situation where we use the blitter first
> >> and we wouldn't have the blitter MOCS initialized.
> >> 
> >> In that sense, that code makes an assumption about how we do things in
> >> a completely different part of the driver and that's always a
> >> potential source of bugs.
> >> 
> >
> >Yes, but this is the same with the golden context and the workarounds
> >(as I understand it) so all this code would have to be moved. 
> 
> Ah, but the workarounds in that function are only for registers in the
> render context, not other rings/engine.

Yes, but it just so happens that we initialise the default context
before userspace so that we know that context is pristine before sending
batches to the GPU.

This is the reason why I think it is important to mark this function as
being executed at that stage, so that all parties can be sure that the
execution is before real use of the GPU and so we can use the RCS to
initialise the other rings. At the moment, I am happy with baking that
assumption into the code, we can readdress it later if there are non-RCS
operations that must be performed at context init and conflict with the
RCS programming.

If you can think of a suitable comment to forewarn us in future about
potential conflicts in adding xcs->init_context(), be my guest.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list