similar to: [PATCH] drm/sched: Use struct for drm_sched_init() params

On Thu, Jan 23, 2025 at 10:35:43AM +0100, Philipp Stanner wrote: > On Thu, 2025-01-23 at 10:29 +0100, Danilo Krummrich wrote: > > On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote: > > > On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote: > > > > On Wed, 22 Jan 2025 15:08:20 +0100 > > > > Philipp Stanner <phasta at kernel.org>

Hi Philipp, On 23/01/25 09:13, Philipp Stanner wrote: > On Thu, 2025-01-23 at 08:10 -0300, Ma?ra Canal wrote: >> Hi Philipp, >> >> On 23/01/25 05:10, Philipp Stanner wrote: >>> On Wed, 2025-01-22 at 19:07 -0300, Ma?ra Canal wrote: >>>> Hi Philipp, >>>> >>>> On 22/01/25 11:08, Philipp Stanner wrote: >>>>>

drm_sched_init() has a great many parameters and upcoming new functionality for the scheduler might add even more. Generally, the great number of parameters reduces readability and has already caused one missnaming in: commit 6f1cacf4eba7 ("drm/nouveau: Improve variable name in nouveau_sched_init()"). Introduce a new struct for the scheduler init parameters and port all users.

On Wed, 2025-01-22 at 19:07 -0300, Ma?ra Canal wrote: > Hi Philipp, > > On 22/01/25 11:08, Philipp Stanner wrote: > > drm_sched_init() has a great many parameters and upcoming new > > functionality for the scheduler might add even more. Generally, the > > great number of parameters reduces readability and has already > > caused > > one missnaming in: >

Hi Philipp, On 22/01/25 11:08, Philipp Stanner wrote: > drm_sched_init() has a great many parameters and upcoming new > functionality for the scheduler might add even more. Generally, the > great number of parameters reduces readability and has already caused > one missnaming in: > > commit 6f1cacf4eba7 ("drm/nouveau: Improve variable name in nouveau_sched_init()").

On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote: > On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote: > > On Wed, 22 Jan 2025 15:08:20 +0100 > > Philipp Stanner <phasta at kernel.org> wrote: > > > > > ?int drm_sched_init(struct drm_gpu_scheduler *sched, > > > - ?? const struct drm_sched_backend_ops *ops, > > > - ??

On Wed, 22 Jan 2025 16:14:59 +0000 Tvrtko Ursulin <tursulin at ursulin.net> wrote: > On 22/01/2025 15:51, Boris Brezillon wrote: > > On Wed, 22 Jan 2025 15:08:20 +0100 > > Philipp Stanner <phasta at kernel.org> wrote: > > > >> --- a/drivers/gpu/drm/panthor/panthor_sched.c > >> +++ b/drivers/gpu/drm/panthor/panthor_sched.c > >> @@

On Wed, Jan 22, 2025 at 06:04:58PM +0100, Boris Brezillon wrote: > On Wed, 22 Jan 2025 16:14:59 +0000 > Tvrtko Ursulin <tursulin at ursulin.net> wrote: > > > On 22/01/2025 15:51, Boris Brezillon wrote: > > > On Wed, 22 Jan 2025 15:08:20 +0100 > > > Philipp Stanner <phasta at kernel.org> wrote: > > > > > >> ---

nouveau_sched_init() uses the function drm_sched_init(). The latter function has parameters called "hang_limit" and "timeout" in its API documentation. nouveau_sched_init(), however, defines a variable called "job_hang_limit" which is passed to drm_sched_init()'s "timeout" parameter. The actual "hang_limit" parameter is directly set to 0.

nouveau_sched_init() uses the function drm_sched_init(). The latter function has parameters called "hang_limit" and "timeout" in its API documentation. nouveau_sched_init(), however, defines a variable called "job_hang_limit" which is passed to drm_sched_init()'s "timeout" parameter. The actual "hang_limit" parameter is directly set to 0.

This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Cc: Alex Deucher <alexander.deucher at amd.com> Cc: amd-gfx at lists.freedesktop.org Cc: Ben Skeggs <bskeggs at redhat.com> Cc: "Christian K?nig" <christian.koenig at amd.com> Cc: Daniel Vetter <daniel at ffwll.ch>

nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call their corresponding *_fini() counterpart. This can lead to nouveau_sched_fini() being called without struct nouveau_sched ever being initialized in the first place. Instead of embedding struct nouveau_sched into struct nouveau_cli and struct nouveau_chan_abi16, allocate struct nouveau_sched separately, such that we can check

On Tue, 2024-06-04 at 10:27 -0500, Blake McBride wrote: > Greetings, > > I have used the nouveau driver with my Nvidia card on Linux.? Works > fine.? However, my problem has to do with running LLM on my GPU with > your driver.? My impression is, it doesn't work.? Am I correct? Yo, "it doesn't work" is not a very precise error description. The maintainers will

From: Dave Airlie <airlied at redhat.com> This is the 3rd iteration of this after talking to Ben and Danilo, I think this makes sense now. The fence sync logic doesn't handle a fence sync across devices as it tries to write to a channel offset from one device into the fence bo from a different device, which won't work so well. This patch fixes that to avoid using the sync path in