Commit 2f835b5d authored by Dave Airlie's avatar Dave Airlie
Browse files

Merge tag 'topic/i915-gem-next-2021-03-26' of ssh://git.freedesktop.org/git/drm/drm into drm-next 



special i915-gem-next pull as requested

- Conversion to dma_resv_locking, obj->mm.lock is gone (Maarten, with
  help from Thomas Hellström)
- watchdog (Tvrtko, one patch to cancel individual request from Chris)
- legacy ioctl cleanup (Jason+Ashutosh)
- i915-gem TODO and RFC process doc (me)
- i915_ prefix for vma_lookup (Liam Howlett) just because I spotted it
  and put it in here too

Signed-off-by: default avatarDave Airlie <airlied@redhat.com>

From: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/YF24MHoOSjpKFEXA@phenom.ffwll.local
parents fe8a0578 e1a5e6a8

Documentation/gpu/index.rst

+1 −0
Original line number Original line Diff line number Diff line
@@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide 
   vga-switcheroo

   vga-switcheroo

   vgaarbiter

   vgaarbiter

   todo

   todo

   rfc/index





.. only::  subproject and html

.. only::  subproject and html

Documentation/gpu/rfc/index.rst

0 → 100644
+17 −0
Original line number Original line Diff line number Diff line 
===============

GPU RFC Section

===============



For complex work, especially new uapi, it is often good to nail the high level

design issues before getting lost in the code details. This section is meant to

host such documentation:



* Each RFC should be a section in this file, explaining the goal and main design

  considerations. Especially for uapi make sure you Cc: all relevant project

  mailing lists and involved people outside of dri-devel.



* For uapi structures add a file to this directory with and then pull the

  kerneldoc in like with real uapi headers.



* Once the code has landed move all the documentation to the right places in

  the main core, helper or driver sections.

drivers/gpu/drm/i915/Kconfig.profile

+14 −0
Original line number Original line Diff line number Diff line 
config DRM_I915_REQUEST_TIMEOUT

	int "Default timeout for requests (ms)"

	default 20000 # milliseconds

	help

	  Configures the default timeout after which any user submissions will

	  be forcefully terminated.



	  Beware setting this value lower, or close to heartbeat interval

	  rounded to whole seconds times three, in order to avoid allowing

	  misbehaving applications causing total rendering failure in unrelated

	  clients.



	  May be 0 to disable the timeout.



config DRM_I915_FENCE_TIMEOUT

config DRM_I915_FENCE_TIMEOUT

	int "Timeout for unsignaled foreign fences (ms, jiffy granularity)"

	int "Timeout for unsignaled foreign fences (ms, jiffy granularity)"

	default 10000 # milliseconds

	default 10000 # milliseconds

drivers/gpu/drm/i915/Makefile

+0 −1
Original line number Original line Diff line number Diff line
@@ -139,7 +139,6 @@ gem-y += \ 
	gem/i915_gem_dmabuf.o \

	gem/i915_gem_dmabuf.o \

	gem/i915_gem_domain.o \

	gem/i915_gem_domain.o \

	gem/i915_gem_execbuffer.o \

	gem/i915_gem_execbuffer.o \

	gem/i915_gem_fence.o \

	gem/i915_gem_internal.o \

	gem/i915_gem_internal.o \

	gem/i915_gem_object.o \

	gem/i915_gem_object.o \

	gem/i915_gem_object_blt.o \

	gem/i915_gem_object_blt.o \

drivers/gpu/drm/i915/TODO.txt

0 → 100644
+41 −0
Original line number Original line Diff line number Diff line 
gem/gt TODO items

-----------------



- For discrete memory manager, merge enough dg1 to be able to refactor it to

  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has

  improved a lot the past 2 years, there's no reason anymore not to use it.



- Come up with a plan what to do with drm/scheduler and how to get there.



- Roll out dma_fence critical section annotations.



- There's a lot of complexity added past few years to make relocations faster.

  That doesn't make sense given hw and gpu apis moved away from this model years

  ago:

  1. Land a modern pre-bound uapi like VM_BIND

  2. Any complexity added in this area past few years which can't be justified

  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on

  the bo and vm, plus some lru locks is all that needed. No complex rcu,

  refcounts, caching, ... on everything.

  This is the matching task on the vm side compared to ttm/dma_resv on the

  backing storage side.



- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.

  How-to-dma_fence is core and drivers really shouldn't build their own world

  here, treating everything else as a fixed platform. i915_sw_fence concepts

  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or

  removed if dri-devel consensus is that it's not a good idea. Once that's done

  maybe even remove it if there's nothing left.



Smaller things:

- i915_utils.h needs to be moved to the right places.



- dma_fence_work should be in drivers/dma-buf



- i915_mm.c should be moved to the right places. Some of the helpers also look a

  bit fishy:



  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/



- tasklet helpers in i915_gem.h also look a bit misplaced and should

  probably be moved to tasklet headers.