Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp629274ybl; Fri, 13 Dec 2019 02:03:04 -0800 (PST) X-Google-Smtp-Source: APXvYqwk2OmSVEKnaPwOShQSVWKKRV97lWWVcoVRyz7tjAl57gFuR5qPPLrcNIMlOBQXaCGGdbh9 X-Received: by 2002:a05:6830:16c6:: with SMTP id l6mr14189585otr.186.1576231384587; Fri, 13 Dec 2019 02:03:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576231384; cv=none; d=google.com; s=arc-20160816; b=eszYAdegBG2GOh/y7nA/v9xSnGRNve5lByKxiJFd/v1u4k1E9/CFASO08f3Zn7drrW fyCBB+2gOIr4zg/Eoc5w2RjtUoHP5DLAiFDxWth2xzlXpTZpylZf7Z7FJeYRmUhHP2jP wzW5mtNh3PdMTI18+ErXZqiSsR0/p8HKSJWi3AhqSiUfqVEkdSO3fa3GeF3nZZbqlC/R q4Ogfu7UH/P/WTCcUL1hnMgUPl4zbCT+x7OQScLZNozJ2W+8aaI/NRaedln1jWBJUhnz g3W05vFDDbkUgFvH+jnwZbl5utUtcDspZDzHaf7bg9uo7/hII+sxK+civM2e6C7wUK4F DnTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature; bh=wNP4rI1DOEGJNKJHekEUoF6Vehge/dTvDIo4/5mFf6E=; b=a1hpSx7xsH6ANteVF+H1/eNGZ5iAHDCxA0CRkMRQ1GBEFXRldzbP1p00AFdcC8zRDC FyIa60iRR6JDO9Ow+fiu81/XLQ1l74S0nIZdo3YlKb1/8Vj3nh0yB17Yvo1r6jzYkA2I bkN54wAzTFPA1yo1YQH7DaeCylHZLs6vHnDsd/7Yu9LqjiUzfEBZMWPSXqfpUpse3hZx bGqkGdRkt0ZTKCZv78rZogn6RZ/mMZV4FHy7AG5uYDr1cWDSYDoWYluRZsNpzfewZqjr nfF8+PL7AWoWnK8euaAG4mvIilm93grVlx0Z97vsaarrBIEtOGcnvLvaVby6cKTnbL1H iy7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b="YsQksu/c"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r14si4606408oic.12.2019.12.13.02.02.50; Fri, 13 Dec 2019 02:03:04 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b="YsQksu/c"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726518AbfLMKAF (ORCPT + 99 others); Fri, 13 Dec 2019 05:00:05 -0500 Received: from mail-wm1-f65.google.com ([209.85.128.65]:36946 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725747AbfLMKAE (ORCPT ); Fri, 13 Dec 2019 05:00:04 -0500 Received: by mail-wm1-f65.google.com with SMTP id f129so5891858wmf.2 for ; Fri, 13 Dec 2019 02:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=wNP4rI1DOEGJNKJHekEUoF6Vehge/dTvDIo4/5mFf6E=; b=YsQksu/cONoPVHsqBo+Ol3YlvExGinuQQnGqL/9wnK6ssNjv2acpOzR/mF/5xjb0JC lLz2XwymDkMLftIpGSrkhlMGozPL55W9NaqX4oKer3AnYFXzByRAb9+fmwOtw3+Oqi0Q sRod9k8H6GnE0c2uXvhE2BaddqdnXk2tHRlqw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=wNP4rI1DOEGJNKJHekEUoF6Vehge/dTvDIo4/5mFf6E=; b=qAGfB8BJp1Y8ifDV898898INWlCwhuhI3NyKztmdS9/P1xUY8kRahooCGubQRUEKri Tq6geTbCr0/qkCXDUSpuNs1xhKAYvpGd5LlEF9YWsjqThVAuxIeKURmw0vKsshAb4mNA EZcfUMirit++W0ITl5zI8wZxHIp+fJGZ0qZZr/nbt+98g9tc/J0m2v1dCjD9f6Xh/pyg QFzS8GmZT09KhLiPHyDYmN7Ww1ctzNhmaeDt02I9KBYX0dH9SLtMqKNlJ/aDGiMDJhCV EAWNA1wuxH2UoYXNG1XEpzq8SMNX06iMdHOAyg3cJXs8Fwg5KQvmfjrHreLDBhogX9tN 4ODA== X-Gm-Message-State: APjAAAW0puIpPTWQvuDBeLGpLHWSeUfXzOTxhrBFvyMS0kz3kiIlVqn6 fZPeTc8Vv9djlRSd/3x7hI3lBA== X-Received: by 2002:a1c:8116:: with SMTP id c22mr11985885wmd.27.1576231202109; Fri, 13 Dec 2019 02:00:02 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:564b:0:7567:bb67:3d7f:f863]) by smtp.gmail.com with ESMTPSA id n67sm3084493wmf.46.2019.12.13.02.00.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Dec 2019 02:00:01 -0800 (PST) Date: Fri, 13 Dec 2019 10:59:59 +0100 From: Daniel Vetter To: Gerd Hoffmann Cc: Thomas Zimmermann , dri-devel@lists.freedesktop.org, David Airlie , open list , gurchetansingh@chromium.org Subject: Re: [PATCH v2 1/2] drm/shmem: add support for per object caching attributes Message-ID: <20191213095959.GA624164@phenom.ffwll.local> Mail-Followup-To: Gerd Hoffmann , Thomas Zimmermann , dri-devel@lists.freedesktop.org, David Airlie , open list , gurchetansingh@chromium.org References: <20191211081810.20079-1-kraxel@redhat.com> <20191211081810.20079-2-kraxel@redhat.com> <0b64e917-48f7-487e-9335-2838b6c62808@suse.de> <20191211123635.GY624164@phenom.ffwll.local> <20191211131830.iz3a2o4xzmmkjsp7@sirius.home.kraxel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191211131830.iz3a2o4xzmmkjsp7@sirius.home.kraxel.org> X-Operating-System: Linux phenom 5.3.0-2-amd64 User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 11, 2019 at 02:18:30PM +0100, Gerd Hoffmann wrote: > Hi, > > > btw on why udl does this: Imported bo are usually rendered by real hw, and > > reading it uncached/wc is the more defensive setting. It would be kinda > > nice if dma-buf would expose this, but I fear dma-api maintainers would > > murder us if we even just propose that ... so it's a mess right now. > > I suspect for imported dma-bufs we should leave the mmap() to the > exporter instead of pulling the pages out of the sgt and map them > ourself. Uh yes. If we still do that, then yes very much we shouldn't. Even better would be to just not do that, because the semantics of dumb gem mmap and dma-buf mmap differ (the latter has the begin/end access ioctl). If we can't ditch the mmap I think we should at least improve the helpers to do the redirect to dma_buf_mmap directly and stop drivers from doing silly stuff. > > btw the issue extends to dma access by devices too, e.g. both i915 and > > amdgpu can select the coherency mode at runtime (using e.g. the pcie > > no-snoop transaction mode), and we have similar uncoordinated hacks in > > there too, like in udl. > > Hmm. Ok. I guess I'm not going to try solve all that properly just for > the little virtio fix. > > Just curious: How do you tell your hardware? Are there bits for that > in the gtt, simliar to the caching bits in the x86 page tables? Brace for contact ... - on amdgpu it's a bit in the gpu pagetable. I think (but not sure, not an expert on these chips) that's the only way. - on i915 it's a also a bit in the gpu pagetables, but userspace can override the caching/coherency mode on a per-texture/render target/*BO level in the command stream. This is why gpus and dma-api don't mix well, since dma-api's goal is to hide all this even from the driver. gpus otoh leak it all the way to userspace. The trouble is as old as AGP from 1999 or so, I've become somewhat cynic at trying to fix this for real and not just with hacks. The disconnect between what we need and what dma-api kernel people want to give us is too big to bridge it seems. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch