From mboxrd@z Thu Jan 1 00:00:00 1970 From: Francisco Jerez Subject: Re: Nouveau fences? Date: Sun, 28 Nov 2010 17:11:11 +0100 Message-ID: <87y68dl97k.fsf@gmail.com> References: <4CF24D65.4030008@shipmail.org> <87k4jxmta8.fsf@riseup.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1500613270==" Return-path: Received: from mail-ww0-f43.google.com (mail-ww0-f43.google.com [74.125.82.43]) by gabe.freedesktop.org (Postfix) with ESMTP id D064D9E7A6 for ; Sun, 28 Nov 2010 08:11:50 -0800 (PST) Received: by wwi17 with SMTP id 17so503649wwi.12 for ; Sun, 28 Nov 2010 08:11:50 -0800 (PST) In-Reply-To: <87k4jxmta8.fsf@riseup.net> (Francisco Jerez's message of "Sun, 28 Nov 2010 15:12:15 +0100") 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: Thomas Hellstrom Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1500613270== Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Francisco Jerez writes: > Thomas Hellstrom writes: > >> Ben, >> >> I'm looking at a way to make TTM memory management asynchronous with >> the CPU. The idea is that you should basically be able to DMA data to >> and from memory regions without waiting for idle, as long as the GPU >> has a means to provide operation ordering. >> > Sounds good. I guess you're mainly dealing with BO eviction > synchronization? The only problem I see on our side is that calls to our > move() hook aren't guaranteed to be carried out in order (because of the > multiple hardware channels). I'm thinking that move() could be extended > with an optional sync_obj argument, that way move() would be able to > make sure that evictions are strictly ordered with respect to the fence > specified. > >> While doing that I looked a bit at the Nouveau fencing. It appears >> like waiting for fences is polling only (no irq to signal fences)? Is >> that correct? >> > That's right, nvidia hardware has no nice way to schedule a fence-like > interrupt we could selectively turn on and off around the sync_obj_wait > hook. There's a bunch of (more or less) chipset-specific hacks that > could be used to get an equivalent effect, but polling has seemed good > enough so far (in the typical case we only take the "lazy" path so CPU > usage is still OK). > > Unconditional PFIFO CACHE interrupts might be an option too, but, I'm a > bit afraid of the PFIFO stalls and useless IRQ storms some applications > could trigger. > Meh, apparently this one couldn't make it through, some spam filter has decided I'm a spammer for some reason... >> /Thomas >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EAREIAAYFAkzyfyAACgkQg5k4nX1Sv1uBHQD8Dlpx4exmgMMyq/ClcVDaKy0F wU3kUfYJl43iGze3BrQA/jxvqaUDga7bWV+peRMb4PKG6KSjs0tDih9MnkrbOSE1 =1frA -----END PGP SIGNATURE----- --==-=-=-- --===============1500613270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1500613270==--