Re: [Mesa-dev] [PATCH] glsl: type check between switch init-expression and case

[Matt Turner]

On Mon, Jun 9, 2014 at 11:51 PM, Tapani Pälli  wrote:
> On 06/10/2014 08:28 AM, Tapani Pälli wrote:
>> On 06/09/2014 09:40 PM, Matt Turner wrote:
>>> On Mon, Jun 9, 2014 at 4:29 AM, Tapani Pälli  wrote:
 Signed-off-by: Tapani Pälli 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79724
 ---
  src/glsl/ast_to_hir.cpp | 9 +
  1 file changed, 9 insertions(+)

 diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
 index d1c77f1..131b25f 100644
 --- a/src/glsl/ast_to_hir.cpp
 +++ b/src/glsl/ast_to_hir.cpp
 @@ -4629,6 +4629,15 @@ ast_case_label::hir(exec_list *instructions,
   }
}

 +  /* Check that types match (no implicit conversions allowed). */
>>> Good news. GLSL 4.30 updated the text to say (I think as a
>>> clarification, so we should have this behavior always):
>> OK, should have realized to check the latest spec too. This is a good
>> addition.
>>
>>> The type of the init-expression value in a switch statement must be a
>>> scalar int or uint. The type of the constant-expression value in a case
>>> label also must be a scalar int or uint. When any pair of these values
>>> is tested for "equal value" and the types do not match, an implicit
>>> conversion will be done to convert the int to a uint (see section 4.1.10
>>> “Implicit Conversions”) before the compare is done.
>>>
>>> Please replace this comment with that spec citation in our usual
>>> format. I guess we'll need a little bit of code to handle implicit
>>> conversions here, but apparently only for int -> uint which is a
>>> relief.
>> Thanks, I will make the appropriate changes.
>
> Older versions of GLSL spec (like 3.30) does have "There are no implicit
> conversions between signed and unsigned integers." though, does this
> check need to be version specific or are we safe just supporting the
> implicit conversion?

Oh, good question. My mistake -- implicit conversions from int -> uint
were added by ARB_gpu_shader5 or GL 4.0. We should only perform them
if we're using either of those.

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

[Mesa-dev] [PATCH] glx: Add an error message when a direct renderer's createScreen() routine fails because no matching fbConfigs or visuals could be found.

[Jon TURNEY]

Nearly all the error cases in *createScreen() issue an error message to diagnose
the failure to initialize before branching to handle_error.  The few remaining
error cases which don't should probably do the same.

(At the moment, it seems this can be triggered in drisw with an X server which
reports definite values for MAX_PBUFFFER_(WIDTH|HEIGHT|SIZE), because those
attributes are checked for an exact match against 0.)

Signed-off-by: Jon TURNEY 
---
 src/glx/dri2_glx.c  | 4 +++-
 src/glx/dri3_glx.c  | 4 +++-
 src/glx/dri_glx.c   | 4 +++-
 src/glx/drisw_glx.c | 4 +++-
 4 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index bd7ed8b..462d560 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -1263,8 +1263,10 @@ dri2CreateScreen(int screen, struct glx_display * priv)
configs = driConvertConfigs(psc->core, psc->base.configs, driver_configs);
visuals = driConvertConfigs(psc->core, psc->base.visuals, driver_configs);
 
-   if (!configs || !visuals)
+   if (!configs || !visuals) {
+   ErrorMessageF("No matching fbConfigs or visuals found\n");
goto handle_error;
+   }
 
glx_config_destroy_list(psc->base.configs);
psc->base.configs = configs;
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 3d8a662..55eed39 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -1741,8 +1741,10 @@ dri3_create_screen(int screen, struct glx_display * priv)
configs = driConvertConfigs(psc->core, psc->base.configs, driver_configs);
visuals = driConvertConfigs(psc->core, psc->base.visuals, driver_configs);
 
-   if (!configs || !visuals)
+   if (!configs || !visuals) {
+   ErrorMessageF("No matching fbConfigs or visuals found\n");
goto handle_error;
+   }
 
glx_config_destroy_list(psc->base.configs);
psc->base.configs = configs;
diff --git a/src/glx/dri_glx.c b/src/glx/dri_glx.c
index 04a0847..5295331 100644
--- a/src/glx/dri_glx.c
+++ b/src/glx/dri_glx.c
@@ -460,8 +460,10 @@ CallCreateNewScreen(Display *dpy, int scrn, struct 
dri_screen *psc,
configs = driConvertConfigs(psc->core, psc->base.configs, driver_configs);
visuals = driConvertConfigs(psc->core, psc->base.visuals, driver_configs);
 
-   if (!configs || !visuals)
+   if (!configs || !visuals) {
+   ErrorMessageF("No matching fbConfigs or visuals found\n");
goto handle_error;
+   }
 
glx_config_destroy_list(psc->base.configs);
psc->base.configs = configs;
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 5885b66..fcb5d8f 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -733,8 +733,10 @@ driswCreateScreen(int screen, struct glx_display *priv)
configs = driConvertConfigs(psc->core, psc->base.configs, driver_configs);
visuals = driConvertConfigs(psc->core, psc->base.visuals, driver_configs);
 
-   if (!configs || !visuals)
+   if (!configs || !visuals) {
+   ErrorMessageF("No matching fbConfigs or visuals found\n");
goto handle_error;
+   }
 
glx_config_destroy_list(psc->base.configs);
psc->base.configs = configs;
-- 
1.8.5.5

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

[Mesa-dev] [PATCH] configure: Don't special case Cygwin to use gnu99, define _XOPEN_SOURCE instead

[Jon TURNEY]

Revert "build: Build on Cygwin with gnu99 instead of c99." and define
_XOPEN_SOURCE appropriately.

This reverts commit 53e36d333c9b619c1a5fe9a8d2d08665654b0234.

Since Cygwin 1.7.18 (April 2013), it's headers correctly prototype strtoll()
when using -std=c99, and correctly prototype strdup() when _XOPEN_SOURCE is
defined appropriately, so this workaround is no longer needed.

Signed-off-by: Jon TURNEY 
Cc: Vinson Lee 
---
 configure.ac | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1525b20..802b05a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -159,20 +159,13 @@ solaris*)
 DEFINES="$DEFINES -DHAVE_PTHREAD -DSVR4"
 ;;
 cygwin*)
-DEFINES="$DEFINES -DHAVE_PTHREAD"
+DEFINES="$DEFINES -D_XOPEN_SOURCE=500 -DHAVE_PTHREAD"
 ;;
 esac
 
 dnl Add flags for gcc and g++
 if test "x$GCC" = xyes; then
-case "$host_os" in
-cygwin*)
-CFLAGS="$CFLAGS -Wall -std=gnu99"
-;;
-*)
-CFLAGS="$CFLAGS -Wall -std=c99"
-;;
-esac
+CFLAGS="$CFLAGS -Wall -std=c99"
 
 # Enable -Werror=implicit-function-declaration and
 # -Werror=missing-prototypes, if available, or otherwise, just
-- 
1.8.5.5

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

Re: [Mesa-dev] [PATCH] Fix zero-division in llvmpipe_texture_layout()

[Roland Scheidegger]

Am 07.06.2014 20:38, schrieb Johannes Obermayr:
> From: Takashi Iwai 
> 
> Fix the crash of "gnome-control-center info" invocation on QEMU where
> zero height is passed at init.
> 
> Fixes: https://bugzilla.novell.com/show_bug.cgi?id=879462
> 
> Signed-off-by: Takashi Iwai 
> ---
> To: mesa-dev@lists.freedesktop.org
> Cc: "10.2" 
> Takashi: Please send also a proper patch to mesa-dev and mesa-stable next 
> time ...
> ---
>  src/gallium/drivers/llvmpipe/lp_texture.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c 
> b/src/gallium/drivers/llvmpipe/lp_texture.c
> index f601181..5ab2559 100644
> --- a/src/gallium/drivers/llvmpipe/lp_texture.c
> +++ b/src/gallium/drivers/llvmpipe/lp_texture.c
> @@ -115,7 +115,7 @@ llvmpipe_texture_layout(struct llvmpipe_screen *screen,
>  lpr->row_stride[level] = align(nblocksx * block_size, 
> util_cpu_caps.cacheline);
>  
>   /* if row_stride * height > LP_MAX_TEXTURE_SIZE */
> - if (lpr->row_stride[level] > LP_MAX_TEXTURE_SIZE / nblocksy) {
> + if (nblocksy && lpr->row_stride[level] > LP_MAX_TEXTURE_SIZE / 
> nblocksy) {
>  /* image too large */
>  goto fail;
>   }
> 

I am sort of surprised zero sized textures don't crash elsewhere (we
should always allocate at least 64 bytes but I wouldn't really trust
texture wrapping code to work later) but this looks good to me. I guess
it could be alternatively more simply written as
(uint64_t)lpr->row_stride[level] * nblocksy > LP_MAX_TEXTURE_SIZE
but either way is fine by me.

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

Re: [Mesa-dev] [PATCH 1/8] softpipe: add depth clamping support.

[Roland Scheidegger]

Am 10.06.2014 07:57, schrieb Dave Airlie:
> From: Dave Airlie 
> 
> This passes the piglit depth clamp tests.
> 
> this is required for GL 3.2.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/drivers/softpipe/sp_quad_depth_test.c | 37 
> ++-
>  src/gallium/drivers/softpipe/sp_screen.c  |  2 +-
>  2 files changed, 31 insertions(+), 8 deletions(-)
> 
> diff --git a/src/gallium/drivers/softpipe/sp_quad_depth_test.c 
> b/src/gallium/drivers/softpipe/sp_quad_depth_test.c
> index f4d7993..2a63fa0 100644
> --- a/src/gallium/drivers/softpipe/sp_quad_depth_test.c
> +++ b/src/gallium/drivers/softpipe/sp_quad_depth_test.c
> @@ -148,10 +148,11 @@ interpolate_quad_depth( struct quad_header *quad )
>   * Compute the depth_data::q[] values from the float fragment Z values.
>   */
>  static void
> -convert_quad_depth( struct depth_data *data, 
> +convert_quad_depth( struct quad_stage *qs, struct depth_data *data, 
>  const struct quad_header *quad )
>  {
> unsigned j;
> +   float dvals[TGSI_QUAD_SIZE];
>  
> /* Convert quad's float depth values to int depth values (q).
>  * If the Z buffer stores integer values, we _have_ to do the depth
> @@ -159,13 +160,31 @@ convert_quad_depth( struct depth_data *data,
>  * conversion of Z values (which isn't an identity function) will cause
>  * Z-fighting errors.
>  */
> +   if (!qs->softpipe->rasterizer->depth_clip) {
> +  float near_val, far_val;
> +  float minval, maxval;
> +
> +  near_val = qs->softpipe->viewport.translate[2] - 
> qs->softpipe->viewport.scale[2];
> +  far_val = near_val + (qs->softpipe->viewport.scale[2] * 2.0);
> +
> +  minval = MIN2(near_val, far_val);
> +  maxval = MAX2(near_val, far_val);
I guess you could precalculate minval/maxval before running the fs. No
biggie though.
(And I'm wondering, though it's only partially related to this code, if
the depth 0/1 clamp is actually happening somewhere. This code here will
clamp to 0/1 if depth clamp is enabled (since the near/far range can't
be outside that), but not if depth clamp is disabled - clipping will
eliminate values outside that, but if depth is written by the fs it
won't of course. GL (but not d3d10) still requires you to clamp depth to
0/1 in this case, and while everybody hates that behavior for float
depth buffers at least if you have non-float depth buffers you need to
do it somewhere otherwise the values outside 0/1 will be random. But
maybe this is done elsewhere.)

> +  for (j = 0; j < TGSI_QUAD_SIZE; j++) {
> + dvals[j] = CLAMP(quad->output.depth[j], minval, maxval);
> +  }
> +   } else {
> +  for (j = 0; j < TGSI_QUAD_SIZE; j++) {
> + dvals[j] = quad->output.depth[j];
> +  }
> +   }
> +
> switch (data->format) {
> case PIPE_FORMAT_Z16_UNORM:
>{
>   float scale = 65535.0;
>  
>   for (j = 0; j < TGSI_QUAD_SIZE; j++) {
> -data->q[j] = (unsigned) (quad->output.depth[j] * scale);
> +data->q[j] = (unsigned) (dvals[j] * scale);
>   }
>}
>break;
> @@ -174,7 +193,7 @@ convert_quad_depth( struct depth_data *data,
>   double scale = (double) (uint) ~0UL;
>  
>   for (j = 0; j < TGSI_QUAD_SIZE; j++) {
> -data->q[j] = (unsigned) (quad->output.depth[j] * scale);
> +data->q[j] = (unsigned) (dvals[j] * scale);
>   }
>}
>break;
> @@ -184,7 +203,7 @@ convert_quad_depth( struct depth_data *data,
>   float scale = (float) ((1 << 24) - 1);
>  
>   for (j = 0; j < TGSI_QUAD_SIZE; j++) {
> -data->q[j] = (unsigned) (quad->output.depth[j] * scale);
> +data->q[j] = (unsigned) (dvals[j] * scale);
>   }
>}
>break;
> @@ -194,7 +213,7 @@ convert_quad_depth( struct depth_data *data,
>   float scale = (float) ((1 << 24) - 1);
>  
>   for (j = 0; j < TGSI_QUAD_SIZE; j++) {
> -data->q[j] = (unsigned) (quad->output.depth[j] * scale);
> +data->q[j] = (unsigned) (dvals[j] * scale);
>   }
>}
>break;
> @@ -204,7 +223,7 @@ convert_quad_depth( struct depth_data *data,
>   union fi fui;
>  
>   for (j = 0; j < TGSI_QUAD_SIZE; j++) {
> -fui.f = quad->output.depth[j];
> +fui.f = dvals[j];
>  data->q[j] = fui.ui;
>   }
>}
> @@ -796,7 +815,7 @@ depth_test_quads_fallback(struct quad_stage *qs,
>  if (interp_depth)
> interpolate_quad_depth(quads[i]);
>  
> -convert_quad_depth(&data, quads[i]);
> +convert_quad_depth(qs, &data, quads[i]);
>   }
>  
>   if (qs->softpipe->depth_stencil->stencil[0].enabled) {
> @@ -895,6 +914,8 @@ choose_depth_test(struct quad_stage *qs,
>  
> boolean occlusion = qs->softpipe->active_query_count;
>  
> +   boolean clipped = qs->softpip

[Mesa-dev] [Bug 79885] New: commit b52a530 (gallium/egl: st_profiles are build time decision, treat them as such) broke egl

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 79885
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: commit b52a530 (gallium/egl: st_profiles are build
time decision, treat them as such) broke egl
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: marvi...@gmx.de
  Hardware: Other
Status: NEW
   Version: git
 Component: EGL
   Product: Mesa

since commit b52a530 I get

# es2_info 
es2_info: es2_info.c:158: make_x_window: Assertion `num_configs > 0' failed.
Aborted

The feature defines look fine, but still something goes wrong.

-- 
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 79885] commit b52a530 (gallium/egl: st_profiles are build time decision, treat them as such) broke egl

[bugzilla-daemon]

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

Marc Dietrich  changed:

   What|Removed |Added

   Hardware|Other   |x86-64 (AMD64)
 OS|All |Linux (All)
 CC||emil.l.veli...@gmail.com

--- Comment #1 from Marc Dietrich  ---
forgot to add this is on r600/amd64 linux

-- 
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] configure: Only check for OpenCL without LLVM when the latter is certain

[Emil Velikov]

On 10/06/14 03:25, Michel Dänzer wrote:
> From: Michel Dänzer 
> 
> LLVM is enabled by default for some architectures, but the test was failing
> before that.
> 
Thanks for fixing my silly mistake Michel. Would you mind CC-ing stable,
similar to the offending commit (93257a56b5b: configure: error out when
building opencl without LLVM) ?

Cc: "10.1 10.2" 
Reviewed-by: Emil Velikov 


> Signed-off-by: Michel Dänzer 
> ---
>  configure.ac | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 7b0009d..0eca945 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1475,10 +1475,6 @@ if test "x$enable_opencl" = xyes; then
>  AC_MSG_ERROR([cannot enable OpenCL without Gallium])
>  fi
>  
> -if test "x$enable_gallium_llvm" != xyes; then
> -AC_MSG_ERROR([cannot enable OpenCL without LLVM])
> -fi
> -
>  if test $GCC_VERSION_MAJOR -lt 4 -o $GCC_VERSION_MAJOR -eq 4 -a 
> $GCC_VERSION_MINOR -lt 7; then
>  AC_MSG_ERROR([gcc >= 4.7 is required to build clover])
>  fi
> @@ -1779,6 +1775,10 @@ if test "x$enable_gallium_llvm" = xyes; then
>  else
>  MESA_LLVM=0
>  LLVM_VERSION_INT=0
> +
> +if test "x$enable_opencl" = xyes; then
> +AC_MSG_ERROR([cannot enable OpenCL without LLVM])
> +fi
>  fi
>  
>  dnl Directory for XVMC libs
> 

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

Re: [Mesa-dev] [PATCH 3/8] softpipe: add layered rendering support.

[Roland Scheidegger]

Am 10.06.2014 07:57, schrieb Dave Airlie:
> From: Dave Airlie 
> 
> This adds support for GL 3.2 layered rendering to softpipe.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/drivers/softpipe/sp_context.h  |  3 ++
>  src/gallium/drivers/softpipe/sp_quad.h |  1 +
>  src/gallium/drivers/softpipe/sp_quad_blend.c   |  8 ++---
>  src/gallium/drivers/softpipe/sp_quad_depth_test.c  |  2 +-
>  .../drivers/softpipe/sp_quad_depth_test_tmp.h  |  2 +-
>  src/gallium/drivers/softpipe/sp_setup.c| 42 
> --
>  src/gallium/drivers/softpipe/sp_state_derived.c|  6 
>  7 files changed, 55 insertions(+), 9 deletions(-)
> 
> diff --git a/src/gallium/drivers/softpipe/sp_context.h 
> b/src/gallium/drivers/softpipe/sp_context.h
> index a56e8a8..aac35f7 100644
> --- a/src/gallium/drivers/softpipe/sp_context.h
> +++ b/src/gallium/drivers/softpipe/sp_context.h
> @@ -121,6 +121,9 @@ struct softpipe_context {
> /** Which vertex shader output slot contains point size */
> int psize_slot;
>  
> +   /** Which vertex shader output slot contains layer */
> +   int layer_slot;
> +
> /** The reduced version of the primitive supplied by the state tracker */
> unsigned reduced_api_prim;
>  
> diff --git a/src/gallium/drivers/softpipe/sp_quad.h 
> b/src/gallium/drivers/softpipe/sp_quad.h
> index 71853d2..b29dad2 100644
> --- a/src/gallium/drivers/softpipe/sp_quad.h
> +++ b/src/gallium/drivers/softpipe/sp_quad.h
> @@ -62,6 +62,7 @@
>  struct quad_header_input
>  {
> int x0, y0;/**< quad window pos, always even */
> +   unsigned layer;
> float coverage[TGSI_QUAD_SIZE]; /**< fragment coverage for antialiasing */
> unsigned facing:1; /**< Front (0) or back (1) facing? */
> unsigned prim:2;   /**< QUAD_PRIM_POINT, LINE, TRI */
> diff --git a/src/gallium/drivers/softpipe/sp_quad_blend.c 
> b/src/gallium/drivers/softpipe/sp_quad_blend.c
> index ae7ecd0..6c52c90 100644
> --- a/src/gallium/drivers/softpipe/sp_quad_blend.c
> +++ b/src/gallium/drivers/softpipe/sp_quad_blend.c
> @@ -935,7 +935,7 @@ blend_fallback(struct quad_stage *qs,
>   struct softpipe_cached_tile *tile
>  = sp_get_cached_tile(softpipe->cbuf_cache[cbuf],
>   quads[0]->input.x0, 
> - quads[0]->input.y0, 0);
> + quads[0]->input.y0, quads[0]->input.layer);
>   const boolean clamp = bqs->clamp[cbuf];
>   const float *blend_color;
>   const boolean dual_source_blend = util_blend_state_is_dual(blend, 
> cbuf);
> @@ -1038,7 +1038,7 @@ blend_single_add_src_alpha_inv_src_alpha(struct 
> quad_stage *qs,
> struct softpipe_cached_tile *tile
>= sp_get_cached_tile(qs->softpipe->cbuf_cache[0],
> quads[0]->input.x0, 
> -   quads[0]->input.y0, 0);
> +   quads[0]->input.y0, quads[0]->input.layer);
>  
> for (q = 0; q < nr; q++) {
>struct quad_header *quad = quads[q];
> @@ -1112,7 +1112,7 @@ blend_single_add_one_one(struct quad_stage *qs,
> struct softpipe_cached_tile *tile
>= sp_get_cached_tile(qs->softpipe->cbuf_cache[0],
> quads[0]->input.x0, 
> -   quads[0]->input.y0, 0);
> +   quads[0]->input.y0, quads[0]->input.layer);
>  
> for (q = 0; q < nr; q++) {
>struct quad_header *quad = quads[q];
> @@ -1180,7 +1180,7 @@ single_output_color(struct quad_stage *qs,
> struct softpipe_cached_tile *tile
>= sp_get_cached_tile(qs->softpipe->cbuf_cache[0],
> quads[0]->input.x0, 
> -   quads[0]->input.y0, 0);
> +   quads[0]->input.y0, quads[0]->input.layer);
>  
> for (q = 0; q < nr; q++) {
>struct quad_header *quad = quads[q];
> diff --git a/src/gallium/drivers/softpipe/sp_quad_depth_test.c 
> b/src/gallium/drivers/softpipe/sp_quad_depth_test.c
> index d758521..12d2d11 100644
> --- a/src/gallium/drivers/softpipe/sp_quad_depth_test.c
> +++ b/src/gallium/drivers/softpipe/sp_quad_depth_test.c
> @@ -806,7 +806,7 @@ depth_test_quads_fallback(struct quad_stage *qs,
>data.format = data.ps->format;
>data.tile = sp_get_cached_tile(qs->softpipe->zsbuf_cache, 
>   quads[0]->input.x0, 
> - quads[0]->input.y0, 0);
> + quads[0]->input.y0, 
> quads[0]->input.layer);
>  
>for (i = 0; i < nr; i++) {
>   get_depth_stencil_values(&data, quads[i]);
> diff --git a/src/gallium/drivers/softpipe/sp_quad_depth_test_tmp.h 
> b/src/gallium/drivers/softpipe/sp_quad_depth_test_tmp.h
> index e7b70f7..7128bf8 100644
> --- a/src/gallium/drivers/softpipe/sp_quad_depth_test_tmp.h
> +++ b/src/gallium/drivers/softpipe/sp_quad_depth_test_tmp.h
> @@

Re: [Mesa-dev] [PATCH 4/8] draw/gs: fix segfault in glsl-1.50-gs-mismatch-prim-type triangles_adjacency

[Roland Scheidegger]

Am 10.06.2014 07:57, schrieb Dave Airlie:
> From: Dave Airlie 
> 
> This crashes on softpipe due to a lack of output memory allocated,
> 
> it appears we allocate memory for enough primtives, but not vertices
> so convert to number of vertices.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/auxiliary/draw/draw_gs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/auxiliary/draw/draw_gs.c 
> b/src/gallium/auxiliary/draw/draw_gs.c
> index fc4f697..0a9bf81 100644
> --- a/src/gallium/auxiliary/draw/draw_gs.c
> +++ b/src/gallium/auxiliary/draw/draw_gs.c
> @@ -555,7 +555,7 @@ int draw_geometry_shader_run(struct draw_geometry_shader 
> *shader,
> /* we allocate exactly one extra vertex per primitive to allow the GS to 
> emit
>  * overflown vertices into some area where they won't harm anyone */
> unsigned total_verts_per_buffer = shader->primitive_boundary *
> -  num_in_primitives;
> +  max_out_prims * u_vertices_per_prim(shader->output_primitive);
>  
> //Assume at least one primitive
> max_out_prims = MAX2(max_out_prims, 1);
> 

Zack would probably know better but looks alright to me.

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

Re: [Mesa-dev] [PATCH 8/8] softpipe: enable AMD_vertex_shader_layer.

[Roland Scheidegger]

Am 10.06.2014 07:57, schrieb Dave Airlie:
> From: Dave Airlie 
> 
> This passes tests now on softpipe.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/drivers/softpipe/sp_screen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/softpipe/sp_screen.c 
> b/src/gallium/drivers/softpipe/sp_screen.c
> index d22ee27..d82fed9 100644
> --- a/src/gallium/drivers/softpipe/sp_screen.c
> +++ b/src/gallium/drivers/softpipe/sp_screen.c
> @@ -156,6 +156,7 @@ softpipe_get_param(struct pipe_screen *screen, enum 
> pipe_cap param)
> case PIPE_CAP_USER_INDEX_BUFFERS:
> case PIPE_CAP_USER_CONSTANT_BUFFERS:
> case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
> +   case PIPE_CAP_TGSI_VS_LAYER:
>return 1;
> case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
>return 16;
> @@ -184,7 +185,6 @@ softpipe_get_param(struct pipe_screen *screen, enum 
> pipe_cap param)
>return 1;
> case PIPE_CAP_ENDIANNESS:
>return PIPE_ENDIAN_NATIVE;
> -   case PIPE_CAP_TGSI_VS_LAYER:
> case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
> case PIPE_CAP_TEXTURE_GATHER_SM5:
> case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> 

5-8 are
Reviewed-by: Roland Scheidegger 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/8] draw/gs: fix segfault in glsl-1.50-gs-mismatch-prim-type triangles_adjacency

[Zack Rusin]

That looks wrong.  The total number of verts per buffer is the maximum number 
of verts that can be output per invocation (primitive_boundary) times number of 
invocations of geometry shader (num_in_primitives).

It's not maximum number of verts that can be output per invocation 
(primitive_boundary) times maximum number of primitives output by geometry 
shader (max_out_prims).

z

- Original Message -
> From: Dave Airlie 
> 
> This crashes on softpipe due to a lack of output memory allocated,
> 
> it appears we allocate memory for enough primtives, but not vertices
> so convert to number of vertices.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/auxiliary/draw/draw_gs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/auxiliary/draw/draw_gs.c
> b/src/gallium/auxiliary/draw/draw_gs.c
> index fc4f697..0a9bf81 100644
> --- a/src/gallium/auxiliary/draw/draw_gs.c
> +++ b/src/gallium/auxiliary/draw/draw_gs.c
> @@ -555,7 +555,7 @@ int draw_geometry_shader_run(struct draw_geometry_shader
> *shader,
> /* we allocate exactly one extra vertex per primitive to allow the GS to
> emit
>  * overflown vertices into some area where they won't harm anyone */
> unsigned total_verts_per_buffer = shader->primitive_boundary *
> -  num_in_primitives;
> +  max_out_prims * u_vertices_per_prim(shader->output_primitive);
>  
> //Assume at least one primitive
> max_out_prims = MAX2(max_out_prims, 1);
> --
> 1.9.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] softpipe: add depth clamping support.

[Brian Paul]

On 06/09/2014 06:58 PM, Dave Airlie wrote:

From: Dave Airlie 

This passes the piglit depth clamp tests.

this is required for GL 3.2.

Signed-off-by: Dave Airlie 
---
  src/gallium/drivers/softpipe/sp_quad_depth_test.c | 37 ++-
  src/gallium/drivers/softpipe/sp_screen.c  |  2 +-
  2 files changed, 31 insertions(+), 8 deletions(-)




Reviewed-by: Brian Paul 

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

[Mesa-dev] [PATCH] egl/gallium: Set defines for supported APIs when using automake

[Niels Ole Salscheider]

This fixes automake builds which are broken since
b52a530ce2aada1967bc8fefa83ab53e6a737dae.

Signed-off-by: Niels Ole Salscheider 
---
 src/gallium/state_trackers/egl/Makefile.am | 20 
 1 file changed, 20 insertions(+)

diff --git a/src/gallium/state_trackers/egl/Makefile.am 
b/src/gallium/state_trackers/egl/Makefile.am
index b7dcdab..828bf13 100644
--- a/src/gallium/state_trackers/egl/Makefile.am
+++ b/src/gallium/state_trackers/egl/Makefile.am
@@ -88,3 +88,23 @@ AM_CPPFLAGS += \
-I$(top_srcdir)/src/gallium/winsys/sw \
-DHAVE_NULL_BACKEND
 endif
+
+if HAVE_OPENGL
+AM_CPPFLAGS += \
+   -DFEATURE_GL=1
+endif
+
+if HAVE_OPENGL_ES1
+AM_CPPFLAGS += \
+   -DFEATURE_ES1=1
+endif
+
+if HAVE_OPENGL_ES2
+AM_CPPFLAGS += \
+   -DFEATURE_ES2=1
+endif
+
+if HAVE_OPENVG
+AM_CPPFLAGS += \
+   -DFEATURE_VG=1
+endif
-- 
2.0.0

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

[Mesa-dev] [Bug 79885] commit b52a530 (gallium/egl: st_profiles are build time decision, treat them as such) broke egl

[bugzilla-daemon]

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

--- Comment #2 from Emil Velikov  ---
This seems rather odd. I'm assuming that you've tried the parent commit and it
works fine ? Are you building with scons by any change ?

Set the variable EGL_LOG_LEVEL=debug and attach the output of the program.

-- 
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 79885] commit b52a530 (gallium/egl: st_profiles are build time decision, treat them as such) broke egl

[bugzilla-daemon]

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

--- Comment #3 from Niels Ole Salscheider  ---
I have just sent a patch ("egl/gallium: Set defines for supported APIs when
using automake") to the list which should fix your problem, too.

-- 
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 mesa] add EGL_TEXTURE_EXTERNAL_WL to WL_bind_wayland_display spec

[Rob Clark]

On Mon, Jun 9, 2014 at 5:53 AM, Pekka Paalanen  wrote:
> On Thu, 16 Aug 2012 17:28:19 -0500
> Rob Clark  wrote:
>
>> From: Rob Clark 
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  docs/WL_bind_wayland_display.spec |5 +
>>  include/EGL/eglmesaext.h  |1 +
>>  2 files changed, 6 insertions(+)
>>
>> diff --git a/docs/WL_bind_wayland_display.spec 
>> b/docs/WL_bind_wayland_display.spec
>> index 02bd6ea..ce52e2d 100644
>> --- a/docs/WL_bind_wayland_display.spec
>> +++ b/docs/WL_bind_wayland_display.spec
>> @@ -75,6 +75,7 @@ New Tokens
>>  EGL_TEXTURE_Y_U_V_WL0x31D7
>>  EGL_TEXTURE_Y_UV_WL 0x31D8
>>  EGL_TEXTURE_Y_XUXV_WL   0x31D9
>> +EGL_TEXTURE_EXTERNAL_WL 0x31DA
>>
>>
>>  Additions to the EGL 1.4 Specification:
>> @@ -143,6 +144,10 @@ Additions to the EGL 1.4 Specification:
>>  Two planes, samples Y from the first plane to r in
>>  the shader, U and V from the second plane to g and a.
>>
>> +EGL_TEXTURE_EXTERNAL_WL
>> +Treated as a single plane texture, but sampled with
>> +samplerExternalOES according to OES_EGL_image_external
>> +
>>  After querying the wl_buffer layout, create EGLImages for the
>>  planes by calling eglCreateImageKHR with wl_buffer as
>>  EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target, NULL
>> diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h
>> index d476d18..2b91897 100644
>> --- a/include/EGL/eglmesaext.h
>> +++ b/include/EGL/eglmesaext.h
>> @@ -118,6 +118,7 @@ typedef EGLDisplay (EGLAPIENTRYP 
>> PFNEGLGETDRMDISPLAYMESA) (int fd);
>>  #define EGL_TEXTURE_Y_U_V_WL0x31D7
>>  #define EGL_TEXTURE_Y_UV_WL 0x31D8
>>  #define EGL_TEXTURE_Y_XUXV_WL   0x31D9
>> +#define EGL_TEXTURE_EXTERNAL_WL 0x31DA
>>
>>  struct wl_display;
>>  struct wl_buffer;
>
> Hi all,
>
> it looks like this patch never made it into Mesa. Also the
> implementation apparently didn't make it into Mesa, as git pick-axe
> does not find any mention of EGL_TEXTURE_EXTERNAL_WL.
>
> Still, the Weston patch was merged on Aug 31st, 2012.
>
> Oops. :-)

heh, well I guess if weston is already using it, perhaps we should
think about merging the mesa patch ;-)

BR,
-R

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

[Mesa-dev] [Bug 79885] commit b52a530 (gallium/egl: st_profiles are build time decision, treat them as such) broke egl

[bugzilla-daemon]

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

--- Comment #4 from Marc Dietrich  ---
Patch from Niels fixed it.

Thanks!

-- 
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] configure: Only check for OpenCL without LLVM when the latter is certain

[Tom Stellard]

On Tue, Jun 10, 2014 at 02:57:41PM +0100, Emil Velikov wrote:
> On 10/06/14 03:25, Michel Dänzer wrote:
> > From: Michel Dänzer 
> > 
> > LLVM is enabled by default for some architectures, but the test was failing
> > before that.
> > 
> Thanks for fixing my silly mistake Michel. Would you mind CC-ing stable,
> similar to the offending commit (93257a56b5b: configure: error out when
> building opencl without LLVM) ?
> 
> Cc: "10.1 10.2" 
> Reviewed-by: Emil Velikov 
> 

I've pushed this patch and cc'd stable.

-Tom

> 
> > Signed-off-by: Michel Dänzer 
> > ---
> >  configure.ac | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/configure.ac b/configure.ac
> > index 7b0009d..0eca945 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -1475,10 +1475,6 @@ if test "x$enable_opencl" = xyes; then
> >  AC_MSG_ERROR([cannot enable OpenCL without Gallium])
> >  fi
> >  
> > -if test "x$enable_gallium_llvm" != xyes; then
> > -AC_MSG_ERROR([cannot enable OpenCL without LLVM])
> > -fi
> > -
> >  if test $GCC_VERSION_MAJOR -lt 4 -o $GCC_VERSION_MAJOR -eq 4 -a 
> > $GCC_VERSION_MINOR -lt 7; then
> >  AC_MSG_ERROR([gcc >= 4.7 is required to build clover])
> >  fi
> > @@ -1779,6 +1775,10 @@ if test "x$enable_gallium_llvm" = xyes; then
> >  else
> >  MESA_LLVM=0
> >  LLVM_VERSION_INT=0
> > +
> > +if test "x$enable_opencl" = xyes; then
> > +AC_MSG_ERROR([cannot enable OpenCL without LLVM])
> > +fi
> >  fi
> >  
> >  dnl Directory for XVMC libs
> > 
> 
> ___
> 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] egl/gallium: Set defines for supported APIs when using automake

[Emil Velikov]

On 10/06/14 15:17, Niels Ole Salscheider wrote:
> This fixes automake builds which are broken since
> b52a530ce2aada1967bc8fefa83ab53e6a737dae.
> 
Not sure what I was smoking with the above mentioned patch.
Seem like I've completely forgotten about automake :\

Niels can you please drop the FEATURE* defines from
src/gallium/targets/egl-static/Makefile.am

With that fixed

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79885
Reviewed-by: Emil Velikov 

Thanks
Emil

> Signed-off-by: Niels Ole Salscheider 
> ---
>  src/gallium/state_trackers/egl/Makefile.am | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/src/gallium/state_trackers/egl/Makefile.am 
> b/src/gallium/state_trackers/egl/Makefile.am
> index b7dcdab..828bf13 100644
> --- a/src/gallium/state_trackers/egl/Makefile.am
> +++ b/src/gallium/state_trackers/egl/Makefile.am
> @@ -88,3 +88,23 @@ AM_CPPFLAGS += \
>   -I$(top_srcdir)/src/gallium/winsys/sw \
>   -DHAVE_NULL_BACKEND
>  endif
> +
> +if HAVE_OPENGL
> +AM_CPPFLAGS += \
> + -DFEATURE_GL=1
> +endif
> +
> +if HAVE_OPENGL_ES1
> +AM_CPPFLAGS += \
> + -DFEATURE_ES1=1
> +endif
> +
> +if HAVE_OPENGL_ES2
> +AM_CPPFLAGS += \
> + -DFEATURE_ES2=1
> +endif
> +
> +if HAVE_OPENVG
> +AM_CPPFLAGS += \
> + -DFEATURE_VG=1
> +endif
> 

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

[Mesa-dev] [Bug 79885] commit b52a530 (gallium/egl: st_profiles are build time decision, treat them as such) broke egl

[bugzilla-daemon]

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

--- Comment #5 from Emil Velikov  ---
Above I mentioned scons, yet completely missed out on our main build system -
automake.
Niels patch is the correct solution but I would appreciate if he can remove the
feature defines from the target as well.

-- 
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] egl/gallium: Set defines for supported APIs when using automake

[Niels Ole Salscheider]

On Tuesday 10 June 2014, 16:18:56, Emil Velikov wrote:
> On 10/06/14 15:17, Niels Ole Salscheider wrote:
> > This fixes automake builds which are broken since
> > b52a530ce2aada1967bc8fefa83ab53e6a737dae.
> 
> Not sure what I was smoking with the above mentioned patch.
> Seem like I've completely forgotten about automake :\
> 
> Niels can you please drop the FEATURE* defines from
> src/gallium/targets/egl-static/Makefile.am

I think they are still necessary since src/gallium/targets/egl-static/egl_st.c 
contains these flags, too... Or am I missing something?
I have seen that you removed them in b52a530ce2aada1967bc8fefa83ab53e6a737dae 
for the other build systems...
 
> With that fixed
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79885
> Reviewed-by: Emil Velikov 
> 
> Thanks
> Emil
> 
> > Signed-off-by: Niels Ole Salscheider 
> > ---
> > 
> >  src/gallium/state_trackers/egl/Makefile.am | 20 
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/src/gallium/state_trackers/egl/Makefile.am
> > b/src/gallium/state_trackers/egl/Makefile.am index b7dcdab..828bf13
> > 100644
> > --- a/src/gallium/state_trackers/egl/Makefile.am
> > +++ b/src/gallium/state_trackers/egl/Makefile.am
> > @@ -88,3 +88,23 @@ AM_CPPFLAGS += \
> > 
> > -I$(top_srcdir)/src/gallium/winsys/sw \
> > -DHAVE_NULL_BACKEND
> >  
> >  endif
> > 
> > +
> > +if HAVE_OPENGL
> > +AM_CPPFLAGS += \
> > +   -DFEATURE_GL=1
> > +endif
> > +
> > +if HAVE_OPENGL_ES1
> > +AM_CPPFLAGS += \
> > +   -DFEATURE_ES1=1
> > +endif
> > +
> > +if HAVE_OPENGL_ES2
> > +AM_CPPFLAGS += \
> > +   -DFEATURE_ES2=1
> > +endif
> > +
> > +if HAVE_OPENVG
> > +AM_CPPFLAGS += \
> > +   -DFEATURE_VG=1
> > +endif

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

Re: [Mesa-dev] [PATCH 1/2] glinfo_common: fix extension_supported() function

[Ian Romanick]

On 06/09/2014 05:26 AM, Brian Paul wrote:
> The code did not correctly handle super-string handling.  For example,
> if we were searching for "WGL_ARB_pixel_format" but we found
> "WGL_ARB_pixel_format_float" we'd stop searching and return 0.  Now
> we search past that initial, incorrect match.

This patch is

Reviewed-by: Ian Romanick 

> ---
>  src/xdemos/glinfo_common.c |   22 --
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
> index e6517d7..e7ef508 100644
> --- a/src/xdemos/glinfo_common.c
> +++ b/src/xdemos/glinfo_common.c
> @@ -306,12 +306,22 @@ build_core_profile_extension_list(const struct 
> ext_functions *extfuncs)
>  GLboolean
>  extension_supported(const char *ext, const char *extensionsList)
>  {
> -   const char *p = strstr(extensionsList, ext);
> -   if (p) {
> -  /* check that next char is a space or end of string */
> -  int extLen = strlen(ext);
> -  if (p[extLen] == 0 || p[extLen] == ' ')
> - return 1;
> +   while (1) {
> +  const char *p = strstr(extensionsList, ext);
> +  if (p) {
> + /* check that next char is a space or end of string */
> + int extLen = strlen(ext);
> + if (p[extLen] == 0 || p[extLen] == ' ') {
> +return 1;
> + }
> + else {
> +/* We found a superset string, keep looking */
> +extensionsList += extLen;
> + }
> +  }
> +  else {
> + break;
> +  }
> }
> return 0;
>  }
> 

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

Re: [Mesa-dev] [PATCH 1/3] glsl: Rebalance expression trees that are reduction operations.

[Ian Romanick]

On 06/09/2014 02:11 PM, Matt Turner wrote:
> +/* Note that this function does not attempt to recognize that reduction trees
> + * are already balanced.
> + */
> +static void
> +is_reduction(ir_instruction *ir, void *data)
> +{
> +   struct is_reduction_data *ird = (struct is_reduction_data *)data;
> +   if (!ird->is_reduction)
> +  return;
> +
> +   /* We don't want to balance a tree that contains multiple constants, since
> +* we'll be able to constant fold them if they're not in separate 
> subtrees.
> +*/
> +   if (ir->as_constant()) {
> +  if (ird->contains_constant) {
> + ird->is_reduction = false;
> +  }

Because of the way visit_tree works, I think this would produce a
false-positive for an expression like foo[2] + 3.  Eventually
is_reduction will get called for both the 2 and the 3.

> +  ird->contains_constant = true;
> +  return;
> +   }
> +
> +   ir_expression *expr = ir->as_expression();
> +   if (!expr)
> +  return;
> +
> +   /* Non-constant matrices might still contain constant vec4 that we can
> +* constant fold once split up. Handling matrices will need some more
> +* work.
> +*/
> +   if (expr->type->is_matrix()) {
> +  ird->is_reduction = false;
> +  return;
> +   }
> +
> +   if (ird->type != NULL && ird->type != expr->type) {
> +  ird->is_reduction = false;
> +  return;
> +   }
> +   ird->type = expr->type;
> +
> +   ird->num_expr++;
> +   if (is_reduction_operation(expr->operation)) {

This (and, actually, the type check above might get tricked by
expressions like a+foo[b%c]+d+e.

I think you might need something like visit_tree that just doesn't try
to navigate past any sort of ir_dereference (or a version that allows
the predicate function to halt navigation of subtrees).

> +  if (ird->operation != 0 && ird->operation != expr->operation)
> + ird->is_reduction = false;
> +  ird->operation = expr->operation;
> +   } else {
> +  ird->is_reduction = false;
> +   }
> +}

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

Re: [Mesa-dev] [PATCH 3/3] glsl: Optimize (v.x + v.y) + (v.z + v.w) into dot(v, 1.0).

[Ian Romanick]

On 06/09/2014 02:11 PM, Matt Turner wrote:
> Cuts five instructions out of SynMark's Gl32VSInstancing benchmark.
> ---
>  src/glsl/opt_algebraic.cpp | 46 
> ++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
> index d57c3e8..be65799 100644
> --- a/src/glsl/opt_algebraic.cpp
> +++ b/src/glsl/opt_algebraic.cpp
> @@ -119,6 +119,44 @@ update_type(ir_expression *ir)
>ir->type = ir->operands[1]->type;
>  }
>  
> +/* Recognize (v.x + v.y) + (v.z + v.w) as dot(v, 1.0) */
> +static ir_expression *
> +try_replace_with_dot(ir_expression *expr0, ir_expression *expr1, void 
> *mem_ctx)
> +{
> +   if (expr0 && expr0->operation == ir_binop_add &&
> +   expr1 && expr1->operation == ir_binop_add) {
> +  ir_swizzle *x = expr0->operands[0]->as_swizzle();
> +  ir_swizzle *y = expr0->operands[1]->as_swizzle();
> +  ir_swizzle *z = expr1->operands[0]->as_swizzle();
> +  ir_swizzle *w = expr1->operands[1]->as_swizzle();
> +
> +  if (!x || x->mask.num_components != 1 || x->mask.has_duplicates ||
> +  !y || y->mask.num_components != 1 || y->mask.has_duplicates ||
> +  !z || z->mask.num_components != 1 || z->mask.has_duplicates ||
> +  !w || w->mask.num_components != 1 || w->mask.has_duplicates) {

Are the has_duplicates checks necessary?  If num_components must be 1,
it's not obvious to me what the extra checks are doing.

> + return NULL;
> +  }
> +
> +  bool swiz_seen[4] = {false, false, false, false};
> +  swiz_seen[x->mask.x] = true;
> +  swiz_seen[y->mask.x] = true;
> +  swiz_seen[z->mask.x] = true;
> +  swiz_seen[w->mask.x] = true;
> +
> +  if (!swiz_seen[0] || !swiz_seen[1] ||
> +  !swiz_seen[2] || !swiz_seen[3]) {
> + return NULL;
> +  }
> +
> +  if (x->val->equals(y->val) &&
> +  x->val->equals(z->val) &&
> +  x->val->equals(w->val)) {
> + return dot(x->val, new(mem_ctx) ir_constant(1.0f, 4));
> +  }
> +   }
> +   return NULL;
> +}
> +
>  void
>  ir_algebraic_visitor::reassociate_operands(ir_expression *ir1,
>  int op1,
> @@ -332,6 +370,14 @@ ir_algebraic_visitor::handle_expression(ir_expression 
> *ir)
>if (op_const[1] && !op_const[0])
>reassociate_constant(ir, 1, op_const[1], op_expr[0]);
>  
> +  /* Recognize (v.x + v.y) + (v.z + v.w) as dot(v, 1.0) */
> +  if (options->OptimizeForAOS) {
> + ir_expression *expr = try_replace_with_dot(op_expr[0], op_expr[1],
> +mem_ctx);
> + if (expr)
> +return expr;
> +  }
> +
>/* Replace (-x + y) * a + x and commutative variations with lrp(x, y, 
> a).
> *
> * (-x + y) * a + x
> 

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

Re: [Mesa-dev] [PATCH] mesa: Fix substitution of large shaders

[Courtney Goeltzenleuchter]

Hi Brian,

I think I've pushed this patch. Could you verify that I haven't broken
anything?

Thanks!
Courtney


On Fri, Jun 6, 2014 at 7:20 PM, Brian Paul  wrote:

>
> Reviewed-by: Brian Paul 
>
> Do you need someone to commit/push this for you?
>
> -Brian
>
>
> On 06/06/2014 12:04 PM, Cody Northrop wrote:
>
>> Whoops, yes, you're right.  ftell() of SEEK_END and strlen() are
>> returning the same value, which does not include the terminating zero.
>> Updated patch below.
>>
>> We use this quite a bit, much faster than editing large apitrace files
>>
>> Thanks,
>>
>> -C
>>
>>
>> Signed-off-by: Cody Northrop mailto:c...@lunarg.com>>
>>
>> ---
>>   src/mesa/main/shaderapi.c | 17 ++---
>>   1 file changed, 14 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
>> index 6f84acd..4048ddf 100644
>> --- a/src/mesa/main/shaderapi.c
>> +++ b/src/mesa/main/shaderapi.c
>> @@ -1392,7 +1392,7 @@ _mesa_LinkProgram(GLhandleARB programObj)
>>   static GLcharARB *
>>   read_shader(const char *fname)
>>   {
>> -   const int max = 50*1000;
>> +   int shader_size = 0;
>>  FILE *f = fopen(fname, "r");
>>  GLcharARB *buffer, *shader;
>>  int len;
>> @@ -1401,8 +1401,19 @@ read_shader(const char *fname)
>> return NULL;
>>  }
>>
>> -   buffer = malloc(max);
>> -   len = fread(buffer, 1, max, f);
>> +   /* allocate enough room for the entire shader */
>> +   fseek(f, 0, SEEK_END);
>> +   shader_size = ftell(f);
>> +   rewind(f);
>> +   assert(shader_size);
>> +
>> +   /* add one for terminating zero */
>> +   shader_size++;
>> +
>> +   buffer = malloc(shader_size);
>> +   assert(buffer);
>> +
>> +   len = fread(buffer, 1, shader_size, f);
>>  buffer[len] = 0;
>>
>>  fclose(f);
>> --
>> 1.8.3.2
>>
>>
>>
>>
>>
>>
>> On Thu, Jun 5, 2014 at 7:13 PM, Brian Paul > > wrote:
>>
>> On 06/05/2014 10:47 AM, Cody Northrop wrote:
>>
>> The fixed size is insufficient for shaders I'm debugging.
>>   Rather than
>> just bump it up, make it dynamic.
>>
>> Thanks,
>>
>> -C
>>
>> Signed-off-by: Cody Northrop >  >
>> >>
>>
>> ---
>>src/mesa/main/shaderapi.c | 14 +++---
>>1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
>> index 6f84acd..e63c124 100644
>> --- a/src/mesa/main/shaderapi.c
>> +++ b/src/mesa/main/shaderapi.c
>> @@ -1392,7 +1392,7 @@ _mesa_LinkProgram(GLhandleARB programObj)
>>static GLcharARB *
>>read_shader(const char *fname)
>>{
>> -   const int max = 50*1000;
>> +   int shader_size = 0;
>>   FILE *f = fopen(fname, "r");
>>   GLcharARB *buffer, *shader;
>>   int len;
>> @@ -1401,8 +1401,16 @@ read_shader(const char *fname)
>>  return NULL;
>>   }
>>
>> -   buffer = malloc(max);
>> -   len = fread(buffer, 1, max, f);
>> +   /* allocate enough room for the entire shader */
>> +   fseek(f, 0, SEEK_END);
>> +   shader_size = ftell(f);
>> +   rewind(f);
>> +   assert(shader_size);
>> +
>> +   buffer = malloc(shader_size);
>>
>>
>> Do you have to add one for the terminating zero?
>>
>>
>>
>> +   assert(buffer);
>> +
>> +   len = fread(buffer, 1, shader_size, f);
>>   buffer[len] = 0;
>>
>>   fclose(f);
>> --
>>
>>
>> I thought I was the only person who ever used this code!
>>
>> Other than the one question above this looks alright.
>>
>> Reviewed-by: Brian Paul mailto:bri...@vmware.com
>> >>
>>
>> _
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org > >
>> http://lists.freedesktop.org/__mailman/listinfo/mesa-dev
>> > /lists.freedesktop.org/mailman/listinfo/mesa-dev&k=
>> oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%
>> 2BTLs8wadB%2BiIj9xpBY%3D%0A&m=BQB5tezP6JJarG3K6deQKB%2FgjK%
>> 2FGhKQvd8LRF8usgCs%3D%0A&s=6d587c1f9718375e59390ea001cad3
>> ee836a3597c86c77596f02292c818b3051>
>>
>>
>>
>>
>>
>> --
>>   Cody Northrop
>>   Graphics Software Engineer
>>   LunarG, Inc.- 3D Driver Innovations
>>   Email: c...@lunarg.com 
>>   Website: http://www.lunarg.com
>> > /www.lunarg.com/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=
>> lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=
>> BQB5tezP6JJarG3K6deQKB%2FgjK%2FGhKQvd8LRF8usgCs%3D%0A&s=
>> e4c25bb2e76d3a5cbff56061766e2be646a3106ae813979beea26ede2680e7ec>
>>
>
> ___

Re: [Mesa-dev] [PATCH] meta: save and restore swizzle for _GenerateMipmap

[Ian Romanick]

On 06/09/2014 07:48 AM, Robert Bragg wrote:
> This makes sure to use a no-op swizzle while iteratively rendering each
> level of a mipmap otherwise we may loose components and effectively
> apply the swizzle twice by the time these levels are sampled.

Right... the swizzle state shouldn't affect mipmap generation at all.
One minor nit below, but otherwise

Reviewed-by: Ian Romanick 

I second Chris's request for a piglit test.  It should be pretty easy to
clone one of the existing tests/fbo/fbo-generatemipmap-*.c tests and
modify it to test this case.

> ---
>  src/mesa/drivers/common/meta_generate_mipmap.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/src/mesa/drivers/common/meta_generate_mipmap.c 
> b/src/mesa/drivers/common/meta_generate_mipmap.c
> index d12806c..4b1718d 100644
> --- a/src/mesa/drivers/common/meta_generate_mipmap.c
> +++ b/src/mesa/drivers/common/meta_generate_mipmap.c
> @@ -43,6 +43,7 @@
>  #include "main/varray.h"
>  #include "main/viewport.h"
>  #include "drivers/common/meta.h"
> +#include "program/prog_instruction.h"
>  
>  
>  /**
> @@ -168,6 +169,8 @@ _mesa_meta_GenerateMipmap(struct gl_context *ctx, GLenum 
> target,
> GLenum faceTarget;
> GLuint dstLevel;
> GLuint samplerSave;
> +   GLint swizzle[4];
> +   GLboolean swizzleSaved = GL_FALSE;
>  
> if (fallback_required(ctx, target, texObj)) {
>_mesa_generate_mipmap(ctx, target, texObj);
> @@ -231,6 +234,13 @@ _mesa_meta_GenerateMipmap(struct gl_context *ctx, GLenum 
> target,
>  
> _mesa_TexParameteri(target, GL_GENERATE_MIPMAP, GL_FALSE);
>  
> +   if (texObj->_Swizzle != SWIZZLE_NOOP) {
> +  static const GLint swizzleNoop[4] = { GL_RED, GL_GREEN, GL_BLUE, 
> GL_ALPHA };
> +  memcpy(swizzle, texObj->Swizzle, sizeof(swizzle));
> +  swizzleSaved = GL_TRUE;
> +  _mesa_TexParameteriv(target, GL_TEXTURE_SWIZZLE_RGBA, swizzleNoop);
> +   }
> +
> /* Silence valgrind warnings about reading uninitialized stack. */
> memset(verts, 0, sizeof(verts));
>  
> @@ -347,4 +357,6 @@ _mesa_meta_GenerateMipmap(struct gl_context *ctx, GLenum 
> target,
> _mesa_TexParameteri(target, GL_TEXTURE_MAX_LEVEL, maxLevelSave);
> if (genMipmapSave)
>_mesa_TexParameteri(target, GL_GENERATE_MIPMAP, genMipmapSave);
> +   if (swizzleSaved)
> +  _mesa_TexParameteriv(target, GL_TEXTURE_SWIZZLE_RGBA, swizzle);
>  }
> 

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

Re: [Mesa-dev] [PATCH 3/3] glsl: Optimize (v.x + v.y) + (v.z + v.w) into dot(v, 1.0).

[Matt Turner]

On Tue, Jun 10, 2014 at 9:46 AM, Ian Romanick  wrote:
> On 06/09/2014 02:11 PM, Matt Turner wrote:
>> Cuts five instructions out of SynMark's Gl32VSInstancing benchmark.
>> ---
>>  src/glsl/opt_algebraic.cpp | 46 
>> ++
>>  1 file changed, 46 insertions(+)
>>
>> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
>> index d57c3e8..be65799 100644
>> --- a/src/glsl/opt_algebraic.cpp
>> +++ b/src/glsl/opt_algebraic.cpp
>> @@ -119,6 +119,44 @@ update_type(ir_expression *ir)
>>ir->type = ir->operands[1]->type;
>>  }
>>
>> +/* Recognize (v.x + v.y) + (v.z + v.w) as dot(v, 1.0) */
>> +static ir_expression *
>> +try_replace_with_dot(ir_expression *expr0, ir_expression *expr1, void 
>> *mem_ctx)
>> +{
>> +   if (expr0 && expr0->operation == ir_binop_add &&
>> +   expr1 && expr1->operation == ir_binop_add) {
>> +  ir_swizzle *x = expr0->operands[0]->as_swizzle();
>> +  ir_swizzle *y = expr0->operands[1]->as_swizzle();
>> +  ir_swizzle *z = expr1->operands[0]->as_swizzle();
>> +  ir_swizzle *w = expr1->operands[1]->as_swizzle();
>> +
>> +  if (!x || x->mask.num_components != 1 || x->mask.has_duplicates ||
>> +  !y || y->mask.num_components != 1 || y->mask.has_duplicates ||
>> +  !z || z->mask.num_components != 1 || z->mask.has_duplicates ||
>> +  !w || w->mask.num_components != 1 || w->mask.has_duplicates) {
>
> Are the has_duplicates checks necessary?  If num_components must be 1,
> it's not obvious to me what the extra checks are doing.

Right.. I don't think so. I'll remove them.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: glx: Reduce error log level

[Courtney Goeltzenleuchter]

The code that parses LIBGL_DRIVERS_PATH was printing an
error for every attempted dlopen. It's not an error to
have to check multiple items in the path, only an error if
no suitable library is found. Reduced the load error to
a warning to match behavior of dynamic linker.

Signed-off-by: Courtney Goeltzenleuchter 
---
 src/glx/dri_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index 8bf4705..63c8de3 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -140,7 +140,7 @@ driOpenDriver(const char *driverName)
   if (handle != NULL)
  break;
   else
- ErrorMessageF("dlopen %s failed (%s)\n", realDriverName, dlerror());
+ InfoMessageF("dlopen %s failed (%s)\n", realDriverName, dlerror());
}
 
if (!handle)
-- 
1.8.3.2

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

Re: [Mesa-dev] [PATCH 00/11] glsl: Remove unused includes found with IWYU

[Tom Stellard]

On Tue, Jun 10, 2014 at 12:57:31AM +0200, thomashellan...@gmail.com wrote:
> From: Thomas Helland 
> 

For the series:

Reviewed-by: Tom Stellard 

Do these patches make any measurable improvement in compile time?

-Tom
> This series removes some unused includes in the glsl-directory.
> These were found with Google's include-what-you-use plugin for clang.
> Patches have been compile-tested and a quick glxgears-run has been done.
> I have not done a full piglit-run, let me know if that's wanted.
> 
> Oh, and excuse me if I've messed up something.
> First run with git and mailing-lists, so lots to learn.
> 
> Thomas Helland (11):
>   glsl: Remove unused includes in link_uniform_init.
>   glsl: Remove unused includes in link_uniform_block_active_visitor.h
>   glsl: Remove unused include in ast_to_hir.cpp
>   glsl: Remove unused include from builtin_variables.cpp
>   glsl: Remove unused include from glsl_types.cpp
>   glsl: Remove unused include from glsl_symbol_table.h
>   glsl: Remove unused include from hir_field_selection.cpp
>   glsl: Remove unused include from ir_basic_block.cpp
>   glsl: Remove unused include from ir_constant_expression.cpp
>   glsl: Remove unused include in ir.cpp
>   glsl: Remove unused include in expr.flatt.
> 
>  src/glsl/ast_to_hir.cpp  | 1 -
>  src/glsl/builtin_variables.cpp   | 1 -
>  src/glsl/glsl_symbol_table.h | 2 +-
>  src/glsl/glsl_types.cpp  | 4 +---
>  src/glsl/hir_field_selection.cpp | 1 -
>  src/glsl/ir.cpp  | 1 -
>  src/glsl/ir_basic_block.cpp  | 2 --
>  src/glsl/ir_constant_expression.cpp  | 1 -
>  src/glsl/ir_expression_flattening.cpp| 2 --
>  src/glsl/link_uniform_block_active_visitor.h | 2 --
>  src/glsl/link_uniform_initializers.cpp   | 2 --
>  11 files changed, 2 insertions(+), 17 deletions(-)
> 
> -- 
> 2.0.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/9] glsl: Add C API to exec_node/exec_list.

[Matt Turner]

Our most frequently used list implementation was only usable from
C by manipulating the members of the structs. This series adds a
C API, wraps the C API with the C++ member functions (so no change
for C++ code), makes the foreach_list macros usable from C, and
replaces an open-coded list in the i965 driver with exec_list.

The C API consists of static inline functions, and the C++ member
functions are also marked inline.

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

[Mesa-dev] [PATCH 9/9] i965: Replace open-coded linked list with exec_list.

[Matt Turner]

---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 29 +++--
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  2 +-
 src/mesa/drivers/dri/i965/intel_resolve_map.c | 60 ++-
 src/mesa/drivers/dri/i965/intel_resolve_map.h | 16 +++
 4 files changed, 45 insertions(+), 62 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index dd7e57a..a0e637a 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -261,6 +261,7 @@ intel_miptree_create_layout(struct brw_context *brw,
mt->logical_height0 = height0;
mt->logical_depth0 = depth0;
mt->fast_clear_state = INTEL_FAST_CLEAR_STATE_NO_MCS;
+   exec_list_make_empty(&mt->hiz_map);
 
/* The cpp is bytes per (1, blockheight)-sized block for compressed
 * textures.  This is why you'll see divides by blockheight all over
@@ -1400,20 +1401,18 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
   return false;
 
/* Mark that all slices need a HiZ resolve. */
-   struct intel_resolve_map *head = &mt->hiz_map;
for (int level = mt->first_level; level <= mt->last_level; ++level) {
   if (!intel_miptree_level_enable_hiz(brw, mt, level))
  continue;
 
   for (int layer = 0; layer < mt->level[level].depth; ++layer) {
-head->next = malloc(sizeof(*head->next));
-head->next->prev = head;
-head->next->next = NULL;
-head = head->next;
-
-head->level = level;
-head->layer = layer;
-head->need = GEN6_HIZ_OP_HIZ_RESOLVE;
+ struct intel_resolve_map *m = malloc(sizeof(struct 
intel_resolve_map));
+ exec_node_init(&m->link);
+ m->level = level;
+ m->layer = layer;
+ m->need = GEN6_HIZ_OP_HIZ_RESOLVE;
+
+ exec_list_push_tail(&mt->hiz_map, &m->link);
   }
}
 
@@ -1513,15 +1512,15 @@ intel_miptree_all_slices_resolve(struct brw_context 
*brw,
 enum gen6_hiz_op need)
 {
bool did_resolve = false;
-   struct intel_resolve_map *i, *next;
 
-   for (i = mt->hiz_map.next; i; i = next) {
-  next = i->next;
-  if (i->need != need)
+   foreach_list_safe(node, &mt->hiz_map) {
+  struct intel_resolve_map *map = (struct intel_resolve_map *)node;
+
+  if (map->need != need)
 continue;
 
-  intel_hiz_exec(brw, mt, i->level, i->layer, need);
-  intel_resolve_map_remove(i);
+  intel_hiz_exec(brw, mt, map->level, map->layer, need);
+  intel_resolve_map_remove(map);
   did_resolve = true;
}
 
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 6a91884..bb04084 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -381,7 +381,7 @@ struct intel_mipmap_tree
 * \c mt->hiz_map. The resolve map of the child HiZ miptree, \c
 * mt->hiz_mt->hiz_map, is unused.
 */
-   struct intel_resolve_map hiz_map;
+   struct exec_list hiz_map; /* List of intel_resolve_map. */
 
/**
 * \brief Stencil miptree for depthstencil textures.
diff --git a/src/mesa/drivers/dri/i965/intel_resolve_map.c 
b/src/mesa/drivers/dri/i965/intel_resolve_map.c
index 04b5c94..a37afa6 100644
--- a/src/mesa/drivers/dri/i965/intel_resolve_map.c
+++ b/src/mesa/drivers/dri/i965/intel_resolve_map.c
@@ -33,50 +33,42 @@
  * changed to the given value of \c need.
  */
 void
-intel_resolve_map_set(struct intel_resolve_map *head,
+intel_resolve_map_set(struct exec_list *resolve_map,
  uint32_t level,
  uint32_t layer,
  enum gen6_hiz_op need)
 {
-   struct intel_resolve_map **tail = &head->next;
-   struct intel_resolve_map *prev = head;
-
-   while (*tail) {
-  if ((*tail)->level == level && (*tail)->layer == layer) {
- (*tail)->need = need;
+   foreach_list_typed(struct intel_resolve_map, map, link, resolve_map) {
+  if (map->level == level && map->layer == layer) {
+ map->need = need;
 return;
   }
-  prev = *tail;
-  tail = &(*tail)->next;
}
 
-   *tail = malloc(sizeof(**tail));
-   (*tail)->prev = prev;
-   (*tail)->next = NULL;
-   (*tail)->level = level;
-   (*tail)->layer = layer;
-   (*tail)->need = need;
+   struct intel_resolve_map *m = malloc(sizeof(struct intel_resolve_map));
+   exec_node_init(&m->link);
+   m->level = level;
+   m->layer = layer;
+   m->need = need;
+
+   exec_list_push_tail(resolve_map, &m->link);
 }
 
 /**
  * \brief Get an element from the map.
  * \return null if element is not contained in map.
  */
-struct intel_resolve_map*
-intel_resolve_map_get(struct intel_resolve_map *head,
+struct intel_resolve_map *
+intel_resolve_map_get(struct exec_list *resolve_map,
  uint32_t level,
  uint32_t layer)
 {
-   struct intel_resolve_map *item = head->next;
-

[Mesa-dev] [PATCH 6/9] glsl: Make exec_list members just wrap the C API.

[Matt Turner]

---
 src/glsl/list.h | 90 +
 1 file changed, 13 insertions(+), 77 deletions(-)

diff --git a/src/glsl/list.h b/src/glsl/list.h
index 49a9a5e..da81062 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -489,131 +489,67 @@ exec_node_insert_list_before(struct exec_node *n, struct 
exec_list *before)
 #ifdef __cplusplus
 inline void exec_list::make_empty()
 {
-   head = (exec_node *) & tail;
-   tail = NULL;
-   tail_pred = (exec_node *) & head;
+   exec_list_make_empty(this);
 }
 
 inline bool exec_list::is_empty() const
 {
-   /* There are three ways to test whether a list is empty or not.
-*
-* - Check to see if the \c head points to the \c tail.
-* - Check to see if the \c tail_pred points to the \c head.
-* - Check to see if the \c head is the sentinel node by test whether its
-*   \c next pointer is \c NULL.
-*
-* The first two methods tend to generate better code on modern systems
-* because they save a pointer dereference.
-*/
-   return head == (exec_node *) &tail;
+   return exec_list_is_empty(this);
 }
 
 inline const exec_node *exec_list::get_head() const
 {
-   return !is_empty() ? head : NULL;
+   return exec_list_get_head_const(this);
 }
 
 inline exec_node *exec_list::get_head()
 {
-   return !is_empty() ? head : NULL;
+   return exec_list_get_head(this);
 }
 
 inline const exec_node *exec_list::get_tail() const
 {
-   return !is_empty() ? tail_pred : NULL;
+   return exec_list_get_tail_const(this);
 }
 
 inline exec_node *exec_list::get_tail()
 {
-   return !is_empty() ? tail_pred : NULL;
+   return exec_list_get_tail(this);
 }
 
 inline void exec_list::push_head(exec_node *n)
 {
-   n->next = head;
-   n->prev = (exec_node *) &head;
-
-   n->next->prev = n;
-   head = n;
+   exec_list_push_head(this, n);
 }
 
 inline void exec_list::push_tail(exec_node *n)
 {
-   n->next = (exec_node *) &tail;
-   n->prev = tail_pred;
-
-   n->prev->next = n;
-   tail_pred = n;
+   exec_list_push_tail(this, n);
 }
 
 inline void exec_list::push_degenerate_list_at_head(exec_node *n)
 {
-   assert(n->prev->next == n);
-
-   n->prev->next = head;
-   head->prev = n->prev;
-   n->prev = (exec_node *) &head;
-   head = n;
+   exec_list_push_degenerate_list_at_head(this, n);
 }
 
 inline exec_node *exec_list::pop_head()
 {
-   exec_node *const n = this->get_head();
-   if (n != NULL)
-  n->remove();
-
-   return n;
+   return exec_list_pop_head(this);
 }
 
 inline void exec_list::move_nodes_to(exec_list *target)
 {
-   if (is_empty()) {
-  target->make_empty();
-   } else {
-  target->head = head;
-  target->tail = NULL;
-  target->tail_pred = tail_pred;
-
-  target->head->prev = (exec_node *) &target->head;
-  target->tail_pred->next = (exec_node *) &target->tail;
-
-  make_empty();
-   }
+   exec_list_move_nodes_to(this, target);
 }
 
 inline void exec_list::append_list(exec_list *source)
 {
-   if (source->is_empty())
-  return;
-
-   /* Link the first node of the source with the last node of the target list.
-*/
-   this->tail_pred->next = source->head;
-   source->head->prev = this->tail_pred;
-
-   /* Make the tail of the source list be the tail of the target list.
-*/
-   this->tail_pred = source->tail_pred;
-   this->tail_pred->next = (exec_node *) &this->tail;
-
-   /* Make the source list empty for good measure.
-*/
-   source->make_empty();
+   exec_list_append(this, source);
 }
 
 inline void exec_node::insert_before(exec_list *before)
 {
-   if (before->is_empty())
-  return;
-
-   before->tail_pred->next = this;
-   before->head->prev = this->prev;
-
-   this->prev->next = before->head;
-   this->prev = before->tail_pred;
-
-   before->make_empty();
+   exec_node_insert_list_before(this, before);
 }
 #endif
 
-- 
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/9] glsl: Move definition of exec_node member functions out of the struct.

[Matt Turner]

---
 src/glsl/list.h | 145 
 1 file changed, 83 insertions(+), 62 deletions(-)

diff --git a/src/glsl/list.h b/src/glsl/list.h
index 694b686..6216855 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -83,67 +83,29 @@ struct exec_node {
   /* empty */
}
 
-   const exec_node *get_next() const
-   {
-  return next;
-   }
-
-   exec_node *get_next()
-   {
-  return next;
-   }
-
-   const exec_node *get_prev() const
-   {
-  return prev;
-   }
+   const exec_node *get_next() const;
+   exec_node *get_next();
 
-   exec_node *get_prev()
-   {
-  return prev;
-   }
+   const exec_node *get_prev() const;
+   exec_node *get_prev();
 
-   void remove()
-   {
-  next->prev = prev;
-  prev->next = next;
-  next = NULL;
-  prev = NULL;
-   }
+   void remove();
 
/**
 * Link a node with itself
 *
 * This creates a sort of degenerate list that is occasionally useful.
 */
-   void self_link()
-   {
-  next = this;
-  prev = this;
-   }
+   void self_link();
 
/**
 * Insert a node in the list after the current node
 */
-   void insert_after(exec_node *after)
-   {
-  after->next = this->next;
-  after->prev = this;
-
-  this->next->prev = after;
-  this->next = after;
-   }
+   void insert_after(exec_node *after);
/**
 * Insert a node in the list before the current node
 */
-   void insert_before(exec_node *before)
-   {
-  before->next = this;
-  before->prev = this->prev;
-
-  this->prev->next = before;
-  this->prev = before;
-   }
+   void insert_before(exec_node *before);
 
/**
 * Insert another list in the list before the current node
@@ -153,33 +115,92 @@ struct exec_node {
/**
 * Replace the current node with the given node.
 */
-   void replace_with(exec_node *replacement)
-   {
-  replacement->prev = this->prev;
-  replacement->next = this->next;
-
-  this->prev->next = replacement;
-  this->next->prev = replacement;
-   }
+   void replace_with(exec_node *replacement);
 
/**
 * Is this the sentinel at the tail of the list?
 */
-   bool is_tail_sentinel() const
-   {
-  return this->next == NULL;
-   }
+   bool is_tail_sentinel() const;
 
/**
 * Is this the sentinel at the head of the list?
 */
-   bool is_head_sentinel() const
-   {
-  return this->prev == NULL;
-   }
+   bool is_head_sentinel() const;
 #endif
 };
 
+#ifdef __cplusplus
+inline const exec_node *exec_node::get_next() const
+{
+   return next;
+}
+
+inline exec_node *exec_node::get_next()
+{
+   return next;
+}
+
+inline const exec_node *exec_node::get_prev() const
+{
+   return prev;
+}
+
+inline exec_node *exec_node::get_prev()
+{
+   return prev;
+}
+
+inline void exec_node::remove()
+{
+   next->prev = prev;
+   prev->next = next;
+   next = NULL;
+   prev = NULL;
+}
+
+inline void exec_node::self_link()
+{
+   next = this;
+   prev = this;
+}
+
+inline void exec_node::insert_after(exec_node *after)
+{
+   after->next = this->next;
+   after->prev = this;
+
+   this->next->prev = after;
+   this->next = after;
+}
+
+inline void exec_node::insert_before(exec_node *before)
+{
+   before->next = this;
+   before->prev = this->prev;
+
+   this->prev->next = before;
+   this->prev = before;
+}
+
+inline void exec_node::replace_with(exec_node *replacement)
+{
+   replacement->prev = this->prev;
+   replacement->next = this->next;
+
+   this->prev->next = replacement;
+   this->next->prev = replacement;
+}
+
+inline bool exec_node::is_tail_sentinel() const
+{
+   return this->next == NULL;
+}
+
+inline bool exec_node::is_head_sentinel() const
+{
+   return this->prev == NULL;
+}
+#endif
 
 #ifdef __cplusplus
 /* This macro will not work correctly if `t' uses virtual inheritance.  If you
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 4/9] glsl: Add C API for exec_list.

[Matt Turner]

---
 src/glsl/list.h | 141 
 1 file changed, 141 insertions(+)

diff --git a/src/glsl/list.h b/src/glsl/list.h
index ce7f81f..a1200ac 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -360,6 +360,147 @@ struct exec_list {
 #endif
 };
 
+static inline void
+exec_list_make_empty(struct exec_list *list)
+{
+   list->head = (struct exec_node *) & list->tail;
+   list->tail = NULL;
+   list->tail_pred = (struct exec_node *) & list->head;
+}
+
+static inline bool
+exec_list_is_empty(const struct exec_list *list)
+{
+   /* There are three ways to test whether a list is empty or not.
+*
+* - Check to see if the \c head points to the \c tail.
+* - Check to see if the \c tail_pred points to the \c head.
+* - Check to see if the \c head is the sentinel node by test whether its
+*   \c next pointer is \c NULL.
+*
+* The first two methods tend to generate better code on modern systems
+* because they save a pointer dereference.
+*/
+   return list->head == (struct exec_node *) &list->tail;
+}
+
+static inline const struct exec_node *
+exec_list_get_head_const(const struct exec_list *list)
+{
+   return !exec_list_is_empty(list) ? list->head : NULL;
+}
+
+static inline struct exec_node *
+exec_list_get_head(struct exec_list *list)
+{
+   return !exec_list_is_empty(list) ? list->head : NULL;
+}
+
+static inline const struct exec_node *
+exec_list_get_tail_const(const struct exec_list *list)
+{
+   return !exec_list_is_empty(list) ? list->tail_pred : NULL;
+}
+
+static inline struct exec_node *
+exec_list_get_tail(struct exec_list *list)
+{
+   return !exec_list_is_empty(list) ? list->tail_pred : NULL;
+}
+
+static inline void
+exec_list_push_head(struct exec_list *list, struct exec_node *n)
+{
+   n->next = list->head;
+   n->prev = (struct exec_node *) &list->head;
+
+   n->next->prev = n;
+   list->head = n;
+}
+
+static inline void
+exec_list_push_tail(struct exec_list *list, struct exec_node *n)
+{
+   n->next = (struct exec_node *) &list->tail;
+   n->prev = list->tail_pred;
+
+   n->prev->next = n;
+   list->tail_pred = n;
+}
+
+static inline void
+exec_list_push_degenerate_list_at_head(struct exec_list *list, struct 
exec_node *n)
+{
+   assert(n->prev->next == n);
+
+   n->prev->next = list->head;
+   list->head->prev = n->prev;
+   n->prev = (struct exec_node *) &list->head;
+   list->head = n;
+}
+
+static inline struct exec_node *
+exec_list_pop_head(struct exec_list *list)
+{
+   struct exec_node *const n = exec_list_get_head(list);
+   if (n != NULL)
+  exec_node_remove(n);
+
+   return n;
+}
+
+static inline void
+exec_list_move_nodes_to(struct exec_list *list, struct exec_list *target)
+{
+   if (exec_list_is_empty(list)) {
+  exec_list_make_empty(target);
+   } else {
+  target->head = list->head;
+  target->tail = NULL;
+  target->tail_pred = list->tail_pred;
+
+  target->head->prev = (struct exec_node *) &target->head;
+  target->tail_pred->next = (struct exec_node *) &target->tail;
+
+  exec_list_make_empty(list);
+   }
+}
+
+static inline void
+exec_list_append(struct exec_list *list, struct exec_list *source)
+{
+   if (exec_list_is_empty(source))
+  return;
+
+   /* Link the first node of the source with the last node of the target list.
+*/
+   list->tail_pred->next = source->head;
+   source->head->prev = list->tail_pred;
+
+   /* Make the tail of the source list be the tail of the target list.
+*/
+   list->tail_pred = source->tail_pred;
+   list->tail_pred->next = (struct exec_node *) &list->tail;
+
+   /* Make the source list empty for good measure.
+*/
+   exec_list_make_empty(source);
+}
+
+static inline void
+exec_node_insert_list_before(struct exec_node *n, struct exec_list *before)
+{
+   if (exec_list_is_empty(before))
+  return;
+
+   before->tail_pred->next = n;
+   before->head->prev = n->prev;
+
+   n->prev->next = before->head;
+   n->prev = before->tail_pred;
+
+   exec_list_make_empty(before);
+}
 
 #ifdef __cplusplus
 inline void exec_list::make_empty()
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 2/9] glsl: Move definition of exec_list member functions out of the struct.

[Matt Turner]

---
 src/glsl/list.h | 235 ++--
 1 file changed, 127 insertions(+), 108 deletions(-)

diff --git a/src/glsl/list.h b/src/glsl/list.h
index 6216855..205dc91 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -242,75 +242,19 @@ struct exec_list {
   make_empty();
}
 
-   void make_empty()
-   {
-  head = (exec_node *) & tail;
-  tail = NULL;
-  tail_pred = (exec_node *) & head;
-   }
-
-   bool is_empty() const
-   {
-  /* There are three ways to test whether a list is empty or not.
-   *
-   * - Check to see if the \c head points to the \c tail.
-   * - Check to see if the \c tail_pred points to the \c head.
-   * - Check to see if the \c head is the sentinel node by test whether its
-   *   \c next pointer is \c NULL.
-   *
-   * The first two methods tend to generate better code on modern systems
-   * because they save a pointer dereference.
-   */
-  return head == (exec_node *) &tail;
-   }
-
-   const exec_node *get_head() const
-   {
-  return !is_empty() ? head : NULL;
-   }
-
-   exec_node *get_head()
-   {
-  return !is_empty() ? head : NULL;
-   }
+   void make_empty();
 
-   const exec_node *get_tail() const
-   {
-  return !is_empty() ? tail_pred : NULL;
-   }
+   bool is_empty() const;
 
-   exec_node *get_tail()
-   {
-  return !is_empty() ? tail_pred : NULL;
-   }
+   const exec_node *get_head() const;
+   exec_node *get_head();
 
-   void push_head(exec_node *n)
-   {
-  n->next = head;
-  n->prev = (exec_node *) &head;
+   const exec_node *get_tail() const;
+   exec_node *get_tail();
 
-  n->next->prev = n;
-  head = n;
-   }
-
-   void push_tail(exec_node *n)
-   {
-  n->next = (exec_node *) &tail;
-  n->prev = tail_pred;
-
-  n->prev->next = n;
-  tail_pred = n;
-   }
-
-   void push_degenerate_list_at_head(exec_node *n)
-   {
-  assert(n->prev->next == n);
-
-  n->prev->next = head;
-  head->prev = n->prev;
-  n->prev = (exec_node *) &head;
-  head = n;
-   }
+   void push_head(exec_node *n);
+   void push_tail(exec_node *n);
+   void push_degenerate_list_at_head(exec_node *n);
 
/**
 * Remove the first node from a list and return it
@@ -320,62 +264,137 @@ struct exec_list {
 *
 * \sa exec_list::get_head
 */
-   exec_node *pop_head()
-   {
-  exec_node *const n = this->get_head();
-  if (n != NULL)
-n->remove();
-
-  return n;
-   }
+   exec_node *pop_head();
 
/**
 * Move all of the nodes from this list to the target list
 */
-   void move_nodes_to(exec_list *target)
-   {
-  if (is_empty()) {
-target->make_empty();
-  } else {
-target->head = head;
-target->tail = NULL;
-target->tail_pred = tail_pred;
-
-target->head->prev = (exec_node *) &target->head;
-target->tail_pred->next = (exec_node *) &target->tail;
-
-make_empty();
-  }
-   }
+   void move_nodes_to(exec_list *target);
 
/**
 * Append all nodes from the source list to the target list
 */
-   void
-   append_list(exec_list *source)
-   {
-  if (source->is_empty())
-return;
-
-  /* Link the first node of the source with the last node of the target 
list.
-   */
-  this->tail_pred->next = source->head;
-  source->head->prev = this->tail_pred;
-
-  /* Make the tail of the source list be the tail of the target list.
-   */
-  this->tail_pred = source->tail_pred;
-  this->tail_pred->next = (exec_node *) &this->tail;
-
-  /* Make the source list empty for good measure.
-   */
-  source->make_empty();
-   }
+   void append_list(exec_list *source);
 #endif
 };
 
 
 #ifdef __cplusplus
+inline void exec_list::make_empty()
+{
+   head = (exec_node *) & tail;
+   tail = NULL;
+   tail_pred = (exec_node *) & head;
+}
+
+inline bool exec_list::is_empty() const
+{
+   /* There are three ways to test whether a list is empty or not.
+*
+* - Check to see if the \c head points to the \c tail.
+* - Check to see if the \c tail_pred points to the \c head.
+* - Check to see if the \c head is the sentinel node by test whether its
+*   \c next pointer is \c NULL.
+*
+* The first two methods tend to generate better code on modern systems
+* because they save a pointer dereference.
+*/
+   return head == (exec_node *) &tail;
+}
+
+inline const exec_node *exec_list::get_head() const
+{
+   return !is_empty() ? head : NULL;
+}
+
+inline exec_node *exec_list::get_head()
+{
+   return !is_empty() ? head : NULL;
+}
+
+inline const exec_node *exec_list::get_tail() const
+{
+   return !is_empty() ? tail_pred : NULL;
+}
+
+inline exec_node *exec_list::get_tail()
+{
+   return !is_empty() ? tail_pred : NULL;
+}
+
+inline void exec_list::push_head(exec_node *n)
+{
+   n->next = head;
+   n->prev = (exec_node *) &head;
+
+   n->next->prev = n;
+   head = n;
+}

[Mesa-dev] [PATCH 3/9] glsl: Add C API for exec_node.

[Matt Turner]

---
 src/glsl/list.h | 82 +
 1 file changed, 82 insertions(+)

diff --git a/src/glsl/list.h b/src/glsl/list.h
index 205dc91..ce7f81f 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -129,6 +129,88 @@ struct exec_node {
 #endif
 };
 
+static inline const struct exec_node *
+exec_node_get_next_const(const struct exec_node *n)
+{
+   return n->next;
+}
+
+static inline struct exec_node *
+exec_node_get_next(struct exec_node *n)
+{
+   return n->next;
+}
+
+static inline const struct exec_node *
+exec_node_get_prev_const(const struct exec_node *n)
+{
+   return n->prev;
+}
+
+static inline struct exec_node *
+exec_node_get_prev(struct exec_node *n)
+{
+   return n->prev;
+}
+
+static inline void
+exec_node_remove(struct exec_node *n)
+{
+   n->next->prev = n->prev;
+   n->prev->next = n->next;
+   n->next = NULL;
+   n->prev = NULL;
+}
+
+static inline void
+exec_node_self_link(struct exec_node *n)
+{
+   n->next = n;
+   n->prev = n;
+}
+
+static inline void
+exec_node_insert_after(struct exec_node *n, struct exec_node *after)
+{
+   after->next = n->next;
+   after->prev = n;
+
+   n->next->prev = after;
+   n->next = after;
+}
+
+static inline void
+exec_node_insert_node_before(struct exec_node *n, struct exec_node *before)
+{
+   before->next = n;
+   before->prev = n->prev;
+
+   n->prev->next = before;
+   n->prev = before;
+}
+
+static inline void
+exec_node_replace_with(struct exec_node *n, struct exec_node *replacement)
+{
+   replacement->prev = n->prev;
+   replacement->next = n->next;
+
+   n->prev->next = replacement;
+   n->next->prev = replacement;
+}
+
+static inline bool
+exec_node_is_tail_sentinel(const struct exec_node *n)
+{
+   return n->next == NULL;
+}
+
+static inline bool
+exec_node_is_head_sentinel(const struct exec_node *n)
+{
+   return n->prev == NULL;
+}
+
 #ifdef __cplusplus
 inline const exec_node *exec_node::get_next() const
 {
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 8/9] glsl: Add an exec_node_init() function, usable from C.

[Matt Turner]

---
 src/glsl/list.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/glsl/list.h b/src/glsl/list.h
index 803aab5..576bc14 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -129,6 +129,13 @@ struct exec_node {
 #endif
 };
 
+static inline void
+exec_node_init(struct exec_node *n)
+{
+   n->next = NULL;
+   n->prev = NULL;
+}
+
 static inline const struct exec_node *
 exec_node_get_next_const(const struct exec_node *n)
 {
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 7/9] glsl: Make foreach macros usable from C by adding struct keyword.

[Matt Turner]

---
 src/glsl/list.h | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/glsl/list.h b/src/glsl/list.h
index da81062..803aab5 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -556,13 +556,13 @@ inline void exec_node::insert_before(exec_list *before)
 /**
  * This version is safe even if the current node is removed.
  */ 
-#define foreach_list_safe(__node, __list)   \
-   for (exec_node * __node = (__list)->head, * __next = __node->next \
-   ; __next != NULL \
+#define foreach_list_safe(__node, __list)  
\
+   for (struct exec_node * __node = (__list)->head, * __next = __node->next
\
+   ; __next != NULL
\
; __node = __next, __next = __next->next)
 
 #define foreach_list(__node, __list)   \
-   for (exec_node * __node = (__list)->head\
+   for (struct exec_node * __node = (__list)->head \
; (__node)->next != NULL\
; (__node) = (__node)->next)
 
@@ -572,19 +572,19 @@ inline void exec_node::insert_before(exec_list *before)
  * This is safe against either current node being removed or replaced.
  */
 #define foreach_two_lists(__node1, __list1, __node2, __list2) \
-   for (exec_node * __node1 = (__list1)->head,\
-  * __node2 = (__list2)->head,\
-  * __next1 = __node1->next,  \
-  * __next2 = __node2->next   \
+   for (struct exec_node * __node1 = (__list1)->head, \
+ * __node2 = (__list2)->head, \
+ * __next1 = __node1->next,   \
+ * __next2 = __node2->next\
; __next1 != NULL && __next2 != NULL  \
; __node1 = __next1,  \
   __node2 = __next2,  \
   __next1 = __next1->next,\
   __next2 = __next2->next)
 
-#define foreach_list_const(__node, __list) \
-   for (const exec_node * __node = (__list)->head  \
-   ; (__node)->next != NULL\
+#define foreach_list_const(__node, __list) \
+   for (const struct exec_node * __node = (__list)->head   \
+   ; (__node)->next != NULL\
; (__node) = (__node)->next)
 
 #define foreach_list_typed(__type, __node, __field, __list)\
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 5/9] glsl: Make exec_node members just wrap the C API.

[Matt Turner]

---
 src/glsl/list.h | 38 +++---
 1 file changed, 11 insertions(+), 27 deletions(-)

diff --git a/src/glsl/list.h b/src/glsl/list.h
index a1200ac..49a9a5e 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -214,73 +214,57 @@ exec_node_is_head_sentinel(const struct exec_node *n)
 #ifdef __cplusplus
 inline const exec_node *exec_node::get_next() const
 {
-   return next;
+   return exec_node_get_next_const(this);
 }
 
 inline exec_node *exec_node::get_next()
 {
-   return next;
+   return exec_node_get_next(this);
 }
 
 inline const exec_node *exec_node::get_prev() const
 {
-   return prev;
+   return exec_node_get_prev_const(this);
 }
 
 inline exec_node *exec_node::get_prev()
 {
-   return prev;
+   return exec_node_get_prev(this);
 }
 
 inline void exec_node::remove()
 {
-   next->prev = prev;
-   prev->next = next;
-   next = NULL;
-   prev = NULL;
+   exec_node_remove(this);
 }
 
 inline void exec_node::self_link()
 {
-   next = this;
-   prev = this;
+   exec_node_self_link(this);
 }
 
 inline void exec_node::insert_after(exec_node *after)
 {
-   after->next = this->next;
-   after->prev = this;
-
-   this->next->prev = after;
-   this->next = after;
+   exec_node_insert_after(this, after);
 }
 
 inline void exec_node::insert_before(exec_node *before)
 {
-   before->next = this;
-   before->prev = this->prev;
-
-   this->prev->next = before;
-   this->prev = before;
+   exec_node_insert_node_before(this, before);
 }
 
 inline void exec_node::replace_with(exec_node *replacement)
 {
-   replacement->prev = this->prev;
-   replacement->next = this->next;
-
-   this->prev->next = replacement;
-   this->next->prev = replacement;
+   exec_node_replace_with(this, replacement);
 }
 
 inline bool exec_node::is_tail_sentinel() const
 {
-   return this->next == NULL;
+   return exec_node_is_tail_sentinel(this);
 }
 
 inline bool exec_node::is_head_sentinel() const
 {
-   return this->prev == NULL;
+   return exec_node_is_head_sentinel(this);
 }
 #endif
 
-- 
1.8.3.2

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

Re: [Mesa-dev] GlassyMesa Announcement

[Tom Stellard]

On Sat, Jun 07, 2014 at 01:24:39PM -0700, Greg Fischer wrote:
> LunarG, with support from Valve, announces the GlassyMesa project, an
> effort to bring the LLVM compiler infrastructure to Mesa.
> 

This is very interesting.  Have you done any testing with any of the
Gallium drivers?

How difficult would it be to bypass the LLVM IR -> GLSL IR -> TGSI
conversion and pass LLVM IR directly to drivers like radeonsi which
already use LLVM?

What are you plans for getting this upstream into Mesa?

-Tom

> What is GlassyMesa?
> 
> GlassyMesa utilizes LunarGLASS, the LLVM compiler stack with modifications
> allowing it to represent and optimize 3D shaders and target GPUs. This
> also includes use of glslang, the Khronos GLSL reference parser. It also
> includes a translation pass from LLVM IR to GLSL IR, the IR used by Mesa
> compiler backends. A slide deck with a block diagram is available at
> lunarg.com/wp-content/uploads/2014/06/GlassyMesaSlides-05Jun2014.pdf
> 
> Why create GlassyMesa?
> 
> LLVM brings state-of-the-art compiler optimizations to Mesa immediately. As
> importantly, it brings a modern Intermediate Representation (IR) which can
> be the basis for rapid development of new optimizations as shaders and
> shader languages evolve as well as enable multiple teams to develop
> components independently more efficiently than current IRs.
> Furthermore, this capability can be used as a basis for development
> of compiler backends using the LLVM backend infrastructure.
> 
> What is the current state of GlassyMesa?
> 
> GlassyMesa is in very early development. It is a proof-of-concept to
> demonstrate this approach can deliver shader runtime improvements and will
> continue to evolve in capability. Much functionality remains to be
> developed. No effort has been made yet to tune shader runtime or compile
> time performance. It is running only a handful of traces to our knowledge.
> Initial performance results are promising.
> 
> Why announce GlassyMesa now?
> 
> LunarG invites the feedback and cooperation of the Mesa community to this
> effort. It believes that an effort like this requires early and frequent
> input and support from the community.
> 
> What are the plans for GlassyMesa?
> 
> LunarG is planning to actively improve GlassyMesa functionality and
> performance over the coming months.
> 
> Where can I find GlassyMesa?
> 
> GlassyMesa is available at: *github.com*:LunarG/steamos_mesa.git, at branch
> 2014ww23.2_i965-LunarGlass_drop1
> 
> What is the licensing?
> 
> LunarGLASS is released under a BSD-style license. See
> http://www.lunarglass.org .

> ___
> 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 00/11] glsl: Remove unused includes found with IWYU

[Matt Turner]

On Mon, Jun 9, 2014 at 3:57 PM,   wrote:
> From: Thomas Helland 
>
> This series removes some unused includes in the glsl-directory.

Thanks. A lot of people use ccache, so series like this cause them to
have to rebuild (and not use ccache).

I've just sent a series that touches src/glsl's list.h, which is
included by a large portion of Mesa, so the rebuild will be
inevitable. I'll push your series at the same time as to not force
multiple rebuilds.

The series is

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

Re: [Mesa-dev] [PATCH 1/3] gallium: Add PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS

[Tom Stellard]

On Fri, May 30, 2014 at 05:31:10PM +0200, Bruno Jiménez wrote:
> ---
>  src/gallium/docs/source/screen.rst   | 2 ++
>  src/gallium/include/pipe/p_defines.h | 3 ++-
>  2 files changed, 4 insertions(+), 1 deletion(-)

Reviewed-by: Tom Stellard 

> 
> diff --git a/src/gallium/docs/source/screen.rst 
> b/src/gallium/docs/source/screen.rst
> index b292257..dde2c38 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -317,6 +317,8 @@ pipe_screen::get_compute_param.
>allocation in bytes.  Value type: ``uint64_t``.
>  * ``PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY``: Maximum frequency of the GPU
>clock in MHz. Value type: ``uint32_t``
> +* ``PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS``: Maximum number of compute units
> +  Value type: ``uint32_t``
>  
>  .. _pipe_bind:
>  
> diff --git a/src/gallium/include/pipe/p_defines.h 
> b/src/gallium/include/pipe/p_defines.h
> index 4024470..5572bb6 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -644,7 +644,8 @@ enum pipe_compute_cap
> PIPE_COMPUTE_CAP_MAX_PRIVATE_SIZE,
> PIPE_COMPUTE_CAP_MAX_INPUT_SIZE,
> PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE,
> -   PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY
> +   PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY,
> +   PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS
>  };
>  
>  /**
> -- 
> 1.9.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] clover: query driver for the max number of compute units

[Tom Stellard]

On Fri, May 30, 2014 at 05:31:12PM +0200, Bruno Jiménez wrote:

Reviewed-by: Tom Stellard 

> ---
>  src/gallium/state_trackers/clover/api/device.cpp  | 2 +-
>  src/gallium/state_trackers/clover/core/device.cpp | 6 ++
>  src/gallium/state_trackers/clover/core/device.hpp | 1 +
>  3 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
> b/src/gallium/state_trackers/clover/api/device.cpp
> index 1bc2692..97b2cf9 100644
> --- a/src/gallium/state_trackers/clover/api/device.cpp
> +++ b/src/gallium/state_trackers/clover/api/device.cpp
> @@ -109,7 +109,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
>break;
>  
> case CL_DEVICE_MAX_COMPUTE_UNITS:
> -  buf.as_scalar() = 1;
> +  buf.as_scalar() = dev.max_compute_units();
>break;
>  
> case CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS:
> diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
> b/src/gallium/state_trackers/clover/core/device.cpp
> index bc3e3e6..b6078db 100644
> --- a/src/gallium/state_trackers/clover/core/device.cpp
> +++ b/src/gallium/state_trackers/clover/core/device.cpp
> @@ -163,6 +163,12 @@ device::max_clock_frequency() const {
>
> PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY)[0];
>  }
>  
> +cl_uint
> +device::max_compute_units() const {
> +   return get_compute_param(pipe,
> +  PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS)[0];
> +}
> +
>  std::vector
>  device::max_block_size() const {
> auto v = get_compute_param(pipe, 
> PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE);
> diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
> b/src/gallium/state_trackers/clover/core/device.hpp
> index 3662c6b..731c31e 100644
> --- a/src/gallium/state_trackers/clover/core/device.hpp
> +++ b/src/gallium/state_trackers/clover/core/device.hpp
> @@ -62,6 +62,7 @@ namespace clover {
>size_t max_threads_per_block() const;
>cl_ulong max_mem_alloc_size() const;
>cl_uint max_clock_frequency() const;
> +  cl_uint max_compute_units() const;
>  
>std::vector max_block_size() const;
>std::string device_name() const;
> -- 
> 1.9.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] radeon/compute: Implement PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS

[Tom Stellard]

On Thu, Jun 05, 2014 at 08:39:29PM +0200, Bruno Jimenez wrote:
> 
> With a couple of changes, it applied cleanly to 3.14.5 (Arch's stable).
> And with the attached patch as #2 for my series I can get the correct
> number of compute units for my CEDAR.
> 
> But I don't know how or where I should add this new query param, given
> that it hasn't been added to the kernel yet. For now I have hardcoded
> the '0x20'.
> 
> Thanks for all Alex!
> Bruno
> 
> 

> From d2f37842171fdaff2a31d756c15479fc56646153 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Bruno=20Jim=C3=A9nez?= 
> Date: Thu, 5 Jun 2014 20:01:56 +0200
> Subject: [PATCH 2/3] radeon/compute: Implement
>  PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS
> 
> ---
>  src/gallium/drivers/radeon/r600_pipe_common.c | 7 +++
>  src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 4 
>  src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
>  3 files changed, 12 insertions(+)
> 
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index 70c4d1a..e7d33a0 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> @@ -519,6 +519,13 @@ static int r600_get_compute_param(struct pipe_screen 
> *screen,
>   }
>   return sizeof(uint32_t);
>  
> + case PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS:
> + if (ret) {
> + uint32_t *max_compute_units = ret;
> + *max_compute_units = rscreen->info.max_compute_units;
> + }
> + return sizeof(uint32_t);
> +
>   default:
>   fprintf(stderr, "unknown PIPE_COMPUTE_CAP %d\n", param);
>   return 0;
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c 
> b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> index e54e79e..124f6fa 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> @@ -382,6 +382,10 @@ static boolean do_winsys_init(struct radeon_drm_winsys 
> *ws)
>  radeon_get_drm_value(ws->fd, RADEON_INFO_MAX_PIPES, NULL,
>   &ws->info.r600_max_pipes);
>  
> +/* RADEON_INFO_ACTIVE_CU_COUNT == 0x20 */

This should be a define at the top of the file, just like we do with the
other RADEON_INFO_* values.

-Tom

> +radeon_get_drm_value(ws->fd, 0x20, NULL,
> + &ws->info.max_compute_units);
> +
>  if (radeon_get_drm_value(ws->fd, RADEON_INFO_SI_TILE_MODE_ARRAY, NULL,
>   ws->info.si_tile_mode_array)) {
>  ws->info.si_tile_mode_array_valid = TRUE;
> diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h 
> b/src/gallium/winsys/radeon/drm/radeon_winsys.h
> index 2d13550..6df1987 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
> +++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
> @@ -198,6 +198,7 @@ struct radeon_info {
>  uint32_tgart_size;
>  uint32_tvram_size;
>  uint32_tmax_sclk;
> +uint32_tmax_compute_units;
>  
>  uint32_tdrm_major; /* version */
>  uint32_tdrm_minor;
> -- 
> 2.0.0
> 

> ___
> 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 2/3] radeon/compute: Implement PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS

[Bruno Jimenez]

On Tue, 2014-06-10 at 14:10 -0400, Tom Stellard wrote:
> On Thu, Jun 05, 2014 at 08:39:29PM +0200, Bruno Jimenez wrote:
> > 
> > With a couple of changes, it applied cleanly to 3.14.5 (Arch's stable).
> > And with the attached patch as #2 for my series I can get the correct
> > number of compute units for my CEDAR.
> > 
> > But I don't know how or where I should add this new query param, given
> > that it hasn't been added to the kernel yet. For now I have hardcoded
> > the '0x20'.
> > 
> > Thanks for all Alex!
> > Bruno
> > 
> > 
> 
> > From d2f37842171fdaff2a31d756c15479fc56646153 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Bruno=20Jim=C3=A9nez?= 
> > Date: Thu, 5 Jun 2014 20:01:56 +0200
> > Subject: [PATCH 2/3] radeon/compute: Implement
> >  PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS
> > 
> > ---
> >  src/gallium/drivers/radeon/r600_pipe_common.c | 7 +++
> >  src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 4 
> >  src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
> >  3 files changed, 12 insertions(+)
> > 
> > diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
> > b/src/gallium/drivers/radeon/r600_pipe_common.c
> > index 70c4d1a..e7d33a0 100644
> > --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> > +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> > @@ -519,6 +519,13 @@ static int r600_get_compute_param(struct pipe_screen 
> > *screen,
> > }
> > return sizeof(uint32_t);
> >  
> > +   case PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS:
> > +   if (ret) {
> > +   uint32_t *max_compute_units = ret;
> > +   *max_compute_units = rscreen->info.max_compute_units;
> > +   }
> > +   return sizeof(uint32_t);
> > +
> > default:
> > fprintf(stderr, "unknown PIPE_COMPUTE_CAP %d\n", param);
> > return 0;
> > diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c 
> > b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> > index e54e79e..124f6fa 100644
> > --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> > +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> > @@ -382,6 +382,10 @@ static boolean do_winsys_init(struct radeon_drm_winsys 
> > *ws)
> >  radeon_get_drm_value(ws->fd, RADEON_INFO_MAX_PIPES, NULL,
> >   &ws->info.r600_max_pipes);
> >  
> > +/* RADEON_INFO_ACTIVE_CU_COUNT == 0x20 */
> 
> This should be a define at the top of the file, just like we do with the
> other RADEON_INFO_* values.

Hi,

This was a bit of a proof of concept that we could do the query and that
it worked.

I'm afraid that the other RADEON_INFO_* values were removed with this
commit:

commit 34564c875357a5d0a1f103f29949eafc2f8e1b35
Author: Marek Olšák 
Date:   Fri Apr 4 20:18:37 2014 +0200

winsys/radeon: remove definitions already present in radeon_drm.h

Reviewed-by: Michel Dänzer 
Reviewed-by: Christian König 

Also, I have seen this morning that the corresponding kernel patch has
been proposed for kernel 3.16:
http://lists.freedesktop.org/archives/dri-devel/2014-June/061483.html
So we really won't be able to do this query until this patch lands.

Anyway, I will change the patch so that RADEON_INFO_ACTIVE_CU_COUNT is
at the top of the file as proposed.

Thanks!
Bruno

> 
> -Tom
> 
> > +radeon_get_drm_value(ws->fd, 0x20, NULL,
> > + &ws->info.max_compute_units);
> > +
> >  if (radeon_get_drm_value(ws->fd, RADEON_INFO_SI_TILE_MODE_ARRAY, NULL,
> >   ws->info.si_tile_mode_array)) {
> >  ws->info.si_tile_mode_array_valid = TRUE;
> > diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h 
> > b/src/gallium/winsys/radeon/drm/radeon_winsys.h
> > index 2d13550..6df1987 100644
> > --- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
> > +++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
> > @@ -198,6 +198,7 @@ struct radeon_info {
> >  uint32_tgart_size;
> >  uint32_tvram_size;
> >  uint32_tmax_sclk;
> > +uint32_tmax_compute_units;
> >  
> >  uint32_tdrm_major; /* version */
> >  uint32_tdrm_minor;
> > -- 
> > 2.0.0
> > 
> 
> > ___
> > 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 0/9] glsl: Add C API to exec_node/exec_list.

[Ian Romanick]

On 06/10/2014 11:00 AM, Matt Turner wrote:
> Our most frequently used list implementation was only usable from
> C by manipulating the members of the structs. This series adds a
> C API, wraps the C API with the C++ member functions (so no change
> for C++ code), makes the foreach_list macros usable from C, and
> replaces an open-coded list in the i965 driver with exec_list.
> 
> The C API consists of static inline functions, and the C++ member
> functions are also marked inline.

Before seeing this series, I would have sworn up and down that at least
the core list API as available from C.  It really did start life as a C
API, but in the C++ switch the C version must have been dropped for
"clarity."

Assuming the answer to my question in patch 7 is, "No new warnings," the
series is

Reviewed-by: Ian Romanick 

> ___
> 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 7/9] glsl: Make foreach macros usable from C by adding struct keyword.

[Ian Romanick]

On 06/10/2014 11:00 AM, Matt Turner wrote:
> ---
>  src/glsl/list.h | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/src/glsl/list.h b/src/glsl/list.h
> index da81062..803aab5 100644
> --- a/src/glsl/list.h
> +++ b/src/glsl/list.h
> @@ -556,13 +556,13 @@ inline void exec_node::insert_before(exec_list *before)
>  /**
>   * This version is safe even if the current node is removed.
>   */ 
> -#define foreach_list_safe(__node, __list) \
> -   for (exec_node * __node = (__list)->head, * __next = __node->next \
> - ; __next != NULL \
> +#define foreach_list_safe(__node, __list)
> \
> +   for (struct exec_node * __node = (__list)->head, * __next = __node->next  
> \
> + ; __next != NULL
> \
>   ; __node = __next, __next = __next->next)

Did you notice if this adds any warnings in C++ uses?  I seem to recall
the compiler squaking if you mixed uses with and without struct.  Or
maybe that was just if you mixed struct and class...

>  
>  #define foreach_list(__node, __list) \
> -   for (exec_node * __node = (__list)->head  \
> +   for (struct exec_node * __node = (__list)->head   \
>   ; (__node)->next != NULL\
>   ; (__node) = (__node)->next)
>  
> @@ -572,19 +572,19 @@ inline void exec_node::insert_before(exec_list *before)
>   * This is safe against either current node being removed or replaced.
>   */
>  #define foreach_two_lists(__node1, __list1, __node2, __list2) \
> -   for (exec_node * __node1 = (__list1)->head,\
> -  * __node2 = (__list2)->head,\
> -  * __next1 = __node1->next,  \
> -  * __next2 = __node2->next   \
> +   for (struct exec_node * __node1 = (__list1)->head, \
> + * __node2 = (__list2)->head, \
> + * __next1 = __node1->next,   \
> + * __next2 = __node2->next\
>   ; __next1 != NULL && __next2 != NULL  \
>   ; __node1 = __next1,  \
>__node2 = __next2,  \
>__next1 = __next1->next,\
>__next2 = __next2->next)
>  
> -#define foreach_list_const(__node, __list)   \
> -   for (const exec_node * __node = (__list)->head\
> - ; (__node)->next != NULL\
> +#define foreach_list_const(__node, __list)   \
> +   for (const struct exec_node * __node = (__list)->head \
> + ; (__node)->next != NULL\
>   ; (__node) = (__node)->next)
>  
>  #define foreach_list_typed(__type, __node, __field, __list)  \
> 

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

Re: [Mesa-dev] Texture object locking

[Neil Roberts]

(I was trying to be too clever with git-sendmail and I accidentally
sent this to the wrong list… sorry!)

Jason wrote:

> Kristian and I were looking at this today, and there seems to be a
> substantial race in the way that we are doing texture locking.

Yes, it does look like this is a problem. I also noticed another
dodgy-looking pattern when implementing the GL_ARB_clear_texture
extension. Whenever it enters a meta function that operates on a
texture image it unlocks the texture object and then does stuff
directly using the texture image pointer. Presumably that pointer
could also be freed at any point. Take a look at
copytexsubimage_using_blit_framebuffer in meta.c for an example.

I suppose in practice though it's probably not all that likely that an
application will go and delete textures in another thread without the
other threads expecting it so I don't know whether it's a major
concern.

I knocked up the following patch to Weston's simple-egl example to try
and get it to crash when deleting textures from multiple threads and
sure enough it does segfault.

Regards,
- Neil

--- >8 --- (use git am --scissors to automatically chop here)
Subject: Hack to test multi-threaded deleting textures

---
 clients/simple-egl.c | 125 +--
 1 file changed, 112 insertions(+), 13 deletions(-)

diff --git a/clients/simple-egl.c b/clients/simple-egl.c
index 2097b4c..6e592b4 100644
--- a/clients/simple-egl.c
+++ b/clients/simple-egl.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xdg-shell-client-protocol.h"
 
@@ -100,6 +101,13 @@ struct window {
int fullscreen, opaque, buffer_size, frame_sync;
 };
 
+struct thread_data {
+   EGLDisplay dpy;
+   EGLSurface surface;
+   EGLContext ctx;
+   int thread_num;
+};
+
 static const char *vert_shader_text =
"uniform mat4 rotation;\n"
"attribute vec4 pos;\n"
@@ -117,15 +125,25 @@ static const char *frag_shader_text =
"  gl_FragColor = v_color;\n"
"}\n";
 
+static const EGLint context_attribs[] = {
+   EGL_CONTEXT_CLIENT_VERSION, 2,
+   EGL_NONE
+};
+
 static int running = 1;
 
+#define N_THREADS 63
+#define N_TEXTURES 512
+#define TEX_SIZE 128
+
+static pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
+static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
+static uint64_t running_threads;
+static GLuint textures[N_TEXTURES];
+
 static void
 init_egl(struct display *display, struct window *window)
 {
-   static const EGLint context_attribs[] = {
-   EGL_CONTEXT_CLIENT_VERSION, 2,
-   EGL_NONE
-   };
const char *extensions;
 
EGLint config_attribs[] = {
@@ -748,13 +766,101 @@ usage(int error_code)
exit(error_code);
 }
 
+static GLuint
+create_texture(void)
+{
+   GLuint tex;
+   GLubyte data[TEX_SIZE * TEX_SIZE * 4];
+
+   glGenTextures(1, &tex);
+   glBindTexture(GL_TEXTURE_2D, tex);
+   glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, TEX_SIZE, TEX_SIZE, 0,
+GL_RGBA, GL_UNSIGNED_BYTE, data);
+   glBindTexture(GL_TEXTURE_2D, 0);
+
+   return tex;
+}
+
+static void *
+thread_func(void *data)
+{
+   struct thread_data *thread_data = data;
+   int i;
+
+   eglMakeCurrent(thread_data->dpy,
+  thread_data->surface,
+  thread_data->surface,
+  thread_data->ctx);
+
+   while (true) {
+   /* Wait until this thread is told to run */
+   pthread_mutex_lock(&mutex);
+   while (!(running_threads & (1ULL << thread_data->thread_num)))
+   pthread_cond_wait(&cond, &mutex);
+   pthread_mutex_unlock(&mutex);
+
+   /* Delete all of the textures */
+   for (i = 0; i < N_TEXTURES; i++)
+   glDeleteTextures(1, textures + i);
+
+   /* Report that our thread is no longer running */
+   pthread_mutex_lock(&mutex);
+   running_threads &= ~(1ULL << thread_data->thread_num);
+   pthread_cond_broadcast(&cond);
+   pthread_mutex_unlock(&mutex);
+   }
+
+   return data;
+}
+
+static void
+delete_thread_test(struct display *display)
+{
+   pthread_t thread;
+   struct thread_data thread_data[N_THREADS];
+   int i;
+
+   for (i = 0; i < N_THREADS; i++) {
+   thread_data[i].dpy = display->egl.dpy;
+   thread_data[i].surface = display->window->egl_surface;
+   thread_data[i].ctx = eglCreateContext(display->egl.dpy,
+ display->egl.conf,
+ display->egl.ctx,
+ context_attribs);
+   thread_data[i].thread_num = i;
+   pthread_create(&thread,
+  NULL, /* attr */

Re: [Mesa-dev] [PATCH] i965: Set the fast clear color value for texture surfaces

[Ian Romanick]

On 06/09/2014 09:43 AM, Neil Roberts wrote:
> When a multisampled texture is used for sampling the fast clear color value
> needs to be programmed into the surface state. This was being left as all
> zeroes so if the surface was cleared to a value other than black then it
> wouldn't work properly. This doesn't matter for single-sample textures because
> in that case the MCS buffer is resolved before it is used as a texture source.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=79729

This sounds believable.  We should get a R-b from one of the guys more
familiar with the backend, but, FWIW,

Reviewed-by: Ian Romanick 
Cc: "10.1 10.2" 

I expect this bug is reproducible on both 10.1.x and 10.2...

> ---
>  src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 4 +++-
>  src/mesa/drivers/dri/i965/gen8_surface_state.c| 4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c 
> b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> index b31f491..12cdc2b 100644
> --- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> @@ -337,6 +337,8 @@ gen7_update_texture_surface(struct gl_context *ctx,
>/* mip count */
>(intelObj->_MaxLevel - tObj->BaseLevel));
>  
> +   surf[7] = mt->fast_clear_color_value;
> +
> if (brw->is_haswell) {
>/* Handling GL_ALPHA as a surface format override breaks 1.30+ style
> * texturing functions that return a float, as our code generation 
> always
> @@ -351,7 +353,7 @@ gen7_update_texture_surface(struct gl_context *ctx,
>  
>const bool need_scs_green_to_blue = for_gather && tex_format == 
> BRW_SURFACEFORMAT_R32G32_FLOAT_LD;
>  
> -  surf[7] =
> +  surf[7] |=
>   SET_FIELD(brw_swizzle_to_scs(GET_SWZ(swizzle, 0), 
> need_scs_green_to_blue), GEN7_SURFACE_SCS_R) |
>   SET_FIELD(brw_swizzle_to_scs(GET_SWZ(swizzle, 1), 
> need_scs_green_to_blue), GEN7_SURFACE_SCS_G) |
>   SET_FIELD(brw_swizzle_to_scs(GET_SWZ(swizzle, 2), 
> need_scs_green_to_blue), GEN7_SURFACE_SCS_B) |
> diff --git a/src/mesa/drivers/dri/i965/gen8_surface_state.c 
> b/src/mesa/drivers/dri/i965/gen8_surface_state.c
> index 406f68e..80ac4f3 100644
> --- a/src/mesa/drivers/dri/i965/gen8_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/gen8_surface_state.c
> @@ -207,9 +207,11 @@ gen8_update_texture_surface(struct gl_context *ctx,
>(firstImage->_BaseFormat == GL_DEPTH_COMPONENT ||
> firstImage->_BaseFormat == GL_DEPTH_STENCIL);
>  
> +   surf[7] = mt->fast_clear_color_value;
> +
> const int swizzle =
>unlikely(alpha_depth) ? SWIZZLE_XYZW : brw_get_texture_swizzle(ctx, 
> tObj);
> -   surf[7] =
> +   surf[7] |=
>SET_FIELD(brw_swizzle_to_scs(GET_SWZ(swizzle, 0), false), 
> GEN7_SURFACE_SCS_R) |
>SET_FIELD(brw_swizzle_to_scs(GET_SWZ(swizzle, 1), false), 
> GEN7_SURFACE_SCS_G) |
>SET_FIELD(brw_swizzle_to_scs(GET_SWZ(swizzle, 2), false), 
> GEN7_SURFACE_SCS_B) |
> 

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

Re: [Mesa-dev] [PATCH] i965: Actually use the Mesa IR optimizer.

[Ian Romanick]

On 06/09/2014 12:36 AM, Kenneth Graunke wrote:
> We have this wonderful thing called an optimizer---maybe we should
> consider calling it?

That's really weird.  The *only* place this is called is in ir_to_mesa.
 It seems like the assember should just call it after assembling any
program.  Weird.  Either way, this patch is

Reviewed-by: Ian Romanick 

> Slightly improves the vertex shaders in Shadowrun Returns, which uses
> ARB_vertex_program and ARB_fragment_program:
> 
> total instructions in shared programs: 117131 -> 117016 (-0.10%)
> instructions in affected programs: 6771 -> 6656 (-1.70%)
> 
> No fragment programs were helped.  Presumably, we don't see any benefits
> for FS because our FS backend has a much better optimizer than our vec4
> backend.
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_fs_fp.cpp   | 2 ++
>  src/mesa/drivers/dri/i965/brw_vec4_vp.cpp | 3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
> index ba5514a..d71c43b 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_fp.cpp
> @@ -113,6 +113,8 @@ fs_visitor::emit_fp_scalar_math(enum opcode opcode,
>  void
>  fs_visitor::emit_fragment_program_code()
>  {
> +   _mesa_optimize_program(ctx, prog);
> +
> setup_fp_regs();
>  
> fs_reg null = fs_reg(brw_null_reg());
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_vp.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_vp.cpp
> index f1000f2..c1b9a2d 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_vp.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_vp.cpp
> @@ -31,6 +31,7 @@
>  #include "brw_vec4.h"
>  #include "brw_vs.h"
>  extern "C" {
> +#include "program/prog_optimize.h"
>  #include "program/prog_parameter.h"
>  #include "program/prog_print.h"
>  }
> @@ -53,6 +54,8 @@ vec4_visitor::emit_vp_sop(uint32_t conditional_mod,
>  void
>  vec4_vs_visitor::emit_program_code()
>  {
> +   _mesa_optimize_program(ctx, prog);
> +
> this->need_all_constants_in_pull_buffer = false;
>  
> setup_vp_regs();
> 

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

Re: [Mesa-dev] [PATCH 7/9] glsl: Make foreach macros usable from C by adding struct keyword.

[Matt Turner]

On Tue, Jun 10, 2014 at 11:38 AM, Ian Romanick  wrote:
> On 06/10/2014 11:00 AM, Matt Turner wrote:
>> ---
>>  src/glsl/list.h | 22 +++---
>>  1 file changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/glsl/list.h b/src/glsl/list.h
>> index da81062..803aab5 100644
>> --- a/src/glsl/list.h
>> +++ b/src/glsl/list.h
>> @@ -556,13 +556,13 @@ inline void exec_node::insert_before(exec_list *before)
>>  /**
>>   * This version is safe even if the current node is removed.
>>   */
>> -#define foreach_list_safe(__node, __list) \
>> -   for (exec_node * __node = (__list)->head, * __next = __node->next \
>> - ; __next != NULL \
>> +#define foreach_list_safe(__node, __list)   
>>  \
>> +   for (struct exec_node * __node = (__list)->head, * __next = __node->next 
>>  \
>> + ; __next != NULL   
>>  \
>>   ; __node = __next, __next = __next->next)
>
> Did you notice if this adds any warnings in C++ uses?  I seem to recall
> the compiler squaking if you mixed uses with and without struct.  Or
> maybe that was just if you mixed struct and class...

Yep, no new warnings.

I tried a little test program
% cat t.cpp
class asdf {
int x;
};

void f() {
asdf a;
struct asdf b;
class asdf c;
}

and I can't make it generate warnings (other than unused variables)
regardless of whether I define asdf as a class or a struct.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/9] glsl: Add C API to exec_node/exec_list.

[Matt Turner]

On Tue, Jun 10, 2014 at 11:38 AM, Ian Romanick  wrote:
> On 06/10/2014 11:00 AM, Matt Turner wrote:
>> Our most frequently used list implementation was only usable from
>> C by manipulating the members of the structs. This series adds a
>> C API, wraps the C API with the C++ member functions (so no change
>> for C++ code), makes the foreach_list macros usable from C, and
>> replaces an open-coded list in the i965 driver with exec_list.
>>
>> The C API consists of static inline functions, and the C++ member
>> functions are also marked inline.
>
> Before seeing this series, I would have sworn up and down that at least
> the core list API as available from C.  It really did start life as a C
> API, but in the C++ switch the C version must have been dropped for
> "clarity."

Must have been before it was imported into git (commit 7e4ce719).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MaxAnisotropy with GL_NEAREST on i965

[Ian Romanick]

On 05/22/2014 02:45 PM, Cody Northrop wrote:
> Greetings,
> 
> I ran into a problem with how Mesa on i965 handles MaxAnisotropy.
> 
> The app I'm looking at sets sampler state min and mag filters to
> GL_NEAREST, but also sets GL_TEXTURE_MAX_ANISOTROPY_EXT, like so:
> 
>  glSamplerParameteri(pointSampler, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
>  glSamplerParameteri(pointSampler, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
>  glSamplerParameteri(pointSampler, GL_TEXTURE_MAX_ANISOTROPY_EXT, 8);
> 
> On Nvidia closed source and Intel closed source drivers, MaxAnisotropy
> is ignored and unfiltered texture results are returned.  In this case,
> solid red.
> 
> Using Haswell with Mesa, MaxAnisotropy trumps GL_NEAREST, and the texels
> are filtered, returning almost greyscale values.  See
> gen7_update_sampler_state().
> 
> According to the extension, both behaviors are allowed:
> 
> http://www.opengl.org/registry/specs/EXT/texture_filter_anisotropic.txt
> 
> Implementations are free to use the specified minification and
> magnification filter to select a particular anisotropic texture
> filtering scheme.  For example, a NEAREST filter with a maximum
> degree of anisotropy of two could be treated as a 2-tap filter that
> accounts for the direction of anisotropy.  Implementations are also
> permitted to ignore the minification or magnification filter and
> implement the highest quality of anisotropic filtering possible.
> 
> So no one is at fault here, it's just different.  What's the policy for
> ambiguities like this?  Should i965 match other vendors?  Or emit a
> warning that requested filter mode is being overridden? 

There are a lot of places in the spec that are explicitly undefined.  We
have a couple different strategies for dealing with those.  When we
notice (and I don't think we ever noticed this particular case):

A. Pick the easiest behavior that some other vendor also does.

B. If all other vendors do the same thing, do that and submit a spec bug.

For "other vendors" we generally just look at the other vendors
available on Linux: AMD and NVIDIA.  We may also look at the Intel
Windows driver and Apple.

Do you know what AMD does in this case?

> Below are modifications to a piglit test that show the problem.  I
> couldn't find any existing tests for EXT_texture_filter_anisotropic. 
> The changes fill a single LOD texture with interleaved colors, then
> expects a single unfiltered red color back, but i965 returns greenish brown.

If we're going to decide that one behavior is correct, we should have a
test for it.  However, that test should be able to run on as many GPUs
that Mesa supports as possible.  It should be pretty easy to make a test
that just uses OpenGL 1.2 + GL_EXT_texture_filter_anisotropic.

It is not at all surprising that there are no tests for this extension.
 Any new tests added should go in tests/spec/ext_texture_filter_anisotropic.

> Thanks,
> 
> -Cody
> 
> 
> 
> diff --git
> a/tests/spec/arb_separate_shader_objects/rendezvous_by_location.c
> b/tests/spec/arb_separate_shader_objects/rendezvous_by_location.c
> index 4193ea5..7e83890 100644
> --- a/tests/spec/arb_separate_shader_objects/rendezvous_by_location.c
> +++ b/tests/spec/arb_separate_shader_objects/rendezvous_by_location.c
> @@ -95,6 +95,7 @@ static const char *fs_code_same_location_order_template =
> "#version %d\n"
> "#extension GL_ARB_separate_shader_objects: require\n"
> "#extension GL_ARB_explicit_attrib_location: enable\n"
> +   "#extension GL_ARB_shading_language_420pack: require\n"
> "\n"
> "#if __VERSION__ >= 130\n"
> "layout(location = 0) out vec4 out_color;\n"
> @@ -104,13 +105,53 @@ static const char
> *fs_code_same_location_order_template =
> "\n"
> "layout(location = 2) in vec3 b; /* should get vec3(0, 0, 1) */\n"
> "layout(location = 3) in vec3 a; /* should get vec3(1, 0, 0) */\n"
> +   "layout(binding = 10) uniform sampler2D interleavedTexture;\n"
> "\n"
> "void main()\n"
> "{\n"
> -   "out_color = vec4(cross(b, a), 1);\n"
> +   "out_color = texture2D(interleavedTexture, vec2(0.0, 0.0));\n"
> "}\n"
> ;
>  
> +/**
> + * Create a an image with 3 interleaved colors.
> + */
> +static GLubyte *
> +create_interleaved_image(GLint w, GLint h, const GLubyte red[4], const
> GLubyte green[4], const GLubyte blue[4])
> +{
> +   GLubyte *buf = (GLubyte *) malloc(w * h * 4);
> +   int i;
> +   for (i = 0; i < w * h; i++) {
> +
> +   switch(i % 3) {
> +   case 0:
> +   buf[i*4+0] = red[0];
> +   buf[i*4+1] = red[1];
> +   buf[i*4+2] = red[2];
> +   buf[i*4+3] = red[3];
> +   break;
> +
> +   case 1:
> +   buf[i*4+0] = green[0];
> +   buf[i*4+1] = green[1];
> + 

Re: [Mesa-dev] [PATCH] Add GPU BLIT of texture image to PBO in Intel driver

[Ian Romanick]

On 02/24/2014 02:55 PM, Matt Turner wrote:
> On Mon, Feb 24, 2014 at 2:04 PM, Jon Ashburn  wrote:
>> Add Intel driver hook for glGetTexImage to accelerate the case of reading
>> texture image into a PBO.  This case gets huge performance gains by using
>> GPU BLIT directly to PBO rather than GPU BLIT to temporary texture followed
>> by memcpy.
>>
>> No regressions on Piglit tests  with Intel driver.
> 
> Patch summary should be prefixed with "i965:" and the commit message
> should contain some performance data.

ping.

We're still waiting for the requested changes to the commit message...

> ___
> 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 7/9] glsl: Make foreach macros usable from C by adding struct keyword.

[Patrick Baggett]

>
>
> Yep, no new warnings.
>
> I tried a little test program
> % cat t.cpp
> class asdf {
> int x;
> };
>
> void f() {
> asdf a;
> struct asdf b;
> class asdf c;
> }
>
C++ never ceases to amaze.


> and I can't make it generate warnings (other than unused variables)
> regardless of whether I define asdf as a class or a struct.
> ___
> 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 7/9] glsl: Make foreach macros usable from C by adding struct keyword.

[Ian Romanick]

On 06/10/2014 12:06 PM, Matt Turner wrote:
> On Tue, Jun 10, 2014 at 11:38 AM, Ian Romanick  wrote:
>> On 06/10/2014 11:00 AM, Matt Turner wrote:
>>> ---
>>>  src/glsl/list.h | 22 +++---
>>>  1 file changed, 11 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/src/glsl/list.h b/src/glsl/list.h
>>> index da81062..803aab5 100644
>>> --- a/src/glsl/list.h
>>> +++ b/src/glsl/list.h
>>> @@ -556,13 +556,13 @@ inline void exec_node::insert_before(exec_list 
>>> *before)
>>>  /**
>>>   * This version is safe even if the current node is removed.
>>>   */
>>> -#define foreach_list_safe(__node, __list) \
>>> -   for (exec_node * __node = (__list)->head, * __next = __node->next \
>>> - ; __next != NULL \
>>> +#define foreach_list_safe(__node, __list)  
>>>   \
>>> +   for (struct exec_node * __node = (__list)->head, * __next = 
>>> __node->next  \
>>> + ; __next != NULL  
>>>   \
>>>   ; __node = __next, __next = __next->next)
>>
>> Did you notice if this adds any warnings in C++ uses?  I seem to recall
>> the compiler squaking if you mixed uses with and without struct.  Or
>> maybe that was just if you mixed struct and class...
> 
> Yep, no new warnings.
> 
> I tried a little test program
> % cat t.cpp
> class asdf {
> int x;
> };
> 
> void f() {
> asdf a;
> struct asdf b;
> class asdf c;
> }
> 
> and I can't make it generate warnings (other than unused variables)
> regardless of whether I define asdf as a class or a struct.

I did a little more research.  Looking at the commit history, it must
just be an MSVC thing:

commit 78d3cfb5b4fe1dbe052f87458e62cc2be2ecf171
Author: Brian Paul 
Date:   Sun Nov 4 16:43:44 2012 -0700

glsl: remove incorrect 'struct' keyword

ir_variable is a class, not a struct.  Fixes an MSVC warning.

Reviewed-by: Jose Fonseca 

So, I think it is just class vs struct (and not struct vs nothing) that
causes the warning.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] radeon/compute: Implement PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS

[Tom Stellard]

On Tue, Jun 10, 2014 at 08:36:05PM +0200, Bruno Jimenez wrote:
> On Tue, 2014-06-10 at 14:10 -0400, Tom Stellard wrote:
> > On Thu, Jun 05, 2014 at 08:39:29PM +0200, Bruno Jimenez wrote:
> > > 
> > > With a couple of changes, it applied cleanly to 3.14.5 (Arch's stable).
> > > And with the attached patch as #2 for my series I can get the correct
> > > number of compute units for my CEDAR.
> > > 
> > > But I don't know how or where I should add this new query param, given
> > > that it hasn't been added to the kernel yet. For now I have hardcoded
> > > the '0x20'.
> > > 
> > > Thanks for all Alex!
> > > Bruno
> > > 
> > > 
> > 
> > > From d2f37842171fdaff2a31d756c15479fc56646153 Mon Sep 17 00:00:00 2001
> > > From: =?UTF-8?q?Bruno=20Jim=C3=A9nez?= 
> > > Date: Thu, 5 Jun 2014 20:01:56 +0200
> > > Subject: [PATCH 2/3] radeon/compute: Implement
> > >  PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS
> > > 
> > > ---
> > >  src/gallium/drivers/radeon/r600_pipe_common.c | 7 +++
> > >  src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 4 
> > >  src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
> > >  3 files changed, 12 insertions(+)
> > > 
> > > diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
> > > b/src/gallium/drivers/radeon/r600_pipe_common.c
> > > index 70c4d1a..e7d33a0 100644
> > > --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> > > +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> > > @@ -519,6 +519,13 @@ static int r600_get_compute_param(struct pipe_screen 
> > > *screen,
> > >   }
> > >   return sizeof(uint32_t);
> > >  
> > > + case PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS:
> > > + if (ret) {
> > > + uint32_t *max_compute_units = ret;
> > > + *max_compute_units = rscreen->info.max_compute_units;
> > > + }
> > > + return sizeof(uint32_t);
> > > +
> > >   default:
> > >   fprintf(stderr, "unknown PIPE_COMPUTE_CAP %d\n", param);
> > >   return 0;
> > > diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c 
> > > b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> > > index e54e79e..124f6fa 100644
> > > --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> > > +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
> > > @@ -382,6 +382,10 @@ static boolean do_winsys_init(struct 
> > > radeon_drm_winsys *ws)
> > >  radeon_get_drm_value(ws->fd, RADEON_INFO_MAX_PIPES, NULL,
> > >   &ws->info.r600_max_pipes);
> > >  
> > > +/* RADEON_INFO_ACTIVE_CU_COUNT == 0x20 */
> > 
> > This should be a define at the top of the file, just like we do with the
> > other RADEON_INFO_* values.
> 
> Hi,
> 
> This was a bit of a proof of concept that we could do the query and that
> it worked.
> 
> I'm afraid that the other RADEON_INFO_* values were removed with this
> commit:
> 
> commit 34564c875357a5d0a1f103f29949eafc2f8e1b35
> Author: Marek Olšák 
> Date:   Fri Apr 4 20:18:37 2014 +0200
> 
> winsys/radeon: remove definitions already present in radeon_drm.h
> 
> Reviewed-by: Michel Dänzer 
> Reviewed-by: Christian König 
> 
> Also, I have seen this morning that the corresponding kernel patch has
> been proposed for kernel 3.16:
> http://lists.freedesktop.org/archives/dri-devel/2014-June/061483.html
> So we really won't be able to do this query until this patch lands.
> 
> Anyway, I will change the patch so that RADEON_INFO_ACTIVE_CU_COUNT is
> at the top of the file as proposed.
>

Thanks, you should also add this same define to libdrm:
include/drm/radeon_drm.h

-Tom

> Thanks!
> Bruno
> 
> > 
> > -Tom
> > 
> > > +radeon_get_drm_value(ws->fd, 0x20, NULL,
> > > + &ws->info.max_compute_units);
> > > +
> > >  if (radeon_get_drm_value(ws->fd, RADEON_INFO_SI_TILE_MODE_ARRAY, 
> > > NULL,
> > >   ws->info.si_tile_mode_array)) {
> > >  ws->info.si_tile_mode_array_valid = TRUE;
> > > diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h 
> > > b/src/gallium/winsys/radeon/drm/radeon_winsys.h
> > > index 2d13550..6df1987 100644
> > > --- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
> > > +++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
> > > @@ -198,6 +198,7 @@ struct radeon_info {
> > >  uint32_tgart_size;
> > >  uint32_tvram_size;
> > >  uint32_tmax_sclk;
> > > +uint32_tmax_compute_units;
> > >  
> > >  uint32_tdrm_major; /* version */
> > >  uint32_tdrm_minor;
> > > -- 
> > > 2.0.0
> > > 
> > 
> > > ___
> > > 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 2/3] radeon/compute: Implement PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS

[Alex Deucher]

On Tue, Jun 10, 2014 at 3:23 PM, Tom Stellard  wrote:
> On Tue, Jun 10, 2014 at 08:36:05PM +0200, Bruno Jimenez wrote:
>> On Tue, 2014-06-10 at 14:10 -0400, Tom Stellard wrote:
>> > On Thu, Jun 05, 2014 at 08:39:29PM +0200, Bruno Jimenez wrote:
>> > >
>> > > With a couple of changes, it applied cleanly to 3.14.5 (Arch's stable).
>> > > And with the attached patch as #2 for my series I can get the correct
>> > > number of compute units for my CEDAR.
>> > >
>> > > But I don't know how or where I should add this new query param, given
>> > > that it hasn't been added to the kernel yet. For now I have hardcoded
>> > > the '0x20'.
>> > >
>> > > Thanks for all Alex!
>> > > Bruno
>> > >
>> > >
>> >
>> > > From d2f37842171fdaff2a31d756c15479fc56646153 Mon Sep 17 00:00:00 2001
>> > > From: =?UTF-8?q?Bruno=20Jim=C3=A9nez?= 
>> > > Date: Thu, 5 Jun 2014 20:01:56 +0200
>> > > Subject: [PATCH 2/3] radeon/compute: Implement
>> > >  PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS
>> > >
>> > > ---
>> > >  src/gallium/drivers/radeon/r600_pipe_common.c | 7 +++
>> > >  src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 4 
>> > >  src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
>> > >  3 files changed, 12 insertions(+)
>> > >
>> > > diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
>> > > b/src/gallium/drivers/radeon/r600_pipe_common.c
>> > > index 70c4d1a..e7d33a0 100644
>> > > --- a/src/gallium/drivers/radeon/r600_pipe_common.c
>> > > +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
>> > > @@ -519,6 +519,13 @@ static int r600_get_compute_param(struct 
>> > > pipe_screen *screen,
>> > >   }
>> > >   return sizeof(uint32_t);
>> > >
>> > > + case PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS:
>> > > + if (ret) {
>> > > + uint32_t *max_compute_units = ret;
>> > > + *max_compute_units = rscreen->info.max_compute_units;
>> > > + }
>> > > + return sizeof(uint32_t);
>> > > +
>> > >   default:
>> > >   fprintf(stderr, "unknown PIPE_COMPUTE_CAP %d\n", param);
>> > >   return 0;
>> > > diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c 
>> > > b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>> > > index e54e79e..124f6fa 100644
>> > > --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>> > > +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>> > > @@ -382,6 +382,10 @@ static boolean do_winsys_init(struct 
>> > > radeon_drm_winsys *ws)
>> > >  radeon_get_drm_value(ws->fd, RADEON_INFO_MAX_PIPES, NULL,
>> > >   &ws->info.r600_max_pipes);
>> > >
>> > > +/* RADEON_INFO_ACTIVE_CU_COUNT == 0x20 */
>> >
>> > This should be a define at the top of the file, just like we do with the
>> > other RADEON_INFO_* values.
>>
>> Hi,
>>
>> This was a bit of a proof of concept that we could do the query and that
>> it worked.
>>
>> I'm afraid that the other RADEON_INFO_* values were removed with this
>> commit:
>>
>> commit 34564c875357a5d0a1f103f29949eafc2f8e1b35
>> Author: Marek Olšák 
>> Date:   Fri Apr 4 20:18:37 2014 +0200
>>
>> winsys/radeon: remove definitions already present in radeon_drm.h
>>
>> Reviewed-by: Michel Dänzer 
>> Reviewed-by: Christian König 
>>
>> Also, I have seen this morning that the corresponding kernel patch has
>> been proposed for kernel 3.16:
>> http://lists.freedesktop.org/archives/dri-devel/2014-June/061483.html
>> So we really won't be able to do this query until this patch lands.
>>
>> Anyway, I will change the patch so that RADEON_INFO_ACTIVE_CU_COUNT is
>> at the top of the file as proposed.
>>
>
> Thanks, you should also add this same define to libdrm:
> include/drm/radeon_drm.h

Wait until the kernel is released before pulling the latest
radeon_drm.h into libdrm.

Alex

>
> -Tom
>
>> Thanks!
>> Bruno
>>
>> >
>> > -Tom
>> >
>> > > +radeon_get_drm_value(ws->fd, 0x20, NULL,
>> > > + &ws->info.max_compute_units);
>> > > +
>> > >  if (radeon_get_drm_value(ws->fd, RADEON_INFO_SI_TILE_MODE_ARRAY, 
>> > > NULL,
>> > >   ws->info.si_tile_mode_array)) {
>> > >  ws->info.si_tile_mode_array_valid = TRUE;
>> > > diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h 
>> > > b/src/gallium/winsys/radeon/drm/radeon_winsys.h
>> > > index 2d13550..6df1987 100644
>> > > --- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
>> > > +++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
>> > > @@ -198,6 +198,7 @@ struct radeon_info {
>> > >  uint32_tgart_size;
>> > >  uint32_tvram_size;
>> > >  uint32_tmax_sclk;
>> > > +uint32_tmax_compute_units;
>> > >
>> > >  uint32_tdrm_major; /* version */
>> > >  uint32_tdrm_minor;
>> > > --
>> > > 2.0.0
>> > >
>> >
>> > > ___
>> > > mesa-dev mailing list
>> > > mesa-dev@lists.freedes

Re: [Mesa-dev] [PATCH] Add GPU BLIT of texture image to PBO in Intel driver

[Jon Ashburn]

See v2 of patch sent to mesa-dev list in  early March:

http://lists.freedesktop.org/archives/mesa-dev/2014-March/055350.html

Or I can resend this v2 patch if needed.
Jon
On 06/10/2014 01:14 PM, Ian Romanick wrote:

On 02/24/2014 02:55 PM, Matt Turner wrote:

On Mon, Feb 24, 2014 at 2:04 PM, Jon Ashburn  wrote:

Add Intel driver hook for glGetTexImage to accelerate the case of reading
texture image into a PBO.  This case gets huge performance gains by using
GPU BLIT directly to PBO rather than GPU BLIT to temporary texture followed
by memcpy.

No regressions on Piglit tests  with Intel driver.

Patch summary should be prefixed with "i965:" and the commit message
should contain some performance data.

ping.

We're still waiting for the requested changes to the commit message...


___
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 0/7] r600g/compute: Some cleanup patches

[Tom Stellard]

On Mon, May 19, 2014 at 06:14:50PM +0200, Bruno Jiménez wrote:
> Hi,
> 
> Firstly, I shall introduce myself (at least more formally than just
> sending some patches). My name is Bruno Jiménez, I'm studying
> physics at Zaragoza's University (Spain) and I am participating in
> this year's Google Summer of Code, where I will try to improve
> the compute_memory_pool, solve an annoying bug related to mappings
> and anything else that I can do.
> 
> These patches are a little first cleanup. I sent the first five
> some time ago, but weren't pushed. The sixth fixes the alignment
> for items whose size is a multiple of 1024 dw and the last one
> corrects the format type of an unsigned.
> 

Thanks for the patches, I've pushed these.

-Tom

> Thanks!
> Bruno
> 
> Bruno Jiménez (7):
>   r600g/compute: Fixing a typo and some indentation
>   r600g/compute: Adding checks for NULL after CALLOC
>   r600g/compute: Add more NULL checks
>   r600g/compute: Tidy a bit compute_memory_finalize_pending
>   r600g/compute: Cleanup of compute_memory_pool.h
>   r600g/compute: align items correctly
>   r600g/compute: Use %u as the unsigned format
> 
>  src/gallium/drivers/r600/compute_memory_pool.c | 64 
> +-
>  src/gallium/drivers/r600/compute_memory_pool.h | 17 +--
>  src/gallium/drivers/r600/evergreen_compute.c   |  2 +-
>  3 files changed, 46 insertions(+), 37 deletions(-)
> 
> -- 
> 1.9.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/19] i965/fs: load_payload on Gen7+.

[Matt Turner]

On Wed, May 28, 2014 at 4:44 PM, Connor Abbott  wrote:
> On Tue, May 27, 2014 at 9:47 PM, Matt Turner  wrote:
>> Here's a respin of my load_payload series from mid-April with some
>> feedback from Ken addressed and some bugs fixed.
>>
>> This series is available in my tree (with a few unrelated patches
>> before it)
>>
>>git://people.freedesktop.org/~mattst88/mesa tex-sources
>>
>> This is a prep series for implementing SSA in the i965 fragment
>> shader backend.
>
> I wonder how SSA in the i965 backend will interact with my SSA in GLSL
> IR series?

I'm not really sure. Of course it'd be nice to not have a bunch of
similar code in src/glsl and the i965 driver.

I've got a bunch of patches on the cfg branch of my tree

 git://people.freedesktop.org/~mattst88/mesa cfg

that start implementing SSA in the fs backend. It's got code to create
the dominance tree and dominance frontier sets, to insert Phi nodes,
and to rename variables. I've also adapted my local value numbering
pass to operate globally, but of course it requires global code motion
to perform fix ups.

I haven't really started on translating out of SSA, because it's been
hard to get interested when performing register allocation from SSA
seems so appealing. That's obviously a sizeable amount of work.

Predication is another problem I need to handle. Gated SSA was
suggested to me as the best solution, with some other nice properties
that allow things like divergence analysis.

> I've recently re-started work on this after my school work
> started winding down, and as of now here are work items remaining I
> can think of:
>
> 1) Add unit tests for the conversion to SSA
> 2) Make the conversion out of SSA not suck as much, esp. with respect
> to writemasked operations (this is pretty difficult, as apparently
> it's still an unsolved problem that to my knowledge no one from
> academia has tried to tackle...)
> 3) Add some trivial SSA-based optimizations (dead code elimination,
> copy propagation)
> 4) Add more complicated optimizations like CSE, constant propagation,
> GVN-GCM... I believe some of these, especially value numbering, depend
> on a flat IR to work, so this might be a lot harder to do.
>
> I propose that I just do #1, post a new patch series with Paul's
> comments on the original one addressed (that would probably take less
> than a week), and then you can use the opt_to_ssa pass to avoid having
> to duplicate that logic that in the backend since it's pretty
> complicated. So it would look like:
>
> GLSL IR -> opt_to_ssa -> SSA-ified GLSL IR -> i965 fragment shader backend

That sounds good. I'd even settle for getting non-SSA GLSL IR in the
backend. I expect SSA GLSL IR will allow lots of our optimizations to
be more effective, and I've got a shader from a benchmark that I could
cut a pile of instructions out of if only it didn't unnecessarily
reuse a variable. SSA would totally fix that.

> We would have to modify the pass that scalarizes the GLSL IR to work
> with phi nodes and ir_quadop_vector expressions, but that wouldn't be
> too difficult. That way we would have an immediate user of the SSA
> stuff while being able to make it useful for everyone else in the long
> term.

Sure. Except I've written the to-SSA code already, and am lacking the
from-SSA equivalent. :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/9] glsl: Add C API to exec_node/exec_list.

[Ian Romanick]

On 06/10/2014 12:10 PM, Matt Turner wrote:
> On Tue, Jun 10, 2014 at 11:38 AM, Ian Romanick  wrote:
>> On 06/10/2014 11:00 AM, Matt Turner wrote:
>>> Our most frequently used list implementation was only usable from
>>> C by manipulating the members of the structs. This series adds a
>>> C API, wraps the C API with the C++ member functions (so no change
>>> for C++ code), makes the foreach_list macros usable from C, and
>>> replaces an open-coded list in the i965 driver with exec_list.
>>>
>>> The C API consists of static inline functions, and the C++ member
>>> functions are also marked inline.
>>
>> Before seeing this series, I would have sworn up and down that at least
>> the core list API as available from C.  It really did start life as a C
>> API, but in the C++ switch the C version must have been dropped for
>> "clarity."
> 
> Must have been before it was imported into git (commit 7e4ce719).

Yeah... the whole compiler used to live an a separate tree during early
development, and the current version is actually the second attempt.
The first attempt was entirely C.  Digging around through old trees...
it looks like list.h in the first attempt (November 2008) used #defines
for the list API, and the oldest commit in the second attempt (March
2010) had the current C++ API.  I'll blame old age for the failing memory.

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

Re: [Mesa-dev] [PATCH] Add GPU BLIT of texture image to PBO in Intel driver

[Ian Romanick]

On 06/10/2014 12:26 PM, Jon Ashburn wrote:
> See v2 of patch sent to mesa-dev list in  early March:
> 
> http://lists.freedesktop.org/archives/mesa-dev/2014-March/055350.html
> 
> Or I can resend this v2 patch if needed.

That's weird.  I have v1 in my inbox, but I don't have v2.  Anyway...

Other than a handful of whitespace issues, that patch looks okay to me.
 Matt?  Ken?

> Jon
> On 06/10/2014 01:14 PM, Ian Romanick wrote:
>> On 02/24/2014 02:55 PM, Matt Turner wrote:
>>> On Mon, Feb 24, 2014 at 2:04 PM, Jon Ashburn  wrote:
 Add Intel driver hook for glGetTexImage to accelerate the case of
 reading
 texture image into a PBO.  This case gets huge performance gains by
 using
 GPU BLIT directly to PBO rather than GPU BLIT to temporary texture
 followed
 by memcpy.

 No regressions on Piglit tests  with Intel driver.
>>> Patch summary should be prefixed with "i965:" and the commit message
>>> should contain some performance data.
>> ping.
>>
>> We're still waiting for the requested changes to the commit message...
>>
>>> ___
>>> 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] i965: Set the fast clear color value for texture surfaces

[Chris Forbes]

Reviewed-by: Chris Forbes 

On Wed, Jun 11, 2014 at 6:51 AM, Ian Romanick  wrote:
> On 06/09/2014 09:43 AM, Neil Roberts wrote:
>> When a multisampled texture is used for sampling the fast clear color value
>> needs to be programmed into the surface state. This was being left as all
>> zeroes so if the surface was cleared to a value other than black then it
>> wouldn't work properly. This doesn't matter for single-sample textures 
>> because
>> in that case the MCS buffer is resolved before it is used as a texture 
>> source.
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=79729
>
> This sounds believable.  We should get a R-b from one of the guys more
> familiar with the backend, but, FWIW,
>
> Reviewed-by: Ian Romanick 
> Cc: "10.1 10.2" 
>
> I expect this bug is reproducible on both 10.1.x and 10.2...
>
>> ---
>>  src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 4 +++-
>>  src/mesa/drivers/dri/i965/gen8_surface_state.c| 4 +++-
>>  2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c 
>> b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
>> index b31f491..12cdc2b 100644
>> --- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
>> +++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
>> @@ -337,6 +337,8 @@ gen7_update_texture_surface(struct gl_context *ctx,
>>/* mip count */
>>(intelObj->_MaxLevel - tObj->BaseLevel));
>>
>> +   surf[7] = mt->fast_clear_color_value;
>> +
>> if (brw->is_haswell) {
>>/* Handling GL_ALPHA as a surface format override breaks 1.30+ style
>> * texturing functions that return a float, as our code generation 
>> always
>> @@ -351,7 +353,7 @@ gen7_update_texture_surface(struct gl_context *ctx,
>>
>>const bool need_scs_green_to_blue = for_gather && tex_format == 
>> BRW_SURFACEFORMAT_R32G32_FLOAT_LD;
>>
>> -  surf[7] =
>> +  surf[7] |=
>>   SET_FIELD(brw_swizzle_to_scs(GET_SWZ(swizzle, 0), 
>> need_scs_green_to_blue), GEN7_SURFACE_SCS_R) |
>>   SET_FIELD(brw_swizzle_to_scs(GET_SWZ(swizzle, 1), 
>> need_scs_green_to_blue), GEN7_SURFACE_SCS_G) |
>>   SET_FIELD(brw_swizzle_to_scs(GET_SWZ(swizzle, 2), 
>> need_scs_green_to_blue), GEN7_SURFACE_SCS_B) |
>> diff --git a/src/mesa/drivers/dri/i965/gen8_surface_state.c 
>> b/src/mesa/drivers/dri/i965/gen8_surface_state.c
>> index 406f68e..80ac4f3 100644
>> --- a/src/mesa/drivers/dri/i965/gen8_surface_state.c
>> +++ b/src/mesa/drivers/dri/i965/gen8_surface_state.c
>> @@ -207,9 +207,11 @@ gen8_update_texture_surface(struct gl_context *ctx,
>>(firstImage->_BaseFormat == GL_DEPTH_COMPONENT ||
>> firstImage->_BaseFormat == GL_DEPTH_STENCIL);
>>
>> +   surf[7] = mt->fast_clear_color_value;
>> +
>> const int swizzle =
>>unlikely(alpha_depth) ? SWIZZLE_XYZW : brw_get_texture_swizzle(ctx, 
>> tObj);
>> -   surf[7] =
>> +   surf[7] |=
>>SET_FIELD(brw_swizzle_to_scs(GET_SWZ(swizzle, 0), false), 
>> GEN7_SURFACE_SCS_R) |
>>SET_FIELD(brw_swizzle_to_scs(GET_SWZ(swizzle, 1), false), 
>> GEN7_SURFACE_SCS_G) |
>>SET_FIELD(brw_swizzle_to_scs(GET_SWZ(swizzle, 2), false), 
>> GEN7_SURFACE_SCS_B) |
>>
>
> ___
> 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 4/8] draw/gs: fix segfault in glsl-1.50-gs-mismatch-prim-type triangles_adjacency

[Dave Airlie]

On 11 June 2014 00:02, Zack Rusin  wrote:
> That looks wrong.  The total number of verts per buffer is the maximum number 
> of verts that can be output per invocation (primitive_boundary) times number 
> of invocations of geometry shader (num_in_primitives).
>
> It's not maximum number of verts that can be output per invocation 
> (primitive_boundary) times maximum number of primitives output by geometry 
> shader (max_out_prims).
>

Okay so just adding * u_vertices_per_prim(shader->output_primitive);
would suffice?

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

Re: [Mesa-dev] [PATCH 4/8] draw/gs: fix segfault in glsl-1.50-gs-mismatch-prim-type triangles_adjacency

[Zack Rusin]

I think the code is already correct and something else goes wrong. The tgsi 
geometry shader code was never done properly so it's more than likely that 
tgsi_exec is doing something wonky.

Geometry shaders specify the maximum number of vertices that they can emit. 
That's what draw_geometry_shader::max_output_vertices is. If a geometry shader 
emits more than that, the verts will be ignored. So our primitive_boundary is 
max_output_vertices + 1  because we want to make sure that in SoA we have a 
scratch space where we can keep writing the overflowed vertices. 

So the worst case scenario for our output buffer is: (max_output_vertices + 1) 
* geometry shader invocations. That's what we have there now and that's 
correct. I don't remember what tgsi_exec does, I think I never even implemented 
proper SoA for gs in tgsi_exec, so if there's anything wrong I'd look for the 
bug there.

z

- Original Message -
> On 11 June 2014 00:02, Zack Rusin  wrote:
> > That looks wrong.  The total number of verts per buffer is the maximum
> > number of verts that can be output per invocation (primitive_boundary)
> > times number of invocations of geometry shader (num_in_primitives).
> >
> > It's not maximum number of verts that can be output per invocation
> > (primitive_boundary) times maximum number of primitives output by geometry
> > shader (max_out_prims).
> >
> 
> Okay so just adding * u_vertices_per_prim(shader->output_primitive);
> would suffice?
> 
> Dave
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Request for information on Radeon

[Aditya Avinash]

Hi,
Thank you very much!!

On Mon, Jun 9, 2014 at 10:19 AM, Marek Olšák  wrote:

> This is probably one of the most difficult tasks. You'll need to:
>
> 1) Add support to Mesa core - new shader stages and the new OpenGL
> functions and queries (src/mesa/main)
>

Ya. This one is straight forward. The added Tessellation stage should be
added to the OpenGL pipeline.


> 2) Add support to the GLSL compiler (src/glsl)
>

Ok!


> 3) Add support to the Gallium interface and TGSI
> (src/gallium/include/pipe) and supporting code (src/gallium/auxiliary)
>
>
Can you explain a bit more?


> 4) Add support to the Mesa state tracker (src/mesa/state_tracker),
> which translates everything from Mesa core and GLSL IR to Gallium and
> TGSI, respectively.
>

Ok!


> 5) Add support to either r600g or radeonsi. For radeonsi, implement
> the Gallium interface and program all the hardware registers
> correctly. On the shader side, add support to the TGSI->LLVM IR
> converter. (src/gallium/drivers/radeonsi) You might also need some
> small changes in the LLVM shader backend, not sure about that.
>
>
Ok!


> 6) Add a lot of of piglit tests.
>
> Ya!

> Marek
>
>
> On Sun, Jun 8, 2014 at 2:05 PM, Aditya Avinash 
> wrote:
> > Hi,
> > I was looking at RadeonFeature. It shows that Tessellation stage is
> "TODO".
> > What should I do to pick it? I am new to Mesa. Can you help me with some
> > documentation which is useful for me to accomplish the task?
> > Thank you!
> >
> > --
> > Regards,
> > Aditya Atluri.
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>

I have been reading about the Tessellation shader and proprietary OpenGL
API present at opengl extensions page.
Where should I get started?
Thank you very much.

-- 
Regards,

*Aditya Atluri,*

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

Re: [Mesa-dev] [PATCH 1/3] gallium: Add PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS

[Francisco Jerez]

Tom Stellard  writes:

> On Fri, May 30, 2014 at 05:31:10PM +0200, Bruno Jiménez wrote:
>> ---
>>  src/gallium/docs/source/screen.rst   | 2 ++
>>  src/gallium/include/pipe/p_defines.h | 3 ++-
>>  2 files changed, 4 insertions(+), 1 deletion(-)
>
> Reviewed-by: Tom Stellard 
>

Reviewed-by: Francisco Jerez 

>> 
>> diff --git a/src/gallium/docs/source/screen.rst 
>> b/src/gallium/docs/source/screen.rst
>> index b292257..dde2c38 100644
>> --- a/src/gallium/docs/source/screen.rst
>> +++ b/src/gallium/docs/source/screen.rst
>> @@ -317,6 +317,8 @@ pipe_screen::get_compute_param.
>>allocation in bytes.  Value type: ``uint64_t``.
>>  * ``PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY``: Maximum frequency of the GPU
>>clock in MHz. Value type: ``uint32_t``
>> +* ``PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS``: Maximum number of compute units
>> +  Value type: ``uint32_t``
>>  
>>  .. _pipe_bind:
>>  
>> diff --git a/src/gallium/include/pipe/p_defines.h 
>> b/src/gallium/include/pipe/p_defines.h
>> index 4024470..5572bb6 100644
>> --- a/src/gallium/include/pipe/p_defines.h
>> +++ b/src/gallium/include/pipe/p_defines.h
>> @@ -644,7 +644,8 @@ enum pipe_compute_cap
>> PIPE_COMPUTE_CAP_MAX_PRIVATE_SIZE,
>> PIPE_COMPUTE_CAP_MAX_INPUT_SIZE,
>> PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE,
>> -   PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY
>> +   PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY,
>> +   PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS
>>  };
>>  
>>  /**
>> -- 
>> 1.9.3
>> 
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


pgpdvpFl90ezO.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 3/3] clover: query driver for the max number of compute units

[Francisco Jerez]

Tom Stellard  writes:

> On Fri, May 30, 2014 at 05:31:12PM +0200, Bruno Jiménez wrote:
>
> Reviewed-by: Tom Stellard 

Reviewed-by: Francisco Jerez 

>
>> ---
>>  src/gallium/state_trackers/clover/api/device.cpp  | 2 +-
>>  src/gallium/state_trackers/clover/core/device.cpp | 6 ++
>>  src/gallium/state_trackers/clover/core/device.hpp | 1 +
>>  3 files changed, 8 insertions(+), 1 deletion(-)
>> 
>> diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
>> b/src/gallium/state_trackers/clover/api/device.cpp
>> index 1bc2692..97b2cf9 100644
>> --- a/src/gallium/state_trackers/clover/api/device.cpp
>> +++ b/src/gallium/state_trackers/clover/api/device.cpp
>> @@ -109,7 +109,7 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
>>break;
>>  
>> case CL_DEVICE_MAX_COMPUTE_UNITS:
>> -  buf.as_scalar() = 1;
>> +  buf.as_scalar() = dev.max_compute_units();
>>break;
>>  
>> case CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS:
>> diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
>> b/src/gallium/state_trackers/clover/core/device.cpp
>> index bc3e3e6..b6078db 100644
>> --- a/src/gallium/state_trackers/clover/core/device.cpp
>> +++ b/src/gallium/state_trackers/clover/core/device.cpp
>> @@ -163,6 +163,12 @@ device::max_clock_frequency() const {
>>
>> PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY)[0];
>>  }
>>  
>> +cl_uint
>> +device::max_compute_units() const {
>> +   return get_compute_param(pipe,
>> +  
>> PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS)[0];
>> +}
>> +
>>  std::vector
>>  device::max_block_size() const {
>> auto v = get_compute_param(pipe, 
>> PIPE_COMPUTE_CAP_MAX_BLOCK_SIZE);
>> diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
>> b/src/gallium/state_trackers/clover/core/device.hpp
>> index 3662c6b..731c31e 100644
>> --- a/src/gallium/state_trackers/clover/core/device.hpp
>> +++ b/src/gallium/state_trackers/clover/core/device.hpp
>> @@ -62,6 +62,7 @@ namespace clover {
>>size_t max_threads_per_block() const;
>>cl_ulong max_mem_alloc_size() const;
>>cl_uint max_clock_frequency() const;
>> +  cl_uint max_compute_units() const;
>>  
>>std::vector max_block_size() const;
>>std::string device_name() const;
>> -- 
>> 1.9.3
>> 
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 2/3] radeon/compute: Implement PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS

[Marek Olšák]

Well, we could just pull radeon_drm.h into Mesa to simplify
the process since libdrm_radeon doesn't really need the updated
header anymore.

Marek

On Tue, Jun 10, 2014 at 9:25 PM, Alex Deucher  wrote:
> On Tue, Jun 10, 2014 at 3:23 PM, Tom Stellard  wrote:
>> On Tue, Jun 10, 2014 at 08:36:05PM +0200, Bruno Jimenez wrote:
>>> On Tue, 2014-06-10 at 14:10 -0400, Tom Stellard wrote:
>>> > On Thu, Jun 05, 2014 at 08:39:29PM +0200, Bruno Jimenez wrote:
>>> > >
>>> > > With a couple of changes, it applied cleanly to 3.14.5 (Arch's stable).
>>> > > And with the attached patch as #2 for my series I can get the correct
>>> > > number of compute units for my CEDAR.
>>> > >
>>> > > But I don't know how or where I should add this new query param, given
>>> > > that it hasn't been added to the kernel yet. For now I have hardcoded
>>> > > the '0x20'.
>>> > >
>>> > > Thanks for all Alex!
>>> > > Bruno
>>> > >
>>> > >
>>> >
>>> > > From d2f37842171fdaff2a31d756c15479fc56646153 Mon Sep 17 00:00:00 2001
>>> > > From: =?UTF-8?q?Bruno=20Jim=C3=A9nez?= 
>>> > > Date: Thu, 5 Jun 2014 20:01:56 +0200
>>> > > Subject: [PATCH 2/3] radeon/compute: Implement
>>> > >  PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS
>>> > >
>>> > > ---
>>> > >  src/gallium/drivers/radeon/r600_pipe_common.c | 7 +++
>>> > >  src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 4 
>>> > >  src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
>>> > >  3 files changed, 12 insertions(+)
>>> > >
>>> > > diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
>>> > > b/src/gallium/drivers/radeon/r600_pipe_common.c
>>> > > index 70c4d1a..e7d33a0 100644
>>> > > --- a/src/gallium/drivers/radeon/r600_pipe_common.c
>>> > > +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
>>> > > @@ -519,6 +519,13 @@ static int r600_get_compute_param(struct 
>>> > > pipe_screen *screen,
>>> > >   }
>>> > >   return sizeof(uint32_t);
>>> > >
>>> > > + case PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS:
>>> > > + if (ret) {
>>> > > + uint32_t *max_compute_units = ret;
>>> > > + *max_compute_units = rscreen->info.max_compute_units;
>>> > > + }
>>> > > + return sizeof(uint32_t);
>>> > > +
>>> > >   default:
>>> > >   fprintf(stderr, "unknown PIPE_COMPUTE_CAP %d\n", param);
>>> > >   return 0;
>>> > > diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c 
>>> > > b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>> > > index e54e79e..124f6fa 100644
>>> > > --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>> > > +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>> > > @@ -382,6 +382,10 @@ static boolean do_winsys_init(struct 
>>> > > radeon_drm_winsys *ws)
>>> > >  radeon_get_drm_value(ws->fd, RADEON_INFO_MAX_PIPES, NULL,
>>> > >   &ws->info.r600_max_pipes);
>>> > >
>>> > > +/* RADEON_INFO_ACTIVE_CU_COUNT == 0x20 */
>>> >
>>> > This should be a define at the top of the file, just like we do with the
>>> > other RADEON_INFO_* values.
>>>
>>> Hi,
>>>
>>> This was a bit of a proof of concept that we could do the query and that
>>> it worked.
>>>
>>> I'm afraid that the other RADEON_INFO_* values were removed with this
>>> commit:
>>>
>>> commit 34564c875357a5d0a1f103f29949eafc2f8e1b35
>>> Author: Marek Olšák 
>>> Date:   Fri Apr 4 20:18:37 2014 +0200
>>>
>>> winsys/radeon: remove definitions already present in radeon_drm.h
>>>
>>> Reviewed-by: Michel Dänzer 
>>> Reviewed-by: Christian König 
>>>
>>> Also, I have seen this morning that the corresponding kernel patch has
>>> been proposed for kernel 3.16:
>>> http://lists.freedesktop.org/archives/dri-devel/2014-June/061483.html
>>> So we really won't be able to do this query until this patch lands.
>>>
>>> Anyway, I will change the patch so that RADEON_INFO_ACTIVE_CU_COUNT is
>>> at the top of the file as proposed.
>>>
>>
>> Thanks, you should also add this same define to libdrm:
>> include/drm/radeon_drm.h
>
> Wait until the kernel is released before pulling the latest
> radeon_drm.h into libdrm.
>
> Alex
>
>>
>> -Tom
>>
>>> Thanks!
>>> Bruno
>>>
>>> >
>>> > -Tom
>>> >
>>> > > +radeon_get_drm_value(ws->fd, 0x20, NULL,
>>> > > + &ws->info.max_compute_units);
>>> > > +
>>> > >  if (radeon_get_drm_value(ws->fd, RADEON_INFO_SI_TILE_MODE_ARRAY, 
>>> > > NULL,
>>> > >   ws->info.si_tile_mode_array)) {
>>> > >  ws->info.si_tile_mode_array_valid = TRUE;
>>> > > diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h 
>>> > > b/src/gallium/winsys/radeon/drm/radeon_winsys.h
>>> > > index 2d13550..6df1987 100644
>>> > > --- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
>>> > > +++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
>>> > > @@ -198,6 +198,7 @@ struct radeon_info {
>>> > >  uint32_tgart_size;
>>> > >  uint32_tvram_size;
>>> > >  uint32_tmax_sclk;

Re: [Mesa-dev] [PATCH 4/8] draw/gs: fix segfault in glsl-1.50-gs-mismatch-prim-type triangles_adjacency

[Dave Airlie]

On 11 June 2014 06:23, Zack Rusin  wrote:
> I think the code is already correct and something else goes wrong. The tgsi 
> geometry shader code was never done properly so it's more than likely that 
> tgsi_exec is doing something wonky.
>
> Geometry shaders specify the maximum number of vertices that they can emit. 
> That's what draw_geometry_shader::max_output_vertices is. If a geometry 
> shader emits more than that, the verts will be ignored. So our 
> primitive_boundary is max_output_vertices + 1  because we want to make sure 
> that in SoA we have a scratch space where we can keep writing the overflowed 
> vertices.
>
> So the worst case scenario for our output buffer is: (max_output_vertices + 
> 1) * geometry shader invocations. That's what we have there now and that's 
> correct. I don't remember what tgsi_exec does, I think I never even 
> implemented proper SoA for gs in tgsi_exec, so if there's anything wrong I'd 
> look for the bug there.
>

Well the main difference is the vector_length is 1 for TGSI, and 4 for
LLVM, this seems to cover over the problem I've seen here,

I'll revisit it today and see if I can spot something else wrong, it
fails for triangle adj because there are 6 vertices per primitive and
we have only malloced space for 4.

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

Re: [Mesa-dev] Request for information on Radeon

[Chris Forbes]

For the first two points, a partial implementation is already done here:

https://github.com/fabe3k/mesa/commits/tessellation

This predates the addition of ARB_separate_shader_objects, which has
some interactions. There are probably also plenty of rough edges, but
it should give you enough to get started with the gallium/tgsi parts.

On Wed, Jun 11, 2014 at 8:45 AM, Aditya Avinash
 wrote:
> Hi,
> Thank you very much!!
>
> On Mon, Jun 9, 2014 at 10:19 AM, Marek Olšák  wrote:
>>
>> This is probably one of the most difficult tasks. You'll need to:
>>
>> 1) Add support to Mesa core - new shader stages and the new OpenGL
>> functions and queries (src/mesa/main)
>
>
> Ya. This one is straight forward. The added Tessellation stage should be
> added to the OpenGL pipeline.
>
>>
>> 2) Add support to the GLSL compiler (src/glsl)
>
>
> Ok!
>
>>
>> 3) Add support to the Gallium interface and TGSI
>> (src/gallium/include/pipe) and supporting code (src/gallium/auxiliary)
>>
>
> Can you explain a bit more?
>
>>
>> 4) Add support to the Mesa state tracker (src/mesa/state_tracker),
>> which translates everything from Mesa core and GLSL IR to Gallium and
>> TGSI, respectively.
>
>
> Ok!
>
>>
>> 5) Add support to either r600g or radeonsi. For radeonsi, implement
>> the Gallium interface and program all the hardware registers
>> correctly. On the shader side, add support to the TGSI->LLVM IR
>> converter. (src/gallium/drivers/radeonsi) You might also need some
>> small changes in the LLVM shader backend, not sure about that.
>>
>
> Ok!
>
>>
>> 6) Add a lot of of piglit tests.
>>
> Ya!
>>
>> Marek
>>
>>
>> On Sun, Jun 8, 2014 at 2:05 PM, Aditya Avinash 
>> wrote:
>> > Hi,
>> > I was looking at RadeonFeature. It shows that Tessellation stage is
>> > "TODO".
>> > What should I do to pick it? I am new to Mesa. Can you help me with some
>> > documentation which is useful for me to accomplish the task?
>> > Thank you!
>> >
>> > --
>> > Regards,
>> > Aditya Atluri.
>> >
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> >
>
>
> I have been reading about the Tessellation shader and proprietary OpenGL API
> present at opengl extensions page.
> Where should I get started?
> Thank you very much.
>
> --
> Regards,
> Aditya Atluri,
> USA.
>
>
> ___
> 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] Request for information on Radeon

[Aditya Avinash]

Hi,


On Tue, Jun 10, 2014 at 5:06 PM, Chris Forbes  wrote:

> For the first two points, a partial implementation is already done here:
>
> https://github.com/fabe3k/mesa/commits/tessellation
>
> This predates the addition of ARB_separate_shader_objects, which has
> some interactions. There are probably also plenty of rough edges, but
> it should give you enough to get started with the gallium/tgsi parts.
>

Thank you very much! Is there any documentation available or irc logs where
I can get more information? As, the code is less commented.
Thank you!


> On Wed, Jun 11, 2014 at 8:45 AM, Aditya Avinash
>  wrote:
> > Hi,
> > Thank you very much!!
> >
> > On Mon, Jun 9, 2014 at 10:19 AM, Marek Olšák  wrote:
> >>
> >> This is probably one of the most difficult tasks. You'll need to:
> >>
> >> 1) Add support to Mesa core - new shader stages and the new OpenGL
> >> functions and queries (src/mesa/main)
> >
> >
> > Ya. This one is straight forward. The added Tessellation stage should be
> > added to the OpenGL pipeline.
> >
> >>
> >> 2) Add support to the GLSL compiler (src/glsl)
> >
> >
> > Ok!
> >
> >>
> >> 3) Add support to the Gallium interface and TGSI
> >> (src/gallium/include/pipe) and supporting code (src/gallium/auxiliary)
> >>
> >
> > Can you explain a bit more?
> >
> >>
> >> 4) Add support to the Mesa state tracker (src/mesa/state_tracker),
> >> which translates everything from Mesa core and GLSL IR to Gallium and
> >> TGSI, respectively.
> >
> >
> > Ok!
> >
> >>
> >> 5) Add support to either r600g or radeonsi. For radeonsi, implement
> >> the Gallium interface and program all the hardware registers
> >> correctly. On the shader side, add support to the TGSI->LLVM IR
> >> converter. (src/gallium/drivers/radeonsi) You might also need some
> >> small changes in the LLVM shader backend, not sure about that.
> >>
> >
> > Ok!
> >
> >>
> >> 6) Add a lot of of piglit tests.
> >>
> > Ya!
> >>
> >> Marek
> >>
> >>
> >> On Sun, Jun 8, 2014 at 2:05 PM, Aditya Avinash <
> adityaavina...@gmail.com>
> >> wrote:
> >> > Hi,
> >> > I was looking at RadeonFeature. It shows that Tessellation stage is
> >> > "TODO".
> >> > What should I do to pick it? I am new to Mesa. Can you help me with
> some
> >> > documentation which is useful for me to accomplish the task?
> >> > Thank you!
> >> >
> >> > --
> >> > Regards,
> >> > Aditya Atluri.
> >> >
> >> > ___
> >> > mesa-dev mailing list
> >> > mesa-dev@lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >> >
> >
> >
> > I have been reading about the Tessellation shader and proprietary OpenGL
> API
> > present at opengl extensions page.
> > Where should I get started?
> > Thank you very much.
> >
> > --
> > Regards,
> > Aditya Atluri,
> > USA.
> >
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>



-- 
Regards,

*Aditya Atluri,*

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

Re: [Mesa-dev] Request for information on Radeon

[Marek Olšák]

On Tue, Jun 10, 2014 at 10:45 PM, Aditya Avinash
 wrote:
> Hi,
> Thank you very much!!
>
> On Mon, Jun 9, 2014 at 10:19 AM, Marek Olšák  wrote:
>>
>> This is probably one of the most difficult tasks. You'll need to:
>>
>> 1) Add support to Mesa core - new shader stages and the new OpenGL
>> functions and queries (src/mesa/main)
>
>
> Ya. This one is straight forward. The added Tessellation stage should be
> added to the OpenGL pipeline.
>
>>
>> 2) Add support to the GLSL compiler (src/glsl)
>
>
> Ok!
>
>>
>> 3) Add support to the Gallium interface and TGSI
>> (src/gallium/include/pipe) and supporting code (src/gallium/auxiliary)
>>
>
> Can you explain a bit more?

Gallium is not just a driver interface, it's a full and self-contained
3D API like OpenGL and Direct3D. It looks a lot like Direct3D 11, so
following its design is usually a good idea, but not required.

The supporting code is at least:
- TGSI generating and parsing
- u_blitter, which should disable tessellation for all its operations
- some state tracking in cso_context, which you'll need for st/mesa

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

Re: [Mesa-dev] [PATCH 00/11] glsl: Remove unused includes found with IWYU

[Thomas Helland]

Thanks for the review!

These patches, along with 5 more I've put together,
don't have any significant impact on compile time.
But that's only 16 files, so it really shouldn't be expected I guess.
A similar effort on firefox gave a 12.5% compile-time improvement though,
so eventually we should be seeing some effects. [1]

Where I do see an impact though is recompiling after changes.
Less object-files needs to be recompiled, so it's often a lot faster.
I don't have any specific numbers here though.

I see that I've managed to get a "From: " line in my mails,
and sender is not showing up correctly in the mailing-list.
Anyone git-savvy who've had similar problems?
If not I'll delve into the dark caves of man-pages and read up.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=903816


2014-06-10 19:58 GMT+02:00 Tom Stellard :

> On Tue, Jun 10, 2014 at 12:57:31AM +0200, thomashellan...@gmail.com wrote:
> > From: Thomas Helland 
> >
>
> For the series:
>
> Reviewed-by: Tom Stellard 
>
> Do these patches make any measurable improvement in compile time?
>
> -Tom
> > This series removes some unused includes in the glsl-directory.
> > These were found with Google's include-what-you-use plugin for clang.
> > Patches have been compile-tested and a quick glxgears-run has been done.
> > I have not done a full piglit-run, let me know if that's wanted.
> >
> > Oh, and excuse me if I've messed up something.
> > First run with git and mailing-lists, so lots to learn.
> >
> > Thomas Helland (11):
> >   glsl: Remove unused includes in link_uniform_init.
> >   glsl: Remove unused includes in link_uniform_block_active_visitor.h
> >   glsl: Remove unused include in ast_to_hir.cpp
> >   glsl: Remove unused include from builtin_variables.cpp
> >   glsl: Remove unused include from glsl_types.cpp
> >   glsl: Remove unused include from glsl_symbol_table.h
> >   glsl: Remove unused include from hir_field_selection.cpp
> >   glsl: Remove unused include from ir_basic_block.cpp
> >   glsl: Remove unused include from ir_constant_expression.cpp
> >   glsl: Remove unused include in ir.cpp
> >   glsl: Remove unused include in expr.flatt.
> >
> >  src/glsl/ast_to_hir.cpp  | 1 -
> >  src/glsl/builtin_variables.cpp   | 1 -
> >  src/glsl/glsl_symbol_table.h | 2 +-
> >  src/glsl/glsl_types.cpp  | 4 +---
> >  src/glsl/hir_field_selection.cpp | 1 -
> >  src/glsl/ir.cpp  | 1 -
> >  src/glsl/ir_basic_block.cpp  | 2 --
> >  src/glsl/ir_constant_expression.cpp  | 1 -
> >  src/glsl/ir_expression_flattening.cpp| 2 --
> >  src/glsl/link_uniform_block_active_visitor.h | 2 --
> >  src/glsl/link_uniform_initializers.cpp   | 2 --
> >  11 files changed, 2 insertions(+), 17 deletions(-)
> >
> > --
> > 2.0.0
> >
> > ___
> > 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 00/11] glsl: Remove unused includes found with IWYU

[Matt Turner]

On Tue, Jun 10, 2014 at 3:39 PM, Thomas Helland
 wrote:
> Where I do see an impact though is recompiling after changes.
> Less object-files needs to be recompiled, so it's often a lot faster.
> I don't have any specific numbers here though.

Oh, that's a good point that I hadn't considered. Thanks!

> I see that I've managed to get a "From: " line in my mails,
> and sender is not showing up correctly in the mailing-list.
> Anyone git-savvy who've had similar problems?
> If not I'll delve into the dark caves of man-pages and read up.

I think you need to set your username and email in ~/.gitconfig. Mine
looks like:

[user]
 email = matts...@gmail.com
 name = Matt Turner

There's a git config tool to handle this, but I never remember the
syntax, so I just edit the file.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: remove unnecessary and incorrect check

[Timothy Arceri]

This code does nothing useful as the next recursive call on the array element 
will override any null values if the element is a record anyway. The code is 
also not doing what the comment says as its trying to set the record type 
pointer for only the first element of the array not the first leaf field of the 
record.

Signed-off-by: Timothy Arceri 
---
 src/glsl/link_uniforms.cpp | 8 
 1 file changed, 8 deletions(-)

diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index ba66053..9566124 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -187,9 +187,6 @@ program_resource_visitor::recursion(const glsl_type *t, 
char **name,
   }
} else if (t->is_array() && (t->fields.array->is_record()
 || t->fields.array->is_interface())) {
-  if (record_type == NULL && t->fields.array->is_record())
- record_type = t->fields.array;
-
   for (unsigned i = 0; i < t->length; i++) {
 size_t new_length = name_length;
 
@@ -198,11 +195,6 @@ program_resource_visitor::recursion(const glsl_type *t, 
char **name,
 
  recursion(t->fields.array, name, new_length, row_major,
record_type);
-
- /* Only the first leaf-field of the record gets called with the
-  * record type pointer.
-  */
- record_type = NULL;
   }
} else {
   this->visit_field(t, *name, row_major, record_type);
-- 
1.9.3

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

Re: [Mesa-dev] [PATCH 00/11] glsl: Remove unused includes found with IWYU

[Brian Paul]

On 06/10/2014 04:39 PM, Thomas Helland wrote:

Thanks for the review!

These patches, along with 5 more I've put together,
don't have any significant impact on compile time.
But that's only 16 files, so it really shouldn't be expected I guess.
A similar effort on firefox gave a 12.5% compile-time improvement though,
so eventually we should be seeing some effects. [1]

Where I do see an impact though is recompiling after changes.
Less object-files needs to be recompiled, so it's often a lot faster.
I don't have any specific numbers here though.
[...]
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=903816



As a side-note, one of the documents about Go talks about C/C++ header 
file inefficiencies:

http://talks.golang.org/2012/splash.article#TOC_5.

It's pretty sobering.

-Brian

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

[Mesa-dev] [PATCH] i965/fs: Copy propagate from load_payload.

[Matt Turner]

---
I'm planning to squash this in to make Abdiel's patches easier
to merge.

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

diff --git a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
index ee601c7..cc6e86f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
@@ -42,7 +42,7 @@ namespace { /* avoid conflict with 
opt_copy_propagation_elements */
 struct acp_entry : public exec_node {
fs_reg dst;
fs_reg src;
-   bool is_from_load_payload;
+   enum opcode opcode;
 };
 
 struct block_data {
@@ -288,7 +288,7 @@ fs_visitor::try_copy_propagate(fs_inst *inst, int arg, 
acp_entry *entry)
if (entry->src.file == IMM)
   return false;
 
-   if (entry->is_from_load_payload &&
+   if (entry->opcode == SHADER_OPCODE_LOAD_PAYLOAD &&
inst->opcode == SHADER_OPCODE_LOAD_PAYLOAD)
   return false;
 
@@ -574,7 +574,7 @@ fs_visitor::opt_copy_propagate_local(void *copy_prop_ctx, 
bblock_t *block,
 acp_entry *entry = ralloc(copy_prop_ctx, acp_entry);
 entry->dst = inst->dst;
 entry->src = inst->src[0];
- entry->is_from_load_payload = false;
+ entry->opcode = inst->opcode;
 acp[entry->dst.reg % ACP_HASH_SIZE].push_tail(entry);
   } else if (inst->opcode == SHADER_OPCODE_LOAD_PAYLOAD &&
  inst->dst.file == GRF) {
@@ -584,7 +584,7 @@ fs_visitor::opt_copy_propagate_local(void *copy_prop_ctx, 
bblock_t *block,
entry->dst = inst->dst;
entry->dst.reg_offset = i;
entry->src = inst->src[i];
-   entry->is_from_load_payload = true;
+   entry->opcode = inst->opcode;
if (!entry->dst.equals(inst->src[i])) {
   acp[entry->dst.reg % ACP_HASH_SIZE].push_tail(entry);
} else {
-- 
1.8.3.2

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

Re: [Mesa-dev] [PATCH 15/19] i965/fs: Support register coalescing on LOAD_PAYLOAD operands.

[Matt Turner]

On Sun, Jun 1, 2014 at 12:01 AM, Kenneth Graunke  wrote:
> On Friday, April 18, 2014 11:56:51 AM Matt Turner wrote:
>> ---
>>  .../drivers/dri/i965/brw_fs_register_coalesce.cpp  | 59
> ++
>>  1 file changed, 49 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
>> index cb4ab57..a363c4c 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
>> @@ -46,7 +46,14 @@
>>  static bool
>>  is_nop_mov(const fs_inst *inst)
>>  {
>> -   if (inst->opcode == BRW_OPCODE_MOV) {
>> +   if (inst->opcode == SHADER_OPCODE_LOAD_PAYLOAD) {
>> +  for (int i = 0; i < inst->sources; i++) {
>> + if (!inst->dst.equals(inst->src[i])) {
>
> I don't think this is what you want.  You're not altering dst.reg_offset,
> here, so dst.reg_offset will presumably always be 0.
>
> For dst.equals(inst->src[i]) to be true for every source, then
>
>dst.reg == src[i].reg for all sources.
>dst.reg_offset == src[i].reg_offset for all sources.
>
> which means src[i].reg_offset == 0 for all sources.

Right, will fix.

> In other words, I think this detects LOAD_PAYLOAD operations that splats the
> first component of a size > 1 VGRF dst to all components.
>
> That's definitely not a nop mov.
>
> I think if you add dst.reg_offset++ on each iteration of the loop, you'll be
> okay here.
>
>> +return false;
>> + }
>> +  }
>> +  return true;
>> +   } else if (inst->opcode == BRW_OPCODE_MOV) {
>>return inst->dst.equals(inst->src[0]);
>> }
>>
>> @@ -54,9 +61,26 @@ is_nop_mov(const fs_inst *inst)
>>  }
>>
>>  static bool
>> +is_copy_payload(const fs_inst *inst)
>> +{
>> +   const int reg = inst->src[0].reg;
>> +   if (inst->src[0].reg_offset != 0)
>> +  return false;
>
> This looks okay, for both src[0] == reg_undef and where it's an actual value.
>
>> +
>> +   for (int i = 1; i < inst->sources; i++) {
>> +  if (inst->src[i].reg != reg ||
>> +  inst->src[i].reg_offset != i) {
>> + return false;
>> +  }
>> +   }
>> +   return true;
>> +}
>> +
>> +static bool
>>  is_coalesce_candidate(const fs_inst *inst, const int *virtual_grf_sizes)
>>  {
>> -   if (inst->opcode != BRW_OPCODE_MOV ||
>> +   if ((inst->opcode != BRW_OPCODE_MOV &&
>> +inst->opcode != SHADER_OPCODE_LOAD_PAYLOAD) ||
>> inst->is_partial_write() ||
>> inst->saturate ||
>> inst->src[0].file != GRF ||
>> @@ -72,6 +96,12 @@ is_coalesce_candidate(const fs_inst *inst, const int
> *virtual_grf_sizes)
>> virtual_grf_sizes[inst->dst.reg])
>>return false;
>>
>> +   if (inst->opcode == SHADER_OPCODE_LOAD_PAYLOAD) {
>> +  if (!is_copy_payload(inst)) {
>> + return false;
>> +  }
>> +   }
>> +
>> return true;
>>  }
>>
>> @@ -144,10 +174,18 @@ fs_visitor::register_coalesce()
>>if (reg_to != inst->dst.reg)
>>   continue;
>>
>> -  const int offset = inst->src[0].reg_offset;
>> -  reg_to_offset[offset] = inst->dst.reg_offset;
>> -  mov[offset] = inst;
>> -  channels_remaining--;
>> +  if (inst->opcode == SHADER_OPCODE_LOAD_PAYLOAD) {
>> + for (int i = 0; i < src_size; i++) {
>
> Isn't src_size always 1 for LOAD_PAYLOAD?  Earlier:
>
>  src_size = virtual_grf_sizes[inst->src[0].reg];

No, since inst->src[0].reg is just the number of the virtual register
(doesn't include the offset) and virtual_grf_sizes[] contains virtual
register sizes.

> Presumably you want inst->sources here...

I think you touched on something. is_copy_payload would say "true" to
a load_payload instruction that copied the first three components of a
size 4 vgrf. But here we actually do want the number of sources. Since
returning true for this doesn't seem useful, I'll add a check to
is_copy_payload to return false if the number of sources doesn't match
the size of the vgrf.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965/fs: Support register coalescing on LOAD_PAYLOAD operands.

[Matt Turner]

---
I'm planning to squash this in to address review comments.

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

diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
index 0aa4b3e..a740c58 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
@@ -47,8 +47,10 @@ static bool
 is_nop_mov(const fs_inst *inst)
 {
if (inst->opcode == SHADER_OPCODE_LOAD_PAYLOAD) {
+  fs_reg dst = inst->dst;
   for (int i = 0; i < inst->sources; i++) {
- if (!inst->dst.equals(inst->src[i])) {
+ dst.reg_offset = i;
+ if (!dst.equals(inst->src[i])) {
 return false;
  }
   }
@@ -61,8 +63,11 @@ is_nop_mov(const fs_inst *inst)
 }
 
 static bool
-is_copy_payload(const fs_inst *inst)
+is_copy_payload(const fs_inst *inst, int src_size)
 {
+   if (src_size != inst->sources)
+  return false;
+
const int reg = inst->src[0].reg;
if (inst->src[0].reg_offset != 0)
   return false;
@@ -97,7 +102,7 @@ is_coalesce_candidate(const fs_inst *inst, const int 
*virtual_grf_sizes)
   return false;
 
if (inst->opcode == SHADER_OPCODE_LOAD_PAYLOAD) {
-  if (!is_copy_payload(inst)) {
+  if (!is_copy_payload(inst, virtual_grf_sizes[inst->src[0].reg])) {
  return false;
   }
}
-- 
1.8.3.2

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

Re: [Mesa-dev] [PATCH 00/19] i965/fs: load_payload on Gen7+.

[Matt Turner]

On Tue, May 27, 2014 at 6:47 PM, Matt Turner  wrote:
> Here's a respin of my load_payload series from mid-April with some
> feedback from Ken addressed and some bugs fixed.
>
>git://people.freedesktop.org/~mattst88/mesa tex-sources

I've force pushed an updated and rebased branch.

> I'd really like to get some R-b tags this time around, since this
> series is necessary for the SSA work I've been anxious to get back to
> for a while.
>
> i965/fs: Add and use an fs_inst copy constructor.
> i965/fs: Disable fs_inst assignment operator.
> i965/fs: ralloc fs_inst's fs_reg sources.
> i965/fs: Store the number of sources an fs_inst has.
> i965/fs: Loop from 0 to inst->sources, not 0 to 3.
> i965/fs: Clean up fs_inst constructors.
> i965/fs: Add a function to resize fs_inst's sources
> i965/fs: Add fs_inst constructor that takes a list of

These were reviewed and committed.

> i965/fs: Add SHADER_OPCODE_LOAD_PAYLOAD.

This has a review.

> i965/fs: Lower LOAD_PAYLOAD and clean up.
> i965/fs: Use LOAD_PAYLOAD in emit_texture_gen7().
> i965/fs: Apply cube map array fixup and restore the
> i965/fs: Only consider real sources when comparing
> i965/fs: Emit load_payload instead of multiple MOVs for
> i965/fs: Support register coalescing on LOAD_PAYLOAD
> i965/fs: Perform CSE on load_payload instructions if
> i965/fs: Copy propagate from load_payload.

These are missing reviews. I've made some small changes in response to
some comments and mailed some fixups that will be squashed into their
respective patches. I'd really like to get this stuff committed.
Should I hope and wait for more review? Resend the whole set of
unreviewed patches?

> i965/fs: Perform CSE on texture operations.
> i965/fs: Optimize SEL with the same sources into a MOV.

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

[Mesa-dev] [PATCH] glsl: Rebalance expression trees that are reduction operations.

[Matt Turner]

---
Easiest thing for now seems to be to bail if we see these
kinds of dereferences. I'll squash this in, adding a description
of the things we don't handle.

 src/glsl/opt_rebalance_tree.cpp | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/src/glsl/opt_rebalance_tree.cpp b/src/glsl/opt_rebalance_tree.cpp
index 5866a60..773aab3 100644
--- a/src/glsl/opt_rebalance_tree.cpp
+++ b/src/glsl/opt_rebalance_tree.cpp
@@ -167,6 +167,19 @@ is_reduction_operation(ir_expression_operation operation)
 
 /* Note that this function does not attempt to recognize that reduction trees
  * are already balanced.
+ *
+ * We return false from this function for a number of reasons other than an
+ * expression tree not being a mathematical reduction. Namely,
+ *
+ *- if the tree contains multiple constants that we may be able to combine.
+ *- if the tree contains matrices:
+ *   - they might contain vec4's with many constant components that we can
+ * simplify after splitting.
+ *   - applying the matrix chain ordering optimization is more than just
+ * balancing an expression tree.
+ *- if the tree contains operations on multiple types.
+ *- if the tree contains ir_dereference_{array,record}, since foo[a+b] + c
+ *  would trick the visiting pass.
  */
 static void
 is_reduction(ir_instruction *ir, void *data)
@@ -186,6 +199,15 @@ is_reduction(ir_instruction *ir, void *data)
   return;
}
 
+   /* Array/record dereferences have subtrees that are not part of the expr
+* tree we're balancing. Skip trees containing them.
+*/
+   if (ir->ir_type == ir_type_dereference_array ||
+   ir->ir_type == ir_type_dereference_record) {
+  ird->is_reduction = false;
+  return;
+   }
+
ir_expression *expr = ir->as_expression();
if (!expr)
   return;
-- 
1.8.3.2

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

Re: [Mesa-dev] [PATCH 4/8] draw/gs: fix segfault in glsl-1.50-gs-mismatch-prim-type triangles_adjacency

[Zack Rusin]

> I'll revisit it today and see if I can spot something else wrong, it
> fails for triangle adj because there are 6 vertices per primitive and
> we have only malloced space for 4.

It has to be something else because that's impossible, in fact it's 2x 
impossible ;)

1) It's illegal and impossible for geometry shader to emit adjacency 
primitives. Only points, lines and triangles can be emitted from gs.

2) The output primitive is irrelevant for the size of the buffer. If a geometry 
shader claims that the max output vertices is four, then it can, at most, emit 
4 points, 2 lines or 1 triangle (incomplete primitives are discarded from 
geometry shader so the extra 4th vertex will be discarded). If a geometry 
shader claims to max emit 4 vertices and you try to emit 100 points, you will 
still get only 4 points (96 will be counted as overflowed but they won't be 
emitted).

My advice would be to check what's in the output buffer with llvmpipe. If 
tgsi_exec doesn't match llvmpipe then there's a bug in tgsi_exec.

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

Re: [Mesa-dev] [PATCH 4/8] draw/gs: fix segfault in glsl-1.50-gs-mismatch-prim-type triangles_adjacency

[Dave Airlie]

On 11 June 2014 10:18, Zack Rusin  wrote:
>> I'll revisit it today and see if I can spot something else wrong, it
>> fails for triangle adj because there are 6 vertices per primitive and
>> we have only malloced space for 4.
>
> It has to be something else because that's impossible, in fact it's 2x 
> impossible ;)
>
> 1) It's illegal and impossible for geometry shader to emit adjacency 
> primitives. Only points, lines and triangles can be emitted from gs.
>
> 2) The output primitive is irrelevant for the size of the buffer. If a 
> geometry shader claims that the max output vertices is four, then it can, at 
> most, emit 4 points, 2 lines or 1 triangle (incomplete primitives are 
> discarded from geometry shader so the extra 4th vertex will be discarded). If 
> a geometry shader claims to max emit 4 vertices and you try to emit 100 
> points, you will still get only 4 points (96 will be counted as overflowed 
> but they won't be emitted).
>
> My advice would be to check what's in the output buffer with llvmpipe. If 
> tgsi_exec doesn't match llvmpipe then there's a bug in tgsi_exec.

Okay I think I found the actual problem,

The input shader is naughty, and says max vertices 3, then emits 6,
because why not.

I've got another patch to limit things that doesn't seem to regress
any, I'll send it on now.

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

[Mesa-dev] [PATCH] draw: avoid buffer overflows with bad geometry programs.

[Dave Airlie]

From: Dave Airlie 

One of the mismatched tests have a max output vertices of 3,
but emits 6 vertices, this means the output buffer is undersized
and causes problems down the line, so limit things later if we
have a number of vertices lower than the number required to execute
a primitive.

Signed-off-by: Dave Airlie 
---
 src/gallium/auxiliary/draw/draw_gs.c  | 4 ++--
 src/gallium/auxiliary/draw/draw_pt_emit.c | 8 +++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_gs.c 
b/src/gallium/auxiliary/draw/draw_gs.c
index fc4f697..d07e88f 100644
--- a/src/gallium/auxiliary/draw/draw_gs.c
+++ b/src/gallium/auxiliary/draw/draw_gs.c
@@ -92,8 +92,8 @@ tgsi_fetch_gs_outputs(struct draw_geometry_shader *shader,
   unsigned num_verts_per_prim = machine->Primitives[prim_idx];
   shader->primitive_lengths[prim_idx +   shader->emitted_primitives] =
  machine->Primitives[prim_idx];
-  shader->emitted_vertices += num_verts_per_prim;
-  for (j = 0; j < num_verts_per_prim; j++, current_idx++) {
+  shader->emitted_vertices += MIN2(num_verts_per_prim, 
shader->max_output_vertices);
+  for (j = 0; j < MIN2(num_verts_per_prim, shader->max_output_vertices); 
j++, current_idx++) {
  int idx = current_idx * shader->info.num_outputs;
 #ifdef DEBUG_OUTPUTS
  debug_printf("%d) Output vert:\n", idx / shader->info.num_outputs);
diff --git a/src/gallium/auxiliary/draw/draw_pt_emit.c 
b/src/gallium/auxiliary/draw/draw_pt_emit.c
index 011efe7..d8e2809 100644
--- a/src/gallium/auxiliary/draw/draw_pt_emit.c
+++ b/src/gallium/auxiliary/draw/draw_pt_emit.c
@@ -26,6 +26,7 @@
  **/
 
 #include "util/u_memory.h"
+#include "util/u_math.h"
 #include "draw/draw_context.h"
 #include "draw/draw_private.h"
 #include "draw/draw_vbuf.h"
@@ -255,9 +256,14 @@ draw_pt_emit_linear(struct pt_emit *emit,
 i < prim_info->primitive_count;
 start += prim_info->primitive_lengths[i], i++)
{
+  int len;
+  if (start > count)
+ continue;
+  len = MIN2(prim_info->primitive_lengths[i], count);
   render->draw_arrays(render,
   start,
-  prim_info->primitive_lengths[i]);
+  len);
+
}

render->release_vertices(render);
-- 
1.9.3

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

Re: [Mesa-dev] [PATCH] configure: Only check for OpenCL without LLVM when the latter is certain

[Michel Dänzer]

On 11.06.2014 00:07, Tom Stellard wrote:
> On Tue, Jun 10, 2014 at 02:57:41PM +0100, Emil Velikov wrote:
>> On 10/06/14 03:25, Michel Dänzer wrote:
>>> From: Michel Dänzer 
>>>
>>> LLVM is enabled by default for some architectures, but the test was failing
>>> before that.
>>>
>> Thanks for fixing my silly mistake Michel. Would you mind CC-ing stable,
>> similar to the offending commit (93257a56b5b: configure: error out when
>> building opencl without LLVM) ?
>>
>> Cc: "10.1 10.2" 
>> Reviewed-by: Emil Velikov 
>>
> 
> I've pushed this patch and cc'd stable.

Thanks, Emil and Tom!


-- 
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] draw: avoid buffer overflows with bad geometry programs.

[Zack Rusin]

To be honest I still don't like it. While the tgsi_exec specific paths in 
draw_gs don't matter to me and can be as ugly as they need to be, they can't be 
polluting the draw_pt_emit code, in other words the primitive_lengths can't be 
bogus at that point - prim_info can't lie about the amount of data that it's 
holding.

z

- Original Message -
> From: Dave Airlie 
> 
> One of the mismatched tests have a max output vertices of 3,
> but emits 6 vertices, this means the output buffer is undersized
> and causes problems down the line, so limit things later if we
> have a number of vertices lower than the number required to execute
> a primitive.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/auxiliary/draw/draw_gs.c  | 4 ++--
>  src/gallium/auxiliary/draw/draw_pt_emit.c | 8 +++-
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/draw/draw_gs.c
> b/src/gallium/auxiliary/draw/draw_gs.c
> index fc4f697..d07e88f 100644
> --- a/src/gallium/auxiliary/draw/draw_gs.c
> +++ b/src/gallium/auxiliary/draw/draw_gs.c
> @@ -92,8 +92,8 @@ tgsi_fetch_gs_outputs(struct draw_geometry_shader *shader,
>unsigned num_verts_per_prim = machine->Primitives[prim_idx];
>shader->primitive_lengths[prim_idx +   shader->emitted_primitives] =
>   machine->Primitives[prim_idx];
> -  shader->emitted_vertices += num_verts_per_prim;
> -  for (j = 0; j < num_verts_per_prim; j++, current_idx++) {
> +  shader->emitted_vertices += MIN2(num_verts_per_prim,
> shader->max_output_vertices);
> +  for (j = 0; j < MIN2(num_verts_per_prim, shader->max_output_vertices);
> j++, current_idx++) {
>   int idx = current_idx * shader->info.num_outputs;
>  #ifdef DEBUG_OUTPUTS
>   debug_printf("%d) Output vert:\n", idx / shader->info.num_outputs);
> diff --git a/src/gallium/auxiliary/draw/draw_pt_emit.c
> b/src/gallium/auxiliary/draw/draw_pt_emit.c
> index 011efe7..d8e2809 100644
> --- a/src/gallium/auxiliary/draw/draw_pt_emit.c
> +++ b/src/gallium/auxiliary/draw/draw_pt_emit.c
> @@ -26,6 +26,7 @@
>   **/
>  
>  #include "util/u_memory.h"
> +#include "util/u_math.h"
>  #include "draw/draw_context.h"
>  #include "draw/draw_private.h"
>  #include "draw/draw_vbuf.h"
> @@ -255,9 +256,14 @@ draw_pt_emit_linear(struct pt_emit *emit,
>  i < prim_info->primitive_count;
>  start += prim_info->primitive_lengths[i], i++)
> {
> +  int len;
> +  if (start > count)
> + continue;
> +  len = MIN2(prim_info->primitive_lengths[i], count);
>render->draw_arrays(render,
>start,
> -  prim_info->primitive_lengths[i]);
> +  len);
> +
> }
> 
> render->release_vertices(render);
> --
> 1.9.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] i965: Add GPU BLIT of texture image to PBO in Intel driver

[Kenneth Graunke]

On Tuesday, March 04, 2014 05:34:44 PM Jon Ashburn wrote:
> Add Intel driver hook for glGetTexImage to accelerate the case of reading
> texture image into a PBO.  This case gets huge performance gains by using
> GPU BLIT directly to PBO rather than GPU BLIT to temporary texture followed
> by memcpy.
> 
> No regressions on Piglit tests  with Intel driver.
> Performance gain (1280 x 800 FBO, Ivybridge):
> glGetTexImage + glMapBufferRange  with patch 1.45 msec
> glGetTexImage + glMapBufferRange without patch 4.68 msec
> ---
>  src/mesa/drivers/dri/i965/intel_tex_image.c | 105 

>  1 file changed, 105 insertions(+)

I fixed up a bunch of small issues with this patch and pushed it.

> diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c 
b/src/mesa/drivers/dri/i965/intel_tex_image.c
> index ee02e68..13a34d5 100644
> --- a/src/mesa/drivers/dri/i965/intel_tex_image.c
> +++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
> @@ -15,6 +15,8 @@
>  #include "main/teximage.h"
>  #include "main/texstore.h"
>  
> +#include "drivers/common/meta.h"
> +
>  #include "intel_mipmap_tree.h"
>  #include "intel_buffer_objects.h"
>  #include "intel_batchbuffer.h"
> @@ -415,10 +417,113 @@ intel_image_target_texture_2d(struct gl_context *ctx, 
GLenum target,
>image->tile_x, image->tile_y);
>  }
>  
> +static bool
> +IntelBlitTexToPbo(struct gl_context * ctx,

We've been trying to move away from camelCase, and never used StudlyCaps.  
I've renamed this to "blit_texture_to_pbo" (we don't need the intel prefix on 
static functions).

> +   GLenum format, GLenum type,
> +   GLvoid * pixels, struct gl_texture_image *texImage)
> +{
> +   struct intel_texture_image *intelImage = intel_texture_image(texImage);
> +   struct brw_context *brw = brw_context(ctx);
> +   const struct gl_pixelstore_attrib *pack = &(ctx->Pack);
> +   struct intel_buffer_object *dst = intel_buffer_object(pack->BufferObj);
> +   GLuint dst_offset;
> +   drm_intel_bo *dst_buffer;
> +   GLenum target = texImage->TexObject->Target;
> +
> +   /*

Comments should start directly after /*.  Fixed.

> +* Check if we can use GPU blit to copy from the hardware texture
> +* format to the user's format/type.
> +* Note that GL's pixel transfer ops don't apply to glGetTexImage()
> +*/
> +
> +   if (!_mesa_format_matches_format_and_type(
> +  intelImage->mt->format, format, type, false))

I reformatted this slightly.

> +   {
> +  perf_debug("%s: unsupported format, fallback to CPU mapping for 
PBO\n", __FUNCTION__);

Wrap at 80 columns.  Fixed.

> +
> +  return false;
> +   }
> +
> +   if (ctx->_ImageTransferState) {
> +  perf_debug("%s: bad transfer state, fallback to CPU mapping for 
PBO\n", __FUNCTION__);
> +  return false;
> +   }
> +
> +   if (pack->SwapBytes || pack->LsbFirst) {
> +  perf_debug("%s: unsupported pack swap params\n", __FUNCTION__);
> +  return false;
> +   }
> +
> +   if (target == GL_TEXTURE_1D_ARRAY || target == GL_TEXTURE_CUBE_MAP_ARRAY 
||
> +   target == GL_TEXTURE_2D_ARRAY) {

This path regresses Piglit's "getteximage-targets 3D" test, which would suffer 
from the same "multiple slices" problem.  (I see you worked on that test - 
perhaps the 3D case didn't exist when you tested this patch?)  I blacklisted
GL_TEXTURE_3D here to avoid that bug.

> +  perf_debug("%s: no support for array textures, fallback to CPU 
mapping for PBO\n", __FUNCTION__);
> +  return false;
> +   }
> +
> +   int dst_stride = _mesa_image_row_stride(pack, texImage->Width, format, 
type);
> +   bool dst_flip = false;
> +   /* Mesa flips the dst_stride for ctx->Pack.Invert, our mt must have a
> +* normal dst_stride.
> +*/
> +   struct gl_pixelstore_attrib uninverted_pack = *pack;
> +   if (ctx->Pack.Invert) {
> +  dst_stride = -dst_stride;
> +  dst_flip = true;
> +  uninverted_pack.Invert = false;
> +   }
> +   dst_offset = (GLintptr) pixels;
> +   dst_offset += _mesa_image_offset(2, &uninverted_pack, texImage->Width,
> +texImage->Height, format, type, 0, 0, 
0);
> +   dst_buffer = intel_bufferobj_buffer(brw, dst, dst_offset,
> +   texImage->Height * dst_stride);
> +
> +   struct intel_mipmap_tree *pbo_mt =
> +intel_miptree_create_for_bo(brw,

Weird whitespace.  Fixed.

> +dst_buffer,
> +intelImage->mt->format,
> +dst_offset,
> +texImage->Width, texImage->Height,
> +dst_stride, I915_TILING_NONE);

Eric removed the tiling parameter in April, so this didn't compile.  Fixed.

Thanks for the patch.  Sorry for not getting to review it earlier...

signature.asc
Description: This is a digitally signed message part.

Re: [Mesa-dev] [PATCH] draw: avoid buffer overflows with bad geometry programs.

[Dave Airlie]

On 11 June 2014 10:48, Zack Rusin  wrote:
> To be honest I still don't like it. While the tgsi_exec specific paths in 
> draw_gs don't matter to me and can be as ugly as they need to be, they can't 
> be polluting the draw_pt_emit code, in other words the primitive_lengths 
> can't be bogus at that point - prim_info can't lie about the amount of data 
> that it's holding.

Thanks for following me on this journey! I think I got it now,
tgsi_exec wasn't bounding to the max output vertices, and causing
subsequent fallout.

I'll send that patch next!

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

[Mesa-dev] [PATCH] tgsi/gs: bound max output vertices in shader

[Dave Airlie]

From: Dave Airlie 

This limits the number of emitted vertices to the shaders max output
vertices, and avoids us writing things into memory that isn't big
enough for it.

Signed-off-by: Dave Airlie 
---
 src/gallium/auxiliary/tgsi/tgsi_exec.c | 8 
 src/gallium/auxiliary/tgsi/tgsi_exec.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 69d98fd..d848348 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -789,6 +789,11 @@ tgsi_exec_machine_bind_shader(
  break;
 
   case TGSI_TOKEN_TYPE_PROPERTY:
+ if (mach->Processor == TGSI_PROCESSOR_GEOMETRY) {
+if (parse.FullToken.FullProperty.Property.PropertyName == 
TGSI_PROPERTY_GS_MAX_OUTPUT_VERTICES) {
+   mach->MaxOutputVertices = 
parse.FullToken.FullProperty.u[0].Data;
+}
+ }
  break;
 
   default:
@@ -1621,6 +1626,9 @@ emit_vertex(struct tgsi_exec_machine *mach)
  if ((mach->ExecMask & (1 << i)))
*/
if (mach->ExecMask) {
+  if 
(mach->Primitives[mach->Temps[TEMP_PRIMITIVE_I].xyzw[TEMP_PRIMITIVE_C].u[0]] >= 
mach->MaxOutputVertices)
+ return;
+
   mach->Temps[TEMP_OUTPUT_I].xyzw[TEMP_OUTPUT_C].u[0] += mach->NumOutputs;
   
mach->Primitives[mach->Temps[TEMP_PRIMITIVE_I].xyzw[TEMP_PRIMITIVE_C].u[0]]++;
}
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.h 
b/src/gallium/auxiliary/tgsi/tgsi_exec.h
index 7a82f69..d53c4ba 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.h
@@ -297,6 +297,7 @@ struct tgsi_exec_machine
unsigned  *Primitives;
unsigned   NumOutputs;
unsigned   MaxGeometryShaderOutputs;
+   unsigned   MaxOutputVertices;
 
/* FRAGMENT processor only. */
const struct tgsi_interp_coef *InterpCoefs;
-- 
1.9.3

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

Re: [Mesa-dev] [PATCH] tgsi/gs: bound max output vertices in shader

[Zack Rusin]

Looks great. If I was into diffs I'd make sweet and passionate love to this one.

Reviewed-by: Zack Rusin 

- Original Message -
> From: Dave Airlie 
> 
> This limits the number of emitted vertices to the shaders max output
> vertices, and avoids us writing things into memory that isn't big
> enough for it.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/auxiliary/tgsi/tgsi_exec.c | 8 
>  src/gallium/auxiliary/tgsi/tgsi_exec.h | 1 +
>  2 files changed, 9 insertions(+)
> 
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c
> b/src/gallium/auxiliary/tgsi/tgsi_exec.c
> index 69d98fd..d848348 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
> @@ -789,6 +789,11 @@ tgsi_exec_machine_bind_shader(
>   break;
>  
>case TGSI_TOKEN_TYPE_PROPERTY:
> + if (mach->Processor == TGSI_PROCESSOR_GEOMETRY) {
> +if (parse.FullToken.FullProperty.Property.PropertyName ==
> TGSI_PROPERTY_GS_MAX_OUTPUT_VERTICES) {
> +   mach->MaxOutputVertices =
> parse.FullToken.FullProperty.u[0].Data;
> +}
> + }
>   break;
>  
>default:
> @@ -1621,6 +1626,9 @@ emit_vertex(struct tgsi_exec_machine *mach)
>   if ((mach->ExecMask & (1 << i)))
> */
> if (mach->ExecMask) {
> +  if
> (mach->Primitives[mach->Temps[TEMP_PRIMITIVE_I].xyzw[TEMP_PRIMITIVE_C].u[0]]
> >= mach->MaxOutputVertices)
> + return;
> +
>mach->Temps[TEMP_OUTPUT_I].xyzw[TEMP_OUTPUT_C].u[0] +=
>mach->NumOutputs;
>
> mach->Primitives[mach->Temps[TEMP_PRIMITIVE_I].xyzw[TEMP_PRIMITIVE_C].u[0]]++;
> }
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.h
> b/src/gallium/auxiliary/tgsi/tgsi_exec.h
> index 7a82f69..d53c4ba 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_exec.h
> +++ b/src/gallium/auxiliary/tgsi/tgsi_exec.h
> @@ -297,6 +297,7 @@ struct tgsi_exec_machine
> unsigned  *Primitives;
> unsigned   NumOutputs;
> unsigned   MaxGeometryShaderOutputs;
> +   unsigned   MaxOutputVertices;
>  
> /* FRAGMENT processor only. */
> const struct tgsi_interp_coef *InterpCoefs;
> --
> 1.9.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] GlassyMesa Announcement

[John Kessenich]

Hi Tom,

On 6/10/2014 12:03 PM, Tom Stellard wrote:

On Sat, Jun 07, 2014 at 01:24:39PM -0700, Greg Fischer wrote:

LunarG, with support from Valve, announces the GlassyMesa project, an
effort to bring the LLVM compiler infrastructure to Mesa.

This is very interesting.  Have you done any testing with any of the
Gallium drivers?


No, we have not yet tested other paths, but we are interested in 
ensuring they work.



How difficult would it be to bypass the LLVM IR -> GLSL IR -> TGSI
conversion and pass LLVM IR directly to drivers like radeonsi which
already use LLVM?


Ideally (from a technical perspective), we'd like to skip going through 
GLSL IR; it's a higher-level language than LLVM IR and we suspect it's 
more efficient in the long run to push LLVM IR lower into the stack.  
The conventions for LLVM-IR usage are a bit different between LunarGLASS 
and radeonsi, but the worst case of transforming LunarGLASS-LLVM-IR -> 
radeonsi-LLVM-IR should be far more efficient than going through lots of 
different representations.  We'll look deeper at radeonsi and get a more 
concrete answer.


Our current use of GLSL IR has two key advantages: it allows more 
expedient comparison of the middle ends by leveraging the existing back 
end, and ongoing it makes the Glassy middle end available to the other 
back ends.



What are you plans for getting this upstream into Mesa?


We're proceeding with getting a fuller technical characterization of 
GlassyMesa, as well as discussing broadly in the community, to help 
decide what's best for Mesa, and form recommendations from there.


Thanks for you interest,
JohnK



-Tom


What is GlassyMesa?

GlassyMesa utilizes LunarGLASS, the LLVM compiler stack with modifications
allowing it to represent and optimize 3D shaders and target GPUs. This
also includes use of glslang, the Khronos GLSL reference parser. It also
includes a translation pass from LLVM IR to GLSL IR, the IR used by Mesa
compiler backends. A slide deck with a block diagram is available at
lunarg.com/wp-content/uploads/2014/06/GlassyMesaSlides-05Jun2014.pdf

Why create GlassyMesa?

LLVM brings state-of-the-art compiler optimizations to Mesa immediately. As
importantly, it brings a modern Intermediate Representation (IR) which can
be the basis for rapid development of new optimizations as shaders and
shader languages evolve as well as enable multiple teams to develop
components independently more efficiently than current IRs.
Furthermore, this capability can be used as a basis for development
of compiler backends using the LLVM backend infrastructure.

What is the current state of GlassyMesa?

GlassyMesa is in very early development. It is a proof-of-concept to
demonstrate this approach can deliver shader runtime improvements and will
continue to evolve in capability. Much functionality remains to be
developed. No effort has been made yet to tune shader runtime or compile
time performance. It is running only a handful of traces to our knowledge.
Initial performance results are promising.

Why announce GlassyMesa now?

LunarG invites the feedback and cooperation of the Mesa community to this
effort. It believes that an effort like this requires early and frequent
input and support from the community.

What are the plans for GlassyMesa?

LunarG is planning to actively improve GlassyMesa functionality and
performance over the coming months.

Where can I find GlassyMesa?

GlassyMesa is available at: *github.com*:LunarG/steamos_mesa.git, at branch
2014ww23.2_i965-LunarGlass_drop1

What is the licensing?

LunarGLASS is released under a BSD-style license. See
http://www.lunarglass.org .
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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


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

[Mesa-dev] [PATCH 1/2] i965: Silence a couple unused parameter warnings

[Ian Romanick]

From: Ian Romanick 

brw_vec4_visitor.cpp:2717:1: warning: unused parameter 'ir' [-Wunused-parameter]
brw_vec4_visitor.cpp:2723:1: warning: unused parameter 'ir' [-Wunused-parameter]

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index ee52c07..249072c 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -2655,13 +2655,13 @@ vec4_visitor::swizzle_result(ir_texture *ir, src_reg 
orig_val, int sampler)
 }
 
 void
-vec4_visitor::visit(ir_return *ir)
+vec4_visitor::visit(ir_return *)
 {
assert(!"not reached");
 }
 
 void
-vec4_visitor::visit(ir_discard *ir)
+vec4_visitor::visit(ir_discard *)
 {
assert(!"not reached");
 }
-- 
1.8.1.4

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

[Mesa-dev] [PATCH 2/2] i965: Emit smarter code for b2i of a comparison

[Ian Romanick]

From: Ian Romanick 

Previously we would emit the comparison, emit an AND to mask off extra
bits from the comparison result, then convert the result to float.  Now,
do the comparison, then use a cleverly constructed SEL to pick either
0.0f or 1.0f.

No piglit regressions on Ivybridge.

NOTE: I have not yet tested actual application performance.  I'll do
that tomorrow.

total instructions in shared programs: 1642311 -> 1639449 (-0.17%)
instructions in affected programs: 136533 -> 133671 (-2.10%)
GAINED:0
LOST:  0

Programs that are affected appear to save between 1 and 5 instuctions
(just by skimming the output from shader-db report.py.

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_vec4.h   |  1 +
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 47 ++
 2 files changed, 48 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index c2bbd68..27e1e39 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -587,6 +587,7 @@ public:
 
bool try_emit_sat(ir_expression *ir);
bool try_emit_mad(ir_expression *ir);
+   bool try_emit_b2f_of_compare(ir_expression *ir);
void resolve_ud_negate(src_reg *reg);
 
src_reg get_timestamp();
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 249072c..902f02d 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -1126,6 +1126,48 @@ vec4_visitor::try_emit_mad(ir_expression *ir)
return true;
 }
 
+bool
+vec4_visitor::try_emit_b2f_of_compare(ir_expression *ir)
+{
+   ir_expression *const cmp = ir->operands[0]->as_expression();
+
+   if (cmp == NULL)
+  return false;
+
+   switch (cmp->operation) {
+   case ir_binop_less:
+   case ir_binop_greater:
+   case ir_binop_lequal:
+   case ir_binop_gequal:
+   case ir_binop_equal:
+   case ir_binop_nequal:
+  break;
+
+   default:
+  return false;
+   }
+
+   cmp->operands[0]->accept(this);
+   const src_reg cmp_src0 = this->result;
+
+   cmp->operands[1]->accept(this);
+   const src_reg cmp_src1 = this->result;
+
+   this->result = src_reg(this, ir->type);
+
+   emit(CMP(dst_reg(this->result), cmp_src0, cmp_src1,
+brw_conditional_for_comparison(cmp->operation)));
+
+   /* If the comparison is false, this->result will just happen to be zero.
+*/
+   vec4_instruction *const inst = emit(BRW_OPCODE_SEL, dst_reg(this->result),
+   fix_3src_operand(src_reg(1.0f)),
+   this->result);
+   inst->predicate = BRW_PREDICATE_NORMAL;
+
+   return true;
+}
+
 void
 vec4_visitor::emit_bool_comparison(unsigned int op,
 dst_reg dst, src_reg src0, src_reg src1)
@@ -1202,6 +1244,11 @@ vec4_visitor::visit(ir_expression *ir)
 return;
}
 
+   if (ir->operation == ir_unop_b2f) {
+  if (try_emit_b2f_of_compare(ir))
+return;
+   }
+
for (operand = 0; operand < ir->get_num_operands(); operand++) {
   this->result.file = BAD_FILE;
   ir->operands[operand]->accept(this);
-- 
1.8.1.4

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

[Mesa-dev] [PATCH] glsl: Store gl_uniform_driver_storage::format as the actual type

[Ian Romanick]

From: Ian Romanick 

And delete the incorrect comment.

Signed-off-by: Ian Romanick 
---
 src/glsl/ir_uniform.h| 7 ++-
 src/mesa/main/uniforms.c | 2 +-
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/src/glsl/ir_uniform.h b/src/glsl/ir_uniform.h
index 3508509..4829eb7 100644
--- a/src/glsl/ir_uniform.h
+++ b/src/glsl/ir_uniform.h
@@ -37,7 +37,7 @@
 extern "C" {
 #endif
 
-enum gl_uniform_driver_format {
+enum PACKED gl_uniform_driver_format {
uniform_native = 0,  /**< Store data in the native format. */
uniform_int_float,   /**< Store integer data as floats. */
uniform_bool_float,  /**< Store boolean data as floats. */
@@ -66,11 +66,8 @@ struct gl_uniform_driver_storage {
 
/**
 * Base format of the stored data.
-*
-* This field must have a value from \c GLSL_TYPE_UINT through \c
-* GLSL_TYPE_SAMPLER.
 */
-   uint8_t format;
+   enum gl_uniform_driver_format format;
 
/**
 * Pointer to the base of the data.
diff --git a/src/mesa/main/uniforms.c b/src/mesa/main/uniforms.c
index 1daade4..f450173 100644
--- a/src/mesa/main/uniforms.c
+++ b/src/mesa/main/uniforms.c
@@ -112,7 +112,7 @@ _mesa_uniform_attach_driver_storage(struct 
gl_uniform_storage *uni,
 
uni->driver_storage[uni->num_driver_storage].element_stride = 
element_stride;
uni->driver_storage[uni->num_driver_storage].vector_stride = vector_stride;
-   uni->driver_storage[uni->num_driver_storage].format = (uint8_t) format;
+   uni->driver_storage[uni->num_driver_storage].format = format;
uni->driver_storage[uni->num_driver_storage].data = data;
 
uni->num_driver_storage++;
-- 
1.8.1.4

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

[Mesa-dev] [PATCH 1/3] configure.ac: Remove single quotes to fix syntax highlighting.

[Matt Turner]

Please stop adding them.
---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index eaca378..c6664b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -543,7 +543,7 @@ darwin*|mingw*)
 *)
 AC_CHECK_FUNCS([clock_gettime], [CLOCK_LIB=],
[AC_CHECK_LIB([rt], [clock_gettime], [CLOCK_LIB=-lrt],
- [AC_MSG_ERROR([Couldn't find 
clock_gettime])])])
+ [AC_MSG_ERROR([Could not find 
clock_gettime])])])
 AC_SUBST([CLOCK_LIB])
 ;;
 esac
@@ -1373,7 +1373,7 @@ if test "x$enable_xa" = xyes; then
 if test "x$with_gallium_drivers" = xswrast; then
AC_MSG_ERROR([
   Building xa requires at least one non swrast gallium driver.
-  If you are looking to use libxatracker.so with vmware's virtual gpu,
+  If you are looking to use libxatracker.so with the VMware driver,
   make sure to include svga in the gallium drivers list, apart from
   enabling XA.
   Example: ./configure --enable-xa --with-gallium-drivers=svga...])
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 3/3] configure.ac: Simplify DUSE_EXTERNAL_DXTN_LIB logic.

[Matt Turner]

---
 configure.ac | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/configure.ac b/configure.ac
index 17e9e9c..4b27455 100644
--- a/configure.ac
+++ b/configure.ac
@@ -149,7 +149,7 @@ _SAVE_LDFLAGS="$LDFLAGS"
 _SAVE_CPPFLAGS="$CPPFLAGS"
 
 dnl Compiler macros
-DEFINES=""
+DEFINES="-DUSE_EXTERNAL_DXTN_LIB=1"
 AC_SUBST([DEFINES])
 case "$host_os" in
 linux*|*-gnu*|gnu*)
@@ -1077,7 +1077,6 @@ if test "x$enable_dri" = xyes; then
 # Platform specific settings and drivers to build
 case "$host_os" in
 linux*)
-DEFINES="$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1"
 DEFINES="$DEFINES -DHAVE_ALIAS"
 if test "x$enable_dri3" = xyes; then
 DEFINES="$DEFINES -DHAVE_DRI3"
@@ -1097,24 +1096,19 @@ if test "x$enable_dri" = xyes; then
 esac
 ;;
 *freebsd* | dragonfly* | *netbsd* | openbsd*)
-DEFINES="$DEFINES -DHAVE_PTHREAD -DUSE_EXTERNAL_DXTN_LIB=1"
+DEFINES="$DEFINES -DHAVE_PTHREAD"
 DEFINES="$DEFINES -DHAVE_ALIAS"
 ;;
 gnu*)
-DEFINES="$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1"
 DEFINES="$DEFINES -DHAVE_ALIAS"
 ;;
-solaris*)
-DEFINES="$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1"
-;;
 cygwin*)
-DEFINES="$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1"
 if test "x$with_dri_drivers" = "xyes"; then
 with_dri_drivers="swrast"
 fi
 ;;
 darwin*)
-DEFINES="$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1 -DGLX_ALIAS_UNSUPPORTED"
+DEFINES="$DEFINES -DGLX_ALIAS_UNSUPPORTED"
 if test "x$with_dri_drivers" = "xyes"; then
 with_dri_drivers="swrast"
 fi
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 2/3] configure.ac: Alphabetize AC_CONFIG_FILES.

[Matt Turner]

This isn't supposed to be difficult.
---
 configure.ac | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/configure.ac b/configure.ac
index c6664b9..17e9e9c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2230,23 +2230,23 @@ AC_CONFIG_FILES([Makefile
src/gallium/targets/dri-vmwgfx/Makefile
src/gallium/targets/egl-static/Makefile
src/gallium/targets/gbm/Makefile
-   src/gallium/targets/opencl/Makefile
-   src/gallium/targets/xa/Makefile
-   src/gallium/targets/xa/xatracker.pc
+   src/gallium/targets/libgl-xlib/Makefile
src/gallium/targets/omx-nouveau/Makefile
+   src/gallium/targets/opencl/Makefile
src/gallium/targets/osmesa/Makefile
src/gallium/targets/osmesa/osmesa.pc
src/gallium/targets/pipe-loader/Makefile
-   src/gallium/targets/radeonsi/dri/Makefile
-   src/gallium/targets/radeonsi/omx/Makefile
-   src/gallium/targets/radeonsi/vdpau/Makefile
src/gallium/targets/r300/dri/Makefile
src/gallium/targets/r600/dri/Makefile
src/gallium/targets/r600/omx/Makefile
src/gallium/targets/r600/vdpau/Makefile
src/gallium/targets/r600/xvmc/Makefile
-   src/gallium/targets/libgl-xlib/Makefile
+   src/gallium/targets/radeonsi/dri/Makefile
+   src/gallium/targets/radeonsi/omx/Makefile
+   src/gallium/targets/radeonsi/vdpau/Makefile
src/gallium/targets/vdpau-nouveau/Makefile
+   src/gallium/targets/xa/Makefile
+   src/gallium/targets/xa/xatracker.pc
src/gallium/targets/xvmc-nouveau/Makefile
src/gallium/tests/trivial/Makefile
src/gallium/tests/unit/Makefile
-- 
1.8.3.2

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