* [PATCH] drm/msm/dpu: Add UBWC support for RGB8888 formats
@ 2019-11-06 23:25 ` Fritz Koenig
0 siblings, 0 replies; 10+ messages in thread
From: Fritz Koenig @ 2019-11-06 23:25 UTC (permalink / raw)
To: Rob Clark, Sean Paul; +Cc: linux-arm-msm, dri-devel, freedreno, Fritz Koenig
Hardware only natively supports BGR8888 UBWC.
UBWC support for RGB8888 can be had by pretending
that the buffer is BGR.
Signed-off-by: Fritz Koenig <frkoenig@google.com>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 18 ++++++++++++++++++
.../drm/msm/disp/dpu1/dpu_hw_catalog_format.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index 24ab6249083a..528632690f1e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -489,12 +489,28 @@ static const struct dpu_format dpu_format_map_ubwc[] = {
true, 4, DPU_FORMAT_FLAG_COMPRESSED,
DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+ /* ARGB8888 and ABGR8888 purposely have the same color
+ * ordering. The hardware only supports ABGR8888 UBWC
+ * natively.
+ */
+ INTERLEAVED_RGB_FMT_TILED(ARGB8888,
+ COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+ C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
+ true, 4, DPU_FORMAT_FLAG_COMPRESSED,
+ DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+
INTERLEAVED_RGB_FMT_TILED(XBGR8888,
COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
false, 4, DPU_FORMAT_FLAG_COMPRESSED,
DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+ INTERLEAVED_RGB_FMT_TILED(XRGB8888,
+ COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+ C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
+ false, 4, DPU_FORMAT_FLAG_COMPRESSED,
+ DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+
INTERLEAVED_RGB_FMT_TILED(ABGR2101010,
COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
@@ -550,7 +566,9 @@ static int _dpu_format_get_media_color_ubwc(const struct dpu_format *fmt)
{
static const struct dpu_media_color_map dpu_media_ubwc_map[] = {
{DRM_FORMAT_ABGR8888, COLOR_FMT_RGBA8888_UBWC},
+ {DRM_FORMAT_ARGB8888, COLOR_FMT_RGBA8888_UBWC},
{DRM_FORMAT_XBGR8888, COLOR_FMT_RGBA8888_UBWC},
+ {DRM_FORMAT_XRGB8888, COLOR_FMT_RGBA8888_UBWC},
{DRM_FORMAT_ABGR2101010, COLOR_FMT_RGBA1010102_UBWC},
{DRM_FORMAT_XBGR2101010, COLOR_FMT_RGBA1010102_UBWC},
{DRM_FORMAT_BGR565, COLOR_FMT_RGB565_UBWC},
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
index bb6112c949ae..fbcb3c4bbfee 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
@@ -6,7 +6,9 @@
static const uint32_t qcom_compressed_supported_formats[] = {
DRM_FORMAT_ABGR8888,
+ DRM_FORMAT_ARGB8888,
DRM_FORMAT_XBGR8888,
+ DRM_FORMAT_XRGB8888,
DRM_FORMAT_BGR565,
};
--
2.24.0.432.g9d3f5f5b63-goog
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH] drm/msm/dpu: Add UBWC support for RGB8888 formats
@ 2019-11-06 23:25 ` Fritz Koenig
0 siblings, 0 replies; 10+ messages in thread
From: Fritz Koenig @ 2019-11-06 23:25 UTC (permalink / raw)
To: Rob Clark, Sean Paul
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Fritz Koenig,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Hardware only natively supports BGR8888 UBWC.
UBWC support for RGB8888 can be had by pretending
that the buffer is BGR.
Signed-off-by: Fritz Koenig <frkoenig@google.com>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 18 ++++++++++++++++++
.../drm/msm/disp/dpu1/dpu_hw_catalog_format.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index 24ab6249083a..528632690f1e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -489,12 +489,28 @@ static const struct dpu_format dpu_format_map_ubwc[] = {
true, 4, DPU_FORMAT_FLAG_COMPRESSED,
DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+ /* ARGB8888 and ABGR8888 purposely have the same color
+ * ordering. The hardware only supports ABGR8888 UBWC
+ * natively.
+ */
+ INTERLEAVED_RGB_FMT_TILED(ARGB8888,
+ COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+ C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
+ true, 4, DPU_FORMAT_FLAG_COMPRESSED,
+ DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+
INTERLEAVED_RGB_FMT_TILED(XBGR8888,
COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
false, 4, DPU_FORMAT_FLAG_COMPRESSED,
DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+ INTERLEAVED_RGB_FMT_TILED(XRGB8888,
+ COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+ C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
+ false, 4, DPU_FORMAT_FLAG_COMPRESSED,
+ DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+
INTERLEAVED_RGB_FMT_TILED(ABGR2101010,
COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
@@ -550,7 +566,9 @@ static int _dpu_format_get_media_color_ubwc(const struct dpu_format *fmt)
{
static const struct dpu_media_color_map dpu_media_ubwc_map[] = {
{DRM_FORMAT_ABGR8888, COLOR_FMT_RGBA8888_UBWC},
+ {DRM_FORMAT_ARGB8888, COLOR_FMT_RGBA8888_UBWC},
{DRM_FORMAT_XBGR8888, COLOR_FMT_RGBA8888_UBWC},
+ {DRM_FORMAT_XRGB8888, COLOR_FMT_RGBA8888_UBWC},
{DRM_FORMAT_ABGR2101010, COLOR_FMT_RGBA1010102_UBWC},
{DRM_FORMAT_XBGR2101010, COLOR_FMT_RGBA1010102_UBWC},
{DRM_FORMAT_BGR565, COLOR_FMT_RGB565_UBWC},
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
index bb6112c949ae..fbcb3c4bbfee 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
@@ -6,7 +6,9 @@
static const uint32_t qcom_compressed_supported_formats[] = {
DRM_FORMAT_ABGR8888,
+ DRM_FORMAT_ARGB8888,
DRM_FORMAT_XBGR8888,
+ DRM_FORMAT_XRGB8888,
DRM_FORMAT_BGR565,
};
--
2.24.0.432.g9d3f5f5b63-goog
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH] drm/msm/dpu: Add UBWC support for RGB8888 formats
@ 2019-11-06 23:25 ` Fritz Koenig
0 siblings, 0 replies; 10+ messages in thread
From: Fritz Koenig @ 2019-11-06 23:25 UTC (permalink / raw)
To: Rob Clark, Sean Paul; +Cc: linux-arm-msm, Fritz Koenig, freedreno, dri-devel
Hardware only natively supports BGR8888 UBWC.
UBWC support for RGB8888 can be had by pretending
that the buffer is BGR.
Signed-off-by: Fritz Koenig <frkoenig@google.com>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 18 ++++++++++++++++++
.../drm/msm/disp/dpu1/dpu_hw_catalog_format.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index 24ab6249083a..528632690f1e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -489,12 +489,28 @@ static const struct dpu_format dpu_format_map_ubwc[] = {
true, 4, DPU_FORMAT_FLAG_COMPRESSED,
DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+ /* ARGB8888 and ABGR8888 purposely have the same color
+ * ordering. The hardware only supports ABGR8888 UBWC
+ * natively.
+ */
+ INTERLEAVED_RGB_FMT_TILED(ARGB8888,
+ COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+ C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
+ true, 4, DPU_FORMAT_FLAG_COMPRESSED,
+ DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+
INTERLEAVED_RGB_FMT_TILED(XBGR8888,
COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
false, 4, DPU_FORMAT_FLAG_COMPRESSED,
DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+ INTERLEAVED_RGB_FMT_TILED(XRGB8888,
+ COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+ C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
+ false, 4, DPU_FORMAT_FLAG_COMPRESSED,
+ DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+
INTERLEAVED_RGB_FMT_TILED(ABGR2101010,
COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
@@ -550,7 +566,9 @@ static int _dpu_format_get_media_color_ubwc(const struct dpu_format *fmt)
{
static const struct dpu_media_color_map dpu_media_ubwc_map[] = {
{DRM_FORMAT_ABGR8888, COLOR_FMT_RGBA8888_UBWC},
+ {DRM_FORMAT_ARGB8888, COLOR_FMT_RGBA8888_UBWC},
{DRM_FORMAT_XBGR8888, COLOR_FMT_RGBA8888_UBWC},
+ {DRM_FORMAT_XRGB8888, COLOR_FMT_RGBA8888_UBWC},
{DRM_FORMAT_ABGR2101010, COLOR_FMT_RGBA1010102_UBWC},
{DRM_FORMAT_XBGR2101010, COLOR_FMT_RGBA1010102_UBWC},
{DRM_FORMAT_BGR565, COLOR_FMT_RGB565_UBWC},
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
index bb6112c949ae..fbcb3c4bbfee 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
@@ -6,7 +6,9 @@
static const uint32_t qcom_compressed_supported_formats[] = {
DRM_FORMAT_ABGR8888,
+ DRM_FORMAT_ARGB8888,
DRM_FORMAT_XBGR8888,
+ DRM_FORMAT_XRGB8888,
DRM_FORMAT_BGR565,
};
--
2.24.0.432.g9d3f5f5b63-goog
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/msm/dpu: Add UBWC support for RGB8888 formats
2019-11-06 23:25 ` Fritz Koenig
@ 2019-11-07 16:29 ` Rob Clark
-1 siblings, 0 replies; 10+ messages in thread
From: Rob Clark @ 2019-11-07 16:29 UTC (permalink / raw)
To: Fritz Koenig; +Cc: Sean Paul, linux-arm-msm, dri-devel, freedreno
On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig <frkoenig@google.com> wrote:
>
> Hardware only natively supports BGR8888 UBWC.
> UBWC support for RGB8888 can be had by pretending
> that the buffer is BGR.
Just to expand, this aligns with how we handle RGB component order in
mesa for tiled or tiled+ubwc. If uncompressed to linear the component
order is RGB, but in tiled or tiled+ubwc, the component order is
always the hw "native" order (BGR) regardless of what the outside
world thinks. But that detail kinda doesn't matter, it's not like
generic code is going to understand the tiled or tiled+ubwc format in
the first place.. and code that does understand it, knows enough to
know that tiled/tiled+ubwc is always in the native component order.
> Signed-off-by: Fritz Koenig <frkoenig@google.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 18 ++++++++++++++++++
> .../drm/msm/disp/dpu1/dpu_hw_catalog_format.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> index 24ab6249083a..528632690f1e 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> @@ -489,12 +489,28 @@ static const struct dpu_format dpu_format_map_ubwc[] = {
> true, 4, DPU_FORMAT_FLAG_COMPRESSED,
> DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
>
> + /* ARGB8888 and ABGR8888 purposely have the same color
> + * ordering. The hardware only supports ABGR8888 UBWC
> + * natively.
> + */
> + INTERLEAVED_RGB_FMT_TILED(ARGB8888,
> + COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> + C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
> + true, 4, DPU_FORMAT_FLAG_COMPRESSED,
> + DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
> +
> INTERLEAVED_RGB_FMT_TILED(XBGR8888,
> COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
> false, 4, DPU_FORMAT_FLAG_COMPRESSED,
> DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
>
> + INTERLEAVED_RGB_FMT_TILED(XRGB8888,
> + COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> + C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
> + false, 4, DPU_FORMAT_FLAG_COMPRESSED,
> + DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
> +
> INTERLEAVED_RGB_FMT_TILED(ABGR2101010,
> COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
> @@ -550,7 +566,9 @@ static int _dpu_format_get_media_color_ubwc(const struct dpu_format *fmt)
> {
> static const struct dpu_media_color_map dpu_media_ubwc_map[] = {
> {DRM_FORMAT_ABGR8888, COLOR_FMT_RGBA8888_UBWC},
> + {DRM_FORMAT_ARGB8888, COLOR_FMT_RGBA8888_UBWC},
> {DRM_FORMAT_XBGR8888, COLOR_FMT_RGBA8888_UBWC},
> + {DRM_FORMAT_XRGB8888, COLOR_FMT_RGBA8888_UBWC},
> {DRM_FORMAT_ABGR2101010, COLOR_FMT_RGBA1010102_UBWC},
> {DRM_FORMAT_XBGR2101010, COLOR_FMT_RGBA1010102_UBWC},
> {DRM_FORMAT_BGR565, COLOR_FMT_RGB565_UBWC},
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
> index bb6112c949ae..fbcb3c4bbfee 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
> @@ -6,7 +6,9 @@
>
> static const uint32_t qcom_compressed_supported_formats[] = {
> DRM_FORMAT_ABGR8888,
> + DRM_FORMAT_ARGB8888,
> DRM_FORMAT_XBGR8888,
> + DRM_FORMAT_XRGB8888,
> DRM_FORMAT_BGR565,
> };
>
> --
> 2.24.0.432.g9d3f5f5b63-goog
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/msm/dpu: Add UBWC support for RGB8888 formats
@ 2019-11-07 16:29 ` Rob Clark
0 siblings, 0 replies; 10+ messages in thread
From: Rob Clark @ 2019-11-07 16:29 UTC (permalink / raw)
To: Fritz Koenig; +Cc: linux-arm-msm, freedreno, Sean Paul, dri-devel
On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig <frkoenig@google.com> wrote:
>
> Hardware only natively supports BGR8888 UBWC.
> UBWC support for RGB8888 can be had by pretending
> that the buffer is BGR.
Just to expand, this aligns with how we handle RGB component order in
mesa for tiled or tiled+ubwc. If uncompressed to linear the component
order is RGB, but in tiled or tiled+ubwc, the component order is
always the hw "native" order (BGR) regardless of what the outside
world thinks. But that detail kinda doesn't matter, it's not like
generic code is going to understand the tiled or tiled+ubwc format in
the first place.. and code that does understand it, knows enough to
know that tiled/tiled+ubwc is always in the native component order.
> Signed-off-by: Fritz Koenig <frkoenig@google.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 18 ++++++++++++++++++
> .../drm/msm/disp/dpu1/dpu_hw_catalog_format.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> index 24ab6249083a..528632690f1e 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
> @@ -489,12 +489,28 @@ static const struct dpu_format dpu_format_map_ubwc[] = {
> true, 4, DPU_FORMAT_FLAG_COMPRESSED,
> DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
>
> + /* ARGB8888 and ABGR8888 purposely have the same color
> + * ordering. The hardware only supports ABGR8888 UBWC
> + * natively.
> + */
> + INTERLEAVED_RGB_FMT_TILED(ARGB8888,
> + COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> + C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
> + true, 4, DPU_FORMAT_FLAG_COMPRESSED,
> + DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
> +
> INTERLEAVED_RGB_FMT_TILED(XBGR8888,
> COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
> false, 4, DPU_FORMAT_FLAG_COMPRESSED,
> DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
>
> + INTERLEAVED_RGB_FMT_TILED(XRGB8888,
> + COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> + C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
> + false, 4, DPU_FORMAT_FLAG_COMPRESSED,
> + DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
> +
> INTERLEAVED_RGB_FMT_TILED(ABGR2101010,
> COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
> C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
> @@ -550,7 +566,9 @@ static int _dpu_format_get_media_color_ubwc(const struct dpu_format *fmt)
> {
> static const struct dpu_media_color_map dpu_media_ubwc_map[] = {
> {DRM_FORMAT_ABGR8888, COLOR_FMT_RGBA8888_UBWC},
> + {DRM_FORMAT_ARGB8888, COLOR_FMT_RGBA8888_UBWC},
> {DRM_FORMAT_XBGR8888, COLOR_FMT_RGBA8888_UBWC},
> + {DRM_FORMAT_XRGB8888, COLOR_FMT_RGBA8888_UBWC},
> {DRM_FORMAT_ABGR2101010, COLOR_FMT_RGBA1010102_UBWC},
> {DRM_FORMAT_XBGR2101010, COLOR_FMT_RGBA1010102_UBWC},
> {DRM_FORMAT_BGR565, COLOR_FMT_RGB565_UBWC},
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
> index bb6112c949ae..fbcb3c4bbfee 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
> @@ -6,7 +6,9 @@
>
> static const uint32_t qcom_compressed_supported_formats[] = {
> DRM_FORMAT_ABGR8888,
> + DRM_FORMAT_ARGB8888,
> DRM_FORMAT_XBGR8888,
> + DRM_FORMAT_XRGB8888,
> DRM_FORMAT_BGR565,
> };
>
> --
> 2.24.0.432.g9d3f5f5b63-goog
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/msm/dpu: Add UBWC support for RGB8888 formats
2019-11-07 16:29 ` Rob Clark
@ 2019-11-07 17:30 ` Eric Anholt
-1 siblings, 0 replies; 10+ messages in thread
From: Eric Anholt @ 2019-11-07 17:30 UTC (permalink / raw)
To: Rob Clark, Fritz Koenig; +Cc: linux-arm-msm, freedreno, Sean Paul, dri-devel
[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]
Rob Clark <robdclark@gmail.com> writes:
> On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig <frkoenig@google.com> wrote:
>>
>> Hardware only natively supports BGR8888 UBWC.
>> UBWC support for RGB8888 can be had by pretending
>> that the buffer is BGR.
>
> Just to expand, this aligns with how we handle RGB component order in
> mesa for tiled or tiled+ubwc. If uncompressed to linear the component
> order is RGB, but in tiled or tiled+ubwc, the component order is
> always the hw "native" order (BGR) regardless of what the outside
> world thinks. But that detail kinda doesn't matter, it's not like
> generic code is going to understand the tiled or tiled+ubwc format in
> the first place.. and code that does understand it, knows enough to
> know that tiled/tiled+ubwc is always in the native component order.
>
>> Signed-off-by: Fritz Koenig <frkoenig@google.com>
>
> Reviewed-by: Rob Clark <robdclark@gmail.com>
Seems like a reasonable workaround to me, and permissible by our fourcc
modifier rules ("you just have to have one way to address the pixels
given a fourcc and a modifier").
Reviewed-by: Eric Anholt <eric@anholt.net>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/msm/dpu: Add UBWC support for RGB8888 formats
@ 2019-11-07 17:30 ` Eric Anholt
0 siblings, 0 replies; 10+ messages in thread
From: Eric Anholt @ 2019-11-07 17:30 UTC (permalink / raw)
To: Rob Clark, Fritz Koenig; +Cc: Sean Paul, linux-arm-msm, freedreno, dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 1134 bytes --]
Rob Clark <robdclark@gmail.com> writes:
> On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig <frkoenig@google.com> wrote:
>>
>> Hardware only natively supports BGR8888 UBWC.
>> UBWC support for RGB8888 can be had by pretending
>> that the buffer is BGR.
>
> Just to expand, this aligns with how we handle RGB component order in
> mesa for tiled or tiled+ubwc. If uncompressed to linear the component
> order is RGB, but in tiled or tiled+ubwc, the component order is
> always the hw "native" order (BGR) regardless of what the outside
> world thinks. But that detail kinda doesn't matter, it's not like
> generic code is going to understand the tiled or tiled+ubwc format in
> the first place.. and code that does understand it, knows enough to
> know that tiled/tiled+ubwc is always in the native component order.
>
>> Signed-off-by: Fritz Koenig <frkoenig@google.com>
>
> Reviewed-by: Rob Clark <robdclark@gmail.com>
Seems like a reasonable workaround to me, and permissible by our fourcc
modifier rules ("you just have to have one way to address the pixels
given a fourcc and a modifier").
Reviewed-by: Eric Anholt <eric@anholt.net>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/msm/dpu: Add UBWC support for RGB8888 formats
@ 2019-11-07 17:43 ` Daniel Vetter
0 siblings, 0 replies; 10+ messages in thread
From: Daniel Vetter @ 2019-11-07 17:43 UTC (permalink / raw)
To: Eric Anholt
Cc: Rob Clark, Fritz Koenig, Sean Paul, linux-arm-msm, freedreno, dri-devel
On Thu, Nov 07, 2019 at 09:30:50AM -0800, Eric Anholt wrote:
> Rob Clark <robdclark@gmail.com> writes:
> > On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig <frkoenig@google.com> wrote:
> >>
> >> Hardware only natively supports BGR8888 UBWC.
> >> UBWC support for RGB8888 can be had by pretending
> >> that the buffer is BGR.
> >
> > Just to expand, this aligns with how we handle RGB component order in
> > mesa for tiled or tiled+ubwc. If uncompressed to linear the component
> > order is RGB, but in tiled or tiled+ubwc, the component order is
> > always the hw "native" order (BGR) regardless of what the outside
> > world thinks. But that detail kinda doesn't matter, it's not like
> > generic code is going to understand the tiled or tiled+ubwc format in
> > the first place.. and code that does understand it, knows enough to
> > know that tiled/tiled+ubwc is always in the native component order.
> >
> >> Signed-off-by: Fritz Koenig <frkoenig@google.com>
> >
> > Reviewed-by: Rob Clark <robdclark@gmail.com>
>
> Seems like a reasonable workaround to me, and permissible by our fourcc
> modifier rules ("you just have to have one way to address the pixels
> given a fourcc and a modifier").
Yeah we have some other aliasing going on already I think. And since for
interopt you just need to pick matching (fourcc, modifier) pairs worst
case that means drivers need to add a bunch of dummies/duplicates. Like we
do here.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cheers, Daniel
>
> Reviewed-by: Eric Anholt <eric@anholt.net>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/msm/dpu: Add UBWC support for RGB8888 formats
@ 2019-11-07 17:43 ` Daniel Vetter
0 siblings, 0 replies; 10+ messages in thread
From: Daniel Vetter @ 2019-11-07 17:43 UTC (permalink / raw)
To: Eric Anholt
Cc: Sean Paul, Fritz Koenig, linux-arm-msm, dri-devel, Rob Clark, freedreno
On Thu, Nov 07, 2019 at 09:30:50AM -0800, Eric Anholt wrote:
> Rob Clark <robdclark@gmail.com> writes:
> > On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig <frkoenig@google.com> wrote:
> >>
> >> Hardware only natively supports BGR8888 UBWC.
> >> UBWC support for RGB8888 can be had by pretending
> >> that the buffer is BGR.
> >
> > Just to expand, this aligns with how we handle RGB component order in
> > mesa for tiled or tiled+ubwc. If uncompressed to linear the component
> > order is RGB, but in tiled or tiled+ubwc, the component order is
> > always the hw "native" order (BGR) regardless of what the outside
> > world thinks. But that detail kinda doesn't matter, it's not like
> > generic code is going to understand the tiled or tiled+ubwc format in
> > the first place.. and code that does understand it, knows enough to
> > know that tiled/tiled+ubwc is always in the native component order.
> >
> >> Signed-off-by: Fritz Koenig <frkoenig@google.com>
> >
> > Reviewed-by: Rob Clark <robdclark@gmail.com>
>
> Seems like a reasonable workaround to me, and permissible by our fourcc
> modifier rules ("you just have to have one way to address the pixels
> given a fourcc and a modifier").
Yeah we have some other aliasing going on already I think. And since for
interopt you just need to pick matching (fourcc, modifier) pairs worst
case that means drivers need to add a bunch of dummies/duplicates. Like we
do here.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cheers, Daniel
>
> Reviewed-by: Eric Anholt <eric@anholt.net>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/msm/dpu: Add UBWC support for RGB8888 formats
@ 2019-11-07 17:43 ` Daniel Vetter
0 siblings, 0 replies; 10+ messages in thread
From: Daniel Vetter @ 2019-11-07 17:43 UTC (permalink / raw)
To: Eric Anholt; +Cc: Sean Paul, Fritz Koenig, linux-arm-msm, dri-devel, freedreno
On Thu, Nov 07, 2019 at 09:30:50AM -0800, Eric Anholt wrote:
> Rob Clark <robdclark@gmail.com> writes:
> > On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig <frkoenig@google.com> wrote:
> >>
> >> Hardware only natively supports BGR8888 UBWC.
> >> UBWC support for RGB8888 can be had by pretending
> >> that the buffer is BGR.
> >
> > Just to expand, this aligns with how we handle RGB component order in
> > mesa for tiled or tiled+ubwc. If uncompressed to linear the component
> > order is RGB, but in tiled or tiled+ubwc, the component order is
> > always the hw "native" order (BGR) regardless of what the outside
> > world thinks. But that detail kinda doesn't matter, it's not like
> > generic code is going to understand the tiled or tiled+ubwc format in
> > the first place.. and code that does understand it, knows enough to
> > know that tiled/tiled+ubwc is always in the native component order.
> >
> >> Signed-off-by: Fritz Koenig <frkoenig@google.com>
> >
> > Reviewed-by: Rob Clark <robdclark@gmail.com>
>
> Seems like a reasonable workaround to me, and permissible by our fourcc
> modifier rules ("you just have to have one way to address the pixels
> given a fourcc and a modifier").
Yeah we have some other aliasing going on already I think. And since for
interopt you just need to pick matching (fourcc, modifier) pairs worst
case that means drivers need to add a bunch of dummies/duplicates. Like we
do here.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cheers, Daniel
>
> Reviewed-by: Eric Anholt <eric@anholt.net>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-11-07 17:43 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-06 23:25 [PATCH] drm/msm/dpu: Add UBWC support for RGB8888 formats Fritz Koenig
2019-11-06 23:25 ` Fritz Koenig
2019-11-06 23:25 ` Fritz Koenig
2019-11-07 16:29 ` Rob Clark
2019-11-07 16:29 ` Rob Clark
2019-11-07 17:30 ` Eric Anholt
2019-11-07 17:30 ` Eric Anholt
2019-11-07 17:43 ` Daniel Vetter
2019-11-07 17:43 ` Daniel Vetter
2019-11-07 17:43 ` Daniel Vetter
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.