Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Message-ID: <76963abd-77a1-4bbd-9537-7b230e648a90@amd.com>
Date:   Wed, 11 Oct 2023 09:07:38 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH drm-misc-next 2/3] drm/gpuva_mgr: generalize
 dma_resv/extobj handling and GEM validation
Content-Language: en-US
To:     Dave Airlie <airlied@gmail.com>,
        =?UTF-8?Q?Thomas_Hellstr=C3=B6m_=28Intel=29?= 
        <thomas_os@shipmail.org>
Cc:     Danilo Krummrich <dakr@redhat.com>, daniel@ffwll.ch,
        matthew.brost@intel.com, thomas.hellstrom@linux.intel.com,
        sarah.walker@imgtec.com, donald.robson@imgtec.com,
        boris.brezillon@collabora.com, faith.ekstrand@collabora.com,
        bskeggs@redhat.com, Liam.Howlett@oracle.com,
        nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        dri-devel@lists.freedesktop.org
References: <20230820215320.4187-1-dakr@redhat.com>
 <20230820215320.4187-3-dakr@redhat.com>
 <0c50ff22-0f11-1e27-c32e-694ce2b1e6c5@shipmail.org> <ZO864yp3UyVEfEjz@pollux>
 <88c45fe6-0942-707c-9ea7-8486c177fcd7@shipmail.org> <ZO9Zq2RhbX8EeHrn@pollux>
 <736b6b6d-9e04-a27d-7d60-0c45d696b304@shipmail.org>
 <ZPB26A0/oLHTmyqk@cassiopeiae>
 <a8f28d62-daec-927a-a33d-5be3eec6a1ed@shipmail.org>
 <ZPDk/lao1JlBNGoJ@cassiopeiae>
 <8a8253ae-0b85-df90-b480-64eeebfafc6d@shipmail.org>
 <CAPM=9tz3o-m+8VJJ6hxWhykat0kpp1UE7dBJE3X91aHHo1Y2VA@mail.gmail.com>
From:   =?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>
In-Reply-To: <CAPM=9tz3o-m+8VJJ6hxWhykat0kpp1UE7dBJE3X91aHHo1Y2VA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cElBV29scDg1WTgxUEsweTFJcTAzZmJXTTF1WFVQZFNXOFNWQ0JZeDJFV0Yz?=
 =?utf-8?B?cGsrdXRwaUxpaTYrUHBZcTFTZ3JnZjBrRUtqWTNFcnVXM0tNUjB0SHhab3hV?=
 =?utf-8?B?SGdCZjNXVlAwTS9SYTg4UUtVQWlCb2d2UnJhQmtXeFRLMko0WCtUWnhFL2JL?=
 =?utf-8?B?cVpONFFid1pySVMxdkNCK1ByNTZ1a0F6cWZhWXM0YzhsYUFoQUt0dkxrajVZ?=
 =?utf-8?B?OUxkQ0NkWUtBQjY0SGZ2RlI5ZUtoblpzMkZMUEhpMkp4RVBUZXBpa2pzdjhi?=
 =?utf-8?B?OTlyYll0TEhqOXVXVUdBMTFDSTlpa0N4bVJtVGJzdzB5ZEZTQkRra2NtOVZB?=
 =?utf-8?B?Rzg5a3kyS1JMYTlLOWp3L2N5REpZVkpuVnBOUSt6YUluK25pOFVmeTlJUith?=
 =?utf-8?B?NG5LTEZGWis2NTBFeFFwMzNRNFp1RmgzUEhrL1dBMGRRTzNwSHRSTWpCa0J4?=
 =?utf-8?B?ams0MFZ3VGRCTE9LOHoxZ2hJTHJ4NG5pZk9VWmhITDNZMitrTHhOblFBTjNl?=
 =?utf-8?B?NVBRU3lXSDNRVzhQUTFiRFdIMGlvcXBYTTBrbVQ2OE9EMVdKR25heWF0L3pB?=
 =?utf-8?B?YTcrL09xem5yNU1lb2NtWWIybEpObzRVdk1UMlZNY2hTR2F5RmFmVGo1N3d5?=
 =?utf-8?B?aFNLSlIvME5NcllXandlOFhla1laZ1NLdVBZVWJWRzZZZVZ6Z3VQOStuRkE2?=
 =?utf-8?B?Rm91QVkxUG9qaDRTdnNvQUl0SmdvTTJqZjF5ZHFNVlRCbjBTeU81ZzRodk5K?=
 =?utf-8?B?REZzalVjSTRkbzNONnZCaFkzYTBkazdKZGYrSU5YNXloRWhlNEI3TzQ5V1Z5?=
 =?utf-8?B?N1MzcTBPeC9oWEJvQS93NkNTN3FPRVBiQmgyNk54eDkzQWJjUE5UTVZmWjIr?=
 =?utf-8?B?dkJRL0xzNFdxZGlpUkJCQmF3bG9GSVN5UHFXNEFONnpUaW94bGlxU3RFcHZn?=
 =?utf-8?B?emszTWM4WldFZ29DMDI2NThTR1MvY2V4U3JvVEgzaDJrZUZUYU0xK0cveC9m?=
 =?utf-8?B?WEtyZm15Z0hJck9VOEwzSC9MOHV3T0l0N09IaFREZmZTcjhsNDVDS1lZbWFa?=
 =?utf-8?B?eFM3SW4xVzNOZzBXaElheHBwdC9iU3lBS1k2bTl5d25BdWdaVWNFVkdETjlT?=
 =?utf-8?B?cXJKQ2xBQTNaWkNzYjVBNmxxMVl2YWJZUHVwM1h2Vm80VExGVDhnWGJ4YU5B?=
 =?utf-8?B?a01oSlZBUFY2MVFvZVQ4czdkaHBSbmZhMDY0ZUFHcGdaTlJoQnJOSkJZTTFx?=
 =?utf-8?B?Y1ZRNmEweE5OOHd4Mnl2MVlsemhLZ3hUSzU1WURhTHNlSUhxaFcxZ0krUlZz?=
 =?utf-8?B?bUxxWFFOeVJRRHF1b0U0cEgzTG10QTNTTjAweWptZktqVjFOUXdFTENzcWh2?=
 =?utf-8?B?cmdpZFZoWWJ1WEpWRkVUcTZHcHdwd2dSNS9FOGJRTnBQdUduZldQa1pjUmsv?=
 =?utf-8?B?NnI1eTlBSE93WXRsL2VVTzNUbkFTUmFKUytzdFJ1UnM2UFAwbFpURUtNWUE0?=
 =?utf-8?B?Q1pHVXYyeWNOR0dNcmlVN1d2T1NxMFhUL2tid3ovNURsSkhDNTJmenhPQUNq?=
 =?utf-8?B?SlRTdFZXeWpQNjZhS1VORHBPUWQrVXF4RW9DUlI4aW50QktyNkVZakVVZ3di?=
 =?utf-8?B?MXNpVTgrM2U1RDVCd1NCMUVpUUY0RStwOE0zWS83NHpzc2VlbzhvemdRaE45?=
 =?utf-8?B?Ym5sWnFKK210RnNXMFF2WmJEeDhTUk5FZzVXRVpOQzcySDFmaEpPVUpFeGZQ?=
 =?utf-8?B?UHNHQ0szRFZneUl6ZE84L0NQWXRHOTVUckszZm1tT1llWTlqSjRKMVBSdTAv?=
 =?utf-8?B?dDdZUVZZTTlad3lSRW13anF5REVja1ozZjRZQ0xndzloYVdIT3JzbzZ4L2xV?=
 =?utf-8?B?WFJlZWtBTkh0TDdQbzFtRXc2by9nM1VEWHpIREIyMWlsZXR2MjczdVBrSlha?=
 =?utf-8?B?OTlQYjVYT2ZqbERETjBuUXdoZ051dEhGT016R2pXY3F2aDhmdWJVcGt3cFEr?=
 =?utf-8?B?MDNWUWoyZTVmcU1lZU1YZmtJRUUrYkFYMUlKN25GNjVWVE9WNEd3ckttY3Vv?=
 =?utf-8?B?R2xsek4zc2g0akFvcmNEbDRic2NnZm1yMWptU2phWG1Gek5aVFNnajFaSnI5?=
 =?utf-8?Q?aCVXlhIOB0TQBrgGw+Fq2T689?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 51acd07b-2f15-439b-4b12-08dbca28c3e6
X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3587.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2023 07:07:44.0307
 (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: rmFo+dEfiINTvvdJNPqEPuL7P1iPgzrkCwa0/MWpc/DbUIhWmHXSIKsC2i5Is3Nl
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7345
X-Spam-Status: No, score=2.7 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS,
	URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Wed, 11 Oct 2023 00:08:21 -0700 (PDT)
X-Spam-Level: **

Am 10.10.23 um 22:23 schrieb Dave Airlie:
>> I think we're then optimizing for different scenarios. Our compute
>> driver will use mostly external objects only, and if shared, I don't
>> forsee them bound to many VMs. What saves us currently here is that in
>> compute mode we only really traverse the extobj list after a preempt
>> fence wait, or when a vm is using a new context for the first time. So
>> vm's extobj list is pretty large. Each bo's vma list will typically be
>> pretty small.
> Can I ask why we are optimising for this userspace, this seems
> incredibly broken.
>
> We've has this sort of problem in the past with Intel letting the tail
> wag the horse, does anyone remember optimising relocations for a
> userspace that didn't actually need to use relocations?
>
> We need to ask why this userspace is doing this, can we get some
> pointers to it? compute driver should have no reason to use mostly
> external objects, the OpenCL and level0 APIs should be good enough to
> figure this out.

Well that is pretty normal use case, AMD works the same way.

In a multi GPU compute stack you have mostly all the data shared between 
different hardware devices.

As I said before looking at just the Vulcan use case is not a good idea 
at all.

Christian.

>
> Dave.