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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 3E140CAC5B5 for ; Mon, 29 Sep 2025 14:07:29 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id EFC6110E428; Mon, 29 Sep 2025 14:07:28 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="VIwCs6nE"; dkim-atps=neutral Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9AD9710E428; Mon, 29 Sep 2025 14:07:27 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 56F1462229; Mon, 29 Sep 2025 14:07:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E39D5C4CEF4; Mon, 29 Sep 2025 14:07:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1759154846; bh=BKY6d1yBc/lroKagYCaSuXxxZ2I6xVz7xuOdW9gGVog=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=VIwCs6nERrhW0nxOSUX19uKaSbWaPiA57FLkrY/4Uprkq5LgrHoiUivCfaZvPlDJb i6KLN/dKDKpt1NR2uxgGrDR52CIUwIHMg23DAcNlGqdewpdtJ70FJNG6vguN5c0uqv nZXAhALVBgh98eaVa0iqjXEivUiyt33u0EBXa0WBUTXuKPWVYVyzjfZ9M0LVem7OQo AEEPO53AterwJzs/a9z5iozTdGXW9hC5C2TJZP7d2vbXGRMDMCg6jLfr24uZafLKzw nS5iP9sVWdC/gpZ6Qm187pNyhz6baXQw04PzSAY31gKs37HoOgNmPLp4Ijx6IsJwhb y4VzpOZRGf51w== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 29 Sep 2025 16:07:18 +0200 Message-Id: Subject: Re: [RFC v8 00/21] DRM scheduling cgroup controller Cc: , , , , , , =?utf-8?q?Christian_K=C3=B6nig?= , "Leo Liu" , =?utf-8?q?Ma=C3=ADra_Canal?= , "Matthew Brost" , =?utf-8?q?Michal_Koutn=C3=BD?= , =?utf-8?q?Michel_D=C3=A4nzer?= , "Philipp Stanner" , "Pierre-Eric Pelloux-Prayer" , "Rob Clark" , "Tejun Heo" , "Alexandre Courbot" , "Alistair Popple" , "John Hubbard" , "Joel Fernandes" , "Timur Tabi" , "Alex Deucher" , "Lucas De Marchi" , =?utf-8?q?Thomas_Hellstr=C3=B6m?= , "Rodrigo Vivi" , "Boris Brezillon" , "Rob Herring" , "Steven Price" , "Liviu Dudau" , "Daniel Almeida" , "Alice Ryhl" , "Boqun Feng" , =?utf-8?q?Gr=C3=A9goire_P=C3=A9an?= To: "Tvrtko Ursulin" From: "Danilo Krummrich" References: <20250903152327.66002-1-tvrtko.ursulin@igalia.com> In-Reply-To: <20250903152327.66002-1-tvrtko.ursulin@igalia.com> X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Wed Sep 3, 2025 at 5:23 PM CEST, Tvrtko Ursulin wrote: > This is another respin of this old work^1 which since v7 is a total rewri= te and > completely changes how the control is done. I only got some of the patches of the series, can you please send all of th= em for subsequent submissions? You may also want to consider resending if you'= re not getting a lot of feedback due to that. :) > On the userspace interface side of things it is the same as before. We ha= ve > drm.weight as an interface, taking integers from 1 to 10000, the same as = CPU and > IO cgroup controllers. In general, I think it would be good to get GPU vendors to speak up to what= kind of interfaces they're heading to with firmware schedulers and potential fir= mware APIs to control scheduling; especially given that this will be a uAPI. (Adding a couple of folks to Cc.) Having that said, I think the basic drm.weight interface is fine and should= work in any case; i.e. with the existing DRM GPU scheduler in both modes, the upcoming DRM Jobqueue efforts and should be generic enough to work with potential firmware interfaces we may see in the future. Philipp should be talking about the DRM Jobqueue component at XDC (probably= just in this moment). -- Some more thoughts on the DRM Jobqueue and scheduling: The idea behind the DRM Jobqueue is to be, as the name suggests, a componen= t that receives jobs from userspace, handles the dependencies (i.e. dma fence= s), and executes the job, e.g. by writing to a firmware managed software ring. It basically does what the GPU scheduler does in 1:1 entity-scheduler mode, just without all the additional complexity of moving job ownership from one component to another (i.e. from entity to scheduler, etc.). With just that, there is no scheduling outside the GPU's firmware scheduler= of course. However, additional scheduler capabilities, e.g. to support hardwar= e rings, or manage firmware schedulers that only support a limited number of software rings (like some Mali GPUs), can be layered on top of that: In contrast to the existing GPU scheduler, the idea would be to keep lettin= g the DRM Jobqueue handle jobs submitted by userspace from end to end (i.e. let t= he push to the hardware (or software) ring buffer), but have an additional component, whose only purpose is to orchestrate the DRM Jobqueues, by manag= ing when they are allowed to push to a ring and which ring they should push to. This way we get rid of one of the issue that the existing GPU scheduler mov= es job ownership between components of different lifetimes (entity and schedul= er), which is one of the fundamental hassles to deal with.