[Intel-gfx] [PATCH] drm/i915: New vfunc prepare_request
Oscar Mateo
oscar.mateo at intel.com
Tue May 2 15:17:41 UTC 2017
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!
More information about the Intel-gfx
mailing list