2014-03-10 17:35 GMT+01:00 Gwenole Beauchesne <gb.de...@gmail.com>:
> I want to be able to map each individual pane of a planar YUV surface (VA-API)
> as a separate image. Either for customizing the shader code for YUV-to-RGB
> conversion, or for directly exposing a single plane to third-party API like
> OpenCL.
>
> This patch series adds support for mapping a surface plane to red (8-bit) or
> red/green (16-bit) components. This is RFC because I don't actually like the
> new format names, and some definitions also need to be added to libdrm and gbm
> actually. Eventually, I would also like the components to appear as integer.
> So, I was also thinking about providing R8I and GR88I formats. WDYT?
I will opt for a tuple-based approach instead, i.e. 1 to 4 typed components.
fourcc enumerations would look like:
('T',<num_components>,<format>,<bytes_per_component>)
T1F4: (float)
T2F8: (double, double)
T1_1: (unorm) [0..1] -> the existing R8 format
T2_1: (unorm, unorm) [0..1] -> the existing RG88 format
T4I2: (int16_t, int16_t, int16_t, int16_t)
T2U1: (uint8_t)
Reason: I don't want to create yet another extension to express the
same things. dma_bufs are fine with me as is, but just need to be more
expressive for compute like kernels. I will follow-up on dri-devel@.
Regards,
Gwenole.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
