date:20131107

https://bugs.freedesktop.org/show_bug.cgi?id=67672

Vladimír Čunát vcu...@gmail.com changed:

   What|Removed |Added

 CC||vcu...@gmail.com

--- Comment #16 from Vladimír Čunát vcu...@gmail.com ---
As for the patches, IMHO the only interferrable is the one adding
--enable-shared-gallium, which was taken from Ubuntu (I think).

-- 
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] [v2 3/6] glsl: ir_serializer class for the shader cache

On 11/06/2013 12:55 PM, Paul Berry wrote:
[snip]
 Ok, I think you are correct about the functions.  But I believe for
 variables, the ir_variable always appears in the IR before any
 references to it.  Can someone confirm this? (Ken or Ian perhaps?)

That's correct, and actually critical.  Driver backends allocate storage
space for variables when they see ir_variable declarations in the
instruction stream.  Later, when they encounter an
ir_dereference_variable, they look up the storage for that variable,
which must already exist.  (i965 has assertions to verify this - if you
dereference a variable that hasn't been declared yet, it will abort.)

--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/37] mesa/program: move source files list to Makefile.sources

2013-11-07 Thread Adrian M Negreanu

On Tue, Nov 5, 2013 at 8:55 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
 On 05/11/13 18:18, Chad Versace wrote:
 On 11/02/2013 12:00 PM, Emil Velikov wrote:
 Rip out the source file list from mesa/Makefile.sources, to a
 more sensible location/file.
 * Split PROGRAM_FILES and GENERATED_FILES.
 * Update the automake and Android build systems.

 Android
 * Slightly reshuffle the Android.mk for readability sake.
 * Use GENERATED_FILES, drop the TODO item.
 * Use explicit 'call' when executing local macros.

 Cc: Chad Versace chad.vers...@linux.intel.com
 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---

 Andoid changes are _not_ tested (yet).

I've applied the first 10 patches in the series on top of
f407ea1f1c8c4f2de188fcfa05cdb83950b51355,
to get rid of the conflicts and such.

With this, I get an error in program_lexer.l, which is caused by
moving the program_pars.tab.{h,c} from
$(intermediates)/program/ to $(intermediates)/

  target  C: libmesa_program =
out/target/product/samsungxe700t/obj/STATIC_LIBRARIES/libmesa_program_intermediates/lex.yy.c
  external/mesa-master/src/mesa/program/program_lexer.l:30:39: fatal
error: program/program_parse.tab.h: No such file or directory




 Thanks
 Emil

 ---
   src/mesa/Makefile.sources | 24 ---
   src/mesa/program/Android.mk   | 65
 ---
   src/mesa/program/Makefile.am  | 25 +--
   src/mesa/program/Makefile.sources | 27 
   4 files changed, 69 insertions(+), 72 deletions(-)
   create mode 100644 src/mesa/program/Makefile.sources

 diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
 index a84f8a7..e4146ae 100644
 --- a/src/mesa/Makefile.sources
 +++ b/src/mesa/Makefile.sources
 @@ -252,30 +252,6 @@ STATETRACKER_FILES = \
   $(SRCDIR)state_tracker/st_texture.c \
   $(SRCDIR)state_tracker/st_vdpau.c

 -PROGRAM_FILES = \
 -$(SRCDIR)program/arbprogparse.c \
 -$(SRCDIR)program/prog_hash_table.c \
 -$(SRCDIR)program/ir_to_mesa.cpp \
 -$(SRCDIR)program/program.c \
 -$(SRCDIR)program/program_parse_extra.c \
 -$(SRCDIR)program/prog_cache.c \
 -$(SRCDIR)program/prog_execute.c \
 -$(SRCDIR)program/prog_instruction.c \
 -$(SRCDIR)program/prog_noise.c \
 -$(SRCDIR)program/prog_optimize.c \
 -$(SRCDIR)program/prog_opt_constant_fold.c \
 -$(SRCDIR)program/prog_parameter.c \
 -$(SRCDIR)program/prog_parameter_layout.c \
 -$(SRCDIR)program/prog_print.c \
 -$(SRCDIR)program/prog_statevars.c \
 -$(SRCDIR)program/programopt.c \
 -$(SRCDIR)program/register_allocate.c \
 -$(SRCDIR)program/sampler.cpp \
 -$(SRCDIR)program/string_to_uint_map.cpp \
 -$(SRCDIR)program/symbol_table.c \
 -$(BUILDDIR)program/lex.yy.c \
 -$(BUILDDIR)program/program_parse.tab.c
 -
   ASM_C_FILES =\
   $(SRCDIR)x86/common_x86.c \
   $(SRCDIR)x86/x86_xform.c \
 diff --git a/src/mesa/program/Android.mk b/src/mesa/program/Android.mk
 index e85afe6..e340ed4 100644
 --- a/src/mesa/program/Android.mk
 +++ b/src/mesa/program/Android.mk
 @@ -18,8 +18,30 @@
   # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
   # DEALINGS IN THE SOFTWARE.

 +# --
 +# libmesa_program.a
 +# --
   LOCAL_PATH := $(call my-dir)

 +# get PROGRAM_FILES and GENERATED_FILES
 +include $(LOCAL_PATH)/Makefile.sources
 +include $(CLEAR_VARS)
 +
 +LOCAL_MODULE := libmesa_program
 +LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 +
 +intermediates := $(call local-intermediates-dir)
 +
 +LOCAL_C_INCLUDES := \
 +$(intermediates) \
 +$(MESA_TOP)/src/mapi \
 +$(MESA_TOP)/src/mesa \
 +$(MESA_TOP)/src/glsl
 +
 +
 +LOCAL_SRC_FILES := $(PROGRAM_FILES)
 +LOCAL_GENERATED_SOURCES := $(addprefix
 $(intermediates)/,$(GENERATED_FILES))
 +
   define local-l-to-c
   @mkdir -p $(dir $@)
   @echo Mesa Lex: $(PRIVATE_MODULE) = $
 @@ -32,48 +54,15 @@ define mesa_local-y-to-c-and-h
   $(hide) $(YACC) -o $@ -p _mesa_program_ $
   endef

 -# --
 -# libmesa_program.a
 -# --
 -
 -# Import the following variables:
 -# PROGRAM_FILES
 -include $(MESA_TOP)/src/mesa/Makefile.sources
 -
 -include $(CLEAR_VARS)
 -
 -LOCAL_MODULE := libmesa_program
 -LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 -
 -intermediates := $(call local-intermediates-dir)
 +$(intermediates)/lex.yy.c: $(LOCAL_PATH)/program_lexer.l
 +$(call local-l-to-c)

 -# TODO(chadv): In Makefile.sources, move these vars to a different
 list so we can
 -# remove this kludge.
 -generated_sources_basenames := \
 -lex.yy.c \
 -program_parse.tab.c \
 -program_parse.tab.h
 +$(intermediates)/program_parse.tab.c: $(LOCAL_PATH)/program_parse.y
 +$(call mesa_local-y-to-c-and-h)

[Mesa-dev] [PATCH 0/7] ARB_vertex_type_10f_11f_11f_rev for i965

Ever since this had appeared as part of GL4.4 I'd been curious
about whether this extension was going to Just Work, or be a
workaround-party like ARB_vertex_type_2_10_10_10_rev.

Today my curiousity got the better of me, and it turns out it
just works.

Tested and enabled on Gen6+ -- theoretically could work on earlier
gens as well, but the spec requires 3.0 so little point.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/7] mesa: add varray support for UNSIGNED_INT_10F_11F_11F_REV type

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 src/mesa/main/varray.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index dee476a..5af4c8c 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -60,6 +60,7 @@
 #define FIXED_GL_BIT 0x800
 #define UNSIGNED_INT_2_10_10_10_REV_BIT 0x1000
 #define INT_2_10_10_10_REV_BIT 0x2000
+#define UNSIGNED_INT_10F_11F_11F_REV_BIT 0x4000
 
 
 /** Convert GL datatype enum into a type_BIT value seen above */
@@ -96,6 +97,8 @@ type_to_bit(const struct gl_context *ctx, GLenum type)
   return UNSIGNED_INT_2_10_10_10_REV_BIT;
case GL_INT_2_10_10_10_REV:
   return INT_2_10_10_10_REV_BIT;
+   case GL_UNSIGNED_INT_10F_11F_11F_REV:
+  return UNSIGNED_INT_10F_11F_11F_REV_BIT;
default:
   return 0;
}
@@ -150,7 +153,7 @@ update_array(struct gl_context *ctx,
}
 
if (_mesa_is_gles(ctx)) {
-  legalTypesMask = ~(FIXED_GL_BIT | DOUBLE_BIT);
+  legalTypesMask = ~(FIXED_GL_BIT | DOUBLE_BIT | 
UNSIGNED_INT_10F_11F_11F_REV_BIT);
 
   /* GL_INT and GL_UNSIGNED_INT data is not allowed in OpenGL ES until
* 3.0.  The 2_10_10_10 types are added in OpenGL ES 3.0 or
@@ -180,6 +183,9 @@ update_array(struct gl_context *ctx,
   if (!ctx-Extensions.ARB_vertex_type_2_10_10_10_rev)
  legalTypesMask = ~(UNSIGNED_INT_2_10_10_10_REV_BIT |
  INT_2_10_10_10_REV_BIT);
+
+  if (!ctx-Extensions.ARB_vertex_type_10f_11f_11f_rev)
+ legalTypesMask = ~UNSIGNED_INT_10F_11F_11F_REV_BIT;
}
 
typeBit = type_to_bit(ctx, type);
@@ -243,6 +249,12 @@ update_array(struct gl_context *ctx,
   return;
}
 
+   if (ctx-Extensions.ARB_vertex_type_10f_11f_11f_rev 
+ type == GL_UNSIGNED_INT_10F_11F_11F_REV  size != 3) {
+  _mesa_error(ctx, GL_INVALID_OPERATION, %s(size=%d), func, size);
+  return;
+   }
+
ASSERT(size = 4);
 
if (stride  0) {
@@ -473,7 +485,8 @@ _mesa_VertexAttribPointer(GLuint index, GLint size, GLenum 
type,
   HALF_BIT | FLOAT_BIT | DOUBLE_BIT |
   FIXED_ES_BIT | FIXED_GL_BIT |
   UNSIGNED_INT_2_10_10_10_REV_BIT |
-  INT_2_10_10_10_REV_BIT);
+  INT_2_10_10_10_REV_BIT |
+  UNSIGNED_INT_10F_11F_11F_REV_BIT);
GET_CURRENT_CONTEXT(ctx);
 
if (index = ctx-Const.VertexProgram.MaxAttribs) {
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/7] mesa: Add extension scaffolding for ARB_vertex_type_10f_11f_11f_rev

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 src/mesa/main/extensions.c | 1 +
 src/mesa/main/mtypes.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 48c4e9f..3da1c42 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -168,6 +168,7 @@ static const struct extension extension_table[] = {
{ GL_ARB_vertex_buffer_object,o(dummy_true),  
GLL,2003 },
{ GL_ARB_vertex_program,  o(ARB_vertex_program),  
GLL,2002 },
{ GL_ARB_vertex_shader,   o(ARB_vertex_shader),   
GL, 2002 },
+   { GL_ARB_vertex_type_10f_11f_11f_rev, 
o(ARB_vertex_type_10f_11f_11f_rev), GL, 2013 },
{ GL_ARB_vertex_type_2_10_10_10_rev,  
o(ARB_vertex_type_2_10_10_10_rev),  GL, 2009 },
{ GL_ARB_window_pos,  o(dummy_true),  
GLL,2001 },
/* EXT extensions */
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index b5c5583..c6322c9 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3291,6 +3291,7 @@ struct gl_extensions
GLboolean ARB_uniform_buffer_object;
GLboolean ARB_vertex_program;
GLboolean ARB_vertex_shader;
+   GLboolean ARB_vertex_type_10f_11f_11f_rev;
GLboolean ARB_vertex_type_2_10_10_10_rev;
GLboolean EXT_blend_color;
GLboolean EXT_blend_equation_separate;
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/7] mesa: Add support to _mesa_bytes_per_vertex_attrib for 10_11_11 format.

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 src/mesa/main/glformats.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index dfee6f1..740faa8 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -345,6 +345,11 @@ _mesa_bytes_per_vertex_attrib(GLint comps, GLenum type)
  return sizeof(GLuint);
   else
  return -1;
+   case GL_UNSIGNED_INT_10F_11F_11F_REV:
+  if (comps == 3)
+ return sizeof(GLuint);
+  else
+ return -1;
default:
   return -1;
}
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 6/7] i965: Enable ARB_vertex_type_10f_11f_11f_rev on Gen6+.

This theoretically works on earlier hardware as well, but the extension
requires at least GL3.0.

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 5eae84f..fbda424 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -210,6 +210,7 @@ intelInitExtensions(struct gl_context *ctx)
   ctx-Extensions.ARB_shading_language_packing = true;
   ctx-Extensions.ARB_texture_multisample = true;
   ctx-Extensions.ARB_sample_shading = true;
+  ctx-Extensions.ARB_vertex_type_10f_11f_11f_rev = true;
 
   /* Test if the kernel has the ioctl. */
   if (drm_intel_reg_read(brw-bufmgr, TIMESTAMP, dummy) == 0)
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 7/7] docs: Mark off ARB_vertex_type_10f_11f_11f_rev.

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 docs/GL3.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index 7d100df..93bd09e 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -175,7 +175,7 @@ GL_ARB_multi_bindnot 
started
 GL_ARB_query_buffer_object   not started
 GL_ARB_texture_mirror_clamp_to_edge  DONE (i965, nv30, nv50, 
nvc0, r300, r600, radeonsi, swrast)
 GL_ARB_texture_stencil8  not started
-GL_ARB_vertex_type_10f_11f_11f_rev   not started
+GL_ARB_vertex_type_10f_11f_11f_rev   DONE (i965)
 
 
 More info about these features and the work involved can be found at
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/7] vbo: add 10_11_11 support to vbo_attrib_tmp

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 src/mesa/vbo/vbo_attrib_tmp.h | 32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/src/mesa/vbo/vbo_attrib_tmp.h b/src/mesa/vbo/vbo_attrib_tmp.h
index bbc0205..358d12d 100644
--- a/src/mesa/vbo/vbo_attrib_tmp.h
+++ b/src/mesa/vbo/vbo_attrib_tmp.h
@@ -25,6 +25,8 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
 
 **/
 
+#include util/u_format_r11g11b10f.h
+
 /* float */
 #define ATTR1FV( A, V ) ATTR( A, 1, GL_FLOAT, (V)[0], 0, 0, 1 )
 #define ATTR2FV( A, V ) ATTR( A, 2, GL_FLOAT, (V)[0], (V)[1], 0, 1 )
@@ -205,6 +207,10 @@ static inline float conv_i2_to_norm_float(const struct 
gl_context *ctx, int i2)
   } else { \
 ATTRI10_##val((attr), (arg));  \
   }\
+   } else if ((type) == GL_UNSIGNED_INT_10F_11F_11F_REV) { \
+  float res[4];\
+  r11g11b10f_to_float3((arg), res);\
+  ATTR##val##FV((attr), res);  \
} else  \
   ERROR(GL_INVALID_VALUE); \
} while(0)
@@ -835,12 +841,26 @@ TAG(VertexAttrib4fvNV)(GLuint index, const GLfloat * v)
   ATTR4FV(index, v);
 }
 
+
 #define ERROR_IF_NOT_PACKED_TYPE(ctx, type, func) \
if (type != GL_INT_2_10_10_10_REV  type != 
GL_UNSIGNED_INT_2_10_10_10_REV) { \
   _mesa_error(ctx, GL_INVALID_ENUM, %s(type), func); \
   return; \
}
 
+/* Extended version of ERROR_IF_NOT_PACKED_TYPE which also
+ * accepts GL_UNSIGNED_INT_10F_11F_11F_REV.
+ *
+ * Only used for VertexAttribP[123]ui[v]; VertexAttribP4* cannot use this type,
+ * and neither can legacy vertex attribs.
+ */
+#define ERROR_IF_NOT_PACKED_TYPE_EXT(ctx, type, func) \
+   if (type != GL_INT_2_10_10_10_REV  type != GL_UNSIGNED_INT_2_10_10_10_REV 
 \
+   type != GL_UNSIGNED_INT_10F_11F_11F_REV) { \
+  _mesa_error(ctx, GL_INVALID_ENUM, %s(type), func); \
+  return; \
+   }
+
 static void GLAPIENTRY
 TAG(VertexP2ui)(GLenum type, GLuint value)
 {
@@ -1094,7 +1114,7 @@ TAG(VertexAttribP1ui)(GLuint index, GLenum type, 
GLboolean normalized,
  GLuint value)
 {
GET_CURRENT_CONTEXT(ctx);
-   ERROR_IF_NOT_PACKED_TYPE(ctx, type, glVertexAttribP1ui);
+   ERROR_IF_NOT_PACKED_TYPE_EXT(ctx, type, glVertexAttribP1ui);
ATTR_UI_INDEX(ctx, 1, type, normalized, index, value);
 }
 
@@ -1103,7 +1123,7 @@ TAG(VertexAttribP2ui)(GLuint index, GLenum type, 
GLboolean normalized,
  GLuint value)
 {
GET_CURRENT_CONTEXT(ctx);
-   ERROR_IF_NOT_PACKED_TYPE(ctx, type, glVertexAttribP2ui);
+   ERROR_IF_NOT_PACKED_TYPE_EXT(ctx, type, glVertexAttribP2ui);
ATTR_UI_INDEX(ctx, 2, type, normalized, index, value);
 }
 
@@ -1112,7 +1132,7 @@ TAG(VertexAttribP3ui)(GLuint index, GLenum type, 
GLboolean normalized,
  GLuint value)
 {
GET_CURRENT_CONTEXT(ctx);
-   ERROR_IF_NOT_PACKED_TYPE(ctx, type, glVertexAttribP3ui);
+   ERROR_IF_NOT_PACKED_TYPE_EXT(ctx, type, glVertexAttribP3ui);
ATTR_UI_INDEX(ctx, 3, type, normalized, index, value);
 }
 
@@ -1130,7 +1150,7 @@ TAG(VertexAttribP1uiv)(GLuint index, GLenum type, 
GLboolean normalized,
   const GLuint *value)
 {
GET_CURRENT_CONTEXT(ctx);
-   ERROR_IF_NOT_PACKED_TYPE(ctx, type, glVertexAttribP1uiv);
+   ERROR_IF_NOT_PACKED_TYPE_EXT(ctx, type, glVertexAttribP1uiv);
ATTR_UI_INDEX(ctx, 1, type, normalized, index, *value);
 }
 
@@ -1139,7 +1159,7 @@ TAG(VertexAttribP2uiv)(GLuint index, GLenum type, 
GLboolean normalized,
   const GLuint *value)
 {
GET_CURRENT_CONTEXT(ctx);
-   ERROR_IF_NOT_PACKED_TYPE(ctx, type, glVertexAttribP2uiv);
+   ERROR_IF_NOT_PACKED_TYPE_EXT(ctx, type, glVertexAttribP2uiv);
ATTR_UI_INDEX(ctx, 2, type, normalized, index, *value);
 }
 
@@ -1148,7 +1168,7 @@ TAG(VertexAttribP3uiv)(GLuint index, GLenum type, 
GLboolean normalized,
   const GLuint *value)
 {
GET_CURRENT_CONTEXT(ctx);
-   ERROR_IF_NOT_PACKED_TYPE(ctx, type, glVertexAttribP3uiv);
+   ERROR_IF_NOT_PACKED_TYPE_EXT(ctx, type, glVertexAttribP3uiv);
ATTR_UI_INDEX(ctx, 3, type, normalized, index, *value);
 }
 
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/7] i965: add support for UNSIGNED_INT_10F_11F_11F_REV vertex attribs

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
 src/mesa/drivers/dri/i965/brw_draw_upload.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c 
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index 4da1b7e..e2002e8 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -244,6 +244,8 @@ brw_get_vertex_surface_type(struct brw_context *brw,
   case GL_UNSIGNED_BYTE: return ubyte_types_direct[size];
   default: assert(0); return 0;
   }
+   } else if (glarray-Type == GL_UNSIGNED_INT_10F_11F_11F_REV) {
+  return BRW_SURFACEFORMAT_R11G11B10_FLOAT;
} else if (glarray-Normalized) {
   switch (glarray-Type) {
   case GL_DOUBLE: return double_types[size];
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] st/xorg: Delete.

2013-11-07 Thread Lucas Stach

Am Mittwoch, den 06.11.2013, 21:52 -0800 schrieb Matt Turner:
 ---
 Deleted files diff removed.
 
I think there was some nice stuff in here that didn't make it into XA,
but that's no valid reason to keep st/xorg alive in the tree.

If someone is interested in porting things to XA, it's just some git
history digging.

So,
Acked-by: Lucas Stach l.st...@pengutronix.de

  configure.ac |   56 +-
  src/gallium/SConscript   |3 -
  src/gallium/state_trackers/Makefile.am   |4 -
  src/gallium/state_trackers/xorg/Makefile.am  |   43 -
  src/gallium/state_trackers/xorg/Makefile.sources |   11 -
  src/gallium/state_trackers/xorg/SConscript   |   29 -
  src/gallium/state_trackers/xorg/compat-api.h |   99 --
  src/gallium/state_trackers/xorg/xorg_composite.c |  585 --
  src/gallium/state_trackers/xorg/xorg_composite.h |   36 -
  src/gallium/state_trackers/xorg/xorg_crtc.c  |  448 
  src/gallium/state_trackers/xorg/xorg_dri2.c  |  473 
  src/gallium/state_trackers/xorg/xorg_driver.c| 1323 
 --
  src/gallium/state_trackers/xorg/xorg_exa.c   | 1087 --
  src/gallium/state_trackers/xorg/xorg_exa.h   |   76 --
  src/gallium/state_trackers/xorg/xorg_exa_tgsi.c  |  690 ---
  src/gallium/state_trackers/xorg/xorg_exa_tgsi.h  |   59 -
  src/gallium/state_trackers/xorg/xorg_output.c|  331 --
  src/gallium/state_trackers/xorg/xorg_renderer.c  |  547 -
  src/gallium/state_trackers/xorg/xorg_renderer.h  |   81 --
  src/gallium/state_trackers/xorg/xorg_tracker.h   |  236 
  src/gallium/state_trackers/xorg/xorg_winsys.h|   50 -
  src/gallium/state_trackers/xorg/xorg_xv.c|  750 
  src/gallium/state_trackers/xorg/xorg_xvmc.c  |  119 --
  23 files changed, 11 insertions(+), 7125 deletions(-)
  delete mode 100644 src/gallium/state_trackers/xorg/Makefile.am
  delete mode 100644 src/gallium/state_trackers/xorg/Makefile.sources
  delete mode 100644 src/gallium/state_trackers/xorg/SConscript
  delete mode 100644 src/gallium/state_trackers/xorg/compat-api.h
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_composite.c
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_composite.h
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_crtc.c
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_dri2.c
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_driver.c
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_exa.c
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_exa.h
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_exa_tgsi.c
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_exa_tgsi.h
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_output.c
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_renderer.c
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_renderer.h
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_tracker.h
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_winsys.h
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_xv.c
  delete mode 100644 src/gallium/state_trackers/xorg/xorg_xvmc.c
 
 diff --git a/configure.ac b/configure.ac
 index 6caa125..28faf24 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -35,8 +35,6 @@ LIBDRM_NOUVEAU_REQUIRED=2.4.33 libdrm = 2.4.41
  LIBDRM_FREEDRENO_REQUIRED=2.4.39
  DRI2PROTO_REQUIRED=2.6
  GLPROTO_REQUIRED=1.4.14
 -LIBDRM_XORG_REQUIRED=2.4.24
 -LIBKMS_XORG_REQUIRED=1.0.0
  
  dnl Check for progs
  AC_PROG_CPP
 @@ -556,11 +554,6 @@ AC_ARG_ENABLE([egl],
  [enable_egl=$enableval],
  [enable_egl=yes])
  
 -AC_ARG_ENABLE([xorg],
 -[AS_HELP_STRING([--enable-xorg],
 -[enable support for X.Org DDX API @:@default=no@:@])],
 -[enable_xorg=$enableval],
 -[enable_xorg=no])
  AC_ARG_ENABLE([xa],
  [AS_HELP_STRING([--enable-xa],
  [enable build of the XA X Acceleration API @:@default=no@:@])],
 @@ -651,7 +644,6 @@ if test x$enable_opengl = xno -a \
  x$enable_gles1 = xno -a \
  x$enable_gles2 = xno -a \
  x$enable_openvg = xno -a \
 -x$enable_xorg = xno -a \
  x$enable_xa = xno -a \
  x$enable_xvmc = xno -a \
  x$enable_vdpau = xno -a \
 @@ -1236,20 +1228,6 @@ fi
  AM_CONDITIONAL(HAVE_GALLIUM_GBM, test x$enable_gallium_gbm = xyes)
  
  dnl
 -dnl X.Org DDX configuration
 -dnl
 -if test x$enable_xorg = xyes; then
 -PKG_CHECK_MODULES([XORG], [xorg-server = 1.6.0])
 -PKG_CHECK_MODULES([LIBDRM_XORG], [libdrm = $LIBDRM_XORG_REQUIRED])
 -PKG_CHECK_MODULES([LIBKMS_XORG], [libkms = $LIBKMS_XORG_REQUIRED])
 -PKG_CHECK_MODULES(XEXT, [xextproto = 7.0.99.1],
 -HAVE_XEXTPROTO_71=yes; DEFINES=$DEFINES -DHAVE_XEXTPROTO_71,
 -HAVE_XEXTPROTO_71=no)
 -GALLIUM_STATE_TRACKERS_DIRS=xorg $GALLIUM_STATE_TRACKERS_DIRS
 -fi
 -AM_CONDITIONAL(HAVE_ST_XORG, test x$enable_xorg =

[Mesa-dev] [Bug 67672] 9.2 git, Test failure in src/gallium/drivers/llvmpipe

https://bugs.freedesktop.org/show_bug.cgi?id=67672

--- Comment #17 from Roland Scheidegger srol...@vmware.com ---
(In reply to comment #15)
 I can reproduce the problem on my machine.
 
 I'm using the tarball at
 ftp://ftp.freedesktop.org/pub/mesa/${version}/MesaLib-${version}.tar.bz2 ,
 where version is 9.2.2, with some distribution-specific patches and
 configuration options (NixOS x-updates branch).  If you think these might be
 interfering, let me know and I'll see if I can build without the changes.
 
 
 Here's my output for GALLIUM_DUMP_CPU=1 ./lp_test_arit (with LD_LIBRARY_PATH
 set for annoying reasons):
 
 $
 LD_LIBRARY_PATH=/tmp/nix-build-mesa-noglu-9.2.2.drv-0/Mesa-9.2.2/src/gallium/
 auxiliary/gallivm/.libs/lp_bld_init.o GALLIUM_DUMP_CPU=1
 ./lp_test_arit
 util_cpu_caps.nr_cpus = 3
 util_cpu_caps.x86_cpu_type = 9
 util_cpu_caps.cacheline = 64
 util_cpu_caps.has_tsc = 1
 util_cpu_caps.has_mmx = 1
 util_cpu_caps.has_mmx2 = 1
 util_cpu_caps.has_sse = 1
 util_cpu_caps.has_sse2 = 1
 util_cpu_caps.has_sse3 = 1
 util_cpu_caps.has_ssse3 = 0
 util_cpu_caps.has_sse4_1 = 0
 util_cpu_caps.has_sse4_2 = 0
 util_cpu_caps.has_avx = 0
 util_cpu_caps.has_3dnow = 1
 util_cpu_caps.has_3dnow_ext = 1
 util_cpu_caps.has_altivec = 0

 processor : 0
 vendor_id : GenuineIntel
 cpu family: 6
 model : 58
 model name: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
 stepping  : 9
 microcode : 0x12
 cpu MHz   : 1200.000
 cache size: 4096 KB
 physical id   : 0
 siblings  : 4
 core id   : 0
 cpu cores : 2
 apicid: 0
 initial apicid: 0
 fpu   : yes
 fpu_exception : yes
 cpuid level   : 13
 wp: yes
 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
 pat
 pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
 constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
 aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16
 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx
 f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi
 flexpriority ept vpid fsgsbase smep erms

Hmm the util_cpu_caps are totally busted, I wonder what's up with that...

-- 
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] DEFAULT_SOFTWARE_DEPTH_BITS=31

On 11/06/2013 04:59 PM, burlen wrote:

On 11/06/2013 12:58 PM, Brian Paul wrote:

On 11/06/2013 12:34 PM, burlen wrote:

When I build osmesa with --with-osmesa-bits=32 I notice that I get 31
bits by way of the compile line define -DDEFAULT_SOFTWARE_DEPTH_BITS=31.
What's the story with the number 31? Is 31 bits really better than 32?

IIRC, 32 bit Z never worked properly because of float-int conversion
problems and such. I think I found that 31 bits worked though. It's
been a long time...

I'm using OSMesa with VTK for rendering on systems that do not have
graphics hardware. I need higher than default depth buffer with OSMesa
to prevent z-buffer fighting artifacts in some cases when rendering in
parallel. I found that --with-osmesa-bits=32 does the trick. however
when building osmesa with 32 bits, most line rendering fails. Here is a
representative image diff from our regression suite that shows an
example of the bug
http://open.cdash.org/testDetails.php?test=216532438build=3087854
https://urldefense.proofpoint.com/v1/url?u=http://open.cdash.org/testDetails.php?test%3D216532438%26build%3D3087854k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=RSWC%2F0O7rDfFjJWLpUVeoSImwj8RMeWUaKnhSM%2Fx2Nk%3D%0As=11a634d8629f9a7fc613440fd0337a158f6951974892d2427bae4b5f570ad641
, there are 80 other failed tests, the ones I examined were all the same.

Experimenting with --with-osmesa-bits options, I've found that using 32
causes the issue, while using 8 , 16 or not using it all doesn't. Do you
have any idea about this?

I set DEFAULT_SOFTWARE_DEPTH_BITS=32 and tried a few demo programs and
they look OK so far.

Could you possibly create an apitrace of one of the failing cases?

-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2 04/15] mesa: Add binding point for indirect buffer


On 11/07/2013 12:06 AM, Chris Forbes wrote:

Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
  src/mesa/main/bufferobj.c| 14 ++
  src/mesa/main/get.c  |  4 
  src/mesa/main/get_hash_params.py |  2 ++
  src/mesa/main/mtypes.h   |  2 ++
  4 files changed, 22 insertions(+)

diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 1f55061..a75802e 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -86,6 +86,12 @@ get_buffer_target(struct gl_context *ctx, GLenum target)
return ctx-CopyReadBuffer;
 case GL_COPY_WRITE_BUFFER:
return ctx-CopyWriteBuffer;
+   case GL_DRAW_INDIRECT_BUFFER:
+  if (ctx-API == API_OPENGL_CORE 
+  ctx-Extensions.ARB_draw_indirect) {
+ return ctx-DrawIndirectBuffer;
+  }
+  break;
 case GL_TRANSFORM_FEEDBACK_BUFFER:
if (ctx-Extensions.EXT_transform_feedback) {
   return ctx-TransformFeedback.CurrentBuffer;
@@ -626,6 +632,9 @@ _mesa_init_buffer_objects( struct gl_context *ctx )
 _mesa_reference_buffer_object(ctx, ctx-UniformBuffer,
 ctx-Shared-NullBufferObj);

+   _mesa_reference_buffer_object(ctx, ctx-DrawIndirectBuffer,
+ctx-Shared-NullBufferObj);
+
 for (i = 0; i  MAX_COMBINED_UNIFORM_BUFFERS; i++) {
_mesa_reference_buffer_object(ctx,
ctx-UniformBufferBindings[i].BufferObject,
@@ -873,6 +882,11 @@ _mesa_DeleteBuffers(GLsizei n, const GLuint *ids)
  _mesa_BindBuffer( GL_ELEMENT_ARRAY_BUFFER_ARB, 0 );
   }

+ /* unbind ARB_draw_indirect binding point */
+ if (ctx-DrawIndirectBuffer == bufObj) {
+_mesa_BindBuffer( GL_DRAW_INDIRECT_BUFFER, 0 );
+ }
+
   /* unbind ARB_copy_buffer binding points */
   if (ctx-CopyReadBuffer == bufObj) {
  _mesa_BindBuffer( GL_COPY_READ_BUFFER, 0 );
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index ad53b25..a471383 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -914,6 +914,10 @@ find_custom_value(struct gl_context *ctx, const struct 
value_desc *d, union valu
 case GL_ATOMIC_COUNTER_BUFFER_BINDING:
v-value_int = ctx-AtomicBuffer-Name;
break;
+   /* GL_ARB_draw_indirect */
+   case GL_DRAW_INDIRECT_BUFFER_BINDING:
+  v-value_int = ctx-DrawIndirectBuffer-Name;
+  break;
 }
  }

diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 0851b7b..226ede0 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -743,6 +743,8 @@ descriptor=[
  { apis: [GL_CORE], params: [
  # GL_ARB_texture_buffer_range
[ TEXTURE_BUFFER_OFFSET_ALIGNMENT, 
CONTEXT_INT(Const.TextureBufferOffsetAlignment), extra_ARB_texture_buffer_range ],
+# GL_ARB_draw_indirect
+  [ DRAW_INDIRECT_BUFFER_BINDING, LOC_CUSTOM, TYPE_INT, 0, 
extra_ARB_draw_indirect ],


Does this really need a LOC_CUSTOM?  Could we just do:

[ DRAW_INDIRECT_BUFFER_BINDING, 
CONTEXT_INT(DrawIndirectBuffer-name), extra_ARB_draw_indirect ],


and remove the switch case above?




  ]}

  ]
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index b474878..4f4fc52 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3813,6 +3813,8 @@ struct gl_context

 struct gl_perf_monitor_state PerfMonitor;

+   struct gl_buffer_object *DrawIndirectBuffer; /**  GL_ARB_draw_indirect */
+
 struct gl_buffer_object *CopyReadBuffer; /** GL_ARB_copy_buffer */
 struct gl_buffer_object *CopyWriteBuffer; /** GL_ARB_copy_buffer */




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2 14/15] vbo: map indirect buffer and extract params if doing sw primitive restart


On 11/07/2013 12:06 AM, Chris Forbes wrote:

V2: Check for mapping failure (thanks Brian)

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
  src/mesa/vbo/vbo_primitive_restart.c | 33 +
  1 file changed, 33 insertions(+)

diff --git a/src/mesa/vbo/vbo_primitive_restart.c 
b/src/mesa/vbo/vbo_primitive_restart.c
index 48d04e1..ee84f10 100644
--- a/src/mesa/vbo/vbo_primitive_restart.c
+++ b/src/mesa/vbo/vbo_primitive_restart.c
@@ -180,6 +180,39 @@ vbo_sw_primitive_restart(struct gl_context *ctx,
 GLboolean map_ib = ib-obj-Name  !ib-obj-Pointer;
 void *ptr;

+   /* If there is an indirect buffer, map it and extract the draw params */
+   if (indirect  prims[0].is_indirect) {
+  struct _mesa_prim new_prim = *prims;
+  struct _mesa_index_buffer new_ib = *ib;
+  const uint32_t *indirect_params;
+  if (!ctx-Driver.MapBufferRange(ctx, 0, indirect-Size, GL_MAP_READ_BIT,
+(struct gl_buffer_object *)indirect)) {
+
+ /* something went wrong with mapping, give up */
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ failed to map indirect buffer for sw primitive restart);


I suspect we'd only hit this if we ran out of memory earlier and failed 
to allocate the buffer.  So, I'd probably report GL_OUT_OF_MEMORY here. 
 I think we do that in other places where mapping fails too.


The rest of the core Mesa changes look OK to me.  For those:
Reviewed-by: Brian Paul bri...@vmware.com


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] DEFAULT_SOFTWARE_DEPTH_BITS=31

2013-11-07 Thread burlen

On 11/07/2013 06:42 AM, Brian Paul wrote:

On 11/06/2013 04:59 PM, burlen wrote:

On 11/06/2013 12:58 PM, Brian Paul wrote:

On 11/06/2013 12:34 PM, burlen wrote:

When I build osmesa with --with-osmesa-bits=32 I notice that I get 31
bits by way of the compile line define
-DDEFAULT_SOFTWARE_DEPTH_BITS=31.

What's the story with the number 31? Is 31 bits really better than 32?

IIRC, 32 bit Z never worked properly because of float-int conversion
problems and such. I think I found that 31 bits worked though. It's
been a long time...

, there are 80 other failed tests, the ones I examined were all the
same.

Experimenting with --with-osmesa-bits options, I've found that using 32
causes the issue, while using 8 , 16 or not using it all doesn't. Do you
have any idea about this?

I set DEFAULT_SOFTWARE_DEPTH_BITS=32 and tried a few demo programs and
they look OK so far.

Could you possibly create an apitrace of one of the failing cases?

did you set DEFAULT_SOFTWARE_DEPTH_BITS=32 or --with-osmesa-bits=32?
--with-osmesa-bits=16 also sets depth bits to 31, and that case doesn't
have the problem. so seems that it's something other than the depth bits
about the --with-osmesa-bits=32 build.

I'll see about the apitrace

Thanks
Burlen

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] DEFAULT_SOFTWARE_DEPTH_BITS=31

On 11/07/2013 09:09 AM, burlen wrote:

On 11/07/2013 06:42 AM, Brian Paul wrote:

On 11/06/2013 04:59 PM, burlen wrote:

On 11/06/2013 12:58 PM, Brian Paul wrote:

On 11/06/2013 12:34 PM, burlen wrote:

When I build osmesa with --with-osmesa-bits=32 I notice that I get 31
bits by way of the compile line define
-DDEFAULT_SOFTWARE_DEPTH_BITS=31.
What's the story with the number 31? Is 31 bits really better than 32?

IIRC, 32 bit Z never worked properly because of float-int conversion
problems and such. I think I found that 31 bits worked though. It's
been a long time...

I'm using OSMesa with VTK for rendering on systems that do not have
graphics hardware. I need higher than default depth buffer with OSMesa
to prevent z-buffer fighting artifacts in some cases when rendering in
parallel. I found that --with-osmesa-bits=32 does the trick. however
when building osmesa with 32 bits, most line rendering fails. Here is a
representative image diff from our regression suite that shows an
example of the bug
https://urldefense.proofpoint.com/v1/url?u=http://open.cdash.org/testDetails.php?test%3D216532438%26build%3D3087854k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=%2BYxiKNKy6tM2b9uufQKWyLEbSfkSZWpC8Kv9gQu9jJs%3D%0As=0f54945a95ef4530f46e70322823ee22159a9400fe3fae6b9c4a324a93ee3c00

https://urldefense.proofpoint.com/v1/url?u=http://open.cdash.org/testDetails.php?test%3D216532438%26build%3D3087854k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=RSWC%2F0O7rDfFjJWLpUVeoSImwj8RMeWUaKnhSM%2Fx2Nk%3D%0As=11a634d8629f9a7fc613440fd0337a158f6951974892d2427bae4b5f570ad641

, there are 80 other failed tests, the ones I examined were all the
same.

Experimenting with --with-osmesa-bits options, I've found that using 32
causes the issue, while using 8 , 16 or not using it all doesn't. Do you
have any idea about this?

I set DEFAULT_SOFTWARE_DEPTH_BITS=32 and tried a few demo programs and
they look OK so far.

Could you possibly create an apitrace of one of the failing cases?

I did -DDEFAULT_SOFTWARE_DEPTH_BITS=32

I'll see about the apitrace

I'm not actually sure what it'll do with OSMesa. But if you can get
anything and I can make a text dump of the GL calls that'll help.

-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] Create untiled buffers in get_back_bo when needed.

We must send to the compositor buffer it is able to read.

Since tiling modes are different on graphic cards, we have
to disable tiling when creating the buffers if we render
with a different graphic card than the compositor.

Signed-off-by: Axel Davy axel.d...@ens.fr
---
 src/egl/drivers/dri2/platform_wayland.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 709df36..b922ff5 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -283,12 +283,17 @@ get_back_bo(struct dri2_egl_surface *dri2_surf, 
__DRIbuffer *buffer)
if (dri2_surf-back == NULL)
   return -1;
if (dri2_surf-back-dri_image == NULL) {
-  dri2_surf-back-dri_image = 
- dri2_dpy-image-createImage(dri2_dpy-dri_screen,
-  dri2_surf-base.Width,
-  dri2_surf-base.Height,
-  __DRI_IMAGE_FORMAT_ARGB,
-  __DRI_IMAGE_USE_SHARE,
+  unsigned int use_flags = __DRI_IMAGE_USE_SHARE;
+
+  if (!dri2_dpy-enable_tiling)
+ use_flags |= __DRI_IMAGE_USE_LINEAR;
+
+   dri2_surf-back-dri_image = 
+  dri2_dpy-image-createImage(dri2_dpy-dri_screen,
+   dri2_surf-base.Width,
+   dri2_surf-base.Height,
+   __DRI_IMAGE_FORMAT_ARGB,
+  use_flags,
   NULL);
   dri2_surf-back-age = 0;
}
-- 
1.8.1.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] Fix FTBFS on GNU/Hurd due to missing PIPE_OS_HURD detection.

2013-11-07 Thread Fabio Pedretti

From: Cyril Brulebois k...@debian.org

Thanks to Pino Toscano.

Patch from Debian package.
---
 src/gallium/auxiliary/os/os_thread.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gallium/auxiliary/os/os_thread.h 
b/src/gallium/auxiliary/os/os_thread.h
index e153ab4..4528abb 100644
--- a/src/gallium/auxiliary/os/os_thread.h
+++ b/src/gallium/auxiliary/os/os_thread.h
@@ -41,7 +41,7 @@
 #include util/u_debug.h /* for assert */
 
 
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS) 
|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_CYGWIN)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS) 
|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_CYGWIN) 
|| defined(PIPE_OS_HURD)
 
 #include pthread.h /* POSIX threads headers */
 #include stdio.h /* for perror() */
@@ -316,7 +316,7 @@ typedef int64_t pipe_condvar;
  * pipe_barrier
  */
 
-#if (defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || 
defined(PIPE_OS_SOLARIS))  !defined(PIPE_OS_ANDROID)
+#if (defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || 
defined(PIPE_OS_SOLARIS) || defined(PIPE_OS_HURD))  !defined(PIPE_OS_ANDROID)
 
 typedef pthread_barrier_t pipe_barrier;
 
@@ -444,7 +444,7 @@ pipe_semaphore_wait(pipe_semaphore *sema)
  */
 
 typedef struct {
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS) 
|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_CYGWIN)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS) 
|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_CYGWIN) 
|| defined(PIPE_OS_HURD)
pthread_key_t key;
 #elif defined(PIPE_SUBSYSTEM_WINDOWS_USER)
DWORD key;
@@ -459,7 +459,7 @@ typedef struct {
 static INLINE void
 pipe_tsd_init(pipe_tsd *tsd)
 {
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS) 
|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_CYGWIN)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS) 
|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_CYGWIN) 
|| defined(PIPE_OS_HURD)
if (pthread_key_create(tsd-key, NULL/*free*/) != 0) {
   perror(pthread_key_create(): failed to allocate key for thread specific 
data);
   exit(-1);
@@ -476,7 +476,7 @@ pipe_tsd_get(pipe_tsd *tsd)
if (tsd-initMagic != (int) PIPE_TSD_INIT_MAGIC) {
   pipe_tsd_init(tsd);
}
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS) 
|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_CYGWIN)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS) 
|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_CYGWIN) 
|| defined(PIPE_OS_HURD)
return pthread_getspecific(tsd-key);
 #elif defined(PIPE_SUBSYSTEM_WINDOWS_USER)
assert(0);
@@ -493,7 +493,7 @@ pipe_tsd_set(pipe_tsd *tsd, void *value)
if (tsd-initMagic != (int) PIPE_TSD_INIT_MAGIC) {
   pipe_tsd_init(tsd);
}
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS) 
|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_CYGWIN)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS) 
|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_CYGWIN) 
|| defined(PIPE_OS_HURD)
if (pthread_setspecific(tsd-key, value) != 0) {
   perror(pthread_set_specific() failed);
   exit(-1);
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/3] Implement DRI_PRIME support for Wayland

These patches enable using DRI_PRIME to use a different card
than the compositor card (with render-nodes).

At the time of writing, Mesa Wayland egl backend doesn't
support render-nodes, because it uses the dri2 backend, which
require using GEM names (render-nodes aren't allowed to use GEM
names). But I'm confident this week or next week, the __DRIimage
remplacement will be ready, thanks to Keith Packard, Kristian Hosberg
and Christopher James Halse Rogers.
That's why I'm publishing these patches now, so they have the time
to be reviewed.

Initially, I wanted to use driconf too, as a complement of DRI_PRIME,
but driconf doesn't support string parameters yet, so it'll come later.

To choose a specific device, the user has to specify the id_path_tag of
the device he wants to use. We get the id_path_tag with udev. Systemd
didn't fill this field for render-nodes, so it has to be set as an additional
rule. David Herrmann has sent a patch for that for Systemd, but I don't know if
it is already pushed.

The choice to use id_path_tag comes to the fact that the id_path is stable,
and that it describes non-pci graphic devices too (usb devices, etc). 

An alternative to choose the device to use is to set DRI_PRIME to 1,
which means choose any other card than the one used by the compositor.

If Mesa doesn't find the device asked by the user, it will use the same
card than the Wayland compositor.

The Wayland Prime support implemented with these patches is different
from X Prime support.

A client using an other card than the compositor will allocate buffers
with no-tiling to render to, and share them with the compositor, unlike
on X, where it would render to a tiled buffer, not shared with the other card,
and a copy mechanism will make the main card receive an untiled buffer.

That means that these (Wayland) clients will perform slowly, compared to
if they weren't using Prime.
In fact it is not how the user is supposed to run a game, for example,
on its dedicated card.

Using a shared, untiled-buffer, but avoiding any copy, is better for 
application which wouldn't do much rendering.

An example of such an application is an embedded Wayland compositor.

To use an heavy application, the user is supposed to launch an
embedded Wayland compositor on the dedicated card, and run the game
inside. The compositor will render into the shared, untiled buffer,
and will copy the content of the game buffers.

Note that the game know it is using the same cards than its compositor,
that's why it enables tiling.

I'm planning to write a Weston shell, designed to run embedded fullscreen games,
that would make Weston resize to the game size, and close when it closes.

Pros:
.If you launch a fullscreen Wayland compositor on the dedicated card,
inside a compositor supporting composite bypass, you'll render the whole
desktop on the dedicated card. The integrated card would only display
the buffer generated, without doing any copy.
.More flexibility


Cons: 
.The user has to use a script to launch a game on the dedicated card.

Pros over X dri2 Prime support:
.Vsync works, whatever the cards used by the client 
.You can understand easily how prime support works


As a last note, this Prime support suffers too from the
lack of dma-buf fences (glitches when the client is still writing
on the buffer when the compositor's card reads it).
Using an embedded compositor suppress all the glitches when
it doesn't take (1/refresh_rate) seconds for it to render a frame,
that is when you don't have an input lag.



Axel Davy (3):
  Move the code to open the graphic device. Support for
render-nodes.
  Create untiled buffers in get_back_bo when needed.
  Implement choosing the device to use with DRI_PRIME

 src/egl/drivers/dri2/egl_dri2.h |   1 +
 src/egl/drivers/dri2/platform_wayland.c | 262 +++-
 2 files changed, 226 insertions(+), 37 deletions(-)

-- 
1.8.1.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] Move the code to open the graphic device. Support for render-nodes.

This patch moves the code to open the graphic device in the Wayland backend,
removes the authentication request when we are on a render-node,
and has a few fixes.

Signed-off-by: Axel Davy axel.d...@ens.fr
---
 src/egl/drivers/dri2/egl_dri2.h |  1 +
 src/egl/drivers/dri2/platform_wayland.c | 93 ++---
 2 files changed, 63 insertions(+), 31 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index c7d6484..350a626 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -133,6 +133,7 @@ struct dri2_egl_display
int  authenticated;
int  formats;
uint32_t  capabilities;
+   int  enable_tiling;
 #endif
 
int (*authenticate) (_EGLDisplay *disp, uint32_t id);
diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index c0de16b..709df36 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -622,8 +622,8 @@ dri2_terminate(_EGLDriver *drv, _EGLDisplay *disp)
_eglCleanupDisplay(disp);
 
dri2_dpy-core-destroyScreen(dri2_dpy-dri_screen);
-   close(dri2_dpy-fd);
dlclose(dri2_dpy-driver);
+   close(dri2_dpy-fd);
free(dri2_dpy-driver_name);
free(dri2_dpy-device_name);
wl_drm_destroy(dri2_dpy-wl_drm);
@@ -635,34 +635,28 @@ dri2_terminate(_EGLDriver *drv, _EGLDisplay *disp)
return EGL_TRUE;
 }
 
+static char
+is_fd_render_node(int fd)
+{
+  struct stat render;
+
+  if (fstat(fd, render))
+return 0;
+
+  if (!S_ISCHR(render.st_mode))
+return 0;
+
+  if (render.st_rdev  0x80)
+return 1;
+  return 0;
+}
+
 static void
 drm_handle_device(void *data, struct wl_drm *drm, const char *device)
 {
struct dri2_egl_display *dri2_dpy = data;
-   drm_magic_t magic;
 
dri2_dpy-device_name = strdup(device);
-   if (!dri2_dpy-device_name)
-  return;
-
-#ifdef O_CLOEXEC
-   dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR | O_CLOEXEC);
-   if (dri2_dpy-fd == -1  errno == EINVAL)
-#endif
-   {
-  dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR);
-  if (dri2_dpy-fd != -1)
- fcntl(dri2_dpy-fd, F_SETFD, fcntl(dri2_dpy-fd, F_GETFD) |
-FD_CLOEXEC);
-   }
-   if (dri2_dpy-fd == -1) {
-  _eglLog(_EGL_WARNING, wayland-egl: could not open %s (%s),
- dri2_dpy-device_name, strerror(errno));
-  return;
-   }
-
-   drmGetMagic(dri2_dpy-fd, magic);
-   wl_drm_authenticate(dri2_dpy-wl_drm, magic);
 }
 
 static void
@@ -738,7 +732,8 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay *disp)
struct dri2_egl_display *dri2_dpy;
const __DRIconfig *config;
uint32_t types;
-   int i;
+   int i, is_render_node;
+   drm_magic_t magic;
static const unsigned int argb_masks[4] =
   { 0xff, 0xff00, 0xff, 0xff00 };
static const unsigned int rgb_masks[4] = { 0xff, 0xff00, 0xff, 0 };
@@ -778,9 +773,39 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay *disp)
if (roundtrip(dri2_dpy)  0 || dri2_dpy-wl_drm == NULL)
   goto cleanup_dpy;
 
-   if (roundtrip(dri2_dpy)  0 || dri2_dpy-fd == -1)
+   if (roundtrip(dri2_dpy)  0 || dri2_dpy-device_name == NULL)
   goto cleanup_drm;
 
+#ifdef O_CLOEXEC
+   dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR | O_CLOEXEC);
+   if (dri2_dpy-fd == -1  errno == EINVAL)
+#endif
+   {
+  dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR);
+  if (dri2_dpy-fd != -1)
+ fcntl(dri2_dpy-fd, F_SETFD, fcntl(dri2_dpy-fd, F_GETFD) |
+FD_CLOEXEC);
+   }
+   if (dri2_dpy-fd == -1) {
+  _eglLog(_EGL_WARNING, wayland-egl: could not open %s (%s),
+ dri2_dpy-device_name, strerror(errno));
+  goto cleanup_drm;
+   }
+
+   if (is_fd_render_node(dri2_dpy-fd))
+   {
+ _eglLog(_EGL_DEBUG, wayland-egl: card is render-node);
+  dri2_dpy-authenticated = 1;
+  is_render_node = 1;
+   }
+   else
+   {
+  drmGetMagic(dri2_dpy-fd, magic);
+  wl_drm_authenticate(dri2_dpy-wl_drm, magic);
+  is_render_node = 0;
+   }
+   dri2_dpy-enable_tiling = 1;
+
if (roundtrip(dri2_dpy)  0 || !dri2_dpy-authenticated)
   goto cleanup_fd;
 
@@ -799,7 +824,7 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay *disp)
dri2_dpy-dri2_loader_extension.flushFrontBuffer = dri2_flush_front_buffer;
dri2_dpy-dri2_loader_extension.getBuffersWithFormat =
   dri2_get_buffers_with_format;
-  
+
dri2_dpy-extensions[0] = dri2_dpy-dri2_loader_extension.base;
dri2_dpy-extensions[1] = image_lookup_extension.base;
dri2_dpy-extensions[2] = use_invalidate.base;
@@ -808,14 +833,16 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay 
*disp)
if (!dri2_create_screen(disp))
   goto cleanup_driver;
 
-   /* The server shouldn't advertise WL_DRM_CAPABILITY_PRIME if the driver
-* doesn't have createImageFromFds, since we're using the same driver on
-* both

[Mesa-dev] [PATCH 3/3] Implement choosing the device to use with DRI_PRIME

two formats are supported: DRI_PRIME=1 will tell Mesa
to choose an other card than the compositor card if possible,
while setting DRI_PRIME to the id_path_tag of a device (like
pci-_02_00_0) tells Mesa to take the device with this
id_path_tag.

If it isn't able to find the desired card ( no render-nodes,
render-nodes not advertising ID_PATH_TAG, invalid ID_PATH_TAG),
then the compositor card is used.

Signed-off-by: Axel Davy axel.d...@ens.fr
---
 src/egl/drivers/dri2/platform_wayland.c | 168 ++--
 1 file changed, 160 insertions(+), 8 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index b922ff5..3900771 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -40,6 +40,10 @@
 #include wayland-client.h
 #include wayland-drm-client-protocol.h
 
+#ifdef HAVE_LIBUDEV
+#include libudev.h
+#endif
+
 enum wl_drm_format_flags {
HAS_ARGB = 1,
HAS_XRGB = 2,
@@ -656,6 +660,74 @@ is_fd_render_node(int fd)
   return 0;
 }
 
+#ifdef HAVE_LIBUDEV
+
+static char *
+get_render_node_from_id_path_tag(struct udev *udev, char* id_path_tag,
+char another_tag)
+{
+  struct udev_device *device;
+  struct udev_enumerate *e;
+  struct udev_list_entry *entry;
+  const char *path, *id_path_tag_tmp;
+  char found = 0;
+
+  e = udev_enumerate_new(udev);
+  udev_enumerate_add_match_subsystem(e, drm);
+  udev_enumerate_add_match_sysname(e, render*);
+
+  udev_enumerate_scan_devices(e);
+  udev_list_entry_foreach(entry, udev_enumerate_get_list_entry(e)) {
+path = udev_list_entry_get_name(entry);
+device = udev_device_new_from_syspath(udev, path);
+if (!device)
+  continue;
+id_path_tag_tmp = udev_device_get_property_value(device, ID_PATH_TAG);
+if (id_path_tag_tmp)
+{
+  if((!another_tag  !strcmp(id_path_tag, id_path_tag_tmp))
+|| (another_tag  strcmp(id_path_tag, id_path_tag_tmp)))
+  {
+  found = 1;
+  break;
+  }
+}
+udev_device_unref(device);
+  }
+
+  if(found)
+  {
+char* path = strdup(udev_device_get_devnode(device));
+udev_device_unref(device);
+return path;
+  }
+  return NULL;
+}
+
+static char *
+get_id_path_tag_from_fd(struct udev *udev, int fd)
+{
+   struct udev_device *device;
+   struct stat buf;
+   const char *id_path_tag_tmp;
+
+   if (fstat(fd, buf)  0) {
+  return NULL;
+   }
+
+   device = udev_device_new_from_devnum(udev, 'c', buf.st_rdev);
+
+   if(!device)
+ return NULL;
+   id_path_tag_tmp = udev_device_get_property_value(device, ID_PATH_TAG);
+   if(!id_path_tag_tmp)
+ return NULL;
+
+   return strdup(id_path_tag_tmp);
+}
+
+#endif
+
 static void
 drm_handle_device(void *data, struct wl_drm *drm, const char *device)
 {
@@ -737,13 +809,20 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay 
*disp)
struct dri2_egl_display *dri2_dpy;
const __DRIconfig *config;
uint32_t types;
-   int i, is_render_node;
+   int i, is_render_node, device_fd, is_different_device;
drm_magic_t magic;
static const unsigned int argb_masks[4] =
   { 0xff, 0xff00, 0xff, 0xff00 };
static const unsigned int rgb_masks[4] = { 0xff, 0xff00, 0xff, 0 };
static const unsigned int rgb565_masks[4] = { 0xf800, 0x07e0, 0x001f, 0 };
 
+   char* prime_device_name = NULL;
+   char* prime = NULL;
+   const char *dri_prime = getenv(DRI_PRIME);
+
+   if (dri_prime)
+ prime = strdup(dri_prime);
+
drv-API.CreateWindowSurface = dri2_create_window_surface;
drv-API.DestroySurface = dri2_destroy_surface;
drv-API.SwapBuffers = dri2_swap_buffers;
@@ -782,21 +861,94 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay 
*disp)
   goto cleanup_drm;
 
 #ifdef O_CLOEXEC
-   dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR | O_CLOEXEC);
-   if (dri2_dpy-fd == -1  errno == EINVAL)
+   device_fd = open(dri2_dpy-device_name, O_RDWR | O_CLOEXEC);
+   if (device_fd == -1  errno == EINVAL)
 #endif
{
-  dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR);
-  if (dri2_dpy-fd != -1)
- fcntl(dri2_dpy-fd, F_SETFD, fcntl(dri2_dpy-fd, F_GETFD) |
+  device_fd = open(dri2_dpy-device_name, O_RDWR);
+  if (device_fd != -1)
+ fcntl(device_fd, F_SETFD, fcntl(device_fd, F_GETFD) |
 FD_CLOEXEC);
}
-   if (dri2_dpy-fd == -1) {
+   if (device_fd == -1) {
   _eglLog(_EGL_WARNING, wayland-egl: could not open %s (%s),
  dri2_dpy-device_name, strerror(errno));
+  free(prime);
   goto cleanup_drm;
}
 
+   if(prime)
+   {
+#ifdef HAVE_LIBUDEV  
+  struct udev* udev = udev_new();
+  char* device_id_path_tag;
+  char another_tag = 0;
+
+  if (!udev)
+ goto prime_clean;
+  device_id_path_tag = get_id_path_tag_from_fd(udev, device_fd);
+  if (!device_id_path_tag)
+ goto udev_clean;
+
+  is_different_device = 1;
+  /* two format are

Re: [Mesa-dev] DEFAULT_SOFTWARE_DEPTH_BITS=31

2013-11-07 Thread burlen

On 11/07/2013 08:14 AM, Brian Paul wrote:

On 11/07/2013 09:09 AM, burlen wrote:

On 11/07/2013 06:42 AM, Brian Paul wrote:

On 11/06/2013 04:59 PM, burlen wrote:

On 11/06/2013 12:58 PM, Brian Paul wrote:

On 11/06/2013 12:34 PM, burlen wrote:
When I build osmesa with --with-osmesa-bits=32 I notice that I
get 31

bits by way of the compile line define
-DDEFAULT_SOFTWARE_DEPTH_BITS=31.
What's the story with the number 31? Is 31 bits really better
than 32?

IIRC, 32 bit Z never worked properly because of float-int conversion
problems and such. I think I found that 31 bits worked though. It's
been a long time...

representative image diff from our regression suite that shows an
example of the bug
https://urldefense.proofpoint.com/v1/url?u=http://open.cdash.org/testDetails.php?test%3D216532438%26build%3D3087854k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=%2BYxiKNKy6tM2b9uufQKWyLEbSfkSZWpC8Kv9gQu9jJs%3D%0As=0f54945a95ef4530f46e70322823ee22159a9400fe3fae6b9c4a324a93ee3c00

, there are 80 other failed tests, the ones I examined were all the
same.

Experimenting with --with-osmesa-bits options, I've found that
using 32
causes the issue, while using 8 , 16 or not using it all doesn't.
Do you

have any idea about this?

I set DEFAULT_SOFTWARE_DEPTH_BITS=32 and tried a few demo programs and
they look OK so far.

Could you possibly create an apitrace of one of the failing cases?

I did -DDEFAULT_SOFTWARE_DEPTH_BITS=32

I'll see about the apitrace

I'm not actually sure what it'll do with OSMesa. But if you can get
anything and I can make a text dump of the GL calls that'll help.

apitrace crashes hard with OSMesa. Works fine when I use my ATI drivers
though. Not sure what the deal is, but looks like that may be a dead end.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure.ac: Drop no-out-of-tree notice.

Matt Turner matts...@gmail.com writes:

 We do support out of tree builds now.

This series is:

Reviewed-by: Eric Anholt e...@anholt.net


pgpi1Kk4N3O2m.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [v2 6/6] mesa: OES_get_program_binary functionality

2013-11-07 Thread Tapani


Hi;

On 11/06/2013 07:35 PM, Erik Faye-Lund wrote:

Sorry for the late reply.

On Fri, Nov 1, 2013 at 4:14 PM, Tapani tapani.pa...@intel.com wrote:

On 11/01/2013 03:31 PM, Erik Faye-Lund wrote:



That won't help for programs that maintain their own (explicit)
shader-cache, which was the intention of introducing binary shaders to
OpenGL ES in the first place.


Ok, we are talking about the extension, I thought you referred to the
automatic caching. For extension to work, we need at least more Piglit tests
to ensure that it does not break.

I was actually of talking about both. But for the caching, it's
probably more forgivable, as developers probably know they changed the
compiler and can step around it by flushing the cache. Especially if
the build time gets included, like Pauls suggested.


Yep, I'll add Paul's improvements to make this more robust/sane.


Of course every time you go and touch the
code, some functionality may break, be it this extension or something else.

That's completely irrelevant here. The rejection mechanism isn't
intended to catch bugs, but to detect intentional format changes. So
let's not confuse the issue.


Fair enough, what I meant is that implementation relies on some of the 
things to work as they work currently and this might change over time. I 
do admit that at it's current state it can break easily so it needs to 
be changed to be more robust.



I'm not sure if Chromium, Qt or other users expect glBinaryProgram call to
always succeed, hopefully not.

If they do, they're buggy. But there is a chance for that, yes. But
I'm actually talking about that they might get *told* that everything
went well, and still get a broken shader. Or even a crash. Of course,
this only applies when mesa is build with local modifications, but
that happens a *lot* while debugging application issues. Perhaps bugs
start to disappear, because applications take another non-buggy
code-path? It'll probably only affect developers, and not happen in
the wild. But I still don't think that's a good excuse.


OK, if not perfect this should at least improve by adding the 
modification time and invalidating cache based on that.



However, by a strict reading of the spec, I don't even yhink we're
allowed to break the shaders for just any reason. The wording of the
spec is An implementation may reject a program binary if it
determines the program binary was produced by an incompatible or
outdated version of the compiler. The way I read that, changes that
doesn't modify the compiler aren't really allowed to reject previous
shaders. While diverging from the spec on this *might* not have many
real-world implications, at the very best your solution goes against
the intention of this rejection-mechanism.


IMO this is a bit academical nit-picking on the subject, you can't 
really draw very strict lines here (as with some other Khronos specs). 
As example many structures are shared within compiler code and other 
code. Changing these structures means you are changing the compiler code 
so your produced shader will be incompatible. I think having a strict 
approach here is more safer and still provides the functionality for 
most of the users, it is up to the driver to decide when a binary is 
unacceptable for whatever reason, it cannot be specified in a spec in a 
sufficient 'works for everyone' way.




I would assume they simply piggie-backed on their binary-shader
support. But I somehow doubt they have such a lazy approach to
binary shaders as this series attempts. I worked on
ARM_mali_shader_binary for the Mali-200 drivers myself, and our
approach was quite different from this, and surely much more robust.


With such strong opinion It would be nice to have some more technical
explanation. Why it was surely more robust?

Easy; it didn't break compatibility for every change to the driver. It
didn't even break when we updated the compiler. As a matter of fact,
I'm not even aware of *any* compatibility breakages (apart from if you
change the hardware, of course), ever.


I don't see my implementation breaking on 'every change to the driver'. 
It's just the check that is quite conservative with this. I will try to 
improve the structures I'm dumping to make the implementation more robust.



The implementation itself can
be likely very different as it targets only a particular GPU while the
approach here is meant to be more generic.

Our implementation did also support multiple GPUs, however I was only
involved in the initial Mali-200 work. But the Mali-200 does not have
a unified ISA, so we had to touch on this area anyway.


To be honest, I find the whole idea of serializing the IR quite
repelling, as it goes against almost every intention of the extension.
Add to that mesa's IR not at all being stable, well yeah, that's a
super-highway to disaster.


Again, I would appreciate a bit more technical approach if possible. I can't
tell from this paragraph if you have a better idea for the architecture or

Re: [Mesa-dev] Contributing to Mesa Demos?

Courtney Goeltzenleuchter court...@lunarg.com writes:

 What's the process of contributing a test to the Mesa demos repository?

Tests should be made automated and put in piglit, instead of in the Mesa
demos repository.


pgpt0EWtwH3M0.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 V2 14/15] vbo: map indirect buffer and extract params if doing sw primitive restart

Chris Forbes chr...@ijw.co.nz writes:

 V2: Check for mapping failure (thanks Brian)

 Signed-off-by: Chris Forbes chr...@ijw.co.nz
 ---
  src/mesa/vbo/vbo_primitive_restart.c | 33 +
  1 file changed, 33 insertions(+)

 diff --git a/src/mesa/vbo/vbo_primitive_restart.c 
 b/src/mesa/vbo/vbo_primitive_restart.c
 index 48d04e1..ee84f10 100644
 --- a/src/mesa/vbo/vbo_primitive_restart.c
 +++ b/src/mesa/vbo/vbo_primitive_restart.c
 @@ -180,6 +180,39 @@ vbo_sw_primitive_restart(struct gl_context *ctx,
 GLboolean map_ib = ib-obj-Name  !ib-obj-Pointer;
 void *ptr;
  
 +   /* If there is an indirect buffer, map it and extract the draw params */
 +   if (indirect  prims[0].is_indirect) {
 +  struct _mesa_prim new_prim = *prims;
 +  struct _mesa_index_buffer new_ib = *ib;
 +  const uint32_t *indirect_params;
 +  if (!ctx-Driver.MapBufferRange(ctx, 0, indirect-Size, 
 GL_MAP_READ_BIT,
 +(struct gl_buffer_object *)indirect)) {

Are you just casting away the const here?  indirect should definitely
not be const, because you're modifying it in calls like this.


pgp6eATrP4Ip3.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Contributing to Mesa Demos?

On Thu, Nov 7, 2013 at 9:01 AM, Courtney Goeltzenleuchter
court...@lunarg.com wrote:
 What's the process of contributing a test to the Mesa demos repository?

Send patches to this list with a [PATCH demos] prefix.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/7] ARB_vertex_type_10f_11f_11f_rev for i965

Chris Forbes chr...@ijw.co.nz writes:

 Ever since this had appeared as part of GL4.4 I'd been curious
 about whether this extension was going to Just Work, or be a
 workaround-party like ARB_vertex_type_2_10_10_10_rev.

 Today my curiousity got the better of me, and it turns out it
 just works.

 Tested and enabled on Gen6+ -- theoretically could work on earlier
 gens as well, but the spec requires 3.0 so little point.

I don't see any piglit tests for this one.


pgpWnb9cxuGkA.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Contributing to Mesa Demos?

On 7 November 2013 09:20, Eric Anholt e...@anholt.net wrote:

 Courtney Goeltzenleuchter court...@lunarg.com writes:

  What's the process of contributing a test to the Mesa demos repository?

 Tests should be made automated and put in piglit, instead of in the Mesa
 demos repository.


Also Piglit has its own mailing list for code review:
http://lists.freedesktop.org/mailman/listinfo/piglit

And for anyone who is not aware, the master code repository for piglit is
here: git://anongit.freedesktop.org/piglit
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2 04/15] mesa: Add binding point for indirect buffer

Brian Paul bri...@vmware.com writes:

 On 11/07/2013 12:06 AM, Chris Forbes wrote:
 Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.

 Signed-off-by: Chris Forbes chr...@ijw.co.nz
 ---
   src/mesa/main/bufferobj.c| 14 ++
   src/mesa/main/get.c  |  4 
   src/mesa/main/get_hash_params.py |  2 ++
   src/mesa/main/mtypes.h   |  2 ++
   4 files changed, 22 insertions(+)

 diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
 index 1f55061..a75802e 100644
 --- a/src/mesa/main/bufferobj.c
 +++ b/src/mesa/main/bufferobj.c
 @@ -86,6 +86,12 @@ get_buffer_target(struct gl_context *ctx, GLenum target)
 return ctx-CopyReadBuffer;
  case GL_COPY_WRITE_BUFFER:
 return ctx-CopyWriteBuffer;
 +   case GL_DRAW_INDIRECT_BUFFER:
 +  if (ctx-API == API_OPENGL_CORE 
 +  ctx-Extensions.ARB_draw_indirect) {
 + return ctx-DrawIndirectBuffer;
 +  }
 +  break;
  case GL_TRANSFORM_FEEDBACK_BUFFER:
 if (ctx-Extensions.EXT_transform_feedback) {
return ctx-TransformFeedback.CurrentBuffer;
 @@ -626,6 +632,9 @@ _mesa_init_buffer_objects( struct gl_context *ctx )
  _mesa_reference_buffer_object(ctx, ctx-UniformBuffer,
   ctx-Shared-NullBufferObj);

 +   _mesa_reference_buffer_object(ctx, ctx-DrawIndirectBuffer,
 + ctx-Shared-NullBufferObj);
 +
  for (i = 0; i  MAX_COMBINED_UNIFORM_BUFFERS; i++) {
 _mesa_reference_buffer_object(ctx,
  ctx-UniformBufferBindings[i].BufferObject,
 @@ -873,6 +882,11 @@ _mesa_DeleteBuffers(GLsizei n, const GLuint *ids)
   _mesa_BindBuffer( GL_ELEMENT_ARRAY_BUFFER_ARB, 0 );
}

 + /* unbind ARB_draw_indirect binding point */
 + if (ctx-DrawIndirectBuffer == bufObj) {
 +_mesa_BindBuffer( GL_DRAW_INDIRECT_BUFFER, 0 );
 + }
 +
/* unbind ARB_copy_buffer binding points */
if (ctx-CopyReadBuffer == bufObj) {
   _mesa_BindBuffer( GL_COPY_READ_BUFFER, 0 );
 diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
 index ad53b25..a471383 100644
 --- a/src/mesa/main/get.c
 +++ b/src/mesa/main/get.c
 @@ -914,6 +914,10 @@ find_custom_value(struct gl_context *ctx, const struct 
 value_desc *d, union valu
  case GL_ATOMIC_COUNTER_BUFFER_BINDING:
 v-value_int = ctx-AtomicBuffer-Name;
 break;
 +   /* GL_ARB_draw_indirect */
 +   case GL_DRAW_INDIRECT_BUFFER_BINDING:
 +  v-value_int = ctx-DrawIndirectBuffer-Name;
 +  break;
  }
   }

 diff --git a/src/mesa/main/get_hash_params.py 
 b/src/mesa/main/get_hash_params.py
 index 0851b7b..226ede0 100644
 --- a/src/mesa/main/get_hash_params.py
 +++ b/src/mesa/main/get_hash_params.py
 @@ -743,6 +743,8 @@ descriptor=[
   { apis: [GL_CORE], params: [
   # GL_ARB_texture_buffer_range
 [ TEXTURE_BUFFER_OFFSET_ALIGNMENT, 
 CONTEXT_INT(Const.TextureBufferOffsetAlignment), 
 extra_ARB_texture_buffer_range ],
 +# GL_ARB_draw_indirect
 +  [ DRAW_INDIRECT_BUFFER_BINDING, LOC_CUSTOM, TYPE_INT, 0, 
 extra_ARB_draw_indirect ],

 Does this really need a LOC_CUSTOM?  Could we just do:

 [ DRAW_INDIRECT_BUFFER_BINDING, 
 CONTEXT_INT(DrawIndirectBuffer-name), extra_ARB_draw_indirect ],

 and remove the switch case above?

get.c is all about things at offsets from the start of the context (or a
couple of other structs), and things that aren't described that way need
custom code.


pgpl1oEpawyZy.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 V2 14/15] vbo: map indirect buffer and extract params if doing sw primitive restart


On 11/07/2013 10:23 AM, Eric Anholt wrote:

Chris Forbes chr...@ijw.co.nz writes:


V2: Check for mapping failure (thanks Brian)

Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
  src/mesa/vbo/vbo_primitive_restart.c | 33 +
  1 file changed, 33 insertions(+)

diff --git a/src/mesa/vbo/vbo_primitive_restart.c 
b/src/mesa/vbo/vbo_primitive_restart.c
index 48d04e1..ee84f10 100644
--- a/src/mesa/vbo/vbo_primitive_restart.c
+++ b/src/mesa/vbo/vbo_primitive_restart.c
@@ -180,6 +180,39 @@ vbo_sw_primitive_restart(struct gl_context *ctx,
 GLboolean map_ib = ib-obj-Name  !ib-obj-Pointer;
 void *ptr;

+   /* If there is an indirect buffer, map it and extract the draw params */
+   if (indirect  prims[0].is_indirect) {
+  struct _mesa_prim new_prim = *prims;
+  struct _mesa_index_buffer new_ib = *ib;
+  const uint32_t *indirect_params;
+  if (!ctx-Driver.MapBufferRange(ctx, 0, indirect-Size, GL_MAP_READ_BIT,
+(struct gl_buffer_object *)indirect)) {


Are you just casting away the const here?  indirect should definitely
not be const, because you're modifying it in calls like this.


Yeah, he's casting away const, but the buffer's being mapped for 
read-only.  An indirect drawing call should never modify the indirect 
buffer's contents.


To avoid the cast we'd need a const-qualified 
ctx-Driver.MapBufferRange() function, but the implementation of that 
would then probably often have to cast-away const too.


I think the above is OK.

-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Contributing to Mesa Demos?

Hi Eric,

Include performance tests?
In my quick look I didn't see anything that looked appropriate to
performance regression testing. The Perf folder under Mesa demos seemed the
closest that I could find.

Thanks,
Courtney


On Thu, Nov 7, 2013 at 10:20 AM, Eric Anholt e...@anholt.net wrote:

 Courtney Goeltzenleuchter court...@lunarg.com writes:

  What's the process of contributing a test to the Mesa demos repository?

 Tests should be made automated and put in piglit, instead of in the Mesa
 demos repository.




-- 
Courtney Goeltzenleuchter
LunarG
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2 05/15] mesa: Add validation helpers for new indirect draws

Chris Forbes chr...@ijw.co.nz writes:

 Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.

 Signed-off-by: Chris Forbes chr...@ijw.co.nz
 ---
  src/mesa/main/api_validate.c | 163 
 +++
  src/mesa/main/api_validate.h |  26 +++
  2 files changed, 189 insertions(+)

 diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
 index f285c97..befd69f 100644
 --- a/src/mesa/main/api_validate.c
 +++ b/src/mesa/main/api_validate.c
 @@ -837,3 +837,166 @@ _mesa_validate_DrawTransformFeedback(struct gl_context 
 *ctx,
  
 return GL_TRUE;
  }
 +
 +static GLboolean
 +valid_draw_indirect(struct gl_context *ctx,
 +GLenum mode, const GLvoid *indirect,
 +GLsizei size, const char *name)
 +{
 +   const GLsizeiptr end = (GLsizeiptr)indirect + size;
 +
 +   if (!_mesa_valid_prim_mode(ctx, mode, name))
 +  return GL_FALSE;
 +
 +   if ((GLsizeiptr)indirect  (sizeof(GLuint) - 1)) {
 +  _mesa_error(ctx, GL_INVALID_OPERATION,
 +  %s(indirect is not aligned), name);
 +  return GL_FALSE;
 +   }
 +
 +   if (_mesa_is_bufferobj(ctx-DrawIndirectBuffer)) {
 +  if (_mesa_bufferobj_mapped(ctx-DrawIndirectBuffer)) {
 + _mesa_error(ctx, GL_INVALID_OPERATION,
 + %s(DRAW_INDIRECT_BUFFER is mapped), name);
 + return GL_FALSE;
 +  }

Other BO usage in the draw path doesn't check that buffers aren't
mapped.  What makes this path special?

 +  if (ctx-DrawIndirectBuffer-Size  end) {
 + _mesa_error(ctx, GL_INVALID_OPERATION,
 + %s(DRAW_INDIRECT_BUFFER too small), name);
 + return GL_FALSE;
 +  }


pgpTXinCnuteS.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 V2 05/15] mesa: Add validation helpers for new indirect draws

On 6 November 2013 23:06, Chris Forbes chr...@ijw.co.nz wrote:

 Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.

 Signed-off-by: Chris Forbes chr...@ijw.co.nz
 ---
  src/mesa/main/api_validate.c | 163
 +++
  src/mesa/main/api_validate.h |  26 +++
  2 files changed, 189 insertions(+)

 diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
 index f285c97..befd69f 100644
 --- a/src/mesa/main/api_validate.c
 +++ b/src/mesa/main/api_validate.c
 @@ -837,3 +837,166 @@ _mesa_validate_DrawTransformFeedback(struct
 gl_context *ctx,

 return GL_TRUE;
  }
 +
 +static GLboolean
 +valid_draw_indirect(struct gl_context *ctx,
 +GLenum mode, const GLvoid *indirect,
 +GLsizei size, const char *name)
 +{
 +   const GLsizeiptr end = (GLsizeiptr)indirect + size;
 +
 +   if (!_mesa_valid_prim_mode(ctx, mode, name))
 +  return GL_FALSE;
 +
 +   if ((GLsizeiptr)indirect  (sizeof(GLuint) - 1)) {
 +  _mesa_error(ctx, GL_INVALID_OPERATION,
 +  %s(indirect is not aligned), name);
 +  return GL_FALSE;
 +   }
 +
 +   if (_mesa_is_bufferobj(ctx-DrawIndirectBuffer)) {
 +  if (_mesa_bufferobj_mapped(ctx-DrawIndirectBuffer)) {
 + _mesa_error(ctx, GL_INVALID_OPERATION,
 + %s(DRAW_INDIRECT_BUFFER is mapped), name);
 + return GL_FALSE;
 +  }
 +  if (ctx-DrawIndirectBuffer-Size  end) {
 + _mesa_error(ctx, GL_INVALID_OPERATION,
 + %s(DRAW_INDIRECT_BUFFER too small), name);
 + return GL_FALSE;
 +  }
 +   } else {
 +  if (ctx-API != API_OPENGL_COMPAT) {
 + _mesa_error(ctx, GL_INVALID_OPERATION,
 + %s: no buffer bound to DRAW_INDIRECT_BUFFER, name);
 + return GL_FALSE;
 +  }
 +   }
 +
 +   if (!check_valid_to_render(ctx, name))
 +  return GL_FALSE;
 +
 +   return GL_TRUE;
 +}
 +
 +static inline GLboolean
 +valid_draw_indirect_elements(struct gl_context *ctx,
 + GLenum mode, GLenum type, const GLvoid
 *indirect,
 + GLsizeiptr size, const char *name)
 +{
 +   if (!valid_elements_type(ctx, type, name))
 +  return GL_FALSE;
 +
 +   /*
 +* Unlike regular DrawElementsInstancedBaseVertex commands, the indices
 +* may not come from a client array and must come from an index buffer.
 +* If no element array buffer is bound, an INVALID_OPERATION error is
 +* generated.
 +*/
 +   if (!_mesa_is_bufferobj(ctx-Array.ArrayObj-ElementArrayBufferObj)) {
 +  _mesa_error(ctx, GL_INVALID_OPERATION,
 +  %s(no buffer bound to GL_ELEMENT_ARRAY_BUFFER), name);
 +  return GL_FALSE;
 +   }
 +
 +   return valid_draw_indirect(ctx, mode, indirect, size, name);
 +}
 +
 +static inline GLboolean
 +valid_draw_indirect_multi(struct gl_context *ctx,
 +  GLsizei primcount, GLsizei stride,
 +  const char *name)
 +{
 +   if (primcount  0) {
 +  _mesa_error(ctx, GL_INVALID_VALUE, %s(primcount  0), name);
 +  return GL_FALSE;
 +   }


ARB_multi_draw_indirect is inconsistent about whether a primcount of 0 is
allowed.  In one place it says:

primcount must be positive, otherwise an INVALID_VALUE error will be
generated.

Which would seem to imply that 0 is not allowed.  But then later it says:

INVALID_VALUE is generated by MultiDrawArraysIndirect or
MultiDrawElementsIndirect if primcount is negative.

Which would seem to imply that 0 is allowed.

OpenGL 4.3 and 4.4 consistently say:

An INVALID_VALUE error is generated if drawcount is not positive.

Usually when there's a difference like this between the extension specs and
the OpenGL spec, the OpenGL spec is the correct one.  So unless we have
experimental evidence from shipping drivers that a primcount of 0 is
allowed, I think we should make it an error.



 +
 +   if (stride % 4) {
 +  _mesa_error(ctx, GL_INVALID_VALUE, %s(stride %% 4), name);
 +  return GL_FALSE;
 +   }
 +
 +   return GL_TRUE;
 +}
 +
 +GLboolean
 +_mesa_validate_DrawArraysIndirect(struct gl_context *ctx,
 +  GLenum mode,
 +  const GLvoid *indirect)
 +{
 +   const unsigned drawArraysNumParams = 4;
 +
 +   FLUSH_CURRENT(ctx, 0);
 +
 +   return valid_draw_indirect(ctx, mode,
 +  indirect, drawArraysNumParams *
 sizeof(GLuint),
 +  glDrawArraysIndirect);
 +}
 +
 +GLboolean
 +_mesa_validate_DrawElementsIndirect(struct gl_context *ctx,
 +GLenum mode, GLenum type,
 +const GLvoid *indirect)
 +{
 +   const unsigned drawElementsNumParams = 5;
 +
 +   FLUSH_CURRENT(ctx, 0);
 +
 +   return valid_draw_indirect_elements(ctx, mode, type,
 +   indirect, drawElementsNumParams *

Re: [Mesa-dev] [PATCH V2 09/15] i965: add state atom for indirect buffer

Chris Forbes chr...@ijw.co.nz writes:

 Signed-off-by: Chris Forbes chr...@ijw.co.nz
 ---
  src/mesa/drivers/dri/i965/brw_context.h  | 10 +
  src/mesa/drivers/dri/i965/brw_draw_upload.c  | 32 
 
  src/mesa/drivers/dri/i965/brw_state.h|  1 +
  src/mesa/drivers/dri/i965/brw_state_upload.c |  2 ++
  4 files changed, 45 insertions(+)

 diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
 b/src/mesa/drivers/dri/i965/brw_context.h
 index ffbfcaa..a0228cf 100644
 --- a/src/mesa/drivers/dri/i965/brw_context.h
 +++ b/src/mesa/drivers/dri/i965/brw_context.h
 @@ -185,6 +185,7 @@ enum brw_state_id {
 BRW_STATE_META_IN_PROGRESS,
 BRW_STATE_INTERPOLATION_MAP,
 BRW_STATE_PUSH_CONSTANT_ALLOCATION,
 +   BRW_STATE_INDIRECT_BUFFER,
 BRW_NUM_STATE_BITS
  };
  
 @@ -224,6 +225,7 @@ enum brw_state_id {
  #define BRW_NEW_META_IN_PROGRESS(1  BRW_STATE_META_IN_PROGRESS)
  #define BRW_NEW_INTERPOLATION_MAP   (1  BRW_STATE_INTERPOLATION_MAP)
  #define BRW_NEW_PUSH_CONSTANT_ALLOCATION (1  
 BRW_STATE_PUSH_CONSTANT_ALLOCATION)
 +#define BRW_NEW_INDIRECT_BUFFER (1  BRW_STATE_INDIRECT_BUFFER)
  
  struct brw_state_flags {
 /** State update flags signalled by mesa internals */
 @@ -1165,6 +1167,14 @@ struct brw_context
unsigned int start_vertex_offset;
 } ib;
  
 +   struct {
 +  /**
 +   * Draw indirect buffer for this draw_prims call.
 +   */
 +  const struct gl_buffer_object *indb;
 +  drm_intel_bo *bo;
 +   } indirect_buffer;
 +
 /* Active vertex program: 
  */
 const struct gl_vertex_program *vertex_program;
 diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c 
 b/src/mesa/drivers/dri/i965/brw_draw_upload.c
 index 4da1b7e..4e7478a 100644
 --- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
 +++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
 @@ -933,3 +933,35 @@ const struct brw_tracked_state brw_index_buffer = {
 },
 .emit = brw_emit_index_buffer,
  };
 +
 +
 +static void brw_upload_indirect_buffer(struct brw_context *brw)
 +{
 +   struct gl_context *ctx = brw-ctx;
 +   struct gl_buffer_object *bufferobj;
 +   drm_intel_bo *bo;
 +
 +   bufferobj = brw-indirect_buffer.indb;
 +   if (bufferobj == NULL)
 +  return;
 +
 +   bo = intel_bufferobj_buffer(brw, intel_buffer_object(bufferobj),
 +   0, bufferobj-Size);
 +   drm_intel_bo_reference(bo);
 +
 +   if (brw-indirect_buffer.bo != bo) {
 +  drm_intel_bo_unreference(brw-indirect_buffer.bo);
 +  brw-indirect_buffer.bo = bo;
 +   }
 +   else {
 +  drm_intel_bo_unreference(bo);
 +   }
 +};

I don't think the extra refcounting and context fields here are worth
saving just doing a

   bo = intel_bufferobj_buffer(brw, intel_buffer_object(indirect),
   0, bufferobj-Size);

per primitive in the indirect-only path that appears later in the
primitive setup.

 +const struct brw_tracked_state brw_indirect_buffer = {
 +   .dirty = {
 +  .brw = BRW_NEW_BATCH | BRW_NEW_INDIRECT_BUFFER,
 +   },
 +   .emit = brw_upload_indirect_buffer,
 +};

There's nothing batch-dependent here.


pgpnDFOzWO6Dy.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 V2 14/15] vbo: map indirect buffer and extract params if doing sw primitive restart

Brian Paul bri...@vmware.com writes:

 On 11/07/2013 10:23 AM, Eric Anholt wrote:
 Chris Forbes chr...@ijw.co.nz writes:

 V2: Check for mapping failure (thanks Brian)

 Signed-off-by: Chris Forbes chr...@ijw.co.nz
 ---
   src/mesa/vbo/vbo_primitive_restart.c | 33 
 +
   1 file changed, 33 insertions(+)

 diff --git a/src/mesa/vbo/vbo_primitive_restart.c 
 b/src/mesa/vbo/vbo_primitive_restart.c
 index 48d04e1..ee84f10 100644
 --- a/src/mesa/vbo/vbo_primitive_restart.c
 +++ b/src/mesa/vbo/vbo_primitive_restart.c
 @@ -180,6 +180,39 @@ vbo_sw_primitive_restart(struct gl_context *ctx,
  GLboolean map_ib = ib-obj-Name  !ib-obj-Pointer;
  void *ptr;

 +   /* If there is an indirect buffer, map it and extract the draw params */
 +   if (indirect  prims[0].is_indirect) {
 +  struct _mesa_prim new_prim = *prims;
 +  struct _mesa_index_buffer new_ib = *ib;
 +  const uint32_t *indirect_params;
 +  if (!ctx-Driver.MapBufferRange(ctx, 0, indirect-Size, 
 GL_MAP_READ_BIT,
 +(struct gl_buffer_object *)indirect)) {

 Are you just casting away the const here?  indirect should definitely
 not be const, because you're modifying it in calls like this.

 Yeah, he's casting away const, but the buffer's being mapped for 
 read-only.  An indirect drawing call should never modify the indirect 
 buffer's contents.

But it sure does modify the indirect buffer object's struct, since it's
getting used to do the call.  In the i965 case, the struct's what bits
have been referenced by the GPU since our last stall? get modified both
in the normal draw path and in the fallback path.

Even state_tracker modifies the struct:

   obj-Pointer = pipe_buffer_map_range(pipe,
st_obj-buffer,
offset, length,
flags,
st_obj-transfer);



pgpUdJvQBsJpS.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 0/7] ARB_vertex_type_10f_11f_11f_rev for i965

Oops -- had pushed tests to my piglit branch but not sent them to the list.

On Fri, Nov 8, 2013 at 6:25 AM, Eric Anholt e...@anholt.net wrote:
 Chris Forbes chr...@ijw.co.nz writes:

 Ever since this had appeared as part of GL4.4 I'd been curious
 about whether this extension was going to Just Work, or be a
 workaround-party like ARB_vertex_type_2_10_10_10_rev.

 Today my curiousity got the better of me, and it turns out it
 just works.

 Tested and enabled on Gen6+ -- theoretically could work on earlier
 gens as well, but the spec requires 3.0 so little point.

 I don't see any piglit tests for this one.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2 09/15] i965: add state atom for indirect buffer

OK -- that's much simpler, thanks.

On Fri, Nov 8, 2013 at 7:11 AM, Eric Anholt e...@anholt.net wrote:
 Chris Forbes chr...@ijw.co.nz writes:

 Signed-off-by: Chris Forbes chr...@ijw.co.nz
 ---
  src/mesa/drivers/dri/i965/brw_context.h  | 10 +
  src/mesa/drivers/dri/i965/brw_draw_upload.c  | 32 
 
  src/mesa/drivers/dri/i965/brw_state.h|  1 +
  src/mesa/drivers/dri/i965/brw_state_upload.c |  2 ++
  4 files changed, 45 insertions(+)

 diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
 b/src/mesa/drivers/dri/i965/brw_context.h
 index ffbfcaa..a0228cf 100644
 --- a/src/mesa/drivers/dri/i965/brw_context.h
 +++ b/src/mesa/drivers/dri/i965/brw_context.h
 @@ -185,6 +185,7 @@ enum brw_state_id {
 BRW_STATE_META_IN_PROGRESS,
 BRW_STATE_INTERPOLATION_MAP,
 BRW_STATE_PUSH_CONSTANT_ALLOCATION,
 +   BRW_STATE_INDIRECT_BUFFER,
 BRW_NUM_STATE_BITS
  };

 @@ -224,6 +225,7 @@ enum brw_state_id {
  #define BRW_NEW_META_IN_PROGRESS(1  BRW_STATE_META_IN_PROGRESS)
  #define BRW_NEW_INTERPOLATION_MAP   (1  BRW_STATE_INTERPOLATION_MAP)
  #define BRW_NEW_PUSH_CONSTANT_ALLOCATION (1  
 BRW_STATE_PUSH_CONSTANT_ALLOCATION)
 +#define BRW_NEW_INDIRECT_BUFFER (1  BRW_STATE_INDIRECT_BUFFER)

  struct brw_state_flags {
 /** State update flags signalled by mesa internals */
 @@ -1165,6 +1167,14 @@ struct brw_context
unsigned int start_vertex_offset;
 } ib;

 +   struct {
 +  /**
 +   * Draw indirect buffer for this draw_prims call.
 +   */
 +  const struct gl_buffer_object *indb;
 +  drm_intel_bo *bo;
 +   } indirect_buffer;
 +
 /* Active vertex program:
  */
 const struct gl_vertex_program *vertex_program;
 diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c 
 b/src/mesa/drivers/dri/i965/brw_draw_upload.c
 index 4da1b7e..4e7478a 100644
 --- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
 +++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
 @@ -933,3 +933,35 @@ const struct brw_tracked_state brw_index_buffer = {
 },
 .emit = brw_emit_index_buffer,
  };
 +
 +
 +static void brw_upload_indirect_buffer(struct brw_context *brw)
 +{
 +   struct gl_context *ctx = brw-ctx;
 +   struct gl_buffer_object *bufferobj;
 +   drm_intel_bo *bo;
 +
 +   bufferobj = brw-indirect_buffer.indb;
 +   if (bufferobj == NULL)
 +  return;
 +
 +   bo = intel_bufferobj_buffer(brw, intel_buffer_object(bufferobj),
 +   0, bufferobj-Size);
 +   drm_intel_bo_reference(bo);
 +
 +   if (brw-indirect_buffer.bo != bo) {
 +  drm_intel_bo_unreference(brw-indirect_buffer.bo);
 +  brw-indirect_buffer.bo = bo;
 +   }
 +   else {
 +  drm_intel_bo_unreference(bo);
 +   }
 +};

 I don't think the extra refcounting and context fields here are worth
 saving just doing a

bo = intel_bufferobj_buffer(brw, intel_buffer_object(indirect),
0, bufferobj-Size);

 per primitive in the indirect-only path that appears later in the
 primitive setup.

 +const struct brw_tracked_state brw_indirect_buffer = {
 +   .dirty = {
 +  .brw = BRW_NEW_BATCH | BRW_NEW_INDIRECT_BUFFER,
 +   },
 +   .emit = brw_upload_indirect_buffer,
 +};

 There's nothing batch-dependent here.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965: Add an implementation of intel_miptree_map using streaming loads.

2013-11-07 Thread Chad Versace


On 11/07/2013 10:55 AM, Matt Turner wrote:

Improves performance of RoboHornet's 2D Canvas toDataURL benchmark
[http://www.robohornet.org/#e=canvastodataurl] by approximately 5x
on Baytrail on ChromiumOS.
---
v2: Added benchmark results
 Remove unnecessary _mesa_align_free in error case
 Rename stride to width_bytes and make const
 Remove mt-region-cpp from malloc size calculation
 Remove misalignment from malloc size calculation

Chad: I think you're right about not needing misalignment in the malloc
size calculation, but if that's incorrect it could mean that the src/dst
buffers aren't coaligned and we'll get no performance improvement. Can
you double check that this patch still gives the expected improvement?


Elapsed time drops by -81.4861% +/- 1.22619% (n=3 s=14.9105, confidence=95%).

This patch has my r-b.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH demos 1/3] Perf: Add command line capabilities to perf framework

These were entirely interactive. Adding ability to pass in
command line arguments allows future tests to include
automated test capabilities.

Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
 src/perf/copytex.c  | 2 +-
 src/perf/drawoverhead.c | 2 +-
 src/perf/fbobind.c  | 2 +-
 src/perf/fill.c | 2 +-
 src/perf/genmipmap.c| 2 +-
 src/perf/glmain.c   | 2 +-
 src/perf/glmain.h   | 2 +-
 src/perf/glslstateschange.c | 2 +-
 src/perf/readpixels.c   | 2 +-
 src/perf/swapbuffers.c  | 2 +-
 src/perf/teximage.c | 2 +-
 src/perf/vbo.c  | 2 +-
 src/perf/vertexrate.c   | 2 +-
 13 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/src/perf/copytex.c b/src/perf/copytex.c
index f7a6b8a..376d699 100644
--- a/src/perf/copytex.c
+++ b/src/perf/copytex.c
@@ -57,7 +57,7 @@ static const struct vertex vertices[1] = {
 
 /** Called from test harness/main */
 void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
 {
const GLenum filter = GL_LINEAR;
GLenum stat;
diff --git a/src/perf/drawoverhead.c b/src/perf/drawoverhead.c
index f75c9bb..06a815f 100644
--- a/src/perf/drawoverhead.c
+++ b/src/perf/drawoverhead.c
@@ -55,7 +55,7 @@ static const struct vertex vertices[4] = {
 
 /** Called from test harness/main */
 void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
 {
/* setup VBO w/ vertex data */
glGenBuffersARB(1, VBO);
diff --git a/src/perf/fbobind.c b/src/perf/fbobind.c
index fb52a93..4206294 100644
--- a/src/perf/fbobind.c
+++ b/src/perf/fbobind.c
@@ -56,7 +56,7 @@ static const struct vertex vertices[1] = {
 
 /** Called from test harness/main */
 void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
 {
const GLenum filter = GL_LINEAR;
GLenum stat;
diff --git a/src/perf/fill.c b/src/perf/fill.c
index 279f2b5..70cb64b 100644
--- a/src/perf/fill.c
+++ b/src/perf/fill.c
@@ -120,7 +120,7 @@ static GLuint ShaderProg1, ShaderProg2;
 
 /** Called from test harness/main */
 void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
 {
GLint u;
 
diff --git a/src/perf/genmipmap.c b/src/perf/genmipmap.c
index 20e2fa3..a37f7ab 100644
--- a/src/perf/genmipmap.c
+++ b/src/perf/genmipmap.c
@@ -52,7 +52,7 @@ static const struct vertex vertices[1] = {
 
 /** Called from test harness/main */
 void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
 {
if (!PerfExtensionSupported(GL_ARB_framebuffer_object)) {
   printf(Sorry, this test requires GL_ARB_framebuffer_object\n);
diff --git a/src/perf/glmain.c b/src/perf/glmain.c
index 81c1173..3bc18ad 100644
--- a/src/perf/glmain.c
+++ b/src/perf/glmain.c
@@ -258,7 +258,7 @@ main(int argc, char *argv[])
glutSpecialFunc(SpecialKey);
glutDisplayFunc(Draw);
glutIdleFunc(Idle);
-   PerfInit();
+   PerfInit(argc, argv);
glutMainLoop();
return 0;
 }
diff --git a/src/perf/glmain.h b/src/perf/glmain.h
index d9bcd5f..18cde08 100644
--- a/src/perf/glmain.h
+++ b/src/perf/glmain.h
@@ -56,7 +56,7 @@ PerfExtensionSupported(const char *ext);
 /** Test programs must implement these functions **/
 
 extern void
-PerfInit(void);
+PerfInit(int argc, char *argv[]);
 
 extern void
 PerfNextRound(void);
diff --git a/src/perf/glslstateschange.c b/src/perf/glslstateschange.c
index 7422b78..83f8d6b 100644
--- a/src/perf/glslstateschange.c
+++ b/src/perf/glslstateschange.c
@@ -257,7 +257,7 @@ InitPrograms(void)
 }
 
 void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
 {
if (!ShadersSupported())
   exit(1);
diff --git a/src/perf/readpixels.c b/src/perf/readpixels.c
index ac7dc42..1e777a6 100644
--- a/src/perf/readpixels.c
+++ b/src/perf/readpixels.c
@@ -51,7 +51,7 @@ static GLvoid *ReadBuffer;
 
 /** Called from test harness/main */
 void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
 {
/* setup VBO */
glGenBuffersARB(1, VBO);
diff --git a/src/perf/swapbuffers.c b/src/perf/swapbuffers.c
index 63c7fc0..24436f7 100644
--- a/src/perf/swapbuffers.c
+++ b/src/perf/swapbuffers.c
@@ -50,7 +50,7 @@ static const struct vertex vertices[4] = {
 
 /** Called from test harness/main */
 void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
 {
/* setup VBO w/ vertex data */
glGenBuffersARB(1, VBO);
diff --git a/src/perf/teximage.c b/src/perf/teximage.c
index a3005d0..88316f3 100644
--- a/src/perf/teximage.c
+++ b/src/perf/teximage.c
@@ -73,7 +73,7 @@ static const struct vertex vertices[1] = {
 
 /** Called from test harness/main */
 void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
 {
/* setup VBO w/ vertex data */
glGenBuffersARB(1, VBO);
diff --git a/src/perf/vbo.c b/src/perf/vbo.c
index b326c05..6a0d313 100644
--- a/src/perf/vbo.c
+++ b/src/perf/vbo.c
@@ -51,7 +51,7 @@ static const GLfloat Vertex0[2] = { 0.0, 0.0 };
 
 /** Called from test harness/main */
 void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
 {
/* setup VBO */
glGenBuffersARB(1, VBO);
diff --git a/src/perf/vertexrate.c b/src/perf/vertexrate.c

[Mesa-dev] [PATCH demos 0/3] Customizable texture upload benchmark

This patch series adds a new benchmark test designed to
measure texture upload speed with configurable parameters.
Can run interactively, similar to teximage test or can use
command line arguments to specify size of texture, mipmap or not,
source pixel format and internal pixel format.

The first patch adds command line argument passing to the perf
infrastructure.

Then adding a simple version of the test.

And finally adding the full command line configurability.

Courtney Goeltzenleuchter (3):
  Perf: Add command line capabilities to perf framework
  Perf: Add test to measure texture upload
  Perf: teximage_enh Add command line options

 src/perf/CMakeLists.txt|   1 +
 src/perf/Makefile.am   |   1 +
 src/perf/bench_glTexImage2D.sh |  73 +
 src/perf/copytex.c |   2 +-
 src/perf/drawoverhead.c|   2 +-
 src/perf/fbobind.c |   2 +-
 src/perf/fill.c|   2 +-
 src/perf/genmipmap.c   |   2 +-
 src/perf/glmain.c  |   2 +-
 src/perf/glmain.h  |   2 +-
 src/perf/glslstateschange.c|   2 +-
 src/perf/readpixels.c  |   2 +-
 src/perf/swapbuffers.c |   2 +-
 src/perf/teximage.c|   2 +-
 src/perf/teximage_enh.README   |  10 +
 src/perf/teximage_enh.c| 597 +
 src/perf/vbo.c |   2 +-
 src/perf/vertexrate.c  |   2 +-
 18 files changed, 695 insertions(+), 13 deletions(-)
 create mode 100755 src/perf/bench_glTexImage2D.sh
 create mode 100644 src/perf/teximage_enh.README
 create mode 100644 src/perf/teximage_enh.c

-- 
1.8.1.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH demos 3/3] Perf: teximage_enh Add command line options

texture_enh allows the user to specify source, internal formats
and mipmap or not. This provides a quick way to get feedback
on texture upload related performance tuning.
Texture image data is initialized and aligned to 64 byte bounary.
Uses Mesa demos Perf library to do the measurements.

Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
 src/perf/teximage_enh.c | 366 +---
 1 file changed, 287 insertions(+), 79 deletions(-)

diff --git a/src/perf/teximage_enh.c b/src/perf/teximage_enh.c
index 9bb3944..0f5d2f7 100644
--- a/src/perf/teximage_enh.c
+++ b/src/perf/teximage_enh.c
@@ -31,6 +31,19 @@
 #include stdio.h
 #include string.h
 
+/**
+ * Align a value up to an alignment value
+ *
+ * If \c value is not already aligned to the requested alignment value, it
+ * will be rounded up.
+ *
+ * \param value  Value to be rounded
+ * \param alignment  Alignment value to be used.  This must be a power of two.
+ *
+ * \sa ROUND_DOWN_TO()
+ */
+#define ALIGN_PTR(value, alignment)  (((uintptr_t)(value) + (alignment) - 1)  
~ (uintptr_t)((alignment) - 1))
+
 int WinWidth = 100, WinHeight = 100;
 
 /* for texture creation */
@@ -39,16 +52,20 @@ static GLuint TexObj = 0;
 static GLubyte *TexImage = NULL;
 
 enum {
-   MODE_CREATE_TEXIMAGE,
-   MODE_TEXIMAGE,
-   MODE_COUNT
+   TEST_CREATE_TEXIMAGE,
+   TEST_TEXIMAGE,
+   TEST_TEXIMAGE_MIPMAP,
+   TEST_COUNT
 };
 
-static const char *mode_name[MODE_COUNT] ={
+static const char *test_name[TEST_COUNT] = {
Create_TexImage,
TexImage,
+   TexImage_Mipmap,
 };
 
+GLboolean test_enable[TEST_COUNT];
+
 struct vertex {
GLfloat x, y, s, t;
 };
@@ -62,17 +79,17 @@ static const struct vertex vertices[1] = {
 GLenum parseType(char *);
 GLenum parseFormat(char *, int);
 void parseConfigFile(void);
+GLuint GenerateMipmapImages(void);
 
 #define VOFFSET(F) ((void *) offsetof(struct vertex, F))
 
-/** defaults; config file options can be provided to set these */
-static const char *configFile = teximage_enh.opts;
-GLint g_level = 1;
+/** defaults; options can be provided to set these */
+GLint g_level = 0;
 GLsizei g_width = 256;
 GLsizei g_height = 256;
 GLuint g_texelsize = 4;
 GLenum g_texsrctype = GL_UNSIGNED_BYTE;
-GLenum g_texfmt = GL_RGB;
+GLenum g_texfmt = GL_RGBA;
 GLenum g_texintfmt = 0;
 GLboolean g_drawpoint = GL_TRUE;
 char configName[2056];
@@ -82,7 +99,21 @@ char typeName[256] = GL_UNSIGNED_BYTE;
 char formatName[256] = GL_RGB;
 char internalformatName[256] = GL_RGB;
 GLboolean g_verbose = GL_FALSE;
-GLboolean g_csvstyle = GL_FALSE;
+
+/* used when mipmapping */
+static GLsizei g_initialwidth;
+static GLsizei g_initialheight;
+int g_numLevel = 0;
+GLubyte *g_mipmapimgs[64];
+GLsizei g_mmwidths[64];
+GLsizei g_mmheights[64];
+
+enum csvStyle {
+   CSV_STYLE_OFF,
+   CSV_STYLE_DATA,
+   CSV_STYLE_FULL
+};
+enum csvStyle g_csvstyle = CSV_STYLE_OFF;
 
 /** parse the type string */
 GLenum
@@ -141,12 +172,12 @@ parseFormat(char *formatstr, int ftype)
} else {
   /* if we get here, format specified is invalid; use a default */
   perf_printf(\n);
-  perf_printf(warning: format %s unknown; using GL_RGB\n, formatstr);
+  perf_printf(warning: format %s unknown; using GL_RGBA\n, formatstr);
   oglformat = GL_RGB;
   if (ftype == formattype) {
- strcpy(formatName, GL_RGB);
+ strcpy(formatName, GL_RGBA);
   } else {
- strcpy(internalformatName, GL_RGB);
+ strcpy(internalformatName, GL_RGBA);
   }
}
 
@@ -154,74 +185,135 @@ parseFormat(char *formatstr, int ftype)
 }
 
 /** parse the args in the teximage_enh.opts file */
-void
-parseConfigFile(void)
+static void
+parseCommands(int argc, char *argv[])
 {
-   FILE *fp;
char *key, *value;
-   char *equal = =;
-   char line[ 128];
-   int len;
int intval;
+   int arg, i;
 
-   //perf_printf(parsing configuration file %s\n, configFile);
-   fp = fopen(configFile, r);
-   if (!fp) {
-  perf_printf(%s file does not exist, using defaults\n, configFile);
-   } else {
-  while (fgets(line, sizeof line, fp) != NULL) {
- //perf_printf(config file line read: %s\n, line);
- /* TODO - better check for blank line */
- if ((strncmp(line, #, 1) == 0) || (line[0] == '\n')) {
-/* comment or blank line, continue */
-//perf_printf(found comment or blank line; continuing\n);
-continue;
- }
+   bzero(test_enable, sizeof (test_enable));
 
- /* get the key and value */
- key = strtok(line, equal);
- value = strtok(NULL, equal);
- intval = atoi(value);
-
- /* remove line feed */
- len = strlen(value);
- if (value[len - 1] == '\n') {
-value[len - 1] = 0;
- }
-
- /* parse the arguments and set options appropriately */
- if (strcmp(key, width) == 0) {
+   for (arg = 1; arg  argc; arg++) {
+  /* parse the arguments and set options appropriately */
+

[Mesa-dev] [PATCH demos 2/3] Perf: Add test to measure texture upload

Needed test to measure texture upload speed under a variety
of modes (mipmap, source format, internal format, size, etc.)
This new test has an interactive run mode like the other Mesa
Perf tests but also includes command line options to make
it automatable.
Fix up code formatting.

Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
 src/perf/CMakeLists.txt|   1 +
 src/perf/Makefile.am   |   1 +
 src/perf/bench_glTexImage2D.sh |  13 ++
 src/perf/teximage_enh.README   |  10 ++
 src/perf/teximage_enh.c| 391 +
 5 files changed, 416 insertions(+)
 create mode 100755 src/perf/bench_glTexImage2D.sh
 create mode 100644 src/perf/teximage_enh.README
 create mode 100644 src/perf/teximage_enh.c

diff --git a/src/perf/CMakeLists.txt b/src/perf/CMakeLists.txt
index 68b6875..ded 100644
--- a/src/perf/CMakeLists.txt
+++ b/src/perf/CMakeLists.txt
@@ -28,6 +28,7 @@ set (targets
readpixels
swapbuffers
teximage
+   teximage_enh
vbo
vertexrate
 )
diff --git a/src/perf/Makefile.am b/src/perf/Makefile.am
index 5363c58..1cc5c43 100644
--- a/src/perf/Makefile.am
+++ b/src/perf/Makefile.am
@@ -51,6 +51,7 @@ bin_PROGRAMS = \
readpixels \
swapbuffers \
teximage \
+   teximage_enh \
vbo \
vertexrate \
glslstateschange
diff --git a/src/perf/bench_glTexImage2D.sh b/src/perf/bench_glTexImage2D.sh
new file mode 100755
index 000..c63a251
--- /dev/null
+++ b/src/perf/bench_glTexImage2D.sh
@@ -0,0 +1,13 @@
+#!/bin/bash
+./teximage_enh --width 1024 --height 1024 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle full --test TexImage
+./teximage_enh --width 1024 --height 1024 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data --test TexImage
+./teximage_enh --width  512 --height  512 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data --test TexImage
+./teximage_enh --width  512 --height  512 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data --test TexImage
+./teximage_enh --width  256 --height  256 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data --test TexImage
+./teximage_enh --width  256 --height  256 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data --test TexImage
+./teximage_enh --width 1024 --height 1024 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data --test 
TexImage_Mipmap
+./teximage_enh --width 1024 --height 1024 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data --test 
TexImage_Mipmap
+./teximage_enh --width  512 --height  512 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data --test 
TexImage_Mipmap
+./teximage_enh --width  512 --height  512 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data --test 
TexImage_Mipmap
+./teximage_enh --width  256 --height  256 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data --test 
TexImage_Mipmap
+./teximage_enh --width  256 --height  256 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data --test 
TexImage_Mipmap
diff --git a/src/perf/teximage_enh.README b/src/perf/teximage_enh.README
new file mode 100644
index 000..44e8aea
--- /dev/null
+++ b/src/perf/teximage_enh.README
@@ -0,0 +1,10 @@
+glTexImage2D benchmark
+  - executable name:  teximage_enh
+  - modified files:  CMakeLists.txt  Makefile.am
+  - new files:
+ teximage_enh.c - code
+ bench_glTexImage2D.sh
+direct run command:  ./teximage_enh
+
+script usage:./test_glTexImage2D.sh
+
diff --git a/src/perf/teximage_enh.c b/src/perf/teximage_enh.c
new file mode 100644
index 000..9bb3944
--- /dev/null
+++ b/src/perf/teximage_enh.c
@@ -0,0 +1,391 @@
+/*
+ * Copyright (C) 2009  VMware, Inc.  All Rights Reserved.
+ *
+ * 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 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

Re: [Mesa-dev] [PATCH 15/18] docs: Import extension spec for GLX_MESA_query_renderer

On 10/11/2013 03:10 PM, Ian Romanick wrote:
 From: Ian Romanick ian.d.roman...@intel.com
 
 The enumerated values are currently allocated from Intel's range.
 
 Signed-off-by: Ian Romanick ian.d.roman...@intel.com
 ---
  docs/MESA_query_renderer.spec | 381 
 ++
  1 file changed, 381 insertions(+)
  create mode 100644 docs/MESA_query_renderer.spec
 
 diff --git a/docs/MESA_query_renderer.spec b/docs/MESA_query_renderer.spec
 new file mode 100644
 index 000..6d683ee
 --- /dev/null
 +++ b/docs/MESA_query_renderer.spec
 @@ -0,0 +1,381 @@
 +Name
 +
 +MESA_query_renderer
 +
 +Name Strings
 +
 +GLX_MESA_query_renderer
 +
 +Contact
 +
 +Ian Romanick ian.d.roman...@intel.com
 +
 +IP Status
 +
 +No known IP claims.
 +
 +Status
 +
 +Incomplete.  DO NOT SHIP.
 +
 +Version
 +
 +Version 5, 14-February-2013
 +
 +Number
 +
 +TBD.
 +
 +Dependencies
 +
 +GLX 1.4 is required.
 +
 +GLX_ARB_create_context and GLX_ARB_create_context_profile are required.
 +
 +This extension interacts with GLX_EXT_create_context_es2_profile and
 +GLX_EXT_create_context_es_profile.
 +
 +Overview
 +
 +In many situations, applications want to detect characteristics of a
 +rendering device before creating a context for that device.  Information
 +gathered at this stage may guide choices the application makes about
 +color depth, number of samples per-pixel, texture quality, and so on.
 +In addition, versions of supported APIs and implementation API
 +preference may also guide start-up decisions made by the application.
 +For example, one implementation may prefer vertex data be supplied using
 +methods only available in a compatibility profile, but another
 +implementation may only support the desired version in a core profile.
 +
 +There are also cases where more than one renderer may be available per
 +display.  For example, there is typically a hardware implementation and
 +a software based implementation.  There are cases where an application
 +may want to pick one over the other.  One such situation is when the
 +software implementation supports more features than the hardware
 +implementation.  Another situation is when a particular version of the
 +hardware implementation is blacklisted due to known bugs.
 +
 +This extension provides a mechanism for the application to query all of
 +the available renderers for a particular display and screen.  In
 +addition, this extension provides a mechanism for applications to create
 +contexts with respect to a specific renderer.
 +
 +New Procedures and Functions
 +
 +Bool glXQueryRendererIntegerMESA(Display *dpy, int screen,
 + int renderer, int attribute,
 + unsigned int *value);
 +Bool glXQueryCurrentRendererIntegerMESA(int attribute, unsigned int 
 *value);
 +
 +const char *glXQueryRendererStringMESA(Display *dpy, int screen,
 +   int renderer, int attribute);
 +
 +const char *glXQueryCurrentRendererStringMESA(int attribute);
 +
 +New Tokens
 +
 +Accepted as an attribute in glXQueryRendererIntegerMESA:
 +
 +GLX_RENDERER_VENDOR_ID_MESA  0x8183
 +GLX_RENDERER_DEVICE_ID_MESA  0x8184
 +GLX_RENDERER_VERSION_MESA0x8185
 +GLX_RENDERER_ACCELERATED_MESA0x8186
 +GLX_RENDERER_VIDEO_MEMORY_MESA   0x8187
 +GLX_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA0x8188
 +GLX_RENDERER_PREFERRED_PROFILE_MESA  0x8189
 +GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA0x818A
 +GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA0x818B
 +GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA  0x818C
 +GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA 0x818D
 +
 +Accepted as an attribute in glXQueryRendererStringMESA:
 +
 +GLX_RENDERER_VENDOR_ID_MESA
 +GLX_RENDERER_DEVICE_ID_MESA
 +
 +Accepted as an attribute name in *attrib_list in
 +glXCreateContextAttribsARB:
 +
 +GLX_RENDERER_ID_MESA 0x818E
 +
 +Additions to the OpenGL / WGL Specifications
 +
 +None. This specification is written for GLX.
 +
 +Additions to the GLX 1.4 Specification
 +
 +[Add the following to Section X.Y.Z of the GLX Specification]
 +
 +To obtain information about the available renderers for a particular
 +display and screen,
 +
 +void glXQueryRendererIntegerMESA(Display *dpy, int screen, int 
 renderer,
 + int attribute, unsigned int *value);

The return type should be Bool, not void.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] i965: add XRGB to tiled_memcpy

MESA_FORMAT_XRGB is equivalent to MESA_FORMAT_ARGB in terms
of storage on the device, so okay to use this optimized copy routine.

Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c 
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index 0384bcc..b1826fa 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -571,7 +571,8 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
(texImage-TexFormat == MESA_FORMAT_A8  format == GL_ALPHA)) {
   cpp = 1;
   mem_copy = memcpy;
-   } else if (texImage-TexFormat == MESA_FORMAT_ARGB) {
+   } else if ((texImage-TexFormat == MESA_FORMAT_ARGB)
+ || (texImage-TexFormat == MESA_FORMAT_XRGB)) {
   cpp = 4;
   if (format == GL_BGRA) {
  mem_copy = memcpy;
-- 
1.8.1.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] i965: Enhance tiled_memcpy to support all levels

Support all levels of a supported texture format.

Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c 
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index b1826fa..b32af3d 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -543,7 +543,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
uint32_t cpp;
mem_copy_fn mem_copy = NULL;
 
-   /* This fastpath is restricted to specific texture types: level 0 of
+   /* This fastpath is restricted to specific texture types:
 * a 2D BGRA, RGBA, L8 or A8 texture. It could be generalized to support
 * more types.
 *
@@ -555,7 +555,6 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
if (!brw-has_llc ||
type != GL_UNSIGNED_BYTE ||
texImage-TexObject-Target != GL_TEXTURE_2D ||
-   texImage-Level != 0 ||
pixels == NULL ||
_mesa_is_bufferobj(packing-BufferObj) ||
packing-Alignment  4 ||
@@ -572,7 +571,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
   cpp = 1;
   mem_copy = memcpy;
} else if ((texImage-TexFormat == MESA_FORMAT_ARGB)
- || (texImage-TexFormat == MESA_FORMAT_XRGB)) {
+|| (texImage-TexFormat == MESA_FORMAT_XRGB)) {
   cpp = 4;
   if (format == GL_BGRA) {
  mem_copy = memcpy;
@@ -631,6 +630,11 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
packing-Alignment, packing-RowLength, packing-SkipPixels,
packing-SkipRows, for_glTexImage);
 
+   /* Adjust x and y offset based on miplevel
+*/
+   xoffset += image-mt-level[texImage-Level].level_x;
+   yoffset += image-mt-level[texImage-Level].level_y;
+
linear_to_tiled(
   xoffset * cpp, (xoffset + width) * cpp,
   yoffset, yoffset + height,
-- 
1.8.1.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/2v2] i965: Extend fast texture upload

This series builds on work from Frank Henigman to optimize the
process of uploading a texture to the GPU. This series adds support for
MESA_XRGB_ and full miptrees where were found to be common activities
in the Smokin' Guns game. The issue was found while profiling the app
but that part is not benchmarked. Smokin-Guns uses mipmap textures with
an internal format of GL_RGB (MESA_XRGB_ in the driver).

These changes need a performance tool to run against to show how they
improve execution performance for specific texture formats. Using this
benchmark I've measured the following improvement on my Ivybridge
Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz.

Using 1024x1024, RGBA  source, mipmap
internal-format Before (MB/sec) After XRGB (MB/sec) After mip (MB/sec)
GL_RGBA 628.15  627.15  615.90
GL_RGB  265.95  456.35  611.53

Test shows similar pattern for 512x512 and 256x256.

Benchmark has been sent to mesa-dev list: teximage_enh

Courtney Goeltzenleuchter (2):
  i965: add XRGB to tiled_memcpy
  i965: Enhance tiled_memcpy to support all levels

 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

-- 
1.8.1.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 15/18] docs: Import extension spec for GLX_MESA_query_renderer

2013-11-07 Thread Dave Airlie

On Sat, Oct 12, 2013 at 8:10 AM, Ian Romanick i...@freedesktop.org wrote:
 From: Ian Romanick ian.d.roman...@intel.com

 The enumerated values are currently allocated from Intel's range.

Some highlevel comments below,


 +GLX renderer attribute number description
 +  of values
 +---   ---
 +GLX_RENDERER_VENDOR_ID_MESA   1   PCI ID of the device vendor
 +GLX_RENDERER_DEVICE_ID_MESA   1   PCI ID of the device

Okay PCI IDs might seem useful but we have a lot of situations where
they aren't available,

a) ARM devices generally don't have them
b) nvidia generally espouse using PCI IDs in favour of a chip family
ID they bake into the GPUs,
nouveau doesn't even know the actual PCI IDs in userspace, we could
find them but it does take a bit more work, like new kernel interface.

 +
 +GLX renderer attributedescription
 +-----
 +GLX_RENDERER_VENDOR_ID_MESA   Name of the renderer provider.  This may
 +  differ from the vendor name of the
 +  underlying hardware.
 +GLX_RENDERER_DEVICE_ID_MESA   Name of the renderer.  This may differ from
 +  the name of the underlying hardware (e.g.,
 +  for a software renderer).
 +
 +If attribute is not a recognized value, NULL is returned, but no GLX
 +error is generated.
 +
 +The string returned for GLX_RENDERER_VENDOR_ID_MESA will have the same
 +format as the string that would be returned by glGetString of GL_VENDOR.
 +It may, however, have a different value.

Any reason for the value to be different here? Like a use case?
 +14) Why not make the queries from issue #14 GL functions (instead of 
 GLX)?
 +

from issue 14? this is issue 14

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/18] i965: Wire up initial support for DRI_RENDERER_QUERY extension

On 10/11/2013 03:10 PM, Ian Romanick wrote:
 From: Ian Romanick ian.d.roman...@intel.com
 
 Signed-off-by: Ian Romanick ian.d.roman...@intel.com
 ---
  src/mesa/drivers/dri/i965/intel_screen.c | 81 
 
  1 file changed, 81 insertions(+)
 
 diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
 b/src/mesa/drivers/dri/i965/intel_screen.c
 index b6b4275..e8a0323 100644
 --- a/src/mesa/drivers/dri/i965/intel_screen.c
 +++ b/src/mesa/drivers/dri/i965/intel_screen.c
 @@ -27,6 +27,7 @@
  
  #include errno.h
  #include time.h
 +#include sys/sysinfo.h
  #include main/glheader.h
  #include main/context.h
  #include main/framebuffer.h
 @@ -835,10 +836,90 @@ static struct __DRIimageExtensionRec 
 intelImageExtension = {
  .createImageFromDmaBufs = intel_create_image_from_dma_bufs
  };
  
 +static int
 +brw_query_renderer_integer(__DRIscreen *psp, int param, int *value)
 +{
 +   const struct intel_screen *const intelScreen =
 +  (struct intel_screen *) psp-driverPrivate;
 +
 +   switch (param) {
 +   case __DRI2_RENDERER_VENDOR_ID:
 +  value[0] = 0x8086;
 +  return 0;
 +   case __DRI2_RENDERER_DEVICE_ID:
 +  value[0] = intelScreen-deviceID;
 +  return 0;
 +   case __DRI2_RENDERER_ACCELERATED:
 +  value[0] = 1;
 +  return 0;
 +   case __DRI2_RENDERER_VIDEO_MEMORY: {
 +  struct sysinfo info;
 +  uint64_t system_memory_bytes;
 +  unsigned system_memory_megabytes;
 +
 +  /* Once a batch uses more than 75% of the maximum mappable size, we
 +   * assume that there's some fragmentation, and we start doing extra
 +   * flushing, etc.  That's the big cliff apps will care about.
 +   *
 +   * Can only map 2G onto the GPU through the GTT.
 +   */
 +  const unsigned gpu_mappable_megabytes = 2 * 1024 * 3 / 4;
 +
 +  if (sysinfo(info)  0)
 + return -1;

This is Linux-specific, so it won't work on BSD or Solaris.  I think you
could also do:

uint64_t system_memory_bytes =
   sysconf(_SC_PHYS_PAGES) * sysconf(_SC_PAGE_SIZE);

(I found this suggestion on StackOverflow:)
http://stackoverflow.com/questions/2513505/how-to-get-available-memory-c-g

According to the man page, sysconf(3) conforms to POSIX.1-2001.  A bit
of searching shows that it's available on Solaris and Mac OS X.

The 3/4 GTT suggestion sounds reasonably sane, but I'd like to hear
Eric's opinion on the matter.

--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965: Enhance tiled_memcpy to support all levels

I saw the perf demo patches and expected to see results from them in
this patch. Any results to share?

On Thu, Nov 7, 2013 at 1:22 PM, Courtney Goeltzenleuchter
court...@lunarg.com wrote:
 Support all levels of a supported texture format.

 Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
 ---
  src/mesa/drivers/dri/i965/intel_tex_subimage.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

 diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c 
 b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
 index b1826fa..b32af3d 100644
 --- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
 +++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
 @@ -543,7 +543,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
 uint32_t cpp;
 mem_copy_fn mem_copy = NULL;

 -   /* This fastpath is restricted to specific texture types: level 0 of
 +   /* This fastpath is restricted to specific texture types:
  * a 2D BGRA, RGBA, L8 or A8 texture. It could be generalized to support
  * more types.
  *
 @@ -555,7 +555,6 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
 if (!brw-has_llc ||
 type != GL_UNSIGNED_BYTE ||
 texImage-TexObject-Target != GL_TEXTURE_2D ||
 -   texImage-Level != 0 ||
 pixels == NULL ||
 _mesa_is_bufferobj(packing-BufferObj) ||
 packing-Alignment  4 ||
 @@ -572,7 +571,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
cpp = 1;
mem_copy = memcpy;
 } else if ((texImage-TexFormat == MESA_FORMAT_ARGB)
 - || (texImage-TexFormat == MESA_FORMAT_XRGB)) {
 +|| (texImage-TexFormat == MESA_FORMAT_XRGB)) {

Extraneous change?

cpp = 4;
if (format == GL_BGRA) {
   mem_copy = memcpy;
 @@ -631,6 +630,11 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
 packing-Alignment, packing-RowLength, packing-SkipPixels,
 packing-SkipRows, for_glTexImage);

 +   /* Adjust x and y offset based on miplevel
 +*/
 +   xoffset += image-mt-level[texImage-Level].level_x;
 +   yoffset += image-mt-level[texImage-Level].level_y;
 +
 linear_to_tiled(
xoffset * cpp, (xoffset + width) * cpp,
yoffset, yoffset + height,
 --
 1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965: Enhance tiled_memcpy to support all levels

On Thu, Nov 7, 2013 at 1:28 PM, Matt Turner matts...@gmail.com wrote:
 I saw the perf demo patches and expected to see results from them in
 this patch. Any results to share?

Oh, I see they're in the cover letter. They should really be in the
commit messages, for a variety of reasons.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965: Enhance tiled_memcpy to support all levels

Hi Matt,

I posted results in my cover letter email: [PATCH 0/2v2] i965: Extend fast
texture upload

Please let me know if you want more details.

Courtney


On Thu, Nov 7, 2013 at 2:28 PM, Matt Turner matts...@gmail.com wrote:

 I saw the perf demo patches and expected to see results from them in
 this patch. Any results to share?

 On Thu, Nov 7, 2013 at 1:22 PM, Courtney Goeltzenleuchter
 court...@lunarg.com wrote:
  Support all levels of a supported texture format.
 
  Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
  ---
   src/mesa/drivers/dri/i965/intel_tex_subimage.c | 10 +++---
   1 file changed, 7 insertions(+), 3 deletions(-)
 
  diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
 b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
  index b1826fa..b32af3d 100644
  --- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
  +++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
  @@ -543,7 +543,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context *
 ctx,
  uint32_t cpp;
  mem_copy_fn mem_copy = NULL;
 
  -   /* This fastpath is restricted to specific texture types: level 0 of
  +   /* This fastpath is restricted to specific texture types:
   * a 2D BGRA, RGBA, L8 or A8 texture. It could be generalized to
 support
   * more types.
   *
  @@ -555,7 +555,6 @@ intel_texsubimage_tiled_memcpy(struct gl_context *
 ctx,
  if (!brw-has_llc ||
  type != GL_UNSIGNED_BYTE ||
  texImage-TexObject-Target != GL_TEXTURE_2D ||
  -   texImage-Level != 0 ||
  pixels == NULL ||
  _mesa_is_bufferobj(packing-BufferObj) ||
  packing-Alignment  4 ||
  @@ -572,7 +571,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context *
 ctx,
 cpp = 1;
 mem_copy = memcpy;
  } else if ((texImage-TexFormat == MESA_FORMAT_ARGB)
  - || (texImage-TexFormat == MESA_FORMAT_XRGB)) {
  +|| (texImage-TexFormat == MESA_FORMAT_XRGB)) {

 Extraneous change?

 cpp = 4;
 if (format == GL_BGRA) {
mem_copy = memcpy;
  @@ -631,6 +630,11 @@ intel_texsubimage_tiled_memcpy(struct gl_context *
 ctx,
  packing-Alignment, packing-RowLength, packing-SkipPixels,
  packing-SkipRows, for_glTexImage);
 
  +   /* Adjust x and y offset based on miplevel
  +*/
  +   xoffset += image-mt-level[texImage-Level].level_x;
  +   yoffset += image-mt-level[texImage-Level].level_y;
  +
  linear_to_tiled(
 xoffset * cpp, (xoffset + width) * cpp,
 yoffset, yoffset + height,
  --
  1.8.1.2




-- 
Courtney Goeltzenleuchter
LunarG
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/18] i965: Wire up initial support for DRI_RENDERER_QUERY extension

2013-11-07 Thread Daniel Vetter

On Sat, Oct 12, 2013 at 12:10 AM, Ian Romanick i...@freedesktop.org wrote:
 +  /* Once a batch uses more than 75% of the maximum mappable size, we
 +   * assume that there's some fragmentation, and we start doing extra
 +   * flushing, etc.  That's the big cliff apps will care about.
 +   *
 +   * Can only map 2G onto the GPU through the GTT.
 +   */
 +  const unsigned gpu_mappable_megabytes = 2 * 1024 * 3 / 4;

We have an ioctl to tell you that, since it's not really 2G on really
old stuff. And will probably change on newer platforms. Also, using
that ioctl allows the kernel to limit your usage in case the available
ram is less than the virtual size of the gtt (atm we don't bother with
that much cleverness, but probably will in the future). See
DRM_IOCTL_I915_GEM_GET_APERTURE in libdrm (it's unfortunately not
exposed through any libdrm function afaics.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/2v2] i965: Extend fast texture upload

On Thu, Nov 7, 2013 at 1:22 PM, Courtney Goeltzenleuchter
court...@lunarg.com wrote:
 This series builds on work from Frank Henigman to optimize the
 process of uploading a texture to the GPU. This series adds support for
 MESA_XRGB_ and full miptrees where were found to be common activities
 in the Smokin' Guns game. The issue was found while profiling the app
 but that part is not benchmarked. Smokin-Guns uses mipmap textures with
 an internal format of GL_RGB (MESA_XRGB_ in the driver).

 These changes need a performance tool to run against to show how they
 improve execution performance for specific texture formats. Using this
 benchmark I've measured the following improvement on my Ivybridge
 Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz.

 Using 1024x1024, RGBA  source, mipmap
 internal-format Before (MB/sec) After XRGB (MB/sec) After mip (MB/sec)
 GL_RGBA 628.15  627.15  615.90
 GL_RGB  265.95  456.35  611.53

Put these results into the individual commit messages.

 Test shows similar pattern for 512x512 and 256x256.

Wouldn't hurt to include these as well.

Patch 1 (with benchmarks in the commit message) is:

Reviewed-by: Matt Turner matts...@gmail.com

I don't know anything about the miptree layout, so I don't feel able
to review the second patch, but it seems plausible.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/18] Implement GLX_MESA_query_renderer

I'd like to hear Eric's opinion on patch 8's memory limit.

I sent comments on patches 6, 8, 10, and 15.

With those fixes, patches 1-11 and 13-15 would get:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org

I don't plan to review patches 12 or 16-18 (unit tests).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 71359] New: varray.c:324:7: error: non-void function 'update_array_format' should return a value [-Wreturn-type]

https://bugs.freedesktop.org/show_bug.cgi?id=71359

  Priority: medium
Bug ID: 71359
  Keywords: regression
CC: chr...@ijw.co.nz, e...@anholt.net
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: varray.c:324:7: error: non-void function
'update_array_format' should return a value
[-Wreturn-type]
  Severity: blocker
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Mesa core
   Product: Mesa

mesa: 6b990a7474f9183077e19613fd0243c84d3824bd

Build error with clang.

main/varray.c:324:7: error: non-void function 'update_array_format' should
return a value [-Wreturn-type]

commit 1f092a95941b990f3a06fa71a3b53e15a8a112e8
Author: Chris Forbes chr...@ijw.co.nz
Date:   Thu Nov 7 22:02:24 2013 +1300

mesa: add varray support for UNSIGNED_INT_10F_11F_11F_REV type

V2: fix interaction with VertexAttribFormat, since that landed after
this was originally written

Signed-off-by: Chris Forbes chr...@ijw.co.nz
Reviewed-by: Eric Anholt e...@anholt.net

-- 
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 4/5] glsl: Apply the transformation (a ^^ a) - false in opt_algebraic.

---
 src/glsl/opt_algebraic.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index ea3c386..448f27e 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -377,7 +377,6 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
   break;
 
case ir_binop_logic_xor:
-  /* FINISHME: Also simplify (a ^^ a) to (false). */
   if (is_vec_zero(op_const[0])) {
 return ir-operands[1];
   } else if (is_vec_zero(op_const[1])) {
@@ -386,6 +385,9 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
 return logic_not(ir-operands[1]);
   } else if (is_vec_one(op_const[1])) {
 return logic_not(ir-operands[0]);
+  } else if (ir-operands[0]-equals(ir-operands[1])) {
+ /* (a ^^ a) == false */
+return ir_constant::zero(mem_ctx, ir-type);
   }
   break;
 
-- 
1.8.4.rc3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/5] glsl: Apply the transformation (a a) - a in opt_algebraic.

---
 src/glsl/opt_algebraic.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 3da27e5..ea3c386 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -357,7 +357,6 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
   break;
 
case ir_binop_logic_and:
-  /* FINISHME: Also simplify (a  a) to (a). */
   if (is_vec_one(op_const[0])) {
 return ir-operands[1];
   } else if (is_vec_one(op_const[1])) {
@@ -371,6 +370,9 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
   */
  return logic_not(logic_or(op_expr[0]-operands[0],
op_expr[1]-operands[0]));
+  } else if (ir-operands[0]-equals(ir-operands[1])) {
+ /* (a  a) == a */
+ return ir-operands[0];
   }
   break;
 
-- 
1.8.4.rc3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/5] glsl: Move the CSE equality functions to the ir class.

I want to reuse them in opt_algebraic.
---
 src/glsl/Makefile.sources |   1 +
 src/glsl/ir.h |  22 ++
 src/glsl/ir_equals.cpp| 196 ++
 src/glsl/opt_cse.cpp  | 178 +
 4 files changed, 220 insertions(+), 177 deletions(-)
 create mode 100644 src/glsl/ir_equals.cpp

diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
index 2aabc05..43f122b 100644
--- a/src/glsl/Makefile.sources
+++ b/src/glsl/Makefile.sources
@@ -33,6 +33,7 @@ LIBGLSL_FILES = \
$(GLSL_SRCDIR)/ir_clone.cpp \
$(GLSL_SRCDIR)/ir_constant_expression.cpp \
$(GLSL_SRCDIR)/ir.cpp \
+   $(GLSL_SRCDIR)/ir_equals.cpp \
$(GLSL_SRCDIR)/ir_expression_flattening.cpp \
$(GLSL_SRCDIR)/ir_function_can_inline.cpp \
$(GLSL_SRCDIR)/ir_function_detect_recursion.cpp \
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 2f06fb9..7859702 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -139,6 +139,16 @@ public:
virtual class ir_jump *  as_jump() { return NULL; }
/*@}*/
 
+   /**
+* IR equality method: Return true if the referenced instruction would
+* return the same value as this one.
+*
+* This intended to be used for CSE and algebraic optimizations, on rvalues
+* in particular.  No support for other instruction types (assignments,
+* jumps, calls, etc.) is planned.
+*/
+   virtual bool equals(ir_instruction *ir);
+
 protected:
ir_instruction()
{
@@ -1405,6 +1415,8 @@ public:
   return this;
}
 
+   virtual bool equals(ir_instruction *ir);
+
virtual ir_expression *clone(void *mem_ctx, struct hash_table *ht) const;
 
/**
@@ -1739,6 +1751,8 @@ public:
 
virtual ir_visitor_status accept(ir_hierarchical_visitor *);
 
+   virtual bool equals(ir_instruction *ir);
+
/**
 * Return a string representing the ir_texture_opcode.
 */
@@ -1843,6 +1857,8 @@ public:
 
virtual ir_visitor_status accept(ir_hierarchical_visitor *);
 
+   virtual bool equals(ir_instruction *ir);
+
bool is_lvalue() const
{
   return val-is_lvalue()  !mask.has_duplicates;
@@ -1907,6 +1923,8 @@ public:
   return this;
}
 
+   virtual bool equals(ir_instruction *ir);
+
/**
 * Get the variable that is ultimately referenced by an r-value
 */
@@ -1965,6 +1983,8 @@ public:
   return this;
}
 
+   virtual bool equals(ir_instruction *ir);
+
/**
 * Get the variable that is ultimately referenced by an r-value
 */
@@ -2099,6 +2119,8 @@ public:
 
virtual ir_visitor_status accept(ir_hierarchical_visitor *);
 
+   virtual bool equals(ir_instruction *ir);
+
/**
 * Get a particular component of a constant as a specific type
 *
diff --git a/src/glsl/ir_equals.cpp b/src/glsl/ir_equals.cpp
new file mode 100644
index 000..0b28b39
--- /dev/null
+++ b/src/glsl/ir_equals.cpp
@@ -0,0 +1,196 @@
+/*
+ * Copyright © 2013 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.
+ */
+
+#include ir.h
+
+/**
+ * Helper for checking equality when one instruction might be NULL, since you
+ * can't a's vtable in that case.
+ */
+static bool
+possibly_null_equals(ir_instruction *a, ir_instruction *b)
+{
+   if (!a || !b)
+  return !a  !b;
+
+   return a-equals(b);
+}
+
+/**
+ * The base equality function: Return not equal for anything we don't know
+ * about.
+ */
+bool
+ir_instruction::equals(ir_instruction *ir)
+{
+   return false;
+}
+
+bool
+ir_constant::equals(ir_instruction *ir)
+{
+   const ir_constant *other = ir-as_constant();
+   if (!other)
+  return false;
+
+   if (type != other-type)
+  return false;
+
+   for (unsigned i = 0; i  type-components(); i++) {
+  if (value.u[i] != other-value.u[i])
+ return false;
+   }
+
+   return true;
+}
+
+bool
+ir_dereference_variable::equals(ir_instruction

[Mesa-dev] [PATCH 2/5] glsl: Apply the transformation (a || a) - a in opt_algebraic.

total instructions in shared programs: 1732385 - 1732373 (-0.00%)
instructions in affected programs: 416 - 404 (-2.88%)
GAINED:0
LOST:  0

(That's 4 already-short fragment shaders in dota2)
---
 src/glsl/opt_algebraic.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index a07e153..3da27e5 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -388,7 +388,6 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
   break;
 
case ir_binop_logic_or:
-  /* FINISHME: Also simplify (a || a) to (a). */
   if (is_vec_zero(op_const[0])) {
 return ir-operands[1];
   } else if (is_vec_zero(op_const[1])) {
@@ -407,6 +406,9 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
   */
  return logic_not(logic_and(op_expr[0]-operands[0],
 op_expr[1]-operands[0]));
+  } else if (ir-operands[0]-equals(ir-operands[1])) {
+ /* (a || a) == a */
+ return ir-operands[0];
   }
   break;
 
-- 
1.8.4.rc3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/5] glsl: Apply the transformation 1/rsq(x) == sqrt(x) in opt_algebraic.

The comment was stale, because the lowering in question wasn't happening
in lower_instructions.cpp.  Presumably if the lowering ever moves there,
we can plumb the lowering mask through to opt_algebraic.

total instructions in shared programs: 1618696 - 1616810 (-0.12%)
instructions in affected programs: 243018 - 241132 (-0.78%)
GAINED:0
LOST:  0
---
 src/glsl/opt_algebraic.cpp | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 448f27e..05a5899 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -420,10 +420,11 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
   if (op_expr[0]  op_expr[0]-operation == ir_unop_rcp)
 return op_expr[0]-operands[0];
 
-  /* FINISHME: We should do rcp(rsq(x)) - sqrt(x) for some
-   * backends, except that some backends will have done sqrt -
-   * rcp(rsq(x)) and we don't want to undo it for them.
+  /* While ir_to_mesa.cpp will lower sqrt(x) to rcp(rsq(x)), it does so at
+   * its IR level, so we can always apply this transformation.
*/
+  if (op_expr[0]  op_expr[0]-operation == ir_unop_rsq)
+ return sqrt(op_expr[0]-operands[0]);
 
   /* As far as we know, all backends are OK with rsq. */
   if (op_expr[0]  op_expr[0]-operation == ir_unop_sqrt) {
-- 
1.8.4.rc3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2 v3] i965: add XRGB to tiled_memcpy

MESA_FORMAT_XRGB is equivalent to MESA_FORMAT_ARGB in terms
of storage on the device, so okay to use this optimized copy routine.

This series builds on work from Frank Henigman to optimize the
process of uploading a texture to the GPU. This series adds support for
MESA_XRGB_ and full miptrees where were found to be common activities
in the Smokin' Guns game. The issue was found while profiling the app
but that part is not benchmarked. Smokin-Guns uses mipmap textures with
an internal format of GL_RGB (MESA_XRGB_ in the driver).

These changes need a performance tool to run against to show how they
improve execution performance for specific texture formats. Using this
benchmark I've measured the following improvement on my Ivybridge
Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz.

Using 1024x1024, RGBA  source, mipmap
THIS PATCH
internal-format Before (MB/sec) XRGB (MB/sec)   mipmap (MB/sec)
GL_RGBA 628.15  627.15  615.90
GL_RGB  265.95  456.35  611.53
512x512
GL_RGBA 600.23  597.00  619.95
GL_RGB  255.50  440.62  611.28
256x256
GL_RGBA 489.08  487.80  587.42
GL_RGB  229.03  376.63  585.00

Test shows similar pattern for 512x512 and 256x256.

Benchmark has been sent to mesa-dev list: teximage_enh

Courtney Goeltzenleuchter (2):
  i965: add XRGB to tiled_memcpy
  i965: Enhance tiled_memcpy to support all levels

 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

--
1.8.1.2

Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c 
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index 0384bcc..b1826fa 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -571,7 +571,8 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
(texImage-TexFormat == MESA_FORMAT_A8  format == GL_ALPHA)) {
   cpp = 1;
   mem_copy = memcpy;
-   } else if (texImage-TexFormat == MESA_FORMAT_ARGB) {
+   } else if ((texImage-TexFormat == MESA_FORMAT_ARGB)
+ || (texImage-TexFormat == MESA_FORMAT_XRGB)) {
   cpp = 4;
   if (format == GL_BGRA) {
  mem_copy = memcpy;
-- 
1.8.1.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2 v3] i965: Enhance tiled_memcpy to support all levels

Support all levels of a supported texture format.

Using 1024x1024, RGBA  source, mipmap
THIS PATCH
internal-format Before (MB/sec) XRGB (MB/sec)   mipmap (MB/sec)
GL_RGBA 628.15  627.15  615.90
GL_RGB  265.95  456.35  611.53
512x512
GL_RGBA 600.23  597.00  619.95
GL_RGB  255.50  440.62  611.28
256x256
GL_RGBA 489.08  487.80  587.42
GL_RGB  229.03  376.63  585.00

Test shows similar pattern for 512x512 and 256x256.

Benchmark has been sent to mesa-dev list: teximage_enh

Courtney Goeltzenleuchter (2):
  i965: add XRGB to tiled_memcpy
  i965: Enhance tiled_memcpy to support all levels

 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

--
1.8.1.2

Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c 
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index b1826fa..b32af3d 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
@@ -543,7 +543,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
uint32_t cpp;
mem_copy_fn mem_copy = NULL;
 
-   /* This fastpath is restricted to specific texture types: level 0 of
+   /* This fastpath is restricted to specific texture types:
 * a 2D BGRA, RGBA, L8 or A8 texture. It could be generalized to support
 * more types.
 *
@@ -555,7 +555,6 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
if (!brw-has_llc ||
type != GL_UNSIGNED_BYTE ||
texImage-TexObject-Target != GL_TEXTURE_2D ||
-   texImage-Level != 0 ||
pixels == NULL ||
_mesa_is_bufferobj(packing-BufferObj) ||
packing-Alignment  4 ||
@@ -572,7 +571,7 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
   cpp = 1;
   mem_copy = memcpy;
} else if ((texImage-TexFormat == MESA_FORMAT_ARGB)
- || (texImage-TexFormat == MESA_FORMAT_XRGB)) {
+|| (texImage-TexFormat == MESA_FORMAT_XRGB)) {
   cpp = 4;
   if (format == GL_BGRA) {
  mem_copy = memcpy;
@@ -631,6 +630,11 @@ intel_texsubimage_tiled_memcpy(struct gl_context * ctx,
packing-Alignment, packing-RowLength, packing-SkipPixels,
packing-SkipRows, for_glTexImage);
 
+   /* Adjust x and y offset based on miplevel
+*/
+   xoffset += image-mt-level[texImage-Level].level_x;
+   yoffset += image-mt-level[texImage-Level].level_y;
+
linear_to_tiled(
   xoffset * cpp, (xoffset + width) * cpp,
   yoffset, yoffset + height,
-- 
1.8.1.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/2v2] i965: Extend fast texture upload

Re-posted patches with updated commit messages.

Thanks,
Courtney


On Thu, Nov 7, 2013 at 2:34 PM, Matt Turner matts...@gmail.com wrote:

 On Thu, Nov 7, 2013 at 1:22 PM, Courtney Goeltzenleuchter
 court...@lunarg.com wrote:
  This series builds on work from Frank Henigman to optimize the
  process of uploading a texture to the GPU. This series adds support for
  MESA_XRGB_ and full miptrees where were found to be common activities
  in the Smokin' Guns game. The issue was found while profiling the app
  but that part is not benchmarked. Smokin-Guns uses mipmap textures with
  an internal format of GL_RGB (MESA_XRGB_ in the driver).
 
  These changes need a performance tool to run against to show how they
  improve execution performance for specific texture formats. Using this
  benchmark I've measured the following improvement on my Ivybridge
  Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz.
 
  Using 1024x1024, RGBA  source, mipmap
  internal-format Before (MB/sec) After XRGB (MB/sec) After mip
 (MB/sec)
  GL_RGBA 628.15  627.15  615.90
  GL_RGB  265.95  456.35  611.53

 Put these results into the individual commit messages.

  Test shows similar pattern for 512x512 and 256x256.

 Wouldn't hurt to include these as well.

 Patch 1 (with benchmarks in the commit message) is:

 Reviewed-by: Matt Turner matts...@gmail.com

 I don't know anything about the miptree layout, so I don't feel able
 to review the second patch, but it seems plausible.




-- 
Courtney Goeltzenleuchter
LunarG
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] glsl: Apply the transformation (a a) - a in opt_algebraic.

Does this affect anything in shader-db?

On Fri, Nov 8, 2013 at 10:58 AM, Eric Anholt e...@anholt.net wrote:
 ---
  src/glsl/opt_algebraic.cpp | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
 index 3da27e5..ea3c386 100644
 --- a/src/glsl/opt_algebraic.cpp
 +++ b/src/glsl/opt_algebraic.cpp
 @@ -357,7 +357,6 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
break;

 case ir_binop_logic_and:
 -  /* FINISHME: Also simplify (a  a) to (a). */
if (is_vec_one(op_const[0])) {
  return ir-operands[1];
} else if (is_vec_one(op_const[1])) {
 @@ -371,6 +370,9 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
*/
   return logic_not(logic_or(op_expr[0]-operands[0],
 op_expr[1]-operands[0]));
 +  } else if (ir-operands[0]-equals(ir-operands[1])) {
 + /* (a  a) == a */
 + return ir-operands[0];
}
break;

 --
 1.8.4.rc3

 ___
 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 71359] varray.c:324:7: error: non-void function 'update_array_format' should return a value [-Wreturn-type]

https://bugs.freedesktop.org/show_bug.cgi?id=71359

Brian Paul bri...@vmware.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Brian Paul bri...@vmware.com ---
Fixed with fe9284a7bfde59c450c49e6c8d58be82907e13a4

-- 
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] glsl: Enable dFdx, dFdy, and fwidth by default in GLSL ES 3.00.

Previously, we only exposed them in desktop GL or with:

   #extension GL_OES_standard_derivatives : enable

GLSL ES 3.00 includes these without an extension, so we need to expose
them by default.

Note that the above #extension line results in an error or desktop GL,
so we don't need to worry about this.

Cc: Aras Pranckevičius a...@unity3d.com
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/glsl/builtin_functions.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 3fa0cb5..8cb75e5 100644
--- a/src/glsl/builtin_functions.cpp
+++ b/src/glsl/builtin_functions.cpp
@@ -293,7 +293,8 @@ static bool
 fs_oes_derivatives(const _mesa_glsl_parse_state *state)
 {
return state-target == fragment_shader 
-  (!state-es_shader || state-OES_standard_derivatives_enable);
+  (state-is_version(110, 300) ||
+   state-OES_standard_derivatives_enable);
 }
 
 static bool
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3 v2] Implement choosing the device to use with DRI_PRIME

two formats are supported: DRI_PRIME=1 will tell Mesa
to choose an other card than the compositor card if possible,
while setting DRI_PRIME to the id_path_tag of a device (like
pci-_02_00_0) tells Mesa to take the device with this
id_path_tag.

Signed-off-by: Axel Davy axel.d...@ens.fr
---
 src/egl/drivers/dri2/platform_wayland.c | 180 ++--
 1 file changed, 170 insertions(+), 10 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index b922ff5..747d745 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -40,6 +40,10 @@
 #include wayland-client.h
 #include wayland-drm-client-protocol.h
 
+#ifdef HAVE_LIBUDEV
+#include libudev.h
+#endif
+
 enum wl_drm_format_flags {
HAS_ARGB = 1,
HAS_XRGB = 2,
@@ -656,6 +660,74 @@ is_fd_render_node(int fd)
   return 0;
 }
 
+#ifdef HAVE_LIBUDEV
+
+static char *
+get_render_node_from_id_path_tag(struct udev *udev, char* id_path_tag,
+char another_tag)
+{
+  struct udev_device *device;
+  struct udev_enumerate *e;
+  struct udev_list_entry *entry;
+  const char *path, *id_path_tag_tmp;
+  char found = 0;
+
+  e = udev_enumerate_new(udev);
+  udev_enumerate_add_match_subsystem(e, drm);
+  udev_enumerate_add_match_sysname(e, render*);
+
+  udev_enumerate_scan_devices(e);
+  udev_list_entry_foreach(entry, udev_enumerate_get_list_entry(e)) {
+path = udev_list_entry_get_name(entry);
+device = udev_device_new_from_syspath(udev, path);
+if (!device)
+  continue;
+id_path_tag_tmp = udev_device_get_property_value(device, ID_PATH_TAG);
+if (id_path_tag_tmp)
+{
+  if((!another_tag  !strcmp(id_path_tag, id_path_tag_tmp))
+|| (another_tag  strcmp(id_path_tag, id_path_tag_tmp)))
+  {
+  found = 1;
+  break;
+  }
+}
+udev_device_unref(device);
+  }
+
+  if(found)
+  {
+char* path = strdup(udev_device_get_devnode(device));
+udev_device_unref(device);
+return path;
+  }
+  return NULL;
+}
+
+static char *
+get_id_path_tag_from_fd(struct udev *udev, int fd)
+{
+   struct udev_device *device;
+   struct stat buf;
+   const char *id_path_tag_tmp;
+
+   if (fstat(fd, buf)  0) {
+  return NULL;
+   }
+
+   device = udev_device_new_from_devnum(udev, 'c', buf.st_rdev);
+
+   if(!device)
+ return NULL;
+   id_path_tag_tmp = udev_device_get_property_value(device, ID_PATH_TAG);
+   if(!id_path_tag_tmp)
+ return NULL;
+
+   return strdup(id_path_tag_tmp);
+}
+
+#endif
+
 static void
 drm_handle_device(void *data, struct wl_drm *drm, const char *device)
 {
@@ -737,13 +809,20 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay 
*disp)
struct dri2_egl_display *dri2_dpy;
const __DRIconfig *config;
uint32_t types;
-   int i, is_render_node;
+   int i, is_render_node, device_fd, is_different_device;
drm_magic_t magic;
static const unsigned int argb_masks[4] =
   { 0xff, 0xff00, 0xff, 0xff00 };
static const unsigned int rgb_masks[4] = { 0xff, 0xff00, 0xff, 0 };
static const unsigned int rgb565_masks[4] = { 0xf800, 0x07e0, 0x001f, 0 };
 
+   char* prime_device_name = NULL;
+   char* prime = NULL;
+   const char *dri_prime = getenv(DRI_PRIME);
+
+   if (dri_prime)
+ prime = strdup(dri_prime);
+
drv-API.CreateWindowSurface = dri2_create_window_surface;
drv-API.DestroySurface = dri2_destroy_surface;
drv-API.SwapBuffers = dri2_swap_buffers;
@@ -781,22 +860,102 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay 
*disp)
if (roundtrip(dri2_dpy)  0 || dri2_dpy-device_name == NULL)
   goto cleanup_drm;
 
+   if (prime  !(dri2_dpy-capabilities  WL_DRM_CAPABILITY_PRIME))
+   /* render-nodes are not supported */
+   {
+  free(prime);
+  prime = NULL;
+   }
+
 #ifdef O_CLOEXEC
-   dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR | O_CLOEXEC);
-   if (dri2_dpy-fd == -1  errno == EINVAL)
+   device_fd = open(dri2_dpy-device_name, O_RDWR | O_CLOEXEC);
+   if (device_fd == -1  errno == EINVAL)
 #endif
{
-  dri2_dpy-fd = open(dri2_dpy-device_name, O_RDWR);
-  if (dri2_dpy-fd != -1)
- fcntl(dri2_dpy-fd, F_SETFD, fcntl(dri2_dpy-fd, F_GETFD) |
+  device_fd = open(dri2_dpy-device_name, O_RDWR);
+  if (device_fd != -1)
+ fcntl(device_fd, F_SETFD, fcntl(device_fd, F_GETFD) |
 FD_CLOEXEC);
}
-   if (dri2_dpy-fd == -1) {
+   if (device_fd == -1) {
   _eglLog(_EGL_WARNING, wayland-egl: could not open %s (%s),
  dri2_dpy-device_name, strerror(errno));
+  free(prime);
   goto cleanup_drm;
}
 
+   if(prime != NULL)
+   {
+#ifdef HAVE_LIBUDEV  
+  struct udev* udev = udev_new();
+  char* device_id_path_tag;
+  char another_tag = 0;
+
+  if (!udev)
+ goto prime_clean;
+  device_id_path_tag = get_id_path_tag_from_fd(udev, device_fd);
+  if (!device_id_path_tag)
+ goto

[Mesa-dev] [PATCH 3/3 v2] Implement choosing the device to use with DRI_PRIME

I forgot to test the capabilities to know if we can use render-nodes.
Being able to do that was the goal of patch 1.

I send a better patch 3.

Axel Davy (1):
  Implement choosing the device to use with DRI_PRIME

 src/egl/drivers/dri2/platform_wayland.c | 180 ++--
 1 file changed, 170 insertions(+), 10 deletions(-)

-- 
1.8.1.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2 10/15] i965: flag new indirect buffer in brw_try_draw_prims

On 6 November 2013 23:06, Chris Forbes chr...@ijw.co.nz wrote:

 Signed-off-by: Chris Forbes chr...@ijw.co.nz
 ---
  src/mesa/drivers/dri/i965/brw_draw.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

 diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
 b/src/mesa/drivers/dri/i965/brw_draw.c
 index e6c3508..9f8ad45 100644
 --- a/src/mesa/drivers/dri/i965/brw_draw.c
 +++ b/src/mesa/drivers/dri/i965/brw_draw.c
 @@ -323,7 +323,8 @@ static bool brw_try_draw_prims( struct gl_context *ctx,
  GLuint nr_prims,
  const struct _mesa_index_buffer *ib,
  GLuint min_index,
 -GLuint max_index )
 +GLuint max_index,
 +const struct gl_buffer_object
 *indirect)
  {
 struct brw_context *brw = brw_context(ctx);
 bool retval = true;
 @@ -377,6 +378,9 @@ static bool brw_try_draw_prims( struct gl_context *ctx,
 brw-vb.max_index = max_index;
 brw-state.dirty.brw |= BRW_NEW_VERTICES;

 +   brw-indirect_buffer.indb = indirect;
 +   brw-state.dirty.brw |= BRW_NEW_INDIRECT_BUFFER;
 +


It seems wasteful to flag this bit on every draw call.  Couldn't we do
something like this?

if (brw-indirect_buffer.indb != NULL || indirect != NULL) {
   brw-indirect_buffer.indb = indirect;
   brw-state.dirty.brw |= BRW_NEW_INDIRECT_BUFFER;
}

Assuming that's addressed, this patch is:

Reviewed-by: Paul Berry stereotype...@gmail.com


 for (i = 0; i  nr_prims; i++) {
int estimated_max_prim_size;

 @@ -506,7 +510,7 @@ void brw_draw_prims( struct gl_context *ctx,
  * manage it.  swrast doesn't support our featureset, so we can't fall
 back
  * to it.
  */
 -   brw_try_draw_prims(ctx, arrays, prims, nr_prims, ib, min_index,
 max_index);
 +   brw_try_draw_prims(ctx, arrays, prims, nr_prims, ib, min_index,
 max_index, indirect);
  }

  void brw_draw_init( struct brw_context *brw )
 --
 1.8.4.2

 ___
 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 10/15] i965: flag new indirect buffer in brw_try_draw_prims

The current plan I think is just to drop the extra state in brw, and
just reference the indirect bo directly when we need it [see Eric's
comment on 09/15]

On Fri, Nov 8, 2013 at 11:41 AM, Paul Berry stereotype...@gmail.com wrote:
 On 6 November 2013 23:06, Chris Forbes chr...@ijw.co.nz wrote:

 Signed-off-by: Chris Forbes chr...@ijw.co.nz
 ---
  src/mesa/drivers/dri/i965/brw_draw.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

 diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
 b/src/mesa/drivers/dri/i965/brw_draw.c
 index e6c3508..9f8ad45 100644
 --- a/src/mesa/drivers/dri/i965/brw_draw.c
 +++ b/src/mesa/drivers/dri/i965/brw_draw.c
 @@ -323,7 +323,8 @@ static bool brw_try_draw_prims( struct gl_context
 *ctx,
  GLuint nr_prims,
  const struct _mesa_index_buffer *ib,
  GLuint min_index,
 -GLuint max_index )
 +GLuint max_index,
 +const struct gl_buffer_object
 *indirect)
  {
 struct brw_context *brw = brw_context(ctx);
 bool retval = true;
 @@ -377,6 +378,9 @@ static bool brw_try_draw_prims( struct gl_context
 *ctx,
 brw-vb.max_index = max_index;
 brw-state.dirty.brw |= BRW_NEW_VERTICES;

 +   brw-indirect_buffer.indb = indirect;
 +   brw-state.dirty.brw |= BRW_NEW_INDIRECT_BUFFER;
 +


 It seems wasteful to flag this bit on every draw call.  Couldn't we do
 something like this?

 if (brw-indirect_buffer.indb != NULL || indirect != NULL) {
brw-indirect_buffer.indb = indirect;
brw-state.dirty.brw |= BRW_NEW_INDIRECT_BUFFER;
 }

 Assuming that's addressed, this patch is:

 Reviewed-by: Paul Berry stereotype...@gmail.com


 for (i = 0; i  nr_prims; i++) {
int estimated_max_prim_size;

 @@ -506,7 +510,7 @@ void brw_draw_prims( struct gl_context *ctx,
  * manage it.  swrast doesn't support our featureset, so we can't fall
 back
  * to it.
  */
 -   brw_try_draw_prims(ctx, arrays, prims, nr_prims, ib, min_index,
 max_index);
 +   brw_try_draw_prims(ctx, arrays, prims, nr_prims, ib, min_index,
 max_index, indirect);
  }

  void brw_draw_init( struct brw_context *brw )
 --
 1.8.4.2

 ___
 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 10/15] i965: flag new indirect buffer in brw_try_draw_prims

On 7 November 2013 14:46, Chris Forbes chr...@ijw.co.nz wrote:

 The current plan I think is just to drop the extra state in brw, and
 just reference the indirect bo directly when we need it [see Eric's
 comment on 09/15]


Ah, ok, that makes sense.  Thanks.



 On Fri, Nov 8, 2013 at 11:41 AM, Paul Berry stereotype...@gmail.com
 wrote:
  On 6 November 2013 23:06, Chris Forbes chr...@ijw.co.nz wrote:
 
  Signed-off-by: Chris Forbes chr...@ijw.co.nz
  ---
   src/mesa/drivers/dri/i965/brw_draw.c | 8 ++--
   1 file changed, 6 insertions(+), 2 deletions(-)
 
  diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
  b/src/mesa/drivers/dri/i965/brw_draw.c
  index e6c3508..9f8ad45 100644
  --- a/src/mesa/drivers/dri/i965/brw_draw.c
  +++ b/src/mesa/drivers/dri/i965/brw_draw.c
  @@ -323,7 +323,8 @@ static bool brw_try_draw_prims( struct gl_context
  *ctx,
   GLuint nr_prims,
   const struct _mesa_index_buffer
 *ib,
   GLuint min_index,
  -GLuint max_index )
  +GLuint max_index,
  +const struct gl_buffer_object
  *indirect)
   {
  struct brw_context *brw = brw_context(ctx);
  bool retval = true;
  @@ -377,6 +378,9 @@ static bool brw_try_draw_prims( struct gl_context
  *ctx,
  brw-vb.max_index = max_index;
  brw-state.dirty.brw |= BRW_NEW_VERTICES;
 
  +   brw-indirect_buffer.indb = indirect;
  +   brw-state.dirty.brw |= BRW_NEW_INDIRECT_BUFFER;
  +
 
 
  It seems wasteful to flag this bit on every draw call.  Couldn't we do
  something like this?
 
  if (brw-indirect_buffer.indb != NULL || indirect != NULL) {
 brw-indirect_buffer.indb = indirect;
 brw-state.dirty.brw |= BRW_NEW_INDIRECT_BUFFER;
  }
 
  Assuming that's addressed, this patch is:
 
  Reviewed-by: Paul Berry stereotype...@gmail.com
 
 
  for (i = 0; i  nr_prims; i++) {
 int estimated_max_prim_size;
 
  @@ -506,7 +510,7 @@ void brw_draw_prims( struct gl_context *ctx,
   * manage it.  swrast doesn't support our featureset, so we can't
 fall
  back
   * to it.
   */
  -   brw_try_draw_prims(ctx, arrays, prims, nr_prims, ib, min_index,
  max_index);
  +   brw_try_draw_prims(ctx, arrays, prims, nr_prims, ib, min_index,
  max_index, indirect);
   }
 
   void brw_draw_init( struct brw_context *brw )
  --
  1.8.4.2
 
  ___
  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 15/18] docs: Import extension spec for GLX_MESA_query_renderer

2013-11-07 Thread Stéphane Marchesin

On Thu, Nov 7, 2013 at 1:22 PM, Dave Airlie airl...@gmail.com wrote:

 On Sat, Oct 12, 2013 at 8:10 AM, Ian Romanick i...@freedesktop.org wrote:
  From: Ian Romanick ian.d.roman...@intel.com
 
  The enumerated values are currently allocated from Intel's range.

 Some highlevel comments below,


  +GLX renderer attribute number description
  +  of values
  +---   ---
  +GLX_RENDERER_VENDOR_ID_MESA   1   PCI ID of the device
 vendor
  +GLX_RENDERER_DEVICE_ID_MESA   1   PCI ID of the device

 Okay PCI IDs might seem useful but we have a lot of situations where
 they aren't available,


I was thinking the same, but then noticed that it's an int, and a pci
device or vendor id is 16 bit, so you could implement this by returning the
pciid if you have it, or something  0x if you don't have it (and sort
of make sure that those don't overlap).

Stéphane


 a) ARM devices generally don't have them
 b) nvidia generally espouse using PCI IDs in favour of a chip family
 ID they bake into the GPUs,
 nouveau doesn't even know the actual PCI IDs in userspace, we could
 find them but it does take a bit more work, like new kernel interface.

  +
  +GLX renderer attributedescription
  +-----
  +GLX_RENDERER_VENDOR_ID_MESA   Name of the renderer provider.  This
 may
  +  differ from the vendor name of the
  +  underlying hardware.
  +GLX_RENDERER_DEVICE_ID_MESA   Name of the renderer.  This may
 differ from
  +  the name of the underlying hardware
 (e.g.,
  +  for a software renderer).
  +
  +If attribute is not a recognized value, NULL is returned, but no
 GLX
  +error is generated.
  +
  +The string returned for GLX_RENDERER_VENDOR_ID_MESA will have the
 same
  +format as the string that would be returned by glGetString of
 GL_VENDOR.
  +It may, however, have a different value.

 Any reason for the value to be different here? Like a use case?
  +14) Why not make the queries from issue #14 GL functions (instead
 of GLX)?
  +

 from issue 14? this is issue 14

 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] [PATCH] glsl: Enable dFdx, dFdy, and fwidth by default in GLSL ES 3.00.

On Thu, Nov 7, 2013 at 2:39 PM, Kenneth Graunke kenn...@whitecape.org wrote:
 Previously, we only exposed them in desktop GL or with:

#extension GL_OES_standard_derivatives : enable

 GLSL ES 3.00 includes these without an extension, so we need to expose
 them by default.

 Note that the above #extension line results in an error or desktop GL,
 so we don't need to worry about this.

 Cc: Aras Pranckevičius a...@unity3d.com
 Cc: mesa-sta...@lists.freedesktop.org
 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 ---
  src/glsl/builtin_functions.cpp | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
 index 3fa0cb5..8cb75e5 100644
 --- a/src/glsl/builtin_functions.cpp
 +++ b/src/glsl/builtin_functions.cpp
 @@ -293,7 +293,8 @@ static bool
  fs_oes_derivatives(const _mesa_glsl_parse_state *state)
  {
 return state-target == fragment_shader 
 -  (!state-es_shader || state-OES_standard_derivatives_enable);
 +  (state-is_version(110, 300) ||
 +   state-OES_standard_derivatives_enable);
  }

  static bool
 --
 1.8.3.2

 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 71363] line rendering with --with-osmesa-bits=32

https://bugs.freedesktop.org/show_bug.cgi?id=71363

--- Comment #1 from burlen burlen.lor...@gmail.com ---
Created attachment 88860
  -- https://bugs.freedesktop.org/attachment.cgi?id=88860action=edit
correct baseline image

-- 
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 71363] New: line rendering with --with-osmesa-bits=32

https://bugs.freedesktop.org/show_bug.cgi?id=71363

  Priority: medium
Bug ID: 71363
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: line rendering with --with-osmesa-bits=32
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: burlen.lor...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Mesa core
   Product: Mesa

Created attachment 88859
  -- https://bugs.freedesktop.org/attachment.cgi?id=88859action=edit
rendered with osmesa --with-depth-bits=32

when runnning VTK regression suite on an OSMesa classic build with
--with-osmesa-bits=32 (and only 32 - 8,16 and none work) 80 regressions show
bad line rendering. I'm attaching some images that are illustrative. There's a
thread on the mesa-dev mailist about this issue.

-- 
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 71363] line rendering with --with-osmesa-bits=32

https://bugs.freedesktop.org/show_bug.cgi?id=71363

burlen burlen.lor...@gmail.com changed:

   What|Removed |Added

  Attachment #88859|0   |1
is obsolete||

--- Comment #2 from burlen burlen.lor...@gmail.com ---
Created attachment 88861
  -- https://bugs.freedesktop.org/attachment.cgi?id=88861action=edit
rendered with osmesa (bug)

-- 
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 71363] line rendering with --with-osmesa-bits=32

https://bugs.freedesktop.org/show_bug.cgi?id=71363

--- Comment #3 from burlen burlen.lor...@gmail.com ---
Created attachment 88862
  -- https://bugs.freedesktop.org/attachment.cgi?id=88862action=edit
diff

-- 
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 3/5] glsl: Apply the transformation (a a) - a in opt_algebraic.

Chris Forbes chr...@ijw.co.nz writes:

 Does this affect anything in shader-db?

Nope, the shader-db-affecting patches had it cited.


pgpOd0euvJ9qG.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] DEFAULT_SOFTWARE_DEPTH_BITS=31

2013-11-07 Thread burlen

On 11/07/2013 08:45 AM, burlen wrote:

On 11/07/2013 08:14 AM, Brian Paul wrote:

On 11/07/2013 09:09 AM, burlen wrote:

On 11/07/2013 06:42 AM, Brian Paul wrote:

On 11/06/2013 04:59 PM, burlen wrote:

On 11/06/2013 12:58 PM, Brian Paul wrote:

On 11/06/2013 12:34 PM, burlen wrote:
When I build osmesa with --with-osmesa-bits=32 I notice that I
get 31

bits by way of the compile line define
-DDEFAULT_SOFTWARE_DEPTH_BITS=31.
What's the story with the number 31? Is 31 bits really better
than 32?

IIRC, 32 bit Z never worked properly because of float-int
conversion
problems and such. I think I found that 31 bits worked though.
It's

been a long time...

parallel. I found that --with-osmesa-bits=32 does the trick. however
when building osmesa with 32 bits, most line rendering fails. Here
is a

, there are 80 other failed tests, the ones I examined were all the
same.

Experimenting with --with-osmesa-bits options, I've found that
using 32
causes the issue, while using 8 , 16 or not using it all doesn't.
Do you

have any idea about this?

I set DEFAULT_SOFTWARE_DEPTH_BITS=32 and tried a few demo programs and
they look OK so far.

Could you possibly create an apitrace of one of the failing cases?

about the --with-osmesa-bits=32 build.

I did -DDEFAULT_SOFTWARE_DEPTH_BITS=32

I'll see about the apitrace

I'm not actually sure what it'll do with OSMesa. But if you can get
anything and I can make a text dump of the GL calls that'll help.

apitrace crashes hard with OSMesa. Works fine when I use my ATI
drivers though. Not sure what the deal is, but looks like that may be
a dead end.

I learned from the apitrace mailing list apitrace is currently
incompatible with OSMesa. -DDEFAULT_SOFTWARE_DEPTH_BITS=32, doesn't
trigger the issue, you'll need --with-osmesa-bits=32. I filed an
official bug report so it doesn't get lost.

Thanks
Burlen

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] r600/llvm: Free binary.code/binary.config in r600_llvm_compile

radeon_llvm_compile allocates memory for binary.code, binary.config, or neither 
depending on
what's being done.

We need to make sure to free that memory after it's no longer needed.
---
 src/gallium/drivers/r600/r600_llvm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_llvm.c 
b/src/gallium/drivers/r600/r600_llvm.c
index f52ae84..084ba2a 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -745,6 +745,13 @@ unsigned r600_llvm_compile(
}
}
 
+   if (binary.code){
+   FREE(binary.code);
+   }
+   if (binary.config){
+   FREE(binary.config);
+   }
+
return r;
 }
 
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] r600/llvm: initialize radeon_llvm_binary

use memset to initialize to 0's... otherwise code_size and config_size could be 
uninitialized when read later in this method. It's also hard to do NULL checks 
on uninitialized pointers.
---
 src/gallium/drivers/r600/r600_llvm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/r600/r600_llvm.c 
b/src/gallium/drivers/r600/r600_llvm.c
index 5afe3cb..f52ae84 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -712,6 +712,7 @@ unsigned r600_llvm_compile(
const char * gpu_family = r600_llvm_gpu_string(family);
unsigned i;
 
+memset(binary, 0, sizeof(struct radeon_llvm_binary));
r = radeon_llvm_compile(mod, binary, gpu_family, dump);
 
assert(binary.code_size % 4 == 0);
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] radeon/llvm: Free elf_buffer after use

Prevents a memory leak.
---
 src/gallium/drivers/radeon/radeon_llvm_emit.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c 
b/src/gallium/drivers/radeon/radeon_llvm_emit.c
index d2e5642..e35c212 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_emit.c
+++ b/src/gallium/drivers/radeon/radeon_llvm_emit.c
@@ -176,6 +176,9 @@ unsigned radeon_llvm_compile(LLVMModuleRef M, struct 
radeon_llvm_binary *binary,
if (elf){
elf_end(elf);
}
+   if (elf_buffer){
+   FREE(elf_buffer);
+   }
LLVMDisposeMemoryBuffer(out_buffer);
LLVMDisposeTargetMachine(tm);
return 0;
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/3] More radeon/llvm memory leak fixes

With the 3 attached patches and my previous series of 6 from yesterday, I can
now launch glxgears on Evergreen without any definite memory leaks according
to: valgrind --leak-check=full glxgears

I've run this through piglit/tests/quick.tests without any regressions.

I don't have commit access, so feel free to push if you don't have any issues.

Aaron Watry (3):
  r600/llvm: initialize radeon_llvm_binary
  r600/llvm: Free binary.code/binary.config in r600_llvm_compile
  radeon/llvm: Free elf_buffer after use

 src/gallium/drivers/r600/r600_llvm.c  | 8 
 src/gallium/drivers/radeon/radeon_llvm_emit.c | 3 +++
 2 files changed, 11 insertions(+)


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/18] i965: Wire up initial support for DRI_RENDERER_QUERY extension

2013-11-07 Thread Ian Romanick

On 11/07/2013 01:33 PM, Daniel Vetter wrote:
 On Sat, Oct 12, 2013 at 12:10 AM, Ian Romanick i...@freedesktop.org wrote:
 +  /* Once a batch uses more than 75% of the maximum mappable size, we
 +   * assume that there's some fragmentation, and we start doing extra
 +   * flushing, etc.  That's the big cliff apps will care about.
 +   *
 +   * Can only map 2G onto the GPU through the GTT.
 +   */
 +  const unsigned gpu_mappable_megabytes = 2 * 1024 * 3 / 4;
 
 We have an ioctl to tell you that, since it's not really 2G on really
 old stuff. And will probably change on newer platforms. Also, using
 that ioctl allows the kernel to limit your usage in case the available
 ram is less than the virtual size of the gtt (atm we don't bother with
 that much cleverness, but probably will in the future). See
 DRM_IOCTL_I915_GEM_GET_APERTURE in libdrm (it's unfortunately not
 exposed through any libdrm function afaics.

This only does GEN4+.  i915 and earlier chips are handled in the
previous patch, which uses drmAgpSize.  Should that be used here too?

 -Daniel

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 15/18] docs: Import extension spec for GLX_MESA_query_renderer

2013-11-07 Thread Ian Romanick

On 11/07/2013 01:22 PM, Dave Airlie wrote:
 On Sat, Oct 12, 2013 at 8:10 AM, Ian Romanick i...@freedesktop.org wrote:
 From: Ian Romanick ian.d.roman...@intel.com

 The enumerated values are currently allocated from Intel's range.
 
 Some highlevel comments below,
 
 
 +GLX renderer attribute number description
 +  of values
 +---   ---
 +GLX_RENDERER_VENDOR_ID_MESA   1   PCI ID of the device vendor
 +GLX_RENDERER_DEVICE_ID_MESA   1   PCI ID of the device
 
 Okay PCI IDs might seem useful but we have a lot of situations where
 they aren't available,
 
 a) ARM devices generally don't have them
 b) nvidia generally espouse using PCI IDs in favour of a chip family
 ID they bake into the GPUs,
 nouveau doesn't even know the actual PCI IDs in userspace, we could
 find them but it does take a bit more work, like new kernel interface.

Multiple ISVs, including Wine, asked specifically for PCI IDs.  If a PCI
ID doesn't exist or can't be provided... zero for the
GLX_RENDERER_DEVICE_ID_MESA?  It should always be possible to provide a
reasonable value for GLX_RENDERER_VENDOR_ID_MESA.  I can add an issue
for that and adjust the documentation of those queries.

Does that sound reasonable?

 +
 +GLX renderer attributedescription
 +-----
 +GLX_RENDERER_VENDOR_ID_MESA   Name of the renderer provider.  This may
 +  differ from the vendor name of the
 +  underlying hardware.
 +GLX_RENDERER_DEVICE_ID_MESA   Name of the renderer.  This may differ 
 from
 +  the name of the underlying hardware (e.g.,
 +  for a software renderer).
 +
 +If attribute is not a recognized value, NULL is returned, but no GLX
 +error is generated.
 +
 +The string returned for GLX_RENDERER_VENDOR_ID_MESA will have the same
 +format as the string that would be returned by glGetString of GL_VENDOR.
 +It may, however, have a different value.
 
 Any reason for the value to be different here? Like a use case?

Vendor and device are the only ones that make any sense to be strings.
Is there any utility in getting the memory size as a string? :)

 +14) Why not make the queries from issue #14 GL functions (instead of 
 GLX)?
 +
 
 from issue 14? this is issue 14

Right... that should say issue #13.

 Dave.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965/fs: Don't perform CSE on inst HW_REG dests (unless it's null)

Commit b16b3c87 began performing CSE on CMP instructions with null
destinations. I relaxed the restrictions a bit too much, thereby
allowing CSE to be performed on instructions with, for instance, an
explicit accumulator destination.

This broke the arb_gpu_shader5/fs-imulExtended shader tests because
they emit MUL instructions with the accumulator as the destination. CSE
would instead cause the MUL to write to a GRF, which is lower precision
than the accumulator.
---
 src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
index 4793874..27541db 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
@@ -129,7 +129,8 @@ fs_visitor::opt_cse_local(bblock_t *block, exec_list *aeb)
inst = (fs_inst *) inst-next) {
 
   /* Skip some cases. */
-  if (is_expression(inst)  !inst-is_partial_write())
+  if (is_expression(inst)  !inst-is_partial_write() 
+  (inst-dst.file != HW_REG || inst-dst.is_null()))
   {
 bool found = false;
 
-- 
1.8.3.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] svga: improve loops over color buffers

Only loop over the actual number of color buffers supported, not
PIPE_MAX_COLOR_BUFS.
---
 src/gallium/drivers/svga/svga_context.c   |3 ++-
 src/gallium/drivers/svga/svga_pipe_misc.c |5 +++--
 src/gallium/drivers/svga/svga_screen.c|   10 ++
 src/gallium/drivers/svga/svga_screen.h|1 +
 src/gallium/drivers/svga/svga_state_framebuffer.c |6 --
 src/gallium/drivers/svga/svga_surface.c   |3 ++-
 6 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_context.c 
b/src/gallium/drivers/svga/svga_context.c
index 83afe79..21fe73a 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -246,6 +246,7 @@ void svga_hwtnl_flush_buffer( struct svga_context *svga,
  */ 
 void svga_surfaces_flush(struct svga_context *svga)
 {
+   struct svga_screen *svgascreen = svga_screen(svga-pipe.screen);
unsigned i;
 
/* Emit buffered drawing commands.
@@ -254,7 +255,7 @@ void svga_surfaces_flush(struct svga_context *svga)
 
/* Emit back-copy from render target view to texture.
 */
-   for (i = 0; i  PIPE_MAX_COLOR_BUFS; i++) {
+   for (i = 0; i  svgascreen-max_color_buffers; i++) {
   if (svga-curr.framebuffer.cbufs[i])
  svga_propagate_surface(svga, svga-curr.framebuffer.cbufs[i]);
}
diff --git a/src/gallium/drivers/svga/svga_pipe_misc.c 
b/src/gallium/drivers/svga/svga_pipe_misc.c
index f1c007b..0fd92428c 100644
--- a/src/gallium/drivers/svga/svga_pipe_misc.c
+++ b/src/gallium/drivers/svga/svga_pipe_misc.c
@@ -52,11 +52,12 @@ static void svga_set_polygon_stipple( struct pipe_context 
*pipe,
 
 void svga_cleanup_framebuffer(struct svga_context *svga)
 {
+   struct svga_screen *svgascreen = svga_screen(svga-pipe.screen);
struct pipe_framebuffer_state *curr = svga-curr.framebuffer;
struct pipe_framebuffer_state *hw = svga-state.hw_clear.framebuffer;
-   int i;
+   unsigned i;
 
-   for (i = 0; i  PIPE_MAX_COLOR_BUFS; i++) {
+   for (i = 0; i  svgascreen-max_color_buffers; i++) {
   pipe_surface_reference(curr-cbufs[i], NULL);
   pipe_surface_reference(hw-cbufs[i], NULL);
}
diff --git a/src/gallium/drivers/svga/svga_screen.c 
b/src/gallium/drivers/svga/svga_screen.c
index cc6214d..3c013ea 100644
--- a/src/gallium/drivers/svga/svga_screen.c
+++ b/src/gallium/drivers/svga/svga_screen.c
@@ -154,10 +154,7 @@ svga_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
case PIPE_CAP_TGSI_TEXCOORD:
   return 0;
case PIPE_CAP_MAX_RENDER_TARGETS:
-  /* The SVGA3D device always supports 4 targets at this time, regardless
-   * of what querying SVGA3D_DEVCAP_MAX_RENDER_TARGETS might return.
-   */
-  return 4;
+  return svgascreen-max_color_buffers;
case PIPE_CAP_OCCLUSION_QUERY:
   return 1;
case PIPE_CAP_QUERY_TIME_ELAPSED:
@@ -661,6 +658,11 @@ svga_screen_create(struct svga_winsys_screen *sws)
   svgascreen-maxPointSize = MIN2(result.f, 80.0f);
}
 
+   /* The SVGA3D device always supports 4 targets at this time, regardless
+* of what querying SVGA3D_DEVCAP_MAX_RENDER_TARGETS might return.
+*/
+   svgascreen-max_color_buffers = 4;
+
pipe_mutex_init(svgascreen-tex_mutex);
pipe_mutex_init(svgascreen-swc_mutex);
 
diff --git a/src/gallium/drivers/svga/svga_screen.h 
b/src/gallium/drivers/svga/svga_screen.h
index 0606147..517a3fa 100644
--- a/src/gallium/drivers/svga/svga_screen.h
+++ b/src/gallium/drivers/svga/svga_screen.h
@@ -48,6 +48,7 @@ struct svga_screen
SVGA3dHardwareVersion hw_version;
 
float maxPointSize;
+   unsigned max_color_buffers;
 
struct {
   boolean force_level_surface_view;
diff --git a/src/gallium/drivers/svga/svga_state_framebuffer.c 
b/src/gallium/drivers/svga/svga_state_framebuffer.c
index 4254404..fb041a3 100644
--- a/src/gallium/drivers/svga/svga_state_framebuffer.c
+++ b/src/gallium/drivers/svga/svga_state_framebuffer.c
@@ -54,6 +54,7 @@ static enum pipe_error
 emit_framebuffer( struct svga_context *svga,
   unsigned dirty )
 {
+   struct svga_screen *svgascreen = svga_screen(svga-pipe.screen);
const struct pipe_framebuffer_state *curr = svga-curr.framebuffer;
struct pipe_framebuffer_state *hw = svga-state.hw_clear.framebuffer;
boolean reemit = svga-rebind.rendertargets;
@@ -65,7 +66,7 @@ emit_framebuffer( struct svga_context *svga,
 * dirty, to ensure that the resources are paged in.
 */

-   for(i = 0; i  PIPE_MAX_COLOR_BUFS; ++i) {
+   for (i = 0; i  svgascreen-max_color_buffers; i++) {
   if (curr-cbufs[i] != hw-cbufs[i] ||
   (reemit  hw-cbufs[i])) {
  if (svga-curr.nr_fbs++  MAX_RT_PER_BATCH)
@@ -118,13 +119,14 @@ emit_framebuffer( struct svga_context *svga,
 enum pipe_error
 svga_reemit_framebuffer_bindings(struct svga_context *svga)
 {
+   struct svga_screen *svgascreen = svga_screen(svga-pipe.screen);
struct pipe_framebuffer_state *hw =

[Mesa-dev] [PATCH 2/3] svga: document magic number of 8 render targets per batch

Grab the comments from commit message b84b7f19dfdc0 to explain
what the code is doing.
---
 src/gallium/drivers/svga/svga_state_framebuffer.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/svga/svga_state_framebuffer.c 
b/src/gallium/drivers/svga/svga_state_framebuffer.c
index 8232c32..4254404 100644
--- a/src/gallium/drivers/svga/svga_state_framebuffer.c
+++ b/src/gallium/drivers/svga/svga_state_framebuffer.c
@@ -33,6 +33,18 @@
 #include svga_debug.h
 
 
+/*
+ * flush our command buffer after the 8th distinct render target
+ *
+ * This helps improve the surface cache behaviour in the face of the
+ * large number of single-use render targets generated by EXA and the xorg
+ * state tracker.  Without this we can reference hundreds of individual
+ * render targets from a command buffer, which leaves little scope for
+ * sharing or reuse of those targets.
+ */
+#define MAX_RT_PER_BATCH 8
+
+
 /***
  * Hardware state update
  */
@@ -56,7 +68,7 @@ emit_framebuffer( struct svga_context *svga,
for(i = 0; i  PIPE_MAX_COLOR_BUFS; ++i) {
   if (curr-cbufs[i] != hw-cbufs[i] ||
   (reemit  hw-cbufs[i])) {
- if (svga-curr.nr_fbs++  8)
+ if (svga-curr.nr_fbs++  MAX_RT_PER_BATCH)
 return PIPE_ERROR_OUT_OF_MEMORY;
 
  ret = SVGA3D_SetRenderTarget(svga-swc, SVGA3D_RT_COLOR0 + i, 
curr-cbufs[i]);
-- 
1.7.10.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] util: set all unused cbufs to NULL in util_copy_framebuffer_state()

This helps fix an issue in the svga driver, and is just safer all-around.
---
 src/gallium/auxiliary/util/u_framebuffer.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/util/u_framebuffer.c 
b/src/gallium/auxiliary/util/u_framebuffer.c
index 7803ec6..f84485d 100644
--- a/src/gallium/auxiliary/util/u_framebuffer.c
+++ b/src/gallium/auxiliary/util/u_framebuffer.c
@@ -88,7 +88,8 @@ util_copy_framebuffer_state(struct pipe_framebuffer_state 
*dst,
for (i = 0; i  src-nr_cbufs; i++)
   pipe_surface_reference(dst-cbufs[i], src-cbufs[i]);
 
-   for (i = src-nr_cbufs; i  dst-nr_cbufs; i++)
+   /* Set remaining dest cbuf pointers to NULL */
+   for ( ; i  Elements(dst-cbufs); i++)
   pipe_surface_reference(dst-cbufs[i], NULL);
 
dst-nr_cbufs = src-nr_cbufs;
-- 
1.7.10.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH demos 3/3] Perf: teximage_enh Add command line options


On 11/07/2013 02:16 PM, Courtney Goeltzenleuchter wrote:

texture_enh allows the user to specify source, internal formats
and mipmap or not. This provides a quick way to get feedback
on texture upload related performance tuning.
Texture image data is initialized and aligned to 64 byte bounary.
Uses Mesa demos Perf library to do the measurements.




It looks like the previous patch in the series added the shell script 
which passes command line params.  Shouldn't this patch come before that 
feature?


I'm not too concerned though.

Acked-by: Brian Paul bri...@vmware.com


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH demos 1/3] Perf: Add command line capabilities to perf framework


On 11/07/2013 02:16 PM, Courtney Goeltzenleuchter wrote:

These were entirely interactive. Adding ability to pass in
command line arguments allows future tests to include
automated test capabilities.

Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
  src/perf/copytex.c  | 2 +-
  src/perf/drawoverhead.c | 2 +-
  src/perf/fbobind.c  | 2 +-
  src/perf/fill.c | 2 +-
  src/perf/genmipmap.c| 2 +-
  src/perf/glmain.c   | 2 +-
  src/perf/glmain.h   | 2 +-
  src/perf/glslstateschange.c | 2 +-
  src/perf/readpixels.c   | 2 +-
  src/perf/swapbuffers.c  | 2 +-
  src/perf/teximage.c | 2 +-
  src/perf/vbo.c  | 2 +-
  src/perf/vertexrate.c   | 2 +-
  13 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/src/perf/copytex.c b/src/perf/copytex.c
index f7a6b8a..376d699 100644
--- a/src/perf/copytex.c
+++ b/src/perf/copytex.c
@@ -57,7 +57,7 @@ static const struct vertex vertices[1] = {

  /** Called from test harness/main */
  void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
  {
 const GLenum filter = GL_LINEAR;
 GLenum stat;
diff --git a/src/perf/drawoverhead.c b/src/perf/drawoverhead.c
index f75c9bb..06a815f 100644
--- a/src/perf/drawoverhead.c
+++ b/src/perf/drawoverhead.c
@@ -55,7 +55,7 @@ static const struct vertex vertices[4] = {

  /** Called from test harness/main */
  void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
  {
 /* setup VBO w/ vertex data */
 glGenBuffersARB(1, VBO);
diff --git a/src/perf/fbobind.c b/src/perf/fbobind.c
index fb52a93..4206294 100644
--- a/src/perf/fbobind.c
+++ b/src/perf/fbobind.c
@@ -56,7 +56,7 @@ static const struct vertex vertices[1] = {

  /** Called from test harness/main */
  void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
  {
 const GLenum filter = GL_LINEAR;
 GLenum stat;
diff --git a/src/perf/fill.c b/src/perf/fill.c
index 279f2b5..70cb64b 100644
--- a/src/perf/fill.c
+++ b/src/perf/fill.c
@@ -120,7 +120,7 @@ static GLuint ShaderProg1, ShaderProg2;

  /** Called from test harness/main */
  void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
  {
 GLint u;

diff --git a/src/perf/genmipmap.c b/src/perf/genmipmap.c
index 20e2fa3..a37f7ab 100644
--- a/src/perf/genmipmap.c
+++ b/src/perf/genmipmap.c
@@ -52,7 +52,7 @@ static const struct vertex vertices[1] = {

  /** Called from test harness/main */
  void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
  {
 if (!PerfExtensionSupported(GL_ARB_framebuffer_object)) {
printf(Sorry, this test requires GL_ARB_framebuffer_object\n);
diff --git a/src/perf/glmain.c b/src/perf/glmain.c
index 81c1173..3bc18ad 100644
--- a/src/perf/glmain.c
+++ b/src/perf/glmain.c
@@ -258,7 +258,7 @@ main(int argc, char *argv[])
 glutSpecialFunc(SpecialKey);
 glutDisplayFunc(Draw);
 glutIdleFunc(Idle);
-   PerfInit();
+   PerfInit(argc, argv);
 glutMainLoop();
 return 0;
  }
diff --git a/src/perf/glmain.h b/src/perf/glmain.h
index d9bcd5f..18cde08 100644
--- a/src/perf/glmain.h
+++ b/src/perf/glmain.h
@@ -56,7 +56,7 @@ PerfExtensionSupported(const char *ext);
  /** Test programs must implement these functions **/

  extern void
-PerfInit(void);
+PerfInit(int argc, char *argv[]);

  extern void
  PerfNextRound(void);
diff --git a/src/perf/glslstateschange.c b/src/perf/glslstateschange.c
index 7422b78..83f8d6b 100644
--- a/src/perf/glslstateschange.c
+++ b/src/perf/glslstateschange.c
@@ -257,7 +257,7 @@ InitPrograms(void)
  }

  void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
  {
 if (!ShadersSupported())
exit(1);
diff --git a/src/perf/readpixels.c b/src/perf/readpixels.c
index ac7dc42..1e777a6 100644
--- a/src/perf/readpixels.c
+++ b/src/perf/readpixels.c
@@ -51,7 +51,7 @@ static GLvoid *ReadBuffer;

  /** Called from test harness/main */
  void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
  {
 /* setup VBO */
 glGenBuffersARB(1, VBO);
diff --git a/src/perf/swapbuffers.c b/src/perf/swapbuffers.c
index 63c7fc0..24436f7 100644
--- a/src/perf/swapbuffers.c
+++ b/src/perf/swapbuffers.c
@@ -50,7 +50,7 @@ static const struct vertex vertices[4] = {

  /** Called from test harness/main */
  void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
  {
 /* setup VBO w/ vertex data */
 glGenBuffersARB(1, VBO);
diff --git a/src/perf/teximage.c b/src/perf/teximage.c
index a3005d0..88316f3 100644
--- a/src/perf/teximage.c
+++ b/src/perf/teximage.c
@@ -73,7 +73,7 @@ static const struct vertex vertices[1] = {

  /** Called from test harness/main */
  void
-PerfInit(void)
+PerfInit(int argc, char *argv[])
  {
 /* setup VBO w/ vertex data */
 glGenBuffersARB(1, VBO);
diff --git a/src/perf/vbo.c b/src/perf/vbo.c
index b326c05..6a0d313 100644
--- a/src/perf/vbo.c
+++ b/src/perf/vbo.c
@@ -51,7 +51,7 @@ static const GLfloat Vertex0[2] = { 0.0, 0.0 };

  /** Called from test harness/main */
  void
-PerfInit(void)
+PerfInit(int argc, char

Re: [Mesa-dev] [PATCH demos 2/3] Perf: Add test to measure texture upload


On 11/07/2013 02:16 PM, Courtney Goeltzenleuchter wrote:

Needed test to measure texture upload speed under a variety
of modes (mipmap, source format, internal format, size, etc.)
This new test has an interactive run mode like the other Mesa
Perf tests but also includes command line options to make
it automatable.
Fix up code formatting.

Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
  src/perf/CMakeLists.txt|   1 +
  src/perf/Makefile.am   |   1 +
  src/perf/bench_glTexImage2D.sh |  13 ++
  src/perf/teximage_enh.README   |  10 ++
  src/perf/teximage_enh.c| 391 +


What does enh mean?  Maybe you could find something a bit more obvious?



  5 files changed, 416 insertions(+)
  create mode 100755 src/perf/bench_glTexImage2D.sh
  create mode 100644 src/perf/teximage_enh.README
  create mode 100644 src/perf/teximage_enh.c

diff --git a/src/perf/CMakeLists.txt b/src/perf/CMakeLists.txt
index 68b6875..ded 100644
--- a/src/perf/CMakeLists.txt
+++ b/src/perf/CMakeLists.txt
@@ -28,6 +28,7 @@ set (targets
readpixels
swapbuffers
teximage
+   teximage_enh
vbo
vertexrate
  )
diff --git a/src/perf/Makefile.am b/src/perf/Makefile.am
index 5363c58..1cc5c43 100644
--- a/src/perf/Makefile.am
+++ b/src/perf/Makefile.am
@@ -51,6 +51,7 @@ bin_PROGRAMS = \
readpixels \
swapbuffers \
teximage \
+   teximage_enh \
vbo \
vertexrate \
glslstateschange
diff --git a/src/perf/bench_glTexImage2D.sh b/src/perf/bench_glTexImage2D.sh
new file mode 100755
index 000..c63a251
--- /dev/null
+++ b/src/perf/bench_glTexImage2D.sh
@@ -0,0 +1,13 @@
+#!/bin/bash
+./teximage_enh --width 1024 --height 1024 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle full --test TexImage
+./teximage_enh --width 1024 --height 1024 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data --test TexImage
+./teximage_enh --width  512 --height  512 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data --test TexImage
+./teximage_enh --width  512 --height  512 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data --test TexImage
+./teximage_enh --width  256 --height  256 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data --test TexImage
+./teximage_enh --width  256 --height  256 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data --test TexImage
+./teximage_enh --width 1024 --height 1024 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data --test 
TexImage_Mipmap
+./teximage_enh --width 1024 --height 1024 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data --test 
TexImage_Mipmap
+./teximage_enh --width  512 --height  512 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data --test 
TexImage_Mipmap
+./teximage_enh --width  512 --height  512 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data --test 
TexImage_Mipmap
+./teximage_enh --width  256 --height  256 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGBA --csvstyle data --test 
TexImage_Mipmap
+./teximage_enh --width  256 --height  256 --type GL_UNSIGNED_BYTE --format 
GL_RGBA --texelsize 4 --internalformat GL_RGB --csvstyle data --test 
TexImage_Mipmap
diff --git a/src/perf/teximage_enh.README b/src/perf/teximage_enh.README
new file mode 100644
index 000..44e8aea
--- /dev/null
+++ b/src/perf/teximage_enh.README
@@ -0,0 +1,10 @@
+glTexImage2D benchmark
+  - executable name:  teximage_enh
+  - modified files:  CMakeLists.txt  Makefile.am
+  - new files:
+ teximage_enh.c - code
+ bench_glTexImage2D.sh
+direct run command:  ./teximage_enh
+
+script usage:./test_glTexImage2D.sh
+
diff --git a/src/perf/teximage_enh.c b/src/perf/teximage_enh.c
new file mode 100644
index 000..9bb3944
--- /dev/null
+++ b/src/perf/teximage_enh.c
@@ -0,0 +1,391 @@
+/*
+ * Copyright (C) 2009  VMware, Inc.  All Rights Reserved.


Maybe add your own LunarG copyright line.



+ *
+ * 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 shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE

[Mesa-dev] [PATCH] i965: Delete #define's and use local variables inside function

2013-11-07 Thread Anuj Phogat

X_f, Y_f, Xp_f, Yp_f variables are used just inside
translate_dst_to_src().So, they can be defined just as
local variables.

Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
I think I missed this change during the review of my single
sample scaled blit patches.

 src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 7e436f7..d54b926 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -1403,10 +1403,6 @@ brw_blorp_blit_program::kill_if_outside_dst_rect()
brw_pop_insn_state(func);
 }
 
-#define X_f retype(X, BRW_REGISTER_TYPE_F)
-#define Y_f retype(Y, BRW_REGISTER_TYPE_F)
-#define Xp_f retype(Xp, BRW_REGISTER_TYPE_F)
-#define Yp_f retype(Yp, BRW_REGISTER_TYPE_F)
 /**
  * Emit code to translate from destination (X, Y) coordinates to source (X, Y)
  * coordinates.
@@ -1414,6 +1410,11 @@ brw_blorp_blit_program::kill_if_outside_dst_rect()
 void
 brw_blorp_blit_program::translate_dst_to_src()
 {
+   struct brw_reg X_f = retype(X, BRW_REGISTER_TYPE_F);
+   struct brw_reg Y_f = retype(Y, BRW_REGISTER_TYPE_F);
+   struct brw_reg Xp_f = retype(Xp, BRW_REGISTER_TYPE_F);
+   struct brw_reg Yp_f = retype(Yp, BRW_REGISTER_TYPE_F);
+
brw_set_compression_control(func, BRW_COMPRESSION_COMPRESSED);
/* Move the UD coordinates to float registers. */
brw_MOV(func, Xp_f, X);
@@ -1489,10 +1490,6 @@ brw_blorp_blit_program::clamp_tex_coords(struct brw_reg 
regX,
brw_MOV(func, regY, clampY1);
brw_set_predicate_control(func, BRW_PREDICATE_NONE);
 }
-#undef X_f
-#undef Y_f
-#undef Xp_f
-#undef Yp_f
 
 /**
  * Emit code to transform the X and Y coordinates as needed for blending
-- 
1.8.1.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 71363] line rendering with --with-osmesa-bits=32

https://bugs.freedesktop.org/show_bug.cgi?id=71363

--- Comment #4 from Brian Paul bri...@vmware.com ---
I'm guessing it's a fragment Z interpolation issue.  Can you provide some info
about:
* does the test use GL_DEPTH_TEST?
* Any calls to glDepthRange()?
* What are the vertex Z values (zeros?)
* Using glPolygonOffset?

-- 
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 06/10] mesa/dri: Move context flag validation down into the drivers

On 10/29/2013 06:07 PM, Ian Romanick wrote:
 From: Ian Romanick ian.d.roman...@intel.com
 
 Soon some drivers will support a different set of flags than other
 drivers.  If some flags have to be filtered in the driver, we might as
 well filter all of them in the driver.

I'm not sure that I agree, but I don't disagree enough to object.

 The changes in nouveau use tabs because nouveau seems to have it's own
 indentation rules.
 
 Signed-off-by: Ian Romanick ian.d.roman...@intel.com
 ---
  src/gallium/state_trackers/dri/common/dri_context.c | 5 +
  src/mesa/drivers/dri/i915/intel_screen.c| 5 +
  src/mesa/drivers/dri/i965/brw_context.c | 5 +
  src/mesa/drivers/dri/nouveau/nouveau_context.c  | 7 ---
  src/mesa/drivers/dri/r200/r200_context.c| 7 ---
  src/mesa/drivers/dri/radeon/radeon_context.c| 7 ---
  6 files changed, 27 insertions(+), 9 deletions(-)
 
 diff --git a/src/gallium/state_trackers/dri/common/dri_context.c 
 b/src/gallium/state_trackers/dri/common/dri_context.c
 index 5cfd1ed..bf986c2 100644
 --- a/src/gallium/state_trackers/dri/common/dri_context.c
 +++ b/src/gallium/state_trackers/dri/common/dri_context.c
 @@ -101,6 +101,11 @@ dri_create_context(gl_api api, const struct gl_config * 
 visual,
goto fail;
 }
  
 +   if (flags  ~(__DRI_CTX_FLAG_DEBUG | __DRI_CTX_FLAG_FORWARD_COMPATIBLE)) {
 +  *error = __DRI_CTX_ERROR_UNKNOWN_FLAG;
 +  return NULL;
 +   }

This function returns a GLboolean, not a pointer.  I think this should
be goto fail to match all the other cases.

Presumably this generates a compiler warning.

 +
 if (notify_reset) {
*error = __DRI_CTX_ERROR_UNKNOWN_ATTRIBUTE;
goto fail;
 diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
 b/src/mesa/drivers/dri/i915/intel_screen.c
 index a4b40b7..9a1b378 100644
 --- a/src/mesa/drivers/dri/i915/intel_screen.c
 +++ b/src/mesa/drivers/dri/i915/intel_screen.c
 @@ -917,6 +917,11 @@ intelCreateContext(gl_api api,
 __DRIscreen *sPriv = driContextPriv-driScreenPriv;
 struct intel_screen *intelScreen = sPriv-driverPrivate;
  
 +   if (flags  ~__DRI_CTX_FLAG_DEBUG) {
 +  *error = __DRI_CTX_ERROR_UNKNOWN_FLAG;
 +  return false;
 +   }
 +
 if (notify_reset) {
*error = __DRI_CTX_ERROR_UNKNOWN_ATTRIBUTE;
return false;
 diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
 b/src/mesa/drivers/dri/i965/brw_context.c
 index 474c1ee..2bb52b6 100644
 --- a/src/mesa/drivers/dri/i965/brw_context.c
 +++ b/src/mesa/drivers/dri/i965/brw_context.c
 @@ -516,6 +516,11 @@ brwCreateContext(gl_api api,
 struct dd_function_table functions;
 struct gl_config visual;
  
 +   if (flags  ~(__DRI_CTX_FLAG_DEBUG | __DRI_CTX_FLAG_FORWARD_COMPATIBLE)) {
 +  *dri_ctx_error = __DRI_CTX_ERROR_UNKNOWN_FLAG;
 +  return NULL;

Again, this should not be NULL.  It should be return false.

 +   }
 +
 if (notify_reset) {
*dri_ctx_error = __DRI_CTX_ERROR_UNKNOWN_ATTRIBUTE;
return false;
 diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c 
 b/src/mesa/drivers/dri/nouveau/nouveau_context.c
 index a7f14b5..bdc0078 100644
 --- a/src/mesa/drivers/dri/nouveau/nouveau_context.c
 +++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c
 @@ -62,9 +62,10 @@ nouveau_context_create(gl_api api,
   struct nouveau_context *nctx;
   struct gl_context *ctx;
  
 - /* API and flag filtering is handled in dri2CreateContextAttribs.
 -  */
 - (void) flags;
 + if (flags  ~__DRI_CTX_FLAG_DEBUG) {
 + *error = __DRI_CTX_ERROR_UNKNOWN_FLAG;
 + return false;
 +}

The line with } is indented using spaces rather than tabs, which is
inconsistent.

  
   if (notify_reset) {
   *error = __DRI_CTX_ERROR_UNKNOWN_ATTRIBUTE;
 diff --git a/src/mesa/drivers/dri/r200/r200_context.c 
 b/src/mesa/drivers/dri/r200/r200_context.c
 index 58c300c..d4e9ca8 100644
 --- a/src/mesa/drivers/dri/r200/r200_context.c
 +++ b/src/mesa/drivers/dri/r200/r200_context.c
 @@ -213,9 +213,10 @@ GLboolean r200CreateContext( gl_api api,
 int i;
 int tcl_mode;
  
 -   /* Flag filtering is handled in dri2CreateContextAttribs.
 -*/
 -   (void) flags;
 +   if (flags  ~__DRI_CTX_FLAG_DEBUG) {
 +  *error = __DRI_CTX_ERROR_UNKNOWN_FLAG;
 +  return false;
 +   }
  
 if (notify_reset) {
*error = __DRI_CTX_ERROR_UNKNOWN_ATTRIBUTE;
 diff --git a/src/mesa/drivers/dri/radeon/radeon_context.c 
 b/src/mesa/drivers/dri/radeon/radeon_context.c
 index c2200d7..76bfe55 100644
 --- a/src/mesa/drivers/dri/radeon/radeon_context.c
 +++ b/src/mesa/drivers/dri/radeon/radeon_context.c
 @@ -180,9 +180,10 @@ r100CreateContext( gl_api api,
 int i;
 int tcl_mode, fthrottle_mode;
  
 -   /* Flag filtering is handled in dri2CreateContextAttribs.
 -*/
 -   (void) flags;
 +   if (flags  ~__DRI_CTX_FLAG_DEBUG) {
 +  *error = __DRI_CTX_ERROR_UNKNOWN_FLAG;
 +  return false;
 +

Re: [Mesa-dev] [PATCH] mesa: Add API debug logging to TexStorage


On 11/05/2013 02:25 PM, Courtney Goeltzenleuchter wrote:

Give glTexStorage* equivalent debug logging to glTexImage*.

Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
  src/mesa/main/texstorage.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
index 7bd8652..84b8f82 100644
--- a/src/mesa/main/texstorage.c
+++ b/src/mesa/main/texstorage.c
@@ -365,6 +365,13 @@ texstorage(GLuint dims, GLenum target, GLsizei levels, 
GLenum internalformat,

 GET_CURRENT_CONTEXT(ctx);

+   if (MESA_VERBOSE  (VERBOSE_API|VERBOSE_TEXTURE))
+  _mesa_debug(ctx, glTexStorage%uD %s %d %s %d %d %d\n,
+  dims,
+  _mesa_lookup_enum_by_nr(target), levels,
+  _mesa_lookup_enum_by_nr(internalformat),
+  width, height, depth);
+
 if (tex_storage_error_check(ctx, dims, target, levels,
 internalformat, width, height, depth)) {
return; /* error was recorded */



Reviewed-by: Brian Paul bri...@vmware.com

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/10] mesa/dri: Add basic plumbing for GLX_ARB_robustness reset notification strategy