Writing a 2D acceleration driver.

[fifteenhex]

Hi,

Background:

• I have a DRM/KMS kernel driver that works with the DRM/KMS system
• I have a partial in-kernel driver for the associated 2D hardware (rect fill, lines, blits with blending etc)
• 2d kernel driver is visible via a char device + ioctls
• I have a shim library that will send jobs into the kernel
• Based on the GLES2 2D I hacked up a skeleton of a directfb2 driver to sit on top of the shim library - https://github.com/linux-chenxing/directfb2-ge (this has a diagram of what I'm trying to do too..)

The last piece of the puzzle is to get a reference to the buffer(s) that DirectFB2 wants to be worked on. I'm guessing with the DRM/KMS system these would be buffers allocated on the kernel side already and I should be able to get a handle that I can turn back into an address inside the kernel and then let the 2D hardware do it's thing.

Any hints would be really helpful. I'm trying to grok what DirectFB2 is doing but there are a lot of layers.

[caramelli]

Hi Daniel,

I really appreciate seeing what you're trying to achieve: DirectFB was designed to use hardware acceleration via a 2D blitter and a dedicated repository for your platform, as you do, it's exactly the right thing to do.

Yes, https://github.com/directfb2/DirectFB2-gles2 is probably a good example: as you have seen, it uses state->src.handle (texture), handle which comes directly in this case from the https://github.com/directfb2/DirectFB2-eglrpi system module.
Indeed, in the file https://github.com/directfb2/DirectFB2-eglrpi/blob/master/egl_surface_pool.c, we have: lock->handle = (void*)(long) alloc->tex;

My understanding is that the drmkms system module provides similar mechanism with drmPrimeHandleToFD() and the offset field: the drmkms-use-prime-fd parameter must be set in the directfbrc configuration file to use it (or on the command line with --dfb:drmkms-use-prime-fd). A gfxdriver illustrating its use is available here https://github.com/directfb2/DirectFB2/blob/directfb-1.8/gfxdrivers/vsp1/vsp1_blt.c

I never had the opportunity to have a hardware to test this parameter drmkms-use-prime-fd.

Hope you manage to get your DirectFB2 hardware acceleration module working!

[fifteenhex]

Hi,

My understanding is that the drmkms system module provides similar mechanism with drmPrimeHandleToFD() and the offset field: the drmkms-use-prime-fd parameter must be set in the directfbrc configuration file to use it (or on the command line with --dfb:drmkms-use-prime-fd). A gfxdriver illustrating its use is available here https://github.com/directfb2/DirectFB2/blob/directfb-1.8/gfxdrivers/vsp1/vsp1_blt.c

This does seem to be the way to go. There are some existing examples for v4l2 of creating a DRM buffer, getting the PRIME fd and then passing that somewhere else to be drawn into. Then on the kernel side the PRIME fd can get turned into a dmabuf.

It looks like I need to expose the headers from the drmkms system module to make sure it's configured correctly in the driver module. I'll send a PR for that..

Hope you manage to get your DirectFB2 hardware acceleration module working!

I hope so too. No one seems to care about 2D stuff anymore but there are lots of cheap Linux capable chips that only have 2D hardware. I think if I can get this working we can use it as an example for wiring up other stuff.

[fifteenhex]

Little progress update. I now have my dfb2 driver sending rect fills to the kernel part of the 2d driver and I'm getting the rects drawn on the surface. A long way off of a full driver but certainly shows it's possible.

[caramelli]

Great!

df_dok --fill-rect can give you an idea of ​​performance gain comparing to results without hardware acceleration.

[fifteenhex]

Great!

df_dok --fill-rect can give you an idea of ​​performance gain comparing to results without hardware acceleration.

df_dok right now shows that rect fills are actually 3 times slower with the HW (it's not running at max frequency though..). I implemented the most basic blitting too and that's slower.

But: Running chocolate-doom on SDL2 went from a bit choppy with >80% cpu usage to very fluid with only 40% cpu usage. I think once I can work out how to get blending etc to work on the hardware it'll be a little bit better. HW seems to be only used for fullscreen blits at the moment.