On 18/06/2015 12:10, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 12:03:12PM +0100, John Harrison wrote:
On 17/06/2015 15:21, Chris Wilson wrote:
On Wed, Jun 17, 2015 at 04:06:05PM +0200, Daniel Vetter wrote:
On Fri, May 29, 2015 at 05:44:16PM +0100, John.C.Harrison@xxxxxxxxx wrote:
From: John Harrison <John.C.Harrison@xxxxxxxxx>
The i915_gem_object_flush_active() call used to do lots. Over time it has done
less and less. Now all it does check the various associated requests to see if
they can be retired. Hence this patch renames the function and updates the
comments around it to match the current operation.
For: VIZ-5115
Signed-off-by: John Harrison <John.C.Harrison@xxxxxxxxx>
When rebasing patches and especially like here when also renaming them a
bit please leave some indication of what you've changed. Took me a while
to figure out where one of my pending comments from the previous round
went too.
And please don't just "v2: rebase", but please add some indicators against
what it conflicted if it's obvious.
This function doesn't do an unconditional retire - the new name is much
worse since it is inconsistent with how requests retire. In my make GEM
umpteen times faster patches, I repurposed this function for reporting
the object's current activeness and called it bool i915_gem_oject_active()
- though that is probably better as i915_gem_object_is_active().
-Chris
Retiring is generally not an unconditional operation.
In the code, I use <object>_retire to perform the retiring operation on
that object. I can rename i915_gem_retire_requests if that makes you
happier, but I don't think it needs to since retire_requests does not
imply to me that all requests are retired, just some indefinite value
(though positive indefinite at least!).
-Chris
Fair enough. I guess I'm still thinking of the driver as it was when I
first wrote the patch series which was before your re-write for
read/read optimisations. Like I said, the exact new name isn't as
important as at least giving it a new name. The old name is definitely
not valid any more. Feel free to suggest something better.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
