On Sun, May 28, 2017 at 09:43:35AM -0400, Rob Clark wrote: > On Mon, May 8, 2017 at 4:35 PM, Jordan Crouse <jcrouse@xxxxxxxxxxxxxx> wrote: > > Add the infrastructure to support the idea of multiple ringbuffers. > > Assign each ringbuffer an id and use that as an index for the various > > ring specific operations. > > > > The biggest delta is to support legacy fences. Each fence gets its own > > sequence number but the legacy functions expect to use a unique integer. > > To handle this we return a unique identifer for each submission but > > map it to a specific ring/sequence under the covers. Newer users use > > a dma_fence pointer anyway so they don't care about the actual sequence > > ID or ring. > > So, WAIT_FENCE is alive and well, and useful since it avoids the > overhead of creating a 'struct file', but it is only used within a > single pipe_context (or at least situations where we know which ctx > the seqno fence applies to). It seems like it would be simpler if we > just introduced a ctx-id in all the ioctls (SUBMIT and WAIT_FENCE) > that take a uint fence. Then I think we don't need hashtable > fancyness. > > Also, one thing I was thinking of is that some-day we might want to > make SUBMIT non-blocking when there is a dependency on a fence from a > different ring. (Ie. queue it up but don't write cmds into rb yet.) > Which means we'd need multiple fence timelines per priority-level rb. > Which brings me back to wanting a CREATE_CTX type of ioctl. (And I > guess DESTROY_CTX.) We could make these simple stubs for now, ie. > CREATE_CTX just returns the priority level back, and not really have > any separate "context" object on the kernel side for now. This > wouldn't change the implementation much from what you have, but I > think that gives us some flexibility to later on actually let us have > multiple contexts at a given priority level which don't block each > other for submits that are still pending on some fence, without > another UABI change. Sure. My motivation here was to mostly avoid making that decision because I know from experience once we start going down that path we end up using the context ID for everything and we end up re-spinning a bunch of APIs. But I agree that the context concept is our inevitable future - I've already posted one set of patches for "draw queues" (which will soon be bravely renamed as submit queues). I think thats the way we want to go because as you said, there is a 100% chance we'll go for asynchronous submissions in the very near future. That said, there is a bit of added complexity for per-queue fences - namely, we need to move the per-ring fence value in the memptrs to a per-queue value. This probably isn't a huge deal (an extra page of memory would give us up to 1024 queues to work with globally) but I get itchy every time an arbitrary limit is introduced no matter how reasonable it might be. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
