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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 B1ADEC48BC2 for ; Wed, 23 Jun 2021 18:43:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 977B661185 for ; Wed, 23 Jun 2021 18:43:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229660AbhFWSpt (ORCPT ); Wed, 23 Jun 2021 14:45:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229523AbhFWSps (ORCPT ); Wed, 23 Jun 2021 14:45:48 -0400 Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 48432C061574; Wed, 23 Jun 2021 11:43:31 -0700 (PDT) Received: by mail-oo1-xc2b.google.com with SMTP id k1-20020a0568200161b029024bef8a628bso965048ood.7; Wed, 23 Jun 2021 11:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cpkWeMAkWCf76CjUWKr9rUiGHMNQHXwmEhD8GnECJcY=; b=FAdddLGyvRhCK6AccX0MB+lVTROAnOJkBjUEiLvKrGbCjDXg8cMuBvzhCKCYG+2wp/ 7FJ3bFXrVJfND52cISdONm5rVb5W9wcg0gd6yEuwoMBJliQ+FKvkdyDQWzozxNSwBNbs JO7eZe4ZccJ/2bx2xYR8vGk+3FNkZO8h7JpLwuS4w5BJ2EAXBGSDJEkL0jivD5z+gFEw 7BIJX+4ApeN6hyu2dSaya30ciWfKtm1usu/9aEHqyXKsn8HrRL8Oik9b/5kIdMgkmffs 40h8uV5SomFi6A7tfXs9WuHwRD2nn3EpgHQL1ljq24NiTrr2WkcWAikxIxKIRjiJG6dp 7Gww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cpkWeMAkWCf76CjUWKr9rUiGHMNQHXwmEhD8GnECJcY=; b=dT2q+uAFiupTv8l87TZ91N6EWS61YuKmypmSJYHLxHxpnneShijbf9ko7dRyNMdiAB 5b6hgqiEoNjC3fTim3nk2I/6tEdEmsZ19XAG25guqblAiVR41k6DzQyl8dubrMCiylFX FFdJqsSNKu6zQ8LzPTqdSu6Oz+MD1lO30YPhJQypJqvX+MRWK9qGTF2bzw0tvkAXD81N neVC117VrIuCXjcJ7jWnz/1IdF/KuBxbEIwT8x61px+n8Di7aWmZdnkgYTEyx/Nr+atv 4JLhlo10CG6JRezacLXpDhI0u7qWKiYdxyfhaePoD0tZwekOQLkgVE+CkN04B8a26cIR pZNA== X-Gm-Message-State: AOAM531cvxcvINOmQtgFJQ9opiB15jxNke9fp5jIgwVJthlCrcod/r01 sM9FQMuToLEL8b8l9BXfT/7COmR1z8Kx0P5mxqQ= X-Google-Smtp-Source: ABdhPJztTw3IUTHnVPOKEUa+mzrtiHw343QNu8CeH1GRn9gntl2RUBK4RDrGb/9f1ZBukujNJOVgfhuumtOwviJ5UvE= X-Received: by 2002:a4a:1a84:: with SMTP id 126mr976948oof.77.1624473810500; Wed, 23 Jun 2021 11:43:30 -0700 (PDT) MIME-Version: 1.0 References: <20210622120142.GL1096940@ziepe.ca> <20210622152343.GO1096940@ziepe.ca> <3fabe8b7-7174-bf49-5ffe-26db30968a27@amd.com> <20210622154027.GS1096940@ziepe.ca> <09df4a03-d99c-3949-05b2-8b49c71a109e@amd.com> <20210622160538.GT1096940@ziepe.ca> <20210623182435.GX1096940@ziepe.ca> In-Reply-To: <20210623182435.GX1096940@ziepe.ca> From: Oded Gabbay Date: Wed, 23 Jun 2021 21:43:04 +0300 Message-ID: Subject: Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF To: Jason Gunthorpe Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , =?UTF-8?Q?Christian_K=C3=B6nig?= , Gal Pressman , sleybo@amazon.com, linux-rdma , Oded Gabbay , Christoph Hellwig , Linux Kernel Mailing List , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Doug Ledford , Tomer Tayar , amd-gfx list , Greg KH , Alex Deucher , Leon Romanovsky , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Wed, Jun 23, 2021 at 9:24 PM Jason Gunthorpe wrote: > > On Wed, Jun 23, 2021 at 10:57:35AM +0200, Christian K=C3=B6nig wrote: > > > > > No it isn't. It makes devices depend on allocating struct pages for= their > > > > BARs which is not necessary nor desired. > > > Which dramatically reduces the cost of establishing DMA mappings, a > > > loop of dma_map_resource() is very expensive. > > > > Yeah, but that is perfectly ok. Our BAR allocations are either in chunk= s of > > at least 2MiB or only a single 4KiB page. > > And very small apparently > > > > > Allocating a struct pages has their use case, for example for expos= ing VRAM > > > > as memory for HMM. But that is something very specific and should n= ot limit > > > > PCIe P2P DMA in general. > > > Sure, but that is an ideal we are far from obtaining, and nobody want= s > > > to work on it prefering to do hacky hacky like this. > > > > > > If you believe in this then remove the scatter list from dmabuf, add = a > > > new set of dma_map* APIs to work on physical addresses and all the > > > other stuff needed. > > > > Yeah, that's what I totally agree on. And I actually hoped that the new= P2P > > work for PCIe would go into that direction, but that didn't materialize= d. > > It is a lot of work and the only gain is to save a bit of memory for > struct pages. Not a very big pay off. > > > But allocating struct pages for PCIe BARs which are essentially registe= rs > > and not memory is much more hacky than the dma_resource_map() approach. > > It doesn't really matter. The pages are in a special zone and are only > being used as handles for the BAR memory. > > > By using PCIe P2P we want to avoid the round trip to the CPU when one d= evice > > has filled the ring buffer and another device must be woken up to proce= ss > > it. > > Sure, we all have these scenarios, what is inside the memory doesn't > realy matter. The mechanism is generic and the struct pages don't care > much if they point at something memory-like or at something > register-like. > > They are already in big trouble because you can't portably use CPU > instructions to access them anyhow. > > Jason Jason, Can you please explain why it is so important to (allow) access them through the CPU ? In regard to p2p, where is the use-case for that ? The whole purpose is that the other device accesses my device, bypassing the CPU. Thanks, Oded 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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 610D1C4743C for ; Wed, 23 Jun 2021 18:43:33 +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 DDBB861185 for ; Wed, 23 Jun 2021 18:43:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DDBB861185 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 65CA46E96F; Wed, 23 Jun 2021 18:43:32 +0000 (UTC) Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 701926E96F; Wed, 23 Jun 2021 18:43:31 +0000 (UTC) Received: by mail-oo1-xc31.google.com with SMTP id k21-20020a4a2a150000b029024955603642so969642oof.8; Wed, 23 Jun 2021 11:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cpkWeMAkWCf76CjUWKr9rUiGHMNQHXwmEhD8GnECJcY=; b=FAdddLGyvRhCK6AccX0MB+lVTROAnOJkBjUEiLvKrGbCjDXg8cMuBvzhCKCYG+2wp/ 7FJ3bFXrVJfND52cISdONm5rVb5W9wcg0gd6yEuwoMBJliQ+FKvkdyDQWzozxNSwBNbs JO7eZe4ZccJ/2bx2xYR8vGk+3FNkZO8h7JpLwuS4w5BJ2EAXBGSDJEkL0jivD5z+gFEw 7BIJX+4ApeN6hyu2dSaya30ciWfKtm1usu/9aEHqyXKsn8HrRL8Oik9b/5kIdMgkmffs 40h8uV5SomFi6A7tfXs9WuHwRD2nn3EpgHQL1ljq24NiTrr2WkcWAikxIxKIRjiJG6dp 7Gww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cpkWeMAkWCf76CjUWKr9rUiGHMNQHXwmEhD8GnECJcY=; b=e33hJSvVdYth5atEGOG+XYXjaKB52SYAoRJw/RKKHYz/D2QzDRKDWc9xyWPjvkZCh0 mfKs3taDWakBrkFQs6EfbyC9gILCQNN9NxWIJkWpF1EbP323qgAElfoiQ0LKrIK3QImv pht/X0QJlAdgF7lS7yUMb+7c07biiXRmIrq/tDR/Q0W4QyioXccjq7CSPFnN2XuZ8pO6 ho7jPnVFVbO8ME8dK44IWNqewvAgZ28iNV6+Uxgw/QD9PFlKRS5fD+M8WMpfI3Qtnv8H 37TXgodK18shFzzTxwydL0z6c6l5jRoSv/XjXgHYnV9t9HK6q+PuMQYLLMc2gl5gMC58 72jw== X-Gm-Message-State: AOAM532i8+Aa/2z/TAlPSNaSQbD8UniUI0B+UwRiBDTpbID1fPw/RhXO Jey1NPbkNrFbvsEkLh2BygsLQ9j8oDC39DT2xJw= X-Google-Smtp-Source: ABdhPJztTw3IUTHnVPOKEUa+mzrtiHw343QNu8CeH1GRn9gntl2RUBK4RDrGb/9f1ZBukujNJOVgfhuumtOwviJ5UvE= X-Received: by 2002:a4a:1a84:: with SMTP id 126mr976948oof.77.1624473810500; Wed, 23 Jun 2021 11:43:30 -0700 (PDT) MIME-Version: 1.0 References: <20210622120142.GL1096940@ziepe.ca> <20210622152343.GO1096940@ziepe.ca> <3fabe8b7-7174-bf49-5ffe-26db30968a27@amd.com> <20210622154027.GS1096940@ziepe.ca> <09df4a03-d99c-3949-05b2-8b49c71a109e@amd.com> <20210622160538.GT1096940@ziepe.ca> <20210623182435.GX1096940@ziepe.ca> In-Reply-To: <20210623182435.GX1096940@ziepe.ca> From: Oded Gabbay Date: Wed, 23 Jun 2021 21:43:04 +0300 Message-ID: Subject: Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF To: Jason Gunthorpe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-rdma , =?UTF-8?Q?Christian_K=C3=B6nig?= , sleybo@amazon.com, Leon Romanovsky , Gal Pressman , dri-devel , =?UTF-8?Q?Christian_K=C3=B6nig?= , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Doug Ledford , Tomer Tayar , amd-gfx list , Greg KH , Alex Deucher , Christoph Hellwig , Oded Gabbay , Linux Kernel Mailing List , "open list:DMA BUFFER SHARING FRAMEWORK" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Jun 23, 2021 at 9:24 PM Jason Gunthorpe wrote: > > On Wed, Jun 23, 2021 at 10:57:35AM +0200, Christian K=C3=B6nig wrote: > > > > > No it isn't. It makes devices depend on allocating struct pages for= their > > > > BARs which is not necessary nor desired. > > > Which dramatically reduces the cost of establishing DMA mappings, a > > > loop of dma_map_resource() is very expensive. > > > > Yeah, but that is perfectly ok. Our BAR allocations are either in chunk= s of > > at least 2MiB or only a single 4KiB page. > > And very small apparently > > > > > Allocating a struct pages has their use case, for example for expos= ing VRAM > > > > as memory for HMM. But that is something very specific and should n= ot limit > > > > PCIe P2P DMA in general. > > > Sure, but that is an ideal we are far from obtaining, and nobody want= s > > > to work on it prefering to do hacky hacky like this. > > > > > > If you believe in this then remove the scatter list from dmabuf, add = a > > > new set of dma_map* APIs to work on physical addresses and all the > > > other stuff needed. > > > > Yeah, that's what I totally agree on. And I actually hoped that the new= P2P > > work for PCIe would go into that direction, but that didn't materialize= d. > > It is a lot of work and the only gain is to save a bit of memory for > struct pages. Not a very big pay off. > > > But allocating struct pages for PCIe BARs which are essentially registe= rs > > and not memory is much more hacky than the dma_resource_map() approach. > > It doesn't really matter. The pages are in a special zone and are only > being used as handles for the BAR memory. > > > By using PCIe P2P we want to avoid the round trip to the CPU when one d= evice > > has filled the ring buffer and another device must be woken up to proce= ss > > it. > > Sure, we all have these scenarios, what is inside the memory doesn't > realy matter. The mechanism is generic and the struct pages don't care > much if they point at something memory-like or at something > register-like. > > They are already in big trouble because you can't portably use CPU > instructions to access them anyhow. > > Jason Jason, Can you please explain why it is so important to (allow) access them through the CPU ? In regard to p2p, where is the use-case for that ? The whole purpose is that the other device accesses my device, bypassing the CPU. Thanks, Oded 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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 5F424C4743C for ; Wed, 23 Jun 2021 18:43:37 +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 2B86B601FC for ; Wed, 23 Jun 2021 18:43:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B86B601FC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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 283E36E978; Wed, 23 Jun 2021 18:43:33 +0000 (UTC) Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 701926E96F; Wed, 23 Jun 2021 18:43:31 +0000 (UTC) Received: by mail-oo1-xc31.google.com with SMTP id k21-20020a4a2a150000b029024955603642so969642oof.8; Wed, 23 Jun 2021 11:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cpkWeMAkWCf76CjUWKr9rUiGHMNQHXwmEhD8GnECJcY=; b=FAdddLGyvRhCK6AccX0MB+lVTROAnOJkBjUEiLvKrGbCjDXg8cMuBvzhCKCYG+2wp/ 7FJ3bFXrVJfND52cISdONm5rVb5W9wcg0gd6yEuwoMBJliQ+FKvkdyDQWzozxNSwBNbs JO7eZe4ZccJ/2bx2xYR8vGk+3FNkZO8h7JpLwuS4w5BJ2EAXBGSDJEkL0jivD5z+gFEw 7BIJX+4ApeN6hyu2dSaya30ciWfKtm1usu/9aEHqyXKsn8HrRL8Oik9b/5kIdMgkmffs 40h8uV5SomFi6A7tfXs9WuHwRD2nn3EpgHQL1ljq24NiTrr2WkcWAikxIxKIRjiJG6dp 7Gww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cpkWeMAkWCf76CjUWKr9rUiGHMNQHXwmEhD8GnECJcY=; b=e33hJSvVdYth5atEGOG+XYXjaKB52SYAoRJw/RKKHYz/D2QzDRKDWc9xyWPjvkZCh0 mfKs3taDWakBrkFQs6EfbyC9gILCQNN9NxWIJkWpF1EbP323qgAElfoiQ0LKrIK3QImv pht/X0QJlAdgF7lS7yUMb+7c07biiXRmIrq/tDR/Q0W4QyioXccjq7CSPFnN2XuZ8pO6 ho7jPnVFVbO8ME8dK44IWNqewvAgZ28iNV6+Uxgw/QD9PFlKRS5fD+M8WMpfI3Qtnv8H 37TXgodK18shFzzTxwydL0z6c6l5jRoSv/XjXgHYnV9t9HK6q+PuMQYLLMc2gl5gMC58 72jw== X-Gm-Message-State: AOAM532i8+Aa/2z/TAlPSNaSQbD8UniUI0B+UwRiBDTpbID1fPw/RhXO Jey1NPbkNrFbvsEkLh2BygsLQ9j8oDC39DT2xJw= X-Google-Smtp-Source: ABdhPJztTw3IUTHnVPOKEUa+mzrtiHw343QNu8CeH1GRn9gntl2RUBK4RDrGb/9f1ZBukujNJOVgfhuumtOwviJ5UvE= X-Received: by 2002:a4a:1a84:: with SMTP id 126mr976948oof.77.1624473810500; Wed, 23 Jun 2021 11:43:30 -0700 (PDT) MIME-Version: 1.0 References: <20210622120142.GL1096940@ziepe.ca> <20210622152343.GO1096940@ziepe.ca> <3fabe8b7-7174-bf49-5ffe-26db30968a27@amd.com> <20210622154027.GS1096940@ziepe.ca> <09df4a03-d99c-3949-05b2-8b49c71a109e@amd.com> <20210622160538.GT1096940@ziepe.ca> <20210623182435.GX1096940@ziepe.ca> In-Reply-To: <20210623182435.GX1096940@ziepe.ca> From: Oded Gabbay Date: Wed, 23 Jun 2021 21:43:04 +0300 Message-ID: Subject: Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF To: Jason Gunthorpe 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: linux-rdma , =?UTF-8?Q?Christian_K=C3=B6nig?= , sleybo@amazon.com, Leon Romanovsky , Gal Pressman , dri-devel , =?UTF-8?Q?Christian_K=C3=B6nig?= , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Doug Ledford , Tomer Tayar , amd-gfx list , Greg KH , Alex Deucher , Christoph Hellwig , Oded Gabbay , Linux Kernel Mailing List , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" T24gV2VkLCBKdW4gMjMsIDIwMjEgYXQgOToyNCBQTSBKYXNvbiBHdW50aG9ycGUgPGpnZ0B6aWVw ZS5jYT4gd3JvdGU6Cj4KPiBPbiBXZWQsIEp1biAyMywgMjAyMSBhdCAxMDo1NzozNUFNICswMjAw LCBDaHJpc3RpYW4gS8O2bmlnIHdyb3RlOgo+Cj4gPiA+ID4gTm8gaXQgaXNuJ3QuIEl0IG1ha2Vz IGRldmljZXMgZGVwZW5kIG9uIGFsbG9jYXRpbmcgc3RydWN0IHBhZ2VzIGZvciB0aGVpcgo+ID4g PiA+IEJBUnMgd2hpY2ggaXMgbm90IG5lY2Vzc2FyeSBub3IgZGVzaXJlZC4KPiA+ID4gV2hpY2gg ZHJhbWF0aWNhbGx5IHJlZHVjZXMgdGhlIGNvc3Qgb2YgZXN0YWJsaXNoaW5nIERNQSBtYXBwaW5n cywgYQo+ID4gPiBsb29wIG9mIGRtYV9tYXBfcmVzb3VyY2UoKSBpcyB2ZXJ5IGV4cGVuc2l2ZS4K PiA+Cj4gPiBZZWFoLCBidXQgdGhhdCBpcyBwZXJmZWN0bHkgb2suIE91ciBCQVIgYWxsb2NhdGlv bnMgYXJlIGVpdGhlciBpbiBjaHVua3Mgb2YKPiA+IGF0IGxlYXN0IDJNaUIgb3Igb25seSBhIHNp bmdsZSA0S2lCIHBhZ2UuCj4KPiBBbmQgdmVyeSBzbWFsbCBhcHBhcmVudGx5Cj4KPiA+ID4gPiBB bGxvY2F0aW5nIGEgc3RydWN0IHBhZ2VzIGhhcyB0aGVpciB1c2UgY2FzZSwgZm9yIGV4YW1wbGUg Zm9yIGV4cG9zaW5nIFZSQU0KPiA+ID4gPiBhcyBtZW1vcnkgZm9yIEhNTS4gQnV0IHRoYXQgaXMg c29tZXRoaW5nIHZlcnkgc3BlY2lmaWMgYW5kIHNob3VsZCBub3QgbGltaXQKPiA+ID4gPiBQQ0ll IFAyUCBETUEgaW4gZ2VuZXJhbC4KPiA+ID4gU3VyZSwgYnV0IHRoYXQgaXMgYW4gaWRlYWwgd2Ug YXJlIGZhciBmcm9tIG9idGFpbmluZywgYW5kIG5vYm9keSB3YW50cwo+ID4gPiB0byB3b3JrIG9u IGl0IHByZWZlcmluZyB0byBkbyBoYWNreSBoYWNreSBsaWtlIHRoaXMuCj4gPiA+Cj4gPiA+IElm IHlvdSBiZWxpZXZlIGluIHRoaXMgdGhlbiByZW1vdmUgdGhlIHNjYXR0ZXIgbGlzdCBmcm9tIGRt YWJ1ZiwgYWRkIGEKPiA+ID4gbmV3IHNldCBvZiBkbWFfbWFwKiBBUElzIHRvIHdvcmsgb24gcGh5 c2ljYWwgYWRkcmVzc2VzIGFuZCBhbGwgdGhlCj4gPiA+IG90aGVyIHN0dWZmIG5lZWRlZC4KPiA+ Cj4gPiBZZWFoLCB0aGF0J3Mgd2hhdCBJIHRvdGFsbHkgYWdyZWUgb24uIEFuZCBJIGFjdHVhbGx5 IGhvcGVkIHRoYXQgdGhlIG5ldyBQMlAKPiA+IHdvcmsgZm9yIFBDSWUgd291bGQgZ28gaW50byB0 aGF0IGRpcmVjdGlvbiwgYnV0IHRoYXQgZGlkbid0IG1hdGVyaWFsaXplZC4KPgo+IEl0IGlzIGEg bG90IG9mIHdvcmsgYW5kIHRoZSBvbmx5IGdhaW4gaXMgdG8gc2F2ZSBhIGJpdCBvZiBtZW1vcnkg Zm9yCj4gc3RydWN0IHBhZ2VzLiBOb3QgYSB2ZXJ5IGJpZyBwYXkgb2ZmLgo+Cj4gPiBCdXQgYWxs b2NhdGluZyBzdHJ1Y3QgcGFnZXMgZm9yIFBDSWUgQkFScyB3aGljaCBhcmUgZXNzZW50aWFsbHkg cmVnaXN0ZXJzCj4gPiBhbmQgbm90IG1lbW9yeSBpcyBtdWNoIG1vcmUgaGFja3kgdGhhbiB0aGUg ZG1hX3Jlc291cmNlX21hcCgpIGFwcHJvYWNoLgo+Cj4gSXQgZG9lc24ndCByZWFsbHkgbWF0dGVy LiBUaGUgcGFnZXMgYXJlIGluIGEgc3BlY2lhbCB6b25lIGFuZCBhcmUgb25seQo+IGJlaW5nIHVz ZWQgYXMgaGFuZGxlcyBmb3IgdGhlIEJBUiBtZW1vcnkuCj4KPiA+IEJ5IHVzaW5nIFBDSWUgUDJQ IHdlIHdhbnQgdG8gYXZvaWQgdGhlIHJvdW5kIHRyaXAgdG8gdGhlIENQVSB3aGVuIG9uZSBkZXZp Y2UKPiA+IGhhcyBmaWxsZWQgdGhlIHJpbmcgYnVmZmVyIGFuZCBhbm90aGVyIGRldmljZSBtdXN0 IGJlIHdva2VuIHVwIHRvIHByb2Nlc3MKPiA+IGl0Lgo+Cj4gU3VyZSwgd2UgYWxsIGhhdmUgdGhl c2Ugc2NlbmFyaW9zLCB3aGF0IGlzIGluc2lkZSB0aGUgbWVtb3J5IGRvZXNuJ3QKPiByZWFseSBt YXR0ZXIuIFRoZSBtZWNoYW5pc20gaXMgZ2VuZXJpYyBhbmQgdGhlIHN0cnVjdCBwYWdlcyBkb24n dCBjYXJlCj4gbXVjaCBpZiB0aGV5IHBvaW50IGF0IHNvbWV0aGluZyBtZW1vcnktbGlrZSBvciBh dCBzb21ldGhpbmcKPiByZWdpc3Rlci1saWtlLgo+Cj4gVGhleSBhcmUgYWxyZWFkeSBpbiBiaWcg dHJvdWJsZSBiZWNhdXNlIHlvdSBjYW4ndCBwb3J0YWJseSB1c2UgQ1BVCj4gaW5zdHJ1Y3Rpb25z IHRvIGFjY2VzcyB0aGVtIGFueWhvdy4KPgo+IEphc29uCgpKYXNvbiwKQ2FuIHlvdSBwbGVhc2Ug ZXhwbGFpbiB3aHkgaXQgaXMgc28gaW1wb3J0YW50IHRvIChhbGxvdykgYWNjZXNzIHRoZW0KdGhy b3VnaCB0aGUgQ1BVID8KSW4gcmVnYXJkIHRvIHAycCwgd2hlcmUgaXMgdGhlIHVzZS1jYXNlIGZv ciB0aGF0ID8KVGhlIHdob2xlIHB1cnBvc2UgaXMgdGhhdCB0aGUgb3RoZXIgZGV2aWNlIGFjY2Vz c2VzIG15IGRldmljZSwKYnlwYXNzaW5nIHRoZSBDUFUuCgpUaGFua3MsCk9kZWQKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KYW1kLWdmeCBtYWlsaW5nIGxp c3QKYW1kLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3Rv cC5vcmcvbWFpbG1hbi9saXN0aW5mby9hbWQtZ2Z4Cg==