From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758542AbcGZXLJ (ORCPT ); Tue, 26 Jul 2016 19:11:09 -0400 Received: from anholt.net ([50.246.234.109]:39795 "EHLO anholt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758014AbcGZXLF (ORCPT ); Tue, 26 Jul 2016 19:11:05 -0400 From: Eric Anholt To: Rob Clark Cc: "dri-devel\@lists.freedesktop.org" , Linux Kernel Mailing List , stable Subject: Re: [PATCH 5/6] drm/vc4: Fix overflow mem unreferencing when the binner runs dry. In-Reply-To: References: <1469566035-22006-1-git-send-email-eric@anholt.net> <1469566035-22006-6-git-send-email-eric@anholt.net> User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 26 Jul 2016 16:11:00 -0700 Message-ID: <87bn1kov0b.fsf@eliezer.anholt.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Rob Clark writes: > On Tue, Jul 26, 2016 at 4:47 PM, Eric Anholt wrote: >> Overflow memory handling is tricky: While it's still referenced by the >> BPO registers, we want to keep it from being freed. When we are >> putting a new set of overflow memory in the registers, we need to >> assign the old one to the last rendering job using it. >> >> We were looking at "what's currently running in the binner", but since >> the bin/render submission split, we may end up with the binner >> completing and having no new job while the renderer is still >> processing. So, if we don't find a bin job at all, look at the >> highest-seqno (last) render job to attach our overflow to. > > so, drive-by comment.. but can you allocate gem bo's without backing > them immediately with pages? If so, just always allocate the bo > up-front and attach it as a dependency of the batch, and only pin it > to actual pages when you have to overflow? The amount of overflow for a given CL is arbitrary, depending on the geometry submitted, and the overflow pool just gets streamed into by the hardware as you submit bin jobs. You'll end up allocating [0,n] new overflows per bin job. I don't see where "allocate gem BOs without backing them immediately with pages" idea would fit into this. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJXl+4EAAoJELXWKTbR/J7occYP/0UzriFXbRM9qI6zVG1AyNsu sbdYigqIvIe4q4Qj0pt5gvX7vuGEWmee2s5ckZYZerpr4R50KXPRtk8GbuYW52G6 dx3fTg5KLxG18cgYHsmXp/IYsYIx1MdZQvt1QLa0Afo1MNcORn+sVKvzKbaago2D ZeHWqe6XmhOZjSBE72SZUDLgrdJji/7t8P7MZ7ESNawx7hvOTYMDn0XNcfoXlGx4 bT/d16j9ZjVeuYX2kw1o+tJIPsG4zuKXcwbgPxk2DNC7RSdUN+6wwLiLddnBNh4f rVatxbD6YNOLaAqWV9LDyUWnDVRdt5kqfRW+rZkWDe+R4ZxTQlHlQZ0q9vLLmnok S1nTLlwPybdEYz0ay7exrq7BvxAAiLPku1kcZiBTVwYLrNAgqUQEnxj94czGYnC7 i5YVkpbCPy8N5A8FBqAfWzLc89hAOUpWh/GSyzUiyvOhlaHI1uKLuBfT7AwZ4oMd Q/cA3vZN4Y/odm4pzIzkrL+6y2svSRh6IWu9bVgi9U/ZMQcoqpf76mRVrUe23xNI 3i63iaDJtN65DEsrRO4knnKyhnIxaLXdg2RGSebd+FnCvYL2pPaLNWwtxZobieWf PVJ545pkJy5tMiJcZ0G/vCtbmj7fmy1z9VYKLJBPUfss7rAudZz47aOJa+BtgXER 9Z9+iSKaf/+nNnl7FLbb =v3eg -----END PGP SIGNATURE----- --=-=-=--