[Mesa-dev] [PATCH] i965/fs: Make the first pre-allocation heuristic be the post heuristic.

[Eric Anholt]

I recently made us try two different things that tried to reduce register
pressure so that we would be more likely to allocate successfully.  But
now that we have the logic for trying two, we can make the first thing we
try be the normal, not-prioritizing-register-pressure heuristic.

This means one less scheduling pass in the common case of that heuristic
not producing spills, plus the best schedule we know how to produce, if
that one happens to succeed.  This is important, because our register
allocation produces a lot of possibly avoidable dependencies for the
post-register-allocation schedule, despite ra_set_allocate_round_robin().

GLB2.7: 1.04127% +/- 0.732461% fps improvement (n=31)
nexuiz: No difference (n=5)
lightsmark: 0.838512% +/- 0.300147% fps improvement (n=86)
minecraft apitrace: No difference (n=15)
---
 src/mesa/drivers/dri/i965/brw_fs.cpp   | 62 ++
 .../drivers/dri/i965/brw_schedule_instructions.cpp |  4 +-
 src/mesa/drivers/dri/i965/brw_shader.h |  1 +
 3 files changed, 44 insertions(+), 23 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 8b3f8df..dbe7503 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3190,6 +3190,7 @@ fs_visitor::run()
 {
sanity_param_count = fp->Base.Parameters->NumParameters;
uint32_t orig_nr_params = c->prog_data.nr_params;
+   bool allocated_without_spills;
 
assign_binding_table_offsets();
 
@@ -3273,27 +3274,45 @@ fs_visitor::run()
   assign_curb_setup();
   assign_urb_setup();
 
-  schedule_instructions(SCHEDULE_PRE_NON_LIFO);
+  static enum instruction_scheduler_mode pre_modes[] = {
+ SCHEDULE_PRE,
+ SCHEDULE_PRE_NON_LIFO,
+ SCHEDULE_PRE_LIFO,
+  };
 
-  if (0)
-assign_regs_trivial();
-  else {
- if (!assign_regs(false)) {
-/* Try a non-spilling register allocation again with a different
- * scheduling heuristic.
- */
-schedule_instructions(SCHEDULE_PRE_LIFO);
-if (!assign_regs(false)) {
-   if (dispatch_width == 16) {
-  fail("Failure to register allocate.  Reduce number of "
-   "live scalar values to avoid this.");
-   } else {
-  while (!assign_regs(true)) {
- if (failed)
-break;
-  }
-   }
-}
+  /* Try each scheduling heuristic to see if it can successfully register
+   * allocate without spilling.  They should be ordered by decreasing
+   * performance but increasing likelihood of allocating.
+   */
+  for (unsigned i = 0; i < ARRAY_SIZE(pre_modes); i++) {
+ schedule_instructions(pre_modes[i]);
+
+ if (0) {
+assign_regs_trivial();
+allocated_without_spills = true;
+ } else {
+allocated_without_spills = assign_regs(false);
+ }
+ if (allocated_without_spills)
+break;
+  }
+
+  if (!allocated_without_spills) {
+ /* We assume that any spilling is worse than just dropping back to
+  * SIMD8.  There's probably actually some intermediate point where
+  * SIMD16 with a couple of spills is still better.
+  */
+ if (dispatch_width == 16) {
+fail("Failure to register allocate.  Reduce number of "
+ "live scalar values to avoid this.");
+ }
+
+ /* Since we're out of heuristics, just go spill registers until we
+  * get an allocation.
+  */
+ while (!assign_regs(true)) {
+if (failed)
+   break;
  }
   }
}
@@ -3308,7 +3327,8 @@ fs_visitor::run()
if (failed)
   return false;
 
-   schedule_instructions(SCHEDULE_POST);
+   if (!allocated_without_spills)
+  schedule_instructions(SCHEDULE_POST);
 
if (dispatch_width == 8) {
   c->prog_data.reg_blocks = brw_register_blocks(grf_used);
diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp 
b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
index a4fae0d..a40a46a 100644
--- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
+++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
@@ -1140,10 +1140,10 @@ 
fs_instruction_scheduler::choose_instruction_to_schedule()
 {
schedule_node *chosen = NULL;
 
-   if (post_reg_alloc) {
+   if (mode == SCHEDULE_PRE || mode == SCHEDULE_POST) {
   int chosen_time = 0;
 
-  /* Of the instructions closest ready to execute or the closest to
+  /* Of the instructions ready to execute or the closest to
* being ready, choose the oldest one.
*/
   foreach_list(node, &instructions) {
diff --git a/src/mesa/drivers/dri/i965/brw_shader.h 
b/src/mesa/drivers/dri/i965/brw_shader.h
index aba24c5..34779ff 100644
---

[Mesa-dev] [PATCH] glsl: Use more portable bash invocation construct.

[Vinson Lee]

Fixes 'make check' on distros where bash is not at /bin/bash.

Signed-off-by: Vinson Lee 
---
 src/glsl/tests/lower_jumps/create_test_cases.py | 2 +-
 src/glsl/tests/lower_jumps/lower_breaks_1.opt_test  | 2 +-
 src/glsl/tests/lower_jumps/lower_breaks_2.opt_test  | 2 +-
 src/glsl/tests/lower_jumps/lower_breaks_3.opt_test  | 2 +-
 src/glsl/tests/lower_jumps/lower_breaks_4.opt_test  | 2 +-
 src/glsl/tests/lower_jumps/lower_breaks_5.opt_test  | 2 +-
 src/glsl/tests/lower_jumps/lower_breaks_6.opt_test  | 2 +-
 src/glsl/tests/lower_jumps/lower_guarded_conditional_break.opt_test | 2 +-
 src/glsl/tests/lower_jumps/lower_pulled_out_jump.opt_test   | 2 +-
 src/glsl/tests/lower_jumps/lower_returns_1.opt_test | 2 +-
 src/glsl/tests/lower_jumps/lower_returns_2.opt_test | 2 +-
 src/glsl/tests/lower_jumps/lower_returns_3.opt_test | 2 +-
 src/glsl/tests/lower_jumps/lower_returns_4.opt_test | 2 +-
 src/glsl/tests/lower_jumps/lower_returns_main_false.opt_test| 2 +-
 src/glsl/tests/lower_jumps/lower_returns_main_true.opt_test | 2 +-
 src/glsl/tests/lower_jumps/lower_returns_sub_false.opt_test | 2 +-
 src/glsl/tests/lower_jumps/lower_returns_sub_true.opt_test  | 2 +-
 src/glsl/tests/lower_jumps/lower_unified_returns.opt_test   | 2 +-
 src/glsl/tests/lower_jumps/remove_continue_at_end_of_loop.opt_test  | 2 +-
 .../lower_jumps/return_non_void_at_end_of_loop_lower_nothing.opt_test   | 2 +-
 .../lower_jumps/return_non_void_at_end_of_loop_lower_return.opt_test| 2 +-
 .../return_non_void_at_end_of_loop_lower_return_and_break.opt_test  | 2 +-
 .../tests/lower_jumps/return_void_at_end_of_loop_lower_nothing.opt_test | 2 +-
 .../tests/lower_jumps/return_void_at_end_of_loop_lower_return.opt_test  | 2 +-
 .../return_void_at_end_of_loop_lower_return_and_break.opt_test  | 2 +-
 src/glsl/tests/optimization-test| 2 +-
 26 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/src/glsl/tests/lower_jumps/create_test_cases.py 
b/src/glsl/tests/lower_jumps/create_test_cases.py
index fbc6f0a..9974681 100644
--- a/src/glsl/tests/lower_jumps/create_test_cases.py
+++ b/src/glsl/tests/lower_jumps/create_test_cases.py
@@ -291,7 +291,7 @@ def create_test_case(doc_string, input_sexp, expected_sexp, 
test_name,
 args = ['../../glsl_test', 'optpass', '--quiet', '--input-ir', 
optimization]
 test_file = '{0}.opt_test'.format(test_name)
 with open(test_file, 'w') as f:
-f.write('#!/bin/bash\n#\n# This file was generated by 
create_test_cases.py.\n#\n')
+f.write('#!/usr/bin/env bash\n#\n# This file was generated by 
create_test_cases.py.\n#\n')
 f.write(doc_string)
 f.write('{0} 

[Mesa-dev] [PATCH] glapi: Do not include dlfcn.h on Windows.

[Vinson Lee]

This patch fixes this MinGW build error.

  CC glapi_gentable.lo
glapi_gentable.c:47:19: fatal error: dlfcn.h: No such file or directory

Signed-off-by: Vinson Lee 
---
 src/mapi/glapi/gen/gl_gentable.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mapi/glapi/gen/gl_gentable.py 
b/src/mapi/glapi/gen/gl_gentable.py
index 5c35271..20bfc34 100644
--- a/src/mapi/glapi/gen/gl_gentable.py
+++ b/src/mapi/glapi/gen/gl_gentable.py
@@ -50,7 +50,9 @@ header = """/* GLXEXT is the define used in the xserver when 
the GLX extension i
 #include 
 #endif
 
+#ifndef _WIN32
 #include 
+#endif
 #include 
 #include 
 
-- 
1.8.1.2

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

[Mesa-dev] [PATCH] glsl: Link glcpp with math library.

[Vinson Lee]

This patch fixes this build error with Oracle Solaris Studio.

libtool: link: /opt/solarisstudio12.3/bin/cc -g -o glcpp/glcpp glcpp.o 
prog_hash_table.o  ./.libs/libglcpp.a
Undefined   first referenced
 symbol in file
sqrtprog_hash_table.o

Signed-off-by: Vinson Lee 
---
 src/glsl/Makefile.am |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index cbf253c..05b6759 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
@@ -93,7 +93,9 @@ libglcpp_la_SOURCES = \
 glcpp_glcpp_SOURCES =  \
glcpp/glcpp.c   \
$(top_srcdir)/src/mesa/program/prog_hash_table.c
-glcpp_glcpp_LDADD = libglcpp.la
+glcpp_glcpp_LDADD =\
+   libglcpp.la \
+   -lm
 
 libglsl_la_LIBADD = libglcpp.la
 libglsl_la_SOURCES =   \
-- 
1.7.9.2

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

[Mesa-dev] [PATCH] gallivm: Ignore unknown file type in non-debug builds.

[Vinson Lee]

Fixes "Uninitialized pointer read" defect reported by Coverity.

Signed-off-by: Vinson Lee 
---
 src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c 
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 37f7a56..6d8dc8c 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -2410,6 +2410,7 @@ emit_dump_file(struct lp_build_tgsi_soa_context *bld,
 res = LLVMBuildLoad(builder, reg_ptr, "");
  } else {
 assert(0);
+continue;
  }
 
  emit_dump_reg(gallivm, file, index, chan, res);
-- 
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/2] mesa: Fix texture target validation for glFramebufferTexture()

[Paul Berry]

Previously we were using the code path for validating
glFramebufferTextureLayer().  But glFramebufferTexture() allows
additional texture types.

Fixes piglit tests:
- spec/!OpenGL 3.2/layered-rendering/gl-layer-cube-map
- spec/!OpenGL 3.2/layered-rendering/framebuffertexture

Cc: "10.0" 
---
 src/mesa/main/fbobject.c | 50 ++--
 1 file changed, 40 insertions(+), 10 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 9dd7161..2feb4c3 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2334,16 +2334,46 @@ framebuffer_texture(struct gl_context *ctx, const char 
*caller, GLenum target,
   texObj = _mesa_lookup_texture(ctx, texture);
   if (texObj != NULL) {
  if (textarget == 0) {
-/* If textarget == 0 it means we're being called by
- * glFramebufferTextureLayer() and textarget is not used.
- * The only legal texture types for that function are 3D and
- * 1D/2D arrays textures.
- */
-err = (texObj->Target != GL_TEXTURE_3D) &&
-(texObj->Target != GL_TEXTURE_1D_ARRAY_EXT) &&
-(texObj->Target != GL_TEXTURE_2D_ARRAY_EXT) &&
-(texObj->Target != GL_TEXTURE_CUBE_MAP_ARRAY) &&
-(texObj->Target != GL_TEXTURE_2D_MULTISAMPLE_ARRAY);
+if (layered) {
+   /* We're being called by glFramebufferTexture() and textarget
+* is not used.
+*/
+   switch (texObj->Target) {
+   case GL_TEXTURE_3D:
+   case GL_TEXTURE_1D_ARRAY_EXT:
+   case GL_TEXTURE_2D_ARRAY_EXT:
+   case GL_TEXTURE_CUBE_MAP:
+   case GL_TEXTURE_CUBE_MAP_ARRAY:
+   case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
+  err = false;
+  break;
+   case GL_TEXTURE_1D:
+   case GL_TEXTURE_2D:
+   case GL_TEXTURE_RECTANGLE:
+   case GL_TEXTURE_2D_MULTISAMPLE:
+  /* These texture types are valid to pass to
+   * glFramebufferTexture(), but since they aren't layered, it
+   * is equivalent to calling glFramebufferTexture{1D,2D}().
+   */
+  err = false;
+  layered = false;
+  textarget = texObj->Target;
+  break;
+   default:
+  err = true;
+  break;
+   }
+} else {
+   /* We're being called by glFramebufferTextureLayer() and
+* textarget is not used.  The only legal texture types for
+* that function are 3D and 1D/2D arrays textures.
+*/
+   err = (texObj->Target != GL_TEXTURE_3D) &&
+  (texObj->Target != GL_TEXTURE_1D_ARRAY_EXT) &&
+  (texObj->Target != GL_TEXTURE_2D_ARRAY_EXT) &&
+  (texObj->Target != GL_TEXTURE_CUBE_MAP_ARRAY) &&
+  (texObj->Target != GL_TEXTURE_2D_MULTISAMPLE_ARRAY);
+}
  }
  else {
 /* Make sure textarget is consistent with the texture's type */
-- 
1.8.4.2

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

[Mesa-dev] [PATCH 2/2] mesa: Implement GL_FRAMEBUFFER_ATTACHMENT_LAYERED query.

[Paul Berry]

>From section 6.1.18 (Renderbuffer Object Queries) of the GL 3.2 spec,
under the heading "If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE
is TEXTURE, then":

If pname is FRAMEBUFFER_ATTACHMENT_LAYERED, then params will
contain TRUE if an entire level of a three-dimesional texture,
cube map texture, or one-or two-dimensional array texture is
attached. Otherwise, params will contain FALSE.

Fixes piglit tests:
- spec/!OpenGL 3.2/layered-rendering/framebuffer-layered-attachments
- spec/!OpenGL 3.2/layered-rendering/framebuffertexture-defaults

Cc: "10.0" 
---
 src/mesa/main/fbobject.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 2feb4c3..facd019 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2950,6 +2950,18 @@ _mesa_GetFramebufferAttachmentParameteriv(GLenum target, 
GLenum attachment,
" invalid FBO attachment structure");
   }
   return;
+   case GL_FRAMEBUFFER_ATTACHMENT_LAYERED:
+  if (!_mesa_has_geometry_shaders(ctx)) {
+ goto invalid_pname_enum;
+  } else if (att->Type == GL_TEXTURE) {
+ *params = att->Layered;
+  } else if (att->Type == GL_NONE) {
+ _mesa_error(ctx, err,
+ "glGetFramebufferAttachmentParameterivEXT(pname)");
+  } else {
+ goto invalid_pname_enum;
+  }
+  return;
default:
   goto invalid_pname_enum;
}
-- 
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 1/5] mesa: Track number of layers in layered framebuffers.

[Chris Forbes]

+   if (layer_count > 0) {
+  fb->NumLayers = layer_count;

It seems like in the nonlayered case there will just be junk left in
fb->NumLayers, which might trip people up in future?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/5] i965: Fix blorp clear of layered framebuffers.

[Paul Berry]

>From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:

When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.

This patch fixes the blorp clear path for color buffers.

Fixes piglit test "spec/!OpenGL 3.2/layered-rendering/clear-color".

Cc: "10.0" 
---
 src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index c7f485e..ae68d52 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -67,7 +67,8 @@ public:
   struct gl_framebuffer *fb,
   struct gl_renderbuffer *rb,
   GLubyte *color_mask,
-  bool partial_clear);
+  bool partial_clear,
+  unsigned layer);
 };
 
 
@@ -183,12 +184,13 @@ brw_blorp_clear_params::brw_blorp_clear_params(struct 
brw_context *brw,
struct gl_framebuffer *fb,
struct gl_renderbuffer *rb,
GLubyte *color_mask,
-   bool partial_clear)
+   bool partial_clear,
+   unsigned layer)
 {
struct gl_context *ctx = &brw->ctx;
struct intel_renderbuffer *irb = intel_renderbuffer(rb);
 
-   dst.set(brw, irb->mt, irb->mt_level, irb->mt_layer, true);
+   dst.set(brw, irb->mt, irb->mt_level, layer, true);
 
/* Override the surface format according to the context's sRGB rules. */
gl_format format = _mesa_get_render_format(ctx, irb->mt->format);
@@ -443,13 +445,13 @@ brw_blorp_const_color_program::compile(struct brw_context 
*brw,
 bool
 do_single_blorp_clear(struct brw_context *brw, struct gl_framebuffer *fb,
   struct gl_renderbuffer *rb, unsigned buf,
-  bool partial_clear)
+  bool partial_clear, unsigned layer)
 {
struct gl_context *ctx = &brw->ctx;
struct intel_renderbuffer *irb = intel_renderbuffer(rb);
 
brw_blorp_clear_params params(brw, fb, rb, ctx->Color.ColorMask[buf],
- partial_clear);
+ partial_clear, layer);
 
bool is_fast_clear =
   (params.fast_clear_op == GEN7_FAST_CLEAR_OP_FAST_CLEAR);
@@ -525,6 +527,7 @@ brw_blorp_clear_color(struct brw_context *brw, struct 
gl_framebuffer *fb,
 
for (unsigned buf = 0; buf < fb->_NumColorDrawBuffers; buf++) {
   struct gl_renderbuffer *rb = fb->_ColorDrawBuffers[buf];
+  struct intel_renderbuffer *irb = intel_renderbuffer(rb);
 
   /* If this is an ES2 context or GL_ARB_ES2_compatibility is supported,
* the framebuffer can be complete with some attachments missing.  In
@@ -533,8 +536,17 @@ brw_blorp_clear_color(struct brw_context *brw, struct 
gl_framebuffer *fb,
   if (rb == NULL)
  continue;
 
-  if (!do_single_blorp_clear(brw, fb, rb, buf, partial_clear))
- return false;
+  if (fb->Layered) {
+ assert(fb->NumLayers == irb->mt->level[irb->mt_level].depth);
+ for (unsigned layer = 0; layer < fb->NumLayers; layer++) {
+if (!do_single_blorp_clear(brw, fb, rb, buf, partial_clear, layer))
+   return false;
+ }
+  } else {
+ unsigned layer = irb->mt_layer;
+ if (!do_single_blorp_clear(brw, fb, rb, buf, partial_clear, layer))
+return false;
+  }
}
 
return true;
-- 
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/5] i965: refactor blorp clear code in preparation for layered clears.

[Paul Berry]

Cc: "10.0" 
---
 src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 119 ++
 1 file changed, 66 insertions(+), 53 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index d1933ce..c7f485e 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
@@ -439,13 +439,75 @@ brw_blorp_const_color_program::compile(struct brw_context 
*brw,
return brw_get_program(&func, program_size);
 }
 
-extern "C" {
+
 bool
-brw_blorp_clear_color(struct brw_context *brw, struct gl_framebuffer *fb,
+do_single_blorp_clear(struct brw_context *brw, struct gl_framebuffer *fb,
+  struct gl_renderbuffer *rb, unsigned buf,
   bool partial_clear)
 {
struct gl_context *ctx = &brw->ctx;
+   struct intel_renderbuffer *irb = intel_renderbuffer(rb);
+
+   brw_blorp_clear_params params(brw, fb, rb, ctx->Color.ColorMask[buf],
+ partial_clear);
+
+   bool is_fast_clear =
+  (params.fast_clear_op == GEN7_FAST_CLEAR_OP_FAST_CLEAR);
+   if (is_fast_clear) {
+  /* Record the clear color in the miptree so that it will be
+   * programmed in SURFACE_STATE by later rendering and resolve
+   * operations.
+   */
+  uint32_t new_color_value =
+ compute_fast_clear_color_bits(&ctx->Color.ClearColor);
+  if (irb->mt->fast_clear_color_value != new_color_value) {
+ irb->mt->fast_clear_color_value = new_color_value;
+ brw->state.dirty.brw |= BRW_NEW_SURFACES;
+  }
+
+  /* If the buffer is already in INTEL_MCS_STATE_CLEAR, the clear is
+   * redundant and can be skipped.
+   */
+  if (irb->mt->mcs_state == INTEL_MCS_STATE_CLEAR)
+ return true;
+
+  /* If the MCS buffer hasn't been allocated yet, we need to allocate
+   * it now.
+   */
+  if (!irb->mt->mcs_mt) {
+ if (!intel_miptree_alloc_non_msrt_mcs(brw, irb->mt)) {
+/* MCS allocation failed--probably this will only happen in
+ * out-of-memory conditions.  But in any case, try to recover
+ * by falling back to a non-blorp clear technique.
+ */
+return false;
+ }
+ brw->state.dirty.brw |= BRW_NEW_SURFACES;
+  }
+   }
+
+   DBG("%s to mt %p level %d layer %d\n", __FUNCTION__,
+   irb->mt, irb->mt_level, irb->mt_layer);
+
+   brw_blorp_exec(brw, ¶ms);
+
+   if (is_fast_clear) {
+  /* Now that the fast clear has occurred, put the buffer in
+   * INTEL_MCS_STATE_CLEAR so that we won't waste time doing redundant
+   * clears.
+   */
+  irb->mt->mcs_state = INTEL_MCS_STATE_CLEAR;
+   }
+
+   return true;
+}
+
 
+extern "C" {
+bool
+brw_blorp_clear_color(struct brw_context *brw, struct gl_framebuffer *fb,
+  bool partial_clear)
+{
/* The constant color clear code doesn't work for multisampled surfaces, so
 * we need to support falling back to other clear mechanisms.
 * Unfortunately, our clear code is based on a bitmask that doesn't
@@ -463,7 +525,6 @@ brw_blorp_clear_color(struct brw_context *brw, struct 
gl_framebuffer *fb,
 
for (unsigned buf = 0; buf < fb->_NumColorDrawBuffers; buf++) {
   struct gl_renderbuffer *rb = fb->_ColorDrawBuffers[buf];
-  struct intel_renderbuffer *irb = intel_renderbuffer(rb);
 
   /* If this is an ES2 context or GL_ARB_ES2_compatibility is supported,
* the framebuffer can be complete with some attachments missing.  In
@@ -472,56 +533,8 @@ brw_blorp_clear_color(struct brw_context *brw, struct 
gl_framebuffer *fb,
   if (rb == NULL)
  continue;
 
-  brw_blorp_clear_params params(brw, fb, rb, ctx->Color.ColorMask[buf],
-partial_clear);
-
-  bool is_fast_clear =
- (params.fast_clear_op == GEN7_FAST_CLEAR_OP_FAST_CLEAR);
-  if (is_fast_clear) {
- /* Record the clear color in the miptree so that it will be
-  * programmed in SURFACE_STATE by later rendering and resolve
-  * operations.
-  */
- uint32_t new_color_value =
-compute_fast_clear_color_bits(&ctx->Color.ClearColor);
- if (irb->mt->fast_clear_color_value != new_color_value) {
-irb->mt->fast_clear_color_value = new_color_value;
-brw->state.dirty.brw |= BRW_NEW_SURFACES;
- }
-
- /* If the buffer is already in INTEL_MCS_STATE_CLEAR, the clear is
-  * redundant and can be skipped.
-  */
- if (irb->mt->mcs_state == INTEL_MCS_STATE_CLEAR)
-continue;
-
- /* If the MCS buffer hasn't been allocated yet, we need to allocate
-  * it now.
-  */
- if (!irb->mt->mcs_mt) {
-if (!intel_miptree_alloc_non_msrt_mcs(brw, irb->mt)) {
-   /* MCS allocation failed--probably this will only happen in
-* out-

[Mesa-dev] [PATCH 1/5] mesa: Track number of layers in layered framebuffers.

[Paul Berry]

In order to properly clear layered framebuffers, we need to know how
many layers they have.  The easiest way to do this is to record it in
the gl_framebuffer struct when we check framebuffer completeness, just
like we do for the Layered boolean.

Cc: "10.0" 
---
 src/mesa/main/fbobject.c | 21 -
 src/mesa/main/mtypes.h   |  6 ++
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 9dd7161..3b84f6a 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -905,6 +905,7 @@ _mesa_test_framebuffer_completeness(struct gl_context *ctx,
   struct gl_renderbuffer_attachment *att;
   GLenum f;
   gl_format attFormat;
+  GLenum att_tex_target = GL_NONE;
 
   /*
* XXX for ARB_fbo, only check color buffers that are named by
@@ -945,6 +946,7 @@ _mesa_test_framebuffer_completeness(struct gl_context *ctx,
*/
   if (att->Type == GL_TEXTURE) {
  const struct gl_texture_image *texImg = att->Renderbuffer->TexImage;
+ att_tex_target = att->Texture->Target;
  minWidth = MIN2(minWidth, texImg->Width);
  maxWidth = MAX2(maxWidth, texImg->Width);
  minHeight = MIN2(minHeight, texImg->Height);
@@ -1057,7 +1059,21 @@ _mesa_test_framebuffer_completeness(struct gl_context 
*ctx,
   }
 
   /* Check that layered rendering is consistent. */
-  att_layer_count = att->Layered ? att->Renderbuffer->Depth : 0;
+  if (att->Layered) {
+ switch (att_tex_target) {
+ case GL_TEXTURE_CUBE_MAP:
+att_layer_count = 6;
+break;
+ case GL_TEXTURE_CUBE_MAP_ARRAY:
+att_layer_count = att->Renderbuffer->Depth * 6;
+break;
+ default:
+att_layer_count = att->Renderbuffer->Depth;
+break;
+ }
+  } else {
+ att_layer_count = 0;
+  }
   if (!layer_count_valid) {
  layer_count = att_layer_count;
  layer_count_valid = true;
@@ -1074,6 +1090,9 @@ _mesa_test_framebuffer_completeness(struct gl_context 
*ctx,
}
 
fb->Layered = layer_count > 0;
+   if (layer_count > 0) {
+  fb->NumLayers = layer_count;
+   }
 
if (_mesa_is_desktop_gl(ctx) && !ctx->Extensions.ARB_ES2_compatibility) {
   /* Check that all DrawBuffers are present */
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 8801d6f..699e6e6 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2996,6 +2996,12 @@ struct gl_framebuffer
 
GLboolean Layered;
 
+   /**
+* If Layered is true, the number of layers in the framebuffer.  For cube
+* maps and cube map arrays, this includes the factor of 6.
+*/
+   GLuint NumLayers;
+
/** Delete this framebuffer */
void (*Delete)(struct gl_framebuffer *fb);
 };
-- 
1.8.4.2

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

[Mesa-dev] [PATCH 0/5] i965: Fix glClear of layered framebuffers.

[Paul Berry]

>From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:

When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.

Patch 1 adds logic to the framebuffer completeness check to record the
number of layers in a layered framebuffer, so that when we later clear
it we will know how many layers need clearing.  Patch 2 fixes the Meta
path for layered clears.  Patches 3 and 4 fix the i965 blorp path
(which is used for most color buffer clears).  Patch 5 fixes the i965
fast depth clear path.

This patch series depends on "[PATCH] glsl: Fix cross-version linking
between VS and GS.", which was sent out for review earlier today.

[PATCH 1/5] mesa: Track number of layers in layered framebuffers.
[PATCH 2/5] meta: fix meta clear of layered framebuffers
[PATCH 3/5] i965: refactor blorp clear code in preparation for layered clears.
[PATCH 4/5] i965: Fix blorp clear of layered framebuffers.
[PATCH 5/5] i965: Fix fast clear of depth buffers.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/5] meta: fix meta clear of layered framebuffers

[Paul Berry]

>From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:

When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.

This patch fixes meta clears to properly clear all layers of a layered
framebuffer attachment.  We accomplish this by adding a geometry
shader to the meta clear program which sets gl_Layer to a uniform
value.  When clearing a layered framebuffer, we execute in a loop,
setting the uniform to point to each layer in turn.

Cc: "10.0" 
---
 src/mesa/drivers/common/meta.c | 51 +++---
 1 file changed, 48 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 99b02ba..a6d5098 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -241,9 +241,11 @@ struct clear_state
GLuint VBO;
GLuint ShaderProg;
GLint ColorLocation;
+   GLint LayerLocation;
 
GLuint IntegerShaderProg;
GLint IntegerColorLocation;
+   GLint IntegerLayerLocation;
 };
 
 
@@ -2145,6 +2147,19 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
   "{\n"
   "   gl_Position = position;\n"
   "}\n";
+   const char *gs_source =
+  "#version 150\n"
+  "layout(triangles) in;\n"
+  "layout(triangle_strip, max_vertices = 4) out;\n"
+  "uniform int layer;\n"
+  "void main()\n"
+  "{\n"
+  "  for (int i = 0; i < 3; i++) {\n"
+  "gl_Layer = layer;\n"
+  "gl_Position = gl_in[i].gl_Position;\n"
+  "EmitVertex();\n"
+  "  }\n"
+  "}\n";
const char *fs_source =
   "#ifdef GL_ES\n"
   "precision highp float;\n"
@@ -2154,7 +2169,7 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
   "{\n"
   "   gl_FragColor = color;\n"
   "}\n";
-   GLuint vs, fs;
+   GLuint vs, gs = 0, fs;
bool has_integer_textures;
 
if (clear->ArrayObj != 0)
@@ -2176,6 +2191,12 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
_mesa_ShaderSource(vs, 1, &vs_source, NULL);
_mesa_CompileShader(vs);
 
+   if (_mesa_has_geometry_shaders(ctx)) {
+  gs = _mesa_CreateShaderObjectARB(GL_GEOMETRY_SHADER);
+  _mesa_ShaderSource(gs, 1, &gs_source, NULL);
+  _mesa_CompileShader(gs);
+   }
+
fs = _mesa_CreateShaderObjectARB(GL_FRAGMENT_SHADER);
_mesa_ShaderSource(fs, 1, &fs_source, NULL);
_mesa_CompileShader(fs);
@@ -2183,6 +2204,8 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
clear->ShaderProg = _mesa_CreateProgramObjectARB();
_mesa_AttachShader(clear->ShaderProg, fs);
_mesa_DeleteObjectARB(fs);
+   if (gs != 0)
+  _mesa_AttachShader(clear->ShaderProg, gs);
_mesa_AttachShader(clear->ShaderProg, vs);
_mesa_DeleteObjectARB(vs);
_mesa_BindAttribLocation(clear->ShaderProg, 0, "position");
@@ -2190,6 +2213,10 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
 
clear->ColorLocation = _mesa_GetUniformLocation(clear->ShaderProg,
  "color");
+   if (gs != 0) {
+  clear->LayerLocation = _mesa_GetUniformLocation(clear->ShaderProg,
+ "layer");
+   }
 
has_integer_textures = _mesa_is_gles3(ctx) ||
   (_mesa_is_desktop_gl(ctx) && ctx->Const.GLSLVersion >= 130);
@@ -2227,6 +2254,8 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
   clear->IntegerShaderProg = _mesa_CreateProgramObjectARB();
   _mesa_AttachShader(clear->IntegerShaderProg, fs);
   _mesa_DeleteObjectARB(fs);
+  if (gs != 0)
+ _mesa_AttachShader(clear->IntegerShaderProg, gs);
   _mesa_AttachShader(clear->IntegerShaderProg, vs);
   _mesa_DeleteObjectARB(vs);
   _mesa_BindAttribLocation(clear->IntegerShaderProg, 0, "position");
@@ -2240,7 +2269,13 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
 
   clear->IntegerColorLocation =
 _mesa_GetUniformLocation(clear->IntegerShaderProg, "color");
+  if (gs != 0) {
+ clear->IntegerLayerLocation =
+_mesa_GetUniformLocation(clear->IntegerShaderProg, "layer");
+  }
}
+   if (gs != 0)
+  _mesa_DeleteObjectARB(gs);
 }
 
 static void
@@ -2371,8 +2406,18 @@ _mesa_meta_glsl_Clear(struct gl_context *ctx, GLbitfield 
buffers)
_mesa_BufferData(GL_ARRAY_BUFFER_ARB, sizeof(verts), verts,
   GL_DYNAMIC_DRAW_ARB);
 
-   /* draw quad */
-   _mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
+   /* draw quad(s) */
+   if (fb->Layered) {
+  for (unsigned layer = 0; layer < fb->NumLayers; layer++) {
+ if (fb->_IntegerColor)
+_mesa_Uniform1i(clear->IntegerLayerLocation, layer);
+ else
+_mesa_Uniform1i(clear->LayerLocation, layer);
+ _mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
+  }
+

[Mesa-dev] [PATCH 5/5] i965: Fix fast clear of depth buffers.

[Paul Berry]

>From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:

When the Clear or ClearBuffer* commands are used to clear a
layered framebuffer attachment, all layers of the attachment are
cleared.

This patch fixes the fast depth clear path.

Fixes piglit test "spec/!OpenGL 3.2/layered-rendering/clear-depth".

Cc: "10.0" 
---
 src/mesa/drivers/dri/i965/brw_clear.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index a727e6e..9c1c9a8 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -181,8 +181,16 @@ brw_fast_clear_depth(struct gl_context *ctx)
 */
intel_batchbuffer_emit_mi_flush(brw);
 
-   intel_hiz_exec(brw, mt, depth_irb->mt_level, depth_irb->mt_layer,
- GEN6_HIZ_OP_DEPTH_CLEAR);
+   if (fb->Layered) {
+  assert(fb->NumLayers == depth_irb->mt->level[depth_irb->mt_level].depth);
+  for (unsigned layer = 0; layer < fb->NumLayers; layer++) {
+ intel_hiz_exec(brw, mt, depth_irb->mt_level, layer,
+GEN6_HIZ_OP_DEPTH_CLEAR);
+  }
+   } else {
+  intel_hiz_exec(brw, mt, depth_irb->mt_level, depth_irb->mt_layer,
+ GEN6_HIZ_OP_DEPTH_CLEAR);
+   }
 
if (brw->gen == 6) {
   /* From the Sandy Bridge PRM, volume 2 part 1, page 314:
-- 
1.8.4.2

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

[Mesa-dev] [PATCH] r600g/compute: Add a work-around for flushing issues on Cayman

[Tom Stellard]

From: Tom Stellard 

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

CC: "10.0" 
---
 src/gallium/drivers/r600/evergreen_compute.c |  4 
 src/gallium/drivers/r600/r600_hw_context.c   |  4 +++-
 src/gallium/drivers/r600/r600_pipe.h | 10 ++
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/r600/evergreen_compute.c 
b/src/gallium/drivers/r600/evergreen_compute.c
index ffdc5c3..d668c8e 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -474,6 +474,10 @@ static void compute_emit_cs(struct r600_context *ctx, 
const uint *block_layout,
r600_flush_emit(ctx);
ctx->b.flags = 0;
 
+   if (ctx->b.chip_class >= CAYMAN) {
+   ctx->skip_surface_sync_on_next_cs_flush = true;
+   }
+
 #if 0
COMPUTE_DBG(ctx->screen, "cdw: %i\n", cs->cdw);
for (i = 0; i < cs->cdw; i++) {
diff --git a/src/gallium/drivers/r600/r600_hw_context.c 
b/src/gallium/drivers/r600/r600_hw_context.c
index 5f3a9bd..191a81d 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -293,7 +293,7 @@ void r600_flush_emit(struct r600_context *rctx)
S_0085F0_SMX_ACTION_ENA(1);
}
 
-   if (cp_coher_cntl) {
+   if (cp_coher_cntl && !rctx->skip_surface_sync_on_next_cs_flush) {
cs->buf[cs->cdw++] = PKT3(PKT3_SURFACE_SYNC, 3, 0);
cs->buf[cs->cdw++] = cp_coher_cntl;   /* CP_COHER_CNTL */
cs->buf[cs->cdw++] = 0x;  /* CP_COHER_SIZE */
@@ -354,6 +354,8 @@ void r600_context_flush(struct r600_context *ctx, unsigned 
flags)
 
/* Flush the CS. */
ctx->b.ws->cs_flush(ctx->b.rings.gfx.cs, flags, 
ctx->screen->cs_count++);
+
+   ctx->skip_surface_sync_on_next_cs_flush = false;
 }
 
 void r600_begin_new_cs(struct r600_context *ctx)
diff --git a/src/gallium/drivers/r600/r600_pipe.h 
b/src/gallium/drivers/r600/r600_pipe.h
index d7af618..f0d4be4 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -507,6 +507,16 @@ struct r600_context {
 
void*sb_context;
struct r600_isa *isa;
+
+   /* Work-around for flushing problems with compute shaders on Cayman:
+* Emitting a SURFACE_SYNC packet with any of the CB*_DEST_BASE_ENA
+* or DB_DEST_BASE_ENA bits set after dispatching a compute shader
+* hangs the GPU.
+*
+* Setting this to true will prevent r600_flush_emit() from emitting
+* a SURFACE_SYNC packet.  This field will be cleared by
+* by r600_context_flush() after flushing the command stream. */
+   boolean skip_surface_sync_on_next_cs_flush;
 };
 
 static INLINE void r600_emit_command_buffer(struct radeon_winsys_cs *cs,
-- 
1.8.1.5

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

[Mesa-dev] [PATCH] glsl: Fix cross-version linking between VS and GS.

[Paul Berry]

Previously, when attempting to link a vertex shader and a geometry
shader that use different GLSL versions, we would sometimes generate a
link error due to the implicit declaration of gl_PerVertex being
different between the two GLSL versions.

This patch fixes that problem by only requiring interface block
definitions to match when they are explicitly declared.

Fixes piglit test "shaders/version-mixing vs-gs".

Cc: "10.0" 
---

This patch depends on "[PATCH v2] glsl: Prohibit illegal mixing of
redeclarations inside/outside gl_PerVertex.", which was sent out for
review earlier today.

 src/glsl/link_interface_blocks.cpp | 29 +
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/src/glsl/link_interface_blocks.cpp 
b/src/glsl/link_interface_blocks.cpp
index a7fceb9..b4379b0 100644
--- a/src/glsl/link_interface_blocks.cpp
+++ b/src/glsl/link_interface_blocks.cpp
@@ -59,6 +59,9 @@ struct interface_block_definition
  instance_name = var->name;
  if (var->type->is_array())
 array_size = var->type->length;
+ explicitly_declared = (var->how_declared == ir_var_declared_normally);
+  } else {
+ explicitly_declared = (var->how_declared == ir_var_declared_in_block);
   }
}
 
@@ -77,6 +80,12 @@ struct interface_block_definition
 * Otherwise -1.
 */
int array_size;
+
+   /**
+* True if this interface block was explicitly declared in the shader;
+* false if it was an implicitly declared built-in interface block.
+*/
+   bool explicitly_declared;
 };
 
 
@@ -91,8 +100,14 @@ intrastage_match(interface_block_definition *a,
  ir_variable_mode mode)
 {
/* Types must match. */
-   if (a->type != b->type)
-  return false;
+   if (a->type != b->type) {
+  /* Exception: if both the interface blocks are implicitly declared,
+   * don't force their types to match.  They might mismatch due to the two
+   * shaders using different GLSL versions, and that's ok.
+   */
+  if (a->explicitly_declared || b->explicitly_declared)
+ return false;
+   }
 
/* Presence/absence of interface names must match. */
if ((a->instance_name == NULL) != (b->instance_name == NULL))
@@ -144,8 +159,14 @@ interstage_match(const interface_block_definition 
*producer,
assert(producer->array_size != 0);
 
/* Types must match. */
-   if (consumer->type != producer->type)
-  return false;
+   if (consumer->type != producer->type) {
+  /* Exception: if both the interface blocks are implicitly declared,
+   * don't force their types to match.  They might mismatch due to the two
+   * shaders using different GLSL versions, and that's ok.
+   */
+  if (consumer->explicitly_declared || producer->explicitly_declared)
+ return false;
+   }
if (extra_array_level) {
   /* Consumer must be an array, and producer must not. */
   if (consumer->array_size == -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 v2] glsl: Prohibit illegal mixing of redeclarations inside/outside gl_PerVertex.

[Paul Berry]

>From section 7.1 (Built-In Language Variables) of the GLSL 4.10
spec:

Also, if a built-in interface block is redeclared, no member of
the built-in declaration can be redeclared outside the block
redeclaration.

We have been regarding this text as a clarification to the behaviour
established for gl_PerVertex by GLSL 1.50, so we apply it regardless
of GLSL version.

This patch enforces the rule by adding a boolean to ir_variable to
track how the variable was declared: implicitly, normally, or in an
interface block.

Fixes piglit tests:
- gs-redeclares-pervertex-out-after-global-redeclaration.geom
- vs-redeclares-pervertex-out-after-global-redeclaration.vert
- gs-redeclares-pervertex-out-after-other-global-redeclaration.geom
- vs-redeclares-pervertex-out-after-other-global-redeclaration.vert
- gs-redeclares-pervertex-out-before-global-redeclaration
- vs-redeclares-pervertex-out-before-global-redeclaration

Cc: "10.0" 

v2: Don't set "how_declared" redundantly in builtin_variables.cpp.
Properly clone "how_declared".
---
 src/glsl/ast_to_hir.cpp| 20 
 src/glsl/builtin_variables.cpp |  1 +
 src/glsl/ir.cpp|  3 ++-
 src/glsl/ir.h  | 36 
 src/glsl/ir_clone.cpp  |  1 +
 5 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 76b256c..0128047 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -3355,6 +3355,15 @@ ast_declarator_list::hir(exec_list *instructions,
   ir_variable *earlier =
  get_variable_being_redeclared(var, decl->get_location(), state,
false /* allow_all_redeclarations */);
+  if (earlier != NULL) {
+ if (strncmp(var->name, "gl_", 3) == 0 &&
+ earlier->how_declared == ir_var_declared_in_block) {
+_mesa_glsl_error(&loc, state,
+ "`%s' has already been redeclared using "
+ "gl_PerVertex", var->name);
+ }
+ earlier->how_declared = ir_var_declared_normally;
+  }
 
   if (decl->initializer != NULL) {
 result = process_initializer((earlier == NULL) ? var : earlier,
@@ -5048,6 +5057,7 @@ ast_interface_block::hir(exec_list *instructions,
 _mesa_glsl_error(&loc, state, "`%s' redeclared",
  this->instance_name);
  }
+ earlier->how_declared = ir_var_declared_normally;
  earlier->type = var->type;
  earlier->reinit_interface_type(block_type);
  delete var;
@@ -5078,7 +5088,11 @@ ast_interface_block::hir(exec_list *instructions,
_mesa_glsl_error(&loc, state,
 "redeclaration of gl_PerVertex can only "
 "include built-in variables");
+} else if (earlier->how_declared == ir_var_declared_normally) {
+   _mesa_glsl_error(&loc, state,
+"`%s' has already been redeclared", var->name);
 } else {
+   earlier->how_declared = ir_var_declared_in_block;
earlier->reinit_interface_type(block_type);
 }
 continue;
@@ -5125,6 +5139,12 @@ ast_interface_block::hir(exec_list *instructions,
 if (var != NULL &&
 var->get_interface_type() == earlier_per_vertex &&
 var->mode == var_mode) {
+   if (var->how_declared == ir_var_declared_normally) {
+  _mesa_glsl_error(&loc, state,
+   "redeclaration of gl_PerVertex cannot "
+   "follow a redeclaration of `%s'",
+   var->name);
+   }
state->symbols->disable_variable(var->name);
var->remove();
 }
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 4d44104..d57324c 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -434,6 +434,7 @@ builtin_variable_generator::add_variable(const char *name,
  enum ir_variable_mode mode, int slot)
 {
ir_variable *var = new(symtab) ir_variable(type, name, mode);
+   var->how_declared = ir_var_declared_implicitly;
 
switch (var->mode) {
case ir_var_auto:
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index 1b49736..297 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -1586,7 +1586,8 @@ ir_variable::ir_variable(const struct glsl_type *type, 
const char *name,
 ir_variable_mode mode)
: max_array_access(0), max_ifc_array_access(NULL),
  read_only(false), centroid(false), invariant(false),
-mode(mode), interpolation(INTERP_QUALIFIER_NONE), atomic()
+ how_declared(ir_var_declared_normally), mode(mode),
+ interpolation(INTERP_QUALIFIER_NO

[Mesa-dev] [PATCH] glsl: Prohibit illegal mixing of redeclarations inside/outside gl_PerVertex.

[Paul Berry]

>From section 7.1 (Built-In Language Variables) of the GLSL 4.10
spec:

Also, if a built-in interface block is redeclared, no member of
the built-in declaration can be redeclared outside the block
redeclaration.

We have been regarding this text as a clarification to the behaviour
established for gl_PerVertex by GLSL 1.50, so we apply it regardless
of GLSL version.

This patch enforces the rule by adding a boolean to ir_variable to
track how the variable was declared: implicitly, normally, or in an
interface block.

Fixes piglit tests:
- gs-redeclares-pervertex-out-after-global-redeclaration.geom
- vs-redeclares-pervertex-out-after-global-redeclaration.vert
- gs-redeclares-pervertex-out-after-other-global-redeclaration.geom
- vs-redeclares-pervertex-out-after-other-global-redeclaration.vert
- gs-redeclares-pervertex-out-before-global-redeclaration
- vs-redeclares-pervertex-out-before-global-redeclaration

Cc: "10.0" 
---
 src/glsl/ast_to_hir.cpp| 20 
 src/glsl/builtin_variables.cpp |  3 +++
 src/glsl/ir.cpp|  3 ++-
 src/glsl/ir.h  | 36 
 4 files changed, 61 insertions(+), 1 deletion(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 76b256c..0128047 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -3355,6 +3355,15 @@ ast_declarator_list::hir(exec_list *instructions,
   ir_variable *earlier =
  get_variable_being_redeclared(var, decl->get_location(), state,
false /* allow_all_redeclarations */);
+  if (earlier != NULL) {
+ if (strncmp(var->name, "gl_", 3) == 0 &&
+ earlier->how_declared == ir_var_declared_in_block) {
+_mesa_glsl_error(&loc, state,
+ "`%s' has already been redeclared using "
+ "gl_PerVertex", var->name);
+ }
+ earlier->how_declared = ir_var_declared_normally;
+  }
 
   if (decl->initializer != NULL) {
 result = process_initializer((earlier == NULL) ? var : earlier,
@@ -5048,6 +5057,7 @@ ast_interface_block::hir(exec_list *instructions,
 _mesa_glsl_error(&loc, state, "`%s' redeclared",
  this->instance_name);
  }
+ earlier->how_declared = ir_var_declared_normally;
  earlier->type = var->type;
  earlier->reinit_interface_type(block_type);
  delete var;
@@ -5078,7 +5088,11 @@ ast_interface_block::hir(exec_list *instructions,
_mesa_glsl_error(&loc, state,
 "redeclaration of gl_PerVertex can only "
 "include built-in variables");
+} else if (earlier->how_declared == ir_var_declared_normally) {
+   _mesa_glsl_error(&loc, state,
+"`%s' has already been redeclared", var->name);
 } else {
+   earlier->how_declared = ir_var_declared_in_block;
earlier->reinit_interface_type(block_type);
 }
 continue;
@@ -5125,6 +5139,12 @@ ast_interface_block::hir(exec_list *instructions,
 if (var != NULL &&
 var->get_interface_type() == earlier_per_vertex &&
 var->mode == var_mode) {
+   if (var->how_declared == ir_var_declared_normally) {
+  _mesa_glsl_error(&loc, state,
+   "redeclaration of gl_PerVertex cannot "
+   "follow a redeclaration of `%s'",
+   var->name);
+   }
state->symbols->disable_variable(var->name);
var->remove();
 }
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index 4d44104..257a36d 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -434,6 +434,7 @@ builtin_variable_generator::add_variable(const char *name,
  enum ir_variable_mode mode, int slot)
 {
ir_variable *var = new(symtab) ir_variable(type, name, mode);
+   var->how_declared = ir_var_declared_implicitly;
 
switch (var->mode) {
case ir_var_auto:
@@ -472,6 +473,7 @@ builtin_variable_generator::add_uniform(const glsl_type 
*type,
 const char *name)
 {
ir_variable *const uni = add_variable(name, type, ir_var_uniform, -1);
+   uni->how_declared = ir_var_declared_implicitly;
 
unsigned i;
for (i = 0; _mesa_builtin_uniform_desc[i].name != NULL; i++) {
@@ -520,6 +522,7 @@ builtin_variable_generator::add_const(const char *name, int 
value)
 {
ir_variable *const var = add_variable(name, glsl_type::int_type,
 ir_var_auto, -1);
+   var->how_declared = ir_var_declared_implicitly;
var->constant_value = new(var) ir_constant(valu

Re: [Mesa-dev] [PATCH 0/1]: Preparing for ARB_viewport_array

[Ian Romanick]

On 10/31/2013 08:55 AM, Courtney Goeltzenleuchter wrote:
> The following patch will begin the process of adding ARB_viewport_array
> to Mesa. Next will be to extend the gl_context Scissor and Viewport
> attributes to hold multiple viewport, scissor and scissor enables.
> Then the DI side of ARB_viewport_array.

I pushed a viewport-array branch to my freedesktop.org repository.
There's a bunch of in-progress refactoring there.  The big thing is
making the current viewport-related structures derived state.  This
minimizes the changes necessary to non-array drivers.

Opinions?

> ___
> 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] mesa: Change driver interface for ARB_viewport_array

[Marek Olšák]

st_viewport has nothing to do with the viewport. It's used if libGL doesn't
expose __DRI_USE_INVALIDATE, so I don't think it's safe to remove it. If
Driver::Viewport is about to removed, the code of st_viewport should be
moved somewhere else.

Marek


On Wed, Nov 20, 2013 at 12:53 AM, Courtney Goeltzenleuchter <
court...@lunarg.com> wrote:

> The Gallium state tracker has a st_viewport that it puts into
> driver->Viewport function table.
>
> It's not clear to me how _NEW_VIEWPORT replaces the function of the
> Driver->Viewport call.
>
> Is it really safe to remove the driver->Viewport call for Gallium?
>
> Courtney
>
>
> On Mon, Nov 4, 2013 at 12:31 PM, Brian Paul  wrote:
>
>> On 11/04/2013 11:43 AM, Ian Romanick wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On 11/01/2013 04:12 PM, Francisco Jerez wrote:
>>>
 Ian Romanick  writes:

  On 11/01/2013 02:04 PM, Courtney Goeltzenleuchter wrote:
>
>> [...]
>>
> More often, the dd_function_table functions allow core Mesa to
> signal the driver driver that something happened... and the
> driver may need to do something in response.  For DRI2 drivers,
> the Viewport function is a good example.  DRI2 drivers use that
> signal as a hint that the window may have been resized.
>
> Other dd_function_table functions are used by core Mesa to
> request the driver create or destroy some resource (e.g., texture
> storage).
>
> If it weren't for the way nouveau used the DepthRange and Scissor
> hooks, I think we could just about get rid of them altogether.  I
> wish that driver just used the dirty state bits like everyone
> else. :(
>

 Cases like the new dd_function_table::Scissor and ::Viewport hooks
 introduced in this patch series are the reason why nouveau tends
 to prefer overriding the dd_function_table to keep track of state
 changes rather than looking at the ctx->NewState bits, because the
 latter tend to be very coarse-grained -- e.g. there's one big
 _NEW_TEXTURE flag for all the state of all texture units while
 nouveau is able to update a subset of the texture state
 independently for only those texture units that have changed.

 With the dd_function_table interface proposed in this patch series
 it would be possible for the drivers to update the state of each
 viewport in the viewport array independently, which might be
 beneficial for some hardware someday, removing ::DepthRange and
 ::Scissor would preclude that possibility.

>>>
>>> Right... I wonder if we might be better of just tracking a bit per
>>> viewport in the gl_context.  I'm assuming we'll end up with something
>>> like:
>>>
>>>  struct gl_viewport_attrib Viewports[MAX_VIEWPORTS];
>>>
>>> in the gl_context.  It would be easy to add
>>>
>>>  GLbitfield  _DirtyViewports;
>>>
>>> along side it.  The various Viewport and DepthRange functions would
>>> set bits in that field along with _NEW_VIEWPORT.  Drivers that care
>>> could examine (and clear) those bits.
>>>
>>> We'd do similar for Scissor.
>>>
>>> Looking at the i965 hardware (and our driver architecture), I believe
>>> we have to upload all of the viewports anytime there's a change
>>> anyway.  The viewports are just stored as an array in a BO.  See
>>> gen7_upload_sf_clip_viewport and similar functions.
>>>
>>> Marek:  Do you know what Radeon / Gallium want?
>>>
>>
>> The gallium interface takes a start,count array of viewports.  The
>> st/mesa state tracker could use the bitfield to determine the changed
>> range.  But we also have the CSO module to help filter out redundant state
>> changes.
>>
>> -Brian
>>
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
>
> --
> Courtney Goeltzenleuchter
> LunarG
>
>
> ___
> 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] mesa: Change driver interface for ARB_viewport_array

[Brian Paul]

On 11/19/2013 04:53 PM, Courtney Goeltzenleuchter wrote:

The Gallium state tracker has a st_viewport that it puts into
driver->Viewport function table.

It's not clear to me how _NEW_VIEWPORT replaces the function of the
Driver->Viewport call.

Is it really safe to remove the driver->Viewport call for Gallium?


For multiple viewports, I think you only have to be concerned with the 
st_atom_viewport.c code.  Have you looked at that?


-Brian




Courtney


On Mon, Nov 4, 2013 at 12:31 PM, Brian Paul mailto:bri...@vmware.com>> wrote:

On 11/04/2013 11:43 AM, Ian Romanick wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/01/2013 04:12 PM, Francisco Jerez wrote:

Ian Romanick mailto:i...@freedesktop.org>> writes:

On 11/01/2013 02:04 PM, Courtney Goeltzenleuchter wrote:

[...]

More often, the dd_function_table functions allow core
Mesa to
signal the driver driver that something happened... and the
driver may need to do something in response.  For DRI2
drivers,
the Viewport function is a good example.  DRI2 drivers
use that
signal as a hint that the window may have been resized.

Other dd_function_table functions are used by core Mesa to
request the driver create or destroy some resource
(e.g., texture
storage).

If it weren't for the way nouveau used the DepthRange
and Scissor
hooks, I think we could just about get rid of them
altogether.  I
wish that driver just used the dirty state bits like
everyone
else. :(


Cases like the new dd_function_table::Scissor and ::Viewport
hooks
introduced in this patch series are the reason why nouveau tends
to prefer overriding the dd_function_table to keep track of
state
changes rather than looking at the ctx->NewState bits,
because the
latter tend to be very coarse-grained -- e.g. there's one big
_NEW_TEXTURE flag for all the state of all texture units while
nouveau is able to update a subset of the texture state
independently for only those texture units that have changed.

With the dd_function_table interface proposed in this patch
series
it would be possible for the drivers to update the state of each
viewport in the viewport array independently, which might be
beneficial for some hardware someday, removing ::DepthRange and
::Scissor would preclude that possibility.


Right... I wonder if we might be better of just tracking a bit per
viewport in the gl_context.  I'm assuming we'll end up with
something
like:

  struct gl_viewport_attrib Viewports[MAX_VIEWPORTS];

in the gl_context.  It would be easy to add

  GLbitfield  _DirtyViewports;

along side it.  The various Viewport and DepthRange functions would
set bits in that field along with _NEW_VIEWPORT.  Drivers that care
could examine (and clear) those bits.

We'd do similar for Scissor.

Looking at the i965 hardware (and our driver architecture), I
believe
we have to upload all of the viewports anytime there's a change
anyway.  The viewports are just stored as an array in a BO.  See
gen7_upload_sf_clip_viewport and similar functions.

Marek:  Do you know what Radeon / Gallium want?


The gallium interface takes a start,count array of viewports.  The
st/mesa state tracker could use the bitfield to determine the
changed range.  But we also have the CSO module to help filter out
redundant state changes.

-Brian


_
mesa-dev mailing list
mesa-dev@lists.freedesktop.org 
http://lists.freedesktop.org/__mailman/listinfo/mesa-dev






--
Courtney Goeltzenleuchter
LunarG



___
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

[Courtney Goeltzenleuchter]

My apologies, I was distracted by other maters - updated commit follows.


On Mon, Nov 11, 2013 at 2:21 PM, Chad Versace
wrote:

> On 11/08/2013 08:13 AM, Courtney Goeltzenleuchter wrote:
>
>> Support all levels of a supported texture format.
>>
>> Using 1024x1024, RGBA  source, mipmap
>> <>
>> 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 
>> ---
>>   src/mesa/drivers/dri/i965/intel_tex_subimage.c | 8 ++--
>>   1 file changed, 6 insertions(+), 2 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..50f802f 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 ||
>> @@ -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
>> +*/
>>
>
> One small nitpick. The above comment is short enough to fit on a single
> line.
> There's no need to place '*/' on a line by itself.
>
>
>  +   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,
>>
>>
> The code looks good, though I haven't tested it yet. But, I see the same
> issues with the commit message that I had with patch 1.
>



-- 
Courtney Goeltzenleuchter
LunarG
___
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

[Courtney Goeltzenleuchter]

Support all levels of a supported texture format.

Using 1024x1024, RGBA  source, mipmap
internal-format Before (MB/sec) mipmap (MB/sec)
GL_RGBA 627.15  615.90
GL_RGB  456.35  611.53
512x512
GL_RGBA 597.00  619.95
GL_RGB  440.62  611.28
256x256
GL_RGBA 487.80  587.42
GL_RGB  376.63  585.00

Test shows similar pattern for 512x512 and 256x256.

Benchmark has been sent to mesa-dev list: teximage_enh

--
1.8.1.2

Signed-off-by: Courtney Goeltzenleuchter 
---
 src/mesa/drivers/dri/i965/intel_tex_subimage.c | 8 ++--
 1 file changed, 6 insertions(+), 2 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..50f802f 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 ||
@@ -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 1/2] i965: add XRGB to tiled_memcpy

[Courtney Goeltzenleuchter]

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.

1024x1024 texture size
internal-format Before (MB/sec) XRGB (MB/sec)
GL_RGBA 628.15  627.15
GL_RGB  265.95  456.35

512x512 texture size
internal-format Before (MB/sec) XRGB (MB/sec)
GL_RGBA 600.23  597.00
GL_RGB  255.50  440.62

256x256 texture size
internal-format Before (MB/sec) XRGB (MB/sec)
GL_RGBA 489.08  487.80
GL_RGB  229.03  376.63

Test shows similar pattern for 512x512 and 256x256.

Benchmark has been sent to mesa-dev list: teximage

--
1.8.1.2

Signed-off-by: Courtney Goeltzenleuchter 
---
 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

Re: [Mesa-dev] [PATCH] mesa: Change driver interface for ARB_viewport_array

[Courtney Goeltzenleuchter]

The Gallium state tracker has a st_viewport that it puts into
driver->Viewport function table.

It's not clear to me how _NEW_VIEWPORT replaces the function of the
Driver->Viewport call.

Is it really safe to remove the driver->Viewport call for Gallium?

Courtney


On Mon, Nov 4, 2013 at 12:31 PM, Brian Paul  wrote:

> On 11/04/2013 11:43 AM, Ian Romanick wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 11/01/2013 04:12 PM, Francisco Jerez wrote:
>>
>>> Ian Romanick  writes:
>>>
>>>  On 11/01/2013 02:04 PM, Courtney Goeltzenleuchter wrote:

> [...]
>
 More often, the dd_function_table functions allow core Mesa to
 signal the driver driver that something happened... and the
 driver may need to do something in response.  For DRI2 drivers,
 the Viewport function is a good example.  DRI2 drivers use that
 signal as a hint that the window may have been resized.

 Other dd_function_table functions are used by core Mesa to
 request the driver create or destroy some resource (e.g., texture
 storage).

 If it weren't for the way nouveau used the DepthRange and Scissor
 hooks, I think we could just about get rid of them altogether.  I
 wish that driver just used the dirty state bits like everyone
 else. :(

>>>
>>> Cases like the new dd_function_table::Scissor and ::Viewport hooks
>>> introduced in this patch series are the reason why nouveau tends
>>> to prefer overriding the dd_function_table to keep track of state
>>> changes rather than looking at the ctx->NewState bits, because the
>>> latter tend to be very coarse-grained -- e.g. there's one big
>>> _NEW_TEXTURE flag for all the state of all texture units while
>>> nouveau is able to update a subset of the texture state
>>> independently for only those texture units that have changed.
>>>
>>> With the dd_function_table interface proposed in this patch series
>>> it would be possible for the drivers to update the state of each
>>> viewport in the viewport array independently, which might be
>>> beneficial for some hardware someday, removing ::DepthRange and
>>> ::Scissor would preclude that possibility.
>>>
>>
>> Right... I wonder if we might be better of just tracking a bit per
>> viewport in the gl_context.  I'm assuming we'll end up with something
>> like:
>>
>>  struct gl_viewport_attrib Viewports[MAX_VIEWPORTS];
>>
>> in the gl_context.  It would be easy to add
>>
>>  GLbitfield  _DirtyViewports;
>>
>> along side it.  The various Viewport and DepthRange functions would
>> set bits in that field along with _NEW_VIEWPORT.  Drivers that care
>> could examine (and clear) those bits.
>>
>> We'd do similar for Scissor.
>>
>> Looking at the i965 hardware (and our driver architecture), I believe
>> we have to upload all of the viewports anytime there's a change
>> anyway.  The viewports are just stored as an array in a BO.  See
>> gen7_upload_sf_clip_viewport and similar functions.
>>
>> Marek:  Do you know what Radeon / Gallium want?
>>
>
> The gallium interface takes a start,count array of viewports.  The st/mesa
> state tracker could use the bitfield to determine the changed range.  But
> we also have the CSO module to help filter out redundant state changes.
>
> -Brian
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



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

[Mesa-dev] [v3 8/8] mesa: Update TexStorage to support ARB_texture_view

[Courtney Goeltzenleuchter]

Call TextureView helper function to set TextureView state
appropriately for the TexStorage calls.

Misc updates from review feedback.

Signed-off-by: Courtney Goeltzenleuchter 
---
 src/mesa/main/teximage.c   | 6 ++
 src/mesa/main/texstorage.c | 5 +++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 793c5d3..149b6da 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -48,6 +48,7 @@
 #include "texobj.h"
 #include "texstate.h"
 #include "texstorage.h"
+#include "textureview.h"
 #include "mtypes.h"
 #include "glformats.h"
 
@@ -4348,6 +4349,11 @@ teximagemultisample(GLuint dims, GLenum target, GLsizei 
samples,
   }
 
   texObj->Immutable = immutable;
+
+  if (immutable) {
+ set_texture_view_state(ctx, texObj, target, 1);
+  }
+
   _mesa_update_fbo_texture(ctx, texObj, 0, 0);
}
 }
diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
index 84b8f82..4cdcb02 100644
--- a/src/mesa/main/texstorage.c
+++ b/src/mesa/main/texstorage.c
@@ -38,6 +38,7 @@
 #include "teximage.h"
 #include "texobj.h"
 #include "texstorage.h"
+#include "textureview.h"
 #include "mtypes.h"
 
 
@@ -436,8 +437,8 @@ texstorage(GLuint dims, GLenum target, GLsizei levels, 
GLenum internalformat,
  return;
   }
 
-  texObj->Immutable = GL_TRUE;
-  texObj->ImmutableLevels = levels;
+  set_texture_view_state(ctx, texObj, target, levels);
+
}
 }
 
-- 
1.8.1.2

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

[Mesa-dev] [v3 2/8] mesa: Tracking for ARB_texture_view extension

[Courtney Goeltzenleuchter]

Signed-off-by: Courtney Goeltzenleuchter 
---
 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 104618c..b7da884 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -156,6 +156,7 @@ static const struct extension extension_table[] = {
{ "GL_ARB_texture_rg",  o(ARB_texture_rg),  
GL, 2008 },
{ "GL_ARB_texture_storage", o(dummy_true),  
GL, 2011 },
{ "GL_ARB_texture_storage_multisample", o(ARB_texture_multisample), 
GL, 2012 },
+   { "GL_ARB_texture_view",o(ARB_texture_view),
GL, 2012 },
{ "GL_ARB_texture_swizzle", o(EXT_texture_swizzle), 
GL, 2008 },
{ "GL_ARB_timer_query", o(ARB_timer_query), 
GL, 2010 },
{ "GL_ARB_transform_feedback2", o(ARB_transform_feedback2), 
GL, 2010 },
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 8801d6f..f6ce6d0 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3367,6 +3367,7 @@ struct gl_extensions
GLboolean ARB_texture_query_lod;
GLboolean ARB_texture_rg;
GLboolean ARB_texture_rgb10_a2ui;
+   GLboolean ARB_texture_view;
GLboolean ARB_timer_query;
GLboolean ARB_transform_feedback2;
GLboolean ARB_transform_feedback3;
-- 
1.8.1.2

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

[Mesa-dev] [v3 6/8] mesa: Fill out ARB_texture_view entry points

[Courtney Goeltzenleuchter]

Add Mesa TextureView logic.
Incorporate feedback on ARB_texture_view

Signed-off-by: Courtney Goeltzenleuchter 
---
 src/mesa/main/textureview.c | 562 +++-
 1 file changed, 561 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/textureview.c b/src/mesa/main/textureview.c
index 4a6bd62..1858465 100644
--- a/src/mesa/main/textureview.c
+++ b/src/mesa/main/textureview.c
@@ -40,8 +40,346 @@
 #include "texobj.h"
 #include "texstorage.h"
 #include "textureview.h"
+#include "stdbool.h"
 #include "mtypes.h"
 
+/* Table 3.X.2 (Compatible internal formats for TextureView)
+---
+| Class | Internal formats|
+---
+| VIEW_CLASS_128_BITS   | RGBA32F, RGBA32UI, RGBA32I  |
+---
+| VIEW_CLASS_96_BITS| RGB32F, RGB32UI, RGB32I |
+---
+| VIEW_CLASS_64_BITS| RGBA16F, RG32F, RGBA16UI, RG32UI, RGBA16I,  |
+|   | RG32I, RGBA16, RGBA16_SNORM |
+---
+| VIEW_CLASS_48_BITS| RGB16, RGB16_SNORM, RGB16F, RGB16UI, RGB16I |
+---
+| VIEW_CLASS_32_BITS| RG16F, R11F_G11F_B10F, R32F,|
+|   | RGB10_A2UI, RGBA8UI, RG16UI, R32UI, |
+|   | RGBA8I, RG16I, R32I, RGB10_A2, RGBA8, RG16, |
+|   | RGBA8_SNORM, RG16_SNORM, SRGB8_ALPHA8, RGB9_E5  |
+---
+| VIEW_CLASS_24_BITS| RGB8, RGB8_SNORM, SRGB8, RGB8UI, RGB8I  |
+---
+| VIEW_CLASS_16_BITS| R16F, RG8UI, R16UI, RG8I, R16I, RG8, R16,   |
+|   | RG8_SNORM, R16_SNORM|
+---
+| VIEW_CLASS_8_BITS | R8UI, R8I, R8, R8_SNORM |
+---
+| VIEW_CLASS_RGTC1_RED  | COMPRESSED_RED_RGTC1,   |
+|   | COMPRESSED_SIGNED_RED_RGTC1 |
+---
+| VIEW_CLASS_RGTC2_RG   | COMPRESSED_RG_RGTC2,|
+|   | COMPRESSED_SIGNED_RG_RGTC2  |
+---
+| VIEW_CLASS_BPTC_UNORM | COMPRESSED_RGBA_BPTC_UNORM, |
+|   | COMPRESSED_SRGB_ALPHA_BPTC_UNORM|
+---
+| VIEW_CLASS_BPTC_FLOAT | COMPRESSED_RGB_BPTC_SIGNED_FLOAT,   |
+|   | COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT  |
+---
+ */
+struct internal_format_class_info {
+   GLenum view_class;
+   GLenum internal_format;
+};
+#define INFO(c,f) {GL_##c, GL_##f}
+static const struct internal_format_class_info _compatible_internal_formats[] 
= {
+   INFO(VIEW_CLASS_128_BITS, RGBA32F),
+   INFO(VIEW_CLASS_128_BITS, RGBA32UI),
+   INFO(VIEW_CLASS_128_BITS, RGBA32I),
+   INFO(VIEW_CLASS_96_BITS, RGB32F),
+   INFO(VIEW_CLASS_96_BITS, RGB32UI),
+   INFO(VIEW_CLASS_96_BITS, RGB32I),
+   INFO(VIEW_CLASS_64_BITS, RGBA16F),
+   INFO(VIEW_CLASS_64_BITS, RG32F),
+   INFO(VIEW_CLASS_64_BITS, RGBA16UI),
+   INFO(VIEW_CLASS_64_BITS, RG32UI),
+   INFO(VIEW_CLASS_64_BITS, RGBA16I),
+   INFO(VIEW_CLASS_64_BITS, RG32I),
+   INFO(VIEW_CLASS_64_BITS, RGBA16),
+   INFO(VIEW_CLASS_64_BITS, RGBA16_SNORM),
+   INFO(VIEW_CLASS_48_BITS, RGB16),
+   INFO(VIEW_CLASS_48_BITS, RGB16_SNORM),
+   INFO(VIEW_CLASS_48_BITS, RGB16F),
+   INFO(VIEW_CLASS_48_BITS, RGB16UI),
+   INFO(VIEW_CLASS_48_BITS, RGB16I),
+   INFO(VIEW_CLASS_32_BITS, RG16F),
+   INFO(VIEW_CLASS_32_BITS, R11F_G11F_B10F),
+   INFO(VIEW_CLASS_32_BITS, R32F),
+   INFO(VIEW_CLASS_32_BITS, RGB10_A2UI),
+   INFO(VIEW_CLASS_32_BITS, RGBA8UI),
+   INFO(VIEW_CLASS_32_BITS, RG16UI),
+   INFO(VIEW_CLASS_32_BITS, R32UI),
+   INFO(VIEW_CLASS_32_BITS, RGBA8I),
+   INFO(VIEW_CLASS_32_BITS, RG16I),
+   INFO(VIEW_CLASS_32_BITS, R32I),
+   INFO(VIEW_CLASS_32_BITS, RGB10_A2),
+   INFO(VIEW_CLASS_32_BITS, RGBA8),
+   INFO(VIEW_CLASS_32_BITS, RG16),
+   INFO(

[Mesa-dev] [v3 5/8] mesa: Add driver entry point for ARB_texture_view

[Courtney Goeltzenleuchter]

Signed-off-by: Courtney Goeltzenleuchter 
---
 src/mesa/drivers/common/driverfuncs.c | 3 +++
 src/mesa/main/dd.h| 5 +
 2 files changed, 8 insertions(+)

diff --git a/src/mesa/drivers/common/driverfuncs.c 
b/src/mesa/drivers/common/driverfuncs.c
index 5faa98a..f185688 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -211,6 +211,9 @@ _mesa_init_driver_functions(struct dd_function_table 
*driver)
/* GL_ARB_texture_storage */
driver->AllocTextureStorage = _mesa_alloc_texture_storage;
 
+   /* GL_ARB_texture_view */
+   driver->TextureView = NULL;
+
/* GL_ARB_texture_multisample */
driver->GetSamplePosition = NULL;
 }
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index b5b874f..3e263f4 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -375,6 +375,11 @@ struct dd_function_table {
 GLsizei levels, GLsizei width,
 GLsizei height, GLsizei depth);
 
+   /** Called as part of glTextureView to add views to origTexObj */
+   GLboolean (*TextureView)(struct gl_context *ctx,
+struct gl_texture_object *texObj,
+struct gl_texture_object *origTexObj);
+
/**
 * Map a renderbuffer into user space.
 * \param mode  bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT and
-- 
1.8.1.2

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

[Mesa-dev] [v3 0/8] Add ARB_texture_view

[Courtney Goeltzenleuchter]

The following patches add the necessary functions to Mesa
to support ARB_texture_view. These patches do not include
the actual driver elements, just the device independent portion.
This extension requires ARB_texture_storage.

The extension supports one new API call, glTextureView and
a handful of enums that have been added as queriable texture
parameters.

Adds one new driver entry point for the driver to
map the view specified onto the origtexture given.

Includes review feedback and a bug fix in compatible_format.

Passes non-rendering ARB_texture_view piglit tests.

Courtney Goeltzenleuchter (8):
  mesa: Add API definitions for ARB_texture_view
  mesa: Tracking for ARB_texture_view extension
  mesa: update texture object for ARB_texture_view
  mesa: ARB_texture_view get parameters
  mesa: Add driver entry point for ARB_texture_view
  mesa: Fill out ARB_texture_view entry points
  mesa: add texture_view helper function for TexStorage
  mesa: Update TexStorage to support ARB_texture_view

 src/mapi/glapi/gen/ARB_texture_view.xml |  23 ++
 src/mapi/glapi/gen/Makefile.am  |   1 +
 src/mapi/glapi/gen/gl_API.xml   |   4 +-
 src/mapi/glapi/gen/gl_genexec.py|   1 +
 src/mesa/Makefile.sources   |   1 +
 src/mesa/SConscript |   1 +
 src/mesa/drivers/common/driverfuncs.c   |   3 +
 src/mesa/main/dd.h  |   5 +
 src/mesa/main/extensions.c  |   1 +
 src/mesa/main/mtypes.h  |   6 +
 src/mesa/main/tests/dispatch_sanity.cpp |   2 +-
 src/mesa/main/teximage.c|   6 +
 src/mesa/main/texparam.c|  60 ++-
 src/mesa/main/texstorage.c  |   5 +-
 src/mesa/main/textureview.c | 684 
 src/mesa/main/textureview.h |  43 ++
 16 files changed, 838 insertions(+), 8 deletions(-)
 create mode 100644 src/mapi/glapi/gen/ARB_texture_view.xml
 create mode 100644 src/mesa/main/textureview.c
 create mode 100644 src/mesa/main/textureview.h

-- 
1.8.1.2

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

[Mesa-dev] [v3 7/8] mesa: add texture_view helper function for TexStorage

[Courtney Goeltzenleuchter]

Add helper function to set texture_view state from TexStorage calls.

Signed-off-by: Courtney Goeltzenleuchter 
---
 src/mesa/main/textureview.c | 59 +
 src/mesa/main/textureview.h |  4 +++
 2 files changed, 63 insertions(+)

diff --git a/src/mesa/main/textureview.c b/src/mesa/main/textureview.c
index 1858465..a25b928 100644
--- a/src/mesa/main/textureview.c
+++ b/src/mesa/main/textureview.c
@@ -379,6 +379,65 @@ compatible_format(struct gl_context *ctx, struct 
gl_texture_object *origTexObj,
_mesa_lookup_enum_by_nr(origInternalFormat));
return GL_FALSE;
 }
+/**
+ * Helper function for TexStorage to set TextureView state
+ */
+void
+set_texture_view_state(struct gl_context *ctx, struct gl_texture_object 
*texObj,
+   GLenum target, GLuint levels)
+{
+   struct gl_texture_image *texImage;
+
+   /* Get a reference to what will become this View's base level */
+   texImage = _mesa_select_tex_image(ctx, texObj, target, 0);
+
+   /* If the command is successful,
+* TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
+* TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become levels.
+* If the texture target is TEXTURE_1D_ARRAY then
+* TEXTURE_VIEW_NUM_LAYERS becomes height.
+* If the texture target is TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY,
+* or TEXTURE_2D_MULTISAMPLE_ARRAY then TEXTURE_VIEW_NUM_LAYERS becomes 
depth.
+* If the texture target is TEXTURE_CUBE_MAP, then
+* TEXTURE_VIEW_NUM_LAYERS becomes 6.
+* For any other texture target, TEXTURE_VIEW_NUM_LAYERS becomes 1.
+* 
+* ARB_texture_multisample: Multisample textures do
+* not have multiple image levels.
+*/
+
+   texObj->Immutable = GL_TRUE;
+   texObj->ImmutableLevels = levels;
+   texObj->MinLevel = 0;
+   texObj->NumLevels = levels;
+   texObj->MinLayer = 0;
+   texObj->NumLayers = 1;
+   switch (target) {
+   case GL_TEXTURE_1D_ARRAY:
+  texObj->NumLayers = texImage->Height;
+  break;
+
+   case GL_TEXTURE_2D_MULTISAMPLE:
+  texObj->NumLevels = 1;
+  texObj->ImmutableLevels = 1;
+  break;
+
+   case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
+  texObj->NumLevels = 1;
+  texObj->ImmutableLevels = 1;
+  /* fall through to set NumLayers */
+
+   case GL_TEXTURE_2D_ARRAY:
+   case GL_TEXTURE_CUBE_MAP_ARRAY:
+  texObj->NumLayers = texImage->Depth;
+  break;
+
+   case GL_TEXTURE_CUBE_MAP:
+  texObj->NumLayers = 6;
+  break;
+
+   }
+}
 
 /**
  * glTextureView (ARB_texture_view)
diff --git a/src/mesa/main/textureview.h b/src/mesa/main/textureview.h
index c2f0f32..36a8ed3 100644
--- a/src/mesa/main/textureview.h
+++ b/src/mesa/main/textureview.h
@@ -36,4 +36,8 @@ _mesa_TextureView(GLuint texture, GLenum target, GLuint 
origtexture,
   GLuint minlevel, GLuint numlevels,
   GLuint minlayer, GLuint numlayers);
 
+extern void
+set_texture_view_state(struct gl_context *ctx, struct gl_texture_object 
*texObj,
+   GLenum target, GLuint levels);
+
 #endif /* TEXTUREVIEW_H */
-- 
1.8.1.2

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

[Mesa-dev] [v3 3/8] mesa: update texture object for ARB_texture_view

[Courtney Goeltzenleuchter]

Add state needed by glTextureView to the gl_texture_object.

Signed-off-by: Courtney Goeltzenleuchter 
---
 src/mesa/main/mtypes.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index f6ce6d0..82fcd61 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1193,6 +1193,11 @@ struct gl_texture_object
 pressure? */
GLboolean Immutable;/**< GL_ARB_texture_storage */
 
+   GLuint MinLevel;/**< GL_ARB_texture_view */
+   GLuint MinLayer;/**< GL_ARB_texture_view */
+   GLuint NumLevels;   /**< GL_ARB_texture_view */
+   GLuint NumLayers;   /**< GL_ARB_texture_view */
+
/** Actual texture images, indexed by [cube face] and [mipmap level] */
struct gl_texture_image *Image[MAX_FACES][MAX_TEXTURE_LEVELS];
 
-- 
1.8.1.2

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

[Mesa-dev] [v3 1/8] mesa: Add API definitions for ARB_texture_view

[Courtney Goeltzenleuchter]

Stub in glTextureView API call to go with the
glTextureView API xml definition.
Includes dispatch test for glTextureView

Signed-off-by: Courtney Goeltzenleuchter 
---
 src/mapi/glapi/gen/ARB_texture_view.xml | 23 
 src/mapi/glapi/gen/Makefile.am  |  1 +
 src/mapi/glapi/gen/gl_API.xml   |  4 +-
 src/mapi/glapi/gen/gl_genexec.py|  1 +
 src/mesa/Makefile.sources   |  1 +
 src/mesa/SConscript |  1 +
 src/mesa/main/tests/dispatch_sanity.cpp |  2 +-
 src/mesa/main/textureview.c | 65 +
 src/mesa/main/textureview.h | 39 
 9 files changed, 135 insertions(+), 2 deletions(-)
 create mode 100644 src/mapi/glapi/gen/ARB_texture_view.xml
 create mode 100644 src/mesa/main/textureview.c
 create mode 100644 src/mesa/main/textureview.h

diff --git a/src/mapi/glapi/gen/ARB_texture_view.xml 
b/src/mapi/glapi/gen/ARB_texture_view.xml
new file mode 100644
index 000..3e6b8c9
--- /dev/null
+++ b/src/mapi/glapi/gen/ARB_texture_view.xml
@@ -0,0 +1,23 @@
+
+
+
+
+
+
+
+
+
+   
+  
+  
+  
+  
+  
+  
+  
+  
+   
+
+
+
+
diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
index 476d943..8c08119 100644
--- a/src/mapi/glapi/gen/Makefile.am
+++ b/src/mapi/glapi/gen/Makefile.am
@@ -124,6 +124,7 @@ API_XML = \
ARB_texture_rg.xml \
ARB_texture_storage_multisample.xml \
ARB_texture_storage.xml \
+   ARB_texture_view.xml \
ARB_vertex_array_object.xml \
ARB_vertex_attrib_binding.xml \
AMD_draw_buffers_blend.xml \
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index a2d914a..ca4bdd3 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -8458,8 +8458,10 @@
 
 
 
-
 
+
+
+http://www.w3.org/2001/XInclude"/>
 http://www.w3.org/2001/XInclude"/>
 
 
diff --git a/src/mapi/glapi/gen/gl_genexec.py b/src/mapi/glapi/gen/gl_genexec.py
index 3ce190f..b557b3b 100644
--- a/src/mapi/glapi/gen/gl_genexec.py
+++ b/src/mapi/glapi/gen/gl_genexec.py
@@ -102,6 +102,7 @@ header = """/**
 #include "main/texstate.h"
 #include "main/texstorage.h"
 #include "main/texturebarrier.h"
+#include "main/textureview.h"
 #include "main/transformfeedback.h"
 #include "main/mtypes.h"
 #include "main/varray.h"
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index a84f8a7..39525bc 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -103,6 +103,7 @@ MAIN_FILES = \
$(SRCDIR)main/texstate.c \
$(SRCDIR)main/texstorage.c \
$(SRCDIR)main/texstore.c \
+$(SRCDIR)main/textureview.c \
$(SRCDIR)main/texturebarrier.c \
$(SRCDIR)main/transformfeedback.c \
$(SRCDIR)main/uniforms.c \
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index a2bb9f1..bb9b304 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -133,6 +133,7 @@ main_sources = [
 'main/texstorage.c',
 'main/texstore.c',
 'main/texturebarrier.c',
+'main/textureview.c',
 'main/transformfeedback.c',
 'main/uniform_query.cpp',
 'main/uniforms.c',
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
b/src/mesa/main/tests/dispatch_sanity.cpp
index 922f0ac..d5388e3 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -853,7 +853,7 @@ const struct function gl_core_functions_possible[] = {
 // { "glDispatchCompute", 43, -1 }, // XXX: Add to xml
 // { "glDispatchComputeIndirect", 43, -1 }, // XXX: Add to xml
 // { "glCopyImageSubData", 43, -1 },// XXX: Add to xml
-// { "glTextureView", 43, -1 }, // XXX: Add to xml
+   { "glTextureView", 43, -1 },
{ "glBindVertexBuffer", 43, -1 },
{ "glVertexAttribFormat", 43, -1 },
{ "glVertexAttribIFormat", 43, -1 },
diff --git a/src/mesa/main/textureview.c b/src/mesa/main/textureview.c
new file mode 100644
index 000..4a6bd62
--- /dev/null
+++ b/src/mesa/main/textureview.c
@@ -0,0 +1,65 @@
+/*
+ * Mesa 3-D graphics library
+ *
+ * Copyright (C) 2013 LunarG, Inc.
+ *
+ * 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 PA

[Mesa-dev] [v3 4/8] mesa: ARB_texture_view get parameters

[Courtney Goeltzenleuchter]

Add support for ARB_texture_view get parameters:
GL_TEXTURE_VIEW_MIN_LEVEL
GL_TEXTURE_VIEW_NUM_LEVELS
GL_TEXTURE_VIEW_MIN_LAYER
GL_TEXTURE_VIEW_NUM_LAYERS

Incorporate feedback regarding when to allow query of
GL_TEXTURE_IMMUTABLE_LEVELS.

Signed-off-by: Courtney Goeltzenleuchter 
---
 src/mesa/main/texparam.c | 60 
 1 file changed, 56 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index d56b7d9..b3e2d0a 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -1565,9 +1565,35 @@ _mesa_GetTexParameterfv( GLenum target, GLenum pname, 
GLfloat *params )
  break;
 
   case GL_TEXTURE_IMMUTABLE_LEVELS:
- if (!_mesa_is_gles3(ctx))
+ if (_mesa_is_gles3(ctx) ||
+ (_mesa_is_desktop_gl(ctx) && ctx->Extensions.ARB_texture_view))
+*params = (GLfloat) obj->ImmutableLevels;
+ else
+goto invalid_pname;
+ break;
+
+  case GL_TEXTURE_VIEW_MIN_LEVEL:
+ if (!ctx->Extensions.ARB_texture_view)
+goto invalid_pname;
+ *params = (GLfloat) obj->MinLevel;
+ break;
+
+  case GL_TEXTURE_VIEW_NUM_LEVELS:
+ if (!ctx->Extensions.ARB_texture_view)
+goto invalid_pname;
+ *params = (GLfloat) obj->NumLevels;
+ break;
+
+  case GL_TEXTURE_VIEW_MIN_LAYER:
+ if (!ctx->Extensions.ARB_texture_view)
+goto invalid_pname;
+ *params = (GLfloat) obj->MinLayer;
+ break;
+
+  case GL_TEXTURE_VIEW_NUM_LAYERS:
+ if (!ctx->Extensions.ARB_texture_view)
 goto invalid_pname;
- *params = (GLfloat) obj->ImmutableLevels;
+ *params = (GLfloat) obj->NumLayers;
  break;
 
   case GL_REQUIRED_TEXTURE_IMAGE_UNITS_OES:
@@ -1746,9 +1772,35 @@ _mesa_GetTexParameteriv( GLenum target, GLenum pname, 
GLint *params )
  break;
 
   case GL_TEXTURE_IMMUTABLE_LEVELS:
- if (!_mesa_is_gles3(ctx))
+ if (_mesa_is_gles3(ctx) ||
+ (_mesa_is_desktop_gl(ctx) && ctx->Extensions.ARB_texture_view))
+*params = obj->ImmutableLevels;
+ else
+goto invalid_pname;
+ break;
+
+  case GL_TEXTURE_VIEW_MIN_LEVEL:
+ if (!ctx->Extensions.ARB_texture_view)
+goto invalid_pname;
+ *params = (GLint) obj->MinLevel;
+ break;
+
+  case GL_TEXTURE_VIEW_NUM_LEVELS:
+ if (!ctx->Extensions.ARB_texture_view)
+goto invalid_pname;
+ *params = (GLint) obj->NumLevels;
+ break;
+
+  case GL_TEXTURE_VIEW_MIN_LAYER:
+ if (!ctx->Extensions.ARB_texture_view)
+goto invalid_pname;
+ *params = (GLint) obj->MinLayer;
+ break;
+
+  case GL_TEXTURE_VIEW_NUM_LAYERS:
+ if (!ctx->Extensions.ARB_texture_view)
 goto invalid_pname;
- *params = obj->ImmutableLevels;
+ *params = (GLint) obj->NumLayers;
  break;
 
   case GL_REQUIRED_TEXTURE_IMAGE_UNITS_OES:
-- 
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] mapi: Add better visibility checks

[Emil Velikov]

On 19/11/13 21:27, Alexander von Gluck IV wrote:
> On Tue, Nov 19, 2013 at 2:55 PM, Emil Velikov 
> wrote:
>> On 17/11/13 18:11, Alexander von Gluck IV wrote:
>>>  * gl.h ensures gcc is 4.x or later before using
>>>hidden visibility. This change matches that behaviour
>>>and ensures better compatibility for older gcc versions.
>>>
>> Hi Alexander,
>>
>> AFAICS there are, currently, 11 cases of such ifdef spaghetti in mesa.
>>
>> IMHO we can easily compact all _but_ the following two into into a
>> single header, in a similar fashion to the inline macro (c99_compat.h).
>>
>> include/GL/gl.h
>> include/KHR/khrplatform.h -> bump the gcc version to 4?
>>
>> The gcc manual[1] indicates that the "new C++ visibility support" is
>> available as of gcc4[2]. Although for the sake of me I cannot find the
>> source of the original C visibility support. Hmm the original
>> khrplatform.h header does not have any of the GCC checks.
>>
>> Chia-I Wu would you have any idea when C visibility support was added to
>> gcc? Would you have any comment on bumping the version to 4.0 ?
>>
>> Would you mind ripping all this stuff out to a header rather than
>> carrying it around any more ?
>>
>> How do other devs feel on the subject ?
>>
> 
> Sounds good to me.  I understand Mesa defines a minimum gcc version, but
> this would increase portability of Mesa while reducing cruft.
> 
IMHO bumping the mesa gcc requirement is a bit of an overkill atm, as
most of the gcc version checks are isolated within a few header files.

include/c99/stdbool.h
include/c99_compat.h
src/mesa/main/compiler.h
src/gallium/auxiliary/util/u_atomic.h
src/gallium/auxiliary/util/u_math.h
src/gallium/include/pipe/p_compiler.h
src/gallium/include/pipe/p_config.h
src/gtest/include/gtest/internal/gtest-port.h
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
src/mesa/main/imports.c
src/mesa/main/imports.h

Quite a few of the above are dupes due to the mesa/gallium split.

Cheers,
Emil
> I went with the 4.0 version as gcc's own webpage shows a 4.0 check. [1]
> 
>>
>>
>> [1] http://gcc.gnu.org/wiki/Visibility
>> [2] http://gcc.gnu.org/gcc-4.0/changes.html
>>
>>
>>>  ---
>>>   src/mapi/glapi/glapi.h |2 +-
>>>   src/mapi/u_compiler.h  |2 +-
>>>   2 files changed, 2 insertions(+), 2 deletions(-)
>>>  
>>>  diff --git a/src/mapi/glapi/glapi.h b/src/mapi/glapi/glapi.h
>>>  index c764271..8e17dc7 100644
>>>  --- a/src/mapi/glapi/glapi.h
>>>  +++ b/src/mapi/glapi/glapi.h
>>>  @@ -61,7 +61,7 @@ extern "C" {
>>>   #else
>>>   #  define _GLAPI_EXPORT __declspec(dllimport)
>>>   #endif
>>>  -#  elif defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >=
>>> 0x590))
>>>  +#  elif (defined(__GNUC__) && __GNUC__ >= 4) ||
>>> (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))
>>>   #define _GLAPI_EXPORT __attribute__((visibility("default")))
>>>   #  else
>>>   #define _GLAPI_EXPORT
>>>  diff --git a/src/mapi/u_compiler.h b/src/mapi/u_compiler.h
>>>  index f376e97..66c961e 100644
>>>  --- a/src/mapi/u_compiler.h
>>>  +++ b/src/mapi/u_compiler.h
>>>  @@ -11,7 +11,7 @@
>>> /* Function visibility */
>>>   #ifndef PUBLIC
>>>  -#  if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >=
>>> 0x590))
>>>  +#  if (defined(__GNUC__) && __GNUC__ >= 4) || (defined(__SUNPRO_C)
>>> && (__SUNPRO_C >= 0x590))
>>>   #define PUBLIC __attribute__((visibility("default")))
>>>   #  elif defined(_MSC_VER)
>>>   #define PUBLIC __declspec(dllexport)
>>>  
>>>
>>
> 

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

[Mesa-dev] [PATCH V2] glsl: Improve error message when attemping assignment to unsized array

[Timothy Arceri]

V2: Return after error to avoid cascading error messages and
removed redundant "to" from error message

Signed-off-by: Timothy Arceri 
---
 src/glsl/ast_to_hir.cpp | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 76b256c..d5a45fd 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -696,9 +696,15 @@ validate_assignment(struct _mesa_glsl_parse_state *state,
 * Note: Whole-array assignments are not permitted in GLSL 1.10, but this
 * is handled by ir_dereference::is_lvalue.
 */
-   if (is_initializer && lhs_type->is_unsized_array() && rhs->type->is_array()
+   if (lhs_type->is_unsized_array() && rhs->type->is_array()
&& (lhs_type->element_type() == rhs->type->element_type())) {
-  return rhs;
+  if (is_initializer) {
+ return rhs;
+  } else {
+ _mesa_glsl_error(&loc, state,
+  "implicitly sized arrays cannot be assigned");
+ return NULL;
+  }
}
 
/* Check for implicit conversion in GLSL 1.20 */
-- 
1.8.3.1

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

Re: [Mesa-dev] [PATCH] mapi: Add better visibility checks

[Alexander von Gluck IV]

On Tue, Nov 19, 2013 at 2:55 PM, Emil Velikov 
 wrote:

On 17/11/13 18:11, Alexander von Gluck IV wrote:

 * gl.h ensures gcc is 4.x or later before using
   hidden visibility. This change matches that behaviour
   and ensures better compatibility for older gcc versions.


Hi Alexander,

AFAICS there are, currently, 11 cases of such ifdef spaghetti in mesa.

IMHO we can easily compact all _but_ the following two into into a
single header, in a similar fashion to the inline macro 
(c99_compat.h).


include/GL/gl.h
include/KHR/khrplatform.h -> bump the gcc version to 4?

The gcc manual[1] indicates that the "new C++ visibility support" is
available as of gcc4[2]. Although for the sake of me I cannot find the
source of the original C visibility support. Hmm the original
khrplatform.h header does not have any of the GCC checks.

Chia-I Wu would you have any idea when C visibility support was added 
to

gcc? Would you have any comment on bumping the version to 4.0 ?

Would you mind ripping all this stuff out to a header rather than
carrying it around any more ?

How do other devs feel on the subject ?



Sounds good to me.  I understand Mesa defines a minimum gcc version, 
but

this would increase portability of Mesa while reducing cruft.

I went with the 4.0 version as gcc's own webpage shows a 4.0 check. [1]




[1] http://gcc.gnu.org/wiki/Visibility
[2] http://gcc.gnu.org/gcc-4.0/changes.html



 ---
  src/mapi/glapi/glapi.h |2 +-
  src/mapi/u_compiler.h  |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/src/mapi/glapi/glapi.h b/src/mapi/glapi/glapi.h

 index c764271..8e17dc7 100644
 --- a/src/mapi/glapi/glapi.h
 +++ b/src/mapi/glapi/glapi.h
 @@ -61,7 +61,7 @@ extern "C" {
  #else
  #  define _GLAPI_EXPORT __declspec(dllimport)
  #endif
 -#  elif defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C 
>= 0x590))
 +#  elif (defined(__GNUC__) && __GNUC__ >= 4) || 
(defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))

  #define _GLAPI_EXPORT __attribute__((visibility("default")))
  #  else
  #define _GLAPI_EXPORT
 diff --git a/src/mapi/u_compiler.h b/src/mapi/u_compiler.h
 index f376e97..66c961e 100644
 --- a/src/mapi/u_compiler.h
 +++ b/src/mapi/u_compiler.h
 @@ -11,7 +11,7 @@
  
  /* Function visibility */

  #ifndef PUBLIC
 -#  if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 
0x590))
 +#  if (defined(__GNUC__) && __GNUC__ >= 4) || (defined(__SUNPRO_C) 
&& (__SUNPRO_C >= 0x590))

  #define PUBLIC __attribute__((visibility("default")))
  #  elif defined(_MSC_VER)
  #define PUBLIC __declspec(dllexport)
 





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

[Mesa-dev] [Bug 70920] [PIGLIT, radeonsi] SIGSEGV for shaders/glsl-fs-inline-explosion

[bugzilla-daemon]

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

--- Comment #3 from Ian Romanick  ---
The cause has been known since the tests were added in 2010:

commit 656cc65b2d3782c078d36342d0deec9886514520
Author: Luca Barbieri 
Date:   Mon Sep 6 04:56:05 2010 +0200

add GLSL inlining/unroll limit tests, currently failing

The current GLSL compiler inlines everything indiscriminately,
and unrolls all loops that have a small iteration count.

This is a bad idea, because it can lead to exponential growth of
the code, as these test cases illustrate.

On a naive implementation (like current Mesa) these tests will
attempt to allocate more than 2^64 bytes of RAM, ensuring failure.

A smart implementation will instead generate actual calls/loops, and the
test passes, since the branch protecting the functions/loops is not taken.

Currently they aren't added to any profile since they obviously cause
piglit to hang until memory is exhausted, possibly causing lots of
swap thrashing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mapi: Add better visibility checks

[Emil Velikov]

On 17/11/13 18:11, Alexander von Gluck IV wrote:
> * gl.h ensures gcc is 4.x or later before using
>   hidden visibility. This change matches that behaviour
>   and ensures better compatibility for older gcc versions.
Hi Alexander,

AFAICS there are, currently, 11 cases of such ifdef spaghetti in mesa.

IMHO we can easily compact all _but_ the following two into into a
single header, in a similar fashion to the inline macro (c99_compat.h).

include/GL/gl.h
include/KHR/khrplatform.h -> bump the gcc version to 4?

The gcc manual[1] indicates that the "new C++ visibility support" is
available as of gcc4[2]. Although for the sake of me I cannot find the
source of the original C visibility support. Hmm the original
khrplatform.h header does not have any of the GCC checks.

Chia-I Wu would you have any idea when C visibility support was added to
gcc? Would you have any comment on bumping the version to 4.0 ?

Would you mind ripping all this stuff out to a header rather than
carrying it around any more ?

How do other devs feel on the subject ?

Thanks,
Emil

[1] http://gcc.gnu.org/wiki/Visibility
[2] http://gcc.gnu.org/gcc-4.0/changes.html


> ---
>  src/mapi/glapi/glapi.h |2 +-
>  src/mapi/u_compiler.h  |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mapi/glapi/glapi.h b/src/mapi/glapi/glapi.h
> index c764271..8e17dc7 100644
> --- a/src/mapi/glapi/glapi.h
> +++ b/src/mapi/glapi/glapi.h
> @@ -61,7 +61,7 @@ extern "C" {
>  #else
>  #  define _GLAPI_EXPORT __declspec(dllimport)
>  #endif
> -#  elif defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))
> +#  elif (defined(__GNUC__) && __GNUC__ >= 4) || (defined(__SUNPRO_C) && 
> (__SUNPRO_C >= 0x590))
>  #define _GLAPI_EXPORT __attribute__((visibility("default")))
>  #  else
>  #define _GLAPI_EXPORT
> diff --git a/src/mapi/u_compiler.h b/src/mapi/u_compiler.h
> index f376e97..66c961e 100644
> --- a/src/mapi/u_compiler.h
> +++ b/src/mapi/u_compiler.h
> @@ -11,7 +11,7 @@
>  
>  /* Function visibility */
>  #ifndef PUBLIC
> -#  if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))
> +#  if (defined(__GNUC__) && __GNUC__ >= 4) || (defined(__SUNPRO_C) && 
> (__SUNPRO_C >= 0x590))
>  #define PUBLIC __attribute__((visibility("default")))
>  #  elif defined(_MSC_VER)
>  #define PUBLIC __declspec(dllexport)
> 

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

Re: [Mesa-dev] [PATCH V3 06/13] vbo: Flesh out implementation of indirect draws

[Chris Forbes]

I've inherited a fair amount of sillyness from the original patches...
sorry, I'll clean that up.

On Wed, Nov 20, 2013 at 9:15 AM, Ian Romanick  wrote:
> With the issues below fixed,
>
> Reviewed-by: Ian Romanick 
>
> On 11/09/2013 01:02 AM, Chris Forbes wrote:
>> Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
>>
>> Signed-off-by: Chris Forbes 
>> ---
>>  src/mesa/vbo/vbo_exec_array.c | 216 
>> ++
>>  1 file changed, 216 insertions(+)
>>
>> diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
>> index 4ea10ee..1c6b8b3 100644
>> --- a/src/mesa/vbo/vbo_exec_array.c
>> +++ b/src/mesa/vbo/vbo_exec_array.c
>> @@ -1564,6 +1564,164 @@ vbo_exec_DrawTransformFeedbackStreamInstanced(GLenum 
>> mode, GLuint name,
>> vbo_draw_transform_feedback(ctx, mode, obj, stream, primcount);
>>  }
>>
>> +static void
>> +vbo_validated_drawarraysindirect(struct gl_context *ctx,
>> + GLenum mode, const GLvoid *indirect)
>> +{
>> +   struct vbo_context *vbo = vbo_context(ctx);
>> +   struct vbo_exec_context *exec = &vbo->exec;
>> +   struct _mesa_prim prim[1];
>> +
>> +   vbo_bind_arrays(ctx);
>> +
>> +   memset(prim, 0, sizeof(prim));
>> +   prim[0].begin = 1;
>> +   prim[0].end = 1;
>> +   prim[0].mode = mode;
>> +   prim[0].indirect_offset = (GLsizeiptr)indirect;
>> +
>> +   /* NOTE: We do NOT want to handle primitive restart here, nor perform any
>> +* other checks that require knowledge of the values in the command 
>> buffer.
>> +* That would deafeat the whole purpose of this function.
>> +*/
>> +
>> +   check_buffers_are_unmapped(exec->array.inputs);
>> +   vbo->draw_prims(ctx, prim, 1,
>> +   NULL, GL_TRUE, 0, ~0,
>> +   NULL,
>> +   ctx->DrawIndirectBuffer);
>> +
>> +   if (MESA_DEBUG_FLAGS & DEBUG_ALWAYS_FLUSH)
>> +  _mesa_flush(ctx);
>> +}
>> +
>> +static void
>> +vbo_validated_multidrawarraysindirect(struct gl_context *ctx,
>> +  GLenum mode,
>> +  const GLvoid *indirect,
>> +  GLsizei primcount, GLsizei stride)
>> +{
>> +   struct vbo_context *vbo = vbo_context(ctx);
>> +   struct vbo_exec_context *exec = &vbo->exec;
>> +   struct _mesa_prim *prim;
>> +   GLsizei i;
>> +   GLsizeiptr offset = (GLsizeiptr)indirect;
>> +
>> +   if (primcount == 0)
>> +  return;
>> +   prim = calloc(1, primcount * sizeof(*prim));
>
>   prim = calloc(primcount, sizeof(*prim));
>
> because primcount could be 0x7fff, and that would overflow on 32-bit
> leading to sadness.  calloc will do the right thing.
>
>> +   if (prim == NULL) {
>> +  _mesa_error(ctx, GL_OUT_OF_MEMORY, "glMultiDrawArraysIndirect");
>> +  return;
>> +   }
>> +
>> +   vbo_bind_arrays(ctx);
>> +
>> +   memset(prim, 0, primcount * sizeof(*prim));
>
> But you used calloc. :(
>
>> +   prim[0].begin = 1;
>> +   prim[primcount - 1].end = 1;
>> +   for (i = 0; i < primcount; ++i, offset += stride) {
>> +  prim[i].mode = mode;
>> +  prim[i].indirect_offset = offset;
>> +   }
>> +
>> +   check_buffers_are_unmapped(exec->array.inputs);
>> +   vbo->draw_prims(ctx, prim, primcount,
>> +   NULL, GL_TRUE, 0, ~0,
>> +   NULL,
>> +   ctx->DrawIndirectBuffer);
>> +
>> +   free(prim);
>> +
>> +   if (MESA_DEBUG_FLAGS & DEBUG_ALWAYS_FLUSH)
>> +  _mesa_flush(ctx);
>> +}
>> +
>> +static void
>> +vbo_validated_drawelementsindirect(struct gl_context *ctx,
>> +   GLenum mode, GLenum type,
>> +   const GLvoid *indirect)
>> +{
>> +   struct vbo_context *vbo = vbo_context(ctx);
>> +   struct vbo_exec_context *exec = &vbo->exec;
>> +   struct _mesa_index_buffer ib;
>> +   struct _mesa_prim prim[1];
>> +
>> +   vbo_bind_arrays(ctx);
>> +
>> +   ib.count = 0; /* unknown */
>> +   ib.type = type;
>> +   ib.obj = ctx->Array.ArrayObj->ElementArrayBufferObj;
>> +   ib.ptr = NULL;
>> +
>> +   memset(prim, 0, sizeof(prim));
>> +   prim[0].begin = 1;
>> +   prim[0].end = 1;
>> +   prim[0].mode = mode;
>> +   prim[0].indexed = 1;
>> +   prim[0].indirect_offset = (GLsizeiptr)indirect;
>> +
>> +   check_buffers_are_unmapped(exec->array.inputs);
>> +   vbo->draw_prims(ctx, prim, 1,
>> +   &ib, GL_TRUE, 0, ~0,
>> +   NULL,
>> +   ctx->DrawIndirectBuffer);
>> +
>> +   if (MESA_DEBUG_FLAGS & DEBUG_ALWAYS_FLUSH)
>> +  _mesa_flush(ctx);
>> +}
>> +
>> +static void
>> +vbo_validated_multidrawelementsindirect(struct gl_context *ctx,
>> +GLenum mode, GLenum type,
>> +const GLvoid *indirect,
>> +GLsizei primcount, GLsizei stride)
>> +{
>> +   struct vbo_context *vbo = vbo_context(ctx);
>> +   struct vbo_exec_context *exec

Re: [Mesa-dev] [PATCH] mesa: enable GL_TEXTURE_LOD_BIAS set/get

[Ian Romanick]

On 11/19/2013 01:05 AM, Tapani Pälli wrote:
> Earlier comments suggest this was removed from GL core spec but it is
> still there. Enabling makes 'texture_lod_bias_getter' Khronos
> conformance tests pass, also removes some errors from Metro Last Light
> game which is using this API.

D'oh!

> Signed-off-by: Tapani Pälli 

Reviewed-by: Ian Romanick 

I agree with Ken that this is a candidate for all the stable branches.

> ---
>  src/mesa/main/texparam.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
> index d56b7d9..e1bfeb0 100644
> --- a/src/mesa/main/texparam.c
> +++ b/src/mesa/main/texparam.c
> @@ -684,11 +684,7 @@ set_tex_parameterf(struct gl_context *ctx,
>return GL_FALSE;
>  
> case GL_TEXTURE_LOD_BIAS:
> -  /* NOTE: this is really part of OpenGL 1.4, not EXT_texture_lod_bias.
> -   * It was removed in core-profile, and it has never existed in OpenGL
> -   * ES.
> -   */

I think I'd leave the "NOTE" part of the comment.  That preceeds b3dd524a.

> -  if (ctx->API != API_OPENGL_COMPAT)
> +  if (_mesa_is_gles(ctx))
>   goto invalid_pname;
>  
>if (!target_allows_setting_sampler_parameters(texObj->Target))
> @@ -1513,7 +1509,7 @@ _mesa_GetTexParameterfv( GLenum target, GLenum pname, 
> GLfloat *params )
>   *params = (GLfloat) obj->DepthMode;
>   break;
>case GL_TEXTURE_LOD_BIAS:
> - if (ctx->API != API_OPENGL_COMPAT)
> + if (_mesa_is_gles(ctx))
>  goto invalid_pname;
>  
>   *params = obj->Sampler.LodBias;
> @@ -1701,10 +1697,13 @@ _mesa_GetTexParameteriv( GLenum target, GLenum pname, 
> GLint *params )
>   *params = (GLint) obj->DepthMode;
>   break;
>case GL_TEXTURE_LOD_BIAS:
> - if (ctx->API != API_OPENGL_COMPAT)
> + if (_mesa_is_gles(ctx))
>  goto invalid_pname;
>  
> - *params = (GLint) obj->Sampler.LodBias;
> + /* GL spec 'Data Conversions' section specifies that floating-point
> +  * value in integer Get function is rounded to nearest integer
> +  */
> + *params = (GLint) roundf(obj->Sampler.LodBias);
>   break;
>case GL_TEXTURE_CROP_RECT_OES:
>   if (ctx->API != API_OPENGLES || !ctx->Extensions.OES_draw_texture)
> 

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

Re: [Mesa-dev] [PATCH] glsl: Improve error message when attemping assignment to unsized array

[Ian Romanick]

Other than the tiny nit below,

Reviewed-by: Ian Romanick 

On 11/19/2013 03:13 AM, Timothy Arceri wrote:
> Signed-off-by: Timothy Arceri 
> ---
>  src/glsl/ast_to_hir.cpp | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index 76b256c..73be274 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -696,9 +696,14 @@ validate_assignment(struct _mesa_glsl_parse_state *state,
>  * Note: Whole-array assignments are not permitted in GLSL 1.10, but this
>  * is handled by ir_dereference::is_lvalue.
>  */
> -   if (is_initializer && lhs_type->is_unsized_array() && 
> rhs->type->is_array()
> +   if (lhs_type->is_unsized_array() && rhs->type->is_array()
> && (lhs_type->element_type() == rhs->type->element_type())) {
> -  return rhs;
> +  if (is_initializer) {
> + return rhs;
> +  } else {
> + _mesa_glsl_error(&loc, state,
> +  "implicitly sized arrays cannot be assigned to");

The "to" is redundant.

> +  }
> }
>  
> /* Check for implicit conversion in GLSL 1.20 */
> 

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

Re: [Mesa-dev] [PATCH] Don't use libudev for glx/dri3

[Eric Anholt]

Keith Packard  writes:

> Eric Anholt  writes:
>
>> Keith Packard  writes:
>>
>>> libudev doesn't have a stable API/ABI, and if the application wants to use 
>>> one
>>> version, we'd best not load another into libGL.
>>>
>>> Signed-off-by: Keith Packard 
>>
>> This looks so simple it's definitely worth dropping udev, but I'd like
>> to see the udev code actually dropped instead of #if 0ed.
>
> It's either that or make it a config option, in case libudev is useful
> on some other system someday?

I hate build options.


pgp18YZnMVdQV.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] st/mesa: fix GL_FEEDBACK mode inverted Y coordinate bug

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Tue, Nov 19, 2013 at 9:11 PM, Brian Paul  wrote:
> We need to check the drawbuffer's orientation before inverting Y
> coordinates.  Fixes piglit feedback tests when running with the
> -fbo option.
>
> Cc: "9.2" "10.0" 
> ---
>  src/mesa/state_tracker/st_cb_feedback.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_feedback.c 
> b/src/mesa/state_tracker/st_cb_feedback.c
> index d2e4346..34a16cc 100644
> --- a/src/mesa/state_tracker/st_cb_feedback.c
> +++ b/src/mesa/state_tracker/st_cb_feedback.c
> @@ -85,9 +85,11 @@ feedback_vertex(struct gl_context *ctx, const struct 
> draw_context *draw,
> const GLfloat *color, *texcoord;
> GLuint slot;
>
> -   /* Recall that Y=0=Top of window for Gallium wincoords */
> win[0] = v->data[0][0];
> -   win[1] = ctx->DrawBuffer->Height - v->data[0][1];
> +   if (st_fb_orientation(ctx->DrawBuffer) == Y_0_TOP)
> +  win[1] = ctx->DrawBuffer->Height - v->data[0][1];
> +   else
> +  win[1] = v->data[0][1];
> win[2] = v->data[0][2];
> win[3] = 1.0F / v->data[0][3];
>
> --
> 1.7.10.4
>
> ___
> 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] mesa: enable GL_TEXTURE_LOD_BIAS set/get

[Eric Anholt]

Eric Anholt  writes:

> Tapani Pälli  writes:
>
>> Earlier comments suggest this was removed from GL core spec but it is
>> still there. Enabling makes 'texture_lod_bias_getter' Khronos
>> conformance tests pass, also removes some errors from Metro Last Light
>> game which is using this API.
>
> Looks to me like this makes things start erroring on a compat context.

Mis-send -- I was misreading the patch, and fumbled my keybinds when
trying to kill the message.


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

Re: [Mesa-dev] [PATCH] mesa: enable GL_TEXTURE_LOD_BIAS set/get

[Eric Anholt]

Tapani Pälli  writes:

> Earlier comments suggest this was removed from GL core spec but it is
> still there. Enabling makes 'texture_lod_bias_getter' Khronos
> conformance tests pass, also removes some errors from Metro Last Light
> game which is using this API.

Looks to me like this makes things start erroring on a compat context.

>
> Signed-off-by: Tapani Pälli 
> ---
>  src/mesa/main/texparam.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
> index d56b7d9..e1bfeb0 100644
> --- a/src/mesa/main/texparam.c
> +++ b/src/mesa/main/texparam.c
> @@ -684,11 +684,7 @@ set_tex_parameterf(struct gl_context *ctx,
>return GL_FALSE;
>  
> case GL_TEXTURE_LOD_BIAS:
> -  /* NOTE: this is really part of OpenGL 1.4, not EXT_texture_lod_bias.
> -   * It was removed in core-profile, and it has never existed in OpenGL
> -   * ES.
> -   */
> -  if (ctx->API != API_OPENGL_COMPAT)
> +  if (_mesa_is_gles(ctx))
>   goto invalid_pname;
>  
>if (!target_allows_setting_sampler_parameters(texObj->Target))
> @@ -1513,7 +1509,7 @@ _mesa_GetTexParameterfv( GLenum target, GLenum pname, 
> GLfloat *params )
>   *params = (GLfloat) obj->DepthMode;
>   break;
>case GL_TEXTURE_LOD_BIAS:
> - if (ctx->API != API_OPENGL_COMPAT)
> + if (_mesa_is_gles(ctx))
>  goto invalid_pname;
>  
>   *params = obj->Sampler.LodBias;
> @@ -1701,10 +1697,13 @@ _mesa_GetTexParameteriv( GLenum target, GLenum pname, 
> GLint *params )
>   *params = (GLint) obj->DepthMode;
>   break;
>case GL_TEXTURE_LOD_BIAS:
> - if (ctx->API != API_OPENGL_COMPAT)
> + if (_mesa_is_gles(ctx))
>  goto invalid_pname;
>  
> - *params = (GLint) obj->Sampler.LodBias;
> + /* GL spec 'Data Conversions' section specifies that floating-point
> +  * value in integer Get function is rounded to nearest integer
> +  */
> + *params = (GLint) roundf(obj->Sampler.LodBias);
>   break;
>case GL_TEXTURE_CROP_RECT_OES:
>   if (ctx->API != API_OPENGLES || !ctx->Extensions.OES_draw_texture)
> -- 
> 1.8.1.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


pgp7PXEBgaqgx.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 15/15] i965/vs: Don't copy propagate into SEND-from-GRF messages.

[Eric Anholt]

Kenneth Graunke  writes:

> SEND can't deal with swizzles, source modifiers, and so on.  This should
> avoid problems with VS pull constant loads on Broadwell.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> index d009a08..8948223 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> @@ -238,6 +238,9 @@ vec4_visitor::try_copy_propagation(vec4_instruction 
> *inst, int arg,
> if (is_3src_inst && value.file == UNIFORM)
>return false;
>  
> +   if (inst->is_send_from_grf())
> +  return false;
> +
> /* We can't copy-propagate a UD negation into a condmod
>  * instruction, because the condmod ends up looking at the 33-bit
>  * signed accumulator value instead of the 32-bit value we wanted

I was worried that we would miss out on cases where doing a copy
propagated . swizzle is fine because the send doesn't actually care
about the other channels.  But there's no effect on shader-db, so:

Reviewed-by: Eric Anholt 



pgpoUNKVnC2j8.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 V3 06/13] vbo: Flesh out implementation of indirect draws

[Ian Romanick]

With the issues below fixed,

Reviewed-by: Ian Romanick 

On 11/09/2013 01:02 AM, Chris Forbes wrote:
> Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
> 
> Signed-off-by: Chris Forbes 
> ---
>  src/mesa/vbo/vbo_exec_array.c | 216 
> ++
>  1 file changed, 216 insertions(+)
> 
> diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
> index 4ea10ee..1c6b8b3 100644
> --- a/src/mesa/vbo/vbo_exec_array.c
> +++ b/src/mesa/vbo/vbo_exec_array.c
> @@ -1564,6 +1564,164 @@ vbo_exec_DrawTransformFeedbackStreamInstanced(GLenum 
> mode, GLuint name,
> vbo_draw_transform_feedback(ctx, mode, obj, stream, primcount);
>  }
>  
> +static void
> +vbo_validated_drawarraysindirect(struct gl_context *ctx,
> + GLenum mode, const GLvoid *indirect)
> +{
> +   struct vbo_context *vbo = vbo_context(ctx);
> +   struct vbo_exec_context *exec = &vbo->exec;
> +   struct _mesa_prim prim[1];
> +
> +   vbo_bind_arrays(ctx);
> +
> +   memset(prim, 0, sizeof(prim));
> +   prim[0].begin = 1;
> +   prim[0].end = 1;
> +   prim[0].mode = mode;
> +   prim[0].indirect_offset = (GLsizeiptr)indirect;
> +
> +   /* NOTE: We do NOT want to handle primitive restart here, nor perform any
> +* other checks that require knowledge of the values in the command 
> buffer.
> +* That would deafeat the whole purpose of this function.
> +*/
> +
> +   check_buffers_are_unmapped(exec->array.inputs);
> +   vbo->draw_prims(ctx, prim, 1,
> +   NULL, GL_TRUE, 0, ~0,
> +   NULL,
> +   ctx->DrawIndirectBuffer);
> +
> +   if (MESA_DEBUG_FLAGS & DEBUG_ALWAYS_FLUSH)
> +  _mesa_flush(ctx);
> +}
> +
> +static void
> +vbo_validated_multidrawarraysindirect(struct gl_context *ctx,
> +  GLenum mode,
> +  const GLvoid *indirect,
> +  GLsizei primcount, GLsizei stride)
> +{
> +   struct vbo_context *vbo = vbo_context(ctx);
> +   struct vbo_exec_context *exec = &vbo->exec;
> +   struct _mesa_prim *prim;
> +   GLsizei i;
> +   GLsizeiptr offset = (GLsizeiptr)indirect;
> +
> +   if (primcount == 0)
> +  return;
> +   prim = calloc(1, primcount * sizeof(*prim));

  prim = calloc(primcount, sizeof(*prim));

because primcount could be 0x7fff, and that would overflow on 32-bit
leading to sadness.  calloc will do the right thing.

> +   if (prim == NULL) {
> +  _mesa_error(ctx, GL_OUT_OF_MEMORY, "glMultiDrawArraysIndirect");
> +  return;
> +   }
> +
> +   vbo_bind_arrays(ctx);
> +
> +   memset(prim, 0, primcount * sizeof(*prim));

But you used calloc. :(

> +   prim[0].begin = 1;
> +   prim[primcount - 1].end = 1;
> +   for (i = 0; i < primcount; ++i, offset += stride) {
> +  prim[i].mode = mode;
> +  prim[i].indirect_offset = offset;
> +   }
> +
> +   check_buffers_are_unmapped(exec->array.inputs);
> +   vbo->draw_prims(ctx, prim, primcount,
> +   NULL, GL_TRUE, 0, ~0,
> +   NULL,
> +   ctx->DrawIndirectBuffer);
> +
> +   free(prim);
> +
> +   if (MESA_DEBUG_FLAGS & DEBUG_ALWAYS_FLUSH)
> +  _mesa_flush(ctx);
> +}
> +
> +static void
> +vbo_validated_drawelementsindirect(struct gl_context *ctx,
> +   GLenum mode, GLenum type,
> +   const GLvoid *indirect)
> +{
> +   struct vbo_context *vbo = vbo_context(ctx);
> +   struct vbo_exec_context *exec = &vbo->exec;
> +   struct _mesa_index_buffer ib;
> +   struct _mesa_prim prim[1];
> +
> +   vbo_bind_arrays(ctx);
> +
> +   ib.count = 0; /* unknown */
> +   ib.type = type;
> +   ib.obj = ctx->Array.ArrayObj->ElementArrayBufferObj;
> +   ib.ptr = NULL;
> +
> +   memset(prim, 0, sizeof(prim));
> +   prim[0].begin = 1;
> +   prim[0].end = 1;
> +   prim[0].mode = mode;
> +   prim[0].indexed = 1;
> +   prim[0].indirect_offset = (GLsizeiptr)indirect;
> +
> +   check_buffers_are_unmapped(exec->array.inputs);
> +   vbo->draw_prims(ctx, prim, 1,
> +   &ib, GL_TRUE, 0, ~0,
> +   NULL,
> +   ctx->DrawIndirectBuffer);
> +
> +   if (MESA_DEBUG_FLAGS & DEBUG_ALWAYS_FLUSH)
> +  _mesa_flush(ctx);
> +}
> +
> +static void
> +vbo_validated_multidrawelementsindirect(struct gl_context *ctx,
> +GLenum mode, GLenum type,
> +const GLvoid *indirect,
> +GLsizei primcount, GLsizei stride)
> +{
> +   struct vbo_context *vbo = vbo_context(ctx);
> +   struct vbo_exec_context *exec = &vbo->exec;
> +   struct _mesa_index_buffer ib;
> +   struct _mesa_prim *prim;
> +   GLsizei i;
> +   GLsizeiptr offset = (GLsizeiptr)indirect;
> +
> +   if (primcount == 0)
> +  return;
> +   prim = calloc(1, primcount * sizeof(*prim));

Same here.

> +   if (prim == NULL) {
> +  _mesa_erro

[Mesa-dev] [PATCH] st/mesa: fix GL_FEEDBACK mode inverted Y coordinate bug

[Brian Paul]

We need to check the drawbuffer's orientation before inverting Y
coordinates.  Fixes piglit feedback tests when running with the
-fbo option.

Cc: "9.2" "10.0" 
---
 src/mesa/state_tracker/st_cb_feedback.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_feedback.c 
b/src/mesa/state_tracker/st_cb_feedback.c
index d2e4346..34a16cc 100644
--- a/src/mesa/state_tracker/st_cb_feedback.c
+++ b/src/mesa/state_tracker/st_cb_feedback.c
@@ -85,9 +85,11 @@ feedback_vertex(struct gl_context *ctx, const struct 
draw_context *draw,
const GLfloat *color, *texcoord;
GLuint slot;
 
-   /* Recall that Y=0=Top of window for Gallium wincoords */
win[0] = v->data[0][0];
-   win[1] = ctx->DrawBuffer->Height - v->data[0][1];
+   if (st_fb_orientation(ctx->DrawBuffer) == Y_0_TOP)
+  win[1] = ctx->DrawBuffer->Height - v->data[0][1];
+   else
+  win[1] = v->data[0][1];
win[2] = v->data[0][2];
win[3] = 1.0F / v->data[0][3];
 
-- 
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] u_gen_mipmap: Use untampered cubemap texture coords when generating mipmaps.

[Brian Paul]

On 11/19/2013 11:54 AM, jfons...@vmware.com wrote:

From: José Fonseca 

It's not necessary to scale down cubemap texture coords when generating
mipmaps: we are doing a 2x minification therefore it's guaranteed that
the texture coords will always be at least 1 texel away of the edges.

Scaling down can actually be harmful, as it may cause artefacts when
generating mipmaps with nearest filtering. Sample points will lie
exactly in the middle each 2x2 texels, so the scaling factor was causing
different texels to be take on each quadrant of the cube face.  This is
apparent with a 1x1 checkerboard pattern in the base mipmap level:
instead of next mipmap level receiving a constant color throughout the
face, it will have different colors for each quadrant of the face.

The behaviour for blits is left untouched for now, but the cubemap
texture coord scaling hack should be reconsidered eventually.
---
  src/gallium/auxiliary/util/u_blit.c   |  3 ++-
  src/gallium/auxiliary/util/u_blitter.c|  3 ++-
  src/gallium/auxiliary/util/u_gen_mipmap.c |  3 ++-
  src/gallium/auxiliary/util/u_texture.c| 11 +--
  src/gallium/auxiliary/util/u_texture.h|  5 -
  5 files changed, 19 insertions(+), 6 deletions(-)




Reviewed-by: Brian Paul 

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

Re: [Mesa-dev] [PATCH] Don't use libudev for glx/dri3

[Keith Packard]

Eric Anholt  writes:

> Keith Packard  writes:
>
>> libudev doesn't have a stable API/ABI, and if the application wants to use 
>> one
>> version, we'd best not load another into libGL.
>>
>> Signed-off-by: Keith Packard 
>
> This looks so simple it's definitely worth dropping udev, but I'd like
> to see the udev code actually dropped instead of #if 0ed.

It's either that or make it a config option, in case libudev is useful
on some other system someday?

-- 
keith.pack...@intel.com


pgpwnupJNE3h4.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 V3 05/13] mesa: Add validation helpers for new indirect draws

[Chris Forbes]

OK, I'll go back to allowing zero. It's silly but harmless.

On Wed, Nov 20, 2013 at 8:29 AM, Ian Romanick  wrote:
> On 11/09/2013 01:02 AM, Chris Forbes wrote:
>> Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
>>
>> V3: - Disallow primcount==0 for DrawMulti*Indirect. The extension spec
>>   contradicts itself on this, but the GL4.3 spec disallows it.
>>
>> - Make it clear that the caller has dealt with stride==0
>>
>> Signed-off-by: Chris Forbes 
>> Reviewed-by: Paul Berry 
>> ---
>>  src/mesa/main/api_validate.c | 167 
>> +++
>>  src/mesa/main/api_validate.h |  26 +++
>>  2 files changed, 193 insertions(+)
>>
>> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
>> index f285c97..f462b68 100644
>> --- a/src/mesa/main/api_validate.c
>> +++ b/src/mesa/main/api_validate.c
>> @@ -837,3 +837,170 @@ _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;
>
> We can drop this check.  We'll never get ctx->API == API_OPENGL_COMPAT
> because we won't even install the dispatch pointers.
>
>> +  }
>> +   }
>> +
>> +   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;
>> +   }
>> +
>> +   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 * 
>> sizeof(GLuint),
>> +   "glDrawEl

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

[Ian Romanick]

On 11/09/2013 01:02 AM, Chris Forbes wrote:
> Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
> 
> V3: - Disallow primcount==0 for DrawMulti*Indirect. The extension spec
>   contradicts itself on this, but the GL4.3 spec disallows it.
> 
> - Make it clear that the caller has dealt with stride==0
> 
> Signed-off-by: Chris Forbes 
> Reviewed-by: Paul Berry 
> ---
>  src/mesa/main/api_validate.c | 167 
> +++
>  src/mesa/main/api_validate.h |  26 +++
>  2 files changed, 193 insertions(+)
> 
> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
> index f285c97..f462b68 100644
> --- a/src/mesa/main/api_validate.c
> +++ b/src/mesa/main/api_validate.c
> @@ -837,3 +837,170 @@ _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;

We can drop this check.  We'll never get ctx->API == API_OPENGL_COMPAT
because we won't even install the dispatch pointers.

> +  }
> +   }
> +
> +   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;
> +   }
> +
> +   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 * 
> sizeof(GLuint),
> +   "glDrawElementsIndirect");
> +}
> +
> +GLboolean
> +_mesa_validate_MultiDrawArraysIndirect(struct gl_context *ctx,
> +   GLenum mode,
> +   const GLvoid *indirect,
> +  

Re: [Mesa-dev] [PATCH V3 01/13] mesa: add indirect drawing buffer parameter to draw functions

[Ian Romanick]

Patches 1, 3, and 4 are

Reviewed-by: Ian Romanick 

I sent a separate reply to patch 2.

On 11/09/2013 01:02 AM, Chris Forbes wrote:
> From: Christoph Bumiller 
> 
> Split from patch implementing ARB_draw_indirect.
> 
> v2: Const-qualify the struct gl_buffer_object *indirect argument.
> v3: Fix up some more draw calls for new argument.
> v4: Fix up rebase conflicts in i965.
> v5: Undo const-qualification
> ---
>  src/mesa/drivers/dri/i965/brw_draw.c  |  3 ++-
>  src/mesa/drivers/dri/i965/brw_draw.h  |  3 ++-
>  src/mesa/drivers/dri/i965/brw_primitive_restart.c |  2 +-
>  src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c  | 13 -
>  src/mesa/state_tracker/st_cb_rasterpos.c  |  2 +-
>  src/mesa/state_tracker/st_draw.c  |  3 ++-
>  src/mesa/state_tracker/st_draw.h  |  6 --
>  src/mesa/state_tracker/st_draw_feedback.c |  3 ++-
>  src/mesa/tnl/t_draw.c |  3 ++-
>  src/mesa/tnl/tnl.h|  3 ++-
>  src/mesa/vbo/vbo.h|  5 -
>  src/mesa/vbo/vbo_exec_array.c |  8 
>  src/mesa/vbo/vbo_exec_draw.c  |  2 +-
>  src/mesa/vbo/vbo_primitive_restart.c  |  4 ++--
>  src/mesa/vbo/vbo_rebase.c |  2 +-
>  src/mesa/vbo/vbo_save_draw.c  |  2 +-
>  src/mesa/vbo/vbo_split_copy.c |  2 +-
>  src/mesa/vbo/vbo_split_inplace.c  |  2 +-
>  18 files changed, 41 insertions(+), 27 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index 7b33b76..0893b6d 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -463,7 +463,8 @@ void brw_draw_prims( struct gl_context *ctx,
>GLboolean index_bounds_valid,
>GLuint min_index,
>GLuint max_index,
> -  struct gl_transform_feedback_object *unused_tfb_object)
> +  struct gl_transform_feedback_object *unused_tfb_object,
> +  struct gl_buffer_object *indirect )
>  {
> struct brw_context *brw = brw_context(ctx);
> const struct gl_client_array **arrays = ctx->Array._DrawArrays;
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.h 
> b/src/mesa/drivers/dri/i965/brw_draw.h
> index fb96813..119d6f1 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.h
> +++ b/src/mesa/drivers/dri/i965/brw_draw.h
> @@ -41,7 +41,8 @@ void brw_draw_prims( struct gl_context *ctx,
>GLboolean index_bounds_valid,
>GLuint min_index,
>GLuint max_index,
> -  struct gl_transform_feedback_object *unused_tfb_object);
> +  struct gl_transform_feedback_object *unused_tfb_object,
> +  struct gl_buffer_object *indirect );
>  
>  void brw_draw_init( struct brw_context *brw );
>  void brw_draw_destroy( struct brw_context *brw );
> diff --git a/src/mesa/drivers/dri/i965/brw_primitive_restart.c 
> b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
> index 2ee6055..a131151 100644
> --- a/src/mesa/drivers/dri/i965/brw_primitive_restart.c
> +++ b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
> @@ -169,7 +169,7 @@ brw_handle_primitive_restart(struct gl_context *ctx,
>/* Cut index should work for primitive restart, so use it
> */
>brw->prim_restart.enable_cut_index = true;
> -  brw_draw_prims(ctx, prims, nr_prims, ib, GL_FALSE, -1, -1, NULL);
> +  brw_draw_prims(ctx, prims, nr_prims, ib, GL_FALSE, -1, -1, NULL, NULL);
>brw->prim_restart.enable_cut_index = false;
> } else {
>/* Not all the primitive draw modes are supported by the cut index,
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c 
> b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
> index 436db32..dff947a 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
> @@ -222,7 +222,8 @@ TAG(vbo_render_prims)(struct gl_context *ctx,
> const struct _mesa_index_buffer *ib,
> GLboolean index_bounds_valid,
> GLuint min_index, GLuint max_index,
> -   struct gl_transform_feedback_object *tfb_vertcount);
> +   struct gl_transform_feedback_object *tfb_vertcount,
> +   struct gl_buffer_object *indirect);
>  
>  static GLboolean
>  vbo_maybe_split(struct gl_context *ctx, const struct gl_client_array 
> **arrays,
> @@ -453,7 +454,8 @@ TAG(vbo_render_prims)(struct gl_context *ctx,
> const struct _mesa_index_buffer *ib,
> GLboolean index_bounds_valid,
> GLuint min_index, GLuint max_index,
> -   struct gl_transform_feedback_object *tfb_vertcount)
> +   struct g

Re: [Mesa-dev] [PATCH V3 02/13] glapi: add plumbing for GL_ARB_draw_indirect and GL_ARB_multi_draw_indirect

[Ian Romanick]

On 11/09/2013 01:02 AM, Chris Forbes wrote:
> Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
> 
> Signed-off-by: Chris Forbes 

I assume 'make check' actually passes? :)

With the change below,

Reviewed-by: Ian Romanick .

> ---
>  src/mapi/glapi/gen/ARB_draw_indirect.xml | 45 
> 
>  src/mapi/glapi/gen/Makefile.am   |  1 +
>  src/mapi/glapi/gen/gl_API.xml|  4 ++-
>  src/mesa/main/tests/dispatch_sanity.cpp  |  8 +++---
>  src/mesa/vbo/vbo_exec_array.c| 32 +++
>  5 files changed, 85 insertions(+), 5 deletions(-)
>  create mode 100644 src/mapi/glapi/gen/ARB_draw_indirect.xml
> 
> diff --git a/src/mapi/glapi/gen/ARB_draw_indirect.xml 
> b/src/mapi/glapi/gen/ARB_draw_indirect.xml
> new file mode 100644
> index 000..7de03cd
> --- /dev/null
> +++ b/src/mapi/glapi/gen/ARB_draw_indirect.xml
> @@ -0,0 +1,45 @@
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + exec="dynamic">
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
> index 476d943..7af769a 100644
> --- a/src/mapi/glapi/gen/Makefile.am
> +++ b/src/mapi/glapi/gen/Makefile.am
> @@ -98,6 +98,7 @@ API_XML = \
>   ARB_draw_buffers.xml \
>   ARB_draw_buffers_blend.xml \
>   ARB_draw_elements_base_vertex.xml \
> + ARB_draw_indirect.xml \
>   ARB_draw_instanced.xml \
>   ARB_ES2_compatibility.xml \
>   ARB_ES3_compatibility.xml \
> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index a2d914a..5c877aa 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -8241,6 +8241,8 @@
>  
>  
>  
> + xmlns:xi="http://www.w3.org/2001/XInclude"/>
> +
>  
>
>
> @@ -8470,7 +8472,7 @@
>  
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
>  
> -
> +
>  
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
>  
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index 922f0ac..e57fb52 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -667,8 +667,8 @@ const struct function gl_core_functions_possible[] = {
> { "glVertexAttribP3uiv", 43, -1 },
> { "glVertexAttribP4ui", 43, -1 },
> { "glVertexAttribP4uiv", 43, -1 },
> -// { "glDrawArraysIndirect", 43, -1 },  // XXX: Add to xml
> -// { "glDrawElementsIndirect", 43, -1 },// XXX: Add to xml
> +   { "glDrawArraysIndirect", 43, -1 },
> +   { "glDrawElementsIndirect", 43, -1 },
>  // { "glUniform1d", 43, -1 },   // XXX: Add to xml
>  // { "glUniform2d", 43, -1 },   // XXX: Add to xml
>  // { "glUniform3d", 43, -1 },   // XXX: Add to xml
> @@ -877,8 +877,8 @@ const struct function gl_core_functions_possible[] = {
> { "glInvalidateBufferData", 43, -1 },
> { "glInvalidateFramebuffer", 43, -1 },
> { "glInvalidateSubFramebuffer", 43, -1 },
> -// { "glMultiDrawArraysIndirect", 43, -1 }, // XXX: Add to xml
> -// { "glMultiDrawElementsIndirect", 43, -1 },   // XXX: Add to xml
> +   { "glMultiDrawArraysIndirect", 43, -1 },
> +   { "glMultiDrawElementsIndirect", 43, -1 },
>  // { "glGetProgramInterfaceiv", 43, -1 },   // XXX: Add to xml
>  // { "glGetProgramResourceIndex", 43, -1 }, // XXX: Add to xml
>  // { "glGetProgramResourceName", 43, -1 },  // XXX: Add to xml
> diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
> index a2c0c7d..4ea10ee 100644
> --- a/src/mesa/vbo/vbo_exec_array.c
> +++ b/src/mesa/vbo/vbo_exec_array.c
> @@ -1564,6 +1564,34 @@ vbo_exec_DrawTransformFeedbackStreamInstanced(GLenum 
> mode, GLuint name,
> vbo_draw_transform_feedback(ctx, mode, obj, stream, primcount);
>  }
>  
> +/**
> + * Like [Multi]DrawArrays/Elements, but they take most arguments from
> + * a buffer object.
> + */
> +static void GLAPIENTRY
> +vbo_exec_DrawArraysIndirect(GLenum mode, const GLvoid *indirect)
> +{
> +}
> +
> +static void GLAPIENTRY
> +vbo_exec_DrawElementsIndirect(GLenum mode, GLenum type,
> +  const GLvoid *indirect)
> +{
> +}
> +
> +static void GLAPIENTRY
> +vbo_exec_MultiDrawArraysIndirect(GLenum mode,
> + const GLvoid *indirect,
> + GLsizei primcount, GLsizei stride)
> +{
> +}
> +
> +static void GLAPIENTRY
> +vbo_exec_MultiDrawElementsIndirect(GLenum mode, GLenum type,
> +   const GLvoid *indirect,
> +   GLsizei primcount, GLsizei stride)
> +{
> +}
>  
>  /**
>   * Ini

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

[Ian Romanick]

On 11/12/2013 12:13 PM, Kenneth Graunke wrote:
> On 11/09/2013 01:02 AM, Chris Forbes wrote:
>> Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.
>>
>> V3: - Disallow primcount==0 for DrawMulti*Indirect. The extension spec
>>   contradicts itself on this, but the GL4.3 spec disallows it.
>>
>> - Make it clear that the caller has dealt with stride==0
>>
>> Signed-off-by: Chris Forbes 
>> Reviewed-by: Paul Berry 
>> ---
>>  src/mesa/main/api_validate.c | 167 
>> +++
>>  src/mesa/main/api_validate.h |  26 +++
>>  2 files changed, 193 insertions(+)
>>
>> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
>> index f285c97..f462b68 100644
>> --- a/src/mesa/main/api_validate.c
>> +++ b/src/mesa/main/api_validate.c
>> @@ -837,3 +837,170 @@ _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;
> 
> /* From the ARB_draw_indirect specification:
>  * "An INVALID_OPERATION error is generated [...] if  is no
>  *  word aligned."
>  */
> 
>> +   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)) {
> 
> I think there's some "most commands will detect attempts to read from a
> mapped buffer object" text which can justify this.  I'm fine with
> leaving it as is.
> 
>> +  if (_mesa_bufferobj_mapped(ctx->DrawIndirectBuffer)) {
>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>> + "%s(DRAW_INDIRECT_BUFFER is mapped)", name);
>> + return GL_FALSE;
>> +  }
> 
> /* From the ARB_draw_indirect specification:
>  * "An INVALID_OPERATION error is generated if the commands source data
>  *  beyond the end of the buffer object [...]"
>  */
> 
>> +  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) {
> 
> It would be great to put a citation for this:
> 
> /* From the ARB_multi_draw_indirect specification:
>  * "INVALID_VALUE is generated by MultiDrawArraysIndirect or
>  *  MultiDrawElementsIndirect if  is negative."
>  *
>  * " must be positive, otherwise an INVALID_VALUE error will
>  *  be generated."
>  */
> 
> These beg the question of whether 0 is allowed.  Usually I interpret
> "negative" as < 0, "positive" as >= 0, and "strictly positive" as > 0.
> So I think zero should be allowed, and I don't see a contradiction.
> 
> The only text I can find in 4.3 and 4.4 just reiterate that it needs to
> positive, and I don't see any text defining "positive."
> 
> Our existing implementation of MultiDrawElements appears to allow 0,
> simply turning it into a noop.  This seems to be supported by the
> pseudocode; the loop will simply execute zero times.

I believe this is correct.  There is common error language since forever
for all GLsizei parameters.

"If a negative number

Re: [Mesa-dev] [PATCH] mesa: enable GL_TEXTURE_LOD_BIAS set/get

[Kenneth Graunke]

On 11/19/2013 01:05 AM, Tapani Pälli wrote:
> Earlier comments suggest this was removed from GL core spec but it is
> still there. Enabling makes 'texture_lod_bias_getter' Khronos
> conformance tests pass, also removes some errors from Metro Last Light
> game which is using this API.
> 
> Signed-off-by: Tapani Pälli 

I can see the confusion.  TEXTURE_LOD_BIAS appears in the section of
deprecated and actually -removed- features...but for TexEnv.  The GL 4.4
core spec still lists it as valid for TexParameter.

This appears to be a regression since
b3dd524a1082efd12d4a796122c300a61ba016d9.

Reviewed-by: Kenneth Graunke 
Cc: "9.0 9.1 9.2 10.0" 

Thanks for fixing this, Tapani!

> ---
>  src/mesa/main/texparam.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
> index d56b7d9..e1bfeb0 100644
> --- a/src/mesa/main/texparam.c
> +++ b/src/mesa/main/texparam.c
> @@ -684,11 +684,7 @@ set_tex_parameterf(struct gl_context *ctx,
>return GL_FALSE;
>  
> case GL_TEXTURE_LOD_BIAS:
> -  /* NOTE: this is really part of OpenGL 1.4, not EXT_texture_lod_bias.
> -   * It was removed in core-profile, and it has never existed in OpenGL
> -   * ES.
> -   */
> -  if (ctx->API != API_OPENGL_COMPAT)
> +  if (_mesa_is_gles(ctx))
>   goto invalid_pname;
>  
>if (!target_allows_setting_sampler_parameters(texObj->Target))
> @@ -1513,7 +1509,7 @@ _mesa_GetTexParameterfv( GLenum target, GLenum pname, 
> GLfloat *params )
>   *params = (GLfloat) obj->DepthMode;
>   break;
>case GL_TEXTURE_LOD_BIAS:
> - if (ctx->API != API_OPENGL_COMPAT)
> + if (_mesa_is_gles(ctx))
>  goto invalid_pname;
>  
>   *params = obj->Sampler.LodBias;
> @@ -1701,10 +1697,13 @@ _mesa_GetTexParameteriv( GLenum target, GLenum pname, 
> GLint *params )
>   *params = (GLint) obj->DepthMode;
>   break;
>case GL_TEXTURE_LOD_BIAS:
> - if (ctx->API != API_OPENGL_COMPAT)
> + if (_mesa_is_gles(ctx))
>  goto invalid_pname;
>  
> - *params = (GLint) obj->Sampler.LodBias;
> + /* GL spec 'Data Conversions' section specifies that floating-point
> +  * value in integer Get function is rounded to nearest integer
> +  */
> + *params = (GLint) roundf(obj->Sampler.LodBias);
>   break;
>case GL_TEXTURE_CROP_RECT_OES:
>   if (ctx->API != API_OPENGLES || !ctx->Extensions.OES_draw_texture)
> 

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

[Mesa-dev] [Bug 71506] indirect_glx.c:350: multiple definition of `indirect_create_context'

[bugzilla-daemon]

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

--- Comment #14 from Emil Velikov  ---
Might be a good idea to pick this up for the 10.0 branch ?

-- 
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] u_gen_mipmap: Use untampered cubemap texture coords when generating mipmaps.

[jfonseca]

From: José Fonseca 

It's not necessary to scale down cubemap texture coords when generating
mipmaps: we are doing a 2x minification therefore it's guaranteed that
the texture coords will always be at least 1 texel away of the edges.

Scaling down can actually be harmful, as it may cause artefacts when
generating mipmaps with nearest filtering. Sample points will lie
exactly in the middle each 2x2 texels, so the scaling factor was causing
different texels to be take on each quadrant of the cube face.  This is
apparent with a 1x1 checkerboard pattern in the base mipmap level:
instead of next mipmap level receiving a constant color throughout the
face, it will have different colors for each quadrant of the face.

The behaviour for blits is left untouched for now, but the cubemap
texture coord scaling hack should be reconsidered eventually.
---
 src/gallium/auxiliary/util/u_blit.c   |  3 ++-
 src/gallium/auxiliary/util/u_blitter.c|  3 ++-
 src/gallium/auxiliary/util/u_gen_mipmap.c |  3 ++-
 src/gallium/auxiliary/util/u_texture.c| 11 +--
 src/gallium/auxiliary/util/u_texture.h|  5 -
 5 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_blit.c 
b/src/gallium/auxiliary/util/u_blit.c
index 4ba71b9..595287d 100644
--- a/src/gallium/auxiliary/util/u_blit.c
+++ b/src/gallium/auxiliary/util/u_blit.c
@@ -272,7 +272,8 @@ setup_vertex_data_tex(struct blit_state *ctx,
   const unsigned stride = sizeof ctx->vertices[0] / sizeof 
ctx->vertices[0][0][0];
   util_map_texcoords2d_onto_cubemap(src_face,
 &ctx->vertices[0][1][0], stride,
-&ctx->vertices[0][1][0], stride);
+&ctx->vertices[0][1][0], stride,
+TRUE);
}
 
offset = get_next_slot( ctx );
diff --git a/src/gallium/auxiliary/util/u_blitter.c 
b/src/gallium/auxiliary/util/u_blitter.c
index 096d3bc..b95cbab 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -659,7 +659,8 @@ static void blitter_set_texcoords(struct 
blitter_context_priv *ctx,
   util_map_texcoords2d_onto_cubemap(layer % 6,
 /* pointer, stride in floats */
 &face_coord[0][0], 2,
-&ctx->vertices[0][1][0], 8);
+&ctx->vertices[0][1][0], 8,
+TRUE);
} else {
   set_texcoords_in_vertices(coord, &ctx->vertices[0][1][0], 8);
}
diff --git a/src/gallium/auxiliary/util/u_gen_mipmap.c 
b/src/gallium/auxiliary/util/u_gen_mipmap.c
index a885f2b..84bf30f 100644
--- a/src/gallium/auxiliary/util/u_gen_mipmap.c
+++ b/src/gallium/auxiliary/util/u_gen_mipmap.c
@@ -1409,7 +1409,8 @@ set_vertex_data(struct gen_mipmap_state *ctx,
   };
 
   util_map_texcoords2d_onto_cubemap(layer, &st[0][0], 2,
-&ctx->vertices[0][1][0], 8);
+&ctx->vertices[0][1][0], 8,
+FALSE);
}
else if (tex_target == PIPE_TEXTURE_1D_ARRAY) {
   /* 1D texture array  */
diff --git a/src/gallium/auxiliary/util/u_texture.c 
b/src/gallium/auxiliary/util/u_texture.c
index d97e57a..e865f8e 100644
--- a/src/gallium/auxiliary/util/u_texture.c
+++ b/src/gallium/auxiliary/util/u_texture.c
@@ -42,7 +42,8 @@
 
 void util_map_texcoords2d_onto_cubemap(unsigned face,
const float *in_st, unsigned in_stride,
-   float *out_str, unsigned out_stride)
+   float *out_str, unsigned out_stride,
+   boolean allow_scale)
 {
int i;
float rx, ry, rz;
@@ -52,8 +53,14 @@ void util_map_texcoords2d_onto_cubemap(unsigned face,
   /* Compute sc = +/-scale and tc = +/-scale.
* Not +/-1 to avoid cube face selection ambiguity near the edges,
* though that can still sometimes happen with this scale factor...
+   *
+   * XXX: Yep, there is no safe scale factor that will prevent sampling
+   * the neighbouring face when stretching out.  A more reliable solution
+   * would be to clamp (sc, tc) against +/- 1.0-1.0/mipsize, in the shader.
+   *
+   * Also, this is not necessary when minifying, or 1:1 blits.
*/
-  const float scale = 0.f;
+  const float scale = allow_scale ? 0.f : 1.0f;
   const float sc = (2 * in_st[0] - 1) * scale;
   const float tc = (2 * in_st[1] - 1) * scale;
 
diff --git a/src/gallium/auxiliary/util/u_texture.h 
b/src/gallium/auxiliary/util/u_texture.h
index 93b2f1e..b1c8c70 100644
--- a/src/gallium/auxiliary/util/u_texture.h
+++ b/src/gallium/auxiliary/util/u_texture.h
@@ -27,6 +27,8 @@
 #ifndef U_TEXTURE_H
 #define 

Re: [Mesa-dev] [PATCH] Don't use libudev for glx/dri3

[Eric Anholt]

Keith Packard  writes:

> libudev doesn't have a stable API/ABI, and if the application wants to use one
> version, we'd best not load another into libGL.
>
> Signed-off-by: Keith Packard 

This looks so simple it's definitely worth dropping udev, but I'd like
to see the udev code actually dropped instead of #if 0ed.


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

Re: [Mesa-dev] sampler arrays indexed with non-constant expressions

[Ian Romanick]

On 11/19/2013 01:16 AM, Erik Faye-Lund wrote:
> On Mon, Nov 18, 2013 at 9:04 PM, Paul Berry  wrote:
>> On 17 November 2013 00:24, Victor Luchitz  wrote:
>>> If compiler actually attempted to unroll the loop above, it would notice
>>> that the does compile correctly. Instead it just emits and error and in my
>>> opinion, contradicts the comment above but not allowing the "useful thing"
>>> in question.
>>>
>>> Can the compiler be changed to _first_ attempt to unroll the loop and then
>>> check for sampler array indices being constants?
>>
>>
>> Thanks for the feedback, Victor.  We are always interested in hearing
>> suggestions about how to improve Mesa.
>>
>> Unfortunately, in this case, your suggestion would make Mesa non-conformant
>> with the GLSL specs because it would allow shaders that are prohibited by
>> the spec.  Generally we try to avoid this sort of non-spec-conformance
>> because it leads to portability problems for developers like you (e.g. your
>> shader works with Mesa, but it fails with other GL implementations).  A
>> further problem is that Mesa has heuristics to decide whether to unroll
>> loops; if we followed your suggestion, then your shader might work today,
>> but fail tomorrow if you make a small change to the shader that makes Mesa
>> decide not to unroll the loop (or we make a change to the heuristics in a
>> future release of Mesa).
> 
> Just as minor nit, I'd like to point out that the OpenGL ES 2.0
> shading language specification defines a concept of
> "constant-index-expressions" which includes loop indices, and allows
> sampler arrays to be indexed by these expressions. This only works
> because it at the same time does not allow arbitrary loops. See
> appendix A, section 4 and 5 of the spec for the details.

Right.  Basically the ES 2.0 limitation is that any loop can be
unrolled... because quite a bit of the original ES 2.0 target hardware
didn't have *any* branching.  This was hardware like i915 or r300.

The case that Paul describes isn't hypothetical, either.  We actually
encountered this a couple years ago.  There was something in the loop
that prevented the compile from unrolling it, and the texture accesses
in the loop caused assertion failures.  We eventually made the loop
unroll, but I seem to recall that had other bad side effects.  I *thin*
the problem was the loop, for some reason or another, had a huge number
of instructions.  I'm fairly sure there was an associated bug report,
but it's probably too much effort to make it worth finding.

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

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

Re: [Mesa-dev] [PATCH 09/15] i965: Add a new representation for Broadwell shader instructions.

[Eric Anholt]

Kenneth Graunke  writes:

> On 11/18/2013 03:22 PM, Kenneth Graunke wrote:
>> On 11/18/2013 12:27 PM, Eric Anholt wrote:
>>> Kenneth Graunke  writes:
>>>
 Broadwell significantly changes the EU instruction encoding.  Many of
 the fields got moved to different bit positions; some even got split
 in two.

 With so many changes, it was infeasible to continue using struct
 brw_instruction.  We needed a new representation.

 This new approach is a bit different: rather than a struct, I created a
 class that has four DWords, and helper functions that read/write various
 bits.  This has several advantages:

 1. We can create several different names for the same bits.  For
example, conditional modifiers, SFID for SEND instructions, and the
MATH instruction's function opcode are all stored in bits 27:24.

In each situation, we can use the appropriate setter function:
set_sfid(), set_math_function(), or set_cond_modifier().  This
is much easier to follow.

 2. Since the fields are expressed using the original 128-bit numbers,
the code to create the getter/setter functions follows the table in
the documentation very closely.

 To aid in debugging, I've enabled -fkeep-inline-functions when building
 gen8_instruction.cpp.  Otherwise, these functions cannot be called by
 gdb, making it insanely difficult to print out anything.
>>>
>>> I dislike C++ creep.
>> 
>> I wrote this in C++ because all of the compiler infrastructure which
>> uses it is already in C++.  It seemed natural.
>> 
>> However, Damien requested that we write it in C so it could be easily
>> copied to xf86-video-intel, intel-gpu-tools, gen4asm/disasm, etc.  Which
>> is probably a good thing.  He actually already ported it to C.
>
> For reference, Damien's C port of this code is in the public
> intel-gpu-tools repo as assember/gen8_instruction.[ch]:

Looks like a pretty straightforward port, with a few more bitfields
added.  I'd consider it a feature to be using the same code as the other
tree (even if we aren't actually using the same code from a library).


pgpmhcTXWu76s.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] mapi: Add better visibility checks

[Alexander von Gluck IV]

On Sun, 17 Nov 2013 12:11:41 -0600
Alexander von Gluck IV  wrote:

> * gl.h ensures gcc is 4.x or later before using
>   hidden visibility. This change matches that behaviour
>   and ensures better compatibility for older gcc versions.
> ---
>  src/mapi/glapi/glapi.h |2 +-
>  src/mapi/u_compiler.h  |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Anyone see any issues with this patch?

Thanks!

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

Re: [Mesa-dev] [PATCH] svga: improve check for 3D compressed textures

[Jose Fonseca]

- Original Message -
> This is basically a a respin of f1dfcf4bce35e6796f873d9a00103b280da81e4c
> per Jose's suggestion.
> 
> Just set the SVGA3dSurfaceFormatCaps flags for 3D and cube textures
> when checking the texture format capabilities.  This will filter out
> unsupported combinations like 3D+DXT.
> ---
>  src/gallium/drivers/svga/svga_screen.c |   12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/src/gallium/drivers/svga/svga_screen.c
> b/src/gallium/drivers/svga/svga_screen.c
> index ebcad2c..c16be16 100644
> --- a/src/gallium/drivers/svga/svga_screen.c
> +++ b/src/gallium/drivers/svga/svga_screen.c
> @@ -447,11 +447,6 @@ svga_is_format_supported( struct pipe_screen *screen,
>}
> }
> 
> -   if (target == PIPE_TEXTURE_3D && util_format_is_compressed(format)) {
> -  /* we don't support compressed 3D textures at this time */
> -  return FALSE;
> -   }
> -
> /*
>  * Query the host capabilities.
>  */
> @@ -469,6 +464,13 @@ svga_is_format_supported( struct pipe_screen *screen,
>mask.texture = 1;
> }
>  
> +   if (target == PIPE_TEXTURE_CUBE) {
> +  mask.cubeTexture = 1;
> +   }
> +   if (target == PIPE_TEXTURE_3D) {
> +  mask.volumeTexture = 1;
> +   }
> +
> return (caps.value & mask.value) == mask.value;
>  }
>  
> --
> 1.7.10.4

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

[Mesa-dev] [PATCH] glXCreatePbuffer and glXCreateGLXPbufferSGIX set drawable to None instead of create pixmap. dri2GetBuffersWithFormat allocates resource for a pbuffer.

[Daniel Czarnowski]

---
 src/glx/dri2_glx.c|   99 +++--
 src/glx/glx_pbuffer.c |8 ++--
 2 files changed, 98 insertions(+), 9 deletions(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 7ce5775..d0f284d 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -50,6 +50,7 @@
 #include "xf86drm.h"
 #include "dri2.h"
 #include "dri_common.h"
+#include "assert.h"
 
 /* From xmlpool/options.h, user exposed so should be stable */
 #define DRI_CONF_VBLANK_NEVER 0
@@ -352,7 +353,7 @@ dri2DestroyDrawable(__GLXDRIdrawable *base)
 * knowing when the application is done with it.  The server will
 * destroy the DRI2 drawable when it destroys the X drawable or the
 * client exits anyway. */
-   if (pdraw->base.xDrawable != pdraw->base.drawable)
+   if (pdraw->base.xDrawable && pdraw->base.xDrawable != pdraw->base.drawable)
   DRI2DestroyDrawable(psc->base.dpy, pdraw->base.xDrawable);
 
free(pdraw);
@@ -397,7 +398,8 @@ dri2CreateDrawable(struct glx_screen *base, XID xDrawable,
   break;
}
 
-   DRI2CreateDrawable(psc->base.dpy, xDrawable);
+   if (xDrawable)
+   DRI2CreateDrawable(psc->base.dpy, xDrawable);
 
dpyPriv = __glXInitialize(psc->base.dpy);
pdp = (struct dri2_display *)dpyPriv->dri2Display;;
@@ -412,7 +414,7 @@ dri2CreateDrawable(struct glx_screen *base, XID xDrawable,
   return NULL;
}
 
-   if (__glxHashInsert(pdp->dri2Hash, xDrawable, pdraw)) {
+   if (xDrawable && __glxHashInsert(pdp->dri2Hash, xDrawable, pdraw)) {
   (*psc->core->destroyDrawable) (pdraw->driDrawable);
   DRI2DestroyDrawable(psc->base.dpy, xDrawable);
   free(pdraw);
@@ -877,6 +879,83 @@ dri2GetBuffers(__DRIdrawable * driDrawable,
return pdraw->buffers;
 }
 
+/* get_aux_bo() and dri2PbufferGetBuffers() come from
+ * src/egl/drivers/dri2/platform_drm.c, 
+ * Mentioned functions work with a struct dri2_drawable instead
+ * of a struct dri2_egl_surface, but the general idea 
+ * is the same.
+ */
+
+static int
+get_aux_bo(struct dri2_drawable *pdraw,
+   unsigned int attachment, 
+   unsigned int format, 
+   __DRIbuffer *buffer) {
+__DRIbuffer *b = NULL;
+struct dri2_screen *psc = (struct dri2_screen *) pdraw->base.psc;
+
+b = psc->dri2->allocateBuffer(psc->driScreen,
+attachment,
+format,
+pdraw->width,
+pdraw->height);
+
+   if (b == NULL)
+  return -1;
+
+   memcpy(buffer, b, sizeof *buffer);
+   return 0;
+}
+
+
+static __DRIbuffer *
+dri2PbufferGetBuffers(__DRIdrawable * driDrawable,
+  int *width, 
+  int *height,
+  unsigned int *attachments, 
+  int count,
+  int *out_count, 
+  void *loaderPrivate) {
+   struct dri2_drawable *pdraw = loaderPrivate;
+   int i, j;
+
+   /* ask for size of buffers */
+   glXQueryGLXPbufferSGIX(pdraw->base.psc->dpy,
+ pdraw->base.drawable,
+ GLX_WIDTH,
+ (unsigned int*)&pdraw->width);
+
+   glXQueryGLXPbufferSGIX(pdraw->base.psc->dpy,
+ pdraw->base.drawable,
+ GLX_HEIGHT,
+ (unsigned 
int*)&pdraw->height);
+
+   if ((!pdraw->width) || (!pdraw->height))
+  return NULL;
+
+   pdraw->bufferCount = 0;
+   for (i = 0, j = 0; i < 2 * count; i += 2, j++) {
+assert(attachments[i] < __DRI_BUFFER_COUNT);
+assert(pdraw->bufferCount < 5);
+
+if (get_aux_bo(pdraw, attachments[i], attachments[i + 1],
+&pdraw->buffers[j]) < 0) {
+ErrorMessageF("failed to allocate aux buffer");
+return NULL;
+}
+   }
+
+   *out_count = j;
+   if (j == 0)
+  return NULL;
+
+   *width = pdraw->width;
+   *height = pdraw->height;
+
+   return pdraw->buffers;
+}
+
+
 static __DRIbuffer *
 dri2GetBuffersWithFormat(__DRIdrawable * driDrawable,
  int *width, int *height,
@@ -886,6 +965,17 @@ dri2GetBuffersWithFormat(__DRIdrawable * driDrawable,
struct dri2_drawable *pdraw = loaderPrivate;
DRI2Buffer *buffers;
 
+   /* If xDrawable is None we're asked for buffers for a pbuffer. */
+   if (pdraw->base.xDrawable == None)
+  return dri2PbufferGetBuffers(driDrawable, 
+   width, 
+   height,
+   attachments, 
+   count, 
+   out_count,
+   loaderPrivate);
+
+
buffers = DRI2GetBuffersWithFormat(pdraw->base.psc->dpy,
   pdraw->base

[Mesa-dev] [PATCH] svga: improve check for 3D compressed textures

[Brian Paul]

This is basically a a respin of f1dfcf4bce35e6796f873d9a00103b280da81e4c
per Jose's suggestion.

Just set the SVGA3dSurfaceFormatCaps flags for 3D and cube textures
when checking the texture format capabilities.  This will filter out
unsupported combinations like 3D+DXT.
---
 src/gallium/drivers/svga/svga_screen.c |   12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_screen.c 
b/src/gallium/drivers/svga/svga_screen.c
index ebcad2c..c16be16 100644
--- a/src/gallium/drivers/svga/svga_screen.c
+++ b/src/gallium/drivers/svga/svga_screen.c
@@ -447,11 +447,6 @@ svga_is_format_supported( struct pipe_screen *screen,
   }
}

-   if (target == PIPE_TEXTURE_3D && util_format_is_compressed(format)) {
-  /* we don't support compressed 3D textures at this time */
-  return FALSE;
-   }
-
/*
 * Query the host capabilities.
 */
@@ -469,6 +464,13 @@ svga_is_format_supported( struct pipe_screen *screen,
   mask.texture = 1;
}
 
+   if (target == PIPE_TEXTURE_CUBE) {
+  mask.cubeTexture = 1;
+   }
+   if (target == PIPE_TEXTURE_3D) {
+  mask.volumeTexture = 1;
+   }
+
return (caps.value & mask.value) == mask.value;
 }
 
-- 
1.7.10.4

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

[Mesa-dev] [Bug 70766] Run-time link error in swrast_dri.so

[bugzilla-daemon]

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

--- Comment #3 from Jan Vesely  ---
(In reply to comment #2)
> did you use cmake to compile llvm?

check this patch:
http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg45916.html

-- 
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 70766] Run-time link error in swrast_dri.so

[bugzilla-daemon]

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

--- Comment #2 from Jan Vesely  ---
did you use cmake to compile llvm?

-- 
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] winsys/radeon: cleanup virtual memory nonsense

[Christian König]

Am 19.11.2013 16:19, schrieb Alex Deucher:

On Tue, Nov 19, 2013 at 5:05 AM, Christian König
 wrote:

From: Christian König 

The alignment of a virtual memory area must always be at least 4096 bytes.

It only worked because size was aligned to 4096 outside of the function.

Signed-off-by: Christian König 

CC the 9.2 and 10.0 branches?  Does this fix the problems you were
looking at last week?


Unfortunately not. I just stumbled over it while working on a patch that 
artificially unaligned all buffers. E.g. when the driver says align the 
buffer to 4k then make sure that it's aligned to 4k but not to 8k. Tried 
to force the lockup with it, but that doesn't work either.


Christian.


Reviewed-by: Alex Deucher 


---
  src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 37 +--
  src/gallium/winsys/radeon/drm/radeon_drm_bo.h |  1 -
  2 files changed, 18 insertions(+), 20 deletions(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 19e2715..3019a52 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -202,15 +202,15 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
*mgr, uint64_t size, ui
  struct radeon_bo_va_hole *hole, *n;
  uint64_t offset = 0, waste = 0;

+alignment = MAX2(alignment, 4096);
+size = align(size, 4096);
+
  pipe_mutex_lock(mgr->bo_va_mutex);
  /* first look for a hole */
  LIST_FOR_EACH_ENTRY_SAFE(hole, n, &mgr->va_holes, list) {
  offset = hole->offset;
-waste = 0;
-if (alignment) {
-waste = offset % alignment;
-waste = waste ? alignment - waste : 0;
-}
+waste = offset % alignment;
+waste = waste ? alignment - waste : 0;
  offset += waste;
  if (offset >= (hole->offset + hole->size)) {
  continue;
@@ -242,11 +242,8 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
*mgr, uint64_t size, ui
  }

  offset = mgr->va_offset;
-waste = 0;
-if (alignment) {
-waste = offset % alignment;
-waste = waste ? alignment - waste : 0;
-}
+waste = offset % alignment;
+waste = waste ? alignment - waste : 0;
  if (waste) {
  n = CALLOC_STRUCT(radeon_bo_va_hole);
  n->size = waste;
@@ -261,6 +258,8 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
*mgr, uint64_t size, ui

  static void radeon_bomgr_force_va(struct radeon_bomgr *mgr, uint64_t va, 
uint64_t size)
  {
+size = align(size, 4096);
+
  pipe_mutex_lock(mgr->bo_va_mutex);
  if (va >= mgr->va_offset) {
  if (va > mgr->va_offset) {
@@ -303,6 +302,8 @@ static void radeon_bomgr_free_va(struct radeon_bomgr *mgr, 
uint64_t va, uint64_t
  {
  struct radeon_bo_va_hole *hole;

+size = align(size, 4096);
+
  pipe_mutex_lock(mgr->bo_va_mutex);
  if ((va + size) == mgr->va_offset) {
  mgr->va_offset = va;
@@ -385,7 +386,7 @@ static void radeon_bo_destroy(struct pb_buffer *_buf)
  drmIoctl(bo->rws->fd, DRM_IOCTL_GEM_CLOSE, &args);

  if (mgr->va) {
-radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
+radeon_bomgr_free_va(mgr, bo->va, bo->base.size);
  }

  pipe_mutex_destroy(bo->map_mutex);
@@ -600,8 +601,7 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
pb_manager *_mgr,
  if (mgr->va) {
  struct drm_radeon_gem_va va;

-bo->va_size = align(size,  4096);
-bo->va = radeon_bomgr_find_va(mgr, bo->va_size, desc->alignment);
+bo->va = radeon_bomgr_find_va(mgr, size, desc->alignment);

  va.handle = bo->handle;
  va.vm_id = 0;
@@ -621,9 +621,9 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
pb_manager *_mgr,
  return NULL;
  }
  if (va.operation == RADEON_VA_RESULT_VA_EXIST) {
-radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
+radeon_bomgr_free_va(mgr, bo->va, size);
  bo->va = va.offset;
-radeon_bomgr_force_va(mgr, bo->va, bo->va_size);
+radeon_bomgr_force_va(mgr, bo->va, size);
  }
  }

@@ -931,8 +931,7 @@ done:
  if (mgr->va && !bo->va) {
  struct drm_radeon_gem_va va;

-bo->va_size = ((bo->base.size + 4095) & ~4095);
-bo->va = radeon_bomgr_find_va(mgr, bo->va_size, 1 << 20);
+bo->va = radeon_bomgr_find_va(mgr, bo->base.size, 1 << 20);

  va.handle = bo->handle;
  va.operation = RADEON_VA_MAP;
@@ -949,9 +948,9 @@ done:
  return NULL;
  }
  if (va.operation == RADEON_VA_RESULT_VA_EXIST) {
-radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
+radeon_bomgr_free_va(mgr, bo->va, bo->base.size);
  bo->va = va.offset;
-radeon_bomgr_force_va(mgr, bo->va, bo->va_size);
+radeon_bomgr_force_va(mgr, bo->va, bo->base.size);
  }
   

[Mesa-dev] [Bug 71506] indirect_glx.c:350: multiple definition of `indirect_create_context'

[bugzilla-daemon]

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

Jon TURNEY  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 CC||jon.tur...@dronecode.org.uk

--- Comment #13 from Jon TURNEY  ---
To ssh://git.freedesktop.org/git/mesa/mesa
   21ae513..5ab59e5  master -> master

-- 
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] winsys/radeon: cleanup virtual memory nonsense

[Alex Deucher]

On Tue, Nov 19, 2013 at 5:05 AM, Christian König
 wrote:
> From: Christian König 
>
> The alignment of a virtual memory area must always be at least 4096 bytes.
>
> It only worked because size was aligned to 4096 outside of the function.
>
> Signed-off-by: Christian König 

CC the 9.2 and 10.0 branches?  Does this fix the problems you were
looking at last week?

Reviewed-by: Alex Deucher 

> ---
>  src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 37 
> +--
>  src/gallium/winsys/radeon/drm/radeon_drm_bo.h |  1 -
>  2 files changed, 18 insertions(+), 20 deletions(-)
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
> b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> index 19e2715..3019a52 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> @@ -202,15 +202,15 @@ static uint64_t radeon_bomgr_find_va(struct 
> radeon_bomgr *mgr, uint64_t size, ui
>  struct radeon_bo_va_hole *hole, *n;
>  uint64_t offset = 0, waste = 0;
>
> +alignment = MAX2(alignment, 4096);
> +size = align(size, 4096);
> +
>  pipe_mutex_lock(mgr->bo_va_mutex);
>  /* first look for a hole */
>  LIST_FOR_EACH_ENTRY_SAFE(hole, n, &mgr->va_holes, list) {
>  offset = hole->offset;
> -waste = 0;
> -if (alignment) {
> -waste = offset % alignment;
> -waste = waste ? alignment - waste : 0;
> -}
> +waste = offset % alignment;
> +waste = waste ? alignment - waste : 0;
>  offset += waste;
>  if (offset >= (hole->offset + hole->size)) {
>  continue;
> @@ -242,11 +242,8 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
> *mgr, uint64_t size, ui
>  }
>
>  offset = mgr->va_offset;
> -waste = 0;
> -if (alignment) {
> -waste = offset % alignment;
> -waste = waste ? alignment - waste : 0;
> -}
> +waste = offset % alignment;
> +waste = waste ? alignment - waste : 0;
>  if (waste) {
>  n = CALLOC_STRUCT(radeon_bo_va_hole);
>  n->size = waste;
> @@ -261,6 +258,8 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
> *mgr, uint64_t size, ui
>
>  static void radeon_bomgr_force_va(struct radeon_bomgr *mgr, uint64_t va, 
> uint64_t size)
>  {
> +size = align(size, 4096);
> +
>  pipe_mutex_lock(mgr->bo_va_mutex);
>  if (va >= mgr->va_offset) {
>  if (va > mgr->va_offset) {
> @@ -303,6 +302,8 @@ static void radeon_bomgr_free_va(struct radeon_bomgr 
> *mgr, uint64_t va, uint64_t
>  {
>  struct radeon_bo_va_hole *hole;
>
> +size = align(size, 4096);
> +
>  pipe_mutex_lock(mgr->bo_va_mutex);
>  if ((va + size) == mgr->va_offset) {
>  mgr->va_offset = va;
> @@ -385,7 +386,7 @@ static void radeon_bo_destroy(struct pb_buffer *_buf)
>  drmIoctl(bo->rws->fd, DRM_IOCTL_GEM_CLOSE, &args);
>
>  if (mgr->va) {
> -radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
> +radeon_bomgr_free_va(mgr, bo->va, bo->base.size);
>  }
>
>  pipe_mutex_destroy(bo->map_mutex);
> @@ -600,8 +601,7 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
> pb_manager *_mgr,
>  if (mgr->va) {
>  struct drm_radeon_gem_va va;
>
> -bo->va_size = align(size,  4096);
> -bo->va = radeon_bomgr_find_va(mgr, bo->va_size, desc->alignment);
> +bo->va = radeon_bomgr_find_va(mgr, size, desc->alignment);
>
>  va.handle = bo->handle;
>  va.vm_id = 0;
> @@ -621,9 +621,9 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
> pb_manager *_mgr,
>  return NULL;
>  }
>  if (va.operation == RADEON_VA_RESULT_VA_EXIST) {
> -radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
> +radeon_bomgr_free_va(mgr, bo->va, size);
>  bo->va = va.offset;
> -radeon_bomgr_force_va(mgr, bo->va, bo->va_size);
> +radeon_bomgr_force_va(mgr, bo->va, size);
>  }
>  }
>
> @@ -931,8 +931,7 @@ done:
>  if (mgr->va && !bo->va) {
>  struct drm_radeon_gem_va va;
>
> -bo->va_size = ((bo->base.size + 4095) & ~4095);
> -bo->va = radeon_bomgr_find_va(mgr, bo->va_size, 1 << 20);
> +bo->va = radeon_bomgr_find_va(mgr, bo->base.size, 1 << 20);
>
>  va.handle = bo->handle;
>  va.operation = RADEON_VA_MAP;
> @@ -949,9 +948,9 @@ done:
>  return NULL;
>  }
>  if (va.operation == RADEON_VA_RESULT_VA_EXIST) {
> -radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
> +radeon_bomgr_free_va(mgr, bo->va, bo->base.size);
>  bo->va = va.offset;
> -radeon_bomgr_force_va(mgr, bo->va, bo->va_size);
> +radeon_bomgr_force_va(mgr, bo->va, bo->base.size);
>  }
>  }
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h 
> b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
> index ee8919b..5536bc1 1006

Re: [Mesa-dev] [PATCH] winsys/radeon: cleanup virtual memory nonsense

[Christian König]

Am 19.11.2013 14:41, schrieb Marek Olšák:

On Tue, Nov 19, 2013 at 11:05 AM, Christian König
 wrote:

From: Christian König 

The alignment of a virtual memory area must always be at least 4096 bytes.

It only worked because size was aligned to 4096 outside of the function.

Signed-off-by: Christian König 
---
  src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 37 +--
  src/gallium/winsys/radeon/drm/radeon_drm_bo.h |  1 -
  2 files changed, 18 insertions(+), 20 deletions(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 19e2715..3019a52 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -202,15 +202,15 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
*mgr, uint64_t size, ui
  struct radeon_bo_va_hole *hole, *n;
  uint64_t offset = 0, waste = 0;

+alignment = MAX2(alignment, 4096);
+size = align(size, 4096);
+
  pipe_mutex_lock(mgr->bo_va_mutex);
  /* first look for a hole */
  LIST_FOR_EACH_ENTRY_SAFE(hole, n, &mgr->va_holes, list) {
  offset = hole->offset;
-waste = 0;
-if (alignment) {
-waste = offset % alignment;
-waste = waste ? alignment - waste : 0;
-}
+waste = offset % alignment;
+waste = waste ? alignment - waste : 0;
  offset += waste;
  if (offset >= (hole->offset + hole->size)) {
  continue;
@@ -242,11 +242,8 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
*mgr, uint64_t size, ui
  }

  offset = mgr->va_offset;
-waste = 0;
-if (alignment) {
-waste = offset % alignment;
-waste = waste ? alignment - waste : 0;
-}
+waste = offset % alignment;
+waste = waste ? alignment - waste : 0;
  if (waste) {
  n = CALLOC_STRUCT(radeon_bo_va_hole);
  n->size = waste;
@@ -261,6 +258,8 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
*mgr, uint64_t size, ui

  static void radeon_bomgr_force_va(struct radeon_bomgr *mgr, uint64_t va, 
uint64_t size)
  {
+size = align(size, 4096);
+
  pipe_mutex_lock(mgr->bo_va_mutex);
  if (va >= mgr->va_offset) {
  if (va > mgr->va_offset) {
@@ -303,6 +302,8 @@ static void radeon_bomgr_free_va(struct radeon_bomgr *mgr, 
uint64_t va, uint64_t
  {
  struct radeon_bo_va_hole *hole;

+size = align(size, 4096);
+
  pipe_mutex_lock(mgr->bo_va_mutex);
  if ((va + size) == mgr->va_offset) {
  mgr->va_offset = va;
@@ -385,7 +386,7 @@ static void radeon_bo_destroy(struct pb_buffer *_buf)
  drmIoctl(bo->rws->fd, DRM_IOCTL_GEM_CLOSE, &args);

  if (mgr->va) {
-radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
+radeon_bomgr_free_va(mgr, bo->va, bo->base.size);
  }

  pipe_mutex_destroy(bo->map_mutex);
@@ -600,8 +601,7 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
pb_manager *_mgr,
  if (mgr->va) {
  struct drm_radeon_gem_va va;

-bo->va_size = align(size,  4096);
-bo->va = radeon_bomgr_find_va(mgr, bo->va_size, desc->alignment);
+bo->va = radeon_bomgr_find_va(mgr, size, desc->alignment);

  va.handle = bo->handle;
  va.vm_id = 0;
@@ -621,9 +621,9 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
pb_manager *_mgr,
  return NULL;
  }
  if (va.operation == RADEON_VA_RESULT_VA_EXIST) {
-radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
+radeon_bomgr_free_va(mgr, bo->va, size);
  bo->va = va.offset;
-radeon_bomgr_force_va(mgr, bo->va, bo->va_size);
+radeon_bomgr_force_va(mgr, bo->va, size);
  }
  }

@@ -931,8 +931,7 @@ done:
  if (mgr->va && !bo->va) {
  struct drm_radeon_gem_va va;

-bo->va_size = ((bo->base.size + 4095) & ~4095);
-bo->va = radeon_bomgr_find_va(mgr, bo->va_size, 1 << 20);
+bo->va = radeon_bomgr_find_va(mgr, bo->base.size, 1 << 20);

Why is the alignment 1<<20 (2M) here? Other than that:


I guess that the alignment isn't available at this point.

IIRC the maximum alignment for our hardware is 1<< (8 + log2(number of 
pipes) + log2(number of banks)) and I think it's going to be a while 
till we break the limit of 64 pipes/banks. So 1<<20 should work fine for 
now.


Christian.


Reviewed-by: Marek Olšák 

Marek


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

Re: [Mesa-dev] rules for merging patches to libdrm

[Christian König]

For merging the patches for new hardware and/or features I agree on the 
process of merging things bottom up. (e.g kernel first, then libdrm, 
mesa last). But to give reasons for the merge into Linus tree it's 
usually better to have a "big picture" you can validate the code against.


So I think the very first step should be to publish everything on the 
appropriate lists, and not try an approach like releasing the kernel 
code first and waiting for it to show up upstream and then try to 
release the userspace code build on top of it.


I had this situation a couple of times where "management" people wanted 
to release things bit by bit to "speed things up" and it always took me 
a bit of time to explain that this wouldn't work in the open source 
world (at least not with the Linux kernel).


Christian.

Am 19.11.2013 15:26, schrieb Marek Olšák:

Having patches on a mailing list is good enough, but generally if
people *trust* you that you will have an open userspace, that's good
enough too if you have people's trust.

In my opinion, the required kernel code must land in Linus's tree
first. If it's not there, it's like it didn't exist at all. Then you
can merge and release dependent libdrm code. And after that, you can
merge dependent Mesa code.

This is really common sense and I don't think we need a strict process
to enforce the rules.

Marek

On Fri, Nov 8, 2013 at 11:32 PM, Matt Turner  wrote:

On Fri, Nov 8, 2013 at 11:29 AM, Dave Airlie  wrote:

Since we seemed to have some confusion over this I'll state it clearly here.

You should not merge kernel interface and ioctls to libdrm until they
have appeared in a git commit upstream with a stable id, this
generally means drm-next, but can also mean drm-intel-next.

How does this interact with the rule that kernel interfaces require an
open source userspace? Is "here are the mesa/libdrm patches that use
it" sufficient to get the kernel interface merged?

libdrm is easy to change and its releases are cheap. What problem does
committing code that uses an in-progress kernel interface to libdrm
cause? I guess I'm not understanding something.
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
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] rules for merging patches to libdrm

[Marek Olšák]

Having patches on a mailing list is good enough, but generally if
people *trust* you that you will have an open userspace, that's good
enough too if you have people's trust.

In my opinion, the required kernel code must land in Linus's tree
first. If it's not there, it's like it didn't exist at all. Then you
can merge and release dependent libdrm code. And after that, you can
merge dependent Mesa code.

This is really common sense and I don't think we need a strict process
to enforce the rules.

Marek

On Fri, Nov 8, 2013 at 11:32 PM, Matt Turner  wrote:
> On Fri, Nov 8, 2013 at 11:29 AM, Dave Airlie  wrote:
>> Since we seemed to have some confusion over this I'll state it clearly here.
>>
>> You should not merge kernel interface and ioctls to libdrm until they
>> have appeared in a git commit upstream with a stable id, this
>> generally means drm-next, but can also mean drm-intel-next.
>
> How does this interact with the rule that kernel interfaces require an
> open source userspace? Is "here are the mesa/libdrm patches that use
> it" sufficient to get the kernel interface merged?
>
> libdrm is easy to change and its releases are cheap. What problem does
> committing code that uses an in-progress kernel interface to libdrm
> cause? I guess I'm not understanding something.
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 70920] [PIGLIT, radeonsi] SIGSEGV for shaders/glsl-fs-inline-explosion

[bugzilla-daemon]

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

Kai  changed:

   What|Removed |Added

 CC||mesa-dev@lists.freedesktop.
   ||org

--- Comment #2 from Kai  ---
Adding mesa-dev, since I'm pretty sure others besides the fine people at Intel
might have an idea what the cause is. ;-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] winsys/radeon: cleanup virtual memory nonsense

[Marek Olšák]

On Tue, Nov 19, 2013 at 11:05 AM, Christian König
 wrote:
> From: Christian König 
>
> The alignment of a virtual memory area must always be at least 4096 bytes.
>
> It only worked because size was aligned to 4096 outside of the function.
>
> Signed-off-by: Christian König 
> ---
>  src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 37 
> +--
>  src/gallium/winsys/radeon/drm/radeon_drm_bo.h |  1 -
>  2 files changed, 18 insertions(+), 20 deletions(-)
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
> b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> index 19e2715..3019a52 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
> @@ -202,15 +202,15 @@ static uint64_t radeon_bomgr_find_va(struct 
> radeon_bomgr *mgr, uint64_t size, ui
>  struct radeon_bo_va_hole *hole, *n;
>  uint64_t offset = 0, waste = 0;
>
> +alignment = MAX2(alignment, 4096);
> +size = align(size, 4096);
> +
>  pipe_mutex_lock(mgr->bo_va_mutex);
>  /* first look for a hole */
>  LIST_FOR_EACH_ENTRY_SAFE(hole, n, &mgr->va_holes, list) {
>  offset = hole->offset;
> -waste = 0;
> -if (alignment) {
> -waste = offset % alignment;
> -waste = waste ? alignment - waste : 0;
> -}
> +waste = offset % alignment;
> +waste = waste ? alignment - waste : 0;
>  offset += waste;
>  if (offset >= (hole->offset + hole->size)) {
>  continue;
> @@ -242,11 +242,8 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
> *mgr, uint64_t size, ui
>  }
>
>  offset = mgr->va_offset;
> -waste = 0;
> -if (alignment) {
> -waste = offset % alignment;
> -waste = waste ? alignment - waste : 0;
> -}
> +waste = offset % alignment;
> +waste = waste ? alignment - waste : 0;
>  if (waste) {
>  n = CALLOC_STRUCT(radeon_bo_va_hole);
>  n->size = waste;
> @@ -261,6 +258,8 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
> *mgr, uint64_t size, ui
>
>  static void radeon_bomgr_force_va(struct radeon_bomgr *mgr, uint64_t va, 
> uint64_t size)
>  {
> +size = align(size, 4096);
> +
>  pipe_mutex_lock(mgr->bo_va_mutex);
>  if (va >= mgr->va_offset) {
>  if (va > mgr->va_offset) {
> @@ -303,6 +302,8 @@ static void radeon_bomgr_free_va(struct radeon_bomgr 
> *mgr, uint64_t va, uint64_t
>  {
>  struct radeon_bo_va_hole *hole;
>
> +size = align(size, 4096);
> +
>  pipe_mutex_lock(mgr->bo_va_mutex);
>  if ((va + size) == mgr->va_offset) {
>  mgr->va_offset = va;
> @@ -385,7 +386,7 @@ static void radeon_bo_destroy(struct pb_buffer *_buf)
>  drmIoctl(bo->rws->fd, DRM_IOCTL_GEM_CLOSE, &args);
>
>  if (mgr->va) {
> -radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
> +radeon_bomgr_free_va(mgr, bo->va, bo->base.size);
>  }
>
>  pipe_mutex_destroy(bo->map_mutex);
> @@ -600,8 +601,7 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
> pb_manager *_mgr,
>  if (mgr->va) {
>  struct drm_radeon_gem_va va;
>
> -bo->va_size = align(size,  4096);
> -bo->va = radeon_bomgr_find_va(mgr, bo->va_size, desc->alignment);
> +bo->va = radeon_bomgr_find_va(mgr, size, desc->alignment);
>
>  va.handle = bo->handle;
>  va.vm_id = 0;
> @@ -621,9 +621,9 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
> pb_manager *_mgr,
>  return NULL;
>  }
>  if (va.operation == RADEON_VA_RESULT_VA_EXIST) {
> -radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
> +radeon_bomgr_free_va(mgr, bo->va, size);
>  bo->va = va.offset;
> -radeon_bomgr_force_va(mgr, bo->va, bo->va_size);
> +radeon_bomgr_force_va(mgr, bo->va, size);
>  }
>  }
>
> @@ -931,8 +931,7 @@ done:
>  if (mgr->va && !bo->va) {
>  struct drm_radeon_gem_va va;
>
> -bo->va_size = ((bo->base.size + 4095) & ~4095);
> -bo->va = radeon_bomgr_find_va(mgr, bo->va_size, 1 << 20);
> +bo->va = radeon_bomgr_find_va(mgr, bo->base.size, 1 << 20);

Why is the alignment 1<<20 (2M) here? Other than that:

Reviewed-by: Marek Olšák 

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

Re: [Mesa-dev] [PATCH] tests: Fix make check for out of tree builds.

[Jon TURNEY]

On 11/11/2013 22:06, Matt Turner wrote:
> On Mon, Nov 11, 2013 at 12:18 PM, Rico Schüller  wrote:
>> Signed-off-by: Rico Schüller 
>> ---
>>  src/mapi/shared-glapi/tests/Makefile.am | 1 +
>>  src/mesa/main/tests/Makefile.am | 1 +
>>  2 Dateien geändert, 2 Zeilen hinzugefügt(+)
>>
>> diff --git a/src/mapi/shared-glapi/tests/Makefile.am 
>> b/src/mapi/shared-glapi/tests/Makefile.am
>> index 98065fc..7e71b4f 100644
>> --- a/src/mapi/shared-glapi/tests/Makefile.am
>> +++ b/src/mapi/shared-glapi/tests/Makefile.am
>> @@ -3,6 +3,7 @@ AM_CFLAGS = $(PTHREAD_CFLAGS)
>>  AM_CPPFLAGS = \
>> -I$(top_srcdir)/src/gtest/include \
>> -I$(top_srcdir)/src/mapi \
>> +   -I$(top_builddir)/src/mapi \
>> -I$(top_srcdir)/include
>>
>>  TESTS = shared-glapi-test
> 
> Thanks! Reviewed-by and committed.

It seems that 'make check' for unshared glapi needs a similar fix.  Patch
attached.


>From 76130730ad77db1225190d1afa0ec2a07a055d58 Mon Sep 17 00:00:00 2001
From: Jon TURNEY 
Date: Fri, 8 Nov 2013 13:22:54 +
Subject: [PATCH 2/4] Fix 'make check' in src/mapi/glapi/tests when builddir !=
 srcdir

make[5]: Entering directory `/jhbuild/build/mesa/mesa/src/mapi/glapi/tests'
  CXX  check_table.o
/jhbuild/checkout/mesa/mesa/src/mapi/glapi/tests/check_table.cpp:29:30: fatal 
error: glapi/glapitable.h: No such file or directory

We should look for the generated file glapi/glapitable.h in builddir, not srcdir

Signed-off-by: Jon TURNEY 
---
 src/mapi/glapi/tests/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mapi/glapi/tests/Makefile.am b/src/mapi/glapi/tests/Makefile.am
index 26149c9..da1094b 100644
--- a/src/mapi/glapi/tests/Makefile.am
+++ b/src/mapi/glapi/tests/Makefile.am
@@ -3,6 +3,7 @@ AM_CFLAGS = $(PTHREAD_CFLAGS)
 AM_CPPFLAGS = \
$(DEFINES) \
-I$(top_srcdir)/src/gtest/include \
+   -I$(top_builddir)/src/mapi \
-I$(top_srcdir)/src/mapi \
-I$(top_srcdir)/include
 
-- 
1.8.3.4

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

[Mesa-dev] [PATCH] glsl: Improve error message when attemping assignment to unsized array

[Timothy Arceri]

Signed-off-by: Timothy Arceri 
---
 src/glsl/ast_to_hir.cpp | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 76b256c..73be274 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -696,9 +696,14 @@ validate_assignment(struct _mesa_glsl_parse_state *state,
 * Note: Whole-array assignments are not permitted in GLSL 1.10, but this
 * is handled by ir_dereference::is_lvalue.
 */
-   if (is_initializer && lhs_type->is_unsized_array() && rhs->type->is_array()
+   if (lhs_type->is_unsized_array() && rhs->type->is_array()
&& (lhs_type->element_type() == rhs->type->element_type())) {
-  return rhs;
+  if (is_initializer) {
+ return rhs;
+  } else {
+ _mesa_glsl_error(&loc, state,
+  "implicitly sized arrays cannot be assigned to");
+  }
}
 
/* Check for implicit conversion in GLSL 1.20 */
-- 
1.8.3.1

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

[Mesa-dev] [PATCH] winsys/radeon: cleanup virtual memory nonsense

[Christian König]

From: Christian König 

The alignment of a virtual memory area must always be at least 4096 bytes.

It only worked because size was aligned to 4096 outside of the function.

Signed-off-by: Christian König 
---
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 37 +--
 src/gallium/winsys/radeon/drm/radeon_drm_bo.h |  1 -
 2 files changed, 18 insertions(+), 20 deletions(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 19e2715..3019a52 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -202,15 +202,15 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
*mgr, uint64_t size, ui
 struct radeon_bo_va_hole *hole, *n;
 uint64_t offset = 0, waste = 0;
 
+alignment = MAX2(alignment, 4096);
+size = align(size, 4096);
+
 pipe_mutex_lock(mgr->bo_va_mutex);
 /* first look for a hole */
 LIST_FOR_EACH_ENTRY_SAFE(hole, n, &mgr->va_holes, list) {
 offset = hole->offset;
-waste = 0;
-if (alignment) {
-waste = offset % alignment;
-waste = waste ? alignment - waste : 0;
-}
+waste = offset % alignment;
+waste = waste ? alignment - waste : 0;
 offset += waste;
 if (offset >= (hole->offset + hole->size)) {
 continue;
@@ -242,11 +242,8 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
*mgr, uint64_t size, ui
 }
 
 offset = mgr->va_offset;
-waste = 0;
-if (alignment) {
-waste = offset % alignment;
-waste = waste ? alignment - waste : 0;
-}
+waste = offset % alignment;
+waste = waste ? alignment - waste : 0;
 if (waste) {
 n = CALLOC_STRUCT(radeon_bo_va_hole);
 n->size = waste;
@@ -261,6 +258,8 @@ static uint64_t radeon_bomgr_find_va(struct radeon_bomgr 
*mgr, uint64_t size, ui
 
 static void radeon_bomgr_force_va(struct radeon_bomgr *mgr, uint64_t va, 
uint64_t size)
 {
+size = align(size, 4096);
+
 pipe_mutex_lock(mgr->bo_va_mutex);
 if (va >= mgr->va_offset) {
 if (va > mgr->va_offset) {
@@ -303,6 +302,8 @@ static void radeon_bomgr_free_va(struct radeon_bomgr *mgr, 
uint64_t va, uint64_t
 {
 struct radeon_bo_va_hole *hole;
 
+size = align(size, 4096);
+
 pipe_mutex_lock(mgr->bo_va_mutex);
 if ((va + size) == mgr->va_offset) {
 mgr->va_offset = va;
@@ -385,7 +386,7 @@ static void radeon_bo_destroy(struct pb_buffer *_buf)
 drmIoctl(bo->rws->fd, DRM_IOCTL_GEM_CLOSE, &args);
 
 if (mgr->va) {
-radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
+radeon_bomgr_free_va(mgr, bo->va, bo->base.size);
 }
 
 pipe_mutex_destroy(bo->map_mutex);
@@ -600,8 +601,7 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
pb_manager *_mgr,
 if (mgr->va) {
 struct drm_radeon_gem_va va;
 
-bo->va_size = align(size,  4096);
-bo->va = radeon_bomgr_find_va(mgr, bo->va_size, desc->alignment);
+bo->va = radeon_bomgr_find_va(mgr, size, desc->alignment);
 
 va.handle = bo->handle;
 va.vm_id = 0;
@@ -621,9 +621,9 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
pb_manager *_mgr,
 return NULL;
 }
 if (va.operation == RADEON_VA_RESULT_VA_EXIST) {
-radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
+radeon_bomgr_free_va(mgr, bo->va, size);
 bo->va = va.offset;
-radeon_bomgr_force_va(mgr, bo->va, bo->va_size);
+radeon_bomgr_force_va(mgr, bo->va, size);
 }
 }
 
@@ -931,8 +931,7 @@ done:
 if (mgr->va && !bo->va) {
 struct drm_radeon_gem_va va;
 
-bo->va_size = ((bo->base.size + 4095) & ~4095);
-bo->va = radeon_bomgr_find_va(mgr, bo->va_size, 1 << 20);
+bo->va = radeon_bomgr_find_va(mgr, bo->base.size, 1 << 20);
 
 va.handle = bo->handle;
 va.operation = RADEON_VA_MAP;
@@ -949,9 +948,9 @@ done:
 return NULL;
 }
 if (va.operation == RADEON_VA_RESULT_VA_EXIST) {
-radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
+radeon_bomgr_free_va(mgr, bo->va, bo->base.size);
 bo->va = va.offset;
-radeon_bomgr_force_va(mgr, bo->va, bo->va_size);
+radeon_bomgr_force_va(mgr, bo->va, bo->base.size);
 }
 }
 
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
index ee8919b..5536bc1 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
@@ -56,7 +56,6 @@ struct radeon_bo {
 uint32_t handle;
 uint32_t name;
 uint64_t va;
-uint64_t va_size;
 enum radeon_bo_domain initial_domain;
 
 /* how many command streams is this bo referenced in? */
-- 
1.8.1.2

___
mesa-dev mailing list

Re: [Mesa-dev] sampler arrays indexed with non-constant expressions

[Erik Faye-Lund]

On Mon, Nov 18, 2013 at 9:04 PM, Paul Berry  wrote:
> On 17 November 2013 00:24, Victor Luchitz  wrote:
>> If compiler actually attempted to unroll the loop above, it would notice
>> that the does compile correctly. Instead it just emits and error and in my
>> opinion, contradicts the comment above but not allowing the "useful thing"
>> in question.
>>
>> Can the compiler be changed to _first_ attempt to unroll the loop and then
>> check for sampler array indices being constants?
>
>
> Thanks for the feedback, Victor.  We are always interested in hearing
> suggestions about how to improve Mesa.
>
> Unfortunately, in this case, your suggestion would make Mesa non-conformant
> with the GLSL specs because it would allow shaders that are prohibited by
> the spec.  Generally we try to avoid this sort of non-spec-conformance
> because it leads to portability problems for developers like you (e.g. your
> shader works with Mesa, but it fails with other GL implementations).  A
> further problem is that Mesa has heuristics to decide whether to unroll
> loops; if we followed your suggestion, then your shader might work today,
> but fail tomorrow if you make a small change to the shader that makes Mesa
> decide not to unroll the loop (or we make a change to the heuristics in a
> future release of Mesa).

Just as minor nit, I'd like to point out that the OpenGL ES 2.0
shading language specification defines a concept of
"constant-index-expressions" which includes loop indices, and allows
sampler arrays to be indexed by these expressions. This only works
because it at the same time does not allow arbitrary loops. See
appendix A, section 4 and 5 of the spec for the details.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 70766] Run-time link error in swrast_dri.so

[bugzilla-daemon]

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

--- Comment #1 from octoploid  ---
Similar thing here:
 (EE) AIGLX error: dlopen of /usr/lib64/dri/r600_dri.so failed
(/usr/lib64/dri/r600_dri.so: undefined symbol: _ZTIN4llvm18format_object_baseE)
 (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed
(/usr/lib64/dri/swrast_dri.so: undefined symbol:
_ZTIN4llvm18format_object_baseE) 

 % c++filt _ZTIN4llvm18format_object_baseE
typeinfo for llvm::format_object_base

Your patch to src/gallium/auxiliary/Makefile.am fixes the issue.

Please note that:
 % llvm-config --cxxflags
-I/usr/local/include  -fPIC -fvisibility-inlines-hidden -Wall -W
-Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic
-Wno-long-long -Wno-maybe-uninitialized -Wnon-virtual-dtor -O3 -DNDEBUG -pipe 
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS
doesn't include -fno-rtti for llvm 3.4 even when llvm was build without
run-time type information (the default).

-- 
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] mesa: enable GL_TEXTURE_LOD_BIAS set/get

[Tapani Pälli]

Earlier comments suggest this was removed from GL core spec but it is
still there. Enabling makes 'texture_lod_bias_getter' Khronos
conformance tests pass, also removes some errors from Metro Last Light
game which is using this API.

Signed-off-by: Tapani Pälli 
---
 src/mesa/main/texparam.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index d56b7d9..e1bfeb0 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -684,11 +684,7 @@ set_tex_parameterf(struct gl_context *ctx,
   return GL_FALSE;
 
case GL_TEXTURE_LOD_BIAS:
-  /* NOTE: this is really part of OpenGL 1.4, not EXT_texture_lod_bias.
-   * It was removed in core-profile, and it has never existed in OpenGL
-   * ES.
-   */
-  if (ctx->API != API_OPENGL_COMPAT)
+  if (_mesa_is_gles(ctx))
  goto invalid_pname;
 
   if (!target_allows_setting_sampler_parameters(texObj->Target))
@@ -1513,7 +1509,7 @@ _mesa_GetTexParameterfv( GLenum target, GLenum pname, 
GLfloat *params )
  *params = (GLfloat) obj->DepthMode;
  break;
   case GL_TEXTURE_LOD_BIAS:
- if (ctx->API != API_OPENGL_COMPAT)
+ if (_mesa_is_gles(ctx))
 goto invalid_pname;
 
  *params = obj->Sampler.LodBias;
@@ -1701,10 +1697,13 @@ _mesa_GetTexParameteriv( GLenum target, GLenum pname, 
GLint *params )
  *params = (GLint) obj->DepthMode;
  break;
   case GL_TEXTURE_LOD_BIAS:
- if (ctx->API != API_OPENGL_COMPAT)
+ if (_mesa_is_gles(ctx))
 goto invalid_pname;
 
- *params = (GLint) obj->Sampler.LodBias;
+ /* GL spec 'Data Conversions' section specifies that floating-point
+  * value in integer Get function is rounded to nearest integer
+  */
+ *params = (GLint) roundf(obj->Sampler.LodBias);
  break;
   case GL_TEXTURE_CROP_RECT_OES:
  if (ctx->API != API_OPENGLES || !ctx->Extensions.OES_draw_texture)
-- 
1.8.1.4

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

Re: [Mesa-dev] rules for merging patches to libdrm

[Thierry Reding]

On Mon, Nov 18, 2013 at 01:38:55PM -0500, Jerome Glisse wrote:
> On Mon, Nov 18, 2013 at 05:41:50PM +0100, Thierry Reding wrote:
> > On Mon, Nov 18, 2013 at 11:21:36AM -0500, Rob Clark wrote:
> > > On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding
> > >  wrote:
> > > > On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote:
> > > >> On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding
> > > >>  wrote:
> > > >> > On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote:
> > > >> >> On 11/09/2013 12:11 AM, Dave Airlie wrote:
> > > >> >> >>> How does this interact with the rule that kernel interfaces 
> > > >> >> >>> require an
> > > >> >> >>> open source userspace? Is "here are the mesa/libdrm patches 
> > > >> >> >>> that use
> > > >> >> >>> it" sufficient to get the kernel interface merged?
> > > >> >> >>
> > > >> >> >> That's my understanding: open source userspace needs to exist, 
> > > >> >> >> but it
> > > >> >> >> doesn't need to be merged upstream yet.
> > > >> >> >
> > > >> >> > Having an opensource userspace and having it committed to a final 
> > > >> >> > repo
> > > >> >> > are different things, as Daniel said patches on the mesa-list were
> > > >> >> > sufficient, they're was no hurry to merge them considering a 
> > > >> >> > kernel
> > > >> >> > release with the code wasn't close, esp with a 3 month release 
> > > >> >> > window
> > > >> >> > if the kernel merge window is close to that anyways.
> > > >> >> >
> > > >> >> >>> libdrm is easy to change and its releases are cheap. What 
> > > >> >> >>> problem does
> > > >> >> >>> committing code that uses an in-progress kernel interface to 
> > > >> >> >>> libdrm
> > > >> >> >>> cause? I guess I'm not understanding something.
> > > >> >> >>
> > > >> >> >
> > > >> >> > Releases are cheap, but ABI breaks aren't so you can't just go 
> > > >> >> > release
> > > >> >> > a libdrm with an ABI for mesa then decide later it was a bad plan.
> > > >> >> >
> > > >> >> >> Introducing new kernel API usually involves assigning numbers 
> > > >> >> >> for things
> > > >> >> >> - a new ioctl number, new #defines for bitfield members, and so 
> > > >> >> >> on.
> > > >> >> >>
> > > >> >> >> Multiple patches can be in flight at the same time.  For 
> > > >> >> >> example, Abdiel
> > > >> >> >> and I both defined execbuf2 flags:
> > > >> >> >>
> > > >> >> >> #define I915_EXEC_RS (1 << 13) (Abdiel's code)
> > > >> >> >> #define I915_EXEC_OA (1 << 13) (my code)
> > > >> >> >>
> > > >> >> >> These obviously conflict.  One of the two will land, and the 
> > > >> >> >> second
> > > >> >> >> patch author will need to switch to (1 << 14) and resubmit.
> > > >> >> >>
> > > >> >> >> If we both decide to push to libdrm, we might get the order 
> > > >> >> >> backwards,
> > > >> >> >> or maybe one series won't get pushed at all (in this case, I'm 
> > > >> >> >> planning
> > > >> >> >> to drop my patch).  Waiting until one lands in the kernel avoids 
> > > >> >> >> that
> > > >> >> >> problem.  Normally, I believe we copy the kernel headers to 
> > > >> >> >> userspace
> > > >> >> >> and fix them up a bit.
> > > >> >> >>
> > > >> >> >> Dave may have other reasons; this is just the one I thought of.
> > > >> >> >
> > > >> >> > But mostly this, we've been stung by this exact thing happening
> > > >> >> > before, and we made the process to stop it from happening again.
> > > >> >>
> > > >> >> Then in all honestly, commits to libdrm should be controlled by 
> > > >> >> either a
> > > >> >> single person or a small cabal... just like the kernel and the 
> > > >> >> xserver.
> > > >> >>  We're clearly in an uncomfortable middle area where we have a 
> > > >> >> stringent
> > > >> >> set of restrictions but no way to actually enforce them.
> > > >> >
> > > >> > That doesn't sound like a bad idea at all. It obviously causes more 
> > > >> > work
> > > >> > for whoever will be the gatekeeper(s).
> > > >> >
> > > >> > It seems to me that libdrm is currently more of a free-for-all type 
> > > >> > of
> > > >> > project, and whoever merges some new feature required for a 
> > > >> > particular X
> > > >> > or Mesa driver cuts a new release so that the version number can be 
> > > >> > used
> > > >> > to track the dependency.
> > > >> >
> > > >> > I wonder if perhaps tying the libdrm releases more tightly to Linux
> > > >> > kernel releases would help. Since there already is a requirement for 
> > > >> > new
> > > >> > kernel APIs to be merged before the libdrm equivalent can be merged,
> > > >> > then having both release cycles in lockstep makes some sense.
> > > >>
> > > >> Not sure about strictly tying it to kernel releases would be ideal.
> > > >> Not *everything* in libdrm is about new kernel APIs.  It tends to be
> > > >> the place for things needed both by xorg ddx and mesa driver, which I
> > > >> suppose is why it ends up a bit of a free-for-all.
> > > >
> > > > I didn't mean that every release would need to be tied to the Linux
> > > > kernel. But whenever a new Linux ke