Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <4ea37684-5dda-94e4-a544-74d3812e8d9d@amd.com>
Date:   Thu, 23 Jun 2022 14:52:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: DMA-buf and uncached system memory
Content-Language: en-US
To:     Lucas Stach <l.stach@pengutronix.de>,
        Pekka Paalanen <ppaalanen@gmail.com>
Cc:     "Sharma, Shashank" <Shashank.Sharma@amd.com>,
        lkml <linux-kernel@vger.kernel.org>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        Nicolas Dufresne <nicolas@ndufresne.ca>,
        linaro-mm-sig@lists.linaro.org,
        Sumit Semwal <sumit.semwal@linaro.org>,
        linux-media <linux-media@vger.kernel.org>
References: <91ff0bbb-ea3a-2663-3453-dea96ccd6dd8@amd.com>
 <YCuPhOT4GhY3RR/6@phenom.ffwll.local>
 <9178e19f5c0e141772b61b759abaa0d176f902b6.camel@ndufresne.ca>
 <CAPj87rPYQNkgVEdHECQcHcYe2nCpgF3RYQKk_=wwhvJSxwHXCg@mail.gmail.com>
 <c6e65ee1-531e-d72c-a6a6-da7149e34f18@amd.com>
 <20220623101326.18beeab3@eldfell>
 <954d0a9b-29ef-52ef-f6ca-22d7e6aa3f4d@amd.com>
 <4b69f9f542d6efde2190b73c87096e87fa24d8ef.camel@pengutronix.de>
 <adc626ec-ff5a-5c06-44ce-09111be450cd@amd.com>
 <fbb228cd78e9bebd7e7921c19e0c4c09d0891f23.camel@pengutronix.de>
 <e691bccc-171d-f674-2817-13a945970f4a@amd.com>
 <95cca943bbfda6af07339fb8d2dc7f4da3aa0280.camel@pengutronix.de>
 <05814ddb-4f3e-99d8-025a-c31db7b2c46b@amd.com>
 <708e27755317a7650ca08ba2e4c14691ac0d6ba2.camel@pengutronix.de>
 <6287f5f8-d9af-e03d-a2c8-ea8ddcbdc0d8@amd.com>
 <f3c32cdd2ab4e76546c549b0cebba8e1d19d1cb0.camel@pengutronix.de>
 <34a1efd9-5447-848b-c08c-de75b48e997e@amd.com>
 <3c088a9a511762f7868b10dbe431942d3724917a.camel@pengutronix.de>
From:   =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
In-Reply-To: <3c088a9a511762f7868b10dbe431942d3724917a.camel@pengutronix.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S3hWWXo0UDRzTTdHcU1XM1V0UmNxSTR1UXYvdGhuMEc5RkFDNkswSzZzREI2?=
 =?utf-8?B?Um1CVkZ1eDdDYXp6Vm1naXpuOE9WL3hLL1oyZklwdjZ6dlpHMkpMaWdMNkk5?=
 =?utf-8?B?dDEyTll3WHRlanM5L3lvdzNUQzl0aWVKdWc1MkFRTUo4cDlzb2JnU3cvMG5E?=
 =?utf-8?B?WTBZbDNnZTU4YjJnSENMZUdIdWN1TE9CSU5abTFreVRJdXJ2eHZQS01HWVBM?=
 =?utf-8?B?R05MYzN6VFpJcitxMlVmaWdETEZDRVFNempvRGZnd1E4TXVReUJMbzZEaDVS?=
 =?utf-8?B?ZytmaVVLbkUyQmx0VW01SndjcGVsQml4Lzl5SEwvaHVJcDhlWElWWW03UEJ6?=
 =?utf-8?B?M3NoMVhRU3pNSWhVMHRYV2JDYzFtUjJkTWRQenNWQ05YQXNPS0pqK0FJdHJi?=
 =?utf-8?B?Yk8rOUh4ZW9GY2ZMdEM5dU9OTnFpam56ZXg4MFFydWdxWHhTSXN4Q0E4dmVi?=
 =?utf-8?B?NUMxM2RNYWkyNkxMbDAwbXBZK2pCNGNVa3B2SWZ1TW1NS3NveGpVMmJoSU1a?=
 =?utf-8?B?bVlPNUFGRmNQaTVpRDN2Q2VkckZ3d3BzRmF5K1hrSjdGbnJnVzRpZnIyVFRr?=
 =?utf-8?B?VXcwRGpMTmxxMW9DTTg2Wlcxd1g1TkZXN2RnK1lvZ2o3djZmeFVJVmZiMnky?=
 =?utf-8?B?UmJjOW5hdHlaZEU1VVJYU1VaQjM5Z0NXdm83M3N6RnBLcStCb3ZRdzcveWx4?=
 =?utf-8?B?NTdFMjhnMklLakdrL0VuVTMzKy9oNWlldDd4bEdjTjdwMWEvUGFxQ3h4T1V5?=
 =?utf-8?B?VzBVYkpQRkhTSGdrVU90SmdXQWN5d1VZcGE0VlY2Y1VSQkxRR1VEZEZ2YVA4?=
 =?utf-8?B?UG9odHBvbU4yRGdxYlR6WWFwTkJMdFh5ZjloNFBaT21rRUljbXVhK1hsMXFG?=
 =?utf-8?B?MlRmTkNSWkNSR0huODB0NzVSak9Obm5aVzAyM2hxNjhUUm5hOCs4YWdBNmxM?=
 =?utf-8?B?SVZFSUVNM2dxb2djVnA5R2VSWVV2M3NWOGt6R1J0TytzZzg0ZEtybnBQOHRL?=
 =?utf-8?B?dXN2NnlEbFRDeXV1cVhhTFFQVlpZazVDaWVvZUFDbzFBQWR1ZGNMaytpc2xL?=
 =?utf-8?B?ZnpSYkVnVkRNTVpsNTlJTld5UUR6cklnUSs5M0JoaG1lZlRRUHZyNGhiZWxw?=
 =?utf-8?B?T2RNbVJnVjNDOVdaOVdhMFQydS9rTzVJcW41ZzlibUg3Z0oyNWg4dHRleG1S?=
 =?utf-8?B?V2dYZHlhTmRlN3ZBNWR2c0hBeXZOQ1B0am5udCt2cCs3Y0JuU25jRU13WDF6?=
 =?utf-8?B?dWdKdTg1eTk2NjYwd2hTNVZka3BwYlBITmRQZTFHRVUrQ1FlemJKZElIbmgw?=
 =?utf-8?B?bVgrZnBTNm40bFpjUVh4czJzektXVC9YUW42MFhmdFRPN0RLNEVCK1NDOXEv?=
 =?utf-8?B?N0UzcWs0ZVdXbVBLNVovQ1ZmQmRuakJyVHNuL0E2cERoNlFYeHFoUjl2Vk9L?=
 =?utf-8?B?a2ZtSGNUbGFoVjBFSkwxUkRXTk1BRlFLbkdjM0R5SFluUy9xZ1JGbG9MNGZ0?=
 =?utf-8?B?aHYrYWk2WG0zMlprY3h0QU1LMDVHVUhYTjVrbjB0M1NVNVRCbUFQbmFBQnBr?=
 =?utf-8?B?aVVDTnhHQXFqcjhhQXVCUStNN0pSVzNxck1PNFhYMjRRMzJsc080R3N5d2Zz?=
 =?utf-8?B?R2hNbHhJeGR5ejN0c2J3NVlVa2pZZyt0bkNVR0FoQ0lZN05WaThZVzVNMklv?=
 =?utf-8?B?elVUeitGQzJQVTBvbHhra0k5NStFWGxVU1NodTFyNVV5Z0FqN2ZPODdEcE51?=
 =?utf-8?B?Y3NkUWJOakNXMFhZUFd0TmEzdVY2MVUrTW9uUmVqVml0c3VBZHMyeDNNUldO?=
 =?utf-8?B?NTlZU2dUZ2lIQkNZZDZLVFNmRmk5cEJpVWRuZGlSd1R0Q0pHd1FtOXN0aVZG?=
 =?utf-8?B?MVZ3TVhNeTRNc0E2dDEyTmpYa0hpQkdDME1VYmhOWkxWczRmSXkySGhrbDd3?=
 =?utf-8?B?bERxS21DdnpqdlBHenRVSnVrT3FPNlNUZ3VnQy85ZHEyd2MyT1M2RnZOYmZN?=
 =?utf-8?B?TUFIdkNxb2JiV0lkMy9nRjhtaWc5WnpicmFTc3VXQU0ybWpPZUgyaDV4WmdM?=
 =?utf-8?B?N2lKVjRsM2pHa1RQb1FZcVljUDduZlNTVGlxSjRkRnFMNjQxZC90bWNyTDVL?=
 =?utf-8?Q?nk8KueZQ4zyVRgGHP0nZrAR1W?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9206c228-2d66-49bb-27ba-08da55173d51
X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3587.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2022 12:52:32.9402
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: SJcUBIToynekO4bPRFH4MWl5iNZbaoat3sS1rbTvPbJOJbQzsDnOkT8kaqX3NkYa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1201MB2555
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Am 23.06.22 um 14:14 schrieb Lucas Stach:
> Am Donnerstag, dem 23.06.2022 um 13:54 +0200 schrieb Christian König:
>> Am 23.06.22 um 13:29 schrieb Lucas Stach:
>> [SNIP]
>> I mean I even had somebody from ARM which told me that this is not going
>> to work with our GPUs on a specific SoC. That there are ARM internal use
>> cases which just seem to work because all the devices are non-coherent
>> is completely new to me.
>>
> Yes, trying to hook up a peripheral that assumes cache snooping in some
> design details to a non coherent SoC may end up exploding in various
> ways. On the other hand you can work around most of those assumptions
> by marking the memory as uncached to the CPU, which may tank
> performance, but will work from a correctness PoV.

Yeah, and exactly that's what I meant with "DMA-buf is not the framework 
for this".

See we do support using uncached/not snooped memory in DMA-buf, but only 
for the exporter side.

For example the AMD and Intel GPUs have a per buffer flag for this.

The importer on the other hand needs to be able to handle whatever the 
exporter provides.

>> [SNIP]
>>> Non coherent access, including your non-snoop scanout, and no domain
>>> transition signal just doesn't go together when you want to solve
>>> things in a generic way.
>> Yeah, that's the stuff I totally agree on.
>>
>> See we absolutely do have the requirement of implementing coherent
>> access without domain transitions for Vulkan and OpenGL+extensions.
>>
> Coherent can mean 2 different things:
> 1. CPU cached with snooping from the IO device
> 2. CPU uncached
>
> The Vulkan and GL "coherent" uses are really coherent without explicit
> domain transitions, so on non coherent arches that require the
> transitions the only way to implement this is by making the memory CPU
> uncached. Which from a performance PoV will probably not be what app
> developers expect, but will still expose the correct behavior.

Quite a boomer for performance, but yes that should work.

>>> Remember that in a fully (not only IO) coherent system the CPU isn't
>>> the only agent that may cache the content you are trying to access
>>> here. The dirty cacheline could reasonably still be sitting in a GPU or
>>> VPU cache, so you need some way to clean those cachelines, which isn't
>>> a magic "importer knows how to call CPU cache clean instructions".
>> IIRC we do already have/had a SYNC_IOCTL for cases like this, but (I
>> need to double check as well, that's way to long ago) this was kicked
>> out because of the requirements above.
>>
> The DMA_BUF_IOCTL_SYNC is available in upstream, with the explicit
> documentation that "userspace can not rely on coherent access".

Yeah, double checked that as well. This is for the coherency case on the 
exporter side.

>>>> You can of course use DMA-buf in an incoherent environment, but then you
>>>> can't expect that this works all the time.
>>>>
>>>> This is documented behavior and so far we have bluntly rejected any of
>>>> the complains that it doesn't work on most ARM SoCs and I don't really
>>>> see a way to do this differently.
>>> Can you point me to that part of the documentation? A quick grep for
>>> "coherent" didn't immediately turn something up within the DMA-buf
>>> dirs.
>> Search for "cache coherency management". It's quite a while ago, but I
>> do remember helping to review that stuff.
>>
> That only turns up the lines in DMA_BUF_IOCTL_SYNC doc, which are
> saying the exact opposite of the DMA-buf is always coherent.

Sounds like I'm not making clear what I want to say here: For the 
exporter using cache coherent memory is optional, for the importer it isn't.

For the exporter it is perfectly valid to use kmalloc, get_free_page 
etc... on his buffers as long as it uses the DMA API to give the 
importer access to it.

The importer on the other hand needs to be able to deal with that. When 
this is not the case then the importer somehow needs to work around that.

Either by flushing the CPU caches or by rejecting using the imported 
buffer for this specific use case (like AMD and Intel drivers should be 
doing).

If the Intel or ARM display drivers need non-cached memory and don't 
reject buffer where they don't know this then that's certainly a bug in 
those drivers.

Otherwise we would need to change all DMA-buf exporters to use a special 
function for allocation non-coherent memory and that is certainly not 
going to fly.

> I also don't see why you think that both world views are so totally
> different. We could just require explicit domain transitions for non-
> snoop access, which would probably solve your scanout issue and would
> not be a problem for most ARM systems, where we could no-op this if the
> buffer is already in uncached memory and at the same time keep the "x86
> assumes cached + snooped access by default" semantics.

Well the key point is we intentionally rejected that design previously 
because it created all kind of trouble as well.

For this limited use case of doing a domain transition right before 
scanout it might make sense, but that's just one use case.

Regards,
Christian.

>
> Regards,
> Lucas
>
>