[Mesa-dev] 10bit output via KMS

[Volker Vogelhuber]

Hi Emil,

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.
I wonder if it is possible to have drmModeAddFB2 to handle
'X', 'R', '3', '0' at all. So is this supported in any way?
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:

---
  include/GL/internal/dri_interface.h      | 1 +
  src/mesa/drivers/dri/i915/intel_screen.c | 3 +++
  2 files changed, 4 insertions(+)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 86efd1b..8a92823 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1202,6 +1202,7 @@ struct __DRIdri2ExtensionRec {
  #define __DRI_IMAGE_FOURCC_ABGR8888    0x34324241
  #define __DRI_IMAGE_FOURCC_XBGR8888    0x34324258
  #define __DRI_IMAGE_FOURCC_SARGB8888    0x83324258
+#define __DRI_IMAGE_FOURCC_XRGB2101010  0x30335258
  #define __DRI_IMAGE_FOURCC_YUV410    0x39565559
  #define __DRI_IMAGE_FOURCC_YUV411    0x31315559
  #define __DRI_IMAGE_FOURCC_YUV420    0x32315559
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
b/src/mesa/drivers/dri/i915/intel_screen.c
index 7e17e95..b25f063 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -194,6 +194,9 @@ static struct intel_image_format 
intel_image_formats[] = {
     { __DRI_IMAGE_FOURCC_XRGB8888, __DRI_IMAGE_COMPONENTS_RGB, 1,
       { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB8888, 4 }, } },

+   { __DRI_IMAGE_FOURCC_XRGB2101010, __DRI_IMAGE_COMPONENTS_RGB, 1,
+     { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB2101010, 4 }, } },
+
     { __DRI_IMAGE_FOURCC_YUV410, __DRI_IMAGE_COMPONENTS_Y_U_V, 3,
       { { 0, 0, 0, __DRI_IMAGE_FORMAT_R8, 1 },
         { 1, 2, 2, __DRI_IMAGE_FORMAT_R8, 1 },
-- 


BTW. Maybe I should mention what hardware and software I'm using:

Intel Apollo Lake with Kernel 4.9.4 and Mesa 17.1.0.


On 24.07.2017 15:43, Emil Velikov wrote:
> [dropping dri-devel, adding mesa-dev]  > > Hi Volker, > > Thanks for giving this a stab. > > Mesa it has it's 
own mailing list, take a look at the instruction for > more details [1]. 
 > > On 24 July 2017 at 13:34, Volker Vogelhuber > 
<v.vogelhuber at digitalendoscopy.de> wrote: >> I have implemented a 
display manager application that takes DMB-BUF FDs >> from another 
process and presents them to a connected output display >> using the KMS 
infrastructure (drmModeAddFB, etc.). So far this works >> without 
problems for XRGB8888. Now I wanted to have 10bit color depth >> per 
channel. I created a FBO with 10bit (by patching the mesa and ex- >> 
ported it's texture as a file descriptor via eglExportDMABUFImageMESA, 
 >> see attached patch). >> When I try to import that file descriptor 
via gbm_bo_import it fails >> because in gbm_bo_import, 
createImageFromFds is called which compares >> the format passed to 
gbm_bo_import with intel_image_formats. But this >> array does not seem 
to support 10bit formats. Now I wonder how one >> could output 10bit per 
color channel to an output connector? >> >> >> --- >> 
include/EGL/eglext.h | 4 ++++ >> src/egl/drivers/dri2/egl_dri2.c | 26 
+++++++++++++++++++++++++- >> src/gbm/backends/dri/gbm_dri.c | 3 +++ >> 
src/mesa/drivers/dri/i965/intel_screen.c | 2 ++ >> 4 files changed, 34 
insertions(+), 1 deletion(-) >> > The patch seems to extend(?) existing 
EGL extension which, I believe, > is not allowed. > > It also adds 
implementations in EGL, GBM and the i965 driver. > Ideally these would 
be separate patches, or at least the i965 vs rest. > > Thanks > Emil > > 
[1] https://www.mesa3d.org/submittingpatches.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170724/0bf84eeb/attachment.html>