[Intel-gfx] [PATCH 1/4] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE

[Jason Ekstrand]

On Mon, Mar 22, 2021 at 5:52 AM Matthew Auld
<matthew.william.auld at gmail.com> wrote:
>
> On Sat, 20 Mar 2021 at 14:48, Jason Ekstrand <jason at jlekstrand.net> wrote:
> >
> > On Fri, Mar 19, 2021 at 5:39 PM Jason Ekstrand <jason at jlekstrand.net> wrote:
> > >
> > > This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a.  This API
> > > has never been used by any real userspace.
> >
> > After further digging, there is a compute-runtime PR for this.  I
> > still think we should drop it and I've updated the commit message
> > locally with the following rationale:
> >
> >     This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a.  This API
> >     was originally added for OpenCL but the compute-runtime PR has sat open
> >     for a year without action so we can still pull it out if we want.  I
> >     argue we should drop it for three reasons:
> >
> >      1. If the compute-runtime PR has sat open for a year, this clearly
> >         isn't that important.
> >
> >      2. It's a very leaky API.  Ring size is an implementation detail of the
> >         current execlist scheduler and really only makes sense there.  It
> >         can't apply to the older ring-buffer scheduler on pre-execlist
> >         hardware because that's shared across all contexts and it won't
> >         apply to the GuC scheduler that's in the pipeline.
>
> Just a drive-by-comment. I thought the lrc model was shared between
> execlists and the GuC, so in both cases we get something like a ring
> per engine per context which the driver can emit commands into. Why
> doesn't ring size still apply with the GuC scheduler?

Even if they both have a ring in some sense, the number of bytes which
correspond to a single request is going to be different and that
difference isn't visible to userspace so bytes is the wrong unit.

--Jason