[Intel-gfx] [PATCH v5 0/7] Command parser batch buffer copy

[Michael H. Nguyen]

On 12/02/2014 01:45 AM, Daniel Vetter wrote:
> On Mon, Dec 01, 2014 at 02:39:51PM -0800, Michael H. Nguyen wrote:
>>
>>
>> On 11/26/2014 11:44 PM, Chris Wilson wrote:
>>> On Wed, Nov 26, 2014 at 01:53:34PM -0800, michael.h.nguyen at intel.com wrote:
>>>> From: "Michael H. Nguyen" <michael.h.nguyen at intel.com>
>>>>
>>>> This is v5 of the series sent here:
>>>> http://lists.freedesktop.org/archives/intel-gfx/2014-November/055141.html
>>>>
>>>> This version incorporates the following feedback from v4.
>>>>
>>>> - 0/7 Move 'pending_read_domains |= I915_GEM_DOMAIN_COMMAND' after the
>>>>    parser (danvet)
>>>> - 1/7 Move purged check inside the loop (danvet)
>>>> - 6/7 Move 'shadow_batch_obj->madv = I915_MADV_WILLNEED' inside _get
>>>>    fnc (danvet)
>>>> - 7/7 Move pin/unpin calls inside i915_parse_cmds() (Chris W)
>>>>
>>>> Issue: VIZ-4719
>>>> Brad Volkin (7):
>>>>    drm/i915: Implement a framework for batch buffer pools
>>>>    drm/i915: Use batch pools with the command parser
>>>>    drm/i915: Add a batch pool debugfs file
>>>>    drm/i915: Add batch pool details to i915_gem_objects debugfs
>>>>    drm/i915: Use batch length instead of object size in command parser
>>>>    drm/i915: Mark shadow batch buffers as purgeable
>>>>    drm/i915: Tidy up execbuffer command parsing code
>>>
>>> This still does not incorporate the feedback from the last N cycles.
>>>
>>> Chiefly: A single cache list, madvise on creation, and squash the
>>> framework and debugging patches into one.
>>
>> Re: single cache list
>>
>> OK. Found the feedback in an old rev.
>
> Btw in your patch you have a fancy retry loop looking at was_purged. On a
> quick look that shouldn't be needed and a simple list-walk should be all
> you need I think.

Right. That has been there for a couple of rev's. I have it addressed in 
the RFC sent to you and Chris privately. Let me know if what I sent 
isn't want you were hoping for.

> -Daniel
>