This series adds DMA and IRQ for the mgag200 driver.
Unfortunately the DMA doesn't make the driver faster.
But it's still a big improvement regarding CPU usage and latency.
CPU usage goes from 100% of 1 CPU to 3% (using top and refreshing the screen continuously).
top without DMA, and a bash script to refresh the screen continuously
PID S %CPU TIME+ COMMAND
1536 R 100.0 4:02.78 kworker/1:0+events
1612 S 3.0 0:03.82 bash
16 I 0.3 0:01.56 rcu_preempt
1467 I 0.3 0:00.11 kworker/u64:1-events_unbound
3650 R 0.3 0:00.02 top
top with DMA, and the same bash script:
PID S %CPU TIME+ COMMAND
1335 D 3.0 0:01.26 kworker/2:0+events
1486 S 0.3 0:00.14 bash
1846 R 0.3 0:00.03 top
1 S 0.0 0:01.87 systemd
2 S 0.0 0:00.00 kthreadd
Latency, measured with cyclictest -s -l 10000:
Without DMA:
# /dev/cpu_dma_latency set to 0us
policy: other/other: loadavg: 1.52 0.52 0.33 3/358 2025
T: 0 ( 1977) P: 0 I:1000 C: 10000 Min: 7 Act: 56 Avg: 85 Max: 2542
With DMA:
# /dev/cpu_dma_latency set to 0us
policy: other/other: loadavg: 1.27 0.48 0.18 2/363 2498
T: 0 ( 2403) P: 0 I:1000 C: 10000 Min: 8 Act: 62 Avg: 59 Max: 339
Last benchmark is glxgears. It's still software rendering, but on my 2 core CPU,
freeing one CPU constantly doing memcpy(), allows it to draw more frames.
Without DMA:
415 frames in 5.0 seconds = 82.973 FPS
356 frames in 5.0 seconds = 71.167 FPS
with DMA:
717 frames in 5.0 seconds = 143.343 FPS
720 frames in 5.0 seconds = 143.993 FPS
Regarding the implementation:
The driver uses primary DMA to send drawing engine commands, and secondary DMA to send the pixels to an ILOAD command.
You can directly program the ILOAD command, and use Primary DMA to send the pixels, but in this case, you can't use the softrap interrupt to wait for the DMA completion.
The pixels are copied from the gem framebuffer to the DMA buffer, but as system memory is much faster than VRAM, it has a negligible impact.
DMA buffer size:
On my test machine (x86_64), I can't allocate more than 4MB of DMA coherent memory, and the framebuffer is 5MB.
So the driver has to cut it into small chunks when the full framebuffer is refreshed.
My implementation tries to allocate 4MB, and then smaller allocation until it succeeds.
The DMA GEM framework tries to allocate the whole framebuffer at once, so it fails for resolutions higher than 1024x768x32.
So I stick with SHMEM, and that extra memcpy.
Pixel width:
I tested this in 16 bits per pixels RGB565 and 32 bits per pixels (XRGB8888).
I didn't find a userspace able to use 24 bits (RGB888), Xorg uses XRGB8888 when specifying
"DefaultDepth" to 24.
I think the added complexity is low, as it only adds ~400 lines, less than 10% of the whole mgag200 driver (~5000 lines).
drivers/gpu/drm/mgag200/Makefile | 3 +-
drivers/gpu/drm/mgag200/mgag200_dma.c | 237 ++++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/mgag200/mgag200_drv.c | 40 +++++++
drivers/gpu/drm/mgag200/mgag200_drv.h | 29 +++++
drivers/gpu/drm/mgag200/mgag200_g200.c | 4 +
drivers/gpu/drm/mgag200/mgag200_g200eh.c | 4 +
drivers/gpu/drm/mgag200/mgag200_g200eh3.c | 4 +
drivers/gpu/drm/mgag200/mgag200_g200er.c | 4 +
drivers/gpu/drm/mgag200/mgag200_g200ev.c | 4 +
drivers/gpu/drm/mgag200/mgag200_g200ew3.c | 4 +
drivers/gpu/drm/mgag200/mgag200_g200se.c | 4 +
drivers/gpu/drm/mgag200/mgag200_g200wb.c | 4 +
drivers/gpu/drm/mgag200/mgag200_mode.c | 84 ++++----------
drivers/gpu/drm/mgag200/mgag200_reg.h | 30 ++++-
14 files changed, 393 insertions(+), 62 deletions(-)
v2:
- Better explain scale and offset simplifications.
- Move all damage handling to mgag200_dma.c
- Move all dma-related variables to struct mga_dma.
- Remove the fallback, DMA should always work.
- Fix the warning reported by the kernel test bot.
Signed-off-by: Jocelyn Falempe <jfalempe@xxxxxxxxxx>
