From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: [PATCH] drm/ttm: pass buffer object for bind/unbind callback Date: Mon, 21 Nov 2011 11:37:26 +0100 Message-ID: <4ECA29E6.4070706@vmware.com> References: <1321568442-8215-1-git-send-email-j.glisse@gmail.com> <4EC60FEC.3010703@vmware.com> <1321622128.13669.4.camel@nisroch> <4EC66BEB.1090900@vmware.com> <1321637208.18323.7.camel@nisroch> <4EC6E0DA.4060907@vmware.com> <1321662373.18323.15.camel@nisroch> <4EC77FDF.5030206@vmware.com> <1321714385.21551.6.camel@nisroch> <4EC7E0CA.1030806@vmware.com> <4EC80780.8030305@vmware.com> <4EC81911.3030608@vmware.com> <4EC82F8E.8010602@vmware.com> <4EC8C899.7040104@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [65.115.85.73]) by gabe.freedesktop.org (Postfix) with ESMTP id A7CBC9E78A for ; Mon, 21 Nov 2011 02:40:07 -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/20/2011 04:13 PM, Jerome Glisse wrote: > On Sun, Nov 20, 2011 at 4:30 AM, Thomas Hellstrom wrote: > >> On 11/19/2011 11:54 PM, Jerome Glisse wrote: >> >> As mentioned previously, and in the discussion with Ben, the page tables >> would not need to be rebuilt on each CS. They would be rebuilt only on the >> first CS following a move_notify that caused a page table invalidation. >> >> move_notify: >> if (is_incompatible(new_mem_type)) { >> bo->page_tables_invalid = true; >> invalidate_page_tables(bo); >> } >> >> command_submission: >> if (bo->page_tables_invalid) { >> set_up_page_tables(bo); >> bo->page_tables_invalid = false; >> } >> >> >> Why is it different from updating page table in move notify ? I don't >> see any bonus here, all the information we need are already available >> in move_notify. >> >> >> >> I've iterated the pros of this approach at least two times before, but for >> completeness let's do it again: >> >> 8<---------------------------------------------------------------------------------------------------- >> >> 1) TTM doesn't need to care about the driver re-populating its GPU page >> tables. >> Since swapin is handled from the tt layer not the bo layer, this makes it a >> bit easier on us. >> 2) Transition to page-faulted GPU virtual maps is straightforward and >> consistent. A non-page-faulting driver sets up the maps at CS time, A >> pagefaulting driver can set them up directly from an irq handler without >> reserving, since the bo is properly fenced or pinned when the pagefault >> happens. >> 3) A non-page-faulting driver knows at CS time exactly which >> page-table-entries really do need populating, and can do this more >> efficiently. >> >> 8<----------------------------------------------------------------------------------------------------- >> >> And some extra items like partially populated TTMs that were mentioned >> elsewhere. >> > If done in move_notify i don't see why 1 would be different or 2. Because to make the interface complete we need to support SYSTEM memory, and call move_notify from swapin, which I am not prepared to do. > I > agree that in some case 3 is true. Given when move notify is call the > ttm_tt is always fully populated at that point (only exception is in > destroy path but it's a special on its own). If driver populate in > move_notify is doesn't change anything from ttm pov. > Then you put a restriction on TTM to *always* have populated TTMs which I am also not prepared to accept. It's been recently added as a performance optimization. I won't spend any more time on this completely stupid argument. I've been asking you to make a minor change in order to get a complete and clean interface, and to get people to do the right thing in the future. You're obviously unwilling to do that. /Thomas