Correct, but since PyraOS was/is still heavily leaning on fbdev I prioritized getting the fbdev rotated for the GamesCon demo. Part of the reason is that xorg-video-omap was slower than xorg-video-modesetting, which itself was slower than xorg-video-fbturbo. These differences are afaik unrelated to DRM vs fbdev and purely depend on the software rendering implementation, with fbturbo taking explicit care to keep the high latency of framebuffer access in mind and e.g. use large Neon reads whenever it has to read from the framebuffer.

From DRM's perspective, fbdev is simply one framebuffer object which is retained by the kernel and which drm_kms_helper puts on screen with some default modesetting whenever there's no DRM master. There are also some special considerations needed for allocating the memory for that framebuffer because it has to be mapped in kernelspace to support legacy operations such as write() into /dev/fb0, whereas DRM buffers are normally only mapped into userspace.

So, what my patches do, successively:

patch/tiler-memtype  -- fixes slowness #1 (I should try to upstream this one)

patch/tiler-fast -- fixes slowness #2 (needs polishing).
patch/tiler-buf-fbdev -- allocates the legacy fbdev framebuffer in TILER memory in an incredibly hacky way.

patch/tiler-fbdev -- hacks a rotation option into the modesetting done by drm_kms_helper

patch/tiler-fast is all that's required to fix the TILER performance problems for users of libdrm_omap (such as xorg-video-omap). The reason libdrm_omap is needed is because special calls are needed to allocate a buffer in TILER memory. Once allocated, displaying it with rotation is standard drm stuff (the "rotation" property of a layer).

This also means that after patch/tiler-buf-fbdev you can use standard drm calls to display the legacy fbdev framebuffer with rotation. That's what was going on in this video: https://www.youtube.com/watch?v=CFjLA9QX_hs  The fbdev applications themselves are completely unaware of any of this.

patch/tiler-fbdev finally moves this setting to kernelspace.

patch/tiler-buf-dumb was an experiment to force the generic "dumb buffer" api to allocate all buffers in TILER memory. This is highly excessive and unnecessary, and might risk running out of TILER memory. It also completely broke SGX and would have broken e.g. etnaviv if we had it working, since I discovered that export of TILER-allocated buffers via the dma-buf API is basically not implemented yet (but does nonsense instead of returning an error).

Fixing dma-buf export is probably one of my highest priorities once I get to focus on graphics again. If I fix vmap of buffers as part of this, then that should also allow for a less hacky version of patch/tiler-buf-fbdev.

Matthijs