From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH 5/6] drm/vc4: Fix overflow mem unreferencing when the binner runs dry. Date: Tue, 26 Jul 2016 16:11:00 -0700 Message-ID: <87bn1kov0b.fsf@eliezer.anholt.net> References: <1469566035-22006-1-git-send-email-eric@anholt.net> <1469566035-22006-6-git-send-email-eric@anholt.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: In-Reply-To: Sender: stable-owner@vger.kernel.org To: Rob Clark Cc: "dri-devel@lists.freedesktop.org" , Linux Kernel Mailing List , stable List-Id: dri-devel@lists.freedesktop.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----- --=-=-=--