[Mesa-dev] 10bit output via KMS

[Daniel Stone]

Hi Volker,

On 24 July 2017 at 14:56, Volker Vogelhuber
<v.vogelhuber at digitalendoscopy.de> wrote:
> thanks for the feedback. The patch was not meant to be submitted
> officially. I'm aware that extending official
> EGL extensions is not allowed. It was just for showing what I have
> changed to get 10bit FBOs exported from Mesa, otherwise it would
> probably not possible to have a render buffer with 10bit used in
> the DRM/KMS infrastructure at all. My problem is also not the
> 10bit part in Mesa. So rendering is working and the output buffer
> seems to have 10bits used. My problem is how to present that buffer
> via the  hardware display output connector. And I thought this has more
> to do with libdrm as with Mesa.

Yes, there are two sides to the story.

Firstly, instead of extending the Mesa dmabuf export extension, you
could have this working more portably by extending GBM to be able to
allocate 10bpc surfaces (used as an EGLSurface) or BOs (imported
through EGL_EXT_image_dma_buf_import and used as a renderbuffer
target).

> I wonder if it is possible to have drmModeAddFB2 to handle
> 'X', 'R', '3', '0' at all. So is this supported in any way?

Secondly, you're correct that you would need (theoretically) to extend
drmModeAddFB2, however it already has DRM_FORMAT_XRGB2101010 and
DRM_FORMAT_XBGR2101010 for i965 and above, which covers everything in
the last 10 years. This is the 'XR30' FourCC you mention, so it should
already be there and working in the kernel.

> In this case it may be enough to
> patch intel_image_formats to support __DRI_IMAGE_FORMAT_XRGB2101010
> by adding __DRI_IMAGE_FOURCC_XRGB2101010 like this:

This looks like the right thing to do, yes. That should automatically
give support for dmabuf import. For GBM rendering, this should already
be supported if you're working from git master (what will become
17.2), once you add the new entry to intel_image_formats.

Cheers,
Daniel