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.vogelhu...@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

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to