Re: [PATCH] drm/i915: New vfunc prepare_request

[Oscar Mateo <oscar.mateo@intel.com>]

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx