diff options
author | Jani Nikula <jani.nikula@intel.com> | 2022-04-11 16:01:56 +0300 |
---|---|---|
committer | Jani Nikula <jani.nikula@intel.com> | 2022-04-11 16:01:56 +0300 |
commit | 83970cd63b9f864525761137b500113ab0b49c94 (patch) | |
tree | 747b97113d60666cbb44f8a5633b961b7eda3c86 /Documentation/gpu | |
parent | 618f5df1f6a5a3f29fad824116da291a7d14ab5e (diff) | |
parent | 3123109284176b1532874591f7c81f3837bbdc17 (diff) |
Merge drm/drm-next into drm-intel-next
Sync up with v5.18-rc1, in particular to get 5e3094cfd9fb
("drm/i915/xehpsdv: Add has_flat_ccs to device info").
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Diffstat (limited to 'Documentation/gpu')
-rw-r--r-- | Documentation/gpu/todo.rst | 47 | ||||
-rw-r--r-- | Documentation/gpu/vgaarbiter.rst | 2 |
2 files changed, 37 insertions, 12 deletions
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7bf7f2111696..127e76ee0b2d 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -241,6 +241,28 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter Level: Advanced +Benchmark and optimize blitting and format-conversion function +-------------------------------------------------------------- + +Drawing to dispay memory quickly is crucial for many applications' +performance. + +On at least x86-64, sys_imageblit() is significantly slower than +cfb_imageblit(), even though both use the same blitting algorithm and +the latter is written for I/O memory. It turns out that cfb_imageblit() +uses movl instructions, while sys_imageblit apparently does not. This +seems to be a problem with gcc's optimizer. DRM's format-conversion +helpers might be subject to similar issues. + +Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion +helpers. In cases that can be further optimized, maybe implement a different +algorithm. For micro-optimizations, use movl/movq instructions explicitly. +That might possibly require architecture-specific helpers (e.g., storel() +storeq()). + +Contact: Thomas Zimmermann <tzimmermann@suse.de> + +Level: Intermediate drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup ----------------------------------------------------------------- @@ -475,8 +497,12 @@ This is a really varied tasks with lots of little bits and pieces: achieved by using an IPI to the local processor. * There's a massive confusion of different panic handlers. DRM fbdev emulation - helpers have one, but on top of that the fbcon code itself also has one. We - need to make sure that they stop fighting over each another. + helpers had their own (long removed), but on top of that the fbcon code itself + also has one. We need to make sure that they stop fighting over each other. + This is worked around by checking ``oops_in_progress`` at various entry points + into the DRM fbdev emulation helpers. A much cleaner approach here would be to + switch fbcon to the `threaded printk support + <https://lwn.net/Articles/800946/>`_. * ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and isn't a full solution for panic paths. We need to make sure that it only @@ -488,16 +514,15 @@ This is a really varied tasks with lots of little bits and pieces: even spinlocks (because NMI and hardirq can panic too). We need to either make sure to not call such paths, or trylock everything. Really tricky. -* For the above locking troubles reasons it's pretty much impossible to - attempt a synchronous modeset from panic handlers. The only thing we could - try to achive is an atomic ``set_base`` of the primary plane, and hope that - it shows up. Everything else probably needs to be delayed to some worker or - something else which happens later on. Otherwise it just kills the box - harder, prevent the panic from going out on e.g. netconsole. +* A clean solution would be an entirely separate panic output support in KMS, + bypassing the current fbcon support. See `[PATCH v2 0/3] drm: Add panic handling + <https://lore.kernel.org/dri-devel/20190311174218.51899-1-noralf@tronnes.org/>`_. -* There's also proposal for a simplied DRM console instead of the full-blown - fbcon and DRM fbdev emulation. Any kind of panic handling tricks should - obviously work for both console, in case we ever get kmslog merged. +* Encoding the actual oops and preceding dmesg in a QR might help with the + dread "important stuff scrolled away" problem. See `[RFC][PATCH] Oops messages + transfer using QR codes + <https://lore.kernel.org/lkml/1446217392-11981-1-git-send-email-alexandru.murtaza@intel.com/>`_ + for some example code that could be reused. Contact: Daniel Vetter diff --git a/Documentation/gpu/vgaarbiter.rst b/Documentation/gpu/vgaarbiter.rst index 339ed5fecd2e..bde3c0afb059 100644 --- a/Documentation/gpu/vgaarbiter.rst +++ b/Documentation/gpu/vgaarbiter.rst @@ -100,7 +100,7 @@ In-kernel interface .. kernel-doc:: include/linux/vgaarb.h :internal: -.. kernel-doc:: drivers/gpu/vga/vgaarb.c +.. kernel-doc:: drivers/pci/vgaarb.c :export: libpciaccess |