[Mesa-dev] [PATCH 11/11] st/mesa: Fix handling of 8888 SNORM and SRGB formats for big-endian
From: Richard Sandiford rsand...@linux.vnet.ibm.com MESA_FORMAT_x8y8z8w8 puts the x channel in the least significant part of the containing 32-bit integer, which is equivalent to PIPE_FORMAT_xyzw. PIPE_FORMAT_x8y8z8w8 puts the x channel first in memory. This patch fixes up the mesa-gallium mapping accordingly. Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com Signed-off-by: Dave Airlie airl...@redhat.com --- src/mesa/state_tracker/st_format.c | 50 ++ 1 file changed, 35 insertions(+), 15 deletions(-) diff --git a/src/mesa/state_tracker/st_format.c b/src/mesa/state_tracker/st_format.c index 6caedfc..37acab6 100644 --- a/src/mesa/state_tracker/st_format.c +++ b/src/mesa/state_tracker/st_format.c @@ -154,11 +154,13 @@ st_mesa_format_to_pipe_format(struct st_context *st, mesa_format mesaFormat) case MESA_FORMAT_BGR_SRGB8: return PIPE_FORMAT_R8G8B8_SRGB; case MESA_FORMAT_A8B8G8R8_SRGB: - return PIPE_FORMAT_A8B8G8R8_SRGB; - case MESA_FORMAT_B8G8R8A8_SRGB: - return PIPE_FORMAT_B8G8R8A8_SRGB; + return PIPE_FORMAT_ABGR_SRGB; case MESA_FORMAT_R8G8B8A8_SRGB: - return PIPE_FORMAT_R8G8B8A8_SRGB; + return PIPE_FORMAT_RGBA_SRGB; + case MESA_FORMAT_B8G8R8A8_SRGB: + return PIPE_FORMAT_BGRA_SRGB; + case MESA_FORMAT_A8R8G8B8_SRGB: + return PIPE_FORMAT_ARGB_SRGB; case MESA_FORMAT_RGBA_FLOAT32: return PIPE_FORMAT_R32G32B32A32_FLOAT; case MESA_FORMAT_RGBA_FLOAT16: @@ -355,7 +357,9 @@ st_mesa_format_to_pipe_format(struct st_context *st, mesa_format mesaFormat) case MESA_FORMAT_G8R8_SNORM: return PIPE_FORMAT_GR88_SNORM; case MESA_FORMAT_R8G8B8A8_SNORM: - return PIPE_FORMAT_R8G8B8A8_SNORM; + return PIPE_FORMAT_RGBA_SNORM; + case MESA_FORMAT_A8B8G8R8_SNORM: + return PIPE_FORMAT_ABGR_SNORM; case MESA_FORMAT_A_SNORM8: return PIPE_FORMAT_A8_SNORM; @@ -400,9 +404,13 @@ st_mesa_format_to_pipe_format(struct st_context *st, mesa_format mesaFormat) case MESA_FORMAT_B5G5R5X1_UNORM: return PIPE_FORMAT_B5G5R5X1_UNORM; case MESA_FORMAT_R8G8B8X8_SNORM: - return PIPE_FORMAT_R8G8B8X8_SNORM; + return PIPE_FORMAT_RGBX_SNORM; + case MESA_FORMAT_X8B8G8R8_SNORM: + return PIPE_FORMAT_XBGR_SNORM; case MESA_FORMAT_R8G8B8X8_SRGB: - return PIPE_FORMAT_R8G8B8X8_SRGB; + return PIPE_FORMAT_RGBX_SRGB; + case MESA_FORMAT_X8B8G8R8_SRGB: + return PIPE_FORMAT_XBGR_SRGB; case MESA_FORMAT_RGBX_UINT8: return PIPE_FORMAT_R8G8B8X8_UINT; case MESA_FORMAT_RGBX_SINT8: @@ -428,6 +436,8 @@ st_mesa_format_to_pipe_format(struct st_context *st, mesa_format mesaFormat) case MESA_FORMAT_B8G8R8X8_SRGB: return PIPE_FORMAT_B8G8R8X8_SRGB; + case MESA_FORMAT_X8R8G8B8_SRGB: + return PIPE_FORMAT_XRGB_SRGB; /* ETC2 formats are emulated as uncompressed ones. * The destination formats mustn't be changed, because they are also @@ -564,10 +574,14 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_L_SRGB8; case PIPE_FORMAT_R8G8B8_SRGB: return MESA_FORMAT_BGR_SRGB8; - case PIPE_FORMAT_A8B8G8R8_SRGB: + case PIPE_FORMAT_ABGR_SRGB: return MESA_FORMAT_A8B8G8R8_SRGB; - case PIPE_FORMAT_B8G8R8A8_SRGB: + case PIPE_FORMAT_RGBA_SRGB: + return MESA_FORMAT_R8G8B8A8_SRGB; + case PIPE_FORMAT_BGRA_SRGB: return MESA_FORMAT_B8G8R8A8_SRGB; + case PIPE_FORMAT_ARGB_SRGB: + return MESA_FORMAT_A8R8G8B8_SRGB; case PIPE_FORMAT_R32G32B32A32_FLOAT: return MESA_FORMAT_RGBA_FLOAT32; case PIPE_FORMAT_R16G16B16A16_FLOAT: @@ -758,8 +772,10 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_R8G8_SNORM; case PIPE_FORMAT_GR88_SNORM: return MESA_FORMAT_G8R8_SNORM; - case PIPE_FORMAT_R8G8B8A8_SNORM: + case PIPE_FORMAT_RGBA_SNORM: return MESA_FORMAT_R8G8B8A8_SNORM; + case PIPE_FORMAT_ABGR_SNORM: + return MESA_FORMAT_A8B8G8R8_SNORM; case PIPE_FORMAT_A8_SNORM: return MESA_FORMAT_A_SNORM8; @@ -804,10 +820,14 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_B4G4R4X4_UNORM; case PIPE_FORMAT_B5G5R5X1_UNORM: return MESA_FORMAT_B5G5R5X1_UNORM; - case PIPE_FORMAT_R8G8B8X8_SNORM: + case PIPE_FORMAT_RGBX_SNORM: return MESA_FORMAT_R8G8B8X8_SNORM; - case PIPE_FORMAT_R8G8B8X8_SRGB: + case PIPE_FORMAT_XBGR_SNORM: + return MESA_FORMAT_X8B8G8R8_SNORM; + case PIPE_FORMAT_RGBX_SRGB: return MESA_FORMAT_R8G8B8X8_SRGB; + case PIPE_FORMAT_XBGR_SRGB: + return MESA_FORMAT_X8B8G8R8_SRGB; case PIPE_FORMAT_R8G8B8X8_UINT: return MESA_FORMAT_RGBX_UINT8; case PIPE_FORMAT_R8G8B8X8_SINT: @@ -831,10 +851,10 @@ st_pipe_format_to_mesa_format(enum pipe_format format) case PIPE_FORMAT_R32G32B32X32_SINT: return MESA_FORMAT_RGBX_SINT32;
[Mesa-dev] [PATCH 02/11] util: Add PIPE_FORMAT_AnLn and PIPE_FORMAT_GnRn formats
From: Richard Sandiford rsand...@linux.vnet.ibm.com
...i.e. formats in which the alpha or green channel is first in memory.
This means that each LnAn and RnGn format has a reversed counterpart,
which is necessary for handling big-endian mesa-gallium mappings.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Reviewed-by: Brian Paul bri...@vmware.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/auxiliary/util/u_format.csv | 9 +
src/gallium/include/pipe/p_format.h | 10 ++
2 files changed, 19 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index affc363..8329cdf 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/auxiliary/util/u_format.csv
@@ -384,3 +384,12 @@ PIPE_FORMAT_R10G10B10A2_UINT, plain, 1, 1, up10 ,
up10 , up10, up2 , xyz
PIPE_FORMAT_B5G6R5_SRGB , plain, 1, 1, un5 , un6 , un5 , ,
zyx1, srgb, un5 , un6 , un5 , , xyz1
+PIPE_FORMAT_A8L8_UNORM, plain, 1, 1, un8 , un8 , , , yyyx, rgb
+PIPE_FORMAT_A8L8_SNORM, plain, 1, 1, sn8 , sn8 , , , yyyx, rgb
+PIPE_FORMAT_A8L8_SRGB , plain, 1, 1, un8 , un8 , , , yyyx, srgb
+PIPE_FORMAT_A16L16_UNORM , plain, 1, 1, un16, un16, , , yyyx, rgb
+
+PIPE_FORMAT_G8R8_UNORM, plain, 1, 1, un8 , un8 , , , yx01, rgb
+PIPE_FORMAT_G8R8_SNORM, plain, 1, 1, sn8 , sn8 , , , yx01, rgb
+PIPE_FORMAT_G16R16_UNORM , plain, 1, 1, un16, un16, , , yx01, rgb
+PIPE_FORMAT_G16R16_SNORM , plain, 1, 1, sn16, sn16, , , yx01, rgb
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_format.h
index 1b04884..d744205 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -349,6 +349,16 @@ enum pipe_format {
PIPE_FORMAT_BPTC_RGB_FLOAT = 257,
PIPE_FORMAT_BPTC_RGB_UFLOAT = 258,
+ PIPE_FORMAT_A8L8_UNORM = 259,
+ PIPE_FORMAT_A8L8_SNORM = 260,
+ PIPE_FORMAT_A8L8_SRGB = 261,
+ PIPE_FORMAT_A16L16_UNORM= 262,
+
+ PIPE_FORMAT_G8R8_UNORM = 263,
+ PIPE_FORMAT_G8R8_SNORM = 264,
+ PIPE_FORMAT_G16R16_UNORM= 265,
+ PIPE_FORMAT_G16R16_SNORM= 266,
+
PIPE_FORMAT_COUNT
};
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/11] mesa: Add MESA_FORMAT_{A8R8G8B8, X8R8G8B8, X8B8G8R8}_SRGB
From: Richard Sandiford rsand...@linux.vnet.ibm.com
This means that each SRGB format has a reversed counterpart,
which is necessary for handling big-endian mesa-gallium mappings.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
src/mesa/main/format_pack.c | 60 +
src/mesa/main/format_unpack.c | 42 +
src/mesa/main/formats.c | 16 +++
src/mesa/main/formats.csv | 3 ++
src/mesa/main/formats.h | 3 ++
src/mesa/main/texformat.c | 10 +
src/mesa/swrast/s_texfetch.c| 3 ++
src/mesa/swrast/s_texfetch_tmp.h| 24 ++
9 files changed, 162 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index b726c27..21b8adb 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -517,6 +517,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
[MESA_FORMAT_B5G5R5X1_UNORM] = BRW_SURFACEFORMAT_B5G5R5X1_UNORM,
[MESA_FORMAT_R8G8B8X8_SNORM] = 0,
[MESA_FORMAT_R8G8B8X8_SRGB] = 0,
+ [MESA_FORMAT_X8B8G8R8_SRGB] = 0,
[MESA_FORMAT_RGBX_UINT8] = 0,
[MESA_FORMAT_RGBX_SINT8] = 0,
[MESA_FORMAT_B10G10R10X2_UNORM] = BRW_SURFACEFORMAT_B10G10R10X2_UNORM,
diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c
index 231fd6c..15bf0e5 100644
--- a/src/mesa/main/format_pack.c
+++ b/src/mesa/main/format_pack.c
@@ -1076,6 +1076,31 @@ pack_float_B8G8R8A8_SRGB(const GLfloat src[4], void *dst)
}
+/* MESA_FORMAT_A8R8G8B8_SRGB */
+
+static void
+pack_ubyte_A8R8G8B8_SRGB(const GLubyte src[4], void *dst)
+{
+ GLuint *d = ((GLuint *) dst);
+ GLubyte r = util_format_linear_to_srgb_8unorm(src[RCOMP]);
+ GLubyte g = util_format_linear_to_srgb_8unorm(src[GCOMP]);
+ GLubyte b = util_format_linear_to_srgb_8unorm(src[BCOMP]);
+ *d = PACK_COLOR_(b, g, r, src[ACOMP]);
+}
+
+static void
+pack_float_A8R8G8B8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLuint *d = ((GLuint *) dst);
+ GLubyte r, g, b, a;
+ r = util_format_linear_float_to_srgb_8unorm(src[RCOMP]);
+ g = util_format_linear_float_to_srgb_8unorm(src[GCOMP]);
+ b = util_format_linear_float_to_srgb_8unorm(src[BCOMP]);
+ UNCLAMPED_FLOAT_TO_UBYTE(a, src[ACOMP]);
+ *d = PACK_COLOR_(b, g, r, a);
+}
+
+
/* MESA_FORMAT_R8G8B8A8_SRGB */
static void
@@ -1750,6 +1775,21 @@ pack_float_R8G8B8X8_SRGB(const GLfloat src[4], void *dst)
}
+/*
+ * MESA_FORMAT_X8B8G8R8_SRGB
+ */
+
+static void
+pack_float_X8B8G8R8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLuint *d = (GLuint *) dst;
+ GLubyte r = util_format_linear_float_to_srgb_8unorm(src[RCOMP]);
+ GLubyte g = util_format_linear_float_to_srgb_8unorm(src[GCOMP]);
+ GLubyte b = util_format_linear_float_to_srgb_8unorm(src[BCOMP]);
+ *d = PACK_COLOR_(r, g, b, 127);
+}
+
+
/* MESA_FORMAT_B10G10R10X2_UNORM */
static void
@@ -1899,6 +1939,20 @@ pack_float_B8G8R8X8_SRGB(const GLfloat src[4], void *dst)
*d = PACK_COLOR_(127, r, g, b);
}
+/*
+ * MESA_FORMAT_X8R8G8B8_SRGB
+ */
+
+static void
+pack_float_X8R8G8B8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLuint *d = (GLuint *) dst;
+ GLubyte r = util_format_linear_float_to_srgb_8unorm(src[RCOMP]);
+ GLubyte g = util_format_linear_float_to_srgb_8unorm(src[GCOMP]);
+ GLubyte b = util_format_linear_float_to_srgb_8unorm(src[BCOMP]);
+ *d = PACK_COLOR_(b, g, r, 127);
+}
+
/**
* Return a function that can pack a GLubyte rgba[4] color.
*/
@@ -1966,6 +2020,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format format)
table[MESA_FORMAT_BGR_SRGB8] = pack_ubyte_BGR_SRGB8;
table[MESA_FORMAT_A8B8G8R8_SRGB] = pack_ubyte_A8B8G8R8_SRGB;
table[MESA_FORMAT_B8G8R8A8_SRGB] = pack_ubyte_B8G8R8A8_SRGB;
+ table[MESA_FORMAT_A8R8G8B8_SRGB] = pack_ubyte_A8R8G8B8_SRGB;
table[MESA_FORMAT_R8G8B8A8_SRGB] = pack_ubyte_R8G8B8A8_SRGB;
table[MESA_FORMAT_L_SRGB8] = pack_ubyte_L_SRGB8;
table[MESA_FORMAT_L8A8_SRGB] = pack_ubyte_L8A8_SRGB;
@@ -2040,6 +2095,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format format)
table[MESA_FORMAT_B5G5R5X1_UNORM] = pack_ubyte_XRGB1555_UNORM;
table[MESA_FORMAT_R8G8B8X8_SNORM] = NULL;
table[MESA_FORMAT_R8G8B8X8_SRGB] = NULL;
+ table[MESA_FORMAT_X8B8G8R8_SRGB] = NULL;
table[MESA_FORMAT_RGBX_UINT8] = NULL;
table[MESA_FORMAT_RGBX_SINT8] = NULL;
table[MESA_FORMAT_B10G10R10X2_UNORM] = pack_ubyte_B10G10R10X2_UNORM;
@@ -2055,6 +2111,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format format)
table[MESA_FORMAT_R10G10B10A2_UNORM] = pack_ubyte_R10G10B10A2_UNORM;
table[MESA_FORMAT_B8G8R8X8_SRGB] = NULL;
+
[Mesa-dev] [PATCH 06/11] util: Add PIPE_FORMAT_x8B8G8R8_SNORM formats
From: Richard Sandiford rsand...@linux.vnet.ibm.com
This means that each RnGnBnxn format has a reversed counterpart,
which is necessary for handling big-endian mesa-gallium mappings.
The associated UNORM and SRGB formats already exist.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Reviewed-by: Brian Paul bri...@vmware.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/auxiliary/util/u_format.csv | 3 +++
src/gallium/include/pipe/p_format.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index 8329cdf..a71aaf1 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/auxiliary/util/u_format.csv
@@ -393,3 +393,6 @@ PIPE_FORMAT_G8R8_UNORM, plain, 1, 1, un8 , un8
, , , yx01, rgb
PIPE_FORMAT_G8R8_SNORM, plain, 1, 1, sn8 , sn8 , , , yx01, rgb
PIPE_FORMAT_G16R16_UNORM , plain, 1, 1, un16, un16, , , yx01, rgb
PIPE_FORMAT_G16R16_SNORM , plain, 1, 1, sn16, sn16, , , yx01, rgb
+
+PIPE_FORMAT_A8B8G8R8_SNORM, plain, 1, 1, sn8 , sn8 , sn8 , sn8 , wzyx,
rgb
+PIPE_FORMAT_X8B8G8R8_SNORM, plain, 1, 1, x8, sn8, sn8, sn8, wzy1,
rgb
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_format.h
index 7eb634d..d309fa1 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -359,6 +359,9 @@ enum pipe_format {
PIPE_FORMAT_G16R16_UNORM= 265,
PIPE_FORMAT_G16R16_SNORM= 266,
+ PIPE_FORMAT_A8B8G8R8_SNORM = 267,
+ PIPE_FORMAT_X8B8G8R8_SNORM = 268,
+
PIPE_FORMAT_COUNT
};
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] big endian LA and 8888 SRGB/SNORM fixes (rebased)
Hi, I've taken Richard's previous patchset and rebased them on top of current mesa formats code, I pushed some of Richard's other patches already but these needs some changes, so I thought I'd repost them in case anyone wanted to take a look. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/11] swrast: Fix handling of MESA_FORMAT_L8A8_SRGB for big-endian
From: Richard Sandiford rsand...@linux.vnet.ibm.com
Luminance is the least-significant byte of the uint16, rather than the
lowest byte in memory. Other parts of mesa already handle this correctly
for big-endian, and swrast already handles other MESA_FORMAT_x8y8 formats
correctly. This case was just an odd-one-out.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Reviewed-by: Brian Paul bri...@vmware.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/swrast/s_texfetch_tmp.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/swrast/s_texfetch_tmp.h b/src/mesa/swrast/s_texfetch_tmp.h
index 72037ec..3923e2b 100644
--- a/src/mesa/swrast/s_texfetch_tmp.h
+++ b/src/mesa/swrast/s_texfetch_tmp.h
@@ -808,11 +808,11 @@ static void
FETCH(L8A8_SRGB)(const struct swrast_texture_image *texImage,
GLint i, GLint j, GLint k, GLfloat *texel)
{
- const GLubyte *src = TEXEL_ADDR(GLubyte, texImage, i, j, k, 2);
+ const GLushort s = *TEXEL_ADDR(GLushort, texImage, i, j, k, 1);
texel[RCOMP] =
texel[GCOMP] =
- texel[BCOMP] = util_format_srgb_8unorm_to_linear_float(src[0]);
- texel[ACOMP] = UBYTE_TO_FLOAT(src[1]); /* linear */
+ texel[BCOMP] = util_format_srgb_8unorm_to_linear_float(s 0xff);
+ texel[ACOMP] = UBYTE_TO_FLOAT(s 8); /* linear */
}
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/11] mesa: Add MESA_FORMAT_A8L8_{SNORM,SRGB}
From: Richard Sandiford rsand...@linux.vnet.ibm.com
The associated UNORM format already existed.
This means that each LnAn format has a reversed counterpart,
which is necessary for handling big-endian mesa-gallium mappings.
[airlied: rebased onto current master]
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Reviewed-by: Brian Paul bri...@vmware.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 2 ++
src/mesa/main/format_pack.c | 37 +
src/mesa/main/format_unpack.c | 29 +++
src/mesa/main/formats.c | 10 +++
src/mesa/main/formats.csv | 2 ++
src/mesa/main/formats.h | 2 ++
src/mesa/main/texformat.c | 3 ++
src/mesa/swrast/s_texfetch.c| 2 ++
src/mesa/swrast/s_texfetch_tmp.h| 24
9 files changed, 111 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index 974f2df..b726c27 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -371,6 +371,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
[MESA_FORMAT_R8G8B8A8_SRGB] = BRW_SURFACEFORMAT_R8G8B8A8_UNORM_SRGB,
[MESA_FORMAT_L_SRGB8] = BRW_SURFACEFORMAT_L8_UNORM_SRGB,
[MESA_FORMAT_L8A8_SRGB] = BRW_SURFACEFORMAT_L8A8_UNORM_SRGB,
+ [MESA_FORMAT_A8L8_SRGB] = 0,
[MESA_FORMAT_SRGB_DXT1] = BRW_SURFACEFORMAT_DXT1_RGB_SRGB,
[MESA_FORMAT_SRGBA_DXT1] = BRW_SURFACEFORMAT_BC1_UNORM_SRGB,
[MESA_FORMAT_SRGBA_DXT3] = BRW_SURFACEFORMAT_BC2_UNORM_SRGB,
@@ -495,6 +496,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
[MESA_FORMAT_A_SNORM8] = 0,
[MESA_FORMAT_L_SNORM8] = 0,
[MESA_FORMAT_L8A8_SNORM] = 0,
+ [MESA_FORMAT_A8L8_SNORM] = 0,
[MESA_FORMAT_I_SNORM8] = 0,
[MESA_FORMAT_A_SNORM16] = 0,
[MESA_FORMAT_L_SNORM16] = 0,
diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c
index 6cbf859..231fd6c 100644
--- a/src/mesa/main/format_pack.c
+++ b/src/mesa/main/format_pack.c
@@ -1129,6 +1129,16 @@ pack_ubyte_L8A8_SRGB(const GLubyte src[4], void *dst)
*d = PACK_COLOR_88(src[ACOMP], l);
}
+/* MESA_FORMAT_A8L8_SRGB */
+
+static void
+pack_ubyte_A8L8_SRGB(const GLubyte src[4], void *dst)
+{
+ GLushort *d = ((GLushort *) dst);
+ GLubyte l = util_format_linear_to_srgb_8unorm(src[RCOMP]);
+ *d = PACK_COLOR_88(l, src[ACOMP]);
+}
+
static void
pack_float_L8A8_SRGB(const GLfloat src[4], void *dst)
{
@@ -1138,6 +1148,15 @@ pack_float_L8A8_SRGB(const GLfloat src[4], void *dst)
*d = PACK_COLOR_88(a, l);
}
+static void
+pack_float_A8L8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLushort *d = ((GLushort *) dst);
+ GLubyte a, l = util_format_linear_float_to_srgb_8unorm(src[RCOMP]);
+ CLAMPED_FLOAT_TO_UBYTE(a, src[ACOMP]);
+ *d = PACK_COLOR_88(l, a);
+}
+
/* MESA_FORMAT_RGBA_FLOAT32 */
@@ -1563,6 +1582,20 @@ pack_float_L8A8_SNORM(const GLfloat src[4], void *dst)
/*
+ * MESA_FORMAT_A8L8_SNORM
+ */
+
+static void
+pack_float_A8L8_SNORM(const GLfloat src[4], void *dst)
+{
+ GLushort *d = (GLushort *) dst;
+ GLbyte l = FLOAT_TO_BYTE(CLAMP(src[RCOMP], -1.0f, 1.0f));
+ GLbyte a = FLOAT_TO_BYTE(CLAMP(src[ACOMP], -1.0f, 1.0f));
+ *d = (l 8) | a;
+}
+
+
+/*
* MESA_FORMAT_A_SNORM16
*/
@@ -1936,6 +1969,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format format)
table[MESA_FORMAT_R8G8B8A8_SRGB] = pack_ubyte_R8G8B8A8_SRGB;
table[MESA_FORMAT_L_SRGB8] = pack_ubyte_L_SRGB8;
table[MESA_FORMAT_L8A8_SRGB] = pack_ubyte_L8A8_SRGB;
+ table[MESA_FORMAT_A8L8_SRGB] = pack_ubyte_A8L8_SRGB;
/* n/a */
table[MESA_FORMAT_SRGB_DXT1] = NULL; /* pack_ubyte_SRGB_DXT1; */
table[MESA_FORMAT_SRGBA_DXT1] = NULL; /* pack_ubyte_SRGBA_DXT1; */
@@ -1989,6 +2023,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format format)
table[MESA_FORMAT_A_SNORM8] = NULL;
table[MESA_FORMAT_L_SNORM8] = NULL;
table[MESA_FORMAT_L8A8_SNORM] = NULL;
+ table[MESA_FORMAT_A8L8_SNORM] = NULL;
table[MESA_FORMAT_I_SNORM8] = NULL;
table[MESA_FORMAT_A_SNORM16] = NULL;
table[MESA_FORMAT_L_SNORM16] = NULL;
@@ -2099,6 +2134,7 @@ _mesa_get_pack_float_rgba_function(mesa_format format)
table[MESA_FORMAT_R8G8B8A8_SRGB] = pack_float_R8G8B8A8_SRGB;
table[MESA_FORMAT_L_SRGB8] = pack_float_L_SRGB8;
table[MESA_FORMAT_L8A8_SRGB] = pack_float_L8A8_SRGB;
+ table[MESA_FORMAT_A8L8_SRGB] = pack_float_A8L8_SRGB;
/* n/a */
table[MESA_FORMAT_SRGB_DXT1] = NULL;
@@ -2153,6 +2189,7 @@ _mesa_get_pack_float_rgba_function(mesa_format format)
table[MESA_FORMAT_A_SNORM8] = pack_float_A_SNORM8;
table[MESA_FORMAT_L_SNORM8] = pack_float_L_SNORM8;
[Mesa-dev] [PATCH 03/11] util: Define PIPE_FORMAT_{LA, AL, RG, GR}nn aliases
From: Richard Sandiford rsand...@linux.vnet.ibm.com
...i.e. formats in which the first listed component is in the least
significant half of the integer.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Reviewed-by: Brian Paul bri...@vmware.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/include/pipe/p_format.h | 32
1 file changed, 32 insertions(+)
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_format.h
index d744205..7eb634d 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -371,6 +371,22 @@ enum pipe_format {
#define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
+#define PIPE_FORMAT_LA88_UNORM PIPE_FORMAT_L8A8_UNORM
+#define PIPE_FORMAT_AL88_UNORM PIPE_FORMAT_A8L8_UNORM
+#define PIPE_FORMAT_LA88_SNORM PIPE_FORMAT_L8A8_SNORM
+#define PIPE_FORMAT_AL88_SNORM PIPE_FORMAT_A8L8_SNORM
+#define PIPE_FORMAT_LA88_SRGB PIPE_FORMAT_L8A8_SRGB
+#define PIPE_FORMAT_AL88_SRGB PIPE_FORMAT_A8L8_SRGB
+#define PIPE_FORMAT_LA1616_UNORM PIPE_FORMAT_L16A16_UNORM
+#define PIPE_FORMAT_AL1616_UNORM PIPE_FORMAT_A16L16_UNORM
+#define PIPE_FORMAT_RG88_UNORM PIPE_FORMAT_R8G8_UNORM
+#define PIPE_FORMAT_GR88_UNORM PIPE_FORMAT_G8R8_UNORM
+#define PIPE_FORMAT_RG88_SNORM PIPE_FORMAT_R8G8_SNORM
+#define PIPE_FORMAT_GR88_SNORM PIPE_FORMAT_G8R8_SNORM
+#define PIPE_FORMAT_RG1616_UNORM PIPE_FORMAT_R16G16_UNORM
+#define PIPE_FORMAT_GR1616_UNORM PIPE_FORMAT_G16R16_UNORM
+#define PIPE_FORMAT_RG1616_SNORM PIPE_FORMAT_R16G16_SNORM
+#define PIPE_FORMAT_GR1616_SNORM PIPE_FORMAT_G16R16_SNORM
#elif defined(PIPE_ARCH_BIG_ENDIAN)
#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
#define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_R8G8B8X8_UNORM
@@ -381,6 +397,22 @@ enum pipe_format {
#define PIPE_FORMAT_BGRX_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
#define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#define PIPE_FORMAT_RGBX_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
+#define PIPE_FORMAT_LA88_UNORM PIPE_FORMAT_A8L8_UNORM
+#define PIPE_FORMAT_AL88_UNORM PIPE_FORMAT_L8A8_UNORM
+#define PIPE_FORMAT_LA88_SNORM PIPE_FORMAT_A8L8_SNORM
+#define PIPE_FORMAT_AL88_SNORM PIPE_FORMAT_L8A8_SNORM
+#define PIPE_FORMAT_LA88_SRGB PIPE_FORMAT_A8L8_SRGB
+#define PIPE_FORMAT_AL88_SRGB PIPE_FORMAT_L8A8_SRGB
+#define PIPE_FORMAT_LA1616_UNORM PIPE_FORMAT_A16L16_UNORM
+#define PIPE_FORMAT_AL1616_UNORM PIPE_FORMAT_L16A16_UNORM
+#define PIPE_FORMAT_RG88_UNORM PIPE_FORMAT_G8R8_UNORM
+#define PIPE_FORMAT_GR88_UNORM PIPE_FORMAT_R8G8_UNORM
+#define PIPE_FORMAT_RG88_SNORM PIPE_FORMAT_G8R8_SNORM
+#define PIPE_FORMAT_GR88_SNORM PIPE_FORMAT_R8G8_SNORM
+#define PIPE_FORMAT_RG1616_UNORM PIPE_FORMAT_G16R16_UNORM
+#define PIPE_FORMAT_GR1616_UNORM PIPE_FORMAT_R16G16_UNORM
+#define PIPE_FORMAT_RG1616_SNORM PIPE_FORMAT_G16R16_SNORM
+#define PIPE_FORMAT_GR1616_SNORM PIPE_FORMAT_R16G16_SNORM
#endif
enum pipe_video_chroma_format
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/11] util: Define PIPE_FORMAT_xyzw8888_{SNORM, SRGB} aliases
From: Richard Sandiford rsand...@linux.vnet.ibm.com
...i.e. formats in which the first listed component is in the least
significant byte of the integer. The corresponding UNORM aliases already exist.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/include/pipe/p_format.h | 24
1 file changed, 24 insertions(+)
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_format.h
index d309fa1..9c02464 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -374,6 +374,18 @@ enum pipe_format {
#define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
+#define PIPE_FORMAT_RGBA_SNORM PIPE_FORMAT_R8G8B8A8_SNORM
+#define PIPE_FORMAT_RGBX_SNORM PIPE_FORMAT_R8G8B8X8_SNORM
+#define PIPE_FORMAT_ABGR_SNORM PIPE_FORMAT_A8B8G8R8_SNORM
+#define PIPE_FORMAT_XBGR_SNORM PIPE_FORMAT_X8B8G8R8_SNORM
+#define PIPE_FORMAT_RGBA_SRGB PIPE_FORMAT_R8G8B8A8_SRGB
+#define PIPE_FORMAT_RGBX_SRGB PIPE_FORMAT_R8G8B8X8_SRGB
+#define PIPE_FORMAT_BGRA_SRGB PIPE_FORMAT_B8G8R8A8_SRGB
+#define PIPE_FORMAT_BGRX_SRGB PIPE_FORMAT_B8G8R8X8_SRGB
+#define PIPE_FORMAT_ARGB_SRGB PIPE_FORMAT_A8R8G8B8_SRGB
+#define PIPE_FORMAT_XRGB_SRGB PIPE_FORMAT_X8R8G8B8_SRGB
+#define PIPE_FORMAT_ABGR_SRGB PIPE_FORMAT_A8B8G8R8_SRGB
+#define PIPE_FORMAT_XBGR_SRGB PIPE_FORMAT_X8B8G8R8_SRGB
#define PIPE_FORMAT_LA88_UNORM PIPE_FORMAT_L8A8_UNORM
#define PIPE_FORMAT_AL88_UNORM PIPE_FORMAT_A8L8_UNORM
#define PIPE_FORMAT_LA88_SNORM PIPE_FORMAT_L8A8_SNORM
@@ -400,6 +412,18 @@ enum pipe_format {
#define PIPE_FORMAT_BGRX_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
#define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#define PIPE_FORMAT_RGBX_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
+#define PIPE_FORMAT_ABGR_SNORM PIPE_FORMAT_R8G8B8A8_SNORM
+#define PIPE_FORMAT_XBGR_SNORM PIPE_FORMAT_R8G8B8X8_SNORM
+#define PIPE_FORMAT_RGBA_SNORM PIPE_FORMAT_A8B8G8R8_SNORM
+#define PIPE_FORMAT_RGBX_SNORM PIPE_FORMAT_X8B8G8R8_SNORM
+#define PIPE_FORMAT_ABGR_SRGB PIPE_FORMAT_R8G8B8A8_SRGB
+#define PIPE_FORMAT_XBGR_SRGB PIPE_FORMAT_R8G8B8X8_SRGB
+#define PIPE_FORMAT_ARGB_SRGB PIPE_FORMAT_B8G8R8A8_SRGB
+#define PIPE_FORMAT_XRGB_SRGB PIPE_FORMAT_B8G8R8X8_SRGB
+#define PIPE_FORMAT_BGRA_SRGB PIPE_FORMAT_A8R8G8B8_SRGB
+#define PIPE_FORMAT_BGRX_SRGB PIPE_FORMAT_X8R8G8B8_SRGB
+#define PIPE_FORMAT_RGBA_SRGB PIPE_FORMAT_A8B8G8R8_SRGB
+#define PIPE_FORMAT_RGBX_SRGB PIPE_FORMAT_X8B8G8R8_SRGB
#define PIPE_FORMAT_LA88_UNORM PIPE_FORMAT_A8L8_UNORM
#define PIPE_FORMAT_AL88_UNORM PIPE_FORMAT_L8A8_UNORM
#define PIPE_FORMAT_LA88_SNORM PIPE_FORMAT_A8L8_SNORM
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/11] mesa: Tweak unpack name for MESA_FORMAT_R8G8B8X8_SNORM
From: Richard Sandiford rsand...@linux.vnet.ibm.com
MESA_FORMAT_R8G8B8X8_SNORM used a function called unpack_X8B8G8R8_SNORM
while MESA_FORMAT_R8G8B8X8_SRGB used a function called unpack_R8G8B8X8_SRGB.
This patch renames the SNORM function to have the same order as the
MESA_FORMAT name, like the SRGB function does.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/main/format_unpack.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index eed92d8..68fbcb3 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -2106,7 +2106,7 @@ unpack_XRGB1555_UNORM(const void *src, GLfloat dst[][4],
GLuint n)
}
static void
-unpack_XBGR_SNORM(const void *src, GLfloat dst[][4], GLuint n)
+unpack_R8G8B8X8_SNORM(const void *src, GLfloat dst[][4], GLuint n)
{
const GLuint *s = ((const GLuint *) src);
GLuint i;
@@ -2526,7 +2526,7 @@ get_unpack_rgba_function(mesa_format format)
table[MESA_FORMAT_B4G4R4X4_UNORM] = unpack_XRGB_UNORM;
table[MESA_FORMAT_B5G5R5X1_UNORM] = unpack_XRGB1555_UNORM;
- table[MESA_FORMAT_R8G8B8X8_SNORM] = unpack_XBGR_SNORM;
+ table[MESA_FORMAT_R8G8B8X8_SNORM] = unpack_R8G8B8X8_SNORM;
table[MESA_FORMAT_R8G8B8X8_SRGB] = unpack_R8G8B8X8_SRGB;
table[MESA_FORMAT_RGBX_UINT8] = unpack_XBGR_UINT;
table[MESA_FORMAT_RGBX_SINT8] = unpack_XBGR_SINT;
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/11] mesa: Fix alpha component in unpack_R8G8B8X8_SRGB.
From: Richard Sandiford rsand...@linux.vnet.ibm.com The function was using the X component as the alpha channel, rather than setting alpha to 1.0. Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com Reviewed-by: Brian Paul bri...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com --- src/mesa/main/format_unpack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c index 68fbcb3..cfa6a60 100644 --- a/src/mesa/main/format_unpack.c +++ b/src/mesa/main/format_unpack.c @@ -2127,7 +2127,7 @@ unpack_R8G8B8X8_SRGB(const void *src, GLfloat dst[][4], GLuint n) dst[i][RCOMP] = util_format_srgb_8unorm_to_linear_float( (s[i] ) 0xff ); dst[i][GCOMP] = util_format_srgb_8unorm_to_linear_float( (s[i] 8) 0xff ); dst[i][BCOMP] = util_format_srgb_8unorm_to_linear_float( (s[i] 16) 0xff ); - dst[i][ACOMP] = UBYTE_TO_FLOAT( s[i] 24 ); /* linear! */ + dst[i][ACOMP] = 1.0f; } } -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/11] st/mesa: Fix handling of LA and RG formats for big-endian
From: Richard Sandiford rsand...@linux.vnet.ibm.com MESA_FORMAT_LnAn puts the luminance in the least significant part of the containing integer, which is equivalent to PIPE_FORMAT_LAnn. PIPE_FORMAT_LnAn puts the luminance first in memory. This patch fixes up the mesa-gallium mapping accordingly. Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com Reviewed-by: Brian Paul bri...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com --- src/mesa/state_tracker/st_format.c | 64 -- 1 file changed, 48 insertions(+), 16 deletions(-) diff --git a/src/mesa/state_tracker/st_format.c b/src/mesa/state_tracker/st_format.c index 531bc65..6caedfc 100644 --- a/src/mesa/state_tracker/st_format.c +++ b/src/mesa/state_tracker/st_format.c @@ -88,9 +88,13 @@ st_mesa_format_to_pipe_format(struct st_context *st, mesa_format mesaFormat) case MESA_FORMAT_L4A4_UNORM: return PIPE_FORMAT_L4A4_UNORM; case MESA_FORMAT_L8A8_UNORM: - return PIPE_FORMAT_L8A8_UNORM; + return PIPE_FORMAT_LA88_UNORM; + case MESA_FORMAT_A8L8_UNORM: + return PIPE_FORMAT_AL88_UNORM; case MESA_FORMAT_L16A16_UNORM: - return PIPE_FORMAT_L16A16_UNORM; + return PIPE_FORMAT_LA1616_UNORM; + case MESA_FORMAT_A16L16_UNORM: + return PIPE_FORMAT_AL1616_UNORM; case MESA_FORMAT_A_UNORM8: return PIPE_FORMAT_A8_UNORM; case MESA_FORMAT_A_UNORM16: @@ -142,7 +146,9 @@ st_mesa_format_to_pipe_format(struct st_context *st, mesa_format mesaFormat) case MESA_FORMAT_SRGBA_DXT5: return PIPE_FORMAT_DXT5_SRGBA; case MESA_FORMAT_L8A8_SRGB: - return PIPE_FORMAT_L8A8_SRGB; + return PIPE_FORMAT_LA88_SRGB; + case MESA_FORMAT_A8L8_SRGB: + return PIPE_FORMAT_AL88_SRGB; case MESA_FORMAT_L_SRGB8: return PIPE_FORMAT_L8_SRGB; case MESA_FORMAT_BGR_SRGB8: @@ -191,9 +197,13 @@ st_mesa_format_to_pipe_format(struct st_context *st, mesa_format mesaFormat) case MESA_FORMAT_R_UNORM16: return PIPE_FORMAT_R16_UNORM; case MESA_FORMAT_R8G8_UNORM: - return PIPE_FORMAT_R8G8_UNORM; + return PIPE_FORMAT_RG88_UNORM; + case MESA_FORMAT_G8R8_UNORM: + return PIPE_FORMAT_GR88_UNORM; case MESA_FORMAT_R16G16_UNORM: - return PIPE_FORMAT_R16G16_UNORM; + return PIPE_FORMAT_RG1616_UNORM; + case MESA_FORMAT_G16R16_UNORM: + return PIPE_FORMAT_GR1616_UNORM; case MESA_FORMAT_RGBA_UNORM16: return PIPE_FORMAT_R16G16B16A16_UNORM; @@ -341,7 +351,9 @@ st_mesa_format_to_pipe_format(struct st_context *st, mesa_format mesaFormat) case MESA_FORMAT_R_SNORM8: return PIPE_FORMAT_R8_SNORM; case MESA_FORMAT_R8G8_SNORM: - return PIPE_FORMAT_R8G8_SNORM; + return PIPE_FORMAT_RG88_SNORM; + case MESA_FORMAT_G8R8_SNORM: + return PIPE_FORMAT_GR88_SNORM; case MESA_FORMAT_R8G8B8A8_SNORM: return PIPE_FORMAT_R8G8B8A8_SNORM; @@ -350,14 +362,18 @@ st_mesa_format_to_pipe_format(struct st_context *st, mesa_format mesaFormat) case MESA_FORMAT_L_SNORM8: return PIPE_FORMAT_L8_SNORM; case MESA_FORMAT_L8A8_SNORM: - return PIPE_FORMAT_L8A8_SNORM; + return PIPE_FORMAT_LA88_SNORM; + case MESA_FORMAT_A8L8_SNORM: + return PIPE_FORMAT_AL88_SNORM; case MESA_FORMAT_I_SNORM8: return PIPE_FORMAT_I8_SNORM; case MESA_FORMAT_R_SNORM16: return PIPE_FORMAT_R16_SNORM; case MESA_FORMAT_R16G16_SNORM: - return PIPE_FORMAT_R16G16_SNORM; + return PIPE_FORMAT_RG1616_SNORM; + case MESA_FORMAT_G16R16_SNORM: + return PIPE_FORMAT_GR1616_SNORM; case MESA_FORMAT_RGBA_SNORM16: return PIPE_FORMAT_R16G16B16A16_SNORM; @@ -476,10 +492,14 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_R10G10B10A2_UNORM; case PIPE_FORMAT_L4A4_UNORM: return MESA_FORMAT_L4A4_UNORM; - case PIPE_FORMAT_L8A8_UNORM: + case PIPE_FORMAT_LA88_UNORM: return MESA_FORMAT_L8A8_UNORM; - case PIPE_FORMAT_L16A16_UNORM: + case PIPE_FORMAT_AL88_UNORM: + return MESA_FORMAT_A8L8_UNORM; + case PIPE_FORMAT_LA1616_UNORM: return MESA_FORMAT_L16A16_UNORM; + case PIPE_FORMAT_AL1616_UNORM: + return MESA_FORMAT_A16L16_UNORM; case PIPE_FORMAT_A8_UNORM: return MESA_FORMAT_A_UNORM8; case PIPE_FORMAT_A16_UNORM: @@ -536,8 +556,10 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_SRGBA_DXT3; case PIPE_FORMAT_DXT5_SRGBA: return MESA_FORMAT_SRGBA_DXT5; - case PIPE_FORMAT_L8A8_SRGB: + case PIPE_FORMAT_LA88_SRGB: return MESA_FORMAT_L8A8_SRGB; + case PIPE_FORMAT_AL88_SRGB: + return MESA_FORMAT_A8L8_SRGB; case PIPE_FORMAT_L8_SRGB: return MESA_FORMAT_L_SRGB8; case PIPE_FORMAT_R8G8B8_SRGB: @@ -583,10 +605,14 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_R_UNORM8; case PIPE_FORMAT_R16_UNORM: return MESA_FORMAT_R_UNORM16; - case PIPE_FORMAT_R8G8_UNORM: + case
Re: [Mesa-dev] [PATCH] i965: add support for RGBA dma_buf imports.
Hi,
2014-09-09 10:56 GMT+02:00 Gwenole Beauchesne gb.de...@gmail.com:
This allows for importing foreign buffers in RGB32 native endian
byte order, i.e. DRM_FORMAT_XBGR, and DRM_FORMAT_ABGR.
Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
src/mesa/drivers/dri/i965/intel_screen.c |6 ++
1 file changed, 6 insertions(+)
Ping. This looks trivial enough, unless I missed anything. :)
Besides, I would like this to land into 10.3, if this is not too late,
or the next 10.3.x.
Thanks,
Gwenole.
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 9e743ee..db7feb2 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -217,12 +217,18 @@ static struct intel_image_format intel_image_formats[]
= {
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
{ { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
+ { __DRI_IMAGE_FOURCC_ABGR, __DRI_IMAGE_COMPONENTS_RGBA, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_ABGR, 4 } } },
+
{ __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
{ { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
{ { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
+ { __DRI_IMAGE_FOURCC_XBGR, __DRI_IMAGE_COMPONENTS_RGB, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_XBGR, 4 }, } },
+
{ __DRI_IMAGE_FOURCC_RGB565, __DRI_IMAGE_COMPONENTS_RGB, 1,
{ { 0, 0, 0, __DRI_IMAGE_FORMAT_RGB565, 2 } } },
--
1.7.9.5
--
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/11] mesa: Add MESA_FORMAT_{A8R8G8B8, X8R8G8B8, X8B8G8R8}_SRGB
static void
+FETCH(A8R8G8B8_SRGB)(const struct swrast_texture_image *texImage,
+ GLint i, GLint j, GLint k, GLfloat *texel)
+{
+ const GLuint s = *TEXEL_ADDR(GLuint, texImage, i, j, k, 1);
+ texel[RCOMP] = nonlinear_to_linear( (s 8) 0xff );
+ texel[GCOMP] = nonlinear_to_linear( (s 16) 0xff );
+ texel[BCOMP] = nonlinear_to_linear( (s 24) );
+ texel[ACOMP] = UBYTE_TO_FLOAT( s 0xff ); /* linear! */
+}
+
+
+static void
FETCH(R8G8B8A8_SRGB)(const struct swrast_texture_image *texImage,
GLint i, GLint j, GLint k, GLfloat *texel)
{
@@ -793,6 +805,18 @@ FETCH(R8G8B8X8_SRGB)(const struct swrast_texture_image
*texImage,
static void
+FETCH(X8B8G8R8_SRGB)(const struct swrast_texture_image *texImage,
+ GLint i, GLint j, GLint k, GLfloat *texel)
+{
+ const GLuint s = *TEXEL_ADDR(GLuint, texImage, i, j, k, 1);
+ texel[RCOMP] = nonlinear_to_linear( (s 24) );
+ texel[GCOMP] = nonlinear_to_linear( (s 16) 0xff );
+ texel[BCOMP] = nonlinear_to_linear( (s 8) 0xff );
+ texel[ACOMP] = 1.0f;
+}
+
+
I've just noticed these locally don't build, I've fixed them to use
the new interfaces.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
On Thursday, August 14, 2014 01:11:32 PM Iago Toral Quiroga wrote: Hi, this series brings support for geometry shaders in Sandy Bridge (gen6) and is combined work from Samuel and myself. I've looked over most of the series, and everything looks good (though I didn't have time to look at it in as much detail as I'd hoped). It sounds like Jordan's reviewed quite a bit of it. Feel free to add my ack on the series: Acked-by: Kenneth Graunke kenn...@whitecape.org I think you're probably good to push it at this point. Fantastic work, as always :) signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/37] i965/gs: Use single dispatch mode as fallback to dual object mode when possible.
On Thursday, September 04, 2014 09:36:34 AM Iago Toral Quiroga wrote: On jue, 2014-09-04 at 00:07 -0700, Jordan Justen wrote: On Wed, Sep 3, 2014 at 11:28 PM, Iago Toral Quiroga ito...@igalia.com wrote: On mié, 2014-09-03 at 17:49 -0700, Jordan Justen wrote: On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga ito...@igalia.com wrote: Currently, when a geometry shader can't use dual object mode we fall back to dual instance mode, however, when invocations == 1, single dispatch mode is more performant and equally efficient in terms of register pressure. Single dispatch mode requires that the driver can handle interleaving of registers, but this is already supported (dual instance mode has the same requirement). Maybe this paragraph could use a minor clarification too? (Of what is required vs. optional. And the fact that we're not doing the optional one.) Sure. How about this?: Single dispatch mode requires that the driver can handle interleaving of input registers, but this is already supported (dual instance mode has the same requirement). However, to take full advantage of single dispatch mode to reduce register pressure we would also need to do interleaved outputs, but currently, the vec4 visitor and generator classes do not support this, so at the moment register pressure in single and dual instance modes is the same. I'm not sure about interleaved outputs. Really, the idea is that we want to be able to store two separate vec4 values in a single vec8 register, i.e. register allocating to both r3.0 and r3.4. Which would provide approximately double the register space for ordinary temporary values. Just a thought. I'm sure whatever you write in the comments will be fine. Thanks! signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: add support for RGBA dma_buf imports.
On Tuesday, September 16, 2014 08:52:02 AM Gwenole Beauchesne wrote: Hi, 2014-09-09 10:56 GMT+02:00 Gwenole Beauchesne gb.de...@gmail.com: This allows for importing foreign buffers in RGB32 native endian byte order, i.e. DRM_FORMAT_XBGR, and DRM_FORMAT_ABGR. Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com --- src/mesa/drivers/dri/i965/intel_screen.c |6 ++ 1 file changed, 6 insertions(+) Ping. This looks trivial enough, unless I missed anything. :) Besides, I would like this to land into 10.3, if this is not too late, or the next 10.3.x. Thanks, Gwenole. Seems like a good idea, and looks right, but I haven't really worked with this code. So, I've added: Acked-by: Kenneth Graunke kenn...@whitecape.org Cc: 10.3 mesa-sta...@lists.freedesktop.org and pushed it. Thanks for the patch! signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: do not emit error for non written varyings on OpenGL ES
Patch fixes following test case from 'shaders-with-varyings' WebGL
conformance suite: vertex shader with unused varying and fragment
shader with used varying must succeed
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/link_varyings.cpp | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 54ceae1..fb2d88c 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -1451,7 +1451,7 @@ assign_varying_locations(struct gl_context *ctx,
if (var var-data.mode == ir_var_shader_in
var-data.is_unmatched_generic_inout) {
-if (prog-Version = 120) {
+if (prog-Version = 120 !prog-IsES) {
/* On page 25 (page 31 of the PDF) of the GLSL 1.20 spec:
*
* Only those varying variables used (i.e. read) in
@@ -1463,6 +1463,16 @@ assign_varying_locations(struct gl_context *ctx,
* We interpret this text as meaning that the VS must
* write the variable for the FS to read it. See
* glsl1-varying read but not written in piglit.
+*
+* Note that this is not an error on OpenGL ES:
+*
+* On Page 91 (Page 97 of the PDF) of the GLSL ES 1.0 spec:
+*
+* If the vertex shader declares but doesn't write to a
+* varying and the fragment shader declares and reads it,
+* is this and error?
+*
+* RESOLUTION: No.
*/
linker_error(prog, %s shader varying %s not written
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
On mar, 2014-09-16 at 01:09 -0700, Kenneth Graunke wrote: On Thursday, August 14, 2014 01:11:32 PM Iago Toral Quiroga wrote: Hi, this series brings support for geometry shaders in Sandy Bridge (gen6) and is combined work from Samuel and myself. I've looked over most of the series, and everything looks good (though I didn't have time to look at it in as much detail as I'd hoped). It sounds like Jordan's reviewed quite a bit of it. That's great, thanks Kenneth. I think Jordan only managed to review the first 6 patches so far. Feel free to add my ack on the series: Acked-by: Kenneth Graunke kenn...@whitecape.org Will do. I think you're probably good to push it at this point. Fantastic work, as always :) Thanks! :) I think Jordan still wanted to review the patches, so I'll wait for his ok before pushing anything. Iago ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/37] i965/gs: Use single dispatch mode as fallback to dual object mode when possible.
On mar, 2014-09-16 at 01:10 -0700, Kenneth Graunke wrote: On Thursday, September 04, 2014 09:36:34 AM Iago Toral Quiroga wrote: On jue, 2014-09-04 at 00:07 -0700, Jordan Justen wrote: On Wed, Sep 3, 2014 at 11:28 PM, Iago Toral Quiroga ito...@igalia.com wrote: On mié, 2014-09-03 at 17:49 -0700, Jordan Justen wrote: On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga ito...@igalia.com wrote: Currently, when a geometry shader can't use dual object mode we fall back to dual instance mode, however, when invocations == 1, single dispatch mode is more performant and equally efficient in terms of register pressure. Single dispatch mode requires that the driver can handle interleaving of registers, but this is already supported (dual instance mode has the same requirement). Maybe this paragraph could use a minor clarification too? (Of what is required vs. optional. And the fact that we're not doing the optional one.) Sure. How about this?: Single dispatch mode requires that the driver can handle interleaving of input registers, but this is already supported (dual instance mode has the same requirement). However, to take full advantage of single dispatch mode to reduce register pressure we would also need to do interleaved outputs, but currently, the vec4 visitor and generator classes do not support this, so at the moment register pressure in single and dual instance modes is the same. I'm not sure about interleaved outputs. Really, the idea is that we want to be able to store two separate vec4 values in a single vec8 register, i.e. register allocating to both r3.0 and r3.4. Which would provide approximately double the register space for ordinary temporary values. Just a thought. I'm sure whatever you write in the comments will be fine. Right, this is more general than simply interleaving the outputs. I think I will just use the explanation you wrote directly: (...) However, to take full advantage of single dispatch mode to reduce register pressure we would also need to ability to store two separate vec4 output values into vec8 registers, which would approximately double our capacity to store temporary values, but currently the vec4 visitor and generator classes do not support this, (...) Iago ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/11] st/mesa: Fix handling of 8888 SNORM and SRGB formats for big-endian
Do you also need to extend DEFAULT_SNORM8_RGBA_FORMATS in st_format.c to include your new SNORM format? (And update a whole bunch of the format_map to use that macro.) On Tue, Sep 16, 2014 at 2:28 AM, Dave Airlie airl...@gmail.com wrote: From: Richard Sandiford rsand...@linux.vnet.ibm.com MESA_FORMAT_x8y8z8w8 puts the x channel in the least significant part of the containing 32-bit integer, which is equivalent to PIPE_FORMAT_xyzw. PIPE_FORMAT_x8y8z8w8 puts the x channel first in memory. This patch fixes up the mesa-gallium mapping accordingly. Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com Signed-off-by: Dave Airlie airl...@redhat.com --- src/mesa/state_tracker/st_format.c | 50 ++ 1 file changed, 35 insertions(+), 15 deletions(-) diff --git a/src/mesa/state_tracker/st_format.c b/src/mesa/state_tracker/st_format.c index 6caedfc..37acab6 100644 --- a/src/mesa/state_tracker/st_format.c +++ b/src/mesa/state_tracker/st_format.c @@ -154,11 +154,13 @@ st_mesa_format_to_pipe_format(struct st_context *st, mesa_format mesaFormat) case MESA_FORMAT_BGR_SRGB8: return PIPE_FORMAT_R8G8B8_SRGB; case MESA_FORMAT_A8B8G8R8_SRGB: - return PIPE_FORMAT_A8B8G8R8_SRGB; - case MESA_FORMAT_B8G8R8A8_SRGB: - return PIPE_FORMAT_B8G8R8A8_SRGB; + return PIPE_FORMAT_ABGR_SRGB; case MESA_FORMAT_R8G8B8A8_SRGB: - return PIPE_FORMAT_R8G8B8A8_SRGB; + return PIPE_FORMAT_RGBA_SRGB; + case MESA_FORMAT_B8G8R8A8_SRGB: + return PIPE_FORMAT_BGRA_SRGB; + case MESA_FORMAT_A8R8G8B8_SRGB: + return PIPE_FORMAT_ARGB_SRGB; case MESA_FORMAT_RGBA_FLOAT32: return PIPE_FORMAT_R32G32B32A32_FLOAT; case MESA_FORMAT_RGBA_FLOAT16: @@ -355,7 +357,9 @@ st_mesa_format_to_pipe_format(struct st_context *st, mesa_format mesaFormat) case MESA_FORMAT_G8R8_SNORM: return PIPE_FORMAT_GR88_SNORM; case MESA_FORMAT_R8G8B8A8_SNORM: - return PIPE_FORMAT_R8G8B8A8_SNORM; + return PIPE_FORMAT_RGBA_SNORM; + case MESA_FORMAT_A8B8G8R8_SNORM: + return PIPE_FORMAT_ABGR_SNORM; case MESA_FORMAT_A_SNORM8: return PIPE_FORMAT_A8_SNORM; @@ -400,9 +404,13 @@ st_mesa_format_to_pipe_format(struct st_context *st, mesa_format mesaFormat) case MESA_FORMAT_B5G5R5X1_UNORM: return PIPE_FORMAT_B5G5R5X1_UNORM; case MESA_FORMAT_R8G8B8X8_SNORM: - return PIPE_FORMAT_R8G8B8X8_SNORM; + return PIPE_FORMAT_RGBX_SNORM; + case MESA_FORMAT_X8B8G8R8_SNORM: + return PIPE_FORMAT_XBGR_SNORM; case MESA_FORMAT_R8G8B8X8_SRGB: - return PIPE_FORMAT_R8G8B8X8_SRGB; + return PIPE_FORMAT_RGBX_SRGB; + case MESA_FORMAT_X8B8G8R8_SRGB: + return PIPE_FORMAT_XBGR_SRGB; case MESA_FORMAT_RGBX_UINT8: return PIPE_FORMAT_R8G8B8X8_UINT; case MESA_FORMAT_RGBX_SINT8: @@ -428,6 +436,8 @@ st_mesa_format_to_pipe_format(struct st_context *st, mesa_format mesaFormat) case MESA_FORMAT_B8G8R8X8_SRGB: return PIPE_FORMAT_B8G8R8X8_SRGB; + case MESA_FORMAT_X8R8G8B8_SRGB: + return PIPE_FORMAT_XRGB_SRGB; /* ETC2 formats are emulated as uncompressed ones. * The destination formats mustn't be changed, because they are also @@ -564,10 +574,14 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_L_SRGB8; case PIPE_FORMAT_R8G8B8_SRGB: return MESA_FORMAT_BGR_SRGB8; - case PIPE_FORMAT_A8B8G8R8_SRGB: + case PIPE_FORMAT_ABGR_SRGB: return MESA_FORMAT_A8B8G8R8_SRGB; - case PIPE_FORMAT_B8G8R8A8_SRGB: + case PIPE_FORMAT_RGBA_SRGB: + return MESA_FORMAT_R8G8B8A8_SRGB; + case PIPE_FORMAT_BGRA_SRGB: return MESA_FORMAT_B8G8R8A8_SRGB; + case PIPE_FORMAT_ARGB_SRGB: + return MESA_FORMAT_A8R8G8B8_SRGB; case PIPE_FORMAT_R32G32B32A32_FLOAT: return MESA_FORMAT_RGBA_FLOAT32; case PIPE_FORMAT_R16G16B16A16_FLOAT: @@ -758,8 +772,10 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_R8G8_SNORM; case PIPE_FORMAT_GR88_SNORM: return MESA_FORMAT_G8R8_SNORM; - case PIPE_FORMAT_R8G8B8A8_SNORM: + case PIPE_FORMAT_RGBA_SNORM: return MESA_FORMAT_R8G8B8A8_SNORM; + case PIPE_FORMAT_ABGR_SNORM: + return MESA_FORMAT_A8B8G8R8_SNORM; case PIPE_FORMAT_A8_SNORM: return MESA_FORMAT_A_SNORM8; @@ -804,10 +820,14 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_B4G4R4X4_UNORM; case PIPE_FORMAT_B5G5R5X1_UNORM: return MESA_FORMAT_B5G5R5X1_UNORM; - case PIPE_FORMAT_R8G8B8X8_SNORM: + case PIPE_FORMAT_RGBX_SNORM: return MESA_FORMAT_R8G8B8X8_SNORM; - case PIPE_FORMAT_R8G8B8X8_SRGB: + case PIPE_FORMAT_XBGR_SNORM: + return MESA_FORMAT_X8B8G8R8_SNORM; + case PIPE_FORMAT_RGBX_SRGB: return
Re: [Mesa-dev] [PATCH] glsl: do not emit error for non written varyings on OpenGL ES
On 09/16/2014 04:21 AM, Tapani Pälli wrote:
Patch fixes following test case from 'shaders-with-varyings' WebGL
conformance suite: vertex shader with unused varying and fragment
shader with used varying must succeed
Oh bother. Using the same rationale as before, could we get a warning
from the linker?
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/link_varyings.cpp | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 54ceae1..fb2d88c 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -1451,7 +1451,7 @@ assign_varying_locations(struct gl_context *ctx,
if (var var-data.mode == ir_var_shader_in
var-data.is_unmatched_generic_inout) {
-if (prog-Version = 120) {
+if (prog-Version = 120 !prog-IsES) {
/* On page 25 (page 31 of the PDF) of the GLSL 1.20 spec:
*
* Only those varying variables used (i.e. read) in
@@ -1463,6 +1463,16 @@ assign_varying_locations(struct gl_context *ctx,
* We interpret this text as meaning that the VS must
* write the variable for the FS to read it. See
* glsl1-varying read but not written in piglit.
+*
+* Note that this is not an error on OpenGL ES:
+*
+* On Page 91 (Page 97 of the PDF) of the GLSL ES 1.0 spec:
+*
+* If the vertex shader declares but doesn't write to a
+* varying and the fragment shader declares and reads it,
+* is this and error?
+*
+* RESOLUTION: No.
*/
linker_error(prog, %s shader varying %s not written
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TGSI and Tessellation Control Shader outputs
OK, so just to summarize: The approach suggested by Roland is to have the outputs be one-dimensional and only representing the current invocation's per-vertex outputs. Each invocation would also get access to other invocations' per-vertex outputs via a 2d input array. So a shader might look something like TESSC DECL IN[][0], POSITION (input patch's per-vertex position) DECL IN[][1], GENERIC (input patch's per-vertex generic attribute) DECL IN[][2], TCS_POSITION (output patch's per-vertex position) DECL IN[][3], TCS_OUTPUT (output patch's per-vertex generic attribute) DECL OUT[0], POSITION DECL OUT[1], GENERIC DECL OUT[2], PATCH And then anything written to OUT[0] would be aliased via IN[][2]. Roland, does that sound right? This seems kinda nasty that there are going to be 2 types of position/pointsize/clipdistance inputs -- do you have a better suggestion for handling that? I still sorta like my hacky idea of declaring the outputs 1-dimensionally, but then allowing them as sources and reading them as though they were 2d... Although that still doesn't deal with a foo[gl_InvocationID] += 1 type of situation very gracefully. On Mon, Sep 1, 2014 at 1:47 PM, Roland Scheidegger srol...@vmware.com wrote: Am 01.09.2014 18:53, schrieb Ilia Mirkin: On Mon, Sep 1, 2014 at 12:47 PM, Roland Scheidegger srol...@vmware.com wrote: Am 01.09.2014 18:19, schrieb Ilia Mirkin: On Mon, Sep 1, 2014 at 12:00 PM, Roland Scheidegger srol...@vmware.com wrote: Am 29.08.2014 22:44, schrieb Ilia Mirkin: Hello, I've been thinking a bit about how to properly implement TCS outputs in TGSI. As a quick reminder, there are per-vertex (i.e. invocation) and per-patch outputs in TCS. And while you can only write to the current invocation's per-vertex outputs, you can read from any of them. (With barrier() used to synchronize invocations.) Per-patch outputs map quite nicely onto the existing infrastructure, so the rest of the questions will be about per-vertex outputs. One can represent per-vertex outputs as 2D output arrays. That means support for them needs to be added all over (which I've actually done, so I'm not complaining about the extra work but rather asking if it's a good idea). And then you might have DCL OUT[][0], GENERIC MOV ADDR[1].x, SV[0] /* invocation id */ MOV OUT[ADDR[1].x][0], TEMP[0] /* store value */ BARRIER MOV TEMP[0], OUT[3][0] /* read output from invocation == 3 */ The advantage here is that it's all nice and consistent. However the disadvantage is that we have to add a totally useless read of the invocation id and use it as a relative index for the store. At least the nvidia shaders don't even have a way of writing other invocations' data even if they wanted to (without resorting to global memory accesses). So it's complicating all sorts of logic for apparently no real benefit. Another approach might be to bypass the invocation id on storing the output, but using it on reads. For example code like DCL OUT[0], GENERIC MOV OUT[0], TEMP[0] BARRIER MOV TEMP[0], OUT[3][0] This avoids having to teach tgsi about 2d outputs (esp reladdr ones). This seems a lot simpler, but it ignores the gl_InvocationID indexing that happens when writing the output. However I don't think that's so bad. It also means that reads and writes are interpreted a little differently for OUT's, but that doesn't seem so bad either. Thoughts? I think in the second case though it should be required to declare the inputs separately. It sounds to me like at least on nv50 the access works different in any case (even if the actual data accessed is the same). Though I have no idea how other hw handles this, but in any case On nvc0 there are load and store instructions (nv50 is a little different, but it also doesn't support tess). When storing, there's no way to provide it the invocation offset. When loading, there is. hull shader from d3d11 uses 2d addressed inputs but 1d addressed outputs too - https://urldefense.proofpoint.com/v1/url?u=http://msdn.microsoft.com/en-us/library/windows/desktop/hh447211%28v%3Dvs.85%29.aspxk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=nYcD1FcBz0UnqCOOj%2B2wurf%2F3rjQNi1sQmGxNT2xfPQ%3D%0As=f81f9c26e90f61f613539e68b7a0cfe070451d77be957c6dc28b2107b03fe497 (though I don't know how that looks like at the ddi level). Probably GL Hmmm... well from a quick read of it, they've bypassed this problem by creating substages with inputs consuming previous stages' outputs. Doesn't exactly look like this to me. They still have this both as input and output in multiple stages. used 2d outputs because it indeed looks more consistent (or perhaps some extension could lift the restriction that only the current invocation be written, though I'm not sure if that would ever make sense). So I think if it doesn't actually make sense to try writing to other outputs, option 2) makes more sense. I think though in this case
Re: [Mesa-dev] [RFC PATCH] mesa: Delete VAO _MaxElement code and index buffer bounds checking.
On 09/15/2014 06:00 PM, Roland Scheidegger wrote: Am 15.09.2014 08:31, schrieb Kenneth Graunke: Fredrik's implementation of ARB_vertex_attrib_binding introduced new gl_vertex_attrib_array and gl_vertex_buffer_binding structures, and converted Mesa's older gl_client_array to be derived state. Ultimately, we'd like to drop gl_client_array and use those structures directly. One hitch is that gl_client_array::_MaxElement doesn't correspond to either structure (unlike every other field), so we'd have to figure out where to store it. The _MaxElement computation uses values from both structures, so it doesn't really belong in either place. We could put it in the VAO, but we'd have to pass it around everywhere. It turns out that it's only used when ctx-Const.CheckArrayBounds is set, which is only set by the (rarely used) classic swrast driver. It appears that drivers/x11 used to set it as well, which was intended to avoid segmentation faults on out-of-bounds memory access in the X server (probably for indirect GLX clients). However, ajax deleted that code in 2010 (commit 1ccef926be46dce3b6b5c76e812e2fae4e205ce7). The bounds checking apparently doesn't actually work, either. Non-VBO attributes arbitrarily set _MaxElement to 2 * 1000 * 1000 * 1000. vbo_save_draw and vbo_exec_draw remark /* ??? */ when setting it, and the i965 code contains a comment noting that _MaxElement is often bogus. Well there's not much you can do for the non-vbo case, since you simply don't know how large that buffer pointed to by that client pointer you were given by the app is... Given that the code is complex, rarely used, and dubiously functional, it doesn't seem worth maintaining going forward. This patch drops it. This will probably mean the classic swrast driver may begin crashing on out of bounds vertex buffer access in some cases, but I believe that is allowed by OpenGL (and probably happened for non-VBO accesses anyway). There do not appear to be any Piglit regressions, either. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/dri/i965/brw_draw_upload.c | 5 +-- src/mesa/drivers/dri/swrast/swrast.c| 3 -- src/mesa/main/api_validate.c| 66 - src/mesa/main/arrayobj.c| 46 src/mesa/main/arrayobj.h| 4 -- src/mesa/main/attrib.c | 1 - src/mesa/main/context.c | 3 -- src/mesa/main/mtypes.h | 10 - src/mesa/main/state.c | 5 --- src/mesa/main/varray.c | 9 +--- src/mesa/main/varray.h | 33 --- src/mesa/vbo/vbo_exec_array.c | 26 +++- src/mesa/vbo/vbo_exec_draw.c| 2 - src/mesa/vbo/vbo_save_draw.c| 1 - src/mesa/vbo/vbo_split_copy.c | 1 - 15 files changed, 9 insertions(+), 206 deletions(-) Hi Brian, Roland, Eric, all... What do you think of this idea? Good idea? Terrible idea? In theory, this seems like a reasonable idea for software drivers, but it doesn't appear that softpipe/llvmpipe use this code, so I'm not sure if it's worth maintaining just for swrast... draw does its own validation (according to more strict d3d10 rules, even), as long as everything comes in nice buffers with known sizes this isn't much of a problem (and it doesn't need to be done as a separate pass). I am pretty sure though any app used to be able to crash the X server (when using indirect rendering) when not doing bounds checking pretty easily, but maybe that vanished at some point somehow (luckily, I never had to look at indirect rendering for years...). I think at some point it was also useful for debugging (so you could more easily see where that weird segfault was coming from) though again of course it did nothing for non-vbo arrays. classic swrast could probably reimplement this on its own if nothing else uses it anymore. Of course real hw nowadays you just give the buffer sizes and the hw will make sure nothing is fetched outside bounds on its own. So, for me dropping this looks ok, but I'm not really working much in that area nowadays. As Eric pointed out, it doesn't look like there's any glDrawElements or VBO code getting used in the X server (the glDrawElements call gets unwound in the client-side GLX code, AFAICT). As it is, the CheckArrayBounds code checks for invalid array indexes at draw-validation time. If a bad index is found, the whole draw is discarded. Alternately, a driver/device can discard individual primitives while drawing if an array index is out of bounds (if the vertex fetch fails, skip the prim). The TnL (src/tnl/) module has never had any support for per-vertex bounds checking but I believe all the gallium drivers (should) handle it. I think this behavior is what's expected of OpenGL/Direct3D nowadays so the
Re: [Mesa-dev] TGSI and Tessellation Control Shader outputs
On Tue, Sep 16, 2014 at 5:42 PM, Ilia Mirkin imir...@alum.mit.edu wrote: OK, so just to summarize: The approach suggested by Roland is to have the outputs be one-dimensional and only representing the current invocation's per-vertex outputs. Each invocation would also get access to other invocations' per-vertex outputs via a 2d input array. So a shader might look something like TESSC DECL IN[][0], POSITION (input patch's per-vertex position) DECL IN[][1], GENERIC (input patch's per-vertex generic attribute) DECL IN[][2], TCS_POSITION (output patch's per-vertex position) DECL IN[][3], TCS_OUTPUT (output patch's per-vertex generic attribute) DECL OUT[0], POSITION DECL OUT[1], GENERIC DECL OUT[2], PATCH And then anything written to OUT[0] would be aliased via IN[][2]. Roland, does that sound right? This seems kinda nasty that there are going to be 2 types of position/pointsize/clipdistance inputs -- do you have a better suggestion for handling that? The output-as-input arrays can be declared as system values (SV), then you don't need to duplicate semantic names. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/37] Geometry shader support in Sandy Bridge
On Tue, Sep 16, 2014 at 3:07 AM, Iago Toral Quiroga ito...@igalia.com wrote: On mar, 2014-09-16 at 01:09 -0700, Kenneth Graunke wrote: On Thursday, August 14, 2014 01:11:32 PM Iago Toral Quiroga wrote: Hi, this series brings support for geometry shaders in Sandy Bridge (gen6) and is combined work from Samuel and myself. I've looked over most of the series, and everything looks good (though I didn't have time to look at it in as much detail as I'd hoped). It sounds like Jordan's reviewed quite a bit of it. That's great, thanks Kenneth. I think Jordan only managed to review the first 6 patches so far. Feel free to add my ack on the series: Acked-by: Kenneth Graunke kenn...@whitecape.org Will do. I think you're probably good to push it at this point. Fantastic work, as always :) Thanks! :) I think Jordan still wanted to review the patches, so I'll wait for his ok before pushing anything. Sorry. I'll get back to this today. So far, for 7-15 you can add: Reviewed-by: Jordan Justen jordan.l.jus...@intel.com Ken: Iago seems to have updated i965/gen6/gs: Implement GS_OPCODE_FF_SYNC. i965/gen6/gs: Implement GS_OPCODE_SET_DWORD_2. At git://github.com/samuelig/mesa.git on the gs-support-snb-for-submission-02092014 branch based on your suggestions in case you wanted to verify the changes. -Jordan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TGSI and Tessellation Control Shader outputs
On Tue, Sep 16, 2014 at 12:29 PM, Marek Olšák mar...@gmail.com wrote: On Tue, Sep 16, 2014 at 5:42 PM, Ilia Mirkin imir...@alum.mit.edu wrote: OK, so just to summarize: The approach suggested by Roland is to have the outputs be one-dimensional and only representing the current invocation's per-vertex outputs. Each invocation would also get access to other invocations' per-vertex outputs via a 2d input array. So a shader might look something like TESSC DECL IN[][0], POSITION (input patch's per-vertex position) DECL IN[][1], GENERIC (input patch's per-vertex generic attribute) DECL IN[][2], TCS_POSITION (output patch's per-vertex position) DECL IN[][3], TCS_OUTPUT (output patch's per-vertex generic attribute) DECL OUT[0], POSITION DECL OUT[1], GENERIC DECL OUT[2], PATCH And then anything written to OUT[0] would be aliased via IN[][2]. Roland, does that sound right? This seems kinda nasty that there are going to be 2 types of position/pointsize/clipdistance inputs -- do you have a better suggestion for handling that? The output-as-input arrays can be declared as system values (SV), then you don't need to duplicate semantic names. OK, that sounds reasonable. And what do you guys think about reading directly from per-patch outputs? Or should they also be mirrored as SV's? We definitely need something since it's shared between invocations and synchronizable using barrier. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: do not emit error for non written varyings on OpenGL ES
On 09/16/2014 05:48 PM, Ian Romanick wrote:
On 09/16/2014 04:21 AM, Tapani Pälli wrote:
Patch fixes following test case from 'shaders-with-varyings' WebGL
conformance suite: vertex shader with unused varying and fragment
shader with used varying must succeed
Oh bother. Using the same rationale as before, could we get a warning
from the linker?
Sure, will send a v2 patch with a warning.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/link_varyings.cpp | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 54ceae1..fb2d88c 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -1451,7 +1451,7 @@ assign_varying_locations(struct gl_context *ctx,
if (var var-data.mode == ir_var_shader_in
var-data.is_unmatched_generic_inout) {
-if (prog-Version = 120) {
+if (prog-Version = 120 !prog-IsES) {
/* On page 25 (page 31 of the PDF) of the GLSL 1.20 spec:
*
* Only those varying variables used (i.e. read) in
@@ -1463,6 +1463,16 @@ assign_varying_locations(struct gl_context *ctx,
* We interpret this text as meaning that the VS must
* write the variable for the FS to read it. See
* glsl1-varying read but not written in piglit.
+*
+* Note that this is not an error on OpenGL ES:
+*
+* On Page 91 (Page 97 of the PDF) of the GLSL ES 1.0 spec:
+*
+* If the vertex shader declares but doesn't write to a
+* varying and the fragment shader declares and reads it,
+* is this and error?
+*
+* RESOLUTION: No.
*/
linker_error(prog, %s shader varying %s not written
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TGSI and Tessellation Control Shader outputs
On Tue, Sep 16, 2014 at 6:41 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Tue, Sep 16, 2014 at 12:29 PM, Marek Olšák mar...@gmail.com wrote: On Tue, Sep 16, 2014 at 5:42 PM, Ilia Mirkin imir...@alum.mit.edu wrote: OK, so just to summarize: The approach suggested by Roland is to have the outputs be one-dimensional and only representing the current invocation's per-vertex outputs. Each invocation would also get access to other invocations' per-vertex outputs via a 2d input array. So a shader might look something like TESSC DECL IN[][0], POSITION (input patch's per-vertex position) DECL IN[][1], GENERIC (input patch's per-vertex generic attribute) DECL IN[][2], TCS_POSITION (output patch's per-vertex position) DECL IN[][3], TCS_OUTPUT (output patch's per-vertex generic attribute) DECL OUT[0], POSITION DECL OUT[1], GENERIC DECL OUT[2], PATCH And then anything written to OUT[0] would be aliased via IN[][2]. Roland, does that sound right? This seems kinda nasty that there are going to be 2 types of position/pointsize/clipdistance inputs -- do you have a better suggestion for handling that? The output-as-input arrays can be declared as system values (SV), then you don't need to duplicate semantic names. OK, that sounds reasonable. And what do you guys think about reading directly from per-patch outputs? Or should they also be mirrored as SV's? We definitely need something since it's shared between invocations and synchronizable using barrier. Alternatively, you can add another TGSI file for these kinds of variables. I personally don't care much as long as it doesn't get messy. I'll probably use on-chip shared memory for the outputs and load/store instructions for accessing them, so if they are inputs or outputs in TGSI doesn't make much difference for me. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH] mesa: Delete VAO _MaxElement code and index buffer bounds checking.
Am 16.09.2014 17:48, schrieb Brian Paul: On 09/15/2014 06:00 PM, Roland Scheidegger wrote: Am 15.09.2014 08:31, schrieb Kenneth Graunke: Fredrik's implementation of ARB_vertex_attrib_binding introduced new gl_vertex_attrib_array and gl_vertex_buffer_binding structures, and converted Mesa's older gl_client_array to be derived state. Ultimately, we'd like to drop gl_client_array and use those structures directly. One hitch is that gl_client_array::_MaxElement doesn't correspond to either structure (unlike every other field), so we'd have to figure out where to store it. The _MaxElement computation uses values from both structures, so it doesn't really belong in either place. We could put it in the VAO, but we'd have to pass it around everywhere. It turns out that it's only used when ctx-Const.CheckArrayBounds is set, which is only set by the (rarely used) classic swrast driver. It appears that drivers/x11 used to set it as well, which was intended to avoid segmentation faults on out-of-bounds memory access in the X server (probably for indirect GLX clients). However, ajax deleted that code in 2010 (commit 1ccef926be46dce3b6b5c76e812e2fae4e205ce7). The bounds checking apparently doesn't actually work, either. Non-VBO attributes arbitrarily set _MaxElement to 2 * 1000 * 1000 * 1000. vbo_save_draw and vbo_exec_draw remark /* ??? */ when setting it, and the i965 code contains a comment noting that _MaxElement is often bogus. Well there's not much you can do for the non-vbo case, since you simply don't know how large that buffer pointed to by that client pointer you were given by the app is... Given that the code is complex, rarely used, and dubiously functional, it doesn't seem worth maintaining going forward. This patch drops it. This will probably mean the classic swrast driver may begin crashing on out of bounds vertex buffer access in some cases, but I believe that is allowed by OpenGL (and probably happened for non-VBO accesses anyway). There do not appear to be any Piglit regressions, either. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/dri/i965/brw_draw_upload.c | 5 +-- src/mesa/drivers/dri/swrast/swrast.c| 3 -- src/mesa/main/api_validate.c| 66 - src/mesa/main/arrayobj.c| 46 src/mesa/main/arrayobj.h| 4 -- src/mesa/main/attrib.c | 1 - src/mesa/main/context.c | 3 -- src/mesa/main/mtypes.h | 10 - src/mesa/main/state.c | 5 --- src/mesa/main/varray.c | 9 +--- src/mesa/main/varray.h | 33 --- src/mesa/vbo/vbo_exec_array.c | 26 +++- src/mesa/vbo/vbo_exec_draw.c| 2 - src/mesa/vbo/vbo_save_draw.c| 1 - src/mesa/vbo/vbo_split_copy.c | 1 - 15 files changed, 9 insertions(+), 206 deletions(-) Hi Brian, Roland, Eric, all... What do you think of this idea? Good idea? Terrible idea? In theory, this seems like a reasonable idea for software drivers, but it doesn't appear that softpipe/llvmpipe use this code, so I'm not sure if it's worth maintaining just for swrast... draw does its own validation (according to more strict d3d10 rules, even), as long as everything comes in nice buffers with known sizes this isn't much of a problem (and it doesn't need to be done as a separate pass). I am pretty sure though any app used to be able to crash the X server (when using indirect rendering) when not doing bounds checking pretty easily, but maybe that vanished at some point somehow (luckily, I never had to look at indirect rendering for years...). I think at some point it was also useful for debugging (so you could more easily see where that weird segfault was coming from) though again of course it did nothing for non-vbo arrays. classic swrast could probably reimplement this on its own if nothing else uses it anymore. Of course real hw nowadays you just give the buffer sizes and the hw will make sure nothing is fetched outside bounds on its own. So, for me dropping this looks ok, but I'm not really working much in that area nowadays. As Eric pointed out, it doesn't look like there's any glDrawElements or VBO code getting used in the X server (the glDrawElements call gets unwound in the client-side GLX code, AFAICT). As it is, the CheckArrayBounds code checks for invalid array indexes at draw-validation time. If a bad index is found, the whole draw is discarded. Alternately, a driver/device can discard individual primitives while drawing if an array index is out of bounds (if the vertex fetch fails, skip the prim). The TnL (src/tnl/) module has never had any support for per-vertex bounds checking but I believe all the gallium drivers
[Mesa-dev] [PATCH v2] glsl: do not emit error for non written varyings on OpenGL ES
Patch fixes following test case from 'shaders-with-varyings' WebGL
conformance suite: vertex shader with unused varying and fragment
shader with used varying must succeed
v2: emit still a warning if the condition happens (Ian)
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/link_varyings.cpp | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 54ceae1..56e68b7 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -1451,7 +1451,22 @@ assign_varying_locations(struct gl_context *ctx,
if (var var-data.mode == ir_var_shader_in
var-data.is_unmatched_generic_inout) {
-if (prog-Version = 120) {
+if (prog-IsES) {
+ /*
+* On Page 91 (Page 97 of the PDF) of the GLSL ES 1.0 spec:
+*
+* If the vertex shader declares but doesn't write to a
+* varying and the fragment shader declares and reads it,
+* is this an error?
+*
+* RESOLUTION: No.
+*/
+ linker_warning(prog, %s shader varying %s not written
+ by %s shader\n.,
+ _mesa_shader_stage_to_string(consumer-Stage),
+ var-name,
+ _mesa_shader_stage_to_string(producer-Stage));
+} else if (prog-Version = 120) {
/* On page 25 (page 31 of the PDF) of the GLSL 1.20 spec:
*
* Only those varying variables used (i.e. read) in
@@ -1464,7 +1479,6 @@ assign_varying_locations(struct gl_context *ctx,
* write the variable for the FS to read it. See
* glsl1-varying read but not written in piglit.
*/
-
linker_error(prog, %s shader varying %s not written
by %s shader\n.,
_mesa_shader_stage_to_string(consumer-Stage),
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TGSI and Tessellation Control Shader outputs
Am 16.09.2014 18:41, schrieb Ilia Mirkin: On Tue, Sep 16, 2014 at 12:29 PM, Marek Olšák mar...@gmail.com wrote: On Tue, Sep 16, 2014 at 5:42 PM, Ilia Mirkin imir...@alum.mit.edu wrote: OK, so just to summarize: The approach suggested by Roland is to have the outputs be one-dimensional and only representing the current invocation's per-vertex outputs. Each invocation would also get access to other invocations' per-vertex outputs via a 2d input array. So a shader might look something like TESSC DECL IN[][0], POSITION (input patch's per-vertex position) DECL IN[][1], GENERIC (input patch's per-vertex generic attribute) DECL IN[][2], TCS_POSITION (output patch's per-vertex position) DECL IN[][3], TCS_OUTPUT (output patch's per-vertex generic attribute) DECL OUT[0], POSITION DECL OUT[1], GENERIC DECL OUT[2], PATCH And then anything written to OUT[0] would be aliased via IN[][2]. Roland, does that sound right? This seems kinda nasty that there are going to be 2 types of position/pointsize/clipdistance inputs -- do you have a better suggestion for handling that? The output-as-input arrays can be declared as system values (SV), then you don't need to duplicate semantic names. OK, that sounds reasonable. And what do you guys think about reading directly from per-patch outputs? Or should they also be mirrored as SV's? We definitely need something since it's shared between invocations and synchronizable using barrier. I guess reading back from outputs is ok then (I probably said something different in the past?), this is usually allowed in tgsi. I guess the difference is that if a driver can't do it you can't just lower it to temp writes + output write later cause it would cause the synchronization to not work (though, you could write any output write deferred to a temp at sync time). My guess is that if you'd write to some output and read back from it, you wouldn't need any sync, but if you'd write to some output and read it back via the input, you'd be required to sync? Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TGSI and Tessellation Control Shader outputs
On Tue, Sep 16, 2014 at 7:31 PM, Roland Scheidegger srol...@vmware.com wrote: Am 16.09.2014 18:41, schrieb Ilia Mirkin: On Tue, Sep 16, 2014 at 12:29 PM, Marek Olšák mar...@gmail.com wrote: On Tue, Sep 16, 2014 at 5:42 PM, Ilia Mirkin imir...@alum.mit.edu wrote: OK, so just to summarize: The approach suggested by Roland is to have the outputs be one-dimensional and only representing the current invocation's per-vertex outputs. Each invocation would also get access to other invocations' per-vertex outputs via a 2d input array. So a shader might look something like TESSC DECL IN[][0], POSITION (input patch's per-vertex position) DECL IN[][1], GENERIC (input patch's per-vertex generic attribute) DECL IN[][2], TCS_POSITION (output patch's per-vertex position) DECL IN[][3], TCS_OUTPUT (output patch's per-vertex generic attribute) DECL OUT[0], POSITION DECL OUT[1], GENERIC DECL OUT[2], PATCH And then anything written to OUT[0] would be aliased via IN[][2]. Roland, does that sound right? This seems kinda nasty that there are going to be 2 types of position/pointsize/clipdistance inputs -- do you have a better suggestion for handling that? The output-as-input arrays can be declared as system values (SV), then you don't need to duplicate semantic names. OK, that sounds reasonable. And what do you guys think about reading directly from per-patch outputs? Or should they also be mirrored as SV's? We definitely need something since it's shared between invocations and synchronizable using barrier. I guess reading back from outputs is ok then (I probably said something different in the past?), this is usually allowed in tgsi. I guess the difference is that if a driver can't do it you can't just lower it to temp writes + output write later cause it would cause the synchronization to not work (though, you could write any output write deferred to a temp at sync time). My guess is that if you'd write to some output and read back from it, you wouldn't need any sync, but if you'd write to some output and read it back via the input, you'd be required to sync? AFAIK, the sync is required if you access outputs that other shaders have written. If you only access outputs that the same shader has written, there is no sync needed. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TGSI and Tessellation Control Shader outputs
Am 16.09.2014 19:40, schrieb Marek Olšák: On Tue, Sep 16, 2014 at 7:31 PM, Roland Scheidegger srol...@vmware.com wrote: Am 16.09.2014 18:41, schrieb Ilia Mirkin: On Tue, Sep 16, 2014 at 12:29 PM, Marek Olšák mar...@gmail.com wrote: On Tue, Sep 16, 2014 at 5:42 PM, Ilia Mirkin imir...@alum.mit.edu wrote: OK, so just to summarize: The approach suggested by Roland is to have the outputs be one-dimensional and only representing the current invocation's per-vertex outputs. Each invocation would also get access to other invocations' per-vertex outputs via a 2d input array. So a shader might look something like TESSC DECL IN[][0], POSITION (input patch's per-vertex position) DECL IN[][1], GENERIC (input patch's per-vertex generic attribute) DECL IN[][2], TCS_POSITION (output patch's per-vertex position) DECL IN[][3], TCS_OUTPUT (output patch's per-vertex generic attribute) DECL OUT[0], POSITION DECL OUT[1], GENERIC DECL OUT[2], PATCH And then anything written to OUT[0] would be aliased via IN[][2]. Roland, does that sound right? This seems kinda nasty that there are going to be 2 types of position/pointsize/clipdistance inputs -- do you have a better suggestion for handling that? The output-as-input arrays can be declared as system values (SV), then you don't need to duplicate semantic names. OK, that sounds reasonable. And what do you guys think about reading directly from per-patch outputs? Or should they also be mirrored as SV's? We definitely need something since it's shared between invocations and synchronizable using barrier. I guess reading back from outputs is ok then (I probably said something different in the past?), this is usually allowed in tgsi. I guess the difference is that if a driver can't do it you can't just lower it to temp writes + output write later cause it would cause the synchronization to not work (though, you could write any output write deferred to a temp at sync time). My guess is that if you'd write to some output and read back from it, you wouldn't need any sync, but if you'd write to some output and read it back via the input, you'd be required to sync? AFAIK, the sync is required if you access outputs that other shaders have written. If you only access outputs that the same shader has written, there is no sync needed. Marek Well that's for OpenGL because it doesn't have different inputs and outputs. But we could easily require sync must be done if we allow the (separate) output to be read accessed. It kinda seems awkward to have an input which you must sync before accessing it except in case the dimension index happens to match the current invocation... Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/vec4: slightly improve insn dumping with no srcs
On Tuesday, September 09, 2014 07:55:28 PM Chris Forbes wrote:
Previously, we would get a trailing ', ' which looked strange.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index cda097f..1d1e29d 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1337,7 +1337,10 @@ vec4_visitor::dump_instruction(backend_instruction
*be_inst, FILE *file)
if (inst-dst.writemask 8)
fprintf(file, w);
}
- fprintf(file, :%s, , brw_reg_type_letters(inst-dst.type));
+ fprintf(file, :%s, brw_reg_type_letters(inst-dst.type));
+
+ if (inst-src[0].file != BAD_FILE)
+ fprintf(file, , );
for (int i = 0; i 3 inst-src[i].file != BAD_FILE; i++) {
if (inst-src[i].negate)
Both are:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: fix prog_optimize.c assertions triggered by SWZ opcode
The SWZ instruction can have swizzle terms 4 (SWIZZLE_ZERO, SWIZZLE_ONE).
These swizzle terms caused a few assertions to fail.
This started happening after the commit mesa: Actually use the Mesa IR
optimizer for ARB programs. when replaying some apitrace files.
A new piglit test (tests/asmparsertest/shaders/ARBfp1.0/swz-08.txt)
exercises this.
Cc: 10.3 mesa-sta...@lists.freedesktop.org
---
src/mesa/program/prog_optimize.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/mesa/program/prog_optimize.c b/src/mesa/program/prog_optimize.c
index 08c1c30..60530eb 100644
--- a/src/mesa/program/prog_optimize.c
+++ b/src/mesa/program/prog_optimize.c
@@ -114,7 +114,6 @@ get_src_arg_mask(const struct prog_instruction *inst,
read_mask = 0x0;
for (comp = 0; comp 4; ++comp) {
const GLuint coord = GET_SWZ(inst-SrcReg[arg].Swizzle, comp);
- ASSERT(coord 4);
if (channel_mask (1 comp) coord = SWIZZLE_W)
read_mask |= 1 coord;
}
@@ -284,11 +283,11 @@ _mesa_remove_dead_code_global(struct gl_program *prog)
for (comp = 0; comp 4; comp++) {
const GLuint swz = GET_SWZ(inst-SrcReg[j].Swizzle, comp);
- ASSERT(swz 4);
- if ((read_mask (1 swz)) == 0)
- continue;
- if (swz = SWIZZLE_W)
+ if (swz = SWIZZLE_W) {
+ if ((read_mask (1 swz)) == 0)
+ continue;
tempRead[index][swz] = GL_TRUE;
+ }
}
}
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 1/1] egl/drm: expose KHR_image_pixmap extension
Hello gents, Can anyone spare a couple of minutes and review this patch ? Thanks Emil On 03/09/14 21:43, Andreas Pokorny wrote: This changes enables EGL_KHR_image_pixmap in the egl drm platform, which is implemented there but has not been advertised yet. Signed-off-by: Andreas Pokorny andreas.poko...@canonical.com --- src/egl/drivers/dri2/platform_drm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/egl/drivers/dri2/platform_drm.c b/src/egl/drivers/dri2/platform_drm.c index e272beb..a39f8ae 100644 --- a/src/egl/drivers/dri2/platform_drm.c +++ b/src/egl/drivers/dri2/platform_drm.c @@ -681,6 +681,7 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp) i + 1, EGL_WINDOW_BIT, attr_list, NULL); } + disp-Extensions.KHR_image_pixmap = EGL_TRUE; if (dri2_dpy-dri2) disp-Extensions.EXT_buffer_age = EGL_TRUE; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: detect LLVM patch level when built via cmake
On 09/09/14 19:56, Emil Velikov wrote:
On 09/09/14 16:26, Tom Stellard wrote:
On Sat, Sep 06, 2014 at 01:43:55AM +1000, Jonathan Gray wrote:
In LLVM 3.4.1 and 3.4.2 the patch level was only set in config.h when
LLVM was built via autoconf and not when it was built with cmake.
Fall back to retrieving the patch level from llvm-config --version to
handle this case.
We should extract LLVM_VERSION_PATH from $LLVM_VERSION and then we won't
have to worry about which config file it is in.
I believe you meant VERSION_PATCH above ? Indeed that would nice thing to have
but I doubt that it will get back-ported to the llvm 3.4 branch.
Are there any plans on making a 3.4.3 release ? Would be nice to have it fixed
at the root rather than adding the hack in mesa :)
Tom can you please let us know if there are any plans for llvm 3.4.3 ?
Would prefer to avoid having this hack in mesa :)
Thanks
Emil
-Emil
-Tom
Cc: 10.2 10.3 mesa-sta...@lists.freedesktop.org
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
configure.ac | 9 +
1 file changed, 9 insertions(+)
diff --git a/configure.ac b/configure.ac
index 99ae6ba..98cd938 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1705,6 +1705,15 @@ if test x$enable_gallium_llvm = xyes; then
[#include ${LLVM_INCLUDEDIR}/llvm/Config/config.h],
LLVM_VERSION_PATCH=0) dnl Default if LLVM_VERSION_PATCH not
found
+dnl In LLVM 3.4.1 and 3.4.2 the patch level was only set in
config.h
+dnl for autoconf builds and not cmake builds
+if test $LLVM_VERSION_PATCH -eq 0; then
+LLVM_VERSION_PATCH=`echo $LLVM_VERSION | cut -d. -f3`
+if test -z $LLVM_VERSION_PATCH; then
+LLVM_VERSION_PATCH=0
+fi
+fi
+
if test -n ${LLVM_VERSION_MAJOR}; then
LLVM_VERSION_INT=${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}
else
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83951] New: Account Request
https://bugs.freedesktop.org/show_bug.cgi?id=83951 Priority: medium Bug ID: 83951 Assignee: mesa-dev@lists.freedesktop.org Summary: Account Request Severity: normal Classification: Unclassified OS: All Reporter: s...@vmware.com Hardware: Other Status: NEW Version: unspecified Component: Other Product: Mesa Created attachment 106391 -- https://bugs.freedesktop.org/attachment.cgi?id=106391action=edit ssh RSA and PGP public keys Requesting push access to mesa/vmwgfx -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] i915: Fix black buffers when importing prime fds
Another humble ping.
I realise that i915 hardware is not top priority yet 5 minutes of someone
experienced with the driver will be greatly appreciated :)
Cheers,
Emil
On 05/09/14 16:20, Emil Velikov wrote:
Hmm the previous cover letter was not attached to any patches :\
Anywho, can someone take a few minutes to check this out ?
-Emil
On 27/08/14 08:36, Andreas Pokorny wrote:
Width and Height of the imported image was never initialized from the
imported bo.
Signed-off-by: Andreas Pokorny andreas.poko...@canonical.com
---
src/mesa/drivers/dri/i915/intel_screen.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
b/src/mesa/drivers/dri/i915/intel_screen.c
index 3aaa45f..00d8580 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -616,6 +616,8 @@ intel_create_image_from_fds(__DRIscreen *screen,
return NULL;
}
+ intel_setup_image_from_dimensions(image);
+
image-planar_format = f;
for (i = 0; i f-nplanes; i++) {
index = f-planes[i].buffer_index;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83951] Account Request
https://bugs.freedesktop.org/show_bug.cgi?id=83951 --- Comment #1 from Sinclair Yeh s...@vmware.com --- Created attachment 106392 -- https://bugs.freedesktop.org/attachment.cgi?id=106392action=edit ssh RSA key -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83951] Account Request
https://bugs.freedesktop.org/show_bug.cgi?id=83951 Sinclair Yeh s...@vmware.com changed: What|Removed |Added Attachment #106391|0 |1 is obsolete|| --- Comment #2 from Sinclair Yeh s...@vmware.com --- Created attachment 106393 -- https://bugs.freedesktop.org/attachment.cgi?id=106393action=edit PGP Public Key -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/fs: Manually generate the meta fast-clear shader
Previously, we were generating the fast-clear shader from GLSL. The
problem is that fast clears require that we use a replicated write rather
than a regular write instruction. In order to get this we had a
complicated and somewhat fragile optimization pass that looked for places
where we can use a replicated write and used it. Since replicated writes
have a lot of restrictions, we only ever use them for fast-clear
operations.
This commit replaces the optimization pass with a function that just
generates the shader we want. This is a) less code, b) less fragile than
the optimization pass, and c) generates a more efficient shader.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
Cc: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 122 ++-
src/mesa/drivers/dri/i965/brw_fs.h | 3 +-
2 files changed, 34 insertions(+), 91 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index a064390..03ce51d 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2310,98 +2310,42 @@ fs_visitor::compute_to_mrf()
* instructions to FS_OPCODE_REP_FB_WRITE.
*/
void
-fs_visitor::try_rep_send()
+fs_visitor::emit_repclear_shader()
{
- int i, count;
- fs_inst *start = NULL;
- bblock_t *mov_block;
+ int base_mrf = 1;
+ int color_mrf = base_mrf + 2;
- /* From the Ivybridge PRM, Volume 4 Part 1, section 3.9.11.2
-* (Message Descriptor - Render Target Write):
-*
-* SIMD16_REPDATA message must not be used in SIMD8 pixel-shaders.
-*/
- if (dispatch_width != 16)
- return;
-
- /* The constant color write message can't handle anything but the 4 color
-* values. We could do MRT, but the loops below would need to understand
-* handling the header being enabled or disabled on different messages. It
-* also requires that the render target be tiled, which might not be the
-* case for some EGLImage paths or if we some day do rendering to PBOs.
-*/
- if (prog-OutputsWritten BITFIELD64_BIT(FRAG_RESULT_DEPTH) ||
- payload.aa_dest_stencil_reg ||
- payload.dest_depth_reg ||
- dual_src_output.file != BAD_FILE)
- return;
-
- /* The optimization is implemented as one pass through the instruction
-* list. We keep track of the most recent block of MOVs into sequential
-* MRFs from single, sequential float registers (ie uniforms). Then when
-* we find an FB_WRITE opcode, we see if the payload registers match the
-* destination registers in our block of MOVs.
-*/
- count = 0;
- foreach_block_and_inst_safe(block, fs_inst, inst, cfg) {
- if (count == 0) {
- start = inst;
- mov_block = block;
- }
- if (inst-opcode == BRW_OPCODE_MOV
- inst-dst.file == MRF
- inst-dst.reg == start-dst.reg + 2 * count
- inst-src[0].file == HW_REG
- inst-src[0].reg_offset == start-src[0].reg_offset + count) {
- if (count == 0) {
-start = inst;
-mov_block = block;
- }
- count++;
- }
-
- if (inst-opcode == FS_OPCODE_FB_WRITE
- count == 4
- (inst-base_mrf == start-dst.reg ||
- (inst-base_mrf + 2 == start-dst.reg inst-header_present))) {
- fs_inst *mov = MOV(start-dst, start-src[0]);
+ fs_inst *mov = emit(MOV(vec4(brw_message_reg(color_mrf)),
+ fs_reg(UNIFORM, 0, BRW_REGISTER_TYPE_F)));
+ mov-force_writemask_all = true;
+ mov-force_uncompressed = true;
- /* Make a MOV that moves the four floats into the replicated write
- * payload. Since we're running at the very end of code generation
- * we can use hw registers and generate the stride and offsets we
- * need for this MOV. We use the first of the eight registers
- * allocated for the SIMD16 payload for the four floats.
- */
- mov-dst.fixed_hw_reg =
-brw_vec4_reg(BRW_MESSAGE_REGISTER_FILE,
- start-dst.reg, 0);
- mov-dst.file = HW_REG;
- mov-dst.type = mov-dst.fixed_hw_reg.type;
-
- mov-src[0].fixed_hw_reg =
-brw_vec4_grf(mov-src[0].fixed_hw_reg.nr, 0);
- mov-src[0].file = HW_REG;
- mov-src[0].type = mov-src[0].fixed_hw_reg.type;
- mov-force_writemask_all = true;
- mov-dst.type = BRW_REGISTER_TYPE_F;
-
- /* Replace the four MOVs with the new vec4 MOV. */
- start-insert_before(mov_block, mov);
- for (i = 0; i 4; i++)
-((fs_inst *) mov-next)-remove(mov_block);
-
- /* Finally, adjust the message length and set the opcode to
- * REP_FB_WRITE for the send, so that the generator will use the
- * replicated data mesage type. Then reset count so we'll start
- * looking for a new block in case we're in a MRT shader.
-
[Mesa-dev] [Bug 83951] Account Request
https://bugs.freedesktop.org/show_bug.cgi?id=83951 Brian Paul bri...@vmware.com changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes |org |ktop.org Product|Mesa|freedesktop.org Component|Other |New Accounts --- Comment #3 from Brian Paul bri...@vmware.com --- Reassigning to fd.o admins. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 17/37] i965/gen6/gs: Implement geometry shaders for outputs other than points.
On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga ito...@igalia.com wrote:
---
src/mesa/drivers/dri/i965/gen6_gs_visitor.cpp | 72
---
src/mesa/drivers/dri/i965/gen6_gs_visitor.h | 2 +
2 files changed, 67 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_gs_visitor.cpp
b/src/mesa/drivers/dri/i965/gen6_gs_visitor.cpp
index b78c55e..5123bd7 100644
--- a/src/mesa/drivers/dri/i965/gen6_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_gs_visitor.cpp
@@ -79,6 +79,21 @@ gen6_gs_visitor::emit_prolog()
* and URB_WRITE messages.
*/
this-temp = src_reg(this, glsl_type::uint_type);
+
+ /* This will be used to know when we are processing the first vertex of
+* a primitive. We will set this to URB_WRITE_PRIM_START only when we know
+* that we are processing the first vertex in the primitive and to zero
+* otherwise. This way we can use its value directly in the URB write
+* headers.
+*/
+ this-first_vertex = src_reg(this, glsl_type::uint_type);
+ emit(MOV(dst_reg(this-first_vertex), URB_WRITE_PRIM_START));
+
+ /* The FF_SYNC message requires to know the number of primitives
generated,
+* so keep a counter for this.
+*/
+ this-prim_count = src_reg(this, glsl_type::uint_type);
+ emit(MOV(dst_reg(this-prim_count), 0u));
}
void
@@ -109,18 +124,26 @@ gen6_gs_visitor::visit(ir_emit_vertex *)
this-vertex_output_offset, 1u));
}
- /* Now buffer flags for this vertex (we only support point output
- * for now).
- */
+ /* Now buffer flags for this vertex */
dst_reg dst(this-vertex_output);
dst.reladdr = ralloc(mem_ctx, src_reg);
memcpy(dst.reladdr, this-vertex_output_offset, sizeof(src_reg));
- /* If we are outputting points, then every vertex has PrimStart and
- * PrimEnd set.
- */
if (c-gp-program.OutputType == GL_POINTS) {
+ /* If we are outputting points, then every vertex has PrimStart and
+ * PrimEnd set.
+ */
emit(MOV(dst, (_3DPRIM_POINTLIST URB_WRITE_PRIM_TYPE_SHIFT) |
URB_WRITE_PRIM_START | URB_WRITE_PRIM_END));
+ emit(ADD(dst_reg(this-prim_count), this-prim_count, 1u));
+ } else {
+ /* Otherwise, we can only set the PrimStart flag, which we have
stored
+ * in the first_vertex register. We will have to wait until we
execute
+ * EndPrimitive() or we end the thread to set the PrimEnd flag on a
+ * vertex.
+ */
+ emit(OR(dst, this-first_vertex,
+ (c-prog_data.output_topology
URB_WRITE_PRIM_TYPE_SHIFT)));
+ emit(MOV(dst_reg(this-first_vertex), 0u));
}
emit(ADD(dst_reg(this-vertex_output_offset),
this-vertex_output_offset, 1u));
@@ -140,6 +163,41 @@ gen6_gs_visitor::visit(ir_end_primitive *)
*/
if (c-gp-program.OutputType == GL_POINTS)
return;
+
+ /* Otheriwse we know that the last vertex we have processed was the last
Typo.
16 17
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
+* vertex in the primitive and we need to set its PrimEnd flag, so do this
+* unless we haven't emitted that vertex at all.
+*
+* Notice that we have already incremented vertex_count when we processed
+* the last emit_vertex, so we need to take that into account in the
+* comparison below (hence the num_output_vertices + 1 in the comparison
+* below).
+*/
+ unsigned num_output_vertices = c-gp-program.VerticesOut;
+ emit(CMP(dst_null_d(), this-vertex_count, src_reg(num_output_vertices +
1),
+BRW_CONDITIONAL_L));
+ emit(IF(BRW_PREDICATE_NORMAL));
+ {
+ /* vertex_output_offset is already pointing at the first entry of the
+ * next vertex. So subtract 1 to modify the flags for the previous
+ * vertex.
+ */
+ src_reg offset(this, glsl_type::uint_type);
+ emit(ADD(dst_reg(offset), this-vertex_output_offset, brw_imm_d(-1)));
+
+ src_reg dst(this-vertex_output);
+ dst.reladdr = ralloc(mem_ctx, src_reg);
+ memcpy(dst.reladdr, offset, sizeof(src_reg));
+
+ emit(OR(dst_reg(dst), dst, URB_WRITE_PRIM_END));
+ emit(ADD(dst_reg(this-prim_count), this-prim_count, 1u));
+
+ /* Set the first vertex flag to indicate that the next vertex will
start
+ * a primitive.
+ */
+ emit(MOV(dst_reg(this-first_vertex), URB_WRITE_PRIM_START));
+ }
+ emit(BRW_OPCODE_ENDIF);
}
void
@@ -234,7 +292,7 @@ gen6_gs_visitor::emit_thread_end()
/* Issue the FF_SYNC message and obtain the initial VUE handle. */
this-current_annotation = gen6 thread end: ff_sync;
emit(GS_OPCODE_FF_SYNC,
-dst_reg(MRF, base_mrf), this-temp, this-vertex_count);
+dst_reg(MRF, base_mrf), this-temp, this-prim_count);
/*
Re: [Mesa-dev] [PATCH] configure.ac: detect LLVM patch level when built via cmake
On Tue, Sep 09, 2014 at 07:56:03PM +0100, Emil Velikov wrote:
On 09/09/14 16:26, Tom Stellard wrote:
On Sat, Sep 06, 2014 at 01:43:55AM +1000, Jonathan Gray wrote:
In LLVM 3.4.1 and 3.4.2 the patch level was only set in config.h when
LLVM was built via autoconf and not when it was built with cmake.
Fall back to retrieving the patch level from llvm-config --version to
handle this case.
We should extract LLVM_VERSION_PATH from $LLVM_VERSION and then we won't
have to worry about which config file it is in.
I believe you meant VERSION_PATCH above ? Indeed that would nice thing to have
but I doubt that it will get back-ported to the llvm 3.4 branch.
I mean we should do this in Mesa's configure script. Something like:
LLVM_VERSION_PATCH = echo $LLVM_VERSION | sed 's/^[0-9]\+\.[0-9]\+\.//g'
Are there any plans on making a 3.4.3 release ? Would be nice to have it fixed
at the root rather than adding the hack in mesa :)
There are no plans to do a 3.4.3 release.
-Tom
-Emil
-Tom
Cc: 10.2 10.3 mesa-sta...@lists.freedesktop.org
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
configure.ac | 9 +
1 file changed, 9 insertions(+)
diff --git a/configure.ac b/configure.ac
index 99ae6ba..98cd938 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1705,6 +1705,15 @@ if test x$enable_gallium_llvm = xyes; then
[#include ${LLVM_INCLUDEDIR}/llvm/Config/config.h],
LLVM_VERSION_PATCH=0) dnl Default if LLVM_VERSION_PATCH not
found
+dnl In LLVM 3.4.1 and 3.4.2 the patch level was only set in
config.h
+dnl for autoconf builds and not cmake builds
+if test $LLVM_VERSION_PATCH -eq 0; then
+LLVM_VERSION_PATCH=`echo $LLVM_VERSION | cut -d. -f3`
+if test -z $LLVM_VERSION_PATCH; then
+LLVM_VERSION_PATCH=0
+fi
+fi
+
if test -n ${LLVM_VERSION_MAJOR}; then
LLVM_VERSION_INT=${LLVM_VERSION_MAJOR}0${LLVM_VERSION_MINOR}
else
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 20/37] i965/gen6/gs: Implement GS_OPCODE_SET_PRIMITIVE_ID.
On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga ito...@igalia.com wrote:
In gen6 the geometry shader payload includes the PrimitiveID information in
r0.1. When the shader code uses glPimitiveIdIn we will have to move this to
a separate hardware register where we can map this attribute. This opcode
takes the selected destination register and moves r0.1 there.
---
src/mesa/drivers/dri/i965/brw_defines.h | 8
src/mesa/drivers/dri/i965/brw_shader.cpp | 2 ++
src/mesa/drivers/dri/i965/brw_vec4.h | 1 +
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 17 +
4 files changed, 28 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index f6bdaeb..b30a095 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1032,6 +1032,14 @@ enum opcode {
* - src1 is the number of primitives written.
*/
GS_OPCODE_FF_SYNC,
+
+ /**
+* Move r0.1 (which holds PrimitiveID information in gen6) to a separate
+* register.
+*
+* - dst is the GRF where PrimitiveID information will be moved.
+*/
+ GS_OPCODE_SET_PRIMITIVE_ID,
};
enum brw_urb_write_flags {
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index b927601..fc3146c 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -534,6 +534,8 @@ brw_instruction_name(enum opcode op)
return get_instance_id;
case GS_OPCODE_FF_SYNC:
return ff_sync;
+ case GS_OPCODE_SET_PRIMITIVE_ID:
+ return set_primitive_id;
default:
/* Yes, this leaks. It's in debug code, it should never occur, and if
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index ad3a77f..6e0da6d 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -665,6 +665,7 @@ private:
void generate_gs_ff_sync(struct brw_reg dst,
struct brw_reg src0,
struct brw_reg src1);
+ void generate_gs_set_primitive_id(struct brw_reg dst);
void generate_oword_dual_block_offsets(struct brw_reg m1,
struct brw_reg index);
void generate_scratch_write(vec4_instruction *inst,
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index 2bf2b67..8293f60 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
@@ -694,6 +694,19 @@ vec4_generator::generate_gs_ff_sync(struct brw_reg dst,
}
void
+vec4_generator::generate_gs_set_primitive_id(struct brw_reg dst)
+{
+ /* In gen6, PrimitiveID is delivered in R0.1 of the payload */
+ struct brw_reg src = brw_vec8_grf(0, 0);
+ brw_push_insn_state(p);
+ brw_set_default_mask_control(p, BRW_MASK_DISABLE);
+ brw_set_default_access_mode(p, BRW_ALIGN_1);
+ brw_MOV(p, get_element_ud(dst, 0), get_element_ud(src, 1));
+ brw_set_default_access_mode(p, BRW_ALIGN_16);
The pop below makes this unneeded, right?
18-20
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
+ brw_pop_insn_state(p);
+}
+
+void
vec4_generator::generate_oword_dual_block_offsets(struct brw_reg m1,
struct brw_reg index)
{
@@ -1283,6 +1296,10 @@
vec4_generator::generate_vec4_instruction(vec4_instruction *instruction,
generate_gs_ff_sync(dst, src[0], src[1]);
break;
+ case GS_OPCODE_SET_PRIMITIVE_ID:
+ generate_gs_set_primitive_id(dst);
+ break;
+
case SHADER_OPCODE_SHADER_TIME_ADD:
brw_shader_time_add(p, src[0],
prog_data-base.binding_table.shader_time_start);
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: Add tokens for DragonFly BSD.
Signed-off-by: Vinson Lee v...@freedesktop.org --- src/gallium/include/pipe/p_config.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/gallium/include/pipe/p_config.h b/src/gallium/include/pipe/p_config.h index b5e7736..5b6db7d 100644 --- a/src/gallium/include/pipe/p_config.h +++ b/src/gallium/include/pipe/p_config.h @@ -218,6 +218,12 @@ #define PIPE_OS_UNIX #endif +#if defined(__DragonFly__) +#define PIPE_OS_DRAGONFLY +#define PIPE_OS_BSD +#define PIPE_OS_UNIX +#endif + #if defined(__GNU__) #define PIPE_OS_HURD #define PIPE_OS_UNIX -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/11] mesa: Add MESA_FORMAT_A8L8_{SNORM, SRGB}
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
On Mon, Sep 15, 2014 at 11:28 PM, Dave Airlie airl...@gmail.com wrote:
From: Richard Sandiford rsand...@linux.vnet.ibm.com
The associated UNORM format already existed.
This means that each LnAn format has a reversed counterpart,
which is necessary for handling big-endian mesa-gallium mappings.
[airlied: rebased onto current master]
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Reviewed-by: Brian Paul bri...@vmware.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 2 ++
src/mesa/main/format_pack.c | 37
+
src/mesa/main/format_unpack.c | 29 +++
src/mesa/main/formats.c | 10 +++
src/mesa/main/formats.csv | 2 ++
src/mesa/main/formats.h | 2 ++
src/mesa/main/texformat.c | 3 ++
src/mesa/swrast/s_texfetch.c| 2 ++
src/mesa/swrast/s_texfetch_tmp.h| 24
9 files changed, 111 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index 974f2df..b726c27 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -371,6 +371,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
[MESA_FORMAT_R8G8B8A8_SRGB] = BRW_SURFACEFORMAT_R8G8B8A8_UNORM_SRGB,
[MESA_FORMAT_L_SRGB8] = BRW_SURFACEFORMAT_L8_UNORM_SRGB,
[MESA_FORMAT_L8A8_SRGB] = BRW_SURFACEFORMAT_L8A8_UNORM_SRGB,
+ [MESA_FORMAT_A8L8_SRGB] = 0,
[MESA_FORMAT_SRGB_DXT1] = BRW_SURFACEFORMAT_DXT1_RGB_SRGB,
[MESA_FORMAT_SRGBA_DXT1] = BRW_SURFACEFORMAT_BC1_UNORM_SRGB,
[MESA_FORMAT_SRGBA_DXT3] = BRW_SURFACEFORMAT_BC2_UNORM_SRGB,
@@ -495,6 +496,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
[MESA_FORMAT_A_SNORM8] = 0,
[MESA_FORMAT_L_SNORM8] = 0,
[MESA_FORMAT_L8A8_SNORM] = 0,
+ [MESA_FORMAT_A8L8_SNORM] = 0,
[MESA_FORMAT_I_SNORM8] = 0,
[MESA_FORMAT_A_SNORM16] = 0,
[MESA_FORMAT_L_SNORM16] = 0,
diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c
index 6cbf859..231fd6c 100644
--- a/src/mesa/main/format_pack.c
+++ b/src/mesa/main/format_pack.c
@@ -1129,6 +1129,16 @@ pack_ubyte_L8A8_SRGB(const GLubyte src[4], void
*dst)
*d = PACK_COLOR_88(src[ACOMP], l);
}
+/* MESA_FORMAT_A8L8_SRGB */
+
+static void
+pack_ubyte_A8L8_SRGB(const GLubyte src[4], void *dst)
+{
+ GLushort *d = ((GLushort *) dst);
+ GLubyte l = util_format_linear_to_srgb_8unorm(src[RCOMP]);
+ *d = PACK_COLOR_88(l, src[ACOMP]);
+}
+
static void
pack_float_L8A8_SRGB(const GLfloat src[4], void *dst)
{
@@ -1138,6 +1148,15 @@ pack_float_L8A8_SRGB(const GLfloat src[4], void
*dst)
*d = PACK_COLOR_88(a, l);
}
+static void
+pack_float_A8L8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLushort *d = ((GLushort *) dst);
+ GLubyte a, l = util_format_linear_float_to_srgb_8unorm(src[RCOMP]);
+ CLAMPED_FLOAT_TO_UBYTE(a, src[ACOMP]);
+ *d = PACK_COLOR_88(l, a);
+}
+
/* MESA_FORMAT_RGBA_FLOAT32 */
@@ -1563,6 +1582,20 @@ pack_float_L8A8_SNORM(const GLfloat src[4], void
*dst)
/*
+ * MESA_FORMAT_A8L8_SNORM
+ */
+
+static void
+pack_float_A8L8_SNORM(const GLfloat src[4], void *dst)
+{
+ GLushort *d = (GLushort *) dst;
+ GLbyte l = FLOAT_TO_BYTE(CLAMP(src[RCOMP], -1.0f, 1.0f));
+ GLbyte a = FLOAT_TO_BYTE(CLAMP(src[ACOMP], -1.0f, 1.0f));
+ *d = (l 8) | a;
+}
+
+
+/*
* MESA_FORMAT_A_SNORM16
*/
@@ -1936,6 +1969,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format
format)
table[MESA_FORMAT_R8G8B8A8_SRGB] = pack_ubyte_R8G8B8A8_SRGB;
table[MESA_FORMAT_L_SRGB8] = pack_ubyte_L_SRGB8;
table[MESA_FORMAT_L8A8_SRGB] = pack_ubyte_L8A8_SRGB;
+ table[MESA_FORMAT_A8L8_SRGB] = pack_ubyte_A8L8_SRGB;
/* n/a */
table[MESA_FORMAT_SRGB_DXT1] = NULL; /* pack_ubyte_SRGB_DXT1; */
table[MESA_FORMAT_SRGBA_DXT1] = NULL; /* pack_ubyte_SRGBA_DXT1; */
@@ -1989,6 +2023,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format
format)
table[MESA_FORMAT_A_SNORM8] = NULL;
table[MESA_FORMAT_L_SNORM8] = NULL;
table[MESA_FORMAT_L8A8_SNORM] = NULL;
+ table[MESA_FORMAT_A8L8_SNORM] = NULL;
table[MESA_FORMAT_I_SNORM8] = NULL;
table[MESA_FORMAT_A_SNORM16] = NULL;
table[MESA_FORMAT_L_SNORM16] = NULL;
@@ -2099,6 +2134,7 @@ _mesa_get_pack_float_rgba_function(mesa_format
format)
table[MESA_FORMAT_R8G8B8A8_SRGB] = pack_float_R8G8B8A8_SRGB;
table[MESA_FORMAT_L_SRGB8] = pack_float_L_SRGB8;
table[MESA_FORMAT_L8A8_SRGB] = pack_float_L8A8_SRGB;
+ table[MESA_FORMAT_A8L8_SRGB] = pack_float_A8L8_SRGB;
/* n/a */
Re: [Mesa-dev] [PATCH 08/11] mesa: Tweak unpack name for MESA_FORMAT_R8G8B8X8_SNORM
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
On Mon, Sep 15, 2014 at 11:28 PM, Dave Airlie airl...@gmail.com wrote:
From: Richard Sandiford rsand...@linux.vnet.ibm.com
MESA_FORMAT_R8G8B8X8_SNORM used a function called unpack_X8B8G8R8_SNORM
while MESA_FORMAT_R8G8B8X8_SRGB used a function called
unpack_R8G8B8X8_SRGB.
This patch renames the SNORM function to have the same order as the
MESA_FORMAT name, like the SRGB function does.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/main/format_unpack.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index eed92d8..68fbcb3 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -2106,7 +2106,7 @@ unpack_XRGB1555_UNORM(const void *src, GLfloat
dst[][4], GLuint n)
}
static void
-unpack_XBGR_SNORM(const void *src, GLfloat dst[][4], GLuint n)
+unpack_R8G8B8X8_SNORM(const void *src, GLfloat dst[][4], GLuint n)
{
const GLuint *s = ((const GLuint *) src);
GLuint i;
@@ -2526,7 +2526,7 @@ get_unpack_rgba_function(mesa_format format)
table[MESA_FORMAT_B4G4R4X4_UNORM] = unpack_XRGB_UNORM;
table[MESA_FORMAT_B5G5R5X1_UNORM] = unpack_XRGB1555_UNORM;
- table[MESA_FORMAT_R8G8B8X8_SNORM] = unpack_XBGR_SNORM;
+ table[MESA_FORMAT_R8G8B8X8_SNORM] = unpack_R8G8B8X8_SNORM;
table[MESA_FORMAT_R8G8B8X8_SRGB] = unpack_R8G8B8X8_SRGB;
table[MESA_FORMAT_RGBX_UINT8] = unpack_XBGR_UINT;
table[MESA_FORMAT_RGBX_SINT8] = unpack_XBGR_SINT;
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/11] mesa: Fix alpha component in unpack_R8G8B8X8_SRGB.
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com This is why we should be auto-generating these... On Mon, Sep 15, 2014 at 11:28 PM, Dave Airlie airl...@gmail.com wrote: From: Richard Sandiford rsand...@linux.vnet.ibm.com The function was using the X component as the alpha channel, rather than setting alpha to 1.0. Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com Reviewed-by: Brian Paul bri...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com --- src/mesa/main/format_unpack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c index 68fbcb3..cfa6a60 100644 --- a/src/mesa/main/format_unpack.c +++ b/src/mesa/main/format_unpack.c @@ -2127,7 +2127,7 @@ unpack_R8G8B8X8_SRGB(const void *src, GLfloat dst[][4], GLuint n) dst[i][RCOMP] = util_format_srgb_8unorm_to_linear_float( (s[i] ) 0xff ); dst[i][GCOMP] = util_format_srgb_8unorm_to_linear_float( (s[i] 8) 0xff ); dst[i][BCOMP] = util_format_srgb_8unorm_to_linear_float( (s[i] 16) 0xff ); - dst[i][ACOMP] = UBYTE_TO_FLOAT( s[i] 24 ); /* linear! */ + dst[i][ACOMP] = 1.0f; } } -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/11] mesa: Add MESA_FORMAT_{A8R8G8B8, X8R8G8B8, X8B8G8R8}_SRGB
Got a couple comments below. Other than that,
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
On Mon, Sep 15, 2014 at 11:28 PM, Dave Airlie airl...@gmail.com wrote:
From: Richard Sandiford rsand...@linux.vnet.ibm.com
This means that each SRGB format has a reversed counterpart,
which is necessary for handling big-endian mesa-gallium mappings.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
src/mesa/main/format_pack.c | 60
+
src/mesa/main/format_unpack.c | 42 +
src/mesa/main/formats.c | 16 +++
src/mesa/main/formats.csv | 3 ++
src/mesa/main/formats.h | 3 ++
src/mesa/main/texformat.c | 10 +
src/mesa/swrast/s_texfetch.c| 3 ++
src/mesa/swrast/s_texfetch_tmp.h| 24 ++
9 files changed, 162 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index b726c27..21b8adb 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -517,6 +517,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
[MESA_FORMAT_B5G5R5X1_UNORM] = BRW_SURFACEFORMAT_B5G5R5X1_UNORM,
[MESA_FORMAT_R8G8B8X8_SNORM] = 0,
[MESA_FORMAT_R8G8B8X8_SRGB] = 0,
+ [MESA_FORMAT_X8B8G8R8_SRGB] = 0,
Any particular reason you go out of your way to add X8B8G8R8_SRGB and not
the other two?
[MESA_FORMAT_RGBX_UINT8] = 0,
[MESA_FORMAT_RGBX_SINT8] = 0,
[MESA_FORMAT_B10G10R10X2_UNORM] =
BRW_SURFACEFORMAT_B10G10R10X2_UNORM,
diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c
index 231fd6c..15bf0e5 100644
--- a/src/mesa/main/format_pack.c
+++ b/src/mesa/main/format_pack.c
@@ -1076,6 +1076,31 @@ pack_float_B8G8R8A8_SRGB(const GLfloat src[4], void
*dst)
}
+/* MESA_FORMAT_A8R8G8B8_SRGB */
+
+static void
+pack_ubyte_A8R8G8B8_SRGB(const GLubyte src[4], void *dst)
+{
+ GLuint *d = ((GLuint *) dst);
+ GLubyte r = util_format_linear_to_srgb_8unorm(src[RCOMP]);
+ GLubyte g = util_format_linear_to_srgb_8unorm(src[GCOMP]);
+ GLubyte b = util_format_linear_to_srgb_8unorm(src[BCOMP]);
+ *d = PACK_COLOR_(b, g, r, src[ACOMP]);
+}
+
+static void
+pack_float_A8R8G8B8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLuint *d = ((GLuint *) dst);
+ GLubyte r, g, b, a;
+ r = util_format_linear_float_to_srgb_8unorm(src[RCOMP]);
+ g = util_format_linear_float_to_srgb_8unorm(src[GCOMP]);
+ b = util_format_linear_float_to_srgb_8unorm(src[BCOMP]);
+ UNCLAMPED_FLOAT_TO_UBYTE(a, src[ACOMP]);
+ *d = PACK_COLOR_(b, g, r, a);
+}
+
+
/* MESA_FORMAT_R8G8B8A8_SRGB */
static void
@@ -1750,6 +1775,21 @@ pack_float_R8G8B8X8_SRGB(const GLfloat src[4], void
*dst)
}
+/*
+ * MESA_FORMAT_X8B8G8R8_SRGB
+ */
+
+static void
+pack_float_X8B8G8R8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLuint *d = (GLuint *) dst;
+ GLubyte r = util_format_linear_float_to_srgb_8unorm(src[RCOMP]);
+ GLubyte g = util_format_linear_float_to_srgb_8unorm(src[GCOMP]);
+ GLubyte b = util_format_linear_float_to_srgb_8unorm(src[BCOMP]);
+ *d = PACK_COLOR_(r, g, b, 127);
That should be a max of 255, these aren't SNORM formats
+}
+
+
/* MESA_FORMAT_B10G10R10X2_UNORM */
static void
@@ -1899,6 +1939,20 @@ pack_float_B8G8R8X8_SRGB(const GLfloat src[4], void
*dst)
*d = PACK_COLOR_(127, r, g, b);
}
+/*
+ * MESA_FORMAT_X8R8G8B8_SRGB
+ */
+
+static void
+pack_float_X8R8G8B8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLuint *d = (GLuint *) dst;
+ GLubyte r = util_format_linear_float_to_srgb_8unorm(src[RCOMP]);
+ GLubyte g = util_format_linear_float_to_srgb_8unorm(src[GCOMP]);
+ GLubyte b = util_format_linear_float_to_srgb_8unorm(src[BCOMP]);
+ *d = PACK_COLOR_(b, g, r, 127);
Max of 255 here too
+}
+
/**
* Return a function that can pack a GLubyte rgba[4] color.
*/
@@ -1966,6 +2020,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format
format)
table[MESA_FORMAT_BGR_SRGB8] = pack_ubyte_BGR_SRGB8;
table[MESA_FORMAT_A8B8G8R8_SRGB] = pack_ubyte_A8B8G8R8_SRGB;
table[MESA_FORMAT_B8G8R8A8_SRGB] = pack_ubyte_B8G8R8A8_SRGB;
+ table[MESA_FORMAT_A8R8G8B8_SRGB] = pack_ubyte_A8R8G8B8_SRGB;
table[MESA_FORMAT_R8G8B8A8_SRGB] = pack_ubyte_R8G8B8A8_SRGB;
table[MESA_FORMAT_L_SRGB8] = pack_ubyte_L_SRGB8;
table[MESA_FORMAT_L8A8_SRGB] = pack_ubyte_L8A8_SRGB;
@@ -2040,6 +2095,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format
format)
table[MESA_FORMAT_B5G5R5X1_UNORM] = pack_ubyte_XRGB1555_UNORM;
table[MESA_FORMAT_R8G8B8X8_SNORM] = NULL;
Re: [Mesa-dev] big endian LA and 8888 SRGB/SNORM fixes (rebased)
Hi Dave, Most of the core mesa stuff looks good to me (a couple comments on the last patch). I'll leave the gallium bits to the gallium people. --Jason Ekstrand On Mon, Sep 15, 2014 at 11:27 PM, Dave Airlie airl...@gmail.com wrote: Hi, I've taken Richard's previous patchset and rebased them on top of current mesa formats code, I pushed some of Richard's other patches already but these needs some changes, so I thought I'd repost them in case anyone wanted to take a look. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 10.3 release plan
On 12/09/14 10:10, Emil Velikov wrote: On 11/09/14 23:21, Ian Romanick wrote: On 09/10/2014 05:45 AM, Emil Velikov wrote: Hello all, The original plan from Ian was to have four release candidates prior to the final release. From what I can see there has been no serious amount of patches nominated for 10.3-rc4, so I'm planning to keep with the plan and release 10.3 this Friday. If you know of any serious issues that must land or any other reason why we should delay 10.3 please let me know ASAP. I hope this is soon enough. :( Ken and I have a few bug fixes that we'd like to have land in the release. I think they're all out on the list for review, but Ken might have one more. Once they land on master, I'll send you a pull-request. Could we do one more RC tomorrow and the final release next week? We probably don't need to wait until Friday, but I don't have a strong opinion. Hi Ian, What a nice timing this is. Just found out that I'll have to be moving to another house bit earlier than expected, and here comes a request to delay the release by a couple of days. Sounds like a plan to me :) So after some interesting few days, I've went through the 10.3 queue. We have 35 newly queued patches, and when running piglit 3457f015314 against mesa 10.2.7 shows * swrast-classic 19 regressions 3 fixes 28 new tests, 28 pass * swrast-gallium (llvmpipe) 2 regressions 37 fixes 97 new tests, 91 pass, 6 fail I will give it a spin on my Sandybridge tomorrow, and barring any serious issues mesa 10.3 will be out this Friday alongside 10.2.8 :) Thanks Emil -Emil Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83631] /usr/include/GL/glxext.h:480:143: error: 'GLintptr' has not been declared
https://bugs.freedesktop.org/show_bug.cgi?id=83631 abortretryf...@gmail.com changed: What|Removed |Added CC||abortretryf...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83631] /usr/include/GL/glxext.h:480:143: error: 'GLintptr' has not been declared
https://bugs.freedesktop.org/show_bug.cgi?id=83631 --- Comment #6 from abortretryf...@gmail.com --- I ran in to this problem trying to build OpenCASCADE for FreeCAD. Not sure if this is helpful or not, but the comment there says: // exclude modern definitions and system-provided glext.h, should be defined before gl.h inclusion #define GL_GLEXT_LEGACY -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/11] util: Define PIPE_FORMAT_xyzw8888_{SNORM, SRGB} aliases
Am 16.09.2014 08:28, schrieb Dave Airlie:
From: Richard Sandiford rsand...@linux.vnet.ibm.com
...i.e. formats in which the first listed component is in the least
significant byte of the integer. The corresponding UNORM aliases already
exist.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/include/pipe/p_format.h | 24
1 file changed, 24 insertions(+)
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_format.h
index d309fa1..9c02464 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -374,6 +374,18 @@ enum pipe_format {
#define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
+#define PIPE_FORMAT_RGBA_SNORM PIPE_FORMAT_R8G8B8A8_SNORM
+#define PIPE_FORMAT_RGBX_SNORM PIPE_FORMAT_R8G8B8X8_SNORM
+#define PIPE_FORMAT_ABGR_SNORM PIPE_FORMAT_A8B8G8R8_SNORM
+#define PIPE_FORMAT_XBGR_SNORM PIPE_FORMAT_X8B8G8R8_SNORM
+#define PIPE_FORMAT_RGBA_SRGB PIPE_FORMAT_R8G8B8A8_SRGB
+#define PIPE_FORMAT_RGBX_SRGB PIPE_FORMAT_R8G8B8X8_SRGB
+#define PIPE_FORMAT_BGRA_SRGB PIPE_FORMAT_B8G8R8A8_SRGB
+#define PIPE_FORMAT_BGRX_SRGB PIPE_FORMAT_B8G8R8X8_SRGB
+#define PIPE_FORMAT_ARGB_SRGB PIPE_FORMAT_A8R8G8B8_SRGB
+#define PIPE_FORMAT_XRGB_SRGB PIPE_FORMAT_X8R8G8B8_SRGB
+#define PIPE_FORMAT_ABGR_SRGB PIPE_FORMAT_A8B8G8R8_SRGB
+#define PIPE_FORMAT_XBGR_SRGB PIPE_FORMAT_X8B8G8R8_SRGB
#define PIPE_FORMAT_LA88_UNORM PIPE_FORMAT_L8A8_UNORM
#define PIPE_FORMAT_AL88_UNORM PIPE_FORMAT_A8L8_UNORM
#define PIPE_FORMAT_LA88_SNORM PIPE_FORMAT_L8A8_SNORM
@@ -400,6 +412,18 @@ enum pipe_format {
#define PIPE_FORMAT_BGRX_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
#define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#define PIPE_FORMAT_RGBX_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
+#define PIPE_FORMAT_ABGR_SNORM PIPE_FORMAT_R8G8B8A8_SNORM
+#define PIPE_FORMAT_XBGR_SNORM PIPE_FORMAT_R8G8B8X8_SNORM
+#define PIPE_FORMAT_RGBA_SNORM PIPE_FORMAT_A8B8G8R8_SNORM
+#define PIPE_FORMAT_RGBX_SNORM PIPE_FORMAT_X8B8G8R8_SNORM
+#define PIPE_FORMAT_ABGR_SRGB PIPE_FORMAT_R8G8B8A8_SRGB
+#define PIPE_FORMAT_XBGR_SRGB PIPE_FORMAT_R8G8B8X8_SRGB
+#define PIPE_FORMAT_ARGB_SRGB PIPE_FORMAT_B8G8R8A8_SRGB
+#define PIPE_FORMAT_XRGB_SRGB PIPE_FORMAT_B8G8R8X8_SRGB
+#define PIPE_FORMAT_BGRA_SRGB PIPE_FORMAT_A8R8G8B8_SRGB
+#define PIPE_FORMAT_BGRX_SRGB PIPE_FORMAT_X8R8G8B8_SRGB
+#define PIPE_FORMAT_RGBA_SRGB PIPE_FORMAT_A8B8G8R8_SRGB
+#define PIPE_FORMAT_RGBX_SRGB PIPE_FORMAT_X8B8G8R8_SRGB
#define PIPE_FORMAT_LA88_UNORM PIPE_FORMAT_A8L8_UNORM
#define PIPE_FORMAT_AL88_UNORM PIPE_FORMAT_L8A8_UNORM
#define PIPE_FORMAT_LA88_SNORM PIPE_FORMAT_A8L8_SNORM
2,3,6,7 look good to me except they should say gallium not util in the
commit message.
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] - fixing bug 83570...idiv by zero now returns zero instead of throwing a integer division by zero exception
From: rconde rcond...@outlook.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c | 22 --
src/gallium/auxiliary/tgsi/tgsi_exec.c | 8
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c
index b9546db..72be171 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c
@@ -1248,8 +1248,26 @@ idiv_emit_cpu(
struct lp_build_tgsi_context * bld_base,
struct lp_build_emit_data * emit_data)
{
- emit_data-output[emit_data-chan] = lp_build_div(bld_base-int_bld,
- emit_data-args[0], emit_data-args[1]);
+ LLVMBuilderRef builder = bld_base-base.gallivm-builder;
+ LLVMValueRef div_mask = lp_build_cmp(bld_base-uint_bld,
+PIPE_FUNC_EQUAL, emit_data-args[1],
+bld_base-uint_bld.zero);
+ /* We want to make sure that we never divide/mod by zero to not
+* generate sigfpe. We don't want to crash just because the
+* shader is doing something weird. */
+ LLVMValueRef divisor = LLVMBuildOr(builder,
+ div_mask,
+ emit_data-args[1], );
+ LLVMValueRef result = lp_build_div(bld_base-uint_bld,
+ emit_data-args[0], divisor);
+
+ LLVMValueRef not_div_mask = LLVMBuildNot(builder,
+div_mask,);
+
+ /* idiv by zero is guaranteed to return 0x */
+ emit_data-output[emit_data-chan] = LLVMBuildAnd(builder,
+ not_div_mask,
+ result, );
}
/* TGSI_OPCODE_INEG (CPU Only) */
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 6dae379..7794801 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -3343,10 +3343,10 @@ micro_idiv(union tgsi_exec_channel *dst,
const union tgsi_exec_channel *src0,
const union tgsi_exec_channel *src1)
{
- dst-i[0] = src0-i[0] / src1-i[0];
- dst-i[1] = src0-i[1] / src1-i[1];
- dst-i[2] = src0-i[2] / src1-i[2];
- dst-i[3] = src0-i[3] / src1-i[3];
+ dst-i[0] = src1-i[0] ? src0-i[0] / src1-i[0] : 0;
+ dst-i[1] = src1-i[1] ? src0-i[1] / src1-i[1] : 0;
+ dst-i[2] = src1-i[2] ? src0-i[2] / src1-i[2] : 0;
+ dst-i[3] = src1-i[3] ? src0-i[3] / src1-i[3] : 0;
}
static void
--
1.9.0.msysgit.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/11] mesa: Add MESA_FORMAT_{A8R8G8B8, X8R8G8B8, X8B8G8R8}_SRGB
On 17 September 2014 09:56, Jason Ekstrand ja...@jlekstrand.net wrote:
Got a couple comments below. Other than that,
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
On Mon, Sep 15, 2014 at 11:28 PM, Dave Airlie airl...@gmail.com wrote:
From: Richard Sandiford rsand...@linux.vnet.ibm.com
This means that each SRGB format has a reversed counterpart,
which is necessary for handling big-endian mesa-gallium mappings.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
src/mesa/main/format_pack.c | 60
+
src/mesa/main/format_unpack.c | 42 +
src/mesa/main/formats.c | 16 +++
src/mesa/main/formats.csv | 3 ++
src/mesa/main/formats.h | 3 ++
src/mesa/main/texformat.c | 10 +
src/mesa/swrast/s_texfetch.c| 3 ++
src/mesa/swrast/s_texfetch_tmp.h| 24 ++
9 files changed, 162 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index b726c27..21b8adb 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -517,6 +517,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
[MESA_FORMAT_B5G5R5X1_UNORM] = BRW_SURFACEFORMAT_B5G5R5X1_UNORM,
[MESA_FORMAT_R8G8B8X8_SNORM] = 0,
[MESA_FORMAT_R8G8B8X8_SRGB] = 0,
+ [MESA_FORMAT_X8B8G8R8_SRGB] = 0,
Any particular reason you go out of your way to add X8B8G8R8_SRGB and not
the other two?
no good one, I'll fix that up.
+static void
+pack_float_X8B8G8R8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLuint *d = (GLuint *) dst;
+ GLubyte r = util_format_linear_float_to_srgb_8unorm(src[RCOMP]);
+ GLubyte g = util_format_linear_float_to_srgb_8unorm(src[GCOMP]);
+ GLubyte b = util_format_linear_float_to_srgb_8unorm(src[BCOMP]);
+ *d = PACK_COLOR_(r, g, b, 127);
That should be a max of 255, these aren't SNORM formats
These two are taken from equivalent code in
pack_float_B8G8R8X8_SRGB
that is currently in mesa, so I should send a patch to fix those up as well?
Thanks,
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: fix SRGB alpha channel value in pack_float_R8G8B8X8_SRGB
From: Dave Airlie airl...@redhat.com Jason pointed out the bug on review adding new formats, but the existing format also appears to have the bug, so use 255 as the max, these are SRGB no SNORM. Signed-off-by: Dave Airlie airl...@redhat.com --- src/mesa/main/format_pack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c index 6cbf859..6bf174a 100644 --- a/src/mesa/main/format_pack.c +++ b/src/mesa/main/format_pack.c @@ -1713,7 +1713,7 @@ pack_float_R8G8B8X8_SRGB(const GLfloat src[4], void *dst) GLubyte r = util_format_linear_float_to_srgb_8unorm(src[RCOMP]); GLubyte g = util_format_linear_float_to_srgb_8unorm(src[GCOMP]); GLubyte b = util_format_linear_float_to_srgb_8unorm(src[BCOMP]); - *d = PACK_COLOR_(127, b, g, r); + *d = PACK_COLOR_(255, b, g, r); } -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] New stable-branch 10.2 candidate pushed
Hello list, It is time for another bi-weekly stable candidate. Currently we have - 19 queued - 3 nominated (outstanding) - and 0 rejected patches Take a look at section Mesa stable queue for more information. Regressions - classic swrast Tests: - glean/glsl1-matrix column check (1) Offending commit 92427707243(mesa: set UniformBooleanTrue = 1.0f by default). As the same commit fixes a couple of regressions (see below) I intend to keep the commit unless someone explicitly requests otherwise. No other regressions were noticed for classic and gallium swrast. Fixes - classic swrast -- Tests: - glean/fragProg1-CMP - glean/glsl1-Preprocessor test 11 (#elif) The above two tests regressed in the 10.2.7 release but has been fixed since then :) Testing reports/general approval Any testing reports (or general approval of the state of the branch) will be greatly appreciated. Trivial merge conflicts --- Here are the commits where I manually merged conflicts, (so these might merit additional review): commit c68183afef3ee29e56f6d0b5571ad6e79664247b Author: Roland Scheidegger srol...@vmware.com gallivm: set mcpu when initializing llvm execution engine (cherry picked from commit cad60420d5ea36a4b6fa2e6c91317f71423aa63e) As usual the plan is to have the next stable (10.2.8) released on Friday, so if you have any questions or comments that you would like to share before the release, please go ahead. Cheers, Emil Mesa stable queue - Nominated (3) = Jonathan Gray (1): configure.ac: detect LLVM patch level when built via cmake Tom Stellard (2): radeonsi: Program RASTER_CONFIG for harvested GPUs v4 R600/SI: radeonsi: Program RASTER_CONFIG for harvested GPUs v3 Queued (19) === Aaron Watry (1): gallivm: Fix build after LLVM commit 211259 Christoph Bumiller (2): nv50/ir/util: fix BitSet issues nvc0/ir: clarify recursion fix to finding first tex uses Ilia Mirkin (4): nv50/ir: avoid array overrun when checking for supported mods nouveau: only enable the depth test if there actually is a depth buffer nouveau: only enable stencil func if the visual has stencil bits nouveau: change internal variables to avoid conflicts with macro args Jonathan Gray (1): configure.ac: strip _GNU_SOURCE from llvm-config output José Fonseca (1): gallivm: Disable workaround for PR12833 on LLVM 3.2+. Maarten Lankhorst (4): nouveau: re-allocate bo's on overflow nouveau: fix MPEG4 hw decoding nouveau: rework reference frame handling nouveau: remove unneeded assert Marek Olšák (3): r600g,radeonsi: make sure there's enough CS space before resuming queries mesa: set UniformBooleanTrue = 1.0f by default st/mesa: use 1.0f as boolean true on drivers without integer support Richard Sandiford (1): gallivm: Fix uses of 2^24 Roland Scheidegger (1): gallivm: set mcpu when initializing llvm execution engine Thomas Hellstrom (1): winsys/svga: Fix incorrect type usage in IOCTL v2 signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83735] [mesa-10.2.x] broken with llvm-3.5 and old CPUs
https://bugs.freedesktop.org/show_bug.cgi?id=83735 Emil Velikov emil.l.veli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Emil Velikov emil.l.veli...@gmail.com --- Thanks gents. I've slightly tweaked the second patch and push both in. They should be out with mesa 10.2.8 coming this Friday -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/11] mesa: Add MESA_FORMAT_{A8R8G8B8, X8R8G8B8, X8B8G8R8}_SRGB
On Sep 16, 2014 6:54 PM, Dave Airlie airl...@gmail.com wrote:
On 17 September 2014 09:56, Jason Ekstrand ja...@jlekstrand.net wrote:
Got a couple comments below. Other than that,
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
On Mon, Sep 15, 2014 at 11:28 PM, Dave Airlie airl...@gmail.com wrote:
From: Richard Sandiford rsand...@linux.vnet.ibm.com
This means that each SRGB format has a reversed counterpart,
which is necessary for handling big-endian mesa-gallium mappings.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
src/mesa/main/format_pack.c | 60
+
src/mesa/main/format_unpack.c | 42 +
src/mesa/main/formats.c | 16 +++
src/mesa/main/formats.csv | 3 ++
src/mesa/main/formats.h | 3 ++
src/mesa/main/texformat.c | 10 +
src/mesa/swrast/s_texfetch.c| 3 ++
src/mesa/swrast/s_texfetch_tmp.h| 24 ++
9 files changed, 162 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index b726c27..21b8adb 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -517,6 +517,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
[MESA_FORMAT_B5G5R5X1_UNORM] = BRW_SURFACEFORMAT_B5G5R5X1_UNORM,
[MESA_FORMAT_R8G8B8X8_SNORM] = 0,
[MESA_FORMAT_R8G8B8X8_SRGB] = 0,
+ [MESA_FORMAT_X8B8G8R8_SRGB] = 0,
Any particular reason you go out of your way to add X8B8G8R8_SRGB and
not
the other two?
no good one, I'll fix that up.
+static void
+pack_float_X8B8G8R8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLuint *d = (GLuint *) dst;
+ GLubyte r = util_format_linear_float_to_srgb_8unorm(src[RCOMP]);
+ GLubyte g = util_format_linear_float_to_srgb_8unorm(src[GCOMP]);
+ GLubyte b = util_format_linear_float_to_srgb_8unorm(src[BCOMP]);
+ *d = PACK_COLOR_(r, g, b, 127);
That should be a max of 255, these aren't SNORM formats
These two are taken from equivalent code in
pack_float_B8G8R8X8_SRGB
that is currently in mesa, so I should send a patch to fix those up as
well?
Yes, unless I'm going crazy. (Which is always a possibility.)
--Jason
Thanks,
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix SRGB alpha channel value in pack_float_R8G8B8X8_SRGB
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com On Sep 16, 2014 6:57 PM, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com Jason pointed out the bug on review adding new formats, but the existing format also appears to have the bug, so use 255 as the max, these are SRGB no SNORM. Signed-off-by: Dave Airlie airl...@redhat.com --- src/mesa/main/format_pack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c index 6cbf859..6bf174a 100644 --- a/src/mesa/main/format_pack.c +++ b/src/mesa/main/format_pack.c @@ -1713,7 +1713,7 @@ pack_float_R8G8B8X8_SRGB(const GLfloat src[4], void *dst) GLubyte r = util_format_linear_float_to_srgb_8unorm(src[RCOMP]); GLubyte g = util_format_linear_float_to_srgb_8unorm(src[GCOMP]); GLubyte b = util_format_linear_float_to_srgb_8unorm(src[BCOMP]); - *d = PACK_COLOR_(127, b, g, r); + *d = PACK_COLOR_(255, b, g, r); } -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] r600g: Implement GL_ARB_sample_shading
Tested with v3. I get the same result as before: everything is fine
except the gs-atan-vec2 test.
I don't know if this is of any value, but running the command manually
in a shell gives the following:
/home/ademers/projects/display/piglit/bin/shader_runner
/home/ademers/projects/display/piglit/generated_tests/spec/glsl-1.50/execution/built-in-functions/gs-atan-vec4.shader_test
-auto
PIGLIT: {result: pass }
I assume the test ran correctly, but not in the context of the piglit
run, am I right?
Alexandre Demers
On 15/09/14 01:15 AM, Alexandre Demers wrote:
Sorry for the delay, I've been away for work and with not much free
time lately.
I'll have a look at it as soon as possible.
Alexandre Demers
On 10/09/14 06:16 AM, Glenn Kennard wrote:
On Sat, 06 Sep 2014 04:00:01 +0200, Alexandre Demers
alexandre.f.dem...@gmail.com wrote:
Thanks Marek, you were right.
So, on cayman, after comparing results from both runs, it seems
there is only one regression which is gs-atan-vec2 under glsl-1.50:
piglit/bin/shader_runner
/home/ademers/projects/display/piglit/generated_tests/spec/glsl-1.50/execution/built-in-functions/gs-atan-vec2.shader_test
-auto
The returned value is the following:
Probe color at (5,0)
Expected: 0.00 1.00 0.00 1.00
Observed: 1.00 0.00 0.00 1.00
I've found that some of the piglit geometry shader tests tend to fail
once one GPU reset has occurred, and persist until the next power
cycle. Did you do a cold restart after the x crash and re-running the
tests? Might be worth trying just re-running the failing test after a
restart and see if it goes away.
/Glenn
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
