On Mon, Mar 22, 2021 at 5:52 AM Matthew Auld <matthew.william.auld@xxxxxxxxx> wrote: > > 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? 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
