From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: [PATCH] drm/ttm: do not try to preserve caching state Date: Wed, 28 Nov 2012 23:18:32 +0100 Message-ID: <50B68DB8.60409@shipmail.org> References: <1354115148-27766-1-git-send-email-j.glisse@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from GOTHNET-SMTP2.gothnet.se (ns2.gothnet.se [82.193.160.251]) by gabe.freedesktop.org (Postfix) with ESMTP id 9582DE5F78 for ; Wed, 28 Nov 2012 14:18:39 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Jerome Glisse Cc: Jerome Glisse , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 11/28/2012 09:09 PM, Jerome Glisse wrote: > On Wed, Nov 28, 2012 at 10:05 AM, wrote: >> From: Jerome Glisse >> >> It make no sense to preserve caching state especialy when >> moving from vram to system. It burden the page allocator to >> match the vram caching (often WC) which just burn CPU cycle >> for no good reasons. Nack. This is a driver problem. What happens with this patch if you evict write-combined TT memory to system? That's why we want to preserve caching state in the first place. If you need a different behavior, you can fine-tune in driver::evict_flags, or in the radeon-case in radeon_move_ram_vram / radeon_move_vram_ram. /Thomas