2 ms·

Have not looked deeply into the code, but I know it is important to work with the "DRM MODIFIERS" in order to work with a native (efficient) framebuffer format

Have not looked deeply into the code, but I know it is important to work with the "DRM MODIFIERS" in order to work with a native (efficient) framebuffer format for the GPU (usually hardware custom tiling). The hard part is to "blit" from a well-known framebuffer format to that native framebuffer format. If I recall properly, on AMD GPU, you would use a 'DMA engine' which will perform the conversion (it may be obsolete and you may have to use the full GPU pipeline with texture image formats). I dunno how much hardware abstraction there is in libdrm (and this is my own dawn fault as I should have dug deeper a long time ago in libdrm interface), do we have to "know" how to deal with the native format, or is there some (expensive) hardware abstraction to deal with this conversion?

dividuum 2y ago
> I dunno how much hardware abstraction there is in libdrm (and this is my own dawn fault as I should have dug deeper a long time ago in libdrm interface), do we have to "know" how to deal with the native format, or is there some (expensive) hardware abstraction to deal with this conversion? From my experience there is no magic at all. You have to wire everything up yourself. Different cards expose different properties and limitations, albeit all through the same API. But you have to handle the differences yourself. For example the Pi's primary VC4 graphics card has 48 planes to place framebuffers onto the screen, while the minimal implementation their 7" display uses only has a single plane. Your code has to know how to handle this. DRM doesn't abstract that away.
- sylware 2y ago
  This is what I thought. Now I wonder what is the added value of libdrm on top of the "DRM IOCTLs". The only thing I could think of is "sharing" the GPU IO memory buffers among all GPU applications. And even that... Well, I really need to have a deeper look one day. Ah!

dividuum 2y ago

> I dunno how much hardware abstraction there is in libdrm (and this is my own dawn fault as I should have dug deeper a long time ago in libdrm interface), do we have to "know" how to deal with the native format, or is there some (expensive) hardware abstraction to deal with this conversion? From my experience there is no magic at all. You have to wire everything up yourself. Different cards expose different properties and limitations, albeit all through the same API. But you have to handle the differences yourself. For example the Pi's primary VC4 graphics card has 48 planes to place framebuffers onto the screen, while the minimal implementation their 7" display uses only has a single plane. Your code has to know how to handle this. DRM doesn't abstract that away.

sylware 2y ago
This is what I thought. Now I wonder what is the added value of libdrm on top of the "DRM IOCTLs". The only thing I could think of is "sharing" the GPU IO memory buffers among all GPU applications. And even that... Well, I really need to have a deeper look one day. Ah!