On 05/02/2017 08:59 AM, Chris Wilson wrote:
On Mon, May 01, 2017 at 07:28:12AM +0000, Oscar Mateo wrote:
On 04/29/2017 08:31 AM, Chris Wilson wrote:
On Fri, Apr 28, 2017 at 05:26:09PM +0000, Oscar Mateo wrote:
This will be more useful later to support platforms that need to emit
HW commands at the beginning of every request (more general than emitting
things at the beginning of every batchbuffer, which is already covered by
emit_bb_start).
We already have one... You are presenting this without a good reason and
failing to transform similar code, which indicates to me that this vfunc
isn't that general.
It looks like I've missed that. What function are you talking about?
For example, you can argue that both legacy ring submission and
execlists share the same sequence of request_alloc:
request->ring = ce->ring (this is now common so can be moved
out, thanks to unifying context pin)
OK
[guc_wq_reserve we have ideas how to eliminate]
Can I simply create a guc_request_alloc for now? This will actually work
out nicely for me, because I only need to emit extra stuff in the GuC
case anyway.
some rudimentary reserving of ring space
context initialisation <- time to unify the legacy code
OK (or, at least, I'll try)
The choice for adding a new callback here, is we either take more common
code out of the request_alloc callback such that we reduce it to you new
vfunc -- and so we may end up with 2 common vfuncs called by the core.
Or you refactor the current code so that you can specialise request
alloc and use some execlist helpers for the common portion.
-Chris
Sounds reasonable, thanks!
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
