tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

drm/panthor: Fix tiler OOM handling to allow incremental rendering

If the kernel couldn't allocate memory because we reached the maximum
number of chunks but no render passes are in flight
(panthor_heap_grow() returning -ENOMEM), we should defer the OOM
handling to the FW by returning a NULL chunk. The FW will then call
the tiler OOM exception handler, which is supposed to implement
incremental rendering (execute an intermediate fragment job to flush
the pending primitives, release the tiler memory that was used to
store those primitives, and start over from where it stopped).

Instead of checking for both ENOMEM and EBUSY, make panthor_heap_grow()
return ENOMEM no matter the reason of this allocation failure, the FW
doesn't care anyway.

v3:
- Add R-bs

v2:
- Make panthor_heap_grow() return -ENOMEM for all kind of allocation
failures
- Document the panthor_heap_grow() semantics

Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
Signed-off-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240502165158.1458959-2-boris.brezillon@collabora.com

authored by

Antonino Maniscalco and committed by
Boris Brezillon d2143297 713a7507

+14 -5
+8 -4
drivers/gpu/drm/panthor/panthor_heap.c
··· 410 410 * @renderpasses_in_flight: Number of render passes currently in-flight. 411 411 * @pending_frag_count: Number of fragment jobs waiting for execution/completion. 412 412 * @new_chunk_gpu_va: Pointer used to return the chunk VA. 413 + * 414 + * Return: 415 + * - 0 if a new heap was allocated 416 + * - -ENOMEM if the tiler context reached the maximum number of chunks 417 + * or if too many render passes are in-flight 418 + * or if the allocation failed 419 + * - -EINVAL if any of the arguments passed to panthor_heap_grow() is invalid 413 420 */ 414 421 int panthor_heap_grow(struct panthor_heap_pool *pool, 415 422 u64 heap_gpu_va, ··· 446 439 * handler provided by the userspace driver, if any). 447 440 */ 448 441 if (renderpasses_in_flight > heap->target_in_flight || 449 - (pending_frag_count > 0 && heap->chunk_count >= heap->max_chunks)) { 450 - ret = -EBUSY; 451 - goto out_unlock; 452 - } else if (heap->chunk_count >= heap->max_chunks) { 442 + heap->chunk_count >= heap->max_chunks) { 453 443 ret = -ENOMEM; 454 444 goto out_unlock; 455 445 }
+6 -1
drivers/gpu/drm/panthor/panthor_sched.c
··· 1385 1385 pending_frag_count, &new_chunk_va); 1386 1386 } 1387 1387 1388 - if (ret && ret != -EBUSY) { 1388 + /* If the heap context doesn't have memory for us, we want to let the 1389 + * FW try to reclaim memory by waiting for fragment jobs to land or by 1390 + * executing the tiler OOM exception handler, which is supposed to 1391 + * implement incremental rendering. 1392 + */ 1393 + if (ret && ret != -ENOMEM) { 1389 1394 drm_warn(&ptdev->base, "Failed to extend the tiler heap\n"); 1390 1395 group->fatal_queues |= BIT(cs_id); 1391 1396 sched_queue_delayed_work(sched, tick, 0);