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, I can allocate only 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.
If it fails to allocate, DMA will be disabled. That's probably not perfect, but at least it's simple.
It's also possible to do some kind of scatter gather DMA, by sending multiple ILOAD/SECDMA, but that increases the complexity a bit.
Adding a module parameter to disable DMA:
I think before merging this work, I will add a module parameter to disable DMA, so that if
something goes wrong it's easy to turn it off.
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.
Big endian:
The DMA can be configured to handle the be->le conversion, but I can't test it, so it's not done yet.
As I don't know if there are still big endian systems with mgag200, maybe disabling DMA for big endian is the safest option ?
I think the complexity is low, as it only adds ~350 lines, less than 10% of the whole mgag200 driver (~5000 lines).
drivers/gpu/drm/mgag200/Makefile | 3 +-
drivers/gpu/drm/mgag200/mgag200_dma.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/mgag200/mgag200_drv.c | 43 +++++++++++++++++++++++++++
drivers/gpu/drm/mgag200/mgag200_drv.h | 28 ++++++++++++++++++
drivers/gpu/drm/mgag200/mgag200_mode.c | 200 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------
drivers/gpu/drm/mgag200/mgag200_reg.h | 30 ++++++++++++++++++-
6 files changed, 362 insertions(+), 56 deletions(-)
Signed-off-by: Jocelyn Falempe <jfalempe@xxxxxxxxxx>
base-commit: 457391b0380335d5 (tag: v6.3)
