On Mon, Jan 11, 2016 at 06:42:33PM +0000, John.C.Harrison@xxxxxxxxx wrote: > From: John Harrison <John.C.Harrison@xxxxxxxxx> > > Split the execbuffer() function in half. The first half collects and > validates all the information required to process the batch buffer. It > also does all the object pinning, relocations, active list management, > etc - basically anything that must be done upfront before the IOCTL > returns and allows the user land side to start changing/freeing > things. The second half does the actual ring submission. I don't get this at all. The point of requests is that GEM constructed a request, which could be used to pass along all the implicit GEM synchronisation points and the explict ones, along with the ringbuffer to execute, to an engine that could then submit it. For legacy, the request was inline and so added immediately to the ring (but that is an implementation detail, there is nothing stopping us from using a chained batch to implement a ring per context), for execlists the request is queued for future execution. A scheduler was meant to sit in the middle and determine the order in which requests were executed, but that should be almost transparent to the high level code tracking the requests. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
