[Mesa-dev] [PATCH 0/6] Make gl_array_object use an array of gl_client_attribs V2
Hi,
following a patch series to make gl_array_object use a VERT_ATTRIB_*
indexed array of gl_client_array structs.
Since we have already 33 client arrays in an array object the VERT_BIT_* and
for vertex shader inputs bitmaps are extended to 64 bits. Drivers
and shader code is updated to use the 64 bits bitmasks for
the vertex array inputs.
Changes since V1:
Compute VERT_BIT*ALL defines. Remove consistency checks.
Squash all three 'Make gl_program::InputsRead 64 bits' into a single patch.
Omit the last two patches which need some further thoughts.
Update a few requested minor changes.
The patchset survives a r600 piglit run on my favourite rv670 development
machine with no regressions.
Please review.
Thanks
Mathias
Mathias Fröhlich (6):
mesa: Introduce more symbolic VERT_{ATTRIB,BIT}* defines.
mesa: Replace _NEW_ARRAY_* bits with VERT_BIT_*
vbo: Use The VERT_{ATTRIB,BIT} defines.
mesa: Make gl_array_object::_Enabled 64 bits.
mesa: Make gl_program::InputsRead 64 bits.
mesa: Use VERT_ATTRIB_* indexed array in gl_array_object.
src/mesa/drivers/dri/i915/i915_fragprog.c |4 +-
src/mesa/drivers/dri/i965/brw_context.h|2 +-
src/mesa/drivers/dri/i965/brw_draw_upload.c|6 +-
src/mesa/drivers/dri/i965/brw_vs.c |4 +-
src/mesa/drivers/dri/i965/brw_vs_constval.c|2 +-
src/mesa/drivers/dri/i965/brw_vs_emit.c|4 +-
src/mesa/drivers/dri/i965/gen6_wm_state.c |2 +-
src/mesa/drivers/dri/i965/gen7_wm_state.c |2 +-
src/mesa/drivers/dri/r200/r200_vertprog.c | 31 +++--
src/mesa/main/api_arrayelt.c | 38 +++---
src/mesa/main/api_validate.c |6 +-
src/mesa/main/arrayobj.c | 96 +---
src/mesa/main/attrib.c | 13 --
src/mesa/main/bufferobj.c | 11 --
src/mesa/main/context.c|2 +-
src/mesa/main/enable.c | 66
src/mesa/main/ff_fragment_shader.cpp |2 +-
src/mesa/main/ffvertex_prog.c | 18 +-
src/mesa/main/get.c| 98 ++--
src/mesa/main/getstring.c | 18 +-
src/mesa/main/mtypes.h | 199 ++-
src/mesa/main/nvprogram.c |8 +-
src/mesa/main/state.c | 85 +-
src/mesa/main/state.h |2 +-
src/mesa/main/varray.c | 110 ++---
src/mesa/program/program_parse.y |6 +-
src/mesa/program/programopt.c |4 +-
src/mesa/state_tracker/st_atom_pixeltransfer.c |2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |8 +-
src/mesa/state_tracker/st_program.c| 10 +-
src/mesa/tnl/t_vb_program.c|2 +-
src/mesa/vbo/vbo_attrib.h | 59
src/mesa/vbo/vbo_context.c | 26 ++--
src/mesa/vbo/vbo_exec.h|4 +-
src/mesa/vbo/vbo_exec_api.c| 24 ++-
src/mesa/vbo/vbo_exec_array.c | 86 ---
src/mesa/vbo/vbo_exec_draw.c | 24 ++--
src/mesa/vbo/vbo_save.c| 24 ++-
src/mesa/vbo/vbo_save_draw.c | 18 ++-
39 files changed, 524 insertions(+), 602 deletions(-)
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] mesa: Introduce more symbolic VERT_{ATTRIB, BIT}* defines.
Introduce a set of defines for VERT_ATTRIB_* and VERT_BIT_* that will be used in the followup patches. Signed-off-by: Mathias Froehlich mathias.froehl...@web.de --- src/mesa/main/mtypes.h | 63 ++- 1 files changed, 45 insertions(+), 18 deletions(-) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 96a4426..f7ec781 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -140,6 +140,35 @@ typedef enum } gl_vert_attrib; /** + * Symbolic constats to help iterating over + * specific blocks of vertex attributes. + * + * VERT_ATTRIB_FF + * includes all fixed function attributes as well as + * the aliased GL_NV_vertex_program shader attributes. + * VERT_ATTRIB_TEX + * include the classic texture coordinate attributes. + * Is a subset of VERT_ATTRIB_FF. + * VERT_ATTRIB_GENERIC_NV + * include the NV shader attributes. + * Is a subset of VERT_ATTRIB_FF. + * VERT_ATTRIB_GENERIC + * include the OpenGL 2.0+ GLSL generic shader attributes. + * These alias the generic GL_ARB_vertex_shader attributes. + */ +#define VERT_ATTRIB_FF(i) (VERT_ATTRIB_POS + (i)) +#define VERT_ATTRIB_FF_MAX VERT_ATTRIB_GENERIC0 + +#define VERT_ATTRIB_TEX(i) (VERT_ATTRIB_TEX0 + (i)) +#define VERT_ATTRIB_TEX_MAX MAX_TEXTURE_COORD_UNITS + +#define VERT_ATTRIB_GENERIC_NV(i) (VERT_ATTRIB_POS + (i)) +#define VERT_ATTRIB_GENERIC_NV_MAX MAX_VERTEX_GENERIC_ATTRIBS + +#define VERT_ATTRIB_GENERIC(i) (VERT_ATTRIB_GENERIC0 + (i)) +#define VERT_ATTRIB_GENERIC_MAX MAX_VERTEX_GENERIC_ATTRIBS + +/** * Bitflags for vertex attributes. * These are used in bitfields in many places. */ @@ -151,6 +180,7 @@ typedef enum #define VERT_BIT_COLOR1 (1 VERT_ATTRIB_COLOR1) #define VERT_BIT_FOG (1 VERT_ATTRIB_FOG) #define VERT_BIT_COLOR_INDEX (1 VERT_ATTRIB_COLOR_INDEX) +#define VERT_BIT_POINT_SIZE (1 VERT_ATTRIB_POINT_SIZE) #define VERT_BIT_EDGEFLAG(1 VERT_ATTRIB_EDGEFLAG) #define VERT_BIT_TEX0(1 VERT_ATTRIB_TEX0) #define VERT_BIT_TEX1(1 VERT_ATTRIB_TEX1) @@ -161,24 +191,21 @@ typedef enum #define VERT_BIT_TEX6(1 VERT_ATTRIB_TEX6) #define VERT_BIT_TEX7(1 VERT_ATTRIB_TEX7) #define VERT_BIT_GENERIC0(1 VERT_ATTRIB_GENERIC0) -#define VERT_BIT_GENERIC1(1 VERT_ATTRIB_GENERIC1) -#define VERT_BIT_GENERIC2(1 VERT_ATTRIB_GENERIC2) -#define VERT_BIT_GENERIC3(1 VERT_ATTRIB_GENERIC3) -#define VERT_BIT_GENERIC4(1 VERT_ATTRIB_GENERIC4) -#define VERT_BIT_GENERIC5(1 VERT_ATTRIB_GENERIC5) -#define VERT_BIT_GENERIC6(1 VERT_ATTRIB_GENERIC6) -#define VERT_BIT_GENERIC7(1 VERT_ATTRIB_GENERIC7) -#define VERT_BIT_GENERIC8(1 VERT_ATTRIB_GENERIC8) -#define VERT_BIT_GENERIC9(1 VERT_ATTRIB_GENERIC9) -#define VERT_BIT_GENERIC10 (1 VERT_ATTRIB_GENERIC10) -#define VERT_BIT_GENERIC11 (1 VERT_ATTRIB_GENERIC11) -#define VERT_BIT_GENERIC12 (1 VERT_ATTRIB_GENERIC12) -#define VERT_BIT_GENERIC13 (1 VERT_ATTRIB_GENERIC13) -#define VERT_BIT_GENERIC14 (1 VERT_ATTRIB_GENERIC14) -#define VERT_BIT_GENERIC15 (1 VERT_ATTRIB_GENERIC15) - -#define VERT_BIT_TEX(u) (1 (VERT_ATTRIB_TEX0 + (u))) -#define VERT_BIT_GENERIC(g) (1 (VERT_ATTRIB_GENERIC0 + (g))) + +#define VERT_BIT(i) (1 (i)) +#define VERT_BIT_ALL ((1 VERT_ATTRIB_MAX) - 1) + +#define VERT_BIT_FF(i) VERT_BIT(i) +#define VERT_BIT_FF_ALL ((1 VERT_ATTRIB_FF_MAX) - 1) +#define VERT_BIT_TEX(i) VERT_BIT(VERT_ATTRIB_TEX(i)) +#define VERT_BIT_TEX_ALL \ + (((1 VERT_ATTRIB_TEX_MAX) - 1) VERT_ATTRIB_TEX(0)) +#define VERT_BIT_GENERIC_NV(i) VERT_BIT(VERT_ATTRIB_GENERIC_NV(i)) +#define VERT_BIT_GENERIC_NV_ALL \ + (((1 VERT_ATTRIB_GENERIC_NV_MAX) - 1) (VERT_ATTRIB_GENERIC_NV(0))) +#define VERT_BIT_GENERIC(i) VERT_BIT(VERT_ATTRIB_GENERIC(i)) +#define VERT_BIT_GENERIC_ALL \ + (((1 VERT_ATTRIB_GENERIC_MAX) - 1) (VERT_ATTRIB_GENERIC(0))) /*@}*/ -- 1.7.4.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] mesa: Replace _NEW_ARRAY_* bits with VERT_BIT_*
Consolidate the two distinct set of flags to use VERT_BIT_*.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
Reviewed-by: Brian Paul bri...@vmware.com
---
src/mesa/main/arrayobj.c |2 +-
src/mesa/main/enable.c | 20 ++--
src/mesa/main/mtypes.h | 37 ++---
src/mesa/main/varray.c | 36 ++--
4 files changed, 31 insertions(+), 64 deletions(-)
diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index 1283940..5524f1f 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -380,7 +380,7 @@ bind_vertex_array(struct gl_context *ctx, GLuint id,
GLboolean genRequired)
}
ctx-NewState |= _NEW_ARRAY;
- ctx-Array.NewState |= _NEW_ARRAY_ALL;
+ ctx-Array.NewState |= VERT_BIT_ALL;
_mesa_reference_array_object(ctx, ctx-Array.ArrayObj, newObj);
/* Pass BindVertexArray call to device driver */
diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index b2c7724..e9b7fa0 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -60,41 +60,41 @@ client_state(struct gl_context *ctx, GLenum cap, GLboolean
state)
switch (cap) {
case GL_VERTEX_ARRAY:
var = arrayObj-Vertex.Enabled;
- flag = _NEW_ARRAY_VERTEX;
+ flag = VERT_BIT_POS;
break;
case GL_NORMAL_ARRAY:
var = arrayObj-Normal.Enabled;
- flag = _NEW_ARRAY_NORMAL;
+ flag = VERT_BIT_NORMAL;
break;
case GL_COLOR_ARRAY:
var = arrayObj-Color.Enabled;
- flag = _NEW_ARRAY_COLOR0;
+ flag = VERT_BIT_COLOR0;
break;
case GL_INDEX_ARRAY:
var = arrayObj-Index.Enabled;
- flag = _NEW_ARRAY_INDEX;
+ flag = VERT_BIT_COLOR_INDEX;
break;
case GL_TEXTURE_COORD_ARRAY:
var = arrayObj-TexCoord[ctx-Array.ActiveTexture].Enabled;
- flag = _NEW_ARRAY_TEXCOORD(ctx-Array.ActiveTexture);
+ flag = VERT_BIT_TEX(ctx-Array.ActiveTexture);
break;
case GL_EDGE_FLAG_ARRAY:
var = arrayObj-EdgeFlag.Enabled;
- flag = _NEW_ARRAY_EDGEFLAG;
+ flag = VERT_BIT_EDGEFLAG;
break;
case GL_FOG_COORDINATE_ARRAY_EXT:
var = arrayObj-FogCoord.Enabled;
- flag = _NEW_ARRAY_FOGCOORD;
+ flag = VERT_BIT_FOG;
break;
case GL_SECONDARY_COLOR_ARRAY_EXT:
var = arrayObj-SecondaryColor.Enabled;
- flag = _NEW_ARRAY_COLOR1;
+ flag = VERT_BIT_COLOR1;
break;
#if FEATURE_point_size_array
case GL_POINT_SIZE_ARRAY_OES:
var = arrayObj-PointSize.Enabled;
- flag = _NEW_ARRAY_POINT_SIZE;
+ flag = VERT_BIT_POINT_SIZE;
break;
#endif
@@ -120,7 +120,7 @@ client_state(struct gl_context *ctx, GLenum cap, GLboolean
state)
GLint n = (GLint) cap - GL_VERTEX_ATTRIB_ARRAY0_NV;
ASSERT(n Elements(ctx-Array.ArrayObj-VertexAttrib));
var = arrayObj-VertexAttrib[n].Enabled;
-flag = _NEW_ARRAY_ATTRIB(n);
+flag = VERT_BIT_GENERIC(n);
}
break;
#endif /* FEATURE_NV_vertex_program */
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index f7ec781..050ebd9 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1639,7 +1639,7 @@ struct gl_array_object
*/
struct gl_client_array VertexAttrib[MAX_VERTEX_GENERIC_ATTRIBS];
- /** Mask of _NEW_ARRAY_* values indicating which arrays are enabled */
+ /** Mask of VERT_BIT_* values indicating which arrays are enabled */
GLbitfield _Enabled;
/**
@@ -1672,7 +1672,7 @@ struct gl_array_attrib
GLboolean PrimitiveRestart;
GLuint RestartIndex;
- GLbitfield NewState;/** mask of _NEW_ARRAY_* values */
+ GLbitfield NewState;/** mask of VERT_BIT_* values */
GLboolean RebindArrays; /** whether the VBO module should rebind arrays
*/
/* GL_ARB_vertex_buffer_object */
@@ -3082,39 +3082,6 @@ struct gl_matrix_stack
/**
- * \name Bits to track array state changes
- *
- * Also used to summarize array enabled.
- */
-/*@{*/
-#define _NEW_ARRAY_VERTEX VERT_BIT_POS
-#define _NEW_ARRAY_WEIGHT VERT_BIT_WEIGHT
-#define _NEW_ARRAY_NORMAL VERT_BIT_NORMAL
-#define _NEW_ARRAY_COLOR0 VERT_BIT_COLOR0
-#define _NEW_ARRAY_COLOR1 VERT_BIT_COLOR1
-#define _NEW_ARRAY_FOGCOORD VERT_BIT_FOG
-#define _NEW_ARRAY_INDEXVERT_BIT_COLOR_INDEX
-#define _NEW_ARRAY_EDGEFLAG VERT_BIT_EDGEFLAG
-#define _NEW_ARRAY_POINT_SIZE VERT_BIT_COLOR_INDEX /* aliased */
-#define _NEW_ARRAY_TEXCOORD_0 VERT_BIT_TEX0
-#define _NEW_ARRAY_TEXCOORD_1 VERT_BIT_TEX1
-#define _NEW_ARRAY_TEXCOORD_2 VERT_BIT_TEX2
-#define _NEW_ARRAY_TEXCOORD_3 VERT_BIT_TEX3
-#define _NEW_ARRAY_TEXCOORD_4 VERT_BIT_TEX4
-#define _NEW_ARRAY_TEXCOORD_5
[Mesa-dev] [PATCH 3/6] vbo: Use The VERT_{ATTRIB,BIT} defines.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
Reviewed-by: Brian Paul bri...@vmware.com
---
src/mesa/vbo/vbo_context.c| 26 +++---
src/mesa/vbo/vbo_exec.h |4 ++--
src/mesa/vbo/vbo_exec_api.c | 24
src/mesa/vbo/vbo_exec_array.c | 41
+
src/mesa/vbo/vbo_exec_draw.c | 22 --
src/mesa/vbo/vbo_save.c | 24
src/mesa/vbo/vbo_save_draw.c | 16 +---
7 files changed, 87 insertions(+), 70 deletions(-)
diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c
index 9de770d..b2e6bbc 100644
--- a/src/mesa/vbo/vbo_context.c
+++ b/src/mesa/vbo/vbo_context.c
@@ -33,13 +33,8 @@
#include vbo.h
#include vbo_context.h
-
-
-#define NR_LEGACY_ATTRIBS 16
-#define NR_GENERIC_ATTRIBS 16
#define NR_MAT_ATTRIBS 12
-
static GLuint check_size( const GLfloat *attr )
{
if (attr[3] != 1.0) return 4;
@@ -55,12 +50,12 @@ static void init_legacy_currval(struct gl_context *ctx)
struct gl_client_array *arrays = vbo-legacy_currval;
GLuint i;
- memset(arrays, 0, sizeof(*arrays) * NR_LEGACY_ATTRIBS);
+ memset(arrays, 0, sizeof(*arrays) * VERT_ATTRIB_FF_MAX);
/* Set up a constant (StrideB == 0) array for each current
* attribute:
*/
- for (i = 0; i NR_LEGACY_ATTRIBS; i++) {
+ for (i = 0; i VERT_ATTRIB_FF_MAX; i++) {
struct gl_client_array *cl = arrays[i];
/* Size will have to be determined at runtime:
@@ -85,9 +80,9 @@ static void init_generic_currval(struct gl_context *ctx)
struct gl_client_array *arrays = vbo-generic_currval;
GLuint i;
- memset(arrays, 0, sizeof(*arrays) * NR_GENERIC_ATTRIBS);
+ memset(arrays, 0, sizeof(*arrays) * VERT_ATTRIB_GENERIC_MAX);
- for (i = 0; i NR_GENERIC_ATTRIBS; i++) {
+ for (i = 0; i VERT_ATTRIB_GENERIC_MAX; i++) {
struct gl_client_array *cl = arrays[i];
/* This will have to be determined at runtime:
@@ -182,14 +177,15 @@ GLboolean _vbo_CreateContext( struct gl_context *ctx )
GLuint i;
/* When no vertex program, pull in the material attributes in
- * the 16..32 generic range.
+ * the generic range.
*/
- for (i = 0; i 16; i++)
+ for (i = 0; i VERT_ATTRIB_FF_MAX; i++)
vbo-map_vp_none[i] = i;
- for (i = 0; i 12; i++)
-vbo-map_vp_none[16+i] = VBO_ATTRIB_MAT_FRONT_AMBIENT + i;
- for (i = 0; i 4; i++)
-vbo-map_vp_none[28+i] = i;
+ for (i = 0; i NR_MAT_ATTRIBS; i++)
+vbo-map_vp_none[VERT_ATTRIB_GENERIC(i)]
+= VBO_ATTRIB_MAT_FRONT_AMBIENT + i;
+ for (i = NR_MAT_ATTRIBS; i VERT_ATTRIB_GENERIC_MAX; i++)
+vbo-map_vp_none[VERT_ATTRIB_GENERIC(i)] = i;
for (i = 0; i Elements(vbo-map_vp_arb); i++)
vbo-map_vp_arb[i] = i;
diff --git a/src/mesa/vbo/vbo_exec.h b/src/mesa/vbo/vbo_exec.h
index 8d6b8f9..cfed8e8 100644
--- a/src/mesa/vbo/vbo_exec.h
+++ b/src/mesa/vbo/vbo_exec.h
@@ -125,8 +125,8 @@ struct vbo_exec_context
/* These just mirror the current arrayobj (todo: make arrayobj
* look like this and remove the mirror):
*/
- const struct gl_client_array *legacy_array[16];
- const struct gl_client_array *generic_array[16];
+ const struct gl_client_array *legacy_array[VERT_ATTRIB_FF_MAX];
+ const struct gl_client_array *generic_array[VERT_ATTRIB_GENERIC_MAX];
/* Arrays and current values manipulated according to program
* mode, etc. These are the attributes as seen by vertex
diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
index 62e7d03..70551e0 100644
--- a/src/mesa/vbo/vbo_exec_api.c
+++ b/src/mesa/vbo/vbo_exec_api.c
@@ -1091,15 +1091,23 @@ void vbo_exec_vtx_init( struct vbo_exec_context *exec
)
struct gl_client_array *arrays = exec-vtx.arrays;
unsigned i;
- memcpy(arrays, vbo-legacy_currval, 16 * sizeof(arrays[0]));
- memcpy(arrays + 16, vbo-generic_currval, 16 * sizeof(arrays[0]));
-
- for (i = 0; i 16; ++i) {
- arrays[i ].BufferObj = NULL;
- arrays[i + 16].BufferObj = NULL;
- _mesa_reference_buffer_object(ctx, arrays[i ].BufferObj,
+ memcpy(arrays, vbo-legacy_currval,
+ VERT_ATTRIB_FF_MAX * sizeof(arrays[0]));
+ for (i = 0; i VERT_ATTRIB_FF_MAX; ++i) {
+ struct gl_client_array *array;
+ array = arrays[VERT_ATTRIB_FF(i)];
+ array-BufferObj = NULL;
+ _mesa_reference_buffer_object(ctx, arrays-BufferObj,
vbo-legacy_currval[i].BufferObj);
- _mesa_reference_buffer_object(ctx, arrays[i + 16].BufferObj,
+ }
+
+ memcpy(arrays + VERT_ATTRIB_GENERIC(0), vbo-generic_currval,
+ VERT_ATTRIB_GENERIC_MAX * sizeof(arrays[0]));
+ for (i = 0; i VERT_ATTRIB_GENERIC_MAX; ++i) {
+ struct gl_client_array
[Mesa-dev] [PATCH 4/6] mesa: Make gl_array_object::_Enabled 64 bits.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
Reviewed-by: Brian Paul bri...@vmware.com
---
src/mesa/main/enable.c |2 +-
src/mesa/main/mtypes.h | 54
src/mesa/main/varray.c |2 +-
3 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index e9b7fa0..f45589f 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -54,7 +54,7 @@ static void
client_state(struct gl_context *ctx, GLenum cap, GLboolean state)
{
struct gl_array_object *arrayObj = ctx-Array.ArrayObj;
- GLuint flag;
+ GLbitfield64 flag;
GLboolean *var;
switch (cap) {
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 050ebd9..5724681 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -173,39 +173,39 @@ typedef enum
* These are used in bitfields in many places.
*/
/*@{*/
-#define VERT_BIT_POS (1 VERT_ATTRIB_POS)
-#define VERT_BIT_WEIGHT (1 VERT_ATTRIB_WEIGHT)
-#define VERT_BIT_NORMAL (1 VERT_ATTRIB_NORMAL)
-#define VERT_BIT_COLOR0 (1 VERT_ATTRIB_COLOR0)
-#define VERT_BIT_COLOR1 (1 VERT_ATTRIB_COLOR1)
-#define VERT_BIT_FOG (1 VERT_ATTRIB_FOG)
-#define VERT_BIT_COLOR_INDEX (1 VERT_ATTRIB_COLOR_INDEX)
-#define VERT_BIT_POINT_SIZE (1 VERT_ATTRIB_POINT_SIZE)
-#define VERT_BIT_EDGEFLAG(1 VERT_ATTRIB_EDGEFLAG)
-#define VERT_BIT_TEX0(1 VERT_ATTRIB_TEX0)
-#define VERT_BIT_TEX1(1 VERT_ATTRIB_TEX1)
-#define VERT_BIT_TEX2(1 VERT_ATTRIB_TEX2)
-#define VERT_BIT_TEX3(1 VERT_ATTRIB_TEX3)
-#define VERT_BIT_TEX4(1 VERT_ATTRIB_TEX4)
-#define VERT_BIT_TEX5(1 VERT_ATTRIB_TEX5)
-#define VERT_BIT_TEX6(1 VERT_ATTRIB_TEX6)
-#define VERT_BIT_TEX7(1 VERT_ATTRIB_TEX7)
-#define VERT_BIT_GENERIC0(1 VERT_ATTRIB_GENERIC0)
-
-#define VERT_BIT(i) (1 (i))
-#define VERT_BIT_ALL ((1 VERT_ATTRIB_MAX) - 1)
+#define VERT_BIT_POS BITFIELD64_BIT(VERT_ATTRIB_POS)
+#define VERT_BIT_WEIGHT BITFIELD64_BIT(VERT_ATTRIB_WEIGHT)
+#define VERT_BIT_NORMAL BITFIELD64_BIT(VERT_ATTRIB_NORMAL)
+#define VERT_BIT_COLOR0 BITFIELD64_BIT(VERT_ATTRIB_COLOR0)
+#define VERT_BIT_COLOR1 BITFIELD64_BIT(VERT_ATTRIB_COLOR1)
+#define VERT_BIT_FOG BITFIELD64_BIT(VERT_ATTRIB_FOG)
+#define VERT_BIT_COLOR_INDEX BITFIELD64_BIT(VERT_ATTRIB_COLOR_INDEX)
+#define VERT_BIT_POINT_SIZE BITFIELD64_BIT(VERT_ATTRIB_POINT_SIZE)
+#define VERT_BIT_EDGEFLAGBITFIELD64_BIT(VERT_ATTRIB_EDGEFLAG)
+#define VERT_BIT_TEX0BITFIELD64_BIT(VERT_ATTRIB_TEX0)
+#define VERT_BIT_TEX1BITFIELD64_BIT(VERT_ATTRIB_TEX1)
+#define VERT_BIT_TEX2BITFIELD64_BIT(VERT_ATTRIB_TEX2)
+#define VERT_BIT_TEX3BITFIELD64_BIT(VERT_ATTRIB_TEX3)
+#define VERT_BIT_TEX4BITFIELD64_BIT(VERT_ATTRIB_TEX4)
+#define VERT_BIT_TEX5BITFIELD64_BIT(VERT_ATTRIB_TEX5)
+#define VERT_BIT_TEX6BITFIELD64_BIT(VERT_ATTRIB_TEX6)
+#define VERT_BIT_TEX7BITFIELD64_BIT(VERT_ATTRIB_TEX7)
+#define VERT_BIT_GENERIC0BITFIELD64_BIT(VERT_ATTRIB_GENERIC0)
+
+#define VERT_BIT(i) BITFIELD64_BIT(i)
+#define VERT_BIT_ALL (BITFIELD64_BIT(VERT_ATTRIB_MAX) - 1)
#define VERT_BIT_FF(i) VERT_BIT(i)
-#define VERT_BIT_FF_ALL ((1 VERT_ATTRIB_FF_MAX) - 1)
+#define VERT_BIT_FF_ALL (BITFIELD64_BIT(VERT_ATTRIB_FF_MAX) - 1)
#define VERT_BIT_TEX(i) VERT_BIT(VERT_ATTRIB_TEX(i))
#define VERT_BIT_TEX_ALL \
- (((1 VERT_ATTRIB_TEX_MAX) - 1) VERT_ATTRIB_TEX(0))
+ ((BITFIELD64_BIT(VERT_ATTRIB_TEX_MAX) - 1) VERT_ATTRIB_TEX(0))
#define VERT_BIT_GENERIC_NV(i) VERT_BIT(VERT_ATTRIB_GENERIC_NV(i))
#define VERT_BIT_GENERIC_NV_ALL \
- (((1 VERT_ATTRIB_GENERIC_NV_MAX) - 1) (VERT_ATTRIB_GENERIC_NV(0)))
+ ((BITFIELD64_BIT(VERT_ATTRIB_GENERIC_NV_MAX) - 1)
(VERT_ATTRIB_GENERIC_NV(0)))
#define VERT_BIT_GENERIC(i) VERT_BIT(VERT_ATTRIB_GENERIC(i))
#define VERT_BIT_GENERIC_ALL \
- (((1 VERT_ATTRIB_GENERIC_MAX) - 1) (VERT_ATTRIB_GENERIC(0)))
+ ((BITFIELD64_BIT(VERT_ATTRIB_GENERIC_MAX) - 1) (VERT_ATTRIB_GENERIC(0)))
/*@}*/
@@ -1640,7 +1640,7 @@ struct gl_array_object
struct gl_client_array VertexAttrib[MAX_VERTEX_GENERIC_ATTRIBS];
/** Mask of VERT_BIT_* values indicating which arrays are enabled */
- GLbitfield _Enabled;
+ GLbitfield64 _Enabled;
/**
* Min of all enabled arrays' _MaxElement. When arrays reside inside VBOs
@@ -1672,7 +1672,7 @@ struct gl_array_attrib
GLboolean PrimitiveRestart;
GLuint RestartIndex;
- GLbitfield NewState;/** mask of VERT_BIT_* values */
+ GLbitfield64 NewState; /** mask of VERT_BIT_* values */
GLboolean RebindArrays; /** whether the VBO module should rebind arrays
*/
/* GL_ARB_vertex_buffer_object */
[Mesa-dev] [PATCH 5/6] mesa: Make gl_program::InputsRead 64 bits.
Make gl_program::InputsRead a 64 bits bitfield.
Adapt the intel and radeon driver to handle a 64 bits
InputsRead value.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/drivers/dri/i915/i915_fragprog.c |4 +-
src/mesa/drivers/dri/i965/brw_context.h|2 +-
src/mesa/drivers/dri/i965/brw_draw_upload.c|6 ++--
src/mesa/drivers/dri/i965/brw_vs.c |4 +-
src/mesa/drivers/dri/i965/brw_vs_constval.c|2 +-
src/mesa/drivers/dri/i965/brw_vs_emit.c|4 +-
src/mesa/drivers/dri/i965/gen6_wm_state.c |2 +-
src/mesa/drivers/dri/i965/gen7_wm_state.c |2 +-
src/mesa/drivers/dri/r200/r200_vertprog.c | 31 +++
src/mesa/main/context.c|2 +-
src/mesa/main/ff_fragment_shader.cpp |2 +-
src/mesa/main/ffvertex_prog.c | 18 +++---
src/mesa/main/mtypes.h |4 +-
src/mesa/main/state.c |2 +-
src/mesa/main/state.h |2 +-
src/mesa/program/program_parse.y |6 ++--
src/mesa/program/programopt.c |4 +-
src/mesa/state_tracker/st_atom_pixeltransfer.c |2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |8 +++---
src/mesa/state_tracker/st_program.c| 10
src/mesa/tnl/t_vb_program.c|2 +-
src/mesa/vbo/vbo_exec_array.c |4 +-
src/mesa/vbo/vbo_exec_draw.c |2 +-
src/mesa/vbo/vbo_save_draw.c |2 +-
24 files changed, 68 insertions(+), 59 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c
b/src/mesa/drivers/dri/i915/i915_fragprog.c
index 063e155..4f016a3 100644
--- a/src/mesa/drivers/dri/i915/i915_fragprog.c
+++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
@@ -1148,7 +1148,7 @@ fixup_depth_write(struct i915_fragment_program *p)
static void
check_wpos(struct i915_fragment_program *p)
{
- GLuint inputs = p-FragProg.Base.InputsRead;
+ GLbitfield64 inputs = p-FragProg.Base.InputsRead;
GLint i;
p-wpos_tex = -1;
@@ -1337,7 +1337,7 @@ i915ValidateFragmentProgram(struct i915_context *i915)
struct i915_fragment_program *p =
(struct i915_fragment_program *) ctx-FragmentProgram._Current;
- const GLuint inputsRead = p-FragProg.Base.InputsRead;
+ const GLbitfield64 inputsRead = p-FragProg.Base.InputsRead;
GLuint s4 = i915-state.Ctx[I915_CTXREG_LIS4] ~S4_VFMT_MASK;
GLuint s2 = S2_TEXCOORD_NONE;
int i, offset = 0;
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index c1b123f5..87675e9 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -379,7 +379,7 @@ struct brw_vs_prog_data {
GLuint nr_pull_params; /** number of dwords referenced by pull_param[] */
GLuint total_scratch;
- GLuint inputs_read;
+ GLbitfield64 inputs_read;
/* Used for calculating urb partitions:
*/
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index bd3d969..b4fd220 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -355,7 +355,7 @@ static void brw_prepare_vertices(struct brw_context *brw)
struct gl_context *ctx = brw-intel.ctx;
struct intel_context *intel = intel_context(ctx);
/* CACHE_NEW_VS_PROG */
- GLbitfield vs_inputs = brw-vs.prog_data-inputs_read;
+ GLbitfield64 vs_inputs = brw-vs.prog_data-inputs_read;
const unsigned char *ptr = NULL;
GLuint interleaved = 0, total_size = 0;
unsigned int min_index = brw-vb.min_index;
@@ -373,10 +373,10 @@ static void brw_prepare_vertices(struct brw_context
*brw)
/* Accumulate the list of enabled arrays. */
brw-vb.nr_enabled = 0;
while (vs_inputs) {
- GLuint i = ffs(vs_inputs) - 1;
+ GLuint i = _mesa_ffsll(vs_inputs) - 1;
struct brw_vertex_element *input = brw-vb.inputs[i];
- vs_inputs = ~(1 i);
+ vs_inputs = ~BITFIELD64_BIT(i);
if (input-glarray-Size get_size(input-glarray-Type))
brw-vb.enabled[brw-vb.nr_enabled++] = input;
}
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
b/src/mesa/drivers/dri/i965/brw_vs.c
index 967f82e..6f9fd6a 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -207,7 +207,7 @@ do_vs_prog(struct brw_context *brw,
if (c.key.copy_edgeflag) {
c.prog_data.outputs_written |= BITFIELD64_BIT(VERT_RESULT_EDGE);
- c.prog_data.inputs_read |= 1VERT_ATTRIB_EDGEFLAG;
+ c.prog_data.inputs_read |= BITFIELD64_BIT(VERT_ATTRIB_EDGEFLAG);
}
/* Put dummy slots into the VUE for the SF to put the replaced
@@ -318,7 +318,7 @@ static void brw_upload_vs_prog(struct brw_context *brw)
/* BRW_NEW_VERTICES */
for (i = 0; i VERT_ATTRIB_MAX; i++) {
-
[Mesa-dev] [PATCH] image/pack: fix missing GL_BGR(A)_INTEGER support.
From: Dave Airlie airl...@redhat.com These codepaths were missing the cases for BGR_INTEGER/BGRA_INTEGER. Signed-off-by: Dave Airlie airl...@redhat.com --- src/mesa/main/image.c |2 ++ src/mesa/main/pack.c |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c index ca31e53..72e944e 100644 --- a/src/mesa/main/image.c +++ b/src/mesa/main/image.c @@ -243,12 +243,14 @@ _mesa_components_in_format( GLenum format ) case GL_RGB: case GL_BGR: case GL_RGB_INTEGER_EXT: + case GL_BGR_INTEGER_EXT: return 3; case GL_RGBA: case GL_BGRA: case GL_ABGR_EXT: case GL_RGBA_INTEGER_EXT: + case GL_BGRA_INTEGER_EXT: return 4; default: diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c index bd85031..4754d34 100644 --- a/src/mesa/main/pack.c +++ b/src/mesa/main/pack.c @@ -2291,6 +2291,7 @@ get_component_mapping(GLenum format, *aDst = 3; break; case GL_BGR: + case GL_BGR_INTEGER: *rSrc = 2; *gSrc = 1; *bSrc = 0; @@ -2312,6 +2313,7 @@ get_component_mapping(GLenum format, *aDst = 3; break; case GL_BGRA: + case GL_BGRA_INTEGER: *rSrc = 2; *gSrc = 1; *bSrc = 0; -- 1.7.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] initial ARB_texture_rgb10_a2ui test (v2)
From: Dave Airlie airl...@redhat.com
This test tries to upload the texture in RGBA/BGRA and 10_10_10_2/2_10_10_10_REV
type/format combinations.
v2: improve test to be less cut-n-paste from older tests and make it a lot
easier to read.
v2 passes on nvidia binary (joi on #nouveau tested it for me), and fails
miserably on fglrx on r600 hw.
Signed-off-by: Dave Airlie airl...@redhat.com
---
tests/spec/CMakeLists.txt |1 +
.../spec/arb_texture_rgb10_a2ui/CMakeLists.gl.txt | 17 ++
tests/spec/arb_texture_rgb10_a2ui/CMakeLists.txt |1 +
.../arb_texture_rgb10_a2ui/texture-rgb10a2ui.c | 263
4 files changed, 282 insertions(+), 0 deletions(-)
create mode 100644 tests/spec/arb_texture_rgb10_a2ui/CMakeLists.gl.txt
create mode 100644 tests/spec/arb_texture_rgb10_a2ui/CMakeLists.txt
create mode 100644 tests/spec/arb_texture_rgb10_a2ui/texture-rgb10a2ui.c
diff --git a/tests/spec/CMakeLists.txt b/tests/spec/CMakeLists.txt
index 863d583..778fec8 100644
--- a/tests/spec/CMakeLists.txt
+++ b/tests/spec/CMakeLists.txt
@@ -37,3 +37,4 @@ add_subdirectory (ext_texture_integer)
add_subdirectory (arb_draw_buffers)
add_subdirectory (oes_draw_texture)
add_subdirectory (arb_blend_func_extended)
+add_subdirectory (arb_texture_rgb10_a2ui)
diff --git a/tests/spec/arb_texture_rgb10_a2ui/CMakeLists.gl.txt
b/tests/spec/arb_texture_rgb10_a2ui/CMakeLists.gl.txt
new file mode 100644
index 000..683c075
--- /dev/null
+++ b/tests/spec/arb_texture_rgb10_a2ui/CMakeLists.gl.txt
@@ -0,0 +1,17 @@
+include_directories(
+ ${GLEXT_INCLUDE_DIR}
+ ${OPENGL_INCLUDE_PATH}
+ ${GLUT_INCLUDE_DIR}
+ ${piglit_SOURCE_DIR}/tests/util
+)
+
+link_libraries (
+ piglitutil
+ ${OPENGL_gl_LIBRARY}
+ ${OPENGL_glu_LIBRARY}
+ ${GLUT_glut_LIBRARY}
+)
+
+add_executable (arb_texture_rgb10_a2ui-texture texture-rgb10a2ui.c)
+
+# vim: ft=cmake:
diff --git a/tests/spec/arb_texture_rgb10_a2ui/CMakeLists.txt
b/tests/spec/arb_texture_rgb10_a2ui/CMakeLists.txt
new file mode 100644
index 000..144a306
--- /dev/null
+++ b/tests/spec/arb_texture_rgb10_a2ui/CMakeLists.txt
@@ -0,0 +1 @@
+piglit_include_target_api()
diff --git a/tests/spec/arb_texture_rgb10_a2ui/texture-rgb10a2ui.c
b/tests/spec/arb_texture_rgb10_a2ui/texture-rgb10a2ui.c
new file mode 100644
index 000..dcea88c
--- /dev/null
+++ b/tests/spec/arb_texture_rgb10_a2ui/texture-rgb10a2ui.c
@@ -0,0 +1,263 @@
+/*
+ * Copyright (c) 2011 Dave Airlie
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * on the rights to use, copy, modify, merge, publish, distribute, sub
+ * license, and/or sell copies of the Software, and to permit persons to whom
+ * the Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NON-INFRINGEMENT. IN NO EVENT SHALL VMWARE AND/OR THEIR SUPPLIERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+/**
+ * @file
+ * Tests GL_ARB_texture_rgb10_a2ui formats/upload paths.
+ */
+
+#include piglit-util.h
+
+int piglit_width = 100, piglit_height = 100;
+int piglit_window_mode = GLUT_RGB | GLUT_ALPHA | GLUT_DOUBLE;
+
+static const char *TestName = texture-integer;
+
+static GLint TexWidth = 16, TexHeight = 16;
+static GLuint Texture;
+
+static GLint BiasUniform = -1, TexUniform = -1;
+
+struct format_info
+{
+ const char *Name;
+ GLenum IntFormat, BaseFormat, Type;
+};
+
+static const struct format_info Formats[] = {
+ { GL_RGB10_A2UI, GL_RGB10_A2UI, GL_RGBA_INTEGER_EXT,
GL_UNSIGNED_INT_10_10_10_2 },
+ { GL_RGB10_A2UI (rev), GL_RGB10_A2UI, GL_RGBA_INTEGER_EXT,
GL_UNSIGNED_INT_2_10_10_10_REV },
+ { GL_RGB10_A2UI (bgra), GL_RGB10_A2UI, GL_BGRA_INTEGER_EXT,
GL_UNSIGNED_INT_10_10_10_2 },
+ { GL_RGB10_A2UI (bgra-rev), GL_RGB10_A2UI, GL_BGRA_INTEGER_EXT,
GL_UNSIGNED_INT_2_10_10_10_REV },
+};
+
+static const char *FragShaderText =
+ #version 130\n
+ uniform vec4 bias; \n
+ uniform isampler2D tex; \n
+ void main() \n
+ { \n
+ vec4 t = vec4(texture(tex, gl_TexCoord[0].xy)); \n
+ gl_FragColor = t + bias; \n
+ } \n;
+
+static GLuint FragShader, Program;
+
+static void
+fill_array(int comps, int texels, void *buf, int type,
+ const int val[4])
+{
+
Re: [Mesa-dev] [PATCH] initial ARB_texture_rgb10_a2ui test (v2)
This test tries to upload the texture in RGBA/BGRA and 10_10_10_2/2_10_10_10_REV type/format combinations. Oops wrong mail sending script, re-sent to piglit list. Sorry for the noise. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] mesa/formats: add mesa MESA_FORMAT_ARGB2101010_UINT description.
From: Dave Airlie airl...@redhat.com
This format is used in the ARB_texture_rgb10_a2ui spec.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/main/formats.c | 17 +
src/mesa/main/formats.h |2 ++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index b9871ae..c884646 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -1496,6 +1496,15 @@ static struct gl_format_info
format_info[MESA_FORMAT_COUNT] =
0, 0, 0, 32, 8, /* Lum/Int/Index/Depth/StencilBits */
1, 1, 8 /* BlockWidth/Height,Bytes */
},
+ {
+ MESA_FORMAT_ARGB2101010_UINT,
+ MESA_FORMAT_ARGB2101010_UINT,
+ GL_RGBA,
+ GL_UNSIGNED_INT,
+ 10, 10, 10, 2,
+ 0, 0, 0, 0, 0,
+ 1, 1, 4
+ },
};
@@ -2449,6 +2458,11 @@ _mesa_format_to_type_and_comps(gl_format format,
*comps = 3;
return;
+ case MESA_FORMAT_ARGB2101010_UINT:
+ *datatype = GL_UNSIGNED_INT_2_10_10_10_REV;
+ *comps = 4;
+ return;
+
case MESA_FORMAT_COUNT:
assert(0);
return;
@@ -2772,6 +2786,9 @@ _mesa_format_matches_format_and_type(gl_format gl_format,
/* FINISHME: SNORM */
return GL_FALSE;
+ case MESA_FORMAT_ARGB2101010_UINT:
+ return GL_FALSE;
+
case MESA_FORMAT_RGB9_E5_FLOAT:
return format == GL_RGB type == GL_UNSIGNED_INT_5_9_9_9_REV;
case MESA_FORMAT_R11_G11_B10_FLOAT:
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index 5f60186..8699092 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -265,6 +265,8 @@ typedef enum
MESA_FORMAT_Z32_FLOAT,
MESA_FORMAT_Z32_FLOAT_X24S8,
+ MESA_FORMAT_ARGB2101010_UINT,
+
MESA_FORMAT_COUNT
} gl_format;
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GL_ARB_texture_rgb10_a2ui support
The first 2 add the core rgb10_a2ui format, and the 3rd is the gallium state tracker support. I've got a one liner fix for r600g and I'll push a docs update along with these. I've tested them with the test that I posted earlier on softpipe + r600g. They also require the image fix I sent for BGRA. Dave. (trivial extension dude). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] st/mesa: add ARB_texture_rgb10_a2ui support
From: Dave Airlie airl...@redhat.com
Add support to the state tracker format and extension enablement code.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/state_tracker/st_extensions.c |6 ++
src/mesa/state_tracker/st_format.c | 11 +--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 25a6cdc..969790a 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -664,4 +664,10 @@ void st_init_extensions(struct st_context *st)
PIPE_BIND_SAMPLER_VIEW)) {
ctx-Extensions.ARB_depth_buffer_float = GL_TRUE;
}
+
+ if (screen-is_format_supported(screen, PIPE_FORMAT_B10G10R10A2_UINT,
+ PIPE_TEXTURE_2D, 0,
+ PIPE_BIND_SAMPLER_VIEW))
+ ctx-Extensions.ARB_texture_rgb10_a2ui = GL_TRUE;
+
}
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index b11245b..bc414f4 100644
--- a/src/mesa/state_tracker/st_format.c
+++ b/src/mesa/state_tracker/st_format.c
@@ -457,7 +457,8 @@ st_mesa_format_to_pipe_format(gl_format mesaFormat)
return PIPE_FORMAT_R9G9B9E5_FLOAT;
case MESA_FORMAT_R11_G11_B10_FLOAT:
return PIPE_FORMAT_R11G11B10_FLOAT;
-
+ case MESA_FORMAT_ARGB2101010_UINT:
+ return PIPE_FORMAT_B10G10R10A2_UINT;
default:
assert(0);
return PIPE_FORMAT_NONE;
@@ -782,6 +783,8 @@ st_pipe_format_to_mesa_format(enum pipe_format format)
case PIPE_FORMAT_R11G11B10_FLOAT:
return MESA_FORMAT_R11_G11_B10_FLOAT;
+ case PIPE_FORMAT_B10G10R10A2_UINT:
+ return MESA_FORMAT_ARGB2101010_UINT;
default:
assert(0);
return MESA_FORMAT_NONE;
@@ -1471,7 +1474,11 @@ static const struct format_mapping format_map[] = {
{
{ GL_R11F_G11F_B10F, 0 },
{ PIPE_FORMAT_R11G11B10_FLOAT, 0 }
- }
+ },
+ {
+ { GL_RGB10_A2UI, 0 },
+ { PIPE_FORMAT_B10G10R10A2_UINT, 0 }
+ },
};
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] mesa: add texformat/store code for GL_RGB10_A2UI.
From: Dave Airlie airl...@redhat.com
This just adds the texstorage and format handling for ARB_texture_rgb10_a2ui
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/main/image.c |2 +
src/mesa/main/texformat.c |9 +++
src/mesa/main/teximage.c |1 +
src/mesa/main/texstore.c | 58 +
4 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c
index 72e944e..f32ca92 100644
--- a/src/mesa/main/image.c
+++ b/src/mesa/main/image.c
@@ -816,6 +816,7 @@ _mesa_is_color_format(GLenum format)
case GL_INTENSITY16_SNORM:
case GL_RGB9_E5:
case GL_R11F_G11F_B10F:
+ case GL_RGB10_A2UI:
return GL_TRUE;
case GL_YCBCR_MESA: /* not considered to be RGB */
/* fall-through */
@@ -1002,6 +1003,7 @@ _mesa_is_integer_format(GLenum format)
case GL_INTENSITY8I_EXT:
case GL_LUMINANCE8I_EXT:
case GL_LUMINANCE_ALPHA8I_EXT:
+ case GL_RGB10_A2UI:
return GL_TRUE;
default:
return GL_FALSE;
diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
index ee9552b..1c6e9e2 100644
--- a/src/mesa/main/texformat.c
+++ b/src/mesa/main/texformat.c
@@ -849,6 +849,15 @@ _mesa_choose_tex_format( struct gl_context *ctx, GLint
internalFormat,
}
}
+ if (ctx-Extensions.ARB_texture_rgb10_a2ui) {
+ switch (internalFormat) {
+ case GL_RGB10_A2UI:
+RETURN_IF_SUPPORTED(MESA_FORMAT_ARGB2101010_UINT);
+break;
+ default:
+break;
+ }
+ }
/* GL_BGRA can be an internal format *only* in OpenGL ES (1.x or 2.0).
*/
if (ctx-API != API_OPENGL) {
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 56335ad..2bc7abd 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -331,6 +331,7 @@ _mesa_base_tex_format( struct gl_context *ctx, GLint
internalFormat )
case GL_RGBA8I_EXT:
case GL_RGBA16I_EXT:
case GL_RGBA32I_EXT:
+ case GL_RGB10_A2UI:
return GL_RGBA;
case GL_RGB8UI_EXT:
case GL_RGB16UI_EXT:
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 6deeb64..4c47976 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -4254,6 +4254,63 @@ _mesa_texstore_z32f_x24s8(TEXSTORE_PARAMS)
}
static GLboolean
+_mesa_texstore_argb2101010_uint(TEXSTORE_PARAMS)
+{
+ const GLuint texelBytes = _mesa_get_format_bytes(dstFormat);
+ const GLenum baseFormat = _mesa_get_format_base_format(dstFormat);
+
+ ASSERT(dstFormat == MESA_FORMAT_ARGB2101010_UINT);
+ ASSERT(texelBytes == 4);
+
+ if (!srcPacking-SwapBytes
+ dstFormat == MESA_FORMAT_ARGB2101010_UINT
+ srcFormat == GL_BGRA_INTEGER_EXT
+ srcType == GL_UNSIGNED_INT_2_10_10_10_REV
+ baseInternalFormat == GL_RGBA) {
+ /* simple memcpy path */
+ memcpy_texture(ctx, dims,
+ dstFormat, dstXoffset, dstYoffset, dstZoffset,
+ dstRowStride, dstSlices,
+ srcWidth, srcHeight, srcDepth, srcFormat, srcType,
+ srcAddr, srcPacking);
+ }
+ else {
+ /* general path */
+ const GLuint *tempImage = make_temp_uint_image(ctx, dims,
+baseInternalFormat,
+baseFormat,
+srcWidth, srcHeight,
srcDepth,
+ srcFormat, srcType, srcAddr,
+srcPacking);
+ const GLuint *src = tempImage;
+ GLint img, row, col;
+ if (!tempImage)
+ return GL_FALSE;
+ for (img = 0; img srcDepth; img++) {
+ GLubyte *dstRow = dstSlices[dstZoffset + img]
++ dstYoffset * dstRowStride
++ dstXoffset * texelBytes;
+
+for (row = 0; row srcHeight; row++) {
+ GLuint *dstUI = (GLuint *) dstRow;
+ for (col = 0; col srcWidth; col++) {
+ GLushort a,r,g,b;
+ r = src[RCOMP];
+ g = src[GCOMP];
+ b = src[BCOMP];
+ a = src[ACOMP];
+ dstUI[col] = (a 30) | (r 20) | (g 10) | (b);
+ src += 4;
+ }
+ dstRow += dstRowStride;
+ }
+ }
+ free((void *) tempImage);
+ }
+ return GL_TRUE;
+}
+
+static GLboolean
_mesa_texstore_null(TEXSTORE_PARAMS)
{
(void) ctx; (void) dims;
@@ -4446,6 +4503,7 @@ _mesa_get_texstore_func(gl_format format)
table[MESA_FORMAT_RGB_UINT32] = _mesa_texstore_rgba_uint32;
table[MESA_FORMAT_RGBA_UINT32] = _mesa_texstore_rgba_uint32;
+ table[MESA_FORMAT_ARGB2101010_UINT] = _mesa_texstore_argb2101010_uint;
initialized = GL_TRUE;
}
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
[Mesa-dev] [PATCH] format_unpack: add ARGB2101010 unpacking.
From: Dave Airlie airl...@redhat.com
This adds the unpacking necessary for an fbo using readpixels.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/main/format_unpack.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index 2f051df..2d2e6a8 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -1642,6 +1642,20 @@ unpack_int_rgba_INTENSITY_UINT32(const GLuint *src,
GLuint dst[][4], GLuint n)
}
}
+static void
+unpack_int_rgba_ARGB2101010_UINT(const GLuint *src, GLuint dst[][4], GLuint n)
+{
+ unsigned int i;
+
+ for (i = 0; i n; i++) {
+ GLuint tmp = src[i];
+ dst[i][0] = (tmp 20) 0x3ff;
+ dst[i][1] = (tmp 10) 0x3ff;
+ dst[i][2] = (tmp 0) 0x3ff;
+ dst[i][3] = (tmp 30) 0x3;
+ }
+}
+
void
_mesa_unpack_int_rgba_row(gl_format format, GLuint n,
const void *src, GLuint dst[][4])
@@ -1680,6 +1694,9 @@ _mesa_unpack_int_rgba_row(gl_format format, GLuint n,
unpack_int_rgba_INTENSITY_UINT32(src, dst, n);
break;
+ case MESA_FORMAT_ARGB2101010_UINT:
+ unpack_int_rgba_ARGB2101010_UINT(src, dst, n);
+ break;
default:
_mesa_problem(NULL, %s: bad format %s, __FUNCTION__,
_mesa_get_format_name(format));
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GL_ARB_texture_rgb10_a2ui support
Just realised its on the required framebuffer format as well, so I'll have to write an FBO test for it and make sure it works. That was easier than I expected, test + patch for mesa sent. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] format_unpack: add 8/16 rgba/rgb types.
From: Dave Airlie airl...@redhat.com
fixing these makes piglit fbo-integer pass on softpipe.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/mesa/main/format_unpack.c | 135 +
1 files changed, 135 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index 2d2e6a8..a6f0ad0 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -1572,6 +1572,58 @@ unpack_int_rgba_RGBA_UINT32(const GLuint *src, GLuint
dst[][4], GLuint n)
}
static void
+unpack_int_rgba_RGBA_UINT8(const GLubyte *src, GLuint dst[][4], GLuint n)
+{
+ unsigned int i;
+
+ for (i = 0; i n; i++) {
+ dst[i][0] = src[i * 4 + 0];
+ dst[i][1] = src[i * 4 + 1];
+ dst[i][2] = src[i * 4 + 2];
+ dst[i][3] = src[i * 4 + 3];
+ }
+}
+
+static void
+unpack_int_rgba_RGBA_INT8(const GLbyte *src, GLuint dst[][4], GLuint n)
+{
+ unsigned int i;
+
+ for (i = 0; i n; i++) {
+ dst[i][0] = src[i * 4 + 0];
+ dst[i][1] = src[i * 4 + 1];
+ dst[i][2] = src[i * 4 + 2];
+ dst[i][3] = src[i * 4 + 3];
+ }
+}
+
+static void
+unpack_int_rgba_RGBA_UINT16(const GLushort *src, GLuint dst[][4], GLuint n)
+{
+ unsigned int i;
+
+ for (i = 0; i n; i++) {
+ dst[i][0] = src[i * 4 + 0];
+ dst[i][1] = src[i * 4 + 1];
+ dst[i][2] = src[i * 4 + 2];
+ dst[i][3] = src[i * 4 + 3];
+ }
+}
+
+static void
+unpack_int_rgba_RGBA_INT16(const GLshort *src, GLuint dst[][4], GLuint n)
+{
+ unsigned int i;
+
+ for (i = 0; i n; i++) {
+ dst[i][0] = src[i * 4 + 0];
+ dst[i][1] = src[i * 4 + 1];
+ dst[i][2] = src[i * 4 + 2];
+ dst[i][3] = src[i * 4 + 3];
+ }
+}
+
+static void
unpack_int_rgba_RGB_UINT32(const GLuint *src, GLuint dst[][4], GLuint n)
{
unsigned int i;
@@ -1585,6 +1637,59 @@ unpack_int_rgba_RGB_UINT32(const GLuint *src, GLuint
dst[][4], GLuint n)
}
static void
+unpack_int_rgba_RGB_UINT16(const GLushort *src, GLuint dst[][4], GLuint n)
+{
+ unsigned int i;
+
+ for (i = 0; i n; i++) {
+ dst[i][0] = src[i * 3 + 0];
+ dst[i][1] = src[i * 3 + 1];
+ dst[i][2] = src[i * 3 + 2];
+ dst[i][3] = 1;
+ }
+}
+
+static void
+unpack_int_rgba_RGB_INT16(const GLshort *src, GLuint dst[][4], GLuint n)
+{
+ unsigned int i;
+
+ for (i = 0; i n; i++) {
+ dst[i][0] = src[i * 3 + 0];
+ dst[i][1] = src[i * 3 + 1];
+ dst[i][2] = src[i * 3 + 2];
+ dst[i][3] = 1;
+ }
+}
+
+static void
+unpack_int_rgba_RGB_UINT8(const GLubyte *src, GLuint dst[][4], GLuint n)
+{
+ unsigned int i;
+
+ for (i = 0; i n; i++) {
+ dst[i][0] = src[i * 3 + 0];
+ dst[i][1] = src[i * 3 + 1];
+ dst[i][2] = src[i * 3 + 2];
+ dst[i][3] = 1;
+ }
+}
+
+
+static void
+unpack_int_rgba_RGB_INT8(const GLbyte *src, GLuint dst[][4], GLuint n)
+{
+ unsigned int i;
+
+ for (i = 0; i n; i++) {
+ dst[i][0] = src[i * 3 + 0];
+ dst[i][1] = src[i * 3 + 1];
+ dst[i][2] = src[i * 3 + 2];
+ dst[i][3] = 1;
+ }
+}
+
+static void
unpack_int_rgba_RG_UINT32(const GLuint *src, GLuint dst[][4], GLuint n)
{
unsigned int i;
@@ -1668,10 +1773,40 @@ _mesa_unpack_int_rgba_row(gl_format format, GLuint n,
case MESA_FORMAT_RGBA_INT32:
unpack_int_rgba_RGBA_UINT32(src, dst, n);
break;
+
+ case MESA_FORMAT_RGBA_UINT8:
+ unpack_int_rgba_RGBA_UINT8(src, dst, n);
+ break;
+ case MESA_FORMAT_RGBA_INT8:
+ unpack_int_rgba_RGBA_INT8(src, dst, n);
+ break;
+
+ case MESA_FORMAT_RGBA_UINT16:
+ unpack_int_rgba_RGBA_UINT16(src, dst, n);
+ break;
+ case MESA_FORMAT_RGBA_INT16:
+ unpack_int_rgba_RGBA_INT16(src, dst, n);
+ break;
+
case MESA_FORMAT_RGB_UINT32:
case MESA_FORMAT_RGB_INT32:
unpack_int_rgba_RGB_UINT32(src, dst, n);
break;
+
+ case MESA_FORMAT_RGB_UINT8:
+ unpack_int_rgba_RGB_UINT8(src, dst, n);
+ break;
+ case MESA_FORMAT_RGB_INT8:
+ unpack_int_rgba_RGB_INT8(src, dst, n);
+ break;
+
+ case MESA_FORMAT_RGB_UINT16:
+ unpack_int_rgba_RGB_UINT16(src, dst, n);
+ break;
+ case MESA_FORMAT_RGB_INT16:
+ unpack_int_rgba_RGB_INT16(src, dst, n);
+ break;
+
case MESA_FORMAT_RG_UINT32:
case MESA_FORMAT_RG_INT32:
unpack_int_rgba_RG_UINT32(src, dst, n);
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] mesa: Make gl_program::InputsRead 64 bits.
On Sun, 27 Nov 2011 18:18:57 +0100, Mathias Fröhlich
mathias.froehl...@gmx.net wrote:
Make gl_program::InputsRead a 64 bits bitfield.
Adapt the intel and radeon driver to handle a 64 bits
InputsRead value.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
@@ -373,10 +373,10 @@ static void brw_prepare_vertices(struct brw_context
*brw)
/* Accumulate the list of enabled arrays. */
brw-vb.nr_enabled = 0;
while (vs_inputs) {
- GLuint i = ffs(vs_inputs) - 1;
+ GLuint i = _mesa_ffsll(vs_inputs) - 1;
This should just be ffsll. If the a platform lacks ffsll, we should
be just defining ffsll on that platform instead of making up a new name
for it for everyone.
@@ -207,7 +207,7 @@ do_vs_prog(struct brw_context *brw,
if (c.key.copy_edgeflag) {
c.prog_data.outputs_written |= BITFIELD64_BIT(VERT_RESULT_EDGE);
- c.prog_data.inputs_read |= 1VERT_ATTRIB_EDGEFLAG;
+ c.prog_data.inputs_read |= BITFIELD64_BIT(VERT_ATTRIB_EDGEFLAG);
}
Let's just use VERT_BIT_EDGEFLAG.
(when I was looking at this, I counted up _BIT_ vs (1 _ATTRIB_), and
there was a clear preference for using _BIT_ defines when available).
/* BRW_NEW_FRAGMENT_PROGRAM */
- if (fp-program.Base.InputsRead (1 FRAG_ATTRIB_WPOS))
+ if (fp-program.Base.InputsRead BITFIELD64_BIT(FRAG_ATTRIB_WPOS))
FRAG_BIT_WPOS
dw5 |= GEN6_WM_USES_SOURCE_DEPTH | GEN6_WM_USES_SOURCE_W;
if (fp-program.Base.OutputsWritten BITFIELD64_BIT(FRAG_RESULT_DEPTH))
dw5 |= GEN6_WM_COMPUTED_DEPTH;
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c
b/src/mesa/drivers/dri/i965/gen7_wm_state.c
index f38d2f1..3775301 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_state.c
@@ -58,7 +58,7 @@ upload_wm_state(struct brw_context *brw)
dw1 |= GEN7_WM_POLYGON_STIPPLE_ENABLE;
/* BRW_NEW_FRAGMENT_PROGRAM */
- if (fp-program.Base.InputsRead (1 FRAG_ATTRIB_WPOS))
+ if (fp-program.Base.InputsRead BITFIELD64_BIT(FRAG_ATTRIB_WPOS))
dw1 |= GEN7_WM_USES_SOURCE_DEPTH | GEN7_WM_USES_SOURCE_W;
if (fp-program.Base.OutputsWritten BITFIELD64_BIT(FRAG_RESULT_DEPTH)) {
writes_depth = true;
same
@@ -560,10 +569,10 @@ static GLboolean r200_translate_vertex_program(struct
gl_context *ctx, struct r2
/* will always find one due to limited array_count */
if (free_inputs (1 j)) {
free_inputs = ~(1 j);
-vp-inputs[i] = j;
-if (j == 0) vp-inputmap_rev[j] = i; /* mapped to pos */
-else if (j 12) vp-inputmap_rev[j + 2] = i; /* mapped to
col/tex
*/
-else vp-inputmap_rev[j + 1] = i; /* mapped to pos1 */
+vp-inputs[VERT_ATTRIB_GENERIC(i)] = j;
+if (j == 0) vp-inputmap_rev[j] = VERT_ATTRIB_GENERIC(i); /*
mapped to pos */
+else if (j 12) vp-inputmap_rev[j + 2] =
VERT_ATTRIB_GENERIC(i);
/* mapped to col/tex */
+else vp-inputmap_rev[j + 1] = VERT_ATTRIB_GENERIC(i); /* mapped
to pos1 */
break;
Correct change, but yuck, that if sequence sure needs some newlines in
there.
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 74b8fa7..7d1be5e 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -3731,7 +3731,7 @@ get_pixel_transfer_visitor(struct st_fragment_program
*fp,
inst-sampler = 0;
inst-tex_target = TEXTURE_2D_INDEX;
- prog-InputsRead |= (1 FRAG_ATTRIB_TEX0);
+ prog-InputsRead |= BITFIELD64_BIT(FRAG_ATTRIB_TEX0);
@@ -3855,7 +3855,7 @@ get_bitmap_visitor(struct st_fragment_program *fp,
inst-sampler = samplerIndex;
inst-tex_target = TEXTURE_2D_INDEX;
- prog-InputsRead |= (1 FRAG_ATTRIB_TEX0);
+ prog-InputsRead |= BITFIELD64_BIT(FRAG_ATTRIB_TEX0);
prog-SamplersUsed |= (1 samplerIndex); /* mark sampler as used */
v-samplers_used |= (1 samplerIndex);
FRAG_BIT_TEX0 for these two?
pgpVQNaFZNFaG.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] mesa: Use VERT_ATTRIB_* indexed array in gl_array_object.
On Sun, 27 Nov 2011 18:19:00 +0100, Mathias Fröhlich mathias.froehl...@gmx.net wrote: Replace the distinct struct gl_client_array members in gl_array_object by an array of gl_client_arrays indexed by VERT_ATTRIB_*. Renumber the vertex attributes slightly to keep the old semantics of the distinct array members. Make use of the upper 32 bits in VERT_BIT_*. Update all occurances of the distinct struct members with the array equivalents. Signed-off-by: Mathias Froehlich mathias.froehl...@web.de diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c index f57579c..6c0dc7c 100644 --- a/src/mesa/main/state.c +++ b/src/mesa/main/state.c @@ -83,98 +83,101 @@ update_arrays( struct gl_context *ctx ) struct gl_array_object *arrayObj = ctx-Array.ArrayObj; GLuint i, min = ~0; - /* find min of _MaxElement values for all enabled arrays */ + /* find min of _MaxElement values for all enabled arrays. +* Note that the generic arrays always take precedence over +* the legacy arrays. +*/ Not an issue for this patch, but I noticed that there's this _mesa_update_array_object_max_element that does something similar, but doesn't follow this rule and would trash the _MaxElement value. Some day, the body of this function should probably be moved to that one, and state.c should call it. It's also a bit disturbing that the code for which array to look at based on program state is duplicated between vbo and here. Other than the one patch with comments, the series overall looks like a great clenaup and is: Reviewed-by: Eric Anholt e...@anholt.net pgpxsME4zfxT4.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] mesa: use _mesa_base_format_has_channel() in fbobject.c queries
Series is Reviewed-by: Eric Anholt e...@anholt.net pgpGWM98IAvNa.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] image/pack: fix missing GL_BGR(A)_INTEGER support.
On Sun, 27 Nov 2011 17:37:09 +, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com These codepaths were missing the cases for BGR_INTEGER/BGRA_INTEGER. Signed-off-by: Dave Airlie airl...@redhat.com Reviewed-by: Eric Anholt e...@anholt.net pgpI1qI97kMbt.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Mesa 7.11.2 release
Mesa 7.11.2 has been released. Mesa 7.11.2 is a bug fix release which fixes bugs found since the 7.11.1 release. This release was made primarily to fix build problems with 7.11.1 on Mandriva and to fix problems related to glCopyTexImage to luminance-alpha textures. That later was believed to have been fixed in 7.11.1 but was not. The tag in the GIT repository for Mesa 7.11.2 is 'mesa-7.11.2'. Mesa 7.11.1 is available for download at ftp://freedesktop.org/pub/mesa/7.11.2/ md5sums: b9e84efee3931c0acbccd1bb5a860554 MesaLib-7.11.2.tar.gz 0837c52698fe3252369c3fdb5195afcc MesaLib-7.11.2.tar.bz2 141273c274d12e0d2bafb497fe937da3 MesaLib-7.11.2.zip 39ae9926794794503815ffdc069521eb MesaGLUT-7.11.2.tar.gz 35ca3a0b54cb6f9d2e0e4eae8f6bb95e MesaGLUT-7.11.2.tar.bz2 f8705fcff2510b6c39cd27b575c05dba MesaGLUT-7.11.2.zip I have verified building from the .tar.bz2 file by doing: tar -xjf MesaLib-7.11.2.tar.bz2 cd Mesa-7.11.2 ./configure --enable-dri --with-dri-drivers=yes \ --enable-gles1 --enable-gles2 --enable-glx-tls \ --disable-glw --disable-glu --with-gallium-drivers \ --enable-gallium-llvm make -j6 I have also verified that I pushed all the cherry picks and the tag. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] format_unpack: add ARGB2101010 unpacking.
On Sun, 27 Nov 2011 20:36:26 +, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com This adds the unpacking necessary for an fbo using readpixels. Signed-off-by: Dave Airlie airl...@redhat.com Reviewed-by: Eric Anholt e...@anholt.net pgpWveDqQMwAC.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] format_unpack: add 8/16 rgba/rgb types.
On Sun, 27 Nov 2011 20:54:34 +, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
fixing these makes piglit fbo-integer pass on softpipe.
I didn't do these because I wasn't sure how clamping and sign extension
were supposed to work in the pack path. The specs have text on it, but
I couldn't make clear sense of it. Do you have a solid idea, and if so
could we get a little bit of explanation in the switch statement maybe?
+static void
unpack_int_rgba_RG_UINT32(const GLuint *src, GLuint dst[][4], GLuint n)
{
unsigned int i;
@@ -1668,10 +1773,40 @@ _mesa_unpack_int_rgba_row(gl_format format, GLuint n,
case MESA_FORMAT_RGBA_INT32:
unpack_int_rgba_RGBA_UINT32(src, dst, n);
break;
+
+ case MESA_FORMAT_RGBA_UINT8:
+ unpack_int_rgba_RGBA_UINT8(src, dst, n);
+ break;
+ case MESA_FORMAT_RGBA_INT8:
+ unpack_int_rgba_RGBA_INT8(src, dst, n);
+ break;
+
+ case MESA_FORMAT_RGBA_UINT16:
+ unpack_int_rgba_RGBA_UINT16(src, dst, n);
+ break;
+ case MESA_FORMAT_RGBA_INT16:
+ unpack_int_rgba_RGBA_INT16(src, dst, n);
+ break;
+
Having the ordering of cases be 32, 8, 16 looks odd. Let's flip it
around to either 8, 16, 32 or 32, 16, 8.
+ case MESA_FORMAT_RGB_UINT8:
+ unpack_int_rgba_RGB_UINT8(src, dst, n);
+ break;
+ case MESA_FORMAT_RGB_INT8:
+ unpack_int_rgba_RGB_INT8(src, dst, n);
+ break;
+
+ case MESA_FORMAT_RGB_UINT16:
+ unpack_int_rgba_RGB_UINT16(src, dst, n);
+ break;
+ case MESA_FORMAT_RGB_INT16:
+ unpack_int_rgba_RGB_INT16(src, dst, n);
+ break;
+
case MESA_FORMAT_RG_UINT32:
case MESA_FORMAT_RG_INT32:
unpack_int_rgba_RG_UINT32(src, dst, n);
No RG/R/A/L/I cases make me sad.
pgpicDpXPj6e2.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Allow generic attributes for glGetActiveAttrib and GL_ACTIVE_ATTRIBUTES
On Tue, 22 Nov 2011 13:47:27 -0800, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com Page 77 (page 91 of the PDF) says about glGetActiveAttrib: The returned attribute name can be the name of a generic attribute or a conventional attribute (which begin with the prefix gl_, see the OpenGL Shading Language specification for a complete list). Page 261 (page 275 of the PDF) says about glGetProgramiv: If pname is ACTIVE_ATTRIBUTES, the number of active attributes in program is returned. It doesn't say anything about built-in vs. user-defined attributes. From the language around glGetActiveAttrib and the lack of an exclusion of built-in attributes, which exists other places (e.g., around glBindAttribLocation), we can infer that GL_ACTIVE_ATTRIBUTES should include the active attribute count. It should also be included in the values returned by glGetActiveAttrib. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43138 Reviewed-by: Eric Anholt e...@anholt.net pgppj6gyBTtsX.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] mesa: add texformat/store code for GL_RGB10_A2UI.
On Sun, 27 Nov 2011 19:27:16 +, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com This just adds the texstorage and format handling for ARB_texture_rgb10_a2ui Looking at places that GL_RGBA32UI is mentioned, it seems like we also need a case for this extension in fbobject.c:_mesa_base_fbo_format(). Looks like teximage.c:get_sized_format_info() doesn't want it because that list is supposed to just be table 3.21 of the GL 3.3 spec for glTexBuffer() (so it explicitly doesn't include this format). pgpRItA5vqjWm.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] mesa/formats: add mesa MESA_FORMAT_ARGB2101010_UINT description.
On Sun, 27 Nov 2011 19:27:15 +, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com This format is used in the ARB_texture_rgb10_a2ui spec. Signed-off-by: Dave Airlie airl...@redhat.com --- src/mesa/main/formats.c | 17 + src/mesa/main/formats.h |2 ++ 2 files changed, 19 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h index 5f60186..8699092 100644 --- a/src/mesa/main/formats.h +++ b/src/mesa/main/formats.h @@ -265,6 +265,8 @@ typedef enum MESA_FORMAT_Z32_FLOAT, MESA_FORMAT_Z32_FLOAT_X24S8, + MESA_FORMAT_ARGB2101010_UINT, + MESA_FORMAT_COUNT } gl_format; Hmm, are we at the point yet where we can safely put new enums somewhere more sensible than at the end of the list? pgpkuT2Us4L1X.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/7] mesa: Fix the datatype of GL_DEPTH32F_STENCIL8's depth channel.
On Wed, 23 Nov 2011 13:52:07 -0700, Brian Paul bri...@vmware.com wrote:
On 11/23/2011 01:37 PM, Eric Anholt wrote:
Asking for the datatype of MESA_FORMAT_Z32_FLOAT_X24S8 is a bit funny
-- there's a float depth channel, and a stencil channel that doesn't
have a particular GLenum associated with its type, so what's the correct
response?
Because there is no query for stencil, just make this format's
datatype be that of the depth channel. It fixes the depth query (and
thus a failure in piglit gl-3.0-required-sized-formats), and none of
the other consumers of the _mesa_get_format_datatype() API care.
---
src/mesa/main/formats.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index b934bd4..324de65 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -1473,7 +1473,7 @@ static struct gl_format_info
format_info[MESA_FORMAT_COUNT] =
MESA_FORMAT_Z32_FLOAT_X24S8, /* Name */
MESA_FORMAT_Z32_FLOAT_X24S8, /* StrName */
GL_DEPTH_STENCIL,/* BaseFormat */
- GL_NONE /* XXX */, /* DataType */
+ GL_FLOAT,/* DataType */
0, 0, 0, 0, /* Red/Green/Blue/AlphaBits */
0, 0, 0, 32, 8, /* Lum/Int/Index/Depth/StencilBits */
1, 1, 8 /* BlockWidth/Height,Bytes */
Minor nit: maybe add a comment to the effect of we're ignoring stencil.
Updated version:
{
MESA_FORMAT_Z32_FLOAT, /* Name */
MESA_FORMAT_Z32_FLOAT, /* StrName */
GL_DEPTH_COMPONENT, /* BaseFormat */
/* DataType here is used to answer GL_TEXTURE_DEPTH_TYPE queries, and is
* never used for stencil because stencil is always GL_UNSIGNED_INT.
*/
GL_FLOAT,
0, 0, 0, 0, /* Red/Green/Blue/AlphaBits */
0, 0, 0, 32, 0, /* Lum/Int/Index/Depth/StencilBits */
1, 1, 4 /* BlockWidth/Height,Bytes */
},
pgp3wHoAaZrHb.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/7] mesa: Make _mesa_is_stencil_format() consistent with _mesa_is_depth_format().
On Wed, 23 Nov 2011 13:53:33 -0700, Brian Paul bri...@vmware.com wrote:
On 11/23/2011 01:37 PM, Eric Anholt wrote:
There was only one consumer of this API, meta.c, which was intending
to ask is this format just stencil index (and nothing else)?.
Instead, if one tried to glDrawPixels of GL_DEPTH_STENCIL-type
formats, it would just try to draw the stencil parts. Nothing good
came of this.
This function looks rather silly at this point, but I'm leaving it in
place to be the obvious parallel API to _mesa_is_depth_format(). Note
that if you want the old behavior, you should use it as
(_mesa_is_stencil_format() || _mesa_is_depthstencil_format()) like is
commonly done for depth-related tests.
---
src/mesa/main/image.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c
index 914a999..d91b4ca 100644
--- a/src/mesa/main/image.c
+++ b/src/mesa/main/image.c
@@ -848,7 +848,6 @@ _mesa_is_stencil_format(GLenum format)
{
switch (format) {
case GL_STENCIL_INDEX:
- case GL_DEPTH_STENCIL:
return GL_TRUE;
default:
return GL_FALSE;
I'd guess/hope this compiles down to:
return format == GL_STENCIL_INDEX;
Either way, Reviewed-by: Brian Paul bri...@vmware.com
Confirmed. For once, gcc does what we would hope!
pgpQD6YgUh919.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: add hard limits for the number of varyings and uniforms for the linker
On 11/25/2011 01:13 AM, Dave Airlie wrote: I'm honestly shocked to read this, Marek. We deliberately want [your] driver to be less capable and couldn't care about less about anything except [our] driver? This is sounding remarkably like a conspiracy theory, and I really didn't expect that from you. I think it takes two to tango, and Ian was pretty direct on irc, he might have been attempting sarcasm but we all know how well that works on irc :-) The IRC logs are public, but I don't expect anyone to ever try and use an argument like I know better than you because I'm on the ARB in any discussion around here again. Its show contempt for those of us who know that standards are joke no matter who produces them. DirectX works because it has a decent test suite + reference renderer not because it has a tight spec group. That's not at all accurate. DirectX has an extremely tight and rigorous spec: the *one* implementation of the API. Because of that, an application developer has quite a bit of assurance that a shader targeting DX 9.0c will run on all hardware if it runs on any hardware. OpenGL on Apple platforms is in a similar situation for a similar reason. There is one implementation of all of the application facing bits. If a shader compiles and links on one driver that advertises 4096 uniform components, then it will compile and link on all of them that advertise 4096 uniform components. In Mesa, we have four drivers that advertise 4096 uniform components on some combinations of hardware: i915, i915g, nouveau, and r300g. By putting resource counting in the driver we have the potential for shaders to compile and link on exactly one driver but fail on the other three. Which is it? Is a consistent ecosystem on which developers can depend a virtue, or is it me trying to ruin someone's driver? You can't argue that it's both. If someone thinks that compacting uniform arrays or varying arrays is an important optimization that our OpenGL ecosystem needs to make applications run, that's great. Patches are welcome. This is an ecosystem. We will all either fail or succeed together. Why do you think so much of the work that I and my team does lives in the shared components? Huge amounts of the code that we've written, especially the GLSL optimizations, could live in our drivers. Doing so would have let us accomplish our goals much, much faster, but we didn't do that because it hurts the ecosystem as a whole. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] reworking pipe_video_decoder / pipe_video_buffer
On 26.11.2011 22:23, Maarten Lankhorst wrote: Hey Andy, On 11/26/2011 01:44 PM, Andy Furniss wrote: Maarten Lankhorst wrote: Testing interlaced videos that decode correctly with nvidia vdpau would help a lot to figure out what the proper way to handle interlacing would be, so if someone has a bunch that play with nvidia accelerated vdpau mplayer correctly, could you please link them? ;) I don't have any nvidia hw but these are interlaced mpeg2. HD http://www.w6rz.net/newmobcal1920.ts http://www.w6rz.net/parkrun1920_23mbps.ts There are smaller and lower bitrate versions on http://www.w6rz.net SD ftp://ftp.tek.com/tv/test/streams/Element/MPEG-Video/625/mobl_060.m2v ftp://ftp.tek.com/tv/test/streams/Element/MPEG-Video/625/bbc3_060.m2v ftp://ftp.tek.com/tv/test/streams/Element/MPEG-Video/625/cact_060.m2v I can easily get broadcast dvb-t SD much of which is interlaced. For some reason mplayer handles all the above images as progressive with vdpau, and it sets picture_structure to 3. I can see the interlacing on movement, but it doesn't seem like mplayer tells vdpau it is interlaced, sigh. :/ And it is a complete different thing to have a internal memory layout of separated top and bottom lines, because this layout is hardware specific, for example you could have all top lines first (luma and chroma) and the the bottom lines, or you can have luma top, then luma bottom, then chroma top then chroma bottom etc... Paired with different tilling modes that gives you probably a couple of hundred different memory layouts. It doesn't make sense to export this to a state tracker. Well, it depends. I read up a bit more, vdpau interlaced mode requires both fields to be decoded to the same surface. I've researched interlaced a bit more, so what I said about top/bottom field earlier can be ignored. I do think it makes sense to allow support for separate top/bottom fields though, if only because of deinterlacing algorithms and handling inverse telecine in a sane way.. to handle those you can't think of progressive frames any more. IIRC it says in the vdpau headers/somewhere that nvidia keep fields separate internally. Doesn't look like it says it in the headers, but it doesn't really surprise me.. I think if you want to handle things like deinterlacing and inverse telecine sanely, you would have to change your approach from handling in full frames to separate fields. You're right that memory layouts shouldn't be part of the state tracker. I think having support for separate field views that get merged in the video mixer renderer would be required to handle deinterlacing sanely, though. Nouveau could then just ask for simple weave deinterlacing on a progressive frame, while other deinterlacing algorithms could be used for interlaced videos. For example bobbing could just be done by stretching a field, and that algorithm is required to have for vdpau, according to the vdpau header. It's really cool you are working on this. One thing to maybe condider early on is the mpeg chroma interlaced issue, which is covered here - http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html It actually initially describes the opposite case (treat progressive as interlaced) to what xv/gl/vdpau does(treat interlaced as progressive), but does explain the issues well. This sample shows the issue - http://www.andyqos.ukfsn.org/snooker-short.ts If you pause when the ball is bouncing around the pocket you can see that the chroma tears have bled between fields so look worse when decoded as progressive. I used -vo x11 for these without zoom to avoid an extra scale - all hw csc I know of will look like this one. http://www.andyqos.ukfsn.org/snooker-prog.png For the next one interlaced sw csc is used but without a filter so the tears are correct but the stationary red balls have artifacts. mplayer -vo x11 -vf scale=::1 or mplayer -vo x11 -vf ilpack=0 http://www.andyqos.ukfsn.org/snooker-interlac.png The only way to get this to look good is use ilpack which by default does interlaced properly plus filters. It actually converts to 4:2:2 so -vo x11 or xv will work (R600). mplayer -vo x11 -vf ilpack http://www.andyqos.ukfsn.org/snooker-interlac-filtered.png Sadly mplayer tells vdpau to have all videos decoded as progressive so I can't really do anything. :-( Oh, crap! That explains why I couldn't find any interlaced videos, sounds like mplayer just tells vdpau that it is progressive even if it isn't. Maybe somebody should dig into the mplayer code and fix this. Any volunteers? Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gl-3.0/api/drawpixels-integer: New test for GL 3.0 integer glDrawPixels.
When the extension was folded in, glDrawPixels of integer formats was
disallowed. Disable the GL_EXT_texture_integer if 3.0 is exposed, and
replace it with a simple make sure it throws the error API test.
I think actually the intent was that this is a correction to
EXT_texture_integer, because I don't see how it was actually supposed
to work back then (see comment in fbo-integer-precision-drawpixels).
---
tests/all.tests|1 +
tests/spec/ext_texture_integer/api-drawpixels.c|5 +
.../fbo-integer-precision-drawpixels.c | 30 +++
tests/spec/gl-3.0/api/CMakeLists.gl.txt|1 +
tests/spec/gl-3.0/api/drawpixels-integer.c | 86
5 files changed, 123 insertions(+), 0 deletions(-)
create mode 100644 tests/spec/gl-3.0/api/drawpixels-integer.c
diff --git a/tests/all.tests b/tests/all.tests
index bbd31f1..96d2f51 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -800,6 +800,7 @@ add_concurrent_test(gl30, 'clearbuffer-invalid-drawbuffer')
add_concurrent_test(gl30, 'clearbuffer-invalid-buffer')
add_concurrent_test(gl30, 'clearbuffer-stencil')
add_concurrent_test(gl30, 'getfragdatalocation')
+add_concurrent_test(gl30, 'gl-3.0-drawpixels-integer')
add_concurrent_test(gl30, 'gl-3.0-required-sized-texture-formats')
add_concurrent_test(gl30, 'gl-3.0-required-renderbuffer-attachment-formats')
add_concurrent_test(gl30, 'gl-3.0-required-texture-attachment-formats')
diff --git a/tests/spec/ext_texture_integer/api-drawpixels.c
b/tests/spec/ext_texture_integer/api-drawpixels.c
index adf311e..eb91718 100644
--- a/tests/spec/ext_texture_integer/api-drawpixels.c
+++ b/tests/spec/ext_texture_integer/api-drawpixels.c
@@ -54,5 +54,10 @@ piglit_display(void)
void
piglit_init(int argc, char **argv)
{
+ if (GLEW_VERSION_3_0) {
+ printf(See tests/spec/gl-3.0/api/drawpixels-integer.c\n);
+ piglit_report_result(PIGLIT_SKIP);
+ }
+
piglit_require_extension(GL_EXT_texture_integer);
}
diff --git a/tests/spec/ext_texture_integer/fbo-integer-precision-drawpixels.c
b/tests/spec/ext_texture_integer/fbo-integer-precision-drawpixels.c
index 5a341f7..fe1a0b2 100644
--- a/tests/spec/ext_texture_integer/fbo-integer-precision-drawpixels.c
+++ b/tests/spec/ext_texture_integer/fbo-integer-precision-drawpixels.c
@@ -283,6 +283,36 @@ piglit_init(int argc, char **argv)
piglit_require_extension(GL_EXT_texture_integer);
piglit_require_GLSL_version(130);
+ if (GLEW_VERSION_3_0) {
+ /* The EXT_texture_integer spec doesn't explicitly
+* disallow glDrawPixels with integer components, and
+* specifies a couple of error cases, e.g. in
+* Rasterization of Pixel Rectangles:
+*
+* If format is one of the integer component
+* formats as defined in table 3.6 and type is
+* FLOAT, the error INVALID ENUM occurs.
+*
+* while in Section 3.7.4 of the GL 3.0 specification
+* (20080923, page 149), a new restriction has been
+* added:
+*
+* If format contains integer components, as
+* shown in table 3.6, an INVALID OPERATION error
+* is generated.
+*
+* The GL 3.0 behavior is tested in
+* gl-3.0/api/drawpixels-integer.c. This restriction
+* persists through GL 3.3 compatibility specs and
+* presumably into the future. It makes sense,
+* because how is the non-normalized integer value
+* supposed to be assigned to the floating-point
+* gl_Color input of the fragment shader?
+*/
+ printf(GL 3.0 obsoletes this test\n);
+ piglit_report_result(PIGLIT_SKIP);
+ }
+
PassthroughFragShader = piglit_compile_shader_text(GL_FRAGMENT_SHADER,
PassthroughFragShaderText);
assert(PassthroughFragShader);
diff --git a/tests/spec/gl-3.0/api/CMakeLists.gl.txt
b/tests/spec/gl-3.0/api/CMakeLists.gl.txt
index 466ffeb..2cb72aa 100644
--- a/tests/spec/gl-3.0/api/CMakeLists.gl.txt
+++ b/tests/spec/gl-3.0/api/CMakeLists.gl.txt
@@ -19,5 +19,6 @@ add_executable (clearbuffer-invalid-drawbuffer
clearbuffer-invalid-drawbuffer.c)
add_executable (clearbuffer-invalid-buffer clearbuffer-invalid-buffer.c)
add_executable (clearbuffer-stencil clearbuffer-common.c clearbuffer-stencil.c)
add_executable (getfragdatalocation getfragdatalocation.c)
+add_executable (gl-3.0-drawpixels-integer drawpixels-integer.c)
# vim: ft=cmake:
diff --git a/tests/spec/gl-3.0/api/drawpixels-integer.c
b/tests/spec/gl-3.0/api/drawpixels-integer.c
new file mode 100644
index 000..bc6aa68
--- /dev/null
+++
[Mesa-dev] GL 3.0 glDrawPixels(integer format)
While looking into MapRenderbuffer for glDrawPixels, I ended up looking at integer again. It looks like GL 3.0 has added sanity to drawpixels for integer, which is to say that they've disallowed it. I don't think there was any way to usefully use drawpixels of integer. Assuming you want to output to an integer FBO, you have to have a fragment shader bound. You would also need to have the input to that fragment shader be integer, or you're going to lose your precision. But how does the glDrawPixels() input data get bound to some user-defined shader input? The fbo-integer-precision-drawpixels testcase currently binds a shader that does gl_FragColor = gl_Color. But if the output to an integer FBO is written through a floating-point shader output, the result is undefined (from GL_EXT_texture_integer): The color components used for per-fragment operations and written into a color buffer are undefined: * for fragment shaders that write floating-point color components to an integer color buffer, or... What should we do with that testcase? If pre-3.0 GL_EXT_texture_integer allows drawpixels for integer, what behavior would we actually want for making use of the user's shader? (I'm assuming that testcase passed for whatever code it was supposed to test because that code just no-opped the shader. Imagine the shader doing some actual math on the color instead.). I'm inclined to adopt 3.0 behavior generally, and assume that the 3.0 wording was a correction after someone noticed that making drawpixels for integer actually work was hopeless. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Reject glDrawPixels(integer format) on GL 3.0 or greater.
When folding GL_EXT_texture_integer into the core, a new (and very
sensible) restriction was added.
---
src/mesa/main/drawpix.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c
index 412cc15..5d1bd5a 100644
--- a/src/mesa/main/drawpix.c
+++ b/src/mesa/main/drawpix.c
@@ -30,6 +30,7 @@
#include enums.h
#include feedback.h
#include framebuffer.h
+#include image.h
#include mfeatures.h
#include pbo.h
#include readpix.h
@@ -76,6 +77,18 @@ _mesa_DrawPixels( GLsizei width, GLsizei height,
goto end; /* the error code was recorded */
}
+ /* GL 3.0 introduced a new restriction on glDrawPixels() over what was in
+* GL_EXT_texture_integer. From section 3.7.4 (Rasterization of Pixel
+* Rectangles) on page 151 of the GL 3.0 specification:
+*
+* If format contains integer components, as shown in table 3.6, an
+* INVALID OPERATION error is generated.
+*/
+ if (ctx-VersionMajor = 3 _mesa_is_integer_format(format)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION, glDrawPixels(integer format));
+ goto end;
+ }
+
if (_mesa_error_check_format_type(ctx, format, type, GL_TRUE)) {
goto end; /* the error code was recorded */
}
--
1.7.7.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] XCB-only GLX protocol?
All, I'm starting to work on GLX_ARB_create_context. This extension and the layered GLX_ARB_create_context_profile extension add some GLX protocol. Is there any reason to keep supporting non-XCB protocol? Are there any platforms that can't / don't use XCB for X protocol? I'm not planning to gut any non-XCB code yet, but that would happen eventually. I just don't want to implement all of the protocol twice. That seems like an unnecessary hassle. Opinions? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Piglit] [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY_BUFFER is per vao
On Thu, Nov 24, 2011 at 11:25:23AM -0800, Eric Anholt wrote: On Wed, 23 Nov 2011 12:24:37 -0700, Brian Paul bri...@vmware.com wrote: On 11/23/2011 12:12 PM, Eric Anholt wrote: On Wed, 23 Nov 2011 17:34:30 +0800, Yuanhan Liuyuanhan@linux.intel.com wrote: From 9a1da8748f0faa23f34398213ff7ee45fda6bf36 Mon Sep 17 00:00:00 2001 From: Yuanhan Liuyuanhan@linux.intel.com Date: Wed, 23 Nov 2011 17:37:33 +0800 Subject: [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY_BUFFER is per vao According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at page 515: the element buffer object is listed in vertex array object. Add a testcase to test that. v2: fix n careless 'always-return-PIGLIT_PASS' fault. Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com diff --git a/tests/general/vao-element-array-buffer.c b/tests/general/vao-element-array-buffer.c new file mode 100644 index 000..8803bff --- /dev/null +++ b/tests/general/vao-element-array-buffer.c @@ -0,0 +1,94 @@ +/* + * Copyright (C) 2011 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the Software), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + * Authors: + *Yuanhan Liuyuanhan@linux.intel.com + */ Generally, the style I advocate is to not include the Authors line in copyright messages. git records who the author was already, and will provide a more accurate view of who wrote the current code if someone wants to know some time down the line. I don't know how many times, 5 years later, I've had emails from someone asking about some code I'd written that just had my name in the header and nothing else really of mine, from back when we were including Authors lines in the CVS days. +glutSwapBuffers(); If you switched this to piglit_present_results, this test could be an add_concurrent_test() instead. Under what circumstances can't glutSwapBuffers() be replaced by piglit_present_results()? I'm guessing many/most of the tests that use the former could be changed to use the later. That might be a good project for someone who wants to contribute. I guess everything using the framework could be trivially converted to it. Doesn't mean all of those are ready to be made concurrent (things explicitly using the window system framebuffer would still need work), but it might save a measurable amount of time to skip that many swaps. Got it. Thanks. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: add hard limits for the number of varyings and uniforms for the linker
On Mon, Nov 28, 2011 at 12:08 AM, Ian Romanick i...@freedesktop.org wrote: In Mesa, we have four drivers that advertise 4096 uniform components on some combinations of hardware: i915, i915g, nouveau, and r300g. By putting resource counting in the driver we have the potential for shaders to compile and link on exactly one driver but fail on the other three. r300g does not advertise 4096 uniform components. The limits are: 1024 uniform components on r300 vertex shaders. 128 uniform components on r300 fragment shaders. 1024 uniform components on r500 fragment shaders. I was investigating how the Intel driver sets the maximum and I didn't find it. Maybe the Intel driver is reporting Mesa defaults (most probably incorrect). Maybe I didn't look hard enough. I have not faked any limits so far. But now I will probably have to raise them a bit in order to comply with the strict rules of the GLSL linker, to close bugs in some other way than WONTFIX of course, and just making work what used to work. Yes, it's lying, but it would make things better at the same time, what other option do I have? (with the least amount of work, of course, I have better things to do) Which is it? Is a consistent ecosystem on which developers can depend a virtue, or is it me trying to ruin someone's driver? You can't argue that it's both. If someone thinks that compacting uniform arrays or varying arrays is an important optimization that our OpenGL ecosystem needs to make applications run, that's great. Patches are welcome. Great. I just committed this last year, is it welcome too? http://cgit.freedesktop.org/mesa/mesa/commit/?id=574ba4b5f50bfe661427327cd792a8a200559376 Though it seems to me that what you're telling me is give me a patch for the GLSL IR or off. In theory, the GLSL compiler is not the only client in Gallium, so I guess none of the Gallium folks are gonna be eager to move things into it. If I move some optimization into the GLSL compiler, it doesn't mean I can remove it from a Gallium driver. I have to keep in mind there's video acceleration and maybe even X acceleration coming for Gallium. As far as varyings are concerned, no driver can do compaction to my knowledge yet. The problem with the GLSL compiler is that it can't even do a _simple_ dead-code elimination on unused varyings like gl_TexCoord[insert_literal_here], i.e. something the years-old ARB program implementation can do (and set the OutputsWritten flag accordingly). For example, if gl_TexCoord[1] is unused, what's stopping you from assigning some user-defined varying to the same location? I am not expecting an answer, I know this issue will be fixed by somebody sooner or later. I am just showing the problem. This is an ecosystem. We will all either fail or succeed together. Why do you think so much of the work that I and my team does lives in the shared components? Huge amounts of the code that we've written, especially the GLSL optimizations, could live in our drivers. Doing so would have let us accomplish our goals much, much faster, but we didn't do that because it hurts the ecosystem as a whole. I agree, but forcing the rules of your driver onto somebody else's driver may be met with disagreement, especially if your shader backend is mediocre to others (because it heavily relies on shared components, unlike other backends, especially Gallium drivers cannot solely rely just on the GLSL compiler). I don't think Mesa is an ecosystem to users such that it has to behave the same no matter what driver is used. Mesa competes with two proprietary drivers, which own quite a large market share, and both are by several orders of magnitude better. They are so much better and popular among professionals that they basically set the standard, because most apps are tested on them and made work on them. Who really cares about Mesa besides regular users who don't/can't replace the graphics driver (including distribution vendors) and open source enthusiasts? We can only shut up and do what the other driver providers do.* Now that I live in a world where some apps are tested only on R600-class hardware (at least) and proprietary drivers, I have to make compromises and hard decisions to keep them working on the old hardware. I tried hard to avoid reporting false limits, but I seem to have been given no other choice. * For example, I cannot advertise ARB_draw_instanced in r600g, because it would break Unigine Heaven and pretty much anything else which uses the extension. Mesa's implementation of ARB_draw_instanced is broken for me. Whether it's broken in the name of religion or compliance with the specification, I don't really give a damn. What I truly give a damn about is whether the Unigine engine works. And last time I tried, it worked without any graphical glitches on all Radeon Gallium drivers as long as I don't enable that extension. Marek ___ mesa-dev mailing list
