From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Hellstrom <thellstrom@vmware.com>
Subject: Re: [RFC 0/3] TTM priority queue logic
Date: Mon, 07 Apr 2014 16:53:04 +0200
Message-ID: <5342BBD0.7010307@vmware.com>
References: <20140404165224.a4856af5.cand@gmx.com>
 <53429938.3050203@vmware.com> <20140407173908.8d623569.cand@gmx.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <dri-devel-bounces@lists.freedesktop.org>
Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com
 [208.91.2.13])
 by gabe.freedesktop.org (Postfix) with ESMTP id 991636E6B1
 for <dri-devel@lists.freedesktop.org>; Mon,  7 Apr 2014 07:53:07 -0700 (PDT)
In-Reply-To: <20140407173908.8d623569.cand@gmx.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/dri-devel>,
 <mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dri-devel>,
 <mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel" <dri-devel-bounces@lists.freedesktop.org>
To: Lauri Kasanen <cand@gmx.com>
Cc: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org

On 04/07/2014 04:39 PM, Lauri Kasanen wrote:
> On Mon, 07 Apr 2014 14:25:28 +0200
> Thomas Hellstrom <thellstrom@vmware.com> wrote:
>
>> Hi, Lauri.
>>
>> On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
>>> Hi list, Thomas,
>>>
>>> I'd like to know if this is going in the right direction.
>> This looks fine with me.
>>
>> However, if possible I'd like the drivers to enable both alloc_threshold
>> and priority queue on a per-memory-type basis.
>>
>> That would mean no new arguments (use_pqueue, alloc_threshold) in
>> ttm_bo_device_init(). Instead, set default values in
>> ttm_bo_init_mm(), and let the driver change them in the init_mem_type()
>> callback.
>>
>> Do you think that would work?
> Thanks for the review.
>
> Alloc_threshold was removed, and the current patch (in drm-next)
> replaced it with a placement flag. So now that logic is in the driver.
>
> Making the pqueue a per-type option would certainly work, I'll edit it
> to do so. I don't see why it would improve GTT or SYSTEM given their
> perf characteristics, but I suppose future devices can always do weird
> things.

Yes. You don't have to explicitly check for VRAM, and drivers can also
set up
other fixed memory types, like a pre-allocated chunk of GTT.

Thanks,
Thomas


> - Lauri