search for: drm_gpu_schedul

...EC to scale without it. > > ?From #nouveau: > > <gfxstrand> CTSing now > <gfxstrand> It looks like it's still going to take 1.5 hours. > > I may have an idea what could be the issue, let me explain. > > Currently, there is a single drm_gpu_scheduler having a > drm_sched_entity > per client (for VM_BIND jobs) and a drm_sched_entity per channel (for > EXEC jobs). > > For VM_BIND jobs the corresponding PT[E]s are allocated before the job > is pushed to the corresponding drm_sched_entity. The PT[E]s are &gt...

...; > that we can get EXEC to scale without it. > > From #nouveau: > > <gfxstrand> CTSing now > <gfxstrand> It looks like it's still going to take 1.5 hours. > > I may have an idea what could be the issue, let me explain. > > Currently, there is a single drm_gpu_scheduler having a drm_sched_entity > per client (for VM_BIND jobs) and a drm_sched_entity per channel (for > EXEC jobs). > > For VM_BIND jobs the corresponding PT[E]s are allocated before the job > is pushed to the corresponding drm_sched_entity. The PT[E]s are freed by > the schedulers...

...tself. It would still be good to see if we can find a way to >> reduce the cross-process drag in the implementation but that's a perf >> optimization we can do later. > > From the kernel side I think the only thing we could really do is to > temporarily run a secondary drm_gpu_scheduler instance, one for VM_BINDs > and one for EXECs until we got the new page table handling in place. > > However, the UMD could avoid such conditions more effectively, since it > controls the address space. Namely, avoid re-using the same region of > the address space right away i...

...ve, we need to either add that or prove > that we can get EXEC to scale without it. From #nouveau: <g?fxstrand> CTSing now <g?fxstrand> It looks like it's still going to take 1.5 hours. I may have an idea what could be the issue, let me explain. Currently, there is a single drm_gpu_scheduler having a drm_sched_entity per client (for VM_BIND jobs) and a drm_sched_entity per channel (for EXEC jobs). For VM_BIND jobs the corresponding PT[E]s are allocated before the job is pushed to the corresponding drm_sched_entity. The PT[E]s are freed by the schedulers free() callback pushing w...

...be good to see if we can find a way to > >> reduce the cross-process drag in the implementation but that's a perf > >> optimization we can do later. > > > > From the kernel side I think the only thing we could really do is to > > temporarily run a secondary drm_gpu_scheduler instance, one for VM_BINDs > > and one for EXECs until we got the new page table handling in place. > > > > However, the UMD could avoid such conditions more effectively, since it > > controls the address space. Namely, avoid re-using the same region of > > the addre...

...; > I think it'd be safer to just establish not to use the kernel global wq for executing > > > work in the fence signalling critical path. > > > > > > We could also run into similar problems with a dedicated wq, e.g. when drivers share > > > a wq between drm_gpu_scheduler instances (see [1]), however, I'm not sure we can catch > > > that with lockdep. > > > > I think if you want to fix it perfectly you'd need to set the max number > > of wq to the number of engines (or for dynamic/fw scheduled engines to the > > number of...

...ed = kzalloc(sizeof(*sched), GFP_KERNEL); + if (!sched) + return -ENOMEM; + + ret = nouveau_sched_init(sched, drm, wq, credit_limit); + if (ret) { + kfree(sched); + return ret; + } + + *psched = sched; + + return 0; +} + + +static void nouveau_sched_fini(struct nouveau_sched *sched) { struct drm_gpu_scheduler *drm_sched = &sched->base; @@ -471,3 +494,14 @@ nouveau_sched_fini(struct nouveau_sched *sched) if (sched->wq) destroy_workqueue(sched->wq); } + +void +nouveau_sched_destroy(struct nouveau_sched **psched) +{ + struct nouveau_sched *sched = *psched; + + nouveau_sched_fini(sched)...