similar to: [PATCH] drm/nouveau: Improve variable names in nouveau_sched_init()

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.

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()").

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

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: >>>>>

On Fri, 2024-02-02 at 17:14 +0000, Timur Tabi wrote: > On Fri, 2024-02-02 at 01:05 +0100, Danilo Krummrich wrote: > > 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. >

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: > > > > > >> ---

If a sched job depends on a dma-fence from a job from the same GPU scheduler instance, but a different scheduler entity, the GPU scheduler does only wait for the particular job to be scheduled, rather than for the job to fully complete. This is due to the GPU scheduler assuming that there is a scheduler instance per ring. However, the current implementation, in order to avoid arbitrary amounts of

"struct nouveau_job_ops" is not modified in these drivers. Constifying this structure moves some data to a read-only section, so increase overall security. In order to do it, "struct nouveau_job" and "struct nouveau_job_args" also need to be adjusted to this new const qualifier. On a x86_64, with allmodconfig: Before: ====== text data bss dec hex

On Thu, 23 Jan 2025 08:33:01 +0100 Philipp Stanner <phasta at mailbox.org> 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 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 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>

So far the DRM GPUVA manager offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVA manager represent a basic GPU-VM