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
