From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41E1DC56201 for ; Wed, 25 Nov 2020 08:37:45 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C131220857 for ; Wed, 25 Nov 2020 08:37:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C131220857 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=amd-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B9CBC6E870; Wed, 25 Nov 2020 08:37:42 +0000 (UTC) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by gabe.freedesktop.org (Postfix) with ESMTPS id D09656E86E; Wed, 25 Nov 2020 08:37:40 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 70CCDABD7; Wed, 25 Nov 2020 08:37:39 +0000 (UTC) To: Daniel Vetter References: <3daf9b24-034a-9791-ce30-9f5eba66e7c1@amd.com> <516877c4-3718-1415-9901-62bffdbf26c8@suse.de> <94fa26eb-d899-8c83-9325-84532639d438@suse.de> <6319ba4d-f45f-77ec-8752-33f3cad443fd@amd.com> <6d2ee787-0bf5-de1d-73af-7c87bad63cda@suse.de> <2431a0e1-7159-b3e7-e1ca-3e7f55c38d8a@amd.com> <20201124140937.GK401619@phenom.ffwll.local> From: Thomas Zimmermann Subject: Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed Message-ID: <278a4498-bdde-402a-1cea-668e9683f7eb@suse.de> Date: Wed, 25 Nov 2020 09:37:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <20201124140937.GK401619@phenom.ffwll.local> X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: airlied@linux.ie, alexander.deucher@amd.com, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, =?UTF-8?Q?Christian_K=c3=b6nig?= Content-Type: multipart/mixed; boundary="===============0770006234==" Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============0770006234== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N7OPKHmdKB0h0lZflU37E0gNvSvlaqVxT" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N7OPKHmdKB0h0lZflU37E0gNvSvlaqVxT Content-Type: multipart/mixed; boundary="8GcQb1ZzC4nYhOFoVafhjNrGptxPtcRgp"; protected-headers="v1" From: Thomas Zimmermann To: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org, airlied@linux.ie, dri-devel@lists.freedesktop.org, alexander.deucher@amd.com, =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: <278a4498-bdde-402a-1cea-668e9683f7eb@suse.de> Subject: Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed References: <3daf9b24-034a-9791-ce30-9f5eba66e7c1@amd.com> <516877c4-3718-1415-9901-62bffdbf26c8@suse.de> <94fa26eb-d899-8c83-9325-84532639d438@suse.de> <6319ba4d-f45f-77ec-8752-33f3cad443fd@amd.com> <6d2ee787-0bf5-de1d-73af-7c87bad63cda@suse.de> <2431a0e1-7159-b3e7-e1ca-3e7f55c38d8a@amd.com> <20201124140937.GK401619@phenom.ffwll.local> In-Reply-To: <20201124140937.GK401619@phenom.ffwll.local> --8GcQb1ZzC4nYhOFoVafhjNrGptxPtcRgp Content-Type: multipart/mixed; boundary="------------A03683CE103C3FCF6029B6AB" Content-Language: en-US This is a multi-part message in MIME format. --------------A03683CE103C3FCF6029B6AB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Am 24.11.20 um 15:09 schrieb Daniel Vetter: > On Tue, Nov 24, 2020 at 02:56:51PM +0100, Thomas Zimmermann wrote: >> Hi >> >> Am 24.11.20 um 14:36 schrieb Christian K=C3=B6nig: >>> Am 24.11.20 um 13:15 schrieb Thomas Zimmermann: >>>> [SNIP] >>>>>>>> First I wanted to put this into >>>>>>>> drm_gem_ttm_vmap/vunmap(), but then wondered why >>>>>>>> ttm_bo_vmap() doe not acquire the lock internally? >>>>>>>> I'd expect that vmap/vunmap are close together and >>>>>>>> do not overlap for the same BO. >>>>>>> >>>>>>> We have use cases like the following during command submission: >>>>>>> >>>>>>> 1. lock >>>>>>> 2. map >>>>>>> 3. copy parts of the BO content somewhere else or patch >>>>>>> it with additional information >>>>>>> 4. unmap >>>>>>> 5. submit BO to the hardware >>>>>>> 6. add hardware fence to the BO to make sure it doesn't move >>>>>>> 7. unlock >>>>>>> >>>>>>> That use case won't be possible with vmap/vunmap if we >>>>>>> move the lock/unlock into it and I hope to replace the >>>>>>> kmap/kunmap functions with them in the near term. >>>>>>> >>>>>>>> Otherwise, acquiring the reservation lock would >>>>>>>> require another ref-counting variable or per-driver >>>>>>>> code. >>>>>>> >>>>>>> Hui, why that? Just put this into >>>>>>> drm_gem_ttm_vmap/vunmap() helper as you initially >>>>>>> planned. >>>>>> >>>>>> Given your example above, step one would acquire the lock, >>>>>> and step two would also acquire the lock as part of the vmap >>>>>> implementation. Wouldn't this fail (At least during unmap or >>>>>> unlock steps) ? >>>>> >>>>> Oh, so you want to nest them? No, that is a rather bad no-go. >>>> >>>> I don't want to nest/overlap them. My question was whether that >>>> would be required. Apparently not. >>>> >>>> While the console's BO is being set for scanout, it's protected from= >>>> movement via the pin/unpin implementation, right? >>> >>> Yes, correct. >>> >>>> The driver does not acquire the resv lock for longer periods. I'm >>>> asking because this would prevent any console-buffer updates while >>>> the console is being displayed. >>> >>> Correct as well, we only hold the lock for things like command >>> submission, pinning, unpinning etc etc.... >>> >> >> Thanks for answering my questions. >> >>>> >>>>> >>>>> You need to make sure that the lock is only taken from the FB >>>>> path which wants to vmap the object. >>>>> >>>>> Why don't you lock the GEM object from the caller in the generic >>>>> FB implementation? >>>> >>>> With the current blitter code, it breaks abstraction. if vmap/vunmap= >>>> hold the lock implicitly, things would be easier. >>> >>> Do you have a link to the code? >> >> It's the damage blitter in the fbdev code. [1] While it flushes the sh= adow >> buffer into the BO, the BO has to be kept in place. I already changed = it to >> lock struct drm_fb_helper.lock, but I don't think this is enough. TTM = could >> still evict the BO concurrently. >=20 > So I'm not sure this is actually a problem: ttm could try to concurrent= ly > evict the buffer we pinned into vram, and then just skip to the next on= e. >=20 > Plus atm generic fbdev isn't used on any chip where we really care abou= t > that last few mb of vram being useable for command submission (well atm= > there's no driver using it). Well, this is the patchset for radeon. If it works out, amdgpu and=20 nouveau are natural next choices. Especially radeon and nouveau support=20 cards with low- to medium-sized VRAM. The MiBs wasted on fbdev certainly = matter. >=20 > Having the buffer pinned into system memory and trying to do a concurre= nt > modeset that tries to pull it in is the hard failure mode. And holding > fb_helper.lock fully prevents that. >=20 > So not really clear on what failure mode you're seeing here? Imagine the fbdev BO is in VRAM, but not pinned. (Maybe Xorg or Wayland=20 is running.) The fbdev BO is a few MiBs and not in use, so TTM would=20 want to evict it if memory gets tight. What I have in mind is a concurrent modeset that requires the memory.=20 If we do a concurrent damage blit without protecting against eviction,=20 things go boom. Same for concurrent 3d graphics with textures, model=20 data, etc. Best regards Thomas >=20 >> There's no recursion taking place, so I guess the reservation lock cou= ld be >> acquired/release in drm_client_buffer_vmap/vunmap(), or a separate pai= r of >> DRM client functions could do the locking. >=20 > Given how this "do the right locking" is a can of worms (and I think it= 's > worse than what you dug out already) I think the fb_helper.lock hack is= > perfectly good enough. >=20 > I'm also somewhat worried that starting to use dma_resv lock in generic= > code, while many helpers/drivers still have their hand-rolled locking, > will make conversion over to dma_resv needlessly more complicated. > -Daniel >=20 >> >> Best regards >> Thomas >> >> [1] https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/drm_= fb_helper.c?id=3Dac60f3f3090115d21f028bffa2dcfb67f695c4f2#n394 >> >>> >>> Please note that the reservation lock you need to take here is part o= f >>> the GEM object. >>> >>> Usually we design things in the way that the code needs to take a loc= k >>> which protects an object, then do some operations with the object and= >>> then release the lock again. >>> >>> Having in the lock inside the operation can be done as well, but >>> returning with it is kind of unusual design. >>> >>>> Sorry for the noob questions. I'm still trying to understand the >>>> implications of acquiring these locks. >>> >>> Well this is the reservation lock of the GEM object we are talking ab= out >>> here. We need to take that for a couple of different operations, >>> vmap/vunmap doesn't sound like a special case to me. >>> >>> Regards, >>> Christian. >>> >>>> >>>> Best regards >>>> Thomas >>> >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> --=20 >> Thomas Zimmermann >> Graphics Driver Developer >> SUSE Software Solutions Germany GmbH >> Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany >> (HRB 36809, AG N=C3=BCrnberg) >> Gesch=C3=A4ftsf=C3=BChrer: Felix Imend=C3=B6rffer >=20 >=20 >=20 >=20 >=20 >=20 --=20 Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany (HRB 36809, AG N=C3=BCrnberg) Gesch=C3=A4ftsf=C3=BChrer: Felix Imend=C3=B6rffer --------------A03683CE103C3FCF6029B6AB Content-Type: application/pgp-keys; name="OpenPGP_0x680DC11D530B7A23.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x680DC11D530B7A23.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdgX= H47 fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0BeB5B= bqP 5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4YchdHm3bkPj= z9E ErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB9GluwvIhSezPg= nEm imZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEBAAHNKFRob21hcyBaa= W1t ZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmNvbT7CwI4EEwEIADgCGwMFCwkIBwIGFQoJCAsCB= BYC AwECHgECF4AWIQRyF/usjOnPY0ShaOVoDcEdUwt6IwUCXvxIWAAKCRBoDcEdUwt6I+aZB/9ih= Onf G4Lgf1L87cvoXh95/bnaJ6aQhP6/ZeRleuCXflnyDajlm3c9loQr0r2bQUi7JeYwUKbBab2QS= GJm DMRGlLMnmzWB8mHmZ6bHAu+2Sth8SraE42p6BB9d8dlYEID+dl/D/xUBeulfkck5rloGtYqDi= +1Q DfkEZJaxVSZ6FFkXuQi/G9qcI4iklN2nv02iQ7mZe8WYAysix6s/6vIobhirEBreclSNxXqis= p8n 91+v855JC11EgRdUXMRK81IAaCKXP8zLx3ixku7mvP9Om61yerHSbeU2HZbIggZYQlFh6llJm= zF1 CjCWgPTJyk4t4kMTcNOw5ykD47vU/KW+wl0EEBECAB0WIQQn6OOmnzvP/7ktjmoud6EwEfXTw= gUC WzodVwAKCRAud6EwEfXTwidvAKDkOADDHfI0QNXqAZcg6i1kOndAYACeLXHBwpjnumkPSyoab= IiL +he8r3zCwHMEEAEIAB0WIQQeXZghmQijlU7YzFiqUDvJrg9HpwUCWznxsQAKCRCqUDvJrg9Hp= 42f CADIvsZcAd04PDFclRltHr2huy6s7+ZZA6PgYlMblEBh4bJA+dNPBTvzpJ7FJv/bmHOa+phWy= Urj EpfFGuOKGuWAfzgVAEu52fMrW3/mm+O26z1AKIu8hiZ/x9OAe4AM71ZO2lZrV1/53ZdzWnRuO= 45N GQcotU8oeVfT9okAfmozmWMmIMq7Q0K6bV8W3qiD5XfDNxjr2caxc/9WX1bZPUo3n0H23MNaA= Tpy Oz732UtDh6sKUAB1RfzBBd/REbjHD7+quwJGAdRScyDRncX1vNb2+wihy0ipA69XY3bkhR5iD= u5r A9enuiMe6J1IBMI1PZh+vOufB/M6cd2D9RULIJaJwsBzBBABCAAdFiEEuyNtt7Ge78bIRx1op= /N8 GYw5MYEFAls6MrsACgkQp/N8GYw5MYEnLQf/dwqlDJVQL2q+i8FFaqTMAm0n9jLRV6pN8JxFH= j0g voyWUOnQuNdAFgtKd26ZhN8NkLoSMO8E19eBPfLoBIFK5yNNVmRHAZm07MzGbA0uNWINJhmdR= bZM RMh0nneXjcEU/IvUmd8TPFTAd24X2mbzHgcaHMLJSVx1ohd4alRJXHIqDobKmiVwekyPnInJn= zWw iuZUkIotTkQple1PT/dF3S+KtPXBL6ldQ4NkAeCjsz4wnzSa9+VKOxEhiHM0PMzXSbkCMP+4m= Xy9 RMplBw9Dm9hN2PSouBPifIrSodiiSWZYXOEkzLiBAB0frCKR63Dnx9kvjCD9Pz5wLd/70rjqI= cLA jgQTAQgAOAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC= 3oj BQJftODHAAoJEGgNwR1TC3ojZSIIAIV3makffp4P4leU8JSLt0aTNewsOhy7VQzKUtlCw3PKD= 3l/ SuymZhQKgH+n6sijzFauZnZ+x0T+Oy+dDVZb3sNJuuMUDIHw18EO9daZBMcueaS54FGe73lAp= HUl 7nxyocCxoqIG8+fP+75itV/ls2TSh5rJvjLvHC8J3NqfGlJ/jlSKrQUnzFbXfE5KGWiKNAn+I= 1a2 EE0I7uLpYgkdb8hcjtV9Rxr2ja+GWOaSoqB29P5GUzipkWo4144Q16JBO6QP2R9y/1ZK9VqH2= 5T8 lTKocLAaHCEdpDqY5KI15as9tIxlI1Vh+eqhTh/gwEm1ykO1gmrQ1zvGLDMB1EE6El3NJ1Rob= 21h cyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIbAwULCQgHAgYVC= gkI CwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJe/EheAAoJEGgNwR1TC3ojq= RgI AIoegtTp1prPzfHgTAuEPd8v58ssHubwi9tg69a8IJ+iMNozhs4iUou84WOLBJNjSieXHZRa8= fJj //2/sTuABn38AQ9FcKX9/B49hrdCo6c0WHHKqlPrSTzuXNKYyOdmSFd/pDhBb2Bn5DTxxH5RP= m/N U/C9nUlwi7Y+FgBlDNa5h592wmJfv0cJAfvF56C+QL65jHFOFIW9xSaTOAxxMXHGJHXki6Iwa= aTg s7QQlKQcd5XvvED1bwLyQ7rq+MEZo5N7IygpQMM3qqGMlCnDdyQ3W95rd0HCWpfa0oVRCOwdu= SL3 5hG7ONqBpvBj8z5GjSbt4HLJGvpeT0k37qzRExrCXQQQEQIAHRYhBCfo46afO8//uS2Oai53o= TAR 9dPCBQJbOh1XAAoJEC53oTAR9dPC05AAoIy0HQ2DBDYugQ42P4HfyxfZTIvKAJ0fqNBcBFW9S= tbR DEP9cfpNVOv8YMLAcwQQAQgAHRYhBB5dmCGZCKOVTtjMWKpQO8muD0enBQJbOfGzAAoJEKpQO= 8mu D0enL0wIAM2NTeUDCofBAkbWHGTZopclefbh0xGPYQEfttNyalp0hn1CrVO7OsX5eTjRqgyOa= 1C5 OAsNghCM4PUmrfv5cZ9+sNn9bRM50uVW9IFRlq8wwBY4+7QejJ5gs7DW/0tZIMZ6iTGKK0WEO= 7gd 2K9hXadPBScTdIqXeWH82meiqElnEQL+K9UeGUBrku+1EQIOxwziKwTDlTvhyJ+xmEKj0uWRc= Ocl 27xLS9XOWPGXcNQBtlZhF8e/E1kFRt5CPP5UBdUCN8qydUadseXivSNDiYob9dyJSFt7G0Bq4= /ac Ret5ANtGRWsp8xYJQRossRMWL0w9P8SiIc2IY/JrQrpz29nCwHMEEAEIAB0WIQS7I223sZ7vx= shH HWin83wZjDkxgQUCWzoywAAKCRCn83wZjDkxgQaDCACyFuBLQWNvLT8GTDqTf/gETzmtoEM6Y= r8O 4jbYg05xiFzAqMZctQsm3zHakx2JrimxDvQJRQJQzp5ICJ7J/BOuSL4FE1SPeQIfjm4jyBZGH= P/W vgHsT5e3+ZCPePPZO+3irarTKVhaaP70Tpka6EsOCZzO6L8D6tUDkhxMX0ymy7p8w9Yt1eD0o= Ume mxrKdS1ulpNJUTBw7gJN8bMowVnycEm6wntxOjrCxuwbkKhFLdn0ejcXQ0UkfbUFKfU64gGBu= S53 ZlM8XlOhQEIw/FrdXszhR+Tg3Ag130cmJhOrghgOBLzvJfUd6OvDT5VIz0QGbAm8SWlAIIms1= 9Z8 kBsLwsCOBBMBCAA4AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEchf7rIzpz2NEoWjla= A3B HVMLeiMFAl+04McACgkQaA3BHVMLeiPHXAf/SEoZa6CKoOAs1ctEP/hN8cEQqbEiuZ+71nm3u= /BQ p/CEUvqGq+iVc8kkpClDbPz5fa9mb+yWwufsnXKOs6ygmEoAEOL7dBZZIaRobBEkB09VXIkx8= lE0 00grBVtToHUGRfZcMoMZ98XhPGU6lJDN200j/2CV46hQDz6PLySecNjOME05mosbYW5N2JwFd= uXP Qx++DjWB32QLBhcOcP3WslTy3PKVe/TcTvk0JpPFMz4UFc+awBVhDgZiGGAW3xLZRYyhpoAEs= N7u XkV2ct0MRxuZ3y4tTYJobhbZwutRojiPPZduRw9CSpNDcQHruFiSOIQTpnLeCA6K2JAZyqmP/= 87A TQRbOdLgAQgAxiY/gz9X5PlFjlq3+DutR02wuFa/UA9iuH1FB584Nges1EdQT16ixhtPpcyvJ= H2F PxeUY5hHApbCJAGhZIOJMyj9eLb2NSefgFd8janHYNNfBzbYsq0sCBNGM/6ptTrdjTGdA3b1Q= YNt iDLIrnUNbcfQh/Zrck2yF4AAr5dz1tqPQsYhzxP26IRYcGcIf5F2GABOdZYYp0N6BRHkGQN8O= Dk7 8UhLKYkEfHYPKiSW/mDgHOSCpOrCZpjOyXxTFkq9trGrTNt6EN1ryW+EVeh00UwCBMsmUu4Ng= 4Ys rYDButLdKnQARuSl0kFvjipWUablsClmi4d4n/6f7uvXb6Wp2wARAQABwsB8BBgBCAAmFiEEc= hf7 rIzpz2NEoWjlaA3BHVMLeiMFAls50uACGwwFCQPCZwAACgkQaA3BHVMLeiOl9wgAifA/k6VwQ= qiR OccKINPPg6fLgacdE/Z9cBNBkIrGa7gAljaH2J/D01/ZOMJnoAy8Le2EA3SsUOPnk32XizUKl= oOj gn7R+Sse7I1pydPbToJ4lXUTs1ie3FSf4tKJGs53LCfp6uPFGL0RhNUsIdwOEESMqYVl+DgAz= gZk xZfWWDT54dt3mgvVqzbxa+8j+4hozJXxFvJei3Wv/xAuVaV1Tc2tMXmntMxTbLdkfaZ/my5Io= cAy 1sTiMonxkcU6jcaEuCNWsFYcT0lc7TzEqSAP7Dq/zf6eiawS5/oLotiupj+2xm/IRfrM3wK2K= s90 9a79Vc1FgCX+Vq3uVIjcfbqqscLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojB= QJf tOH6AAoJEGgNwR1TC3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6= Baa 6H7ufXNQtThRyIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3= T0T trijKP4ASAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446S= h8W n/2DYa8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRai= tYJ 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9fOwU0EX7ThE= wEQ ANJiTIb/nQ+MPgIBsSfBBhmXrVFUwFveO6DWPZ0M+Y5xBJhvDukosstSgcLCdld4SFF2JnnCo= yh9 boM2j2Ksd5wNzTzXlo3lEzFRAipftboviUjap0qxoRwy1hBV3Ft1/VyNwwYY7qjGVATQU7cIT= /zL gb+Sd0NPQA8r2NvpJq1MnI8nFfA2ZH4diuRtavhEBUzp63SlCYxnyxqT5AQzSQGUpsjSyh1A5= ezt j1pwxgnkX7F9ZT0lUBo6zZM6ZBq8Nkyvox46l79QoWMBm9y+/nIXy/uXdT6RaumPjBzVttGmk= Onm TlGUJyQAndAE1boib9iWCJ4kIr2ezRKjXJXGuaM1m7hSfdQYWed0j52+nW9qGSNNk1GjYXM8Z= SWT agX6O5mfbpzRgBBK/XoE9NWRNAa4V+tUX4/vqqDl0m+O4F2GYs6Eu7WLredRgwjDuMF/VCKvQ= fr3 yjIt90Zi10cHQw3khdJWmSDKYgenpvsffo4x56biifOh6IxS/whf5/BAx4nx8GyX7JO0DUnUu= ieC NfEGRu8QbYBSOkO/vdm4xy7RZwdzlqN8zjCLFOCG346Bnsx3ku2lNtX6qZoajmfD4oO6N0Xds= 2pE wjufCfJW9sCLdBmqLD5OvsRljyv7vt5w28XSF1tyhQaxIs+8sFJtwfCliduffq56FcFrEXCxs= LQr ABEBAAHCwqwEGAEIACAWIQRyF/usjOnPY0ShaOVoDcEdUwt6IwUCX7ThEwIbAgJACRBoDcEdU= wt6 I8F0IAQZAQgAHRYhBMZ3Zv36bjFHcGBRaJYfxNxEKL/gBQJftOETAAoJEJYfxNxEKL/gkygQA= LQH pXm45ZfMCDx7u/d7rRH/R7EfEV5OAoS981IkzbTgrb9z6YYfhQqH+R2ImgoX/Lou7zSjyd22/= IaZ AnTKHKkXIFIM1uB144dqAi3tW/Bei/CSdiD7DY1q92Ebl6e+Gpf3TZdATSY00fVeLMNFnjbbz= CVX 9+LEKYARNm7kYogVJMc5CuVmXBn9FFF3cioRvpuals8llsFc4WiUBJfDfOzjXExqv3OMtJj0s= qlK sXdnLkXbtAmEvFaxqUuO1ZwTCTGflrn/g4C8Cg0ifk0wZGgGYRindkJE1vOQZPaDI7GtNxJ+D= sx4 fL/8tf7Wuk3TZ6t/ofKhjq8sUVCVhnlyd/3ujruDu/PhwwYBsHjNn+PmHeCCRJuOWwKapdfjH= 9nt sHXTvyXBB2D3H7Oj7S/HOTXRNTUWhaxICKtq+XDSuJKOv7CNevkjMF4ybQDsrUxnaWd76YqNP= vZv PYoTqKzKukifjGXMsxC6HU4K2GscpvoaIk7glaD+NYi3fIGi/gR0UNc6cmXtOrYKSnCsNOwcO= CJL DjEr6YdbdAXO2wxCLqnupo8JRJgA8hjjHM5OoTGEyP/c+DKDqFO90YilX1XN8xchHrw+bDv0E= Zm0 RZpVdL7WNr7qQE4UhDfuyo4Gis4Z+npzoOL4g3yaQQfK32zZD9iqk9152b7ny2Ke5oFIF5SSa= EwH /2tLNBevzgzWuEB6FtqoMT5RjDyx+xBeImRlhnP0EenRh+EP0nmLCAaFiP4tTp1bX54SyByp8= wcN 7F2+v2Sgdd64w1pdrjT74Zf1xj0NTxEdt5jEaPfl5Vjv3cXiB8ACwPkMIXmkJx3uaGJynl4Os= irb nzzviEzvDVpLAxL7Qr6imlKUh92iAoz+XxEDqgMZnJJOTDFdDxEBhv911VzlRraDNdxw4MHMm= 5Nr 5pj4HGYh3PigzNo0KIreB50YqhGOesaC4Q75gv8mLc2Ec5dEq79BVMUOaCmYDShBN9j6JovNs= WSR 5YP3tXi+jZ+VnyKLft9wo1fh1oYadFEVSHgGsEY=3D =3DfoRs -----END PGP PUBLIC KEY BLOCK----- --------------A03683CE103C3FCF6029B6AB-- --8GcQb1ZzC4nYhOFoVafhjNrGptxPtcRgp-- --N7OPKHmdKB0h0lZflU37E0gNvSvlaqVxT Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEExndm/fpuMUdwYFFolh/E3EQov+AFAl++F9IFAwAAAAAACgkQlh/E3EQov+BM EQ/+L9CZjg2Pnp5a+hGpqwUCeEsnUxwx+/jmMh5A1ViEbi1YRPVVj0R7P74CgdB7PhbIBGmHu8Xf oIaUxCmUYmgA5jnXAZ8FVExaeAfjl2lPcD7/ruZEEx6BZOr/Koy1hRekmcvxv9Ri/T2kHdTJ50N7 CE/0pNjZGPy6YGJ59MhKCYAZCwI2lEfMvIi1+M9EyrVIbx3aDyOrZrTeF2awb2ood70CeDbWNRbw 38sMUHHYtRWPiJbtm7f8jGLOADC6Z8qpYCM3UTqT68fe4aDAyvYg1+dVZiKEDUOjU3+860K8YB7B 0uxcB5Rgm1EZgkTz15simbbOTqgY1WpAli0G8y5CflJafwUEczQHPBJmBI92DazUZ6fi2qp3wxc2 sWt6BBGfG8Kp46NQ0z8X3w14TMlXqCGY3235RtaWqqFWb1AeSkrRgyDbFCHpYfMJYyFphDppQfqt ewi244rCFmZQJ/ntXIh+OKP7yRQFzAsuhq1ow/nYx1+qrma03ZiD4JcuDhmS/xZn5y8W1PgKcxwG 3jpgE6I0v9Bc3bJwCELndt8ugNnGj3Z0qlWjAcLw4FHLKUjPlM1/0dpDAHl+ohM5fwDVzHmYAXGI 6NEt0YdoolgndGXV74T/bGUjjYBIWnf2EavLuuRiIt2KEFNi2Ad7TUfCnTcbzZqB11bRyrZsLptw whI= =0EzJ -----END PGP SIGNATURE----- --N7OPKHmdKB0h0lZflU37E0gNvSvlaqVxT-- --===============0770006234== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx --===============0770006234==--