[Intel-gfx] [PATCH 11/66] drm/i915: Preallocate stashes for vma page-directories

Thomas Hellström (Intel) thomas_os at shipmail.org
Thu Jul 30 12:04:27 UTC 2020



On 7/28/20 4:50 PM, Chris Wilson wrote:
> Quoting Thomas Hellström (Intel) (2020-07-27 10:24:24)
>> Hi, Chris,
>>
>> It appears to me like this series is doing a lot of different things:
>>
>> - Various optimizations
>> - Locking rework
>> - Adding schedulers
>> - Other misc fixes
>>
>> Could you please separate out as much as possible the locking rework
>> prerequisites in one series with cover letter, and most importantly the
>> major part of the locking rework (only) with a more elaborate cover
>> letter discussing, if not trivial, how each patch fits in and on design
>> and future directions, Questions that I have stumbled on so far (being a
>> new-to-the-driver reviewer):
> The locking depend on the former work to reduce the impact. It's still a
> major issue that we introduce a broad lock that is held for several
> hundred milliseconds across many objects that stalls game&compositor.
>   
>> - When are memory allocations disallowed? If we need to pre-allocate in
>> execbuf, when? why?
> That should be mentioned in the code.
>
>> - When is the request dma-fence published?
> There a big comment to that effect.
>
>> - Do we need to keep cpu asynchronous execbuf tasks after this? why?
> Keep? Oh, you mean not immediately discard after publishing them, but
> why we need them. Same reason as we need them before.
>
>> - What about userptr pinning ending up in the dma_fence critical path?
> It's in the user critical path (the shortest path to perform their
> sequence of operations), but it's before the dma-fence itself. I say
> that's a particularly nasty false claim that it is not on the critical
> path, but being where it is circumvents the whole argument.
>   
>> And then move anything non-related to separate series?
> Not related to what? Development of i915?
> -Chris

So while it's true that a good prior understaning of the driver together 
with a detailed analysis of the code would provide answers to most of 
these questions, they were actually primarilly intended to serve as 
inspiration for an elaborate cover letter.

I believe a discussion touching these items would be a good aid to 
people embarking on reviewing the series.

/Thomas






More information about the Intel-gfx mailing list