Re: [PATCH 1/4] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 20 Mar 2021 at 14:48, Jason Ekstrand <jason@xxxxxxxxxxxxxx> wrote:
>
> On Fri, Mar 19, 2021 at 5:39 PM Jason Ekstrand <jason@xxxxxxxxxxxxxx> 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?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux