From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755484AbdDMBLV (ORCPT ); Wed, 12 Apr 2017 21:11:21 -0400 Received: from anholt.net ([50.246.234.109]:60016 "EHLO anholt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752134AbdDMBLT (ORCPT ); Wed, 12 Apr 2017 21:11:19 -0400 From: Eric Anholt To: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/vc4: Allow using more than 256MB of CMA memory. In-Reply-To: <20170327231025.19391-1-eric@anholt.net> References: <20170327231025.19391-1-eric@anholt.net> User-Agent: Notmuch/0.22.2+1~gb0bcfaa (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 12 Apr 2017 18:11:16 -0700 Message-ID: <87shldglhn.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 Eric Anholt writes: > Until now, we've had to limit Raspberry Pi to 256MB of CMA memory to > keep from triggering the hardware addressing bug between of the tile > binner of the tile alloc memory (where the top 4 bits come from the > tile state data array's address). > > To work around that and allow more memory to be reserved for graphics, > allocate a single BO to store tile state data arrays and tile > alloc/overflow memory while the GPU is active, and make sure that that > one BO doesn't happen to cross a 256MB boundary. With that in place, > we can allocate textures and shaders anywhere in system memory (still > contiguous, of course). Ping for reviewers on this one -- it's a pretty big usability win. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlju0DQACgkQtdYpNtH8 nuj9rA/+N0P7G4XpQHkEdWSdTb66fYsfGSL0xTGWwawIP3/WytVLsZFo1UllJgFb oC7f7ldYEvrvFi19Vzdt2TSoo+KAhEvs1aPLqG80mLdpjV2bK+VV0nrzRJV9w4pj /FuzDcBeDH7DxchuFCznHMg5MgQq55tLiuqVL99/u+C6Ap4eWmjcvVp9OXXvV3c6 fFfROIVZ62iccOB5eqVtXGUdeoG3w152EzVWK3knGyxxoYj21+kMTLhufS6cg71G GoxX2sQn4odsxy6RkZRUUlf4QvnlRQd6e0Tl2nQQIkv65QhYepp5irUjgsDC8DJt MmEEqybKro/RZutvKprTNL5WfGs7c3TkVagnsWfZHlwvotJEs0BVu9PM1Ji5JNwK ro0kUM4tmp7ITyWxtv5ik/vpr4WCJvd7r9C5Op8Rxqu77Yp3LIbs8LWB7zsYH2P+ +jx8yub5+JYZb3Vdf2exZiUFr/QYAP0J/5bENhGPBEhrEtYg/spyKxyXpW+AvXhd vpqWrLr48+AOjWsHEmfBfaLe6YSjZ3LYwBy+wEyQBsLAWpC0hXdprpKlS+u34jko 5JhAz6ZnmzsX0v+PEk2S02OjQ3OBzBiMRLUGUYqGao7BiWUmEsdQ9MLtAYtT+nXP nR5wOHXHMcH9Rz04CXGboXAzsWgq7MNH3gG4ulW5qdrJg1hr7eU= =Vfla -----END PGP SIGNATURE----- --=-=-=-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH] drm/vc4: Allow using more than 256MB of CMA memory. Date: Wed, 12 Apr 2017 18:11:16 -0700 Message-ID: <87shldglhn.fsf@eliezer.anholt.net> References: <20170327231025.19391-1-eric@anholt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0502398113==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 60F7E8928B for ; Thu, 13 Apr 2017 01:11:18 +0000 (UTC) In-Reply-To: <20170327231025.19391-1-eric@anholt.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org --===============0502398113== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Eric Anholt writes: > Until now, we've had to limit Raspberry Pi to 256MB of CMA memory to > keep from triggering the hardware addressing bug between of the tile > binner of the tile alloc memory (where the top 4 bits come from the > tile state data array's address). > > To work around that and allow more memory to be reserved for graphics, > allocate a single BO to store tile state data arrays and tile > alloc/overflow memory while the GPU is active, and make sure that that > one BO doesn't happen to cross a 256MB boundary. With that in place, > we can allocate textures and shaders anywhere in system memory (still > contiguous, of course). Ping for reviewers on this one -- it's a pretty big usability win. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlju0DQACgkQtdYpNtH8 nuj9rA/+N0P7G4XpQHkEdWSdTb66fYsfGSL0xTGWwawIP3/WytVLsZFo1UllJgFb oC7f7ldYEvrvFi19Vzdt2TSoo+KAhEvs1aPLqG80mLdpjV2bK+VV0nrzRJV9w4pj /FuzDcBeDH7DxchuFCznHMg5MgQq55tLiuqVL99/u+C6Ap4eWmjcvVp9OXXvV3c6 fFfROIVZ62iccOB5eqVtXGUdeoG3w152EzVWK3knGyxxoYj21+kMTLhufS6cg71G GoxX2sQn4odsxy6RkZRUUlf4QvnlRQd6e0Tl2nQQIkv65QhYepp5irUjgsDC8DJt MmEEqybKro/RZutvKprTNL5WfGs7c3TkVagnsWfZHlwvotJEs0BVu9PM1Ji5JNwK ro0kUM4tmp7ITyWxtv5ik/vpr4WCJvd7r9C5Op8Rxqu77Yp3LIbs8LWB7zsYH2P+ +jx8yub5+JYZb3Vdf2exZiUFr/QYAP0J/5bENhGPBEhrEtYg/spyKxyXpW+AvXhd vpqWrLr48+AOjWsHEmfBfaLe6YSjZ3LYwBy+wEyQBsLAWpC0hXdprpKlS+u34jko 5JhAz6ZnmzsX0v+PEk2S02OjQ3OBzBiMRLUGUYqGao7BiWUmEsdQ9MLtAYtT+nXP nR5wOHXHMcH9Rz04CXGboXAzsWgq7MNH3gG4ulW5qdrJg1hr7eU= =Vfla -----END PGP SIGNATURE----- --=-=-=-- --===============0502398113== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0502398113==--