On Mon, Mar 22, 2021 at 5:52 AM Matthew Auld matthew.william.auld@gmail.com wrote:
On Sat, 20 Mar 2021 at 14:48, Jason Ekstrand jason@jlekstrand.net wrote:
On Fri, Mar 19, 2021 at 5:39 PM Jason Ekstrand jason@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