Re: [PATCH v3 5/5] drm: Add TODO item for optimizing format helpers
From: Sam Ravnborg <hidden>
Date: 2022-02-23 20:34:36
Also in:
dri-devel
On Wed, Feb 23, 2022 at 08:38:04PM +0100, Thomas Zimmermann wrote:
quoted hunk ↗ jump to hunk
Add a TODO item for optimizing blitting and format-conversion helpers in DRM and fbdev. There's always demand for faster graphics output. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> --- Documentation/gpu/todo.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7bf7f2111696..7f113c6a02dd 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'
display
+performance. + +On at least x86-64, sys_imageblit() is significantly slower than
On, at least x86-64, ... To me the extra comma makes sense, but grammar is not my strong side.
+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 +heleprs might be subject to similar issues.
helpers
+ +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.
algorithm. (period, not comma)
+That might possibly require architecture specific helpers (e.g., storel() +storeq()). + +Contact: Thomas Zimmermann [off-list ref] + +Level: Intermediate
With the small fixes above: Acked-by: Sam Ravnborg <redacted> Another option would be to re-implement imageblit() to be drm specific. Maybe we can then throw out some legacy code and optimize only for the drm use. And then maybe only a small part of the code would differ if this is I/O memory or direct accessible memory. Sam