[Mesa-dev] [PATCH] i965: Use has_surface_tile_offset in depth/stencil alignment workaround.

[Kenneth Graunke]

Currently, has_surface_tile_offset is equivalent to gen == 4 && !is_g4x.

We already use it for related checks in brw_wm_surface_state.c, so it
makes sense to use it here too.  It's simpler and more future-proof.

Broadwell also lacks surface tile offsets.  With this patch, I won't
need to update any generation checking; I can simply not set the flag.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_misc_state.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 70b0dbd..454017e 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -338,7 +338,7 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw,
  rebase_depth = true;
 
   /* We didn't even have intra-tile offsets before g45. */
-  if (brw->gen == 4 && !brw->is_g4x) {
+  if (!brw->has_surface_tile_offset) {
  if (tile_x || tile_y)
 rebase_depth = true;
   }
@@ -397,7 +397,7 @@ brw_workaround_depthstencil_alignment(struct brw_context 
*brw,
   if (stencil_tile_x & 7 || stencil_tile_y & 7)
  rebase_stencil = true;
 
-  if (brw->gen == 4 && !brw->is_g4x) {
+  if (!brw->has_surface_tile_offset) {
  if (stencil_tile_x || stencil_tile_y)
 rebase_stencil = true;
   }
-- 
1.8.3.2

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

Re: [Mesa-dev] [v2 5/6] glsl: functions to serialize gl_shader and gl_shader_program

[Tapani Pälli]

On 11/06/2013 12:02 AM, Paul Berry wrote:
On 1 November 2013 02:16, Tapani Pälli > wrote:


+static void
+calc_item(const void *key, void *data, void *closure)


How about "increment_count" for the name of this function?


ok


+{
+   unsigned *sz = (unsigned *) closure;
+   *sz = *sz + 1;
+}
+
+
+static unsigned
+_hash_table_size(struct string_to_uint_map *map)


This function is global, so its name can't start with an 
underscore--such names are reserved for library functions.  Same goes 
for many of the other functions in this file.


will change


+{
+   unsigned size = 0;
+   map->iterate(calc_item, &size);
+   return size;
+}
+
+
+static void
+serialize_item(const void *key, void *data, void *closure)
+{
+   memory_writer *blob = (memory_writer *) closure;
+   uint32_t value = ((intptr_t)data);
+
+   blob->write_string((char *)key);
+   blob->write_uint32(&value);
+}
+
+
+static void
+_serialize_hash_table(struct string_to_uint_map *map,
memory_writer *blob)
+{
+   uint32_t size = _hash_table_size(map);
+   blob->write_uint32(&size);
+   map->iterate(serialize_item, blob);


Rather than take two passes over the hash table (one to compute its 
size and one to output its contents), why not do the trick that we do 
with overwrite() in ir_cache_serializer.cpp?  (In other words, reserve 
space for the size of the hashtable in bytes, then serialize the 
hashtable, then overwrite the reserved space with the actual size).


yes this is faster, will change


+   /* Shaders IR, to be decided if we want these to be available */


Has there been previous discussion on the mesa-dev list about whether 
or not we want these to be available?  If so, please include a link to 
previous discussion and a brief summary.  if not, what does the 
decision hinge on? At first blush it seems to me that there's no 
reason to serialize the IR of the individual shaders, since 
ARB_get_program_binary operates on full programs rather than 
individual shaders.




Nope there has been no previous discussion about this. Automatic cache 
will need these to be able to quick exit from glCompileShader (if 
wanted), it's easier for the implementation to have them as separate 
blobs than part of whole program blob though. With the extension I'm not 
sure if unlinked IR is required for possible run-time recompilations? 
I'd like someone to confirm this.



Also, typically we prefer to disable code using "if (false)" rather 
than ifdefs, because that ensures that the disabled code still 
compiles.  (Otherwise, it's much more likely to bit rot as the rest of 
the code base evolves).


ok, will use if (false), I also changethe unlinked shader define to use 
your STORE_UNLINKED_SHADERS proposal



Are we going to attempt to store the back-end compiled shaders?  It 
seems like we'd have to do that in order to get a lot of the benefit 
of ARB_get_program_binary.


Yes it is definitely required, there is big amount of time spent in 
Driver->LinkShader(). However, this was left out for now. It might be 
that several back-end blobs are needed and I'm not sure how well it 
works and what should happen when recompilation happens. This needs a 
bit more thought. At least new API is needed with driver to simply 
retrieve and put binary blobs, I would certainly like some advice how to 
approach the problem.


// Tapani

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

[Mesa-dev] R: Re: [PATCH 3/4] mesa: fix build on kFreeBSD

[Fabio Pedretti]

Done, I also improved commit message of patches 3 and 4. Updated patches 
follow.

>I think we could simplify this a bit.
>
>2013/11/5 Fabio Pedretti :
>> From: Aurelien Jarno 
>> From: Cyril Brulebois 
>>
>> mesa fails to build on GNU/kFreeBSD, since some parts are not enabled.
>>
>> Debian bug: http://bugs.debian.org/524690
>>
>> Patch from Debian package
>> ---
>>  configure.ac | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 0a25047..e250734 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -425,7 +425,7 @@ if test "x$enable_asm" = xyes; then
>>  case "$host_cpu" in
>>  i?86)
>>  case "$host_os" in
>> -linux* | *freebsd* | dragonfly* | *netbsd* | openbsd*)
>> +linux* | *freebsd* | dragonfly* | *netbsd* | openbsd* | kfreebsd*-
gnu*)
>*freebsd* already includes kfreebsd*-gnu*
>
>>  test "x$enable_64bit" = xyes && asm_arch=x86_64 || 
asm_arch=x86
>>  ;;
>>  gnu*)
>> @@ -435,7 +435,7 @@ if test "x$enable_asm" = xyes; then
>>  ;;
>>  x86_64|amd64)
>>  case "$host_os" in
>> -linux* | *freebsd* | dragonfly* | *netbsd* | openbsd*)
>> +linux* | *freebsd* | dragonfly* | *netbsd* | openbsd* | kfreebsd*-
gnu*)
>same as above
>
>>  test "x$enable_32bit" = xyes && asm_arch=x86 || 
asm_arch=x86_64
>>  ;;
>>  esac
>> @@ -974,7 +974,7 @@ if test "x$enable_dri" = xyes; then
>>  ;;
>>  esac
>>  ;;
>> -freebsd* | dragonfly* | *netbsd* | openbsd*)
>> +freebsd* | dragonfly* | *netbsd* | openbsd* | kfreebsd*-gnu*)
>
>To be consistent we could use *freebsd* as well.
>
>Andreas.
>
>>  DEFINES="$DEFINES -DHAVE_PTHREAD -DUSE_EXTERNAL_DXTN_LIB=1"
>>  DEFINES="$DEFINES -DHAVE_ALIAS"
>>
>> --
>> 1.8.3.2
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>


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

[Mesa-dev] [PATCH 3/4] configure.ac: fix build on GNU/kFreeBSD

[Fabio Pedretti]

Based on existing patch from Debian package.

Debian bug: http://bugs.debian.org/524690
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 0a25047..989168a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -974,7 +974,7 @@ if test "x$enable_dri" = xyes; then
 ;;
 esac
 ;;
-freebsd* | dragonfly* | *netbsd* | openbsd*)
+*freebsd* | dragonfly* | *netbsd* | openbsd*)
 DEFINES="$DEFINES -DHAVE_PTHREAD -DUSE_EXTERNAL_DXTN_LIB=1"
 DEFINES="$DEFINES -DHAVE_ALIAS"
 
-- 
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/4] gallium: fix build on GNU/kFreeBSD

[Fabio Pedretti]

Patch from Debian package
---
 src/gallium/auxiliary/rtasm/rtasm_execmem.c | 2 +-
 src/gallium/include/pipe/p_config.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/rtasm/rtasm_execmem.c 
b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
index 3c4b048..edc1b66 100644
--- a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
+++ b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
@@ -38,7 +38,7 @@
 
 #include "rtasm_execmem.h"
 
-#if defined(PIPE_OS_BSD)
+#ifndef MAP_ANONYMOUS
 #define MAP_ANONYMOUS MAP_ANON
 #endif
 
diff --git a/src/gallium/include/pipe/p_config.h 
b/src/gallium/include/pipe/p_config.h
index 9bccf32..64acd02 100644
--- a/src/gallium/include/pipe/p_config.h
+++ b/src/gallium/include/pipe/p_config.h
@@ -190,7 +190,7 @@
 #define PIPE_OS_ANDROID
 #endif
 
-#if defined(__FreeBSD__)
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #define PIPE_OS_FREEBSD
 #define PIPE_OS_BSD
 #define PIPE_OS_UNIX
-- 
1.8.3.2

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

[Mesa-dev] [Bug 69101] prime: black window

[bugzilla-daemon]

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

Mike Lothian  changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #4 from Mike Lothian  ---
By any chance are you using SNA rather than UXA on xf86-video-intel? I'm
experiencing the same issues as you

-- 
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] st/vdpau: resolve delayed rendering for GL interop

[Christian König]

We need to take/release the driver lock around this as well.

I've fixed this and pushed the result upstream. Any idea when your 
deinterlacer is ready to hit the list as a patch?


Thanks for the help,
Christian.

Am 06.11.2013 00:35, schrieb Grigori Goronzy:

Otherwise OutputSurface interop has funny results sometimes.
This fixes interop with the mpv media player.
---
  src/gallium/state_trackers/vdpau/output.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/gallium/state_trackers/vdpau/output.c 
b/src/gallium/state_trackers/vdpau/output.c
index def01c8..76c7312 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -734,5 +734,6 @@ struct pipe_resource 
*vlVdpOutputSurfaceGallium(VdpOutputSurface surface)
 if (!vlsurface || !vlsurface->surface)
return NULL;
  
+   vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL);

 return vlsurface->surface->texture;
  }


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

[Mesa-dev] [PATCH] vl: use a separate context for shader based decode

[Christian König]

From: Christian König 

This makes VDPAU thread save again.

Signed-off-by: Christian König 
---
 src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 180 ++-
 src/gallium/auxiliary/vl/vl_mpeg12_decoder.h |   1 +
 2 files changed, 120 insertions(+), 61 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c 
b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
index ca4eb3e..3777174 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
@@ -82,6 +82,63 @@ static const unsigned const_empty_block_mask_420[3][2][2] = {
{ { 0x01, 0x01 },  { 0x01, 0x01 } }
 };
 
+struct video_buffer_private
+{
+   struct pipe_sampler_view *sampler_view_planes[VL_NUM_COMPONENTS];
+   struct pipe_surface  *surfaces[VL_MAX_SURFACES];
+
+   struct vl_mpeg12_buffer *buffer;
+};
+
+static void
+vl_mpeg12_destroy_buffer(struct vl_mpeg12_buffer *buf);
+
+static void
+destroy_video_buffer_private(void *private)
+{
+   struct video_buffer_private *priv = private;
+   unsigned i;
+
+   for (i = 0; i < VL_NUM_COMPONENTS; ++i)
+  pipe_sampler_view_reference(&priv->sampler_view_planes[i], NULL);
+
+   for (i = 0; i < VL_MAX_SURFACES; ++i)
+  pipe_surface_reference(&priv->surfaces[i], NULL);
+
+   if (priv->buffer)
+  vl_mpeg12_destroy_buffer(priv->buffer);
+}
+
+static struct video_buffer_private *
+get_video_buffer_private(struct vl_mpeg12_decoder *dec, struct 
pipe_video_buffer *buf)
+{
+   struct pipe_context *pipe = dec->context;
+   struct video_buffer_private *priv;
+   struct pipe_sampler_view **sv;
+   struct pipe_surface **surf;
+   unsigned i;
+
+   priv = vl_video_buffer_get_associated_data(buf, &dec->base);
+   if (priv)
+  return priv;
+
+   priv = CALLOC_STRUCT(video_buffer_private);
+
+   sv = buf->get_sampler_view_planes(buf);
+   for (i = 0; i < VL_NUM_COMPONENTS; ++i)
+  if (sv[i])
+ priv->sampler_view_planes[i] = pipe->create_sampler_view(pipe, 
sv[i]->texture, sv[i]);
+
+   surf = buf->get_surfaces(buf);
+   for (i = 0; i < VL_MAX_SURFACES; ++i)
+  if (surf[i])
+ priv->surfaces[i] = pipe->create_surface(pipe, surf[i]->texture, 
surf[i]);
+
+   vl_video_buffer_set_associated_data(buf, &dec->base, priv, 
destroy_video_buffer_private);
+
+   return priv;
+}
+
 static bool
 init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct vl_mpeg12_buffer 
*buffer)
 {
@@ -103,7 +160,7 @@ init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct 
vl_mpeg12_buffer *buffer
res_tmpl.usage = PIPE_USAGE_STREAM;
res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW;
 
-   res = dec->base.context->screen->resource_create(dec->base.context->screen, 
&res_tmpl);
+   res = dec->context->screen->resource_create(dec->context->screen, 
&res_tmpl);
if (!res)
   goto error_source;
 
@@ -111,7 +168,7 @@ init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct 
vl_mpeg12_buffer *buffer
memset(&sv_tmpl, 0, sizeof(sv_tmpl));
u_sampler_view_default_template(&sv_tmpl, res, res->format);
sv_tmpl.swizzle_r = sv_tmpl.swizzle_g = sv_tmpl.swizzle_b = 
sv_tmpl.swizzle_a = PIPE_SWIZZLE_RED;
-   buffer->zscan_source = 
dec->base.context->create_sampler_view(dec->base.context, res, &sv_tmpl);
+   buffer->zscan_source = dec->context->create_sampler_view(dec->context, res, 
&sv_tmpl);
pipe_resource_reference(&res, NULL);
if (!buffer->zscan_source)
   goto error_sampler;
@@ -384,9 +441,8 @@ UploadYcbcrBlocks(struct vl_mpeg12_decoder *dec,
 }
 
 static void
-vl_mpeg12_destroy_buffer(void *buffer)
+vl_mpeg12_destroy_buffer(struct vl_mpeg12_buffer *buf)
 {
-   struct vl_mpeg12_buffer *buf = buffer;
 
assert(buf);
 
@@ -407,11 +463,11 @@ vl_mpeg12_destroy(struct pipe_video_codec *decoder)
assert(decoder);
 
/* Asserted in softpipe_delete_fs_state() for some reason */
-   dec->base.context->bind_vs_state(dec->base.context, NULL);
-   dec->base.context->bind_fs_state(dec->base.context, NULL);
+   dec->context->bind_vs_state(dec->context, NULL);
+   dec->context->bind_fs_state(dec->context, NULL);
 
-   dec->base.context->delete_depth_stencil_alpha_state(dec->base.context, 
dec->dsa);
-   dec->base.context->delete_sampler_state(dec->base.context, 
dec->sampler_ycbcr);
+   dec->context->delete_depth_stencil_alpha_state(dec->context, dec->dsa);
+   dec->context->delete_sampler_state(dec->context, dec->sampler_ycbcr);
 
vl_mc_cleanup(&dec->mc_y);
vl_mc_cleanup(&dec->mc_c);
@@ -426,8 +482,8 @@ vl_mpeg12_destroy(struct pipe_video_codec *decoder)
vl_zscan_cleanup(&dec->zscan_y);
vl_zscan_cleanup(&dec->zscan_c);
 
-   dec->base.context->delete_vertex_elements_state(dec->base.context, 
dec->ves_ycbcr);
-   dec->base.context->delete_vertex_elements_state(dec->base.context, 
dec->ves_mv);
+   dec->context->delete_vertex_elements_state(dec->context, dec->ves_ycbcr);
+   dec->context->delete_vertex_elements_state(dec->context, dec->ves_mv);
 
pipe_resource_reference(&dec->quads.buffer, NULL);
pipe_resou

Re: [Mesa-dev] [PATCH] st/vdpau: resolve delayed rendering for GL interop

[Grigori Goronzy]

On 06.11.2013 15:08, Christian König wrote:

We need to take/release the driver lock around this as well.

I've fixed this and pushed the result upstream. Any idea when your
deinterlacer is ready to hit the list as a patch?



Thanks for fixing this up.

The simple temporal deinterlacer should be almost good to go, I think. 
It's not perfect (no deinterlacer is), but usually much better than bob. 
In some cases motion is misdetected and combing remains; but I have not 
seen any motion adaptive deinterlacer without such issues so far.


I would love to still see the deinterlacer in Mesa 10.0, but I don't 
know if this is a realistic goal.


Best regards
Grigori


Thanks for the help,
Christian.

Am 06.11.2013 00:35, schrieb Grigori Goronzy:

Otherwise OutputSurface interop has funny results sometimes.
This fixes interop with the mpv media player.
---
  src/gallium/state_trackers/vdpau/output.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index def01c8..76c7312 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -734,5 +734,6 @@ struct pipe_resource
*vlVdpOutputSurfaceGallium(VdpOutputSurface surface)
 if (!vlsurface || !vlsurface->surface)
return NULL;
+   vlVdpResolveDelayedRendering(vlsurface->device, NULL, NULL);
 return vlsurface->surface->texture;
  }




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

[Mesa-dev] [PATCH] gallivm: fix indirect addressing of inputs

[sroland]

From: Roland Scheidegger 

We weren't adding the soa offsets when constructing the indices
for the gather functions. That meant that we were always returning
the data in the first element.
(Copied straight from the same fix for temps.)
While here fix up a couple of broken comments in the fetch functions,
plus don't name a straight float type float4 which is just confusing.
---
 src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |   45 ++-
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c 
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index e50f1d1..75f6def 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -993,11 +993,11 @@ emit_fetch_immediate(
   LLVMValueRef length_vec =
  lp_build_const_int_vec(bld->bld_base.base.gallivm, uint_bld->type,
 bld->bld_base.base.type.length);
-  LLVMValueRef index_vec;  /* index into the const buffer */
+  LLVMValueRef index_vec;  /* index into the immediate register array */
   LLVMValueRef imms_array;
   LLVMValueRef pixel_offsets;
   LLVMValueRef offsets[LP_MAX_VECTOR_LENGTH];
-  LLVMTypeRef float4_ptr_type;
+  LLVMTypeRef float_ptr_type;
   int i;
 
   /* build pixel offset vector: {0, 1, 2, 3, ...} */
@@ -1013,12 +1013,12 @@ emit_fetch_immediate(
   index_vec = lp_build_add(uint_bld, index_vec, pixel_offsets);
 
   /* cast imms_array pointer to float* */
-  float4_ptr_type = LLVMPointerType(
+  float_ptr_type = LLVMPointerType(
  LLVMFloatTypeInContext(bld->bld_base.base.gallivm->context), 0);
   imms_array = LLVMBuildBitCast(builder, bld->imms_array,
-float4_ptr_type, "");
+float_ptr_type, "");
 
-  /* Gather values from the temporary register array */
+  /* Gather values from the immediate register array */
   res = build_gather(&bld_base->base, imms_array, index_vec);
}
else {
@@ -1044,6 +1044,7 @@ emit_fetch_input(
struct gallivm_state *gallivm = bld->bld_base.base.gallivm;
LLVMBuilderRef builder = gallivm->builder;
struct lp_build_context *uint_bld = &bld_base->uint_bld;
+   struct lp_build_context *float_bld = &bld_base->base;
LLVMValueRef indirect_index = NULL;
LLVMValueRef res;
 
@@ -1059,21 +1060,31 @@ emit_fetch_input(
  lp_build_const_int_vec(gallivm, uint_bld->type, swizzle);
   LLVMValueRef length_vec =
  lp_build_const_int_vec(gallivm, uint_bld->type, 
bld->bld_base.base.type.length);
-  LLVMValueRef index_vec;  /* index into the const buffer */
+  LLVMValueRef index_vec;  /* index into the input reg array */
   LLVMValueRef inputs_array;
-  LLVMTypeRef float4_ptr_type;
+  LLVMValueRef pixel_offsets;
+  LLVMValueRef offsets[LP_MAX_VECTOR_LENGTH];
+  LLVMTypeRef float_ptr_type;
+  int i;
+
+  /* build pixel offset vector: {0, 1, 2, 3, ...} */
+  for (i = 0; i < float_bld->type.length; i++) {
+ offsets[i] = lp_build_const_int32(gallivm, i);
+  }
+  pixel_offsets = LLVMConstVector(offsets, float_bld->type.length);
 
   /* index_vec = (indirect_index * 4 + swizzle) * length */
   index_vec = lp_build_shl_imm(uint_bld, indirect_index, 2);
   index_vec = lp_build_add(uint_bld, index_vec, swizzle_vec);
   index_vec = lp_build_mul(uint_bld, index_vec, length_vec);
+  index_vec = lp_build_add(uint_bld, index_vec, pixel_offsets);
 
   /* cast inputs_array pointer to float* */
-  float4_ptr_type = 
LLVMPointerType(LLVMFloatTypeInContext(gallivm->context), 0);
+  float_ptr_type = 
LLVMPointerType(LLVMFloatTypeInContext(gallivm->context), 0);
   inputs_array = LLVMBuildBitCast(builder, bld->inputs_array,
- float4_ptr_type, "");
+  float_ptr_type, "");
 
-  /* Gather values from the temporary register array */
+  /* Gather values from the input register array */
   res = build_gather(&bld_base->base, inputs_array, index_vec);
} else {
   if (bld->indirect_files & (1 << TGSI_FILE_INPUT)) {
@@ -1117,9 +1128,9 @@ emit_fetch_gs_input(
 
if (reg->Register.Indirect) {
   attrib_index = get_indirect_index(bld,
-  reg->Register.File,
-  reg->Register.Index,
-  ®->Indirect);
+reg->Register.File,
+reg->Register.Index,
+®->Indirect);
} else {
   attrib_index = lp_build_const_int32(gallivm, reg->Register.Index);
}
@@ -1179,11 +1190,11 @@ emit_fetch_temporary(
   LLVMValueRef length_vec =
  lp_build_const_int_vec(bld->bld_base.base.gallivm, uint_

Re: [Mesa-dev] [PATCH] vl: use a separate context for shader based decode

[Christian König]

Ups, indeed. That line is still in my code directory not amended to the 
patch.


Thanks for the info, will send out a v2 soon. Anything else I should 
take care of?


Christian.

Am 06.11.2013 16:38, schrieb Aaron Watry:

I haven't looked in-depth at the rest of the patch, but I don't see
anywhere in vl_mpeg12_destroy that you are actually destroying the
context that you create in vl_create_mpeg12_decoder.  Would I be
correct in assuming that this is leaked memory?

--Aaron

On Wed, Nov 6, 2013 at 8:13 AM, Christian König  wrote:

From: Christian König 

This makes VDPAU thread save again.

Signed-off-by: Christian König 
---
  src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 180 ++-
  src/gallium/auxiliary/vl/vl_mpeg12_decoder.h |   1 +
  2 files changed, 120 insertions(+), 61 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c 
b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
index ca4eb3e..3777174 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
@@ -82,6 +82,63 @@ static const unsigned const_empty_block_mask_420[3][2][2] = {
 { { 0x01, 0x01 },  { 0x01, 0x01 } }
  };

+struct video_buffer_private
+{
+   struct pipe_sampler_view *sampler_view_planes[VL_NUM_COMPONENTS];
+   struct pipe_surface  *surfaces[VL_MAX_SURFACES];
+
+   struct vl_mpeg12_buffer *buffer;
+};
+
+static void
+vl_mpeg12_destroy_buffer(struct vl_mpeg12_buffer *buf);
+
+static void
+destroy_video_buffer_private(void *private)
+{
+   struct video_buffer_private *priv = private;
+   unsigned i;
+
+   for (i = 0; i < VL_NUM_COMPONENTS; ++i)
+  pipe_sampler_view_reference(&priv->sampler_view_planes[i], NULL);
+
+   for (i = 0; i < VL_MAX_SURFACES; ++i)
+  pipe_surface_reference(&priv->surfaces[i], NULL);
+
+   if (priv->buffer)
+  vl_mpeg12_destroy_buffer(priv->buffer);
+}
+
+static struct video_buffer_private *
+get_video_buffer_private(struct vl_mpeg12_decoder *dec, struct 
pipe_video_buffer *buf)
+{
+   struct pipe_context *pipe = dec->context;
+   struct video_buffer_private *priv;
+   struct pipe_sampler_view **sv;
+   struct pipe_surface **surf;
+   unsigned i;
+
+   priv = vl_video_buffer_get_associated_data(buf, &dec->base);
+   if (priv)
+  return priv;
+
+   priv = CALLOC_STRUCT(video_buffer_private);
+
+   sv = buf->get_sampler_view_planes(buf);
+   for (i = 0; i < VL_NUM_COMPONENTS; ++i)
+  if (sv[i])
+ priv->sampler_view_planes[i] = pipe->create_sampler_view(pipe, 
sv[i]->texture, sv[i]);
+
+   surf = buf->get_surfaces(buf);
+   for (i = 0; i < VL_MAX_SURFACES; ++i)
+  if (surf[i])
+ priv->surfaces[i] = pipe->create_surface(pipe, surf[i]->texture, 
surf[i]);
+
+   vl_video_buffer_set_associated_data(buf, &dec->base, priv, 
destroy_video_buffer_private);
+
+   return priv;
+}
+
  static bool
  init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct vl_mpeg12_buffer 
*buffer)
  {
@@ -103,7 +160,7 @@ init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct 
vl_mpeg12_buffer *buffer
 res_tmpl.usage = PIPE_USAGE_STREAM;
 res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW;

-   res = dec->base.context->screen->resource_create(dec->base.context->screen, 
&res_tmpl);
+   res = dec->context->screen->resource_create(dec->context->screen, 
&res_tmpl);
 if (!res)
goto error_source;

@@ -111,7 +168,7 @@ init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct 
vl_mpeg12_buffer *buffer
 memset(&sv_tmpl, 0, sizeof(sv_tmpl));
 u_sampler_view_default_template(&sv_tmpl, res, res->format);
 sv_tmpl.swizzle_r = sv_tmpl.swizzle_g = sv_tmpl.swizzle_b = 
sv_tmpl.swizzle_a = PIPE_SWIZZLE_RED;
-   buffer->zscan_source = 
dec->base.context->create_sampler_view(dec->base.context, res, &sv_tmpl);
+   buffer->zscan_source = dec->context->create_sampler_view(dec->context, res, 
&sv_tmpl);
 pipe_resource_reference(&res, NULL);
 if (!buffer->zscan_source)
goto error_sampler;
@@ -384,9 +441,8 @@ UploadYcbcrBlocks(struct vl_mpeg12_decoder *dec,
  }

  static void
-vl_mpeg12_destroy_buffer(void *buffer)
+vl_mpeg12_destroy_buffer(struct vl_mpeg12_buffer *buf)
  {
-   struct vl_mpeg12_buffer *buf = buffer;

 assert(buf);

@@ -407,11 +463,11 @@ vl_mpeg12_destroy(struct pipe_video_codec *decoder)
 assert(decoder);

 /* Asserted in softpipe_delete_fs_state() for some reason */
-   dec->base.context->bind_vs_state(dec->base.context, NULL);
-   dec->base.context->bind_fs_state(dec->base.context, NULL);
+   dec->context->bind_vs_state(dec->context, NULL);
+   dec->context->bind_fs_state(dec->context, NULL);

-   dec->base.context->delete_depth_stencil_alpha_state(dec->base.context, 
dec->dsa);
-   dec->base.context->delete_sampler_state(dec->base.context, 
dec->sampler_ycbcr);
+   dec->context->delete_depth_stencil_alpha_state(dec->context, dec->dsa);
+   dec->context->delete_sampler_state(dec->context, dec->sampler_ycbcr);

 vl_mc_cleanup(&dec->mc_y);
 vl_mc_cleanup(&dec-

Re: [Mesa-dev] [PATCH] gallivm: fix indirect addressing of inputs

[Jose Fonseca]

Looks good.  Though I thought we had fixed this once before.

Could you double check there are no similar issues with the remaining register 
files (output, etc)?

Jose

- Original Message -
> From: Roland Scheidegger 
> 
> We weren't adding the soa offsets when constructing the indices
> for the gather functions. That meant that we were always returning
> the data in the first element.
> (Copied straight from the same fix for temps.)
> While here fix up a couple of broken comments in the fetch functions,
> plus don't name a straight float type float4 which is just confusing.
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |   45
>  ++-
>  1 file changed, 28 insertions(+), 17 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> index e50f1d1..75f6def 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> @@ -993,11 +993,11 @@ emit_fetch_immediate(
>LLVMValueRef length_vec =
>   lp_build_const_int_vec(bld->bld_base.base.gallivm, uint_bld->type,
>  bld->bld_base.base.type.length);
> -  LLVMValueRef index_vec;  /* index into the const buffer */
> +  LLVMValueRef index_vec;  /* index into the immediate register array */
>LLVMValueRef imms_array;
>LLVMValueRef pixel_offsets;
>LLVMValueRef offsets[LP_MAX_VECTOR_LENGTH];
> -  LLVMTypeRef float4_ptr_type;
> +  LLVMTypeRef float_ptr_type;
>int i;
>  
>/* build pixel offset vector: {0, 1, 2, 3, ...} */
> @@ -1013,12 +1013,12 @@ emit_fetch_immediate(
>index_vec = lp_build_add(uint_bld, index_vec, pixel_offsets);
>  
>/* cast imms_array pointer to float* */
> -  float4_ptr_type = LLVMPointerType(
> +  float_ptr_type = LLVMPointerType(
>   LLVMFloatTypeInContext(bld->bld_base.base.gallivm->context), 0);
>imms_array = LLVMBuildBitCast(builder, bld->imms_array,
> -float4_ptr_type, "");
> +float_ptr_type, "");
>  
> -  /* Gather values from the temporary register array */
> +  /* Gather values from the immediate register array */
>res = build_gather(&bld_base->base, imms_array, index_vec);
> }
> else {
> @@ -1044,6 +1044,7 @@ emit_fetch_input(
> struct gallivm_state *gallivm = bld->bld_base.base.gallivm;
> LLVMBuilderRef builder = gallivm->builder;
> struct lp_build_context *uint_bld = &bld_base->uint_bld;
> +   struct lp_build_context *float_bld = &bld_base->base;
> LLVMValueRef indirect_index = NULL;
> LLVMValueRef res;
>  
> @@ -1059,21 +1060,31 @@ emit_fetch_input(
>   lp_build_const_int_vec(gallivm, uint_bld->type, swizzle);
>LLVMValueRef length_vec =
>   lp_build_const_int_vec(gallivm, uint_bld->type,
>   bld->bld_base.base.type.length);
> -  LLVMValueRef index_vec;  /* index into the const buffer */
> +  LLVMValueRef index_vec;  /* index into the input reg array */
>LLVMValueRef inputs_array;
> -  LLVMTypeRef float4_ptr_type;
> +  LLVMValueRef pixel_offsets;
> +  LLVMValueRef offsets[LP_MAX_VECTOR_LENGTH];
> +  LLVMTypeRef float_ptr_type;
> +  int i;
> +
> +  /* build pixel offset vector: {0, 1, 2, 3, ...} */
> +  for (i = 0; i < float_bld->type.length; i++) {
> + offsets[i] = lp_build_const_int32(gallivm, i);
> +  }
> +  pixel_offsets = LLVMConstVector(offsets, float_bld->type.length);
>  
>/* index_vec = (indirect_index * 4 + swizzle) * length */
>index_vec = lp_build_shl_imm(uint_bld, indirect_index, 2);
>index_vec = lp_build_add(uint_bld, index_vec, swizzle_vec);
>index_vec = lp_build_mul(uint_bld, index_vec, length_vec);
> +  index_vec = lp_build_add(uint_bld, index_vec, pixel_offsets);
>  
>/* cast inputs_array pointer to float* */
> -  float4_ptr_type =
> LLVMPointerType(LLVMFloatTypeInContext(gallivm->context), 0);
> +  float_ptr_type =
> LLVMPointerType(LLVMFloatTypeInContext(gallivm->context), 0);
>inputs_array = LLVMBuildBitCast(builder, bld->inputs_array,
> - float4_ptr_type, "");
> +  float_ptr_type, "");
>  
> -  /* Gather values from the temporary register array */
> +  /* Gather values from the input register array */
>res = build_gather(&bld_base->base, inputs_array, index_vec);
> } else {
>if (bld->indirect_files & (1 << TGSI_FILE_INPUT)) {
> @@ -1117,9 +1128,9 @@ emit_fetch_gs_input(
>  
> if (reg->Register.Indirect) {
>attrib_index = get_indirect_index(bld,
> -  reg->Register.File,
> -  reg->Register.Index,
> -  ®->Indirect);
> + 

Re: [Mesa-dev] [PATCH] mesa: for GLSL_DUMP_ON_ERROR, also dump the info log

[Jose Fonseca]

LGTM.

Jose

- Original Message -
> Since it's helpful to know why the shader did not compile.
> Also, call fflush() for Windows.
> ---
>  src/mesa/main/shaderapi.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> index 7da860d..1d9aac3 100644
> --- a/src/mesa/main/shaderapi.c
> +++ b/src/mesa/main/shaderapi.c
> @@ -825,6 +825,8 @@ compile_shader(struct gl_context *ctx, GLuint shaderObj)
>   fprintf(stderr, "GLSL source for %s shader %d:\n",
>   _mesa_glsl_shader_target_name(sh->Type), sh->Name);
>   fprintf(stderr, "%s\n", sh->Source);
> + fprintf(stderr, "Info Log:\n%s\n", sh->InfoLog);
> + fflush(stderr);
>}
>  
>if (ctx->Shader.Flags & GLSL_REPORT_ERRORS) {
> --
> 1.7.10.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vl: use a separate context for shader based decode

[Aaron Watry]

I haven't looked in-depth at the rest of the patch, but I don't see
anywhere in vl_mpeg12_destroy that you are actually destroying the
context that you create in vl_create_mpeg12_decoder.  Would I be
correct in assuming that this is leaked memory?

--Aaron

On Wed, Nov 6, 2013 at 8:13 AM, Christian König  wrote:
> From: Christian König 
>
> This makes VDPAU thread save again.
>
> Signed-off-by: Christian König 
> ---
>  src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 180 
> ++-
>  src/gallium/auxiliary/vl/vl_mpeg12_decoder.h |   1 +
>  2 files changed, 120 insertions(+), 61 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c 
> b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
> index ca4eb3e..3777174 100644
> --- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
> +++ b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
> @@ -82,6 +82,63 @@ static const unsigned const_empty_block_mask_420[3][2][2] 
> = {
> { { 0x01, 0x01 },  { 0x01, 0x01 } }
>  };
>
> +struct video_buffer_private
> +{
> +   struct pipe_sampler_view *sampler_view_planes[VL_NUM_COMPONENTS];
> +   struct pipe_surface  *surfaces[VL_MAX_SURFACES];
> +
> +   struct vl_mpeg12_buffer *buffer;
> +};
> +
> +static void
> +vl_mpeg12_destroy_buffer(struct vl_mpeg12_buffer *buf);
> +
> +static void
> +destroy_video_buffer_private(void *private)
> +{
> +   struct video_buffer_private *priv = private;
> +   unsigned i;
> +
> +   for (i = 0; i < VL_NUM_COMPONENTS; ++i)
> +  pipe_sampler_view_reference(&priv->sampler_view_planes[i], NULL);
> +
> +   for (i = 0; i < VL_MAX_SURFACES; ++i)
> +  pipe_surface_reference(&priv->surfaces[i], NULL);
> +
> +   if (priv->buffer)
> +  vl_mpeg12_destroy_buffer(priv->buffer);
> +}
> +
> +static struct video_buffer_private *
> +get_video_buffer_private(struct vl_mpeg12_decoder *dec, struct 
> pipe_video_buffer *buf)
> +{
> +   struct pipe_context *pipe = dec->context;
> +   struct video_buffer_private *priv;
> +   struct pipe_sampler_view **sv;
> +   struct pipe_surface **surf;
> +   unsigned i;
> +
> +   priv = vl_video_buffer_get_associated_data(buf, &dec->base);
> +   if (priv)
> +  return priv;
> +
> +   priv = CALLOC_STRUCT(video_buffer_private);
> +
> +   sv = buf->get_sampler_view_planes(buf);
> +   for (i = 0; i < VL_NUM_COMPONENTS; ++i)
> +  if (sv[i])
> + priv->sampler_view_planes[i] = pipe->create_sampler_view(pipe, 
> sv[i]->texture, sv[i]);
> +
> +   surf = buf->get_surfaces(buf);
> +   for (i = 0; i < VL_MAX_SURFACES; ++i)
> +  if (surf[i])
> + priv->surfaces[i] = pipe->create_surface(pipe, surf[i]->texture, 
> surf[i]);
> +
> +   vl_video_buffer_set_associated_data(buf, &dec->base, priv, 
> destroy_video_buffer_private);
> +
> +   return priv;
> +}
> +
>  static bool
>  init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct vl_mpeg12_buffer 
> *buffer)
>  {
> @@ -103,7 +160,7 @@ init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct 
> vl_mpeg12_buffer *buffer
> res_tmpl.usage = PIPE_USAGE_STREAM;
> res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW;
>
> -   res = 
> dec->base.context->screen->resource_create(dec->base.context->screen, 
> &res_tmpl);
> +   res = dec->context->screen->resource_create(dec->context->screen, 
> &res_tmpl);
> if (!res)
>goto error_source;
>
> @@ -111,7 +168,7 @@ init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct 
> vl_mpeg12_buffer *buffer
> memset(&sv_tmpl, 0, sizeof(sv_tmpl));
> u_sampler_view_default_template(&sv_tmpl, res, res->format);
> sv_tmpl.swizzle_r = sv_tmpl.swizzle_g = sv_tmpl.swizzle_b = 
> sv_tmpl.swizzle_a = PIPE_SWIZZLE_RED;
> -   buffer->zscan_source = 
> dec->base.context->create_sampler_view(dec->base.context, res, &sv_tmpl);
> +   buffer->zscan_source = dec->context->create_sampler_view(dec->context, 
> res, &sv_tmpl);
> pipe_resource_reference(&res, NULL);
> if (!buffer->zscan_source)
>goto error_sampler;
> @@ -384,9 +441,8 @@ UploadYcbcrBlocks(struct vl_mpeg12_decoder *dec,
>  }
>
>  static void
> -vl_mpeg12_destroy_buffer(void *buffer)
> +vl_mpeg12_destroy_buffer(struct vl_mpeg12_buffer *buf)
>  {
> -   struct vl_mpeg12_buffer *buf = buffer;
>
> assert(buf);
>
> @@ -407,11 +463,11 @@ vl_mpeg12_destroy(struct pipe_video_codec *decoder)
> assert(decoder);
>
> /* Asserted in softpipe_delete_fs_state() for some reason */
> -   dec->base.context->bind_vs_state(dec->base.context, NULL);
> -   dec->base.context->bind_fs_state(dec->base.context, NULL);
> +   dec->context->bind_vs_state(dec->context, NULL);
> +   dec->context->bind_fs_state(dec->context, NULL);
>
> -   dec->base.context->delete_depth_stencil_alpha_state(dec->base.context, 
> dec->dsa);
> -   dec->base.context->delete_sampler_state(dec->base.context, 
> dec->sampler_ycbcr);
> +   dec->context->delete_depth_stencil_alpha_state(dec->context, dec->dsa);
> +   dec->context->delete_sampler_state(dec->context, dec->sampler_ycbcr);
>
> vl_mc_cleanup(&dec->mc_y);
> 

Re: [Mesa-dev] [PATCH] vl: use a separate context for shader based decode

[Aaron Watry]

On Wed, Nov 6, 2013 at 8:13 AM, Christian König  wrote:
> From: Christian König 
>
> This makes VDPAU thread save again.
>
> Signed-off-by: Christian König 
> ---
>  src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 180 
> ++-
>  src/gallium/auxiliary/vl/vl_mpeg12_decoder.h |   1 +
>  2 files changed, 120 insertions(+), 61 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c 
> b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
> index ca4eb3e..3777174 100644
> --- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
> +++ b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
> @@ -82,6 +82,63 @@ static const unsigned const_empty_block_mask_420[3][2][2] 
> = {
> { { 0x01, 0x01 },  { 0x01, 0x01 } }
>  };
>
> +struct video_buffer_private
> +{
> +   struct pipe_sampler_view *sampler_view_planes[VL_NUM_COMPONENTS];
> +   struct pipe_surface  *surfaces[VL_MAX_SURFACES];
> +
> +   struct vl_mpeg12_buffer *buffer;
> +};
> +
> +static void
> +vl_mpeg12_destroy_buffer(struct vl_mpeg12_buffer *buf);
> +
> +static void
> +destroy_video_buffer_private(void *private)
> +{
> +   struct video_buffer_private *priv = private;
> +   unsigned i;
> +
> +   for (i = 0; i < VL_NUM_COMPONENTS; ++i)
> +  pipe_sampler_view_reference(&priv->sampler_view_planes[i], NULL);
> +
> +   for (i = 0; i < VL_MAX_SURFACES; ++i)
> +  pipe_surface_reference(&priv->surfaces[i], NULL);
> +
> +   if (priv->buffer)
> +  vl_mpeg12_destroy_buffer(priv->buffer);

Should we be freeing priv/private at the end here, or is this struct
still in use elsewhere?
I'm assuming that it's unused, given that this is the matching
destructor for get_video_buffer_private
where the struct is CALLOC'd.

I'm not too qualified to give a full review of this patch, but I had
memory leaks on my mind after some stuff I was working on last night.
I didn't see any others besides the one in my first email and this
one. I haven't run this through valgrind, so for the moment it's just
me looking for stuff that's fishy.

--Aaron

> +}
> +
> +static struct video_buffer_private *
> +get_video_buffer_private(struct vl_mpeg12_decoder *dec, struct 
> pipe_video_buffer *buf)
> +{
> +   struct pipe_context *pipe = dec->context;
> +   struct video_buffer_private *priv;
> +   struct pipe_sampler_view **sv;
> +   struct pipe_surface **surf;
> +   unsigned i;
> +
> +   priv = vl_video_buffer_get_associated_data(buf, &dec->base);
> +   if (priv)
> +  return priv;
> +
> +   priv = CALLOC_STRUCT(video_buffer_private);
> +
> +   sv = buf->get_sampler_view_planes(buf);
> +   for (i = 0; i < VL_NUM_COMPONENTS; ++i)
> +  if (sv[i])
> + priv->sampler_view_planes[i] = pipe->create_sampler_view(pipe, 
> sv[i]->texture, sv[i]);
> +
> +   surf = buf->get_surfaces(buf);
> +   for (i = 0; i < VL_MAX_SURFACES; ++i)
> +  if (surf[i])
> + priv->surfaces[i] = pipe->create_surface(pipe, surf[i]->texture, 
> surf[i]);
> +
> +   vl_video_buffer_set_associated_data(buf, &dec->base, priv, 
> destroy_video_buffer_private);
> +
> +   return priv;
> +}
> +
>  static bool
>  init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct vl_mpeg12_buffer 
> *buffer)
>  {
> @@ -103,7 +160,7 @@ init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct 
> vl_mpeg12_buffer *buffer
> res_tmpl.usage = PIPE_USAGE_STREAM;
> res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW;
>
> -   res = 
> dec->base.context->screen->resource_create(dec->base.context->screen, 
> &res_tmpl);
> +   res = dec->context->screen->resource_create(dec->context->screen, 
> &res_tmpl);
> if (!res)
>goto error_source;
>
> @@ -111,7 +168,7 @@ init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct 
> vl_mpeg12_buffer *buffer
> memset(&sv_tmpl, 0, sizeof(sv_tmpl));
> u_sampler_view_default_template(&sv_tmpl, res, res->format);
> sv_tmpl.swizzle_r = sv_tmpl.swizzle_g = sv_tmpl.swizzle_b = 
> sv_tmpl.swizzle_a = PIPE_SWIZZLE_RED;
> -   buffer->zscan_source = 
> dec->base.context->create_sampler_view(dec->base.context, res, &sv_tmpl);
> +   buffer->zscan_source = dec->context->create_sampler_view(dec->context, 
> res, &sv_tmpl);
> pipe_resource_reference(&res, NULL);
> if (!buffer->zscan_source)
>goto error_sampler;
> @@ -384,9 +441,8 @@ UploadYcbcrBlocks(struct vl_mpeg12_decoder *dec,
>  }
>
>  static void
> -vl_mpeg12_destroy_buffer(void *buffer)
> +vl_mpeg12_destroy_buffer(struct vl_mpeg12_buffer *buf)
>  {
> -   struct vl_mpeg12_buffer *buf = buffer;
>
> assert(buf);
>
> @@ -407,11 +463,11 @@ vl_mpeg12_destroy(struct pipe_video_codec *decoder)
> assert(decoder);
>
> /* Asserted in softpipe_delete_fs_state() for some reason */
> -   dec->base.context->bind_vs_state(dec->base.context, NULL);
> -   dec->base.context->bind_fs_state(dec->base.context, NULL);
> +   dec->context->bind_vs_state(dec->context, NULL);
> +   dec->context->bind_fs_state(dec->context, NULL);
>
> -   dec->base.context->delete_depth_stencil_alpha_state(dec->base.context, 
> 

[Mesa-dev] Problem getting a 32-bit X11 visual when porting from GLX to EGL

[Simon Farnsworth]

Hello all,

I'm attempting to port our GLX based code to EGL/X11, as a first step towards 
being ready for Wayland, and I've hit a snag. We use an X11 compositor to get 
translucent windows blending one atop the other, and I carefully select a 32 
bit RGBA visual (ID 0x64 on my system) instead of a 24 bit RGB visual (IDs 
0x21 and 0x22 on my system) to make this work.

I've got the code working on EGL/X11, but I can't find an EGLConfig that's 
based 
on visual 0x64 - they're all based on 0x21 (TrueColor) and 0x22 (DirectColor).

Looking at 
http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_x11.c#n671
 
suggests this is deliberate. I've tried the stupid patch below, but that makes 
all the TrueColor EGLConfigs into the RGBA visual 0x64, which is clearly not 
wanted based on the comment.

How should I proceed here? I can obviously go back to GLX, and migrate to EGL 
when I migrate to Wayland, but I'd prefer to move to EGL now while I'm still 
X11 based.

diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index a518db1..18fb81d 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -649,6 +649,37 @@ dri2_add_configs_for_visuals(struct dri2_egl_display 
*dri2_dpy,
   EGL_SWAP_BEHAVIOR_PRESERVED_BIT;
 
while (d.rem > 0) {
+  if (d.data->depth != 32) {
+ xcb_depth_next(&d);
+ continue;
+  }
+  EGLBoolean class_added[6] = { 0, };
+
+  visuals = xcb_depth_visuals(d.data);
+  for (i = 0; i < xcb_depth_visuals_length(d.data); i++) {
+if (class_added[visuals[i]._class])
+   continue;
+
+class_added[visuals[i]._class] = EGL_TRUE;
+for (j = 0; dri2_dpy->driver_configs[j]; j++) {
+config_attrs[1] = visuals[i].visual_id;
+config_attrs[3] = visuals[i]._class;
+
+rgba_masks[0] = visuals[i].red_mask;
+rgba_masks[1] = visuals[i].green_mask;
+rgba_masks[2] = visuals[i].blue_mask;
+rgba_masks[3] =
+   ~(rgba_masks[0] | rgba_masks[1] | rgba_masks[2]);
+   dri2_add_config(disp, dri2_dpy->driver_configs[j], id++,
+   surface_type, config_attrs, rgba_masks);
+}
+  }
+
+  xcb_depth_next(&d);
+   }
+
+   d = xcb_screen_allowed_depths_iterator(s.data);
+   while (d.rem > 0) {
   EGLBoolean class_added[6] = { 0, };
 
   visuals = xcb_depth_visuals(d.data);


-- 
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 6/6] st/egl: fix drm surface size init

[Lucas Stach]

Signed-off-by: Lucas Stach 
---
 src/gallium/state_trackers/egl/drm/modeset.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/egl/drm/modeset.c 
b/src/gallium/state_trackers/egl/drm/modeset.c
index dc71a761053b..11b6db1949c6 100644
--- a/src/gallium/state_trackers/egl/drm/modeset.c
+++ b/src/gallium/state_trackers/egl/drm/modeset.c
@@ -311,7 +311,8 @@ drm_display_create_surface_from_resource(struct 
native_display *ndpy,
  PIPE_BIND_SAMPLER_VIEW |
  PIPE_BIND_DISPLAY_TARGET |
  PIPE_BIND_SCANOUT);
-   
+
+   resource_surface_set_size(drmsurf->rsurf, drmsurf->width, drmsurf->height);
resource_surface_import_resource(drmsurf->rsurf, natt, resource);
 
drmsurf->base.destroy = drm_surface_destroy;
-- 
1.8.4.rc3

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

[Mesa-dev] [PATCH 2/6] gallium/targets: build freedreno pipe

[Lucas Stach]

Signed-off-by: Lucas Stach 
---
 src/gallium/targets/pipe-loader/Makefile.am  | 16 
 src/gallium/targets/pipe-loader/pipe_freedreno.c | 21 +
 2 files changed, 37 insertions(+)
 create mode 100644 src/gallium/targets/pipe-loader/pipe_freedreno.c

diff --git a/src/gallium/targets/pipe-loader/Makefile.am 
b/src/gallium/targets/pipe-loader/Makefile.am
index e6772b8e3083..234da336a8f8 100644
--- a/src/gallium/targets/pipe-loader/Makefile.am
+++ b/src/gallium/targets/pipe-loader/Makefile.am
@@ -45,6 +45,22 @@ PIPE_LIBS = \
-lpthread \
-lm
 
+if HAVE_GALLIUM_FREEDRENO
+pipe_LTLIBRARIES += pipe_freedreno.la
+pipe_freedreno_la_SOURCES = pipe_freedreno.c
+nodist_EXTRA_pipe_freedreno_la_SOURCES = dummy.cpp
+pipe_freedreno_la_LIBADD = \
+   $(PIPE_LIBS) \
+   $(top_builddir)/src/gallium/winsys/freedreno/drm/libfreedrenodrm.la \
+   $(top_builddir)/src/gallium/drivers/freedreno/libfreedreno.la \
+   $(FREEDRENO_LIBS)
+pipe_freedreno_la_LDFLAGS = -no-undefined -avoid-version -module
+if HAVE_MESA_LLVM
+pipe_freedreno_la_LIBADD += $(LLVM_LIBS)
+pipe_freedreno_la_LDFLAGS += $(LLVM_LDFLAGS)
+endif
+endif
+
 if HAVE_GALLIUM_I915
 pipe_LTLIBRARIES += pipe_i915.la
 pipe_i915_la_SOURCES = pipe_i915.c
diff --git a/src/gallium/targets/pipe-loader/pipe_freedreno.c 
b/src/gallium/targets/pipe-loader/pipe_freedreno.c
new file mode 100644
index ..72d24ba4428b
--- /dev/null
+++ b/src/gallium/targets/pipe-loader/pipe_freedreno.c
@@ -0,0 +1,21 @@
+
+#include "target-helpers/inline_debug_helper.h"
+#include "state_tracker/drm_driver.h"
+#include "freedreno/drm/freedreno_drm_public.h"
+
+static struct pipe_screen *
+create_screen(int fd)
+{
+   struct pipe_screen *screen;
+
+   screen = fd_drm_screen_create(fd);
+   if (!screen)
+  return NULL;
+
+   screen = debug_screen_wrap(screen);
+
+   return screen;
+}
+
+PUBLIC
+DRM_DRIVER_DESCRIPTOR("freedreno", "freedreno", create_screen, NULL)
-- 
1.8.4.rc3

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

[Mesa-dev] [PATCH 3/6] gallium: pipe-loader: make aware of platform DRM devices

[Lucas Stach]

Allows to load gallium pipes for ARM DRM drivers.

Signed-off-by: Lucas Stach 
---
 include/platform_ids/platform_driver_map.h | 18 
 src/gallium/auxiliary/pipe-loader/pipe_loader.h|  1 +
 .../auxiliary/pipe-loader/pipe_loader_drm.c| 53 ++
 3 files changed, 62 insertions(+), 10 deletions(-)
 create mode 100644 include/platform_ids/platform_driver_map.h

diff --git a/include/platform_ids/platform_driver_map.h 
b/include/platform_ids/platform_driver_map.h
new file mode 100644
index ..c428b81349e6
--- /dev/null
+++ b/include/platform_ids/platform_driver_map.h
@@ -0,0 +1,18 @@
+#ifndef _PLATFORM_DRIVER_MAP_H_
+#define _PLATFORM_DRIVER_MAP_H_
+
+#include 
+
+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
+#endif
+
+static const struct {
+   const char *driver;
+   const char **platform_ids;
+   int num_platform_ids;
+} platform_driver_map[] = {
+   { NULL, NULL, 0 }
+};
+
+#endif /* _PLATFORM_DRIVER_MAP_H_ */
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.h 
b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
index 444bdf1751f9..e915c6380185 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.h
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.h
@@ -44,6 +44,7 @@ struct pipe_screen;
 enum pipe_loader_device_type {
PIPE_LOADER_DEVICE_SOFTWARE,
PIPE_LOADER_DEVICE_PCI,
+   PIPE_LOADER_DEVICE_PLATFORM,
NUM_PIPE_LOADER_DEVICE_TYPES
 };
 
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
index 339d7bf10b67..908beac24cb4 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
@@ -50,6 +50,7 @@
 
 #define DRIVER_MAP_GALLIUM_ONLY
 #include "pci_ids/pci_id_driver_map.h"
+#include "platform_ids/platform_driver_map.h"
 
 struct pipe_loader_drm_device {
struct pipe_loader_device base;
@@ -88,6 +89,7 @@ find_drm_pci_id(struct pipe_loader_drm_device *ddev)
   &ddev->base.u.pci.chip_id) != 2)
   goto fail;
 
+   ddev->base.type = PIPE_LOADER_DEVICE_PCI;
return TRUE;
 
   fail:
@@ -100,7 +102,7 @@ find_drm_pci_id(struct pipe_loader_drm_device *ddev)
 }
 
 static boolean
-find_drm_driver_name(struct pipe_loader_drm_device *ddev)
+find_drm_pci_driver_name(struct pipe_loader_drm_device *ddev)
 {
struct pipe_loader_device *dev = &ddev->base;
int i, j;
@@ -128,6 +130,36 @@ find_drm_driver_name(struct pipe_loader_drm_device *ddev)
return TRUE;
 }
 
+static boolean
+find_drm_platform_driver(struct pipe_loader_drm_device *ddev)
+{
+   char *driver = NULL;
+   drmVersionPtr version;
+   int i, j;
+
+   version = drmGetVersion(ddev->fd);
+   if (!version)
+  return FALSE;
+
+   driver = strndup(version->name, version->name_len);
+   drmFreeVersion(version);
+
+   for (i = 0; platform_driver_map[i].driver; i++) {
+  for (j = 0; j < platform_driver_map[i].num_platform_ids; j++) {
+ if (strcmp(driver, platform_driver_map[i].platform_ids[j]) == 0) {
+ddev->base.driver_name = platform_driver_map[i].driver;
+ddev->base.type = PIPE_LOADER_DEVICE_PLATFORM;
+
+free(driver);
+return TRUE;
+ }
+  }
+   }
+
+   free(driver);
+   return FALSE;
+}
+
 static struct pipe_loader_ops pipe_loader_drm_ops;
 
 static void
@@ -188,22 +220,23 @@ pipe_loader_drm_probe_fd(struct pipe_loader_device **dev, 
int fd)
 {
struct pipe_loader_drm_device *ddev = CALLOC_STRUCT(pipe_loader_drm_device);
 
-   ddev->base.type = PIPE_LOADER_DEVICE_PCI;
ddev->base.ops = &pipe_loader_drm_ops;
ddev->fd = fd;
 
pipe_loader_drm_x_auth(fd);
 
-   if (!find_drm_pci_id(ddev))
-  goto fail;
-
-   if (!find_drm_driver_name(ddev))
-  goto fail;
+   if (find_drm_pci_id(ddev)) {
+  if (find_drm_pci_driver_name(ddev)) {
+  *dev = &ddev->base;
+  return TRUE;
+  }
+   }
 
-   *dev = &ddev->base;
-   return TRUE;
+   if (find_drm_platform_driver(ddev)) {
+  *dev = &ddev->base;
+  return TRUE;
+   }
 
-  fail:
FREE(ddev);
return FALSE;
 }
-- 
1.8.4.rc3

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

[Mesa-dev] [PATCH 5/6] gallium: gbm/egl: support GBM surface extensions on DRM

[Lucas Stach]

Let's applications like Weston create EGL onscreen-surfaces
on bare DRM devices.

Signed-off-by: Lucas Stach 
---
 src/gallium/state_trackers/egl/drm/native_drm.c| 11 ++
 src/gallium/state_trackers/gbm/gbm_drm.c   | 44 ++
 .../state_trackers/gbm/gbm_gallium_drmint.h| 12 ++
 3 files changed, 67 insertions(+)

diff --git a/src/gallium/state_trackers/egl/drm/native_drm.c 
b/src/gallium/state_trackers/egl/drm/native_drm.c
index c82bbe4d7417..10a77603d2aa 100644
--- a/src/gallium/state_trackers/egl/drm/native_drm.c
+++ b/src/gallium/state_trackers/egl/drm/native_drm.c
@@ -83,6 +83,7 @@ drm_display_get_configs(struct native_display *ndpy, int 
*num_configs)
   }
 
   nconf->color_format = format;
+  nconf->window_bit = TRUE;
 
   /* support KMS */
   if (drmdpy->resources)
@@ -211,6 +212,15 @@ drm_create_pixmap_surface(struct native_display *ndpy,
return drm_display_create_surface_from_resource(ndpy, bo->resource);
 }
 
+static struct native_surface *
+drm_create_window_surface(struct native_display *ndpy,
+EGLNativeWindowType win,
+const struct native_config *nconf)
+{
+   struct gbm_gallium_drm_surface *surf = (void *) win;
+   return drm_display_create_surface_from_resource(ndpy, surf->bo->resource);
+}
+
 static boolean
 drm_display_init_screen(struct native_display *ndpy)
 {
@@ -246,6 +256,7 @@ drm_create_display(struct gbm_gallium_drm_device *gbmdrm, 
int own_gbm,
drmdpy->base.get_configs = drm_display_get_configs;
 
drmdpy->base.create_pixmap_surface = drm_create_pixmap_surface;
+   drmdpy->base.create_window_surface = drm_create_window_surface;
 
drmdpy->base.buffer = &drm_display_buffer;
 #ifdef HAVE_WAYLAND_BACKEND
diff --git a/src/gallium/state_trackers/gbm/gbm_drm.c 
b/src/gallium/state_trackers/gbm/gbm_drm.c
index 725f12f6dad5..ad1c4a5c5639 100644
--- a/src/gallium/state_trackers/gbm/gbm_drm.c
+++ b/src/gallium/state_trackers/gbm/gbm_drm.c
@@ -218,6 +218,47 @@ gbm_gallium_drm_bo_create(struct gbm_device *gbm,
return &bo->base.base;
 }
 
+static struct gbm_surface *
+gbm_gallium_drm_surface_create(struct gbm_device *gbm,
+   uint32_t width, uint32_t height,
+   uint32_t format, uint32_t flags)
+{
+   struct gbm_gallium_drm_surface *surf;
+
+   surf = calloc(1, sizeof *surf);
+   if (surf == NULL)
+  return NULL;
+
+   surf->base.gbm = gbm;
+   surf->base.width = width;
+   surf->base.height = height;
+   surf->base.format = format;
+   surf->base.flags = flags;
+
+   surf->bo = gbm_gallium_drm_bo_create(gbm, width, height, format,
+GBM_BO_USE_RENDERING);
+
+   return &surf->base;
+}
+
+static void
+gbm_gallium_drm_surface_destroy(struct gbm_surface *_surf)
+{
+   struct gbm_gallium_drm_surface *surf = gbm_gallium_drm_surface(_surf);
+
+   gbm_gallium_drm_bo_destroy(&surf->bo->base.base);
+
+   free(surf);
+}
+
+static struct gbm_bo *
+gbm_gallium_drm_lock_front_buffer(struct gbm_surface *_surf)
+{
+   struct gbm_gallium_drm_surface *surf = gbm_gallium_drm_surface(_surf);
+
+   return surf->bo;
+}
+
 static void
 gbm_gallium_drm_destroy(struct gbm_device *gbm)
 {
@@ -240,6 +281,9 @@ gbm_gallium_drm_device_create(int fd)
gdrm->base.base.bo_import = gbm_gallium_drm_bo_import;
gdrm->base.base.bo_destroy = gbm_gallium_drm_bo_destroy;
gdrm->base.base.is_format_supported = gbm_gallium_drm_is_format_supported;
+   gdrm->base.base.surface_create = gbm_gallium_drm_surface_create;
+   gdrm->base.base.surface_destroy = gbm_gallium_drm_surface_destroy;
+   gdrm->base.base.surface_lock_front_buffer = 
gbm_gallium_drm_lock_front_buffer;
gdrm->base.base.destroy = gbm_gallium_drm_destroy;
 
gdrm->base.type = GBM_DRM_DRIVER_TYPE_GALLIUM;
diff --git a/src/gallium/state_trackers/gbm/gbm_gallium_drmint.h 
b/src/gallium/state_trackers/gbm/gbm_gallium_drmint.h
index a5d6d834737b..e873e9174d45 100644
--- a/src/gallium/state_trackers/gbm/gbm_gallium_drmint.h
+++ b/src/gallium/state_trackers/gbm/gbm_gallium_drmint.h
@@ -53,6 +53,12 @@ struct gbm_gallium_drm_bo {
struct pipe_resource *resource;
 };
 
+struct gbm_gallium_drm_surface {
+   struct gbm_surface base;
+
+   struct gbm_gallium_drm_bo *bo;
+};
+
 static inline struct gbm_gallium_drm_device *
 gbm_gallium_drm_device(struct gbm_device *gbm)
 {
@@ -65,6 +71,12 @@ gbm_gallium_drm_bo(struct gbm_bo *bo)
return (struct gbm_gallium_drm_bo *) bo;
 }
 
+static inline struct gbm_gallium_drm_surface *
+gbm_gallium_drm_surface(struct gbm_surface *surface)
+{
+   return (struct gbm_gallium_drm_surface *) surface;
+}
+
 struct gbm_device *
 gbm_gallium_drm_device_create(int fd);
 
-- 
1.8.4.rc3

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

[Mesa-dev] [PATCH 0/6] radeon: Plug some memory leaks

[Aaron Watry]

I decided to have some fun and hooked valgrind up to my 7850 while running
a few OpenCL tests in piglit. This is the first batch of fixes.

Aaron Watry (6):
  radeon/llvm: fix spelling error
  radeon/llvm: Free libelf resources
  radeon/llvm: Free created llvm memory buffer
  radeonsi/compute: Free program and program.kernels on shutdown
  radeonsi/compute: Dispose of LLVM module after compiling kernels
  gallium/pipe_loader: un-reference udev resources when we're done with
them.

 src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c |  3 +++
 src/gallium/drivers/radeon/radeon_llvm_emit.c   |  3 +++
 src/gallium/drivers/radeon/radeon_llvm_util.c   |  1 +
 src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c |  2 +-
 src/gallium/drivers/radeonsi/radeonsi_compute.c | 17 -
 5 files changed, 24 insertions(+), 2 deletions(-)


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

[Mesa-dev] [PATCH 5/6] radeonsi/compute: Dispose of LLVM module after compiling kernels

[Aaron Watry]

---
 src/gallium/drivers/radeonsi/radeonsi_compute.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/radeonsi/radeonsi_compute.c 
b/src/gallium/drivers/radeonsi/radeonsi_compute.c
index 28a3f17..6531bcd 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_compute.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_compute.c
@@ -49,6 +49,7 @@ static void *radeonsi_create_compute_state(
LLVMModuleRef mod = radeon_llvm_get_kernel_module(i, code,
header->num_bytes);
si_compile_llvm(rctx, &program->kernels[i], mod);
+LLVMDisposeModule(mod);
}
 
return program;
-- 
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/6] radeon/llvm: fix spelling error

[Aaron Watry]

---
 src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c 
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 286ccdd..57026bf 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -1379,7 +1379,7 @@ void radeon_llvm_finalize_module(struct 
radeon_llvm_context * ctx)
LLVMAddAggressiveDCEPass(gallivm->passmgr);
LLVMAddCFGSimplificationPass(gallivm->passmgr);
 
-   /* Run the passs */
+   /* Run the pass */
LLVMRunFunctionPassManager(gallivm->passmgr, ctx->main_fn);
 
LLVMDisposeBuilder(gallivm->builder);
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 6/6] gallium/pipe_loader: un-reference udev resources when we're done with them.

[Aaron Watry]

---
 src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
index 339d7bf..927fb24 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
@@ -88,6 +88,9 @@ find_drm_pci_id(struct pipe_loader_drm_device *ddev)
   &ddev->base.u.pci.chip_id) != 2)
   goto fail;
 
+   udev_device_unref(device);
+   udev_unref(udev);
+
return TRUE;
 
   fail:
-- 
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/6] radeon/llvm: Free created llvm memory buffer

[Aaron Watry]

---
 src/gallium/drivers/radeon/radeon_llvm_util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c 
b/src/gallium/drivers/radeon/radeon_llvm_util.c
index 7192dee..aec5d67 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_util.c
+++ b/src/gallium/drivers/radeon/radeon_llvm_util.c
@@ -42,6 +42,7 @@ LLVMModuleRef radeon_llvm_parse_bitcode(const unsigned char * 
bitcode,
buf = LLVMCreateMemoryBufferWithMemoryRangeCopy((const char*)bitcode,
bitcode_len, "radeon");
LLVMParseBitcodeInContext(ctx, buf, &module, NULL);
+LLVMDisposeMemoryBuffer(buf);
return module;
 }
 
-- 
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/6] radeon/llvm: Free libelf resources

[Aaron Watry]

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

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

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

[Mesa-dev] [PATCH 4/6] radeonsi/compute: Free program and program.kernels on shutdown

[Aaron Watry]

---
 src/gallium/drivers/radeonsi/radeonsi_compute.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/radeonsi_compute.c 
b/src/gallium/drivers/radeonsi/radeonsi_compute.c
index 265dbd7..28a3f17 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_compute.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_compute.c
@@ -236,7 +236,21 @@ static void radeonsi_launch_grid(
 }
 
 
-static void si_delete_compute_state(struct pipe_context *ctx, void* state){}
+static void si_delete_compute_state(struct pipe_context *ctx, void* state){
+struct si_pipe_compute *program = (struct si_pipe_compute *)state;
+
+if (!state) {
+return;
+}
+
+if (program->kernels) {
+FREE(program->kernels);
+}
+
+//And then free the program itself.
+FREE(program);
+}
+
 static void si_set_compute_resources(struct pipe_context * ctx_,
unsigned start, unsigned count,
struct pipe_surface ** surfaces) { }
-- 
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/6] pipe-loader: add freedreno platform IDs

[Lucas Stach]

Signed-off-by: Lucas Stach 
---
 include/platform_ids/platform_driver_map.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/platform_ids/platform_driver_map.h 
b/include/platform_ids/platform_driver_map.h
index c428b81349e6..68595ef0a2f7 100644
--- a/include/platform_ids/platform_driver_map.h
+++ b/include/platform_ids/platform_driver_map.h
@@ -7,11 +7,16 @@
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
 #endif
 
+static const char *freedreno_platform_ids[] = {
+   "msm",
+};
+
 static const struct {
const char *driver;
const char **platform_ids;
int num_platform_ids;
 } platform_driver_map[] = {
+   { "freedreno", freedreno_platform_ids, ARRAY_SIZE(freedreno_platform_ids)},
{ NULL, NULL, 0 }
 };
 
-- 
1.8.4.rc3

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

[Mesa-dev] [PATCH 1/6] gbm: Support non-PCI devices

[Lucas Stach]

From: Thierry Reding 

When probing non-PCI DRM devices, such as those found in a lot of SoCs,
GBM errors out because it expects the device to have an associated PCI
ID which can be used to lookup the driver name in a table.

This patch removes this restriction by using the driver name from the
drmVersion structure as a fallback if a device doesn't have an
associated PCI ID.

Signed-off-by: Thierry Reding 
Tested-by: Rob Clark 
---
 src/gbm/backends/dri/driver_name.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/src/gbm/backends/dri/driver_name.c 
b/src/gbm/backends/dri/driver_name.c
index 2ed209fa438b..be74023d6c3a 100644
--- a/src/gbm/backends/dri/driver_name.c
+++ b/src/gbm/backends/dri/driver_name.c
@@ -30,6 +30,7 @@
 #include 
 
 #include 
+#include 
 
 #include "gbm_driint.h"
 #define DRIVER_MAP_DRI2_ONLY
@@ -43,6 +44,7 @@ dri_fd_get_driver_name(int fd)
const char *pci_id;
char *driver = NULL;
int vendor_id, chip_id, i, j;
+   drmVersionPtr version;
 
udev = udev_new();
device = _gbm_udev_device_new_from_fd(udev, fd);
@@ -56,9 +58,22 @@ dri_fd_get_driver_name(int fd)
}
 
pci_id = udev_device_get_property_value(parent, "PCI_ID");
-   if (pci_id == NULL ||
-   sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
-  fprintf(stderr, "gbm: malformed or no PCI ID");
+   if (pci_id == NULL) {
+  version = drmGetVersion(fd);
+  if (!version) {
+ fprintf(stderr, "gbm: cannot get DRM module version\n");
+ goto out;
+  }
+
+  driver = strndup(version->name, version->name_len);
+  _gbm_log("using driver %s for %d\n", driver, fd);
+
+  drmFreeVersion(version);
+  goto out;
+   }
+
+   if (sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
+  fprintf(stderr, "gbm: malformed PCI ID");
   goto out;
}
 
-- 
1.8.4.rc3

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

[Mesa-dev] [PATCH] vl: use a separate context for shader based decode v2

[Christian König]

From: Christian König 

This makes VDPAU thread save again.

v2: fix some memory leaks reported by Aaron Watry.

Signed-off-by: Christian König 
---
 src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 184 ++-
 src/gallium/auxiliary/vl/vl_mpeg12_decoder.h |   1 +
 2 files changed, 124 insertions(+), 61 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c 
b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
index ca4eb3e..1e69108 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
@@ -82,6 +82,65 @@ static const unsigned const_empty_block_mask_420[3][2][2] = {
{ { 0x01, 0x01 },  { 0x01, 0x01 } }
 };
 
+struct video_buffer_private
+{
+   struct pipe_sampler_view *sampler_view_planes[VL_NUM_COMPONENTS];
+   struct pipe_surface  *surfaces[VL_MAX_SURFACES];
+
+   struct vl_mpeg12_buffer *buffer;
+};
+
+static void
+vl_mpeg12_destroy_buffer(struct vl_mpeg12_buffer *buf);
+
+static void
+destroy_video_buffer_private(void *private)
+{
+   struct video_buffer_private *priv = private;
+   unsigned i;
+
+   for (i = 0; i < VL_NUM_COMPONENTS; ++i)
+  pipe_sampler_view_reference(&priv->sampler_view_planes[i], NULL);
+
+   for (i = 0; i < VL_MAX_SURFACES; ++i)
+  pipe_surface_reference(&priv->surfaces[i], NULL);
+
+   if (priv->buffer)
+  vl_mpeg12_destroy_buffer(priv->buffer);
+
+   FREE(priv);
+}
+
+static struct video_buffer_private *
+get_video_buffer_private(struct vl_mpeg12_decoder *dec, struct 
pipe_video_buffer *buf)
+{
+   struct pipe_context *pipe = dec->context;
+   struct video_buffer_private *priv;
+   struct pipe_sampler_view **sv;
+   struct pipe_surface **surf;
+   unsigned i;
+
+   priv = vl_video_buffer_get_associated_data(buf, &dec->base);
+   if (priv)
+  return priv;
+
+   priv = CALLOC_STRUCT(video_buffer_private);
+
+   sv = buf->get_sampler_view_planes(buf);
+   for (i = 0; i < VL_NUM_COMPONENTS; ++i)
+  if (sv[i])
+ priv->sampler_view_planes[i] = pipe->create_sampler_view(pipe, 
sv[i]->texture, sv[i]);
+
+   surf = buf->get_surfaces(buf);
+   for (i = 0; i < VL_MAX_SURFACES; ++i)
+  if (surf[i])
+ priv->surfaces[i] = pipe->create_surface(pipe, surf[i]->texture, 
surf[i]);
+
+   vl_video_buffer_set_associated_data(buf, &dec->base, priv, 
destroy_video_buffer_private);
+
+   return priv;
+}
+
 static bool
 init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct vl_mpeg12_buffer 
*buffer)
 {
@@ -103,7 +162,7 @@ init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct 
vl_mpeg12_buffer *buffer
res_tmpl.usage = PIPE_USAGE_STREAM;
res_tmpl.bind = PIPE_BIND_SAMPLER_VIEW;
 
-   res = dec->base.context->screen->resource_create(dec->base.context->screen, 
&res_tmpl);
+   res = dec->context->screen->resource_create(dec->context->screen, 
&res_tmpl);
if (!res)
   goto error_source;
 
@@ -111,7 +170,7 @@ init_zscan_buffer(struct vl_mpeg12_decoder *dec, struct 
vl_mpeg12_buffer *buffer
memset(&sv_tmpl, 0, sizeof(sv_tmpl));
u_sampler_view_default_template(&sv_tmpl, res, res->format);
sv_tmpl.swizzle_r = sv_tmpl.swizzle_g = sv_tmpl.swizzle_b = 
sv_tmpl.swizzle_a = PIPE_SWIZZLE_RED;
-   buffer->zscan_source = 
dec->base.context->create_sampler_view(dec->base.context, res, &sv_tmpl);
+   buffer->zscan_source = dec->context->create_sampler_view(dec->context, res, 
&sv_tmpl);
pipe_resource_reference(&res, NULL);
if (!buffer->zscan_source)
   goto error_sampler;
@@ -384,9 +443,8 @@ UploadYcbcrBlocks(struct vl_mpeg12_decoder *dec,
 }
 
 static void
-vl_mpeg12_destroy_buffer(void *buffer)
+vl_mpeg12_destroy_buffer(struct vl_mpeg12_buffer *buf)
 {
-   struct vl_mpeg12_buffer *buf = buffer;
 
assert(buf);
 
@@ -407,11 +465,11 @@ vl_mpeg12_destroy(struct pipe_video_codec *decoder)
assert(decoder);
 
/* Asserted in softpipe_delete_fs_state() for some reason */
-   dec->base.context->bind_vs_state(dec->base.context, NULL);
-   dec->base.context->bind_fs_state(dec->base.context, NULL);
+   dec->context->bind_vs_state(dec->context, NULL);
+   dec->context->bind_fs_state(dec->context, NULL);
 
-   dec->base.context->delete_depth_stencil_alpha_state(dec->base.context, 
dec->dsa);
-   dec->base.context->delete_sampler_state(dec->base.context, 
dec->sampler_ycbcr);
+   dec->context->delete_depth_stencil_alpha_state(dec->context, dec->dsa);
+   dec->context->delete_sampler_state(dec->context, dec->sampler_ycbcr);
 
vl_mc_cleanup(&dec->mc_y);
vl_mc_cleanup(&dec->mc_c);
@@ -426,8 +484,8 @@ vl_mpeg12_destroy(struct pipe_video_codec *decoder)
vl_zscan_cleanup(&dec->zscan_y);
vl_zscan_cleanup(&dec->zscan_c);
 
-   dec->base.context->delete_vertex_elements_state(dec->base.context, 
dec->ves_ycbcr);
-   dec->base.context->delete_vertex_elements_state(dec->base.context, 
dec->ves_mv);
+   dec->context->delete_vertex_elements_state(dec->context, dec->ves_ycbcr);
+   dec->context->delete_vertex_elements_state(dec->context, dec->ves_mv);
 

Re: [Mesa-dev] 9.2.2 OSMesa classic 80 new regressions in VTK

[burlen]

On 11/05/2013 09:42 AM, Ian Romanick wrote:

On 11/05/2013 09:32 AM, burlen wrote:

Upgrading from 9.2.0 to 9.2.2 with OSMesa classic I'm seeing 80 new
regressions in VTK.
http://open.cdash.org/viewTest.php?onlyfailed&buildid=3087854
click "Failed" to see an image diff. Maybe related to line rendering?
Any chance a mesa developer could investigate?

Can you bisect?
OK, by git bisect I've noticed that this isn't a regression in between 
9.2 and 9.2.2! The problem is because in my latest dashboard builds I'm 
using


   --with-osmesa-bits=32

which is how I usually deploy osmesa because we zbuffer precision issues 
in the past. Removing this option this tests all pass again.


Unfortunately I don't know how long this option has been a problem since 
the few VTK dashboards that test Mesa have never as far as I know built 
withh 32 bits. :-(


does this help you guys at all?


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

Re: [Mesa-dev] Fix crashes with static LLVM

[Kai Wasserbäch]

Dear Tom,
Tom Stellard schrieb am 06.11.2013 01:24:
> On Wed, Oct 23, 2013 at 04:26:18PM -0400, Tom Stellard wrote:
>> The attached patches introduce linker scripts to the pipe-loader and
>> egl-static targets.  The linker scripts prevents these targets from
>> exporting LLVM (and other) symbols that they shouldn't be.  This fixes
>> several crashes in the radeon drivers when statically linking LLVM.
>>
>> With these patches: clover, glamor, and the egl demos from the mesa-demo 
>> repo all
>> work for me with statically linked LLVM, but I would like to get 
>> confirmation that
>> this works for other people too, so if you care about these use cases, 
>> please test
>> and let me know the results.
>>
> 
> I have gotten some positive feedback on these patches from testers, so
> if there are no objections, I will push these tomorrow.

by now I can give you a Tested-by as I've used these patches for almost two
weeks and various builds. Please don't forget to include my fix for out-of-tree
builds ([0]), when you push this series.

Thanks,
Kai


[0] 



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Erik Faye-Lund]

Sorry for the late reply.

On Fri, Nov 1, 2013 at 4:14 PM, Tapani  wrote:
> On 11/01/2013 03:31 PM, Erik Faye-Lund wrote:
>>
>>
>> Won't using the git-sha1 as a compatibility-criteria cause issues for
>> developers with local changes? I'm not so worried about this for
>> OES_get_program_binary itself, but once the shader-cache is in place
>> it sounds like a potential source of difficult to track down
>> misbehavior...
>
>
> I agree it might be too aggressive criteria but it is hard to come up
> with
> better and as simple.

 That's not my objection. My objection is that this might give
 headaches for people with local modifications to the glsl-compiler.
 Local modifications does not affect the git-sha1.
>>>
>>>
>>> For the automatic shader cache this headache could be helped a bit with a
>>> environment variable or drirc setting that can be used during
>>> development.
>>> On the other hand an automatic cache must work in a transparent way so it
>>> should be always able to recover when it fails, so one should only see it
>>> as
>>> 'slower than usual' (since recompilation/relink required) sort of
>>> behaviour.
>>> The WIP of the automatic cache I sent some time earlier also marked
>>> (renamed) these 'problematic' cached shaders so that they can be detected
>>> on
>>> further runs and cache can ignore those.
>>>
>>> I agree that it might become problematic, on the other hand it is also
>>> easy
>>> to just wipe ~/.cache/mesa and disable cache.
>>
>> That won't help for programs that maintain their own (explicit)
>> shader-cache, which was the intention of introducing binary shaders to
>> OpenGL ES in the first place.
>
>
> Ok, we are talking about the extension, I thought you referred to the
> automatic caching. For extension to work, we need at least more Piglit tests
> to ensure that it does not break.

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

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

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

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

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

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

>>> Not sure if Nvidia or
>>> Imagination try to handles these cases with their cache implementations.
>>
>> I would assume they simply piggie-backed on their binary-shader
>> support. But I somehow doubt they have such a "lazy" approach to
>> binary shaders as this series attempts. I worked on
>> ARM_mali_shader_binary for the Mali-200 drivers myself, and our
>> approach was quite different from this, and surely much more robust.
>
>
> With such strong opinion It would be nice to have some more technical
> explanation. Why it was "surely more robust"?

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

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

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

>> To be honest, I find the whole idea of serializing the IR quite
>> repelling, as it goes against almost every intention of the extension.
>> Add to that mesa's IR not at all being stable, wel

Re: [Mesa-dev] [PATCH 1/6] glsl: Implement parser support for atomic counters.

[Matt Turner]

On Tue, Oct 29, 2013 at 4:37 PM, Francisco Jerez  wrote:
> v2: Mark atomic counters as read-only variables.  Move offset overlap
> code to the linker.  Use the contains_atomic() convenience method.
> v3: Use pointer to integer instead of non-const reference.  Add
> comment so we remember to add a spec quotation from the next GLSL
> release once the issue of atomic counter aggregation within
> structures is clarified.
> ---

You asked me recently to check some minimum values on the Windows
driver. From your minmax test (first col is minumum required, second
col is number allowed by the driver):

GL_MAX_FRAGMENT_ATOMIC_COUNTERS   8 4096
GL_MAX_COMBINED_ATOMIC_COUNTERS   8 4096
GL_MAX_FRAGMENT_ATOMIC_COUNTER_BUFFERS18
GL_MAX_COMBINED_ATOMIC_COUNTER_BUFFERS18
(40 on Haswell)
GL_MAX_ATOMIC_COUNTER_BUFFER_SIZE3216384
GL_MAX_ATOMIC_COUNTER_BUFFER_BINDINGS 18
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/6] radeon/llvm: Free libelf resources

[Tom Stellard]

On Wed, Nov 06, 2013 at 10:36:51AM -0600, Aaron Watry wrote:
> ---
>  src/gallium/drivers/radeon/radeon_llvm_emit.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c 
> b/src/gallium/drivers/radeon/radeon_llvm_emit.c
> index 8bf278b..20b3206 100644
> --- a/src/gallium/drivers/radeon/radeon_llvm_emit.c
> +++ b/src/gallium/drivers/radeon/radeon_llvm_emit.c
> @@ -173,6 +173,9 @@ unsigned radeon_llvm_compile(LLVMModuleRef M, struct 
> radeon_llvm_binary *binary,
>   }
>   }
>  
> +if (elf){
> +elf_end(elf);
> +}

The indentation looks wrong here.

>   LLVMDisposeMemoryBuffer(out_buffer);
>   LLVMDisposeTargetMachine(tm);
>   return 0;
> -- 
> 1.8.3.2
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/6] radeon: Plug some memory leaks

[Tom Stellard]

These look good, but the indentation seems wrong in patches 2 through 6.

-Tom

On Wed, Nov 06, 2013 at 10:36:49AM -0600, Aaron Watry wrote:
> I decided to have some fun and hooked valgrind up to my 7850 while running
> a few OpenCL tests in piglit. This is the first batch of fixes.
> 
> Aaron Watry (6):
>   radeon/llvm: fix spelling error
>   radeon/llvm: Free libelf resources
>   radeon/llvm: Free created llvm memory buffer
>   radeonsi/compute: Free program and program.kernels on shutdown
>   radeonsi/compute: Dispose of LLVM module after compiling kernels
>   gallium/pipe_loader: un-reference udev resources when we're done with
> them.
> 
>  src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c |  3 +++
>  src/gallium/drivers/radeon/radeon_llvm_emit.c   |  3 +++
>  src/gallium/drivers/radeon/radeon_llvm_util.c   |  1 +
>  src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c |  2 +-
>  src/gallium/drivers/radeonsi/radeonsi_compute.c | 17 -
>  5 files changed, 24 insertions(+), 2 deletions(-)
> 
> 
> ___
> 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] [v2 6/6] mesa: OES_get_program_binary functionality

[Paul Berry]

On 6 November 2013 09:35, Erik Faye-Lund  wrote:

> Sorry for the late reply.
>
> On Fri, Nov 1, 2013 at 4:14 PM, Tapani  wrote:
> > On 11/01/2013 03:31 PM, Erik Faye-Lund wrote:
> >>
> >>
> >> Won't using the git-sha1 as a compatibility-criteria cause issues for
> >> developers with local changes? I'm not so worried about this for
> >> OES_get_program_binary itself, but once the shader-cache is in place
> >> it sounds like a potential source of difficult to track down
> >> misbehavior...
> >
> >
> > I agree it might be too aggressive criteria but it is hard to come up
> > with
> > better and as simple.
> 
>  That's not my objection. My objection is that this might give
>  headaches for people with local modifications to the glsl-compiler.
>  Local modifications does not affect the git-sha1.
> >>>
> >>>
> >>> For the automatic shader cache this headache could be helped a bit
> with a
> >>> environment variable or drirc setting that can be used during
> >>> development.
> >>> On the other hand an automatic cache must work in a transparent way so
> it
> >>> should be always able to recover when it fails, so one should only see
> it
> >>> as
> >>> 'slower than usual' (since recompilation/relink required) sort of
> >>> behaviour.
> >>> The WIP of the automatic cache I sent some time earlier also marked
> >>> (renamed) these 'problematic' cached shaders so that they can be
> detected
> >>> on
> >>> further runs and cache can ignore those.
> >>>
> >>> I agree that it might become problematic, on the other hand it is also
> >>> easy
> >>> to just wipe ~/.cache/mesa and disable cache.
> >>
> >> That won't help for programs that maintain their own (explicit)
> >> shader-cache, which was the intention of introducing binary shaders to
> >> OpenGL ES in the first place.
> >
> >
> > Ok, we are talking about the extension, I thought you referred to the
> > automatic caching. For extension to work, we need at least more Piglit
> tests
> > to ensure that it does not break.
>
> I was actually of talking about both. But for the caching, it's
> probably more forgivable, as developers probably know they changed the
> compiler and can step around it by flushing the cache. Especially if
> the build time gets included, like Pauls suggested.
>
> > Of course every time you go and touch the
> > code, some functionality may break, be it this extension or something
> else.
>
> That's completely irrelevant here. The rejection mechanism isn't
> intended to catch bugs, but to detect intentional format changes. So
> let's not confuse the issue.
>
> > I'm not sure if Chromium, Qt or other users expect glBinaryProgram call
> to
> > always succeed, hopefully not.
>
> If they do, they're buggy. But there is a chance for that, yes. But
> I'm actually talking about that they might get *told* that everything
> went well, and still get a broken shader. Or even a crash. Of course,
> this only applies when mesa is build with local modifications, but
> that happens a *lot* while debugging application issues. Perhaps bugs
> start to disappear, because applications take another non-buggy
> code-path? It'll probably only affect developers, and not happen in
> the wild. But I still don't think that's a good excuse.
>
> However, by a strict reading of the spec, I don't even yhink we're
> allowed to break the shaders for just any reason. The wording of the
> spec is "An implementation may reject a program binary if it
> determines the program binary was produced by an incompatible or
> outdated version of the compiler". The way I read that, changes that
> doesn't modify the compiler aren't really allowed to reject previous
> shaders. While diverging from the spec on this *might* not have many
> real-world implications, at the very best your solution goes against
> the intention of this rejection-mechanism.
>

We have to regard any bug fix, feature improvement, or performance
optimization that's applied to the parser, ast, optimization passes, or
lowering passes as constituting a change to the compiler.  Otherwise when
the user upgrades Mesa, any apps that use get_program_binary will fail to
get the advantage of the upgraded code.  As a practical matter, nearly
every sMesa release makes changes to one of those components, even point
releases.  So allowing old program binaries in the event that the compiler
hasn't changed really wouldn't produce any end user benefit.  And it would
risk big developer headaches if we ever make a change that affects
compilation without realizing it.  IMHO the risks outweigh the benefits.

And as far as whether we're strictly conforming to the spec, the spec is
vague here since it doesn't define what constitutes the "version of the
compiler" vs the "version of the driver".  I think it's an entirely
defensible interpretation to consider the compiler version and the driver
version to be the same thing; so whenever the driver is upgraded, the
client application needs to be prepared for the poss

Re: [Mesa-dev] [PATCH 0/6] radeon: Plug some memory leaks

[Aaron Watry]

On Wed, Nov 6, 2013 at 12:15 PM, Tom Stellard  wrote:
> These look good, but the indentation seems wrong in patches 2 through 6.

An artifact of expanding tabs to 4 spaces in the IDE...  Although I'd
argue that patch 6 is correct given that the portion of the file
affected already uses tabs for spaces.

Do you want a v2, or are you happy with the patches assuming that I
fix the indentation?

--Aaron

>
> -Tom
>
> On Wed, Nov 06, 2013 at 10:36:49AM -0600, Aaron Watry wrote:
>> I decided to have some fun and hooked valgrind up to my 7850 while running
>> a few OpenCL tests in piglit. This is the first batch of fixes.
>>
>> Aaron Watry (6):
>>   radeon/llvm: fix spelling error
>>   radeon/llvm: Free libelf resources
>>   radeon/llvm: Free created llvm memory buffer
>>   radeonsi/compute: Free program and program.kernels on shutdown
>>   radeonsi/compute: Dispose of LLVM module after compiling kernels
>>   gallium/pipe_loader: un-reference udev resources when we're done with
>> them.
>>
>>  src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c |  3 +++
>>  src/gallium/drivers/radeon/radeon_llvm_emit.c   |  3 +++
>>  src/gallium/drivers/radeon/radeon_llvm_util.c   |  1 +
>>  src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c |  2 +-
>>  src/gallium/drivers/radeonsi/radeonsi_compute.c | 17 -
>>  5 files changed, 24 insertions(+), 2 deletions(-)
>>
>>
>> ___
>> 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/6] radeon: Plug some memory leaks

[Tom Stellard]

On Wed, Nov 06, 2013 at 12:59:09PM -0600, Aaron Watry wrote:
> On Wed, Nov 6, 2013 at 12:15 PM, Tom Stellard  wrote:
> > These look good, but the indentation seems wrong in patches 2 through 6.
> 
> An artifact of expanding tabs to 4 spaces in the IDE...  Although I'd
> argue that patch 6 is correct given that the portion of the file
> affected already uses tabs for spaces.
> 
> Do you want a v2, or are you happy with the patches assuming that I
> fix the indentation?
>

If you don't have commit access, then you will need to send a v2, so
I can commit them.  If you have commit access, then these patches are

Reviewed-by: Tom Stellard 

If you make sure the indentation is consistent.

-Tom

> --Aaron
> 
> >
> > -Tom
> >
> > On Wed, Nov 06, 2013 at 10:36:49AM -0600, Aaron Watry wrote:
> >> I decided to have some fun and hooked valgrind up to my 7850 while running
> >> a few OpenCL tests in piglit. This is the first batch of fixes.
> >>
> >> Aaron Watry (6):
> >>   radeon/llvm: fix spelling error
> >>   radeon/llvm: Free libelf resources
> >>   radeon/llvm: Free created llvm memory buffer
> >>   radeonsi/compute: Free program and program.kernels on shutdown
> >>   radeonsi/compute: Dispose of LLVM module after compiling kernels
> >>   gallium/pipe_loader: un-reference udev resources when we're done with
> >> them.
> >>
> >>  src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c |  3 +++
> >>  src/gallium/drivers/radeon/radeon_llvm_emit.c   |  3 +++
> >>  src/gallium/drivers/radeon/radeon_llvm_util.c   |  1 +
> >>  src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c |  2 +-
> >>  src/gallium/drivers/radeonsi/radeonsi_compute.c | 17 -
> >>  5 files changed, 24 insertions(+), 2 deletions(-)
> >>
> >>
> >> ___
> >> 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] [v2 6/6] mesa: OES_get_program_binary functionality

[Erik Faye-Lund]

On Wed, Nov 6, 2013 at 7:49 PM, Paul Berry  wrote:
> On 6 November 2013 09:35, Erik Faye-Lund  wrote:
>>
>> Sorry for the late reply.
>>
>> On Fri, Nov 1, 2013 at 4:14 PM, Tapani  wrote:
>> > On 11/01/2013 03:31 PM, Erik Faye-Lund wrote:
>> >>
>> >>
>> >> Won't using the git-sha1 as a compatibility-criteria cause issues for
>> >> developers with local changes? I'm not so worried about this for
>> >> OES_get_program_binary itself, but once the shader-cache is in place
>> >> it sounds like a potential source of difficult to track down
>> >> misbehavior...
>> >
>> >
>> > I agree it might be too aggressive criteria but it is hard to come
>> > up
>> > with
>> > better and as simple.
>> 
>>  That's not my objection. My objection is that this might give
>>  headaches for people with local modifications to the glsl-compiler.
>>  Local modifications does not affect the git-sha1.
>> >>>
>> >>>
>> >>> For the automatic shader cache this headache could be helped a bit
>> >>> with a
>> >>> environment variable or drirc setting that can be used during
>> >>> development.
>> >>> On the other hand an automatic cache must work in a transparent way so
>> >>> it
>> >>> should be always able to recover when it fails, so one should only see
>> >>> it
>> >>> as
>> >>> 'slower than usual' (since recompilation/relink required) sort of
>> >>> behaviour.
>> >>> The WIP of the automatic cache I sent some time earlier also marked
>> >>> (renamed) these 'problematic' cached shaders so that they can be
>> >>> detected
>> >>> on
>> >>> further runs and cache can ignore those.
>> >>>
>> >>> I agree that it might become problematic, on the other hand it is also
>> >>> easy
>> >>> to just wipe ~/.cache/mesa and disable cache.
>> >>
>> >> That won't help for programs that maintain their own (explicit)
>> >> shader-cache, which was the intention of introducing binary shaders to
>> >> OpenGL ES in the first place.
>> >
>> >
>> > Ok, we are talking about the extension, I thought you referred to the
>> > automatic caching. For extension to work, we need at least more Piglit
>> > tests
>> > to ensure that it does not break.
>>
>> I was actually of talking about both. But for the caching, it's
>> probably more forgivable, as developers probably know they changed the
>> compiler and can step around it by flushing the cache. Especially if
>> the build time gets included, like Pauls suggested.
>>
>> > Of course every time you go and touch the
>> > code, some functionality may break, be it this extension or something
>> > else.
>>
>> That's completely irrelevant here. The rejection mechanism isn't
>> intended to catch bugs, but to detect intentional format changes. So
>> let's not confuse the issue.
>>
>> > I'm not sure if Chromium, Qt or other users expect glBinaryProgram call
>> > to
>> > always succeed, hopefully not.
>>
>> If they do, they're buggy. But there is a chance for that, yes. But
>> I'm actually talking about that they might get *told* that everything
>> went well, and still get a broken shader. Or even a crash. Of course,
>> this only applies when mesa is build with local modifications, but
>> that happens a *lot* while debugging application issues. Perhaps bugs
>> start to disappear, because applications take another non-buggy
>> code-path? It'll probably only affect developers, and not happen in
>> the wild. But I still don't think that's a good excuse.
>>
>> However, by a strict reading of the spec, I don't even yhink we're
>> allowed to break the shaders for just any reason. The wording of the
>> spec is "An implementation may reject a program binary if it
>> determines the program binary was produced by an incompatible or
>> outdated version of the compiler". The way I read that, changes that
>> doesn't modify the compiler aren't really allowed to reject previous
>> shaders. While diverging from the spec on this *might* not have many
>> real-world implications, at the very best your solution goes against
>> the intention of this rejection-mechanism.
>
>
> We have to regard any bug fix, feature improvement, or performance
> optimization that's applied to the parser, ast, optimization passes, or
> lowering passes as constituting a change to the compiler.

Not quite. Bug-fixes are fine; if the compiled shader was buggy,
you'll have a buggy binary shader, and it should be loaded with those
bugs intact. Feature improvements also does not matter: surely, a
pre-compiled shader won't use newer features. The same goes for
performance optimization; a program that pre-compiled a shader from an
old compiler surely won't expect to get a performance boost from new
optimization passes. If so, they'll use source shaders instead, and
pay the price of re-compiling. This is *exactly* what binary shaders
are for.

>  Otherwise when
> the user upgrades Mesa, any apps that use get_program_binary will fail to
> get the advantage of the upgraded code.

Yes, as I said, that's a part of the contract.

> As a practica

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

[Paul Berry]

On 6 November 2013 11:24, Erik Faye-Lund  wrote:

> On Wed, Nov 6, 2013 at 7:49 PM, Paul Berry 
> wrote:
> > On 6 November 2013 09:35, Erik Faye-Lund  wrote:
> >>
> >> Sorry for the late reply.
> >>
> >> On Fri, Nov 1, 2013 at 4:14 PM, Tapani  wrote:
> >> > On 11/01/2013 03:31 PM, Erik Faye-Lund wrote:
> >> >>
> >> >>
> >> >> Won't using the git-sha1 as a compatibility-criteria cause issues for
> >> >> developers with local changes? I'm not so worried about this for
> >> >> OES_get_program_binary itself, but once the shader-cache is in place
> >> >> it sounds like a potential source of difficult to track down
> >> >> misbehavior...
> >> >
> >> >
> >> > I agree it might be too aggressive criteria but it is hard to come
> >> > up
> >> > with
> >> > better and as simple.
> >> 
> >>  That's not my objection. My objection is that this might give
> >>  headaches for people with local modifications to the glsl-compiler.
> >>  Local modifications does not affect the git-sha1.
> >> >>>
> >> >>>
> >> >>> For the automatic shader cache this headache could be helped a bit
> >> >>> with a
> >> >>> environment variable or drirc setting that can be used during
> >> >>> development.
> >> >>> On the other hand an automatic cache must work in a transparent way
> so
> >> >>> it
> >> >>> should be always able to recover when it fails, so one should only
> see
> >> >>> it
> >> >>> as
> >> >>> 'slower than usual' (since recompilation/relink required) sort of
> >> >>> behaviour.
> >> >>> The WIP of the automatic cache I sent some time earlier also marked
> >> >>> (renamed) these 'problematic' cached shaders so that they can be
> >> >>> detected
> >> >>> on
> >> >>> further runs and cache can ignore those.
> >> >>>
> >> >>> I agree that it might become problematic, on the other hand it is
> also
> >> >>> easy
> >> >>> to just wipe ~/.cache/mesa and disable cache.
> >> >>
> >> >> That won't help for programs that maintain their own (explicit)
> >> >> shader-cache, which was the intention of introducing binary shaders
> to
> >> >> OpenGL ES in the first place.
> >> >
> >> >
> >> > Ok, we are talking about the extension, I thought you referred to the
> >> > automatic caching. For extension to work, we need at least more Piglit
> >> > tests
> >> > to ensure that it does not break.
> >>
> >> I was actually of talking about both. But for the caching, it's
> >> probably more forgivable, as developers probably know they changed the
> >> compiler and can step around it by flushing the cache. Especially if
> >> the build time gets included, like Pauls suggested.
> >>
> >> > Of course every time you go and touch the
> >> > code, some functionality may break, be it this extension or something
> >> > else.
> >>
> >> That's completely irrelevant here. The rejection mechanism isn't
> >> intended to catch bugs, but to detect intentional format changes. So
> >> let's not confuse the issue.
> >>
> >> > I'm not sure if Chromium, Qt or other users expect glBinaryProgram
> call
> >> > to
> >> > always succeed, hopefully not.
> >>
> >> If they do, they're buggy. But there is a chance for that, yes. But
> >> I'm actually talking about that they might get *told* that everything
> >> went well, and still get a broken shader. Or even a crash. Of course,
> >> this only applies when mesa is build with local modifications, but
> >> that happens a *lot* while debugging application issues. Perhaps bugs
> >> start to disappear, because applications take another non-buggy
> >> code-path? It'll probably only affect developers, and not happen in
> >> the wild. But I still don't think that's a good excuse.
> >>
> >> However, by a strict reading of the spec, I don't even yhink we're
> >> allowed to break the shaders for just any reason. The wording of the
> >> spec is "An implementation may reject a program binary if it
> >> determines the program binary was produced by an incompatible or
> >> outdated version of the compiler". The way I read that, changes that
> >> doesn't modify the compiler aren't really allowed to reject previous
> >> shaders. While diverging from the spec on this *might* not have many
> >> real-world implications, at the very best your solution goes against
> >> the intention of this rejection-mechanism.
> >
> >
> > We have to regard any bug fix, feature improvement, or performance
> > optimization that's applied to the parser, ast, optimization passes, or
> > lowering passes as constituting a change to the compiler.
>
> Not quite. Bug-fixes are fine; if the compiled shader was buggy,
> you'll have a buggy binary shader, and it should be loaded with those
> bugs intact. Feature improvements also does not matter: surely, a
> pre-compiled shader won't use newer features. The same goes for
> performance optimization; a program that pre-compiled a shader from an
> old compiler surely won't expect to get a performance boost from new
> optimization passes. If so, they'll use source shaders instead, and
> pay th

[Mesa-dev] DEFAULT_SOFTWARE_DEPTH_BITS=31

[burlen]

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

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

[Mesa-dev] [PATCH] gallivm: deduplicate some indirect register address code

[sroland]

From: Roland Scheidegger 

There's only one minor functional change, for immediates the pixel offsets
are no longer added since the values are all the same for all elements in
any case (it might be better if those weren't stored as soa vectors in the
first place maybe).
---
 src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |  253 +--
 1 file changed, 96 insertions(+), 157 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c 
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 75f6def..5f81066 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -898,6 +898,39 @@ stype_to_fetch(struct lp_build_tgsi_context * bld_base,
 }
 
 static LLVMValueRef
+get_soa_array_offsets(struct lp_build_context *uint_bld,
+  LLVMValueRef indirect_index,
+  unsigned chan_index,
+  boolean need_perelement_offset)
+{
+   struct gallivm_state *gallivm = uint_bld->gallivm;
+   LLVMValueRef chan_vec =
+  lp_build_const_int_vec(uint_bld->gallivm, uint_bld->type, chan_index);
+   LLVMValueRef length_vec =
+  lp_build_const_int_vec(gallivm, uint_bld->type, uint_bld->type.length);
+   LLVMValueRef index_vec;
+
+   /* index_vec = (indirect_index * 4 + chan_index) * length + offsets */
+   index_vec = lp_build_shl_imm(uint_bld, indirect_index, 2);
+   index_vec = lp_build_add(uint_bld, index_vec, chan_vec);
+   index_vec = lp_build_mul(uint_bld, index_vec, length_vec);
+
+   if (need_perelement_offset) {
+  LLVMValueRef pixel_offsets;
+  int i;
+ /* build pixel offset vector: {0, 1, 2, 3, ...} */
+  pixel_offsets = uint_bld->undef;
+  for (i = 0; i < uint_bld->type.length; i++) {
+ LLVMValueRef ii = lp_build_const_int32(gallivm, i);
+ pixel_offsets = LLVMBuildInsertElement(gallivm->builder, 
pixel_offsets,
+ii, ii, "");
+  }
+  index_vec = lp_build_add(uint_bld, index_vec, pixel_offsets);
+   }
+   return index_vec;
+}
+
+static LLVMValueRef
 emit_fetch_constant(
struct lp_build_tgsi_context * bld_base,
const struct tgsi_full_src_register * reg,
@@ -908,7 +941,6 @@ emit_fetch_constant(
struct gallivm_state *gallivm = bld_base->base.gallivm;
LLVMBuilderRef builder = gallivm->builder;
struct lp_build_context *uint_bld = &bld_base->uint_bld;
-   LLVMValueRef indirect_index = NULL;
unsigned dimension = 0;
LLVMValueRef dimension_index;
LLVMValueRef consts_ptr;
@@ -927,16 +959,15 @@ emit_fetch_constant(
consts_ptr = lp_build_array_get(gallivm, bld->consts_ptr, dimension_index);
 
if (reg->Register.Indirect) {
+  LLVMValueRef indirect_index;
+  LLVMValueRef swizzle_vec =
+ lp_build_const_int_vec(gallivm, uint_bld->type, swizzle);
+  LLVMValueRef index_vec;  /* index into the const buffer */
+
   indirect_index = get_indirect_index(bld,
   reg->Register.File,
   reg->Register.Index,
   ®->Indirect);
-   }
-
-   if (reg->Register.Indirect) {
-  LLVMValueRef swizzle_vec =
- lp_build_const_int_vec(bld->bld_base.base.gallivm, uint_bld->type, 
swizzle);
-  LLVMValueRef index_vec;  /* index into the const buffer */
 
   /* index_vec = indirect_index * 4 + swizzle */
   index_vec = lp_build_shl_imm(uint_bld, indirect_index, 2);
@@ -949,7 +980,7 @@ emit_fetch_constant(
   LLVMValueRef index;  /* index into the const buffer */
   LLVMValueRef scalar, scalar_ptr;
 
-  index = lp_build_const_int32(gallivm, reg->Register.Index*4 + swizzle);
+  index = lp_build_const_int32(gallivm, reg->Register.Index * 4 + swizzle);
 
   scalar_ptr = LLVMBuildGEP(builder, consts_ptr,
 &index, 1, "");
@@ -974,49 +1005,32 @@ emit_fetch_immediate(
struct lp_build_tgsi_soa_context * bld = lp_soa_context(bld_base);
struct gallivm_state *gallivm = bld->bld_base.base.gallivm;
LLVMBuilderRef builder = gallivm->builder;
-   struct lp_build_context *uint_bld = &bld_base->uint_bld;
-   struct lp_build_context *float_bld = &bld_base->base;
LLVMValueRef res = NULL;
-   LLVMValueRef indirect_index = NULL;
 
if (reg->Register.Indirect) {
+  LLVMValueRef indirect_index;
+  LLVMValueRef index_vec;  /* index into the immediate register array */
+  LLVMValueRef imms_array;
+  LLVMTypeRef fptr_type;
+
   indirect_index = get_indirect_index(bld,
   reg->Register.File,
   reg->Register.Index,
   ®->Indirect);
-   }
-
-   if (reg->Register.Indirect) {
-  LLVMValueRef swizzle_vec =
- lp_build_const_int_vec(bld->bld_base.base.gallivm,
-uint_bld->type, swizzle);
-  LLVMValueRef 

[Mesa-dev] [PATCH 5/7] mesa: Update TexStorage to support ARB_texture_view

[Courtney Goeltzenleuchter]

TexStorage and TexStorageMultisample updates texture object
state needed by ARB_texture_view extension.

Set appropriate TextureView state in texture object.

mesa: Add ARB_texture_view

Signed-off-by: Courtney Goeltzenleuchter 
---
 src/mesa/main/teximage.c   | 38 ++
 src/mesa/main/texstorage.c | 33 +
 2 files changed, 71 insertions(+)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 793c5d3..c01f72e 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -4348,6 +4348,44 @@ teximagemultisample(GLuint dims, GLenum target, GLsizei 
samples,
   }
 
   texObj->Immutable = immutable;
+
+  if (immutable) {
+ /* If the command is successful,
+  * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
+  * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become levels.
+  * If the texture target is TEXTURE_1D_ARRAY then
+  * TEXTURE_VIEW_NUM_LAYERS becomes height.
+  * If the texture target is TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY,
+  * or TEXTURE_2D_MULTISAMPLE_ARRAY then TEXTURE_VIEW_NUM_LAYERS 
becomes depth.
+  * If the texture target is TEXTURE_CUBE_MAP, then
+  * TEXTURE_VIEW_NUM_LAYERS becomes 6.
+  * For any other texture target, TEXTURE_VIEW_NUM_LAYERS becomes 1.
+  * ARB_texture_multisample: Multisample textures do
+  * not have multiple image levels.
+  */
+ texObj->Immutable = GL_TRUE;
+ texObj->ImmutableLevels = 1;
+ texObj->MinLevel = 0;
+ texObj->NumLevels = 1;
+ texObj->MinLayer = 0;
+ texObj->NumLayers = 1;
+ switch (target) {
+ case GL_TEXTURE_1D_ARRAY:
+texObj->NumLayers = height;
+break;
+
+ case GL_TEXTURE_2D_ARRAY:
+ case GL_TEXTURE_CUBE_MAP_ARRAY:
+ case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
+texObj->NumLayers = depth;
+break;
+
+ case GL_TEXTURE_CUBE_MAP:
+texObj->NumLayers = 6;
+break;
+ }
+  }
+
   _mesa_update_fbo_texture(ctx, texObj, 0, 0);
}
 }
diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
index 84b8f82..4da3c91 100644
--- a/src/mesa/main/texstorage.c
+++ b/src/mesa/main/texstorage.c
@@ -436,8 +436,41 @@ texstorage(GLuint dims, GLenum target, GLsizei levels, 
GLenum internalformat,
  return;
   }
 
+  /* If the command is successful,
+   * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
+   * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become levels.
+   * If the texture target is TEXTURE_1D_ARRAY then
+   * TEXTURE_VIEW_NUM_LAYERS becomes height.
+   * If the texture target is TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY,
+   * or TEXTURE_2D_MULTISAMPLE_ARRAY then TEXTURE_VIEW_NUM_LAYERS becomes 
depth.
+   * If the texture target is TEXTURE_CUBE_MAP, then
+   * TEXTURE_VIEW_NUM_LAYERS becomes 6.
+   * For any other texture target, TEXTURE_VIEW_NUM_LAYERS becomes 1.
+   */
+
   texObj->Immutable = GL_TRUE;
   texObj->ImmutableLevels = levels;
+  texObj->MinLevel = 0;
+  texObj->NumLevels = levels;
+  texObj->MinLayer = 0;
+  texObj->NumLayers = 1;
+  switch (target)
+  {
+  case GL_TEXTURE_1D_ARRAY:
+ texObj->NumLayers = height;
+ break;
+
+  case GL_TEXTURE_2D_ARRAY:
+  case GL_TEXTURE_CUBE_MAP_ARRAY:
+  case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
+ texObj->NumLayers = depth;
+ break;
+
+  case GL_TEXTURE_CUBE_MAP:
+ texObj->NumLayers = 6;
+ break;
+  }
+
}
 }
 
-- 
1.8.1.2

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

Re: [Mesa-dev] [PATCH 5/7] mesa: Update TexStorage to support ARB_texture_view

[Chris Forbes]

The only interesting targets in teximagemultisample are
GL_TEXTURE_2D_MULTISAMPLE and GL_TEXTURE_2D_MULTISAMPLE_ARRAY.

On Thu, Nov 7, 2013 at 8:55 AM, Courtney Goeltzenleuchter
 wrote:
> TexStorage and TexStorageMultisample updates texture object
> state needed by ARB_texture_view extension.
>
> Set appropriate TextureView state in texture object.
>
> mesa: Add ARB_texture_view
>
> Signed-off-by: Courtney Goeltzenleuchter 
> ---
>  src/mesa/main/teximage.c   | 38 ++
>  src/mesa/main/texstorage.c | 33 +
>  2 files changed, 71 insertions(+)
>
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index 793c5d3..c01f72e 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -4348,6 +4348,44 @@ teximagemultisample(GLuint dims, GLenum target, 
> GLsizei samples,
>}
>
>texObj->Immutable = immutable;
> +
> +  if (immutable) {
> + /* If the command is successful,
> +  * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
> +  * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become 
> levels.
> +  * If the texture target is TEXTURE_1D_ARRAY then
> +  * TEXTURE_VIEW_NUM_LAYERS becomes height.
> +  * If the texture target is TEXTURE_2D_ARRAY, 
> TEXTURE_CUBE_MAP_ARRAY,
> +  * or TEXTURE_2D_MULTISAMPLE_ARRAY then TEXTURE_VIEW_NUM_LAYERS 
> becomes depth.
> +  * If the texture target is TEXTURE_CUBE_MAP, then
> +  * TEXTURE_VIEW_NUM_LAYERS becomes 6.
> +  * For any other texture target, TEXTURE_VIEW_NUM_LAYERS becomes 1.
> +  * ARB_texture_multisample: Multisample textures do
> +  * not have multiple image levels.
> +  */
> + texObj->Immutable = GL_TRUE;
> + texObj->ImmutableLevels = 1;
> + texObj->MinLevel = 0;
> + texObj->NumLevels = 1;
> + texObj->MinLayer = 0;
> + texObj->NumLayers = 1;
> + switch (target) {
> + case GL_TEXTURE_1D_ARRAY:
> +texObj->NumLayers = height;
> +break;
> +
> + case GL_TEXTURE_2D_ARRAY:
> + case GL_TEXTURE_CUBE_MAP_ARRAY:
> + case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
> +texObj->NumLayers = depth;
> +break;
> +
> + case GL_TEXTURE_CUBE_MAP:
> +texObj->NumLayers = 6;
> +break;
> + }
> +  }
> +
>_mesa_update_fbo_texture(ctx, texObj, 0, 0);
> }
>  }
> diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
> index 84b8f82..4da3c91 100644
> --- a/src/mesa/main/texstorage.c
> +++ b/src/mesa/main/texstorage.c
> @@ -436,8 +436,41 @@ texstorage(GLuint dims, GLenum target, GLsizei levels, 
> GLenum internalformat,
>   return;
>}
>
> +  /* If the command is successful,
> +   * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
> +   * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become levels.
> +   * If the texture target is TEXTURE_1D_ARRAY then
> +   * TEXTURE_VIEW_NUM_LAYERS becomes height.
> +   * If the texture target is TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY,
> +   * or TEXTURE_2D_MULTISAMPLE_ARRAY then TEXTURE_VIEW_NUM_LAYERS 
> becomes depth.
> +   * If the texture target is TEXTURE_CUBE_MAP, then
> +   * TEXTURE_VIEW_NUM_LAYERS becomes 6.
> +   * For any other texture target, TEXTURE_VIEW_NUM_LAYERS becomes 1.
> +   */
> +
>texObj->Immutable = GL_TRUE;
>texObj->ImmutableLevels = levels;
> +  texObj->MinLevel = 0;
> +  texObj->NumLevels = levels;
> +  texObj->MinLayer = 0;
> +  texObj->NumLayers = 1;
> +  switch (target)
> +  {
> +  case GL_TEXTURE_1D_ARRAY:
> + texObj->NumLayers = height;
> + break;
> +
> +  case GL_TEXTURE_2D_ARRAY:
> +  case GL_TEXTURE_CUBE_MAP_ARRAY:
> +  case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
> + texObj->NumLayers = depth;
> + break;
> +
> +  case GL_TEXTURE_CUBE_MAP:
> + texObj->NumLayers = 6;
> + break;
> +  }
> +
> }
>  }
>
> --
> 1.8.1.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Paul Berry]

On 6 November 2013 11:24, Erik Faye-Lund  wrote:

> On Wed, Nov 6, 2013 at 7:49 PM, Paul Berry 
> wrote:
> > On 6 November 2013 09:35, Erik Faye-Lund  wrote:
> >>
> >> Sorry for the late reply.
> >>
> >> On Fri, Nov 1, 2013 at 4:14 PM, Tapani  wrote:
> >> > On 11/01/2013 03:31 PM, Erik Faye-Lund wrote:
> >> >>
> >> >>
> >> >> Won't using the git-sha1 as a compatibility-criteria cause issues for
> >> >> developers with local changes? I'm not so worried about this for
> >> >> OES_get_program_binary itself, but once the shader-cache is in place
> >> >> it sounds like a potential source of difficult to track down
> >> >> misbehavior...
> >> >
> >> >
> >> > I agree it might be too aggressive criteria but it is hard to come
> >> > up
> >> > with
> >> > better and as simple.
> >> 
> >>  That's not my objection. My objection is that this might give
> >>  headaches for people with local modifications to the glsl-compiler.
> >>  Local modifications does not affect the git-sha1.
> >> >>>
> >> >>>
> >> >>> For the automatic shader cache this headache could be helped a bit
> >> >>> with a
> >> >>> environment variable or drirc setting that can be used during
> >> >>> development.
> >> >>> On the other hand an automatic cache must work in a transparent way
> so
> >> >>> it
> >> >>> should be always able to recover when it fails, so one should only
> see
> >> >>> it
> >> >>> as
> >> >>> 'slower than usual' (since recompilation/relink required) sort of
> >> >>> behaviour.
> >> >>> The WIP of the automatic cache I sent some time earlier also marked
> >> >>> (renamed) these 'problematic' cached shaders so that they can be
> >> >>> detected
> >> >>> on
> >> >>> further runs and cache can ignore those.
> >> >>>
> >> >>> I agree that it might become problematic, on the other hand it is
> also
> >> >>> easy
> >> >>> to just wipe ~/.cache/mesa and disable cache.
> >> >>
> >> >> That won't help for programs that maintain their own (explicit)
> >> >> shader-cache, which was the intention of introducing binary shaders
> to
> >> >> OpenGL ES in the first place.
> >> >
> >> >
> >> > Ok, we are talking about the extension, I thought you referred to the
> >> > automatic caching. For extension to work, we need at least more Piglit
> >> > tests
> >> > to ensure that it does not break.
> >>
> >> I was actually of talking about both. But for the caching, it's
> >> probably more forgivable, as developers probably know they changed the
> >> compiler and can step around it by flushing the cache. Especially if
> >> the build time gets included, like Pauls suggested.
> >>
> >> > Of course every time you go and touch the
> >> > code, some functionality may break, be it this extension or something
> >> > else.
> >>
> >> That's completely irrelevant here. The rejection mechanism isn't
> >> intended to catch bugs, but to detect intentional format changes. So
> >> let's not confuse the issue.
> >>
> >> > I'm not sure if Chromium, Qt or other users expect glBinaryProgram
> call
> >> > to
> >> > always succeed, hopefully not.
> >>
> >> If they do, they're buggy. But there is a chance for that, yes. But
> >> I'm actually talking about that they might get *told* that everything
> >> went well, and still get a broken shader. Or even a crash. Of course,
> >> this only applies when mesa is build with local modifications, but
> >> that happens a *lot* while debugging application issues. Perhaps bugs
> >> start to disappear, because applications take another non-buggy
> >> code-path? It'll probably only affect developers, and not happen in
> >> the wild. But I still don't think that's a good excuse.
> >>
> >> However, by a strict reading of the spec, I don't even yhink we're
> >> allowed to break the shaders for just any reason. The wording of the
> >> spec is "An implementation may reject a program binary if it
> >> determines the program binary was produced by an incompatible or
> >> outdated version of the compiler". The way I read that, changes that
> >> doesn't modify the compiler aren't really allowed to reject previous
> >> shaders. While diverging from the spec on this *might* not have many
> >> real-world implications, at the very best your solution goes against
> >> the intention of this rejection-mechanism.
> >
> >
> > We have to regard any bug fix, feature improvement, or performance
> > optimization that's applied to the parser, ast, optimization passes, or
> > lowering passes as constituting a change to the compiler.
>
> Not quite. Bug-fixes are fine; if the compiled shader was buggy,
> you'll have a buggy binary shader, and it should be loaded with those
> bugs intact. Feature improvements also does not matter: surely, a
> pre-compiled shader won't use newer features. The same goes for
> performance optimization; a program that pre-compiled a shader from an
> old compiler surely won't expect to get a performance boost from new
> optimization passes. If so, they'll use source shaders instead, and
> pay th

Re: [Mesa-dev] [PATCH 20/37] targets/r600: move drm_target.c to a common folder

[Adrian M Negreanu]

On Sat, Nov 2, 2013 at 9:00 PM, Emil Velikov  wrote:
> ... and symlink to each target.
> Make automake's subdir-objects work for r600.
I think r600 and r300 were removed from the tree[1].
git am complains about missing dirs
   error: src/gallium/targets/r600/xorg/Makefile.am: does not exist in index
same error for:
   src/gallium/targets/radeonsi/xorg/Makefile.am:
   src/gallium/targets/r300/xvmc/Makefile.am:
   src/gallium/targets/r300/vdpau/Makefile.am:
   src/gallium/targets/xvmc-softpipe/Makefile.am:
   src/gallium/targets/vdpau-softpipe/Makefile.am:

[1] http://comments.gmane.org/gmane.comp.video.mesa3d.devel/66106

>
> Signed-off-by: Emil Velikov 
> ---
>  src/gallium/targets/r600/common/drm_target.c | 69 
> 
>  src/gallium/targets/r600/dri/Makefile.am |  2 +-
>  src/gallium/targets/r600/dri/drm_target.c|  1 +
>  src/gallium/targets/r600/drm_target.c| 69 
> 
>  src/gallium/targets/r600/vdpau/Makefile.am   |  2 +-
>  src/gallium/targets/r600/vdpau/drm_target.c  |  1 +
>  src/gallium/targets/r600/xorg/Makefile.am|  2 +-
>  src/gallium/targets/r600/xorg/drm_target.c   |  1 +
>  src/gallium/targets/r600/xvmc/Makefile.am|  2 +-
>  src/gallium/targets/r600/xvmc/drm_target.c   |  1 +
>  10 files changed, 77 insertions(+), 73 deletions(-)
>  create mode 100644 src/gallium/targets/r600/common/drm_target.c
>  create mode 12 src/gallium/targets/r600/dri/drm_target.c
>  delete mode 100644 src/gallium/targets/r600/drm_target.c
>  create mode 12 src/gallium/targets/r600/vdpau/drm_target.c
>  create mode 12 src/gallium/targets/r600/xorg/drm_target.c
>  create mode 12 src/gallium/targets/r600/xvmc/drm_target.c
>
> diff --git a/src/gallium/targets/r600/common/drm_target.c 
> b/src/gallium/targets/r600/common/drm_target.c
> new file mode 100644
> index 000..28004ac
> --- /dev/null
> +++ b/src/gallium/targets/r600/common/drm_target.c
> @@ -0,0 +1,69 @@
> +/**
> + *
> + * Copyright 2013 Advanced Micro Devices, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
> + * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + **/
> +
> +#include "state_tracker/drm_driver.h"
> +#include "target-helpers/inline_debug_helper.h"
> +#include "radeon/drm/radeon_drm_public.h"
> +#include "radeon/drm/radeon_winsys.h"
> +#include "r600/r600_public.h"
> +
> +static struct pipe_screen *create_screen(int fd)
> +{
> +   struct radeon_winsys *radeon;
> +
> +   radeon = radeon_drm_winsys_create(fd);
> +   if (!radeon)
> +  return NULL;
> +
> +   if (!radeon->screen) {
> +  radeon->screen = r600_screen_create(radeon);
> +  if (!radeon->screen)
> + return NULL;
> +
> +  radeon->screen = debug_screen_wrap(radeon->screen);
> +   }
> +
> +   return radeon->screen;
> +}
> +
> +static const struct drm_conf_ret throttle_ret = {
> +   .type = DRM_CONF_INT,
> +   .val.val_int = 2,
> +};
> +
> +static const struct drm_conf_ret *drm_configuration(enum drm_conf conf)
> +{
> +   switch (conf) {
> +   case DRM_CONF_THROTTLE:
> +  return &throttle_ret;
> +   default:
> +  break;
> +   }
> +   return NULL;
> +}
> +
> +DRM_DRIVER_DESCRIPTOR("r600", "radeon", create_screen, drm_configuration)
> diff --git a/src/gallium/targets/r600/dri/Makefile.am 
> b/src/gallium/targets/r600/dri/Makefile.am
> index c7fca32..b5ea37a 100644
> --- a/src/gallium/targets/r600/dri/Makefile.am
> +++ b/src/gallium/targets/r600/dri/Makefile.am
> @@ -41,7 +41,7 @@ dridir = $(DRI_DRIVER_INSTALL_DIR)
>  dri_LTLIBRARIES = r600_dri.la
>
>  r600_dri_la_SOURCES = \
> -   ../drm_target.c
> +   drm_target.c
>
>  r600_dri_la_LDFLAGS = $(DRI_DRIVER_LDFLAGS)
>
> diff --git a/src/gallium/targets/r600/dri/drm_target.c 
> b/src/galli

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

[Erik Faye-Lund]

On Wed, Nov 6, 2013 at 9:19 PM, Paul Berry  wrote:
> On 6 November 2013 11:24, Erik Faye-Lund  wrote:
>>
>> On Wed, Nov 6, 2013 at 7:49 PM, Paul Berry 
>> wrote:
>> > On 6 November 2013 09:35, Erik Faye-Lund  wrote:
>> >>
>> >> Sorry for the late reply.
>> >>
>> >> On Fri, Nov 1, 2013 at 4:14 PM, Tapani  wrote:
>> >> > On 11/01/2013 03:31 PM, Erik Faye-Lund wrote:
>> >> >>
>> >> >>
>> >> >> Won't using the git-sha1 as a compatibility-criteria cause issues
>> >> >> for
>> >> >> developers with local changes? I'm not so worried about this for
>> >> >> OES_get_program_binary itself, but once the shader-cache is in place
>> >> >> it sounds like a potential source of difficult to track down
>> >> >> misbehavior...
>> >> >
>> >> >
>> >> > I agree it might be too aggressive criteria but it is hard to
>> >> > come
>> >> > up
>> >> > with
>> >> > better and as simple.
>> >> 
>> >>  That's not my objection. My objection is that this might give
>> >>  headaches for people with local modifications to the
>> >>  glsl-compiler.
>> >>  Local modifications does not affect the git-sha1.
>> >> >>>
>> >> >>>
>> >> >>> For the automatic shader cache this headache could be helped a bit
>> >> >>> with a
>> >> >>> environment variable or drirc setting that can be used during
>> >> >>> development.
>> >> >>> On the other hand an automatic cache must work in a transparent way
>> >> >>> so
>> >> >>> it
>> >> >>> should be always able to recover when it fails, so one should only
>> >> >>> see
>> >> >>> it
>> >> >>> as
>> >> >>> 'slower than usual' (since recompilation/relink required) sort of
>> >> >>> behaviour.
>> >> >>> The WIP of the automatic cache I sent some time earlier also marked
>> >> >>> (renamed) these 'problematic' cached shaders so that they can be
>> >> >>> detected
>> >> >>> on
>> >> >>> further runs and cache can ignore those.
>> >> >>>
>> >> >>> I agree that it might become problematic, on the other hand it is
>> >> >>> also
>> >> >>> easy
>> >> >>> to just wipe ~/.cache/mesa and disable cache.
>> >> >>
>> >> >> That won't help for programs that maintain their own (explicit)
>> >> >> shader-cache, which was the intention of introducing binary shaders
>> >> >> to
>> >> >> OpenGL ES in the first place.
>> >> >
>> >> >
>> >> > Ok, we are talking about the extension, I thought you referred to the
>> >> > automatic caching. For extension to work, we need at least more
>> >> > Piglit
>> >> > tests
>> >> > to ensure that it does not break.
>> >>
>> >> I was actually of talking about both. But for the caching, it's
>> >> probably more forgivable, as developers probably know they changed the
>> >> compiler and can step around it by flushing the cache. Especially if
>> >> the build time gets included, like Pauls suggested.
>> >>
>> >> > Of course every time you go and touch the
>> >> > code, some functionality may break, be it this extension or something
>> >> > else.
>> >>
>> >> That's completely irrelevant here. The rejection mechanism isn't
>> >> intended to catch bugs, but to detect intentional format changes. So
>> >> let's not confuse the issue.
>> >>
>> >> > I'm not sure if Chromium, Qt or other users expect glBinaryProgram
>> >> > call
>> >> > to
>> >> > always succeed, hopefully not.
>> >>
>> >> If they do, they're buggy. But there is a chance for that, yes. But
>> >> I'm actually talking about that they might get *told* that everything
>> >> went well, and still get a broken shader. Or even a crash. Of course,
>> >> this only applies when mesa is build with local modifications, but
>> >> that happens a *lot* while debugging application issues. Perhaps bugs
>> >> start to disappear, because applications take another non-buggy
>> >> code-path? It'll probably only affect developers, and not happen in
>> >> the wild. But I still don't think that's a good excuse.
>> >>
>> >> However, by a strict reading of the spec, I don't even yhink we're
>> >> allowed to break the shaders for just any reason. The wording of the
>> >> spec is "An implementation may reject a program binary if it
>> >> determines the program binary was produced by an incompatible or
>> >> outdated version of the compiler". The way I read that, changes that
>> >> doesn't modify the compiler aren't really allowed to reject previous
>> >> shaders. While diverging from the spec on this *might* not have many
>> >> real-world implications, at the very best your solution goes against
>> >> the intention of this rejection-mechanism.
>> >
>> >
>> > We have to regard any bug fix, feature improvement, or performance
>> > optimization that's applied to the parser, ast, optimization passes, or
>> > lowering passes as constituting a change to the compiler.
>>
>> Not quite. Bug-fixes are fine; if the compiled shader was buggy,
>> you'll have a buggy binary shader, and it should be loaded with those
>> bugs intact. Feature improvements also does not matter: surely, a
>> pre-compiled shader won't use newer features. The s

Re: [Mesa-dev] [PATCH 5/7] mesa: Update TexStorage to support ARB_texture_view

[Courtney Goeltzenleuchter]

Correct and I check_multisample_target checks for that.
And we never get to this code if using a PROXY target.
Or did I miss something?


On Wed, Nov 6, 2013 at 1:14 PM, Chris Forbes  wrote:

> The only interesting targets in teximagemultisample are
> GL_TEXTURE_2D_MULTISAMPLE and GL_TEXTURE_2D_MULTISAMPLE_ARRAY.
>
> On Thu, Nov 7, 2013 at 8:55 AM, Courtney Goeltzenleuchter
>  wrote:
> > TexStorage and TexStorageMultisample updates texture object
> > state needed by ARB_texture_view extension.
> >
> > Set appropriate TextureView state in texture object.
> >
> > mesa: Add ARB_texture_view
> >
> > Signed-off-by: Courtney Goeltzenleuchter 
> > ---
> >  src/mesa/main/teximage.c   | 38 ++
> >  src/mesa/main/texstorage.c | 33 +
> >  2 files changed, 71 insertions(+)
> >
> > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> > index 793c5d3..c01f72e 100644
> > --- a/src/mesa/main/teximage.c
> > +++ b/src/mesa/main/teximage.c
> > @@ -4348,6 +4348,44 @@ teximagemultisample(GLuint dims, GLenum target,
> GLsizei samples,
> >}
> >
> >texObj->Immutable = immutable;
> > +
> > +  if (immutable) {
> > + /* If the command is successful,
> > +  * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
> > +  * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become
> levels.
> > +  * If the texture target is TEXTURE_1D_ARRAY then
> > +  * TEXTURE_VIEW_NUM_LAYERS becomes height.
> > +  * If the texture target is TEXTURE_2D_ARRAY,
> TEXTURE_CUBE_MAP_ARRAY,
> > +  * or TEXTURE_2D_MULTISAMPLE_ARRAY then
> TEXTURE_VIEW_NUM_LAYERS becomes depth.
> > +  * If the texture target is TEXTURE_CUBE_MAP, then
> > +  * TEXTURE_VIEW_NUM_LAYERS becomes 6.
> > +  * For any other texture target, TEXTURE_VIEW_NUM_LAYERS
> becomes 1.
> > +  * ARB_texture_multisample: Multisample textures do
> > +  * not have multiple image levels.
> > +  */
> > + texObj->Immutable = GL_TRUE;
> > + texObj->ImmutableLevels = 1;
> > + texObj->MinLevel = 0;
> > + texObj->NumLevels = 1;
> > + texObj->MinLayer = 0;
> > + texObj->NumLayers = 1;
> > + switch (target) {
> > + case GL_TEXTURE_1D_ARRAY:
> > +texObj->NumLayers = height;
> > +break;
> > +
> > + case GL_TEXTURE_2D_ARRAY:
> > + case GL_TEXTURE_CUBE_MAP_ARRAY:
> > + case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
> > +texObj->NumLayers = depth;
> > +break;
> > +
> > + case GL_TEXTURE_CUBE_MAP:
> > +texObj->NumLayers = 6;
> > +break;
> > + }
> > +  }
> > +
> >_mesa_update_fbo_texture(ctx, texObj, 0, 0);
> > }
> >  }
> > diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
> > index 84b8f82..4da3c91 100644
> > --- a/src/mesa/main/texstorage.c
> > +++ b/src/mesa/main/texstorage.c
> > @@ -436,8 +436,41 @@ texstorage(GLuint dims, GLenum target, GLsizei
> levels, GLenum internalformat,
> >   return;
> >}
> >
> > +  /* If the command is successful,
> > +   * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
> > +   * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become
> levels.
> > +   * If the texture target is TEXTURE_1D_ARRAY then
> > +   * TEXTURE_VIEW_NUM_LAYERS becomes height.
> > +   * If the texture target is TEXTURE_2D_ARRAY,
> TEXTURE_CUBE_MAP_ARRAY,
> > +   * or TEXTURE_2D_MULTISAMPLE_ARRAY then TEXTURE_VIEW_NUM_LAYERS
> becomes depth.
> > +   * If the texture target is TEXTURE_CUBE_MAP, then
> > +   * TEXTURE_VIEW_NUM_LAYERS becomes 6.
> > +   * For any other texture target, TEXTURE_VIEW_NUM_LAYERS becomes
> 1.
> > +   */
> > +
> >texObj->Immutable = GL_TRUE;
> >texObj->ImmutableLevels = levels;
> > +  texObj->MinLevel = 0;
> > +  texObj->NumLevels = levels;
> > +  texObj->MinLayer = 0;
> > +  texObj->NumLayers = 1;
> > +  switch (target)
> > +  {
> > +  case GL_TEXTURE_1D_ARRAY:
> > + texObj->NumLayers = height;
> > + break;
> > +
> > +  case GL_TEXTURE_2D_ARRAY:
> > +  case GL_TEXTURE_CUBE_MAP_ARRAY:
> > +  case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
> > + texObj->NumLayers = depth;
> > + break;
> > +
> > +  case GL_TEXTURE_CUBE_MAP:
> > + texObj->NumLayers = 6;
> > + break;
> > +  }
> > +
> > }
> >  }
> >
> > --
> > 1.8.1.2
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



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

Re: [Mesa-dev] [v2 5/6] glsl: functions to serialize gl_shader and gl_shader_program

[Paul Berry]

On 6 November 2013 00:59, Tapani Pälli  wrote:

>  On 11/06/2013 12:02 AM, Paul Berry wrote:
>
> On 1 November 2013 02:16, Tapani Pälli  wrote:
>
>> +static void
>> +calc_item(const void *key, void *data, void *closure)
>>
>
>  How about "increment_count" for the name of this function?
>
>
> ok
>
>
>
>
>> +{
>> +   unsigned *sz = (unsigned *) closure;
>> +   *sz = *sz + 1;
>> +}
>> +
>> +
>> +static unsigned
>> +_hash_table_size(struct string_to_uint_map *map)
>>
>
>  This function is global, so its name can't start with an
> underscore--such names are reserved for library functions.  Same goes for
> many of the other functions in this file.
>
>
> will change
>
>
>
>
>> +{
>> +   unsigned size = 0;
>> +   map->iterate(calc_item, &size);
>> +   return size;
>> +}
>> +
>> +
>> +static void
>> +serialize_item(const void *key, void *data, void *closure)
>> +{
>> +   memory_writer *blob = (memory_writer *) closure;
>> +   uint32_t value = ((intptr_t)data);
>> +
>> +   blob->write_string((char *)key);
>> +   blob->write_uint32(&value);
>> +}
>> +
>> +
>> +static void
>> +_serialize_hash_table(struct string_to_uint_map *map, memory_writer
>> *blob)
>> +{
>> +   uint32_t size = _hash_table_size(map);
>> +   blob->write_uint32(&size);
>> +   map->iterate(serialize_item, blob);
>>
>
>  Rather than take two passes over the hash table (one to compute its size
> and one to output its contents), why not do the trick that we do with
> overwrite() in ir_cache_serializer.cpp?  (In other words, reserve space for
> the size of the hashtable in bytes, then serialize the hashtable, then
> overwrite the reserved space with the actual size).
>
>
>
> yes this is faster, will change
>
>
>+   /* Shaders IR, to be decided if we want these to be available */
>>
>
>  Has there been previous discussion on the mesa-dev list about whether or
> not we want these to be available?  If so, please include a link to
> previous discussion and a brief summary.  if not, what does the decision
> hinge on?  At first blush it seems to me that there's no reason to
> serialize the IR of the individual shaders, since ARB_get_program_binary
> operates on full programs rather than individual shaders.
>
>
> Nope there has been no previous discussion about this. Automatic cache
> will need these to be able to quick exit from glCompileShader (if wanted),
> it's easier for the implementation to have them as separate blobs than part
> of whole program blob though. With the extension I'm not sure if unlinked
> IR is required for possible run-time recompilations? I'd like someone to
> confirm this.
>

Yeah, you're probably right that we need to store the individual shaders'
IR for automatic caching.

For OES_get_program_binary, based on my reading of the spec, we shouldn't
store the individual shaders' IR.  ProgramBinaryOES only loads the linked
shader; it leaves the compiled shader objects (if any) alone.


>
>
>
>   Also, typically we prefer to disable code using "if (false)" rather
> than ifdefs, because that ensures that the disabled code still compiles.
> (Otherwise, it's much more likely to bit rot as the rest of the code base
> evolves).
>
>
> ok, will use if (false), I also changethe unlinked shader define to use
> your STORE_UNLINKED_SHADERS proposal
>
>
>
>   Are we going to attempt to store the back-end compiled shaders?  It
> seems like we'd have to do that in order to get a lot of the benefit of
> ARB_get_program_binary.
>
>
> Yes it is definitely required, there is big amount of time spent in
> Driver->LinkShader(). However, this was left out for now. It might be that
> several back-end blobs are needed and I'm not sure how well it works and
> what should happen when recompilation happens. This needs a bit more
> thought. At least new API is needed with driver to simply retrieve and put
> binary blobs, I would certainly like some advice how to approach the
> problem.
>
> // Tapani
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 20/37] targets/r600: move drm_target.c to a common folder

[Emil Velikov]

On 06/11/13 20:26, Adrian M Negreanu wrote:
> On Sat, Nov 2, 2013 at 9:00 PM, Emil Velikov  wrote:
>> ... and symlink to each target.
>> Make automake's subdir-objects work for r600.
> I think r600 and r300 were removed from the tree[1].
> git am complains about missing dirs
>error: src/gallium/targets/r600/xorg/Makefile.am: does not exist in index
> same error for:
>src/gallium/targets/radeonsi/xorg/Makefile.am:
>src/gallium/targets/r300/xvmc/Makefile.am:
>src/gallium/targets/r300/vdpau/Makefile.am:
>src/gallium/targets/xvmc-softpipe/Makefile.am:
>src/gallium/targets/vdpau-softpipe/Makefile.am:
> 
> [1] http://comments.gmane.org/gmane.comp.video.mesa3d.devel/66106
> 
Hi Adrian,

There have been some changes, that would result in a few conflicts.

If you're interested in testing the Android changes then you can apply
up to (or even only) patch 10.

Planning to give the series a respin/rebase in a day or so. Meanwhile it
would be great to hear a few more people, esp on the gallium side.

Cheers
Emil
>>
>> Signed-off-by: Emil Velikov 
>> ---
>>  src/gallium/targets/r600/common/drm_target.c | 69 
>> 
>>  src/gallium/targets/r600/dri/Makefile.am |  2 +-
>>  src/gallium/targets/r600/dri/drm_target.c|  1 +
>>  src/gallium/targets/r600/drm_target.c| 69 
>> 
>>  src/gallium/targets/r600/vdpau/Makefile.am   |  2 +-
>>  src/gallium/targets/r600/vdpau/drm_target.c  |  1 +
>>  src/gallium/targets/r600/xorg/Makefile.am|  2 +-
>>  src/gallium/targets/r600/xorg/drm_target.c   |  1 +
>>  src/gallium/targets/r600/xvmc/Makefile.am|  2 +-
>>  src/gallium/targets/r600/xvmc/drm_target.c   |  1 +
>>  10 files changed, 77 insertions(+), 73 deletions(-)
>>  create mode 100644 src/gallium/targets/r600/common/drm_target.c
>>  create mode 12 src/gallium/targets/r600/dri/drm_target.c
>>  delete mode 100644 src/gallium/targets/r600/drm_target.c
>>  create mode 12 src/gallium/targets/r600/vdpau/drm_target.c
>>  create mode 12 src/gallium/targets/r600/xorg/drm_target.c
>>  create mode 12 src/gallium/targets/r600/xvmc/drm_target.c
>>
>> diff --git a/src/gallium/targets/r600/common/drm_target.c 
>> b/src/gallium/targets/r600/common/drm_target.c
>> new file mode 100644
>> index 000..28004ac
>> --- /dev/null
>> +++ b/src/gallium/targets/r600/common/drm_target.c
>> @@ -0,0 +1,69 @@
>> +/**
>> + *
>> + * Copyright 2013 Advanced Micro Devices, Inc.
>> + * All Rights Reserved.
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the
>> + * "Software"), to deal in the Software without restriction, including
>> + * without limitation the rights to use, copy, modify, merge, publish,
>> + * distribute, sub license, and/or sell copies of the Software, and to
>> + * permit persons to whom the Software is furnished to do so, subject to
>> + * the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the
>> + * next paragraph) shall be included in all copies or substantial portions
>> + * of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
>> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
>> + * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
>> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
>> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
>> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
>> + *
>> + **/
>> +
>> +#include "state_tracker/drm_driver.h"
>> +#include "target-helpers/inline_debug_helper.h"
>> +#include "radeon/drm/radeon_drm_public.h"
>> +#include "radeon/drm/radeon_winsys.h"
>> +#include "r600/r600_public.h"
>> +
>> +static struct pipe_screen *create_screen(int fd)
>> +{
>> +   struct radeon_winsys *radeon;
>> +
>> +   radeon = radeon_drm_winsys_create(fd);
>> +   if (!radeon)
>> +  return NULL;
>> +
>> +   if (!radeon->screen) {
>> +  radeon->screen = r600_screen_create(radeon);
>> +  if (!radeon->screen)
>> + return NULL;
>> +
>> +  radeon->screen = debug_screen_wrap(radeon->screen);
>> +   }
>> +
>> +   return radeon->screen;
>> +}
>> +
>> +static const struct drm_conf_ret throttle_ret = {
>> +   .type = DRM_CONF_INT,
>> +   .val.val_int = 2,
>> +};
>> +
>> +static const struct drm_conf_ret *drm_configuration(enum drm_conf conf)
>> +{
>> +   switch (conf) {
>> +   case DRM_CONF_THROTTLE:
>> +  return &throttle_ret;
>> +   default:
>> +  break;
>> +   }
>> +   return NULL;
>> +}
>> +
>> +DRM_DRIVER_DESCRIPTOR("r600", "radeon", create_screen, drm_configuration)
>> diff --gi

Re: [Mesa-dev] [PATCH 5/7] mesa: Update TexStorage to support ARB_texture_view

[Chris Forbes]

Your change to teximagemultisample just has a bunch of spurious stuff for
other targets. not harmful -- it will never get reached -- but spurious.

It might be worth pulling both blocks out into a shared helper.




On Thu, Nov 7, 2013 at 9:32 AM, Courtney Goeltzenleuchter <
court...@lunarg.com> wrote:

> Correct and I check_multisample_target checks for that.
> And we never get to this code if using a PROXY target.
> Or did I miss something?
>
>
> On Wed, Nov 6, 2013 at 1:14 PM, Chris Forbes  wrote:
>
>> The only interesting targets in teximagemultisample are
>> GL_TEXTURE_2D_MULTISAMPLE and GL_TEXTURE_2D_MULTISAMPLE_ARRAY.
>>
>> On Thu, Nov 7, 2013 at 8:55 AM, Courtney Goeltzenleuchter
>>  wrote:
>> > TexStorage and TexStorageMultisample updates texture object
>> > state needed by ARB_texture_view extension.
>> >
>> > Set appropriate TextureView state in texture object.
>> >
>> > mesa: Add ARB_texture_view
>> >
>> > Signed-off-by: Courtney Goeltzenleuchter 
>> > ---
>> >  src/mesa/main/teximage.c   | 38 ++
>> >  src/mesa/main/texstorage.c | 33 +
>> >  2 files changed, 71 insertions(+)
>> >
>> > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
>> > index 793c5d3..c01f72e 100644
>> > --- a/src/mesa/main/teximage.c
>> > +++ b/src/mesa/main/teximage.c
>> > @@ -4348,6 +4348,44 @@ teximagemultisample(GLuint dims, GLenum target,
>> GLsizei samples,
>> >}
>> >
>> >texObj->Immutable = immutable;
>> > +
>> > +  if (immutable) {
>> > + /* If the command is successful,
>> > +  * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
>> > +  * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS
>> become levels.
>> > +  * If the texture target is TEXTURE_1D_ARRAY then
>> > +  * TEXTURE_VIEW_NUM_LAYERS becomes height.
>> > +  * If the texture target is TEXTURE_2D_ARRAY,
>> TEXTURE_CUBE_MAP_ARRAY,
>> > +  * or TEXTURE_2D_MULTISAMPLE_ARRAY then
>> TEXTURE_VIEW_NUM_LAYERS becomes depth.
>> > +  * If the texture target is TEXTURE_CUBE_MAP, then
>> > +  * TEXTURE_VIEW_NUM_LAYERS becomes 6.
>> > +  * For any other texture target, TEXTURE_VIEW_NUM_LAYERS
>> becomes 1.
>> > +  * ARB_texture_multisample: Multisample textures do
>> > +  * not have multiple image levels.
>> > +  */
>> > + texObj->Immutable = GL_TRUE;
>> > + texObj->ImmutableLevels = 1;
>> > + texObj->MinLevel = 0;
>> > + texObj->NumLevels = 1;
>> > + texObj->MinLayer = 0;
>> > + texObj->NumLayers = 1;
>> > + switch (target) {
>> > + case GL_TEXTURE_1D_ARRAY:
>> > +texObj->NumLayers = height;
>> > +break;
>> > +
>> > + case GL_TEXTURE_2D_ARRAY:
>> > + case GL_TEXTURE_CUBE_MAP_ARRAY:
>> > + case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
>> > +texObj->NumLayers = depth;
>> > +break;
>> > +
>> > + case GL_TEXTURE_CUBE_MAP:
>> > +texObj->NumLayers = 6;
>> > +break;
>> > + }
>> > +  }
>> > +
>> >_mesa_update_fbo_texture(ctx, texObj, 0, 0);
>> > }
>> >  }
>> > diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
>> > index 84b8f82..4da3c91 100644
>> > --- a/src/mesa/main/texstorage.c
>> > +++ b/src/mesa/main/texstorage.c
>> > @@ -436,8 +436,41 @@ texstorage(GLuint dims, GLenum target, GLsizei
>> levels, GLenum internalformat,
>> >   return;
>> >}
>> >
>> > +  /* If the command is successful,
>> > +   * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
>> > +   * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become
>> levels.
>> > +   * If the texture target is TEXTURE_1D_ARRAY then
>> > +   * TEXTURE_VIEW_NUM_LAYERS becomes height.
>> > +   * If the texture target is TEXTURE_2D_ARRAY,
>> TEXTURE_CUBE_MAP_ARRAY,
>> > +   * or TEXTURE_2D_MULTISAMPLE_ARRAY then TEXTURE_VIEW_NUM_LAYERS
>> becomes depth.
>> > +   * If the texture target is TEXTURE_CUBE_MAP, then
>> > +   * TEXTURE_VIEW_NUM_LAYERS becomes 6.
>> > +   * For any other texture target, TEXTURE_VIEW_NUM_LAYERS becomes
>> 1.
>> > +   */
>> > +
>> >texObj->Immutable = GL_TRUE;
>> >texObj->ImmutableLevels = levels;
>> > +  texObj->MinLevel = 0;
>> > +  texObj->NumLevels = levels;
>> > +  texObj->MinLayer = 0;
>> > +  texObj->NumLayers = 1;
>> > +  switch (target)
>> > +  {
>> > +  case GL_TEXTURE_1D_ARRAY:
>> > + texObj->NumLayers = height;
>> > + break;
>> > +
>> > +  case GL_TEXTURE_2D_ARRAY:
>> > +  case GL_TEXTURE_CUBE_MAP_ARRAY:
>> > +  case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
>> > + texObj->NumLayers = depth;
>> > + break;
>> > +
>> > +  case GL_TEXTURE_CUBE_MAP:
>> > + texObj->NumLayers = 6;
>> > + break;
>> > +  }
>> > +
>> > }
>> >  }
>> >
>> > --
>> > 1.8.

Re: [Mesa-dev] [PATCH 11/37] scons: build mesa/program as a convinience library

[Emil Velikov]

On 02/11/13 19:00, Emil Velikov wrote:
> * Demangle the large and complex mesa/SConscript.
> * Make use of source file lists in Makefile.sources.
> * Makes the build systems symmetric.
> 
> Signed-off-by: Emil Velikov 
Planning to drop this patch and revisit the idea of sharing the sources
list at a later stage.

~Emil

> ---
> 
> I've tried squashing mesa & mesa_program into one library,
> but my attempts have been futile. Any ideas ?
> 
> Cheers
> Emil
> ---
>  src/gallium/targets/dri-i915/SConscript   |  1 +
>  src/gallium/targets/dri-swrast/SConscript |  1 +
>  src/gallium/targets/dri-vmwgfx/SConscript |  1 +
>  src/gallium/targets/egl-static/SConscript |  7 ++-
>  src/gallium/targets/libgl-gdi/SConscript  | 11 ++-
>  src/gallium/targets/libgl-xlib/SConscript |  1 +
>  src/mesa/SConscript   | 31 
> +--
>  src/mesa/drivers/osmesa/SConscript|  1 +
>  src/mesa/drivers/windows/gdi/SConscript   |  1 +
>  src/mesa/drivers/x11/SConscript   |  3 ++-
>  src/mesa/program/SConscript   | 29 +
>  11 files changed, 54 insertions(+), 33 deletions(-)
>  create mode 100644 src/mesa/program/SConscript
> 
> diff --git a/src/gallium/targets/dri-i915/SConscript 
> b/src/gallium/targets/dri-i915/SConscript
> index 77dca6c..045829e 100644
> --- a/src/gallium/targets/dri-i915/SConscript
> +++ b/src/gallium/targets/dri-i915/SConscript
> @@ -17,6 +17,7 @@ env.Prepend(LIBS = [
>  trace,
>  rbug,
>  mesa,
> +mesa_program,
>  glsl,
>  gallium,
>  COMMON_DRI_DRM_OBJECTS
> diff --git a/src/gallium/targets/dri-swrast/SConscript 
> b/src/gallium/targets/dri-swrast/SConscript
> index 3a70e5a..37720de 100644
> --- a/src/gallium/targets/dri-swrast/SConscript
> +++ b/src/gallium/targets/dri-swrast/SConscript
> @@ -14,6 +14,7 @@ env.Prepend(LIBS = [
>  trace,
>  rbug,
>  mesa,
> +mesa_program,
>  glsl,
>  gallium,
>  COMMON_DRI_SW_OBJECTS
> diff --git a/src/gallium/targets/dri-vmwgfx/SConscript 
> b/src/gallium/targets/dri-vmwgfx/SConscript
> index 455ef70..0691d8c 100644
> --- a/src/gallium/targets/dri-vmwgfx/SConscript
> +++ b/src/gallium/targets/dri-vmwgfx/SConscript
> @@ -21,6 +21,7 @@ env.Prepend(LIBS = [
>  svgadrm,
>  svga,
>  mesa,
> +mesa_program,
>  glsl,
>  gallium,
>  COMMON_DRI_DRM_OBJECTS
> diff --git a/src/gallium/targets/egl-static/SConscript 
> b/src/gallium/targets/egl-static/SConscript
> index b4ccc5b..a8b1e0b 100644
> --- a/src/gallium/targets/egl-static/SConscript
> +++ b/src/gallium/targets/egl-static/SConscript
> @@ -69,7 +69,12 @@ if env['gles']:
>  env.Prepend(LIBPATH = [shared_glapi.dir])
>  # manually add LIBPREFIX on windows
>  glapi_name = 'glapi' if env['platform'] != 'windows' else 'libglapi'
> -env.Prepend(LIBS = [glapi_name, glsl, mesa])
> +env.Prepend(LIBS = [
> +glapi_name,
> +mesa,
> +mesa_program,
> +glsl
> +])
>  
>  # OpenVG
>  if True:
> diff --git a/src/gallium/targets/libgl-gdi/SConscript 
> b/src/gallium/targets/libgl-gdi/SConscript
> index f8393da..5a795db 100644
> --- a/src/gallium/targets/libgl-gdi/SConscript
> +++ b/src/gallium/targets/libgl-gdi/SConscript
> @@ -47,7 +47,16 @@ if env['gles']:
>  opengl32 = env.SharedLibrary(
>  target ='opengl32',
>  source = sources,
> -LIBS = wgl + ws_gdi + glapi + mesa + drivers + gallium + glsl + 
> env['LIBS'],
> +env.Prepend(LIBS = [
> +wgl,
> +ws_gdi,
> +glapi,
> +mesa,
> +mesa_program,
> +glsl,
> +drivers,
> +gallium,
> +])
>  )
>  
>  env.Alias('opengl32', opengl32)
> diff --git a/src/gallium/targets/libgl-xlib/SConscript 
> b/src/gallium/targets/libgl-xlib/SConscript
> index fc0264c..78472c5 100644
> --- a/src/gallium/targets/libgl-xlib/SConscript
> +++ b/src/gallium/targets/libgl-xlib/SConscript
> @@ -29,6 +29,7 @@ env.Prepend(LIBS = [
>  ws_xlib,
>  glapi,
>  mesa,
> +mesa_program,
>  glsl,
>  gallium,
>  ])
> diff --git a/src/mesa/SConscript b/src/mesa/SConscript
> index a2bb9f1..2c5a838 100644
> --- a/src/mesa/SConscript
> +++ b/src/mesa/SConscript
> @@ -288,35 +288,6 @@ statetracker_sources = [
>  'state_tracker/st_vdpau.c',
>  ]
>  
> -env.Append(YACCFLAGS = '-d -p "_mesa_program_"')
> -program_lex = env.CFile('program/lex.yy.c', 'program/program_lexer.l')
> -program_parse = env.CFile('program/program_parse.tab.c',
> -  'program/program_parse.y')
> -
> -program_sources = [
> -'program/arbprogparse.c',
> -'program/prog_hash_table.c',
> -'program/ir_to_mesa.cpp',
> -'program/program.c',
> -'program/program_parse_extra.c',
> -'program/prog_cache.c',
> -'program/prog_execute.c',
> -'program/prog_instruction.c',
> -'program/prog_noise.c',
> -'program/prog_optimize.c',
> -'program/prog_opt_constant_fold.c',
> -'program

Re: [Mesa-dev] [v2 3/6] glsl: ir_serializer class for the shader cache

[Paul Berry]

On 5 November 2013 23:45, Tapani Pälli  wrote:

>  On 11/05/2013 07:36 PM, Paul Berry wrote:
>
> On 1 November 2013 02:16, Tapani Pälli  wrote:
>
>>
>> +
>> +/**
>> + * Function to create an unique string for a ir_variable. This is
>> + * used by variable dereferences to indicate the exact ir_variable
>> + * when deserialization happens.
>>
>
>  I still don't understand why we don't just use the pointer for this
> purpose.  It's unique, and it takes up much less storage than
> _.
>
>
>
> We need to construct a unique name to refer to when reading so this is
> constructed here already. It could be also just a counter like is used
> somewhere else (to have assignment_tmp@1, assignment_tmp@2) but I wanted
> to keep this code minimal as it's just unique naming.
>

I'm sorry, there's still something I'm not understanding.  Before
serialization, the names are not unique.  So I don't see why we need to
create unique names when reading.  The goal should be to reproduce the IR
data structure that was saved as closely as possible.

It seems like storing the address of the ir_variable (or some other
suitably determined unique numeric id) should be sufficient for this.  When
we serialize the ir_variable, we write out its unique numeric id.  When we
serialize an ir_dereference_variable, we write out the unique numeric id of
the ir_variable it refers to.  When deserializing an ir_variable, we store
the mapping from its unique numeric id to its new address in memory in a
hash table.  When deserializing an ir_dereference_variable, we look up the
unique numeric id to find the address of the ir_variable that's already
been deserialized.

It doesn't seem to me that uniqueness of names is necessary anywhere in
that process.  What am I missing?


>
>+
>> +   for (unsigned i = 0; i < ir->num_state_slots; i++) {
>> +  blob.write_int32(&ir->state_slots[i].swizzle);
>>
>
>  Swizzles are unsigned 8-bit values.  This should be write_uint8.
>
>
>
> OK, maybe the struct could also be changed to have only 8 bits instead of
> a int then.
>

I could get behind that change.


>
>
>   +   CACHE_DEBUG("write %d prototypes\n", total);
>
>> +
>> +   foreach_list_const(node, shader->ir) {
>> +  ir_instruction *const inst = (ir_instruction *) node;
>> +  if (inst->as_variable())
>> + if (save(inst))
>> +goto write_errors;
>> +   }
>> +
>> +   foreach_list_const(node, shader->ir) {
>> +  ir_instruction *const inst = (ir_instruction *) node;
>> +  if (inst->as_function())
>> + if (save(inst))
>> +goto write_errors;
>> +   }
>>
>
>  Why is it necessary to save the variables and instructions first?
>
>
> This is because during parsing we might encounter a call to a function
> that does not exist yet, same goes for variable references. Another way
> would be to modify the reading side so that it makes 2 passes over the data
> but I took this way as originally reader did not use mmap so it was just
> simpler.
>

Ok, I think you are correct about the functions.  But I believe for
variables, the ir_variable always appears in the IR before any references
to it.  Can someone confirm this? (Ken or Ian perhaps?)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] DEFAULT_SOFTWARE_DEPTH_BITS=31

[Brian Paul]

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

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


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


-Brian

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

Re: [Mesa-dev] [PATCH 5/7] mesa: Update TexStorage to support ARB_texture_view

[Courtney Goeltzenleuchter]

Ah, I get it, the switch statement after. Yeah, that could make sense as a
helper wouldn't it. I'll look at that.


On Wed, Nov 6, 2013 at 1:42 PM, Chris Forbes  wrote:

> Your change to teximagemultisample just has a bunch of spurious stuff for
> other targets. not harmful -- it will never get reached -- but spurious.
>
> It might be worth pulling both blocks out into a shared helper.
>
>
>
>
> On Thu, Nov 7, 2013 at 9:32 AM, Courtney Goeltzenleuchter <
> court...@lunarg.com> wrote:
>
>> Correct and I check_multisample_target checks for that.
>> And we never get to this code if using a PROXY target.
>> Or did I miss something?
>>
>>
>> On Wed, Nov 6, 2013 at 1:14 PM, Chris Forbes  wrote:
>>
>>> The only interesting targets in teximagemultisample are
>>> GL_TEXTURE_2D_MULTISAMPLE and GL_TEXTURE_2D_MULTISAMPLE_ARRAY.
>>>
>>> On Thu, Nov 7, 2013 at 8:55 AM, Courtney Goeltzenleuchter
>>>  wrote:
>>> > TexStorage and TexStorageMultisample updates texture object
>>> > state needed by ARB_texture_view extension.
>>> >
>>> > Set appropriate TextureView state in texture object.
>>> >
>>> > mesa: Add ARB_texture_view
>>> >
>>> > Signed-off-by: Courtney Goeltzenleuchter 
>>> > ---
>>> >  src/mesa/main/teximage.c   | 38 ++
>>> >  src/mesa/main/texstorage.c | 33 +
>>> >  2 files changed, 71 insertions(+)
>>> >
>>> > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
>>> > index 793c5d3..c01f72e 100644
>>> > --- a/src/mesa/main/teximage.c
>>> > +++ b/src/mesa/main/teximage.c
>>> > @@ -4348,6 +4348,44 @@ teximagemultisample(GLuint dims, GLenum target,
>>> GLsizei samples,
>>> >}
>>> >
>>> >texObj->Immutable = immutable;
>>> > +
>>> > +  if (immutable) {
>>> > + /* If the command is successful,
>>> > +  * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
>>> > +  * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS
>>> become levels.
>>> > +  * If the texture target is TEXTURE_1D_ARRAY then
>>> > +  * TEXTURE_VIEW_NUM_LAYERS becomes height.
>>> > +  * If the texture target is TEXTURE_2D_ARRAY,
>>> TEXTURE_CUBE_MAP_ARRAY,
>>> > +  * or TEXTURE_2D_MULTISAMPLE_ARRAY then
>>> TEXTURE_VIEW_NUM_LAYERS becomes depth.
>>> > +  * If the texture target is TEXTURE_CUBE_MAP, then
>>> > +  * TEXTURE_VIEW_NUM_LAYERS becomes 6.
>>> > +  * For any other texture target, TEXTURE_VIEW_NUM_LAYERS
>>> becomes 1.
>>> > +  * ARB_texture_multisample: Multisample textures do
>>> > +  * not have multiple image levels.
>>> > +  */
>>> > + texObj->Immutable = GL_TRUE;
>>> > + texObj->ImmutableLevels = 1;
>>> > + texObj->MinLevel = 0;
>>> > + texObj->NumLevels = 1;
>>> > + texObj->MinLayer = 0;
>>> > + texObj->NumLayers = 1;
>>> > + switch (target) {
>>> > + case GL_TEXTURE_1D_ARRAY:
>>> > +texObj->NumLayers = height;
>>> > +break;
>>> > +
>>> > + case GL_TEXTURE_2D_ARRAY:
>>> > + case GL_TEXTURE_CUBE_MAP_ARRAY:
>>> > + case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
>>> > +texObj->NumLayers = depth;
>>> > +break;
>>> > +
>>> > + case GL_TEXTURE_CUBE_MAP:
>>> > +texObj->NumLayers = 6;
>>> > +break;
>>> > + }
>>> > +  }
>>> > +
>>> >_mesa_update_fbo_texture(ctx, texObj, 0, 0);
>>> > }
>>> >  }
>>> > diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
>>> > index 84b8f82..4da3c91 100644
>>> > --- a/src/mesa/main/texstorage.c
>>> > +++ b/src/mesa/main/texstorage.c
>>> > @@ -436,8 +436,41 @@ texstorage(GLuint dims, GLenum target, GLsizei
>>> levels, GLenum internalformat,
>>> >   return;
>>> >}
>>> >
>>> > +  /* If the command is successful,
>>> > +   * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
>>> > +   * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become
>>> levels.
>>> > +   * If the texture target is TEXTURE_1D_ARRAY then
>>> > +   * TEXTURE_VIEW_NUM_LAYERS becomes height.
>>> > +   * If the texture target is TEXTURE_2D_ARRAY,
>>> TEXTURE_CUBE_MAP_ARRAY,
>>> > +   * or TEXTURE_2D_MULTISAMPLE_ARRAY then TEXTURE_VIEW_NUM_LAYERS
>>> becomes depth.
>>> > +   * If the texture target is TEXTURE_CUBE_MAP, then
>>> > +   * TEXTURE_VIEW_NUM_LAYERS becomes 6.
>>> > +   * For any other texture target, TEXTURE_VIEW_NUM_LAYERS
>>> becomes 1.
>>> > +   */
>>> > +
>>> >texObj->Immutable = GL_TRUE;
>>> >texObj->ImmutableLevels = levels;
>>> > +  texObj->MinLevel = 0;
>>> > +  texObj->NumLevels = levels;
>>> > +  texObj->MinLayer = 0;
>>> > +  texObj->NumLayers = 1;
>>> > +  switch (target)
>>> > +  {
>>> > +  case GL_TEXTURE_1D_ARRAY:
>>> > + texObj->NumLayers = height;
>>> > + break;
>>> > +
>>> > +  case GL_TEXTURE_2D_ARRAY:
>>> > +  case GL_T

Re: [Mesa-dev] [PATCH 3/4] mesa: fix build on kFreeBSD

[Andreas Boll]

Thanks,
I've pushed all 4 patches.

2013/11/6 Fabio Pedretti :
> Done, I also improved commit message of patches 3 and 4. Updated patches
> follow.
>
>>I think we could simplify this a bit.
>>
>>2013/11/5 Fabio Pedretti :
>>> From: Aurelien Jarno 
>>> From: Cyril Brulebois 
>>>
>>> mesa fails to build on GNU/kFreeBSD, since some parts are not enabled.
>>>
>>> Debian bug: http://bugs.debian.org/524690
>>>
>>> Patch from Debian package
>>> ---
>>>  configure.ac | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 0a25047..e250734 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -425,7 +425,7 @@ if test "x$enable_asm" = xyes; then
>>>  case "$host_cpu" in
>>>  i?86)
>>>  case "$host_os" in
>>> -linux* | *freebsd* | dragonfly* | *netbsd* | openbsd*)
>>> +linux* | *freebsd* | dragonfly* | *netbsd* | openbsd* | kfreebsd*-
> gnu*)
>>*freebsd* already includes kfreebsd*-gnu*
>>
>>>  test "x$enable_64bit" = xyes && asm_arch=x86_64 ||
> asm_arch=x86
>>>  ;;
>>>  gnu*)
>>> @@ -435,7 +435,7 @@ if test "x$enable_asm" = xyes; then
>>>  ;;
>>>  x86_64|amd64)
>>>  case "$host_os" in
>>> -linux* | *freebsd* | dragonfly* | *netbsd* | openbsd*)
>>> +linux* | *freebsd* | dragonfly* | *netbsd* | openbsd* | kfreebsd*-
> gnu*)
>>same as above
>>
>>>  test "x$enable_32bit" = xyes && asm_arch=x86 ||
> asm_arch=x86_64
>>>  ;;
>>>  esac
>>> @@ -974,7 +974,7 @@ if test "x$enable_dri" = xyes; then
>>>  ;;
>>>  esac
>>>  ;;
>>> -freebsd* | dragonfly* | *netbsd* | openbsd*)
>>> +freebsd* | dragonfly* | *netbsd* | openbsd* | kfreebsd*-gnu*)
>>
>>To be consistent we could use *freebsd* as well.
>>
>>Andreas.
>>
>>>  DEFINES="$DEFINES -DHAVE_PTHREAD -DUSE_EXTERNAL_DXTN_LIB=1"
>>>  DEFINES="$DEFINES -DHAVE_ALIAS"
>>>
>>> --
>>> 1.8.3.2
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/7] mesa: Update TexStorage to support ARB_texture_view

[Courtney Goeltzenleuchter]

Okay, making that change, the commit's flow better if patches 5,6,7 become
new 5,6,7,8.

What's the recommended process for superseding the previous patches for
these new ones?

Courtney


On Wed, Nov 6, 2013 at 2:04 PM, Courtney Goeltzenleuchter <
court...@lunarg.com> wrote:

> Ah, I get it, the switch statement after. Yeah, that could make sense as a
> helper wouldn't it. I'll look at that.
>
>
> On Wed, Nov 6, 2013 at 1:42 PM, Chris Forbes  wrote:
>
>> Your change to teximagemultisample just has a bunch of spurious stuff for
>> other targets. not harmful -- it will never get reached -- but spurious.
>>
>> It might be worth pulling both blocks out into a shared helper.
>>
>>
>>
>>
>> On Thu, Nov 7, 2013 at 9:32 AM, Courtney Goeltzenleuchter <
>> court...@lunarg.com> wrote:
>>
>>> Correct and I check_multisample_target checks for that.
>>> And we never get to this code if using a PROXY target.
>>> Or did I miss something?
>>>
>>>
>>> On Wed, Nov 6, 2013 at 1:14 PM, Chris Forbes  wrote:
>>>
 The only interesting targets in teximagemultisample are
 GL_TEXTURE_2D_MULTISAMPLE and GL_TEXTURE_2D_MULTISAMPLE_ARRAY.

 On Thu, Nov 7, 2013 at 8:55 AM, Courtney Goeltzenleuchter
  wrote:
 > TexStorage and TexStorageMultisample updates texture object
 > state needed by ARB_texture_view extension.
 >
 > Set appropriate TextureView state in texture object.
 >
 > mesa: Add ARB_texture_view
 >
 > Signed-off-by: Courtney Goeltzenleuchter 
 > ---
 >  src/mesa/main/teximage.c   | 38
 ++
 >  src/mesa/main/texstorage.c | 33 +
 >  2 files changed, 71 insertions(+)
 >
 > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
 > index 793c5d3..c01f72e 100644
 > --- a/src/mesa/main/teximage.c
 > +++ b/src/mesa/main/teximage.c
 > @@ -4348,6 +4348,44 @@ teximagemultisample(GLuint dims, GLenum
 target, GLsizei samples,
 >}
 >
 >texObj->Immutable = immutable;
 > +
 > +  if (immutable) {
 > + /* If the command is successful,
 > +  * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
 > +  * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS
 become levels.
 > +  * If the texture target is TEXTURE_1D_ARRAY then
 > +  * TEXTURE_VIEW_NUM_LAYERS becomes height.
 > +  * If the texture target is TEXTURE_2D_ARRAY,
 TEXTURE_CUBE_MAP_ARRAY,
 > +  * or TEXTURE_2D_MULTISAMPLE_ARRAY then
 TEXTURE_VIEW_NUM_LAYERS becomes depth.
 > +  * If the texture target is TEXTURE_CUBE_MAP, then
 > +  * TEXTURE_VIEW_NUM_LAYERS becomes 6.
 > +  * For any other texture target, TEXTURE_VIEW_NUM_LAYERS
 becomes 1.
 > +  * ARB_texture_multisample: Multisample textures do
 > +  * not have multiple image levels.
 > +  */
 > + texObj->Immutable = GL_TRUE;
 > + texObj->ImmutableLevels = 1;
 > + texObj->MinLevel = 0;
 > + texObj->NumLevels = 1;
 > + texObj->MinLayer = 0;
 > + texObj->NumLayers = 1;
 > + switch (target) {
 > + case GL_TEXTURE_1D_ARRAY:
 > +texObj->NumLayers = height;
 > +break;
 > +
 > + case GL_TEXTURE_2D_ARRAY:
 > + case GL_TEXTURE_CUBE_MAP_ARRAY:
 > + case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
 > +texObj->NumLayers = depth;
 > +break;
 > +
 > + case GL_TEXTURE_CUBE_MAP:
 > +texObj->NumLayers = 6;
 > +break;
 > + }
 > +  }
 > +
 >_mesa_update_fbo_texture(ctx, texObj, 0, 0);
 > }
 >  }
 > diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
 > index 84b8f82..4da3c91 100644
 > --- a/src/mesa/main/texstorage.c
 > +++ b/src/mesa/main/texstorage.c
 > @@ -436,8 +436,41 @@ texstorage(GLuint dims, GLenum target, GLsizei
 levels, GLenum internalformat,
 >   return;
 >}
 >
 > +  /* If the command is successful,
 > +   * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
 > +   * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become
 levels.
 > +   * If the texture target is TEXTURE_1D_ARRAY then
 > +   * TEXTURE_VIEW_NUM_LAYERS becomes height.
 > +   * If the texture target is TEXTURE_2D_ARRAY,
 TEXTURE_CUBE_MAP_ARRAY,
 > +   * or TEXTURE_2D_MULTISAMPLE_ARRAY then
 TEXTURE_VIEW_NUM_LAYERS becomes depth.
 > +   * If the texture target is TEXTURE_CUBE_MAP, then
 > +   * TEXTURE_VIEW_NUM_LAYERS becomes 6.
 > +   * For any other texture target, TEXTURE_VIEW_NUM_LAYERS
 becomes 1.
 > +   */
 > +
 >texObj->Immutable = GL_TRUE;
 

Re: [Mesa-dev] [PATCH 5/7] mesa: Update TexStorage to support ARB_texture_view

[Chris Forbes]

The usual way is you send out a complete new series marked V2 after
incorporating all the review comments etc.


On Thu, Nov 7, 2013 at 11:04 AM, Courtney Goeltzenleuchter <
court...@lunarg.com> wrote:

> Okay, making that change, the commit's flow better if patches 5,6,7 become
> new 5,6,7,8.
>
> What's the recommended process for superseding the previous patches for
> these new ones?
>
> Courtney
>
>
> On Wed, Nov 6, 2013 at 2:04 PM, Courtney Goeltzenleuchter <
> court...@lunarg.com> wrote:
>
>> Ah, I get it, the switch statement after. Yeah, that could make sense as
>> a helper wouldn't it. I'll look at that.
>>
>>
>> On Wed, Nov 6, 2013 at 1:42 PM, Chris Forbes  wrote:
>>
>>> Your change to teximagemultisample just has a bunch of spurious stuff
>>> for other targets. not harmful -- it will never get reached -- but spurious.
>>>
>>> It might be worth pulling both blocks out into a shared helper.
>>>
>>>
>>>
>>>
>>> On Thu, Nov 7, 2013 at 9:32 AM, Courtney Goeltzenleuchter <
>>> court...@lunarg.com> wrote:
>>>
 Correct and I check_multisample_target checks for that.
 And we never get to this code if using a PROXY target.
 Or did I miss something?


 On Wed, Nov 6, 2013 at 1:14 PM, Chris Forbes  wrote:

> The only interesting targets in teximagemultisample are
> GL_TEXTURE_2D_MULTISAMPLE and GL_TEXTURE_2D_MULTISAMPLE_ARRAY.
>
> On Thu, Nov 7, 2013 at 8:55 AM, Courtney Goeltzenleuchter
>  wrote:
> > TexStorage and TexStorageMultisample updates texture object
> > state needed by ARB_texture_view extension.
> >
> > Set appropriate TextureView state in texture object.
> >
> > mesa: Add ARB_texture_view
> >
> > Signed-off-by: Courtney Goeltzenleuchter 
> > ---
> >  src/mesa/main/teximage.c   | 38
> ++
> >  src/mesa/main/texstorage.c | 33 +
> >  2 files changed, 71 insertions(+)
> >
> > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> > index 793c5d3..c01f72e 100644
> > --- a/src/mesa/main/teximage.c
> > +++ b/src/mesa/main/teximage.c
> > @@ -4348,6 +4348,44 @@ teximagemultisample(GLuint dims, GLenum
> target, GLsizei samples,
> >}
> >
> >texObj->Immutable = immutable;
> > +
> > +  if (immutable) {
> > + /* If the command is successful,
> > +  * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
> > +  * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS
> become levels.
> > +  * If the texture target is TEXTURE_1D_ARRAY then
> > +  * TEXTURE_VIEW_NUM_LAYERS becomes height.
> > +  * If the texture target is TEXTURE_2D_ARRAY,
> TEXTURE_CUBE_MAP_ARRAY,
> > +  * or TEXTURE_2D_MULTISAMPLE_ARRAY then
> TEXTURE_VIEW_NUM_LAYERS becomes depth.
> > +  * If the texture target is TEXTURE_CUBE_MAP, then
> > +  * TEXTURE_VIEW_NUM_LAYERS becomes 6.
> > +  * For any other texture target, TEXTURE_VIEW_NUM_LAYERS
> becomes 1.
> > +  * ARB_texture_multisample: Multisample textures do
> > +  * not have multiple image levels.
> > +  */
> > + texObj->Immutable = GL_TRUE;
> > + texObj->ImmutableLevels = 1;
> > + texObj->MinLevel = 0;
> > + texObj->NumLevels = 1;
> > + texObj->MinLayer = 0;
> > + texObj->NumLayers = 1;
> > + switch (target) {
> > + case GL_TEXTURE_1D_ARRAY:
> > +texObj->NumLayers = height;
> > +break;
> > +
> > + case GL_TEXTURE_2D_ARRAY:
> > + case GL_TEXTURE_CUBE_MAP_ARRAY:
> > + case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
> > +texObj->NumLayers = depth;
> > +break;
> > +
> > + case GL_TEXTURE_CUBE_MAP:
> > +texObj->NumLayers = 6;
> > +break;
> > + }
> > +  }
> > +
> >_mesa_update_fbo_texture(ctx, texObj, 0, 0);
> > }
> >  }
> > diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
> > index 84b8f82..4da3c91 100644
> > --- a/src/mesa/main/texstorage.c
> > +++ b/src/mesa/main/texstorage.c
> > @@ -436,8 +436,41 @@ texstorage(GLuint dims, GLenum target, GLsizei
> levels, GLenum internalformat,
> >   return;
> >}
> >
> > +  /* If the command is successful,
> > +   * TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
> > +   * TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS
> become levels.
> > +   * If the texture target is TEXTURE_1D_ARRAY then
> > +   * TEXTURE_VIEW_NUM_LAYERS becomes height.
> > +   * If the texture target is TEXTURE_2D_ARRAY,
> TEXTURE_CUBE_MAP_ARRAY,
> > +   * or TEXTURE_2D_MULTISAMP

Re: [Mesa-dev] [PATCH 0/7] Add ARB_texture_view

[Chris Forbes]

Patches 1-4, 6 are:

Reviewed-by: Chris Forbes 

With the changes discussed for teximagemultisample and pulling the
view parameter setting out into a helper function, patch 5 is also:

Reviewed-by: Chris Forbes 

On Wed, Nov 6, 2013 at 11:59 AM, Courtney Goeltzenleuchter
 wrote:
> The following patches add the necessary functions to Mesa
> to support ARB_texture_view. These patches do not include
> the actual driver elements, just the device independent portion.
> This extension requires ARB_texture_storage.
>
> The extension supports one new API call, glTextureView and
> a handful of enums that have been added as queriable texture
> parameters.
>
> Adds one new driver entry point for the driver to
> map the view specified onto the origtexture given.
>
> Passes non-rendering ARB_texture_view piglit tests (recently added).
>
> Courtney Goeltzenleuchter (7):
>   mesa: Add API definitions for ARB_texture_view
>   mesa: Tracking for ARB_texture_view extension
>   mesa: update texture object for ARB_texture_view
>   mesa: ARB_texture_view get parameters
>   mesa: Update TexStorage to support ARB_texture_view
>   mesa: Add driver entry point for ARB_texture_view
>   mesa: Fill out ARB_texture_view entry points
>
>  src/mapi/glapi/gen/ARB_texture_view.xml |  23 ++
>  src/mapi/glapi/gen/Makefile.am  |   1 +
>  src/mapi/glapi/gen/gl_API.xml   |   6 +-
>  src/mapi/glapi/gen/gl_genexec.py|   1 +
>  src/mesa/Makefile.sources   |   1 +
>  src/mesa/SConscript |   1 +
>  src/mesa/drivers/common/driverfuncs.c   |   3 +
>  src/mesa/main/dd.h  |   5 +
>  src/mesa/main/extensions.c  |   1 +
>  src/mesa/main/mtypes.h  |   6 +
>  src/mesa/main/tests/dispatch_sanity.cpp |   2 +-
>  src/mesa/main/texparam.c|  60 ++-
>  src/mesa/main/texstorage.c  |  32 ++
>  src/mesa/main/textureview.c | 621 
> 
>  src/mesa/main/textureview.h |  39 ++
>  15 files changed, 796 insertions(+), 6 deletions(-)
>  create mode 100644 src/mapi/glapi/gen/ARB_texture_view.xml
>  create mode 100644 src/mesa/main/textureview.c
>  create mode 100644 src/mesa/main/textureview.h
>
> --
> 1.8.1.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: deduplicate some indirect register address code

[Zack Rusin]

Looks good.

Reviewed-by: Zack Rusin 

- Original Message -
> From: Roland Scheidegger 
> 
> There's only one minor functional change, for immediates the pixel offsets
> are no longer added since the values are all the same for all elements in
> any case (it might be better if those weren't stored as soa vectors in the
> first place maybe).
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c |  253
>  +--
>  1 file changed, 96 insertions(+), 157 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> index 75f6def..5f81066 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> @@ -898,6 +898,39 @@ stype_to_fetch(struct lp_build_tgsi_context * bld_base,
>  }
>  
>  static LLVMValueRef
> +get_soa_array_offsets(struct lp_build_context *uint_bld,
> +  LLVMValueRef indirect_index,
> +  unsigned chan_index,
> +  boolean need_perelement_offset)
> +{
> +   struct gallivm_state *gallivm = uint_bld->gallivm;
> +   LLVMValueRef chan_vec =
> +  lp_build_const_int_vec(uint_bld->gallivm, uint_bld->type, chan_index);
> +   LLVMValueRef length_vec =
> +  lp_build_const_int_vec(gallivm, uint_bld->type,
> uint_bld->type.length);
> +   LLVMValueRef index_vec;
> +
> +   /* index_vec = (indirect_index * 4 + chan_index) * length + offsets */
> +   index_vec = lp_build_shl_imm(uint_bld, indirect_index, 2);
> +   index_vec = lp_build_add(uint_bld, index_vec, chan_vec);
> +   index_vec = lp_build_mul(uint_bld, index_vec, length_vec);
> +
> +   if (need_perelement_offset) {
> +  LLVMValueRef pixel_offsets;
> +  int i;
> + /* build pixel offset vector: {0, 1, 2, 3, ...} */
> +  pixel_offsets = uint_bld->undef;
> +  for (i = 0; i < uint_bld->type.length; i++) {
> + LLVMValueRef ii = lp_build_const_int32(gallivm, i);
> + pixel_offsets = LLVMBuildInsertElement(gallivm->builder,
> pixel_offsets,
> +ii, ii, "");
> +  }
> +  index_vec = lp_build_add(uint_bld, index_vec, pixel_offsets);
> +   }
> +   return index_vec;
> +}
> +
> +static LLVMValueRef
>  emit_fetch_constant(
> struct lp_build_tgsi_context * bld_base,
> const struct tgsi_full_src_register * reg,
> @@ -908,7 +941,6 @@ emit_fetch_constant(
> struct gallivm_state *gallivm = bld_base->base.gallivm;
> LLVMBuilderRef builder = gallivm->builder;
> struct lp_build_context *uint_bld = &bld_base->uint_bld;
> -   LLVMValueRef indirect_index = NULL;
> unsigned dimension = 0;
> LLVMValueRef dimension_index;
> LLVMValueRef consts_ptr;
> @@ -927,16 +959,15 @@ emit_fetch_constant(
> consts_ptr = lp_build_array_get(gallivm, bld->consts_ptr,
> dimension_index);
>  
> if (reg->Register.Indirect) {
> +  LLVMValueRef indirect_index;
> +  LLVMValueRef swizzle_vec =
> + lp_build_const_int_vec(gallivm, uint_bld->type, swizzle);
> +  LLVMValueRef index_vec;  /* index into the const buffer */
> +
>indirect_index = get_indirect_index(bld,
>reg->Register.File,
>reg->Register.Index,
>®->Indirect);
> -   }
> -
> -   if (reg->Register.Indirect) {
> -  LLVMValueRef swizzle_vec =
> - lp_build_const_int_vec(bld->bld_base.base.gallivm, uint_bld->type,
> swizzle);
> -  LLVMValueRef index_vec;  /* index into the const buffer */
>  
>/* index_vec = indirect_index * 4 + swizzle */
>index_vec = lp_build_shl_imm(uint_bld, indirect_index, 2);
> @@ -949,7 +980,7 @@ emit_fetch_constant(
>LLVMValueRef index;  /* index into the const buffer */
>LLVMValueRef scalar, scalar_ptr;
>  
> -  index = lp_build_const_int32(gallivm, reg->Register.Index*4 +
> swizzle);
> +  index = lp_build_const_int32(gallivm, reg->Register.Index * 4 +
> swizzle);
>  
>scalar_ptr = LLVMBuildGEP(builder, consts_ptr,
>  &index, 1, "");
> @@ -974,49 +1005,32 @@ emit_fetch_immediate(
> struct lp_build_tgsi_soa_context * bld = lp_soa_context(bld_base);
> struct gallivm_state *gallivm = bld->bld_base.base.gallivm;
> LLVMBuilderRef builder = gallivm->builder;
> -   struct lp_build_context *uint_bld = &bld_base->uint_bld;
> -   struct lp_build_context *float_bld = &bld_base->base;
> LLVMValueRef res = NULL;
> -   LLVMValueRef indirect_index = NULL;
>  
> if (reg->Register.Indirect) {
> +  LLVMValueRef indirect_index;
> +  LLVMValueRef index_vec;  /* index into the immediate register array */
> +  LLVMValueRef imms_array;
> +  LLVMTypeRef fptr_type;
> +
>indirect_index = get_indirect_index(bld,
>reg->Register.File,
>  

Re: [Mesa-dev] [PATCH 00/11] Implement GL_ARB_vertex_attrib_binding

[Eric Anholt]

Fredrik Höglund  writes:

> So here's ARB_vertex_attrib_binding, take two.
>
> This incorporates all the feedback from Eric and Ian.
>
> Patches 6, 7, and 8 in the previous series have now been squashed into
> patch 5.  This is unfortunate, since patch 5 was already larger than
> I would have liked, but unfortunately it's necessary to avoid piglit
> regressions between patches 5 and 8.
>
> This series is also available at:
>
> git://people.freedesktop.org/~fredrik/mesa arb-vertex-attrib-binding-2

The last 2 also get my reviewed-by.  I'm hoping you can land this before
the branchpoint.


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

Re: [Mesa-dev] [PATCH 1/2] mesa: Add a streaming load memcpy implementation.

[Eric Anholt]

Matt Turner  writes:

> Uses SSE 4.1's MOVNTDQA instruction (streaming load) to read from
> uncached memory without polluting the cache.
> ---
> We should add runtime detection support later.

I'd really like to see runtime detection with this.  Effectively not
supporting this on 32-bit sucks, and doing it this way will encourage
people to use compiler flags to get this path, even when those compiler
flags hurt performance in general (in my testing, at least).


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

[Mesa-dev] [PATCH 0/6 v2] radeon: Plug some memory leaks

[Aaron Watry]

Turns out that I don't have commit access to Mesa, just piglit.  Feel
free to push if they look good.

I decided to have some fun and hooked valgrind up to my SI while running
a few OpenCL tests in piglit. This is the first batch of fixes.

Aaron Watry (6):
  radeon/llvm: fix spelling error
  radeon/llvm: Free libelf resources
  radeon/llvm: Free created llvm memory buffer
  radeonsi/compute: Free program and program.kernels on shutdown
  radeonsi/compute: Dispose of LLVM module after compiling kernels
  gallium/pipe_loader: un-reference udev resources when we're done with
them.

v2: Fix indentation in patches 2, 3, 4, and 5.

 src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c |  3 +++
 src/gallium/drivers/radeon/radeon_llvm_emit.c   |  3 +++
 src/gallium/drivers/radeon/radeon_llvm_util.c   |  1 +
 src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c |  2 +-
 src/gallium/drivers/radeonsi/radeonsi_compute.c | 17 -
 5 files changed, 24 insertions(+), 2 deletions(-)

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

[Mesa-dev] [PATCH 4/6] radeonsi/compute: Free program and program.kernels on shutdown

[Aaron Watry]

v2: Fix indentation

Reviewed-by: Tom Stellard 
---
 src/gallium/drivers/radeonsi/radeonsi_compute.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/radeonsi_compute.c 
b/src/gallium/drivers/radeonsi/radeonsi_compute.c
index 265dbd7..32d2487 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_compute.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_compute.c
@@ -236,7 +236,21 @@ static void radeonsi_launch_grid(
 }
 
 
-static void si_delete_compute_state(struct pipe_context *ctx, void* state){}
+static void si_delete_compute_state(struct pipe_context *ctx, void* state){
+   struct si_pipe_compute *program = (struct si_pipe_compute *)state;
+
+   if (!state) {
+   return;
+   }
+
+   if (program->kernels) {
+   FREE(program->kernels);
+   }
+
+   //And then free the program itself.
+   FREE(program);
+}
+
 static void si_set_compute_resources(struct pipe_context * ctx_,
unsigned start, unsigned count,
struct pipe_surface ** surfaces) { }
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 6/6] gallium/pipe_loader: un-reference udev resources when we're done with them.

[Aaron Watry]

Reviewed-by: Tom Stellard 
---
 src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c 
b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
index 339d7bf..927fb24 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
@@ -88,6 +88,9 @@ find_drm_pci_id(struct pipe_loader_drm_device *ddev)
   &ddev->base.u.pci.chip_id) != 2)
   goto fail;
 
+   udev_device_unref(device);
+   udev_unref(udev);
+
return TRUE;
 
   fail:
-- 
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/6] radeon/llvm: Free libelf resources

[Aaron Watry]

v2: Fix indentation

Reviewed-by: Tom Stellard 
---
 src/gallium/drivers/radeon/radeon_llvm_emit.c | 3 +++
 1 file changed, 3 insertions(+)

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

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

[Mesa-dev] [PATCH 1/6] radeon/llvm: fix spelling error

[Aaron Watry]

Reviewed-by: Tom Stellard 
---
 src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c 
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 286ccdd..57026bf 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -1379,7 +1379,7 @@ void radeon_llvm_finalize_module(struct 
radeon_llvm_context * ctx)
LLVMAddAggressiveDCEPass(gallivm->passmgr);
LLVMAddCFGSimplificationPass(gallivm->passmgr);
 
-   /* Run the passs */
+   /* Run the pass */
LLVMRunFunctionPassManager(gallivm->passmgr, ctx->main_fn);
 
LLVMDisposeBuilder(gallivm->builder);
-- 
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/6] radeonsi/compute: Dispose of LLVM module after compiling kernels

[Aaron Watry]

v2: Fix indentation

Reviewed-by: Tom Stellard 
---
 src/gallium/drivers/radeonsi/radeonsi_compute.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/radeonsi/radeonsi_compute.c 
b/src/gallium/drivers/radeonsi/radeonsi_compute.c
index 32d2487..fff9b76 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_compute.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_compute.c
@@ -49,6 +49,7 @@ static void *radeonsi_create_compute_state(
LLVMModuleRef mod = radeon_llvm_get_kernel_module(i, code,
header->num_bytes);
si_compile_llvm(rctx, &program->kernels[i], mod);
+   LLVMDisposeModule(mod);
}
 
return program;
-- 
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/6] radeon/llvm: Free created llvm memory buffer

[Aaron Watry]

v2: Fix indentation

Reviewed-by: Tom Stellard 
---
 src/gallium/drivers/radeon/radeon_llvm_util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c 
b/src/gallium/drivers/radeon/radeon_llvm_util.c
index 7192dee..f2b3e13 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_util.c
+++ b/src/gallium/drivers/radeon/radeon_llvm_util.c
@@ -42,6 +42,7 @@ LLVMModuleRef radeon_llvm_parse_bitcode(const unsigned char * 
bitcode,
buf = LLVMCreateMemoryBufferWithMemoryRangeCopy((const char*)bitcode,
bitcode_len, "radeon");
LLVMParseBitcodeInContext(ctx, buf, &module, NULL);
+   LLVMDisposeMemoryBuffer(buf);
return module;
 }
 
-- 
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] i965: Use has_surface_tile_offset in depth/stencil alignment workaround.

[Eric Anholt]

Kenneth Graunke  writes:

> Currently, has_surface_tile_offset is equivalent to gen == 4 && !is_g4x.
>
> We already use it for related checks in brw_wm_surface_state.c, so it
> makes sense to use it here too.  It's simpler and more future-proof.
>
> Broadwell also lacks surface tile offsets.  With this patch, I won't
> need to update any generation checking; I can simply not set the flag.
>
> Signed-off-by: Kenneth Graunke 

Reviewed-by: Eric Anholt 

I sure wish I could kill this code.


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

Re: [Mesa-dev] DEFAULT_SOFTWARE_DEPTH_BITS=31

[burlen]

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

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

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


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




I'm using OSMesa with VTK for rendering on systems that do not have 
graphics hardware. I need higher than default depth buffer with OSMesa 
to prevent z-buffer fighting artifacts in some cases when rendering in 
parallel. I found that --with-osmesa-bits=32 does the trick. however 
when building osmesa with 32 bits, most line rendering fails. Here is a 
representative image diff from our regression suite that shows an 
example of the bug 
http://open.cdash.org/testDetails.php?test=216532438&build=3087854 , 
there are 80 other failed tests, the ones I examined were all the same.


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


Thanks
Burlen

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

[Mesa-dev] [PATCH] Add DRM_MODE_PAGE_FLIP_ASYNC define

[Keith Packard]

This exposes the kernel API for performing asynchronous flips

Signed-off-by: Keith Packard 
---

 include/drm/drm.h  | 1 +
 include/drm/drm_mode.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 725bf51..f0b4c16 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -797,6 +797,7 @@ struct drm_event_vblank {
 #define DRM_CAP_DUMB_PREFER_SHADOW 0x4
 #define DRM_CAP_PRIME 0x5
 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
+#define DRM_CAP_ASYNC_PAGE_FLIP 0x7
 
 #define DRM_PRIME_CAP_IMPORT 0x1
 #define DRM_PRIME_CAP_EXPORT 0x2
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index c1bb1a3..76fd76b 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -425,7 +425,8 @@ struct drm_mode_crtc_lut {
 };
 
 #define DRM_MODE_PAGE_FLIP_EVENT 0x01
-#define DRM_MODE_PAGE_FLIP_FLAGS DRM_MODE_PAGE_FLIP_EVENT
+#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
+#define DRM_MODE_PAGE_FLIP_FLAGS 
(DRM_MODE_PAGE_FLIP_EVENT|DRM_MODE_PAGE_FLIP_ASYNC)
 
 /*
  * Request a page flip on the specified crtc.
-- 
1.8.4.2

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

Re: [Mesa-dev] [PATCH] Add DRM_MODE_PAGE_FLIP_ASYNC define

[Eric Anholt]

Keith Packard  writes:

> This exposes the kernel API for performing asynchronous flips
>
> Signed-off-by: Keith Packard 

Reviewed-by: Eric Anholt 


pgpWaOc6OxPM4.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 02/11] mesa: implement GL_ARB_draw_indirect and GL_ARB_multi_draw_indirect

[Paul Berry]

On 4 November 2013 06:57, Brian Paul  wrote:

> On 11/04/2013 02:09 AM, Chris Forbes wrote:
>
>> From: Christoph Bumiller 
>>
>>
>> diff --git a/src/mapi/glapi/gen/ARB_draw_indirect.xml
>> b/src/mapi/glapi/gen/ARB_draw_indirect.xml
>> new file mode 100644
>> index 000..7de03cd
>> --- /dev/null
>> +++ b/src/mapi/glapi/gen/ARB_draw_indirect.xml
>> @@ -0,0 +1,45 @@
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>>
>
> The use of GLvoid has been removed in glext.h and I'd be OK with doing the
> same in the dispatch code.


I'd be in favor of that too, but I think it should be done as a separate
patch series--at the moment all the dispatch xml consistently uses GLvoid,
so IMHO we should stay consistent for now, and then later switch everything
over to "void" in one fell swoop.


>
>
>
>  +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +> exec="dynamic">
>> +
>> +
>> +
>> +
>> +
>> +
>> +> exec="dynamic">
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> diff --git a/src/mapi/glapi/gen/Makefile.am
>> b/src/mapi/glapi/gen/Makefile.am
>> index cbbf659..0c67513 100644
>> --- a/src/mapi/glapi/gen/Makefile.am
>> +++ b/src/mapi/glapi/gen/Makefile.am
>> @@ -98,6 +98,7 @@ API_XML = \
>> ARB_draw_buffers.xml \
>> ARB_draw_buffers_blend.xml \
>> ARB_draw_elements_base_vertex.xml \
>> +   ARB_draw_indirect.xml \
>> ARB_draw_instanced.xml \
>> ARB_ES2_compatibility.xml \
>> ARB_ES3_compatibility.xml \
>> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.
>> xml
>> index 69014c5..7cab5ba 100644
>> --- a/src/mapi/glapi/gen/gl_API.xml
>> +++ b/src/mapi/glapi/gen/gl_API.xml
>> @@ -8241,6 +8241,8 @@
>>
>>   
>>
>> +http://www.w3.org/
>> 2001/XInclude"/>
>> +
>>   
>> 
>> 
>> @@ -8466,7 +8468,7 @@
>>
>>   http://www.w3.org/2001/XInclude"/>
>>
>> -
>> +
>>
>>   http://www.w3.org/2001/XInclude"/>
>>
>> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
>> index f285c97..f3128cb 100644
>> --- a/src/mesa/main/api_validate.c
>> +++ b/src/mesa/main/api_validate.c
>> @@ -837,3 +837,156 @@ _mesa_validate_DrawTransformFeedback(struct
>> gl_context *ctx,
>>
>>  return GL_TRUE;
>>   }
>> +
>>
>
> Maybe put a comment on this describing what 'size' is.
>
>
>  +static GLboolean
>> +valid_draw_indirect(struct gl_context *ctx,
>> +GLenum mode, const GLvoid *indirect,
>> +GLsizei size, const char *name)
>> +{
>> +   const GLsizeiptr end = (GLsizeiptr)indirect + size;
>> +
>> +   if (!_mesa_valid_prim_mode(ctx, mode, name))
>> +  return GL_FALSE;
>> +
>> +   if ((GLsizeiptr)indirect & (sizeof(GLuint) - 1)) {
>> +  _mesa_error(ctx, GL_INVALID_OPERATION,
>> +  "%s(indirect is not aligned)", name);
>> +  return GL_FALSE;
>> +   }
>> +
>> +   if (_mesa_is_bufferobj(ctx->DrawIndirectBuffer)) {
>> +  if (_mesa_bufferobj_mapped(ctx->DrawIndirectBuffer)) {
>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>> + "%s(DRAW_INDIRECT_BUFFER is mapped)", name);
>> + return GL_FALSE;
>> +  }
>> +  if (ctx->DrawIndirectBuffer->Size < end) {
>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>> + "%s(DRAW_INDIRECT_BUFFER too small)", name);
>> + return GL_FALSE;
>> +  }
>> +   } else {
>> +  if (ctx->API != API_OPENGL_COMPAT) {
>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>> + "%s: no buffer bound to DRAW_INDIRECT_BUFFER",
>> name);
>> + return GL_FALSE;
>> +  }
>> +   }
>> +
>> +   if (!check_valid_to_render(ctx, name))
>> +  return GL_FALSE;
>> +
>> +   return GL_TRUE;
>> +}
>> +
>> +static inline GLboolean
>> +valid_draw_indirect_elements(struct gl_context *ctx,
>> + GLenum mode, GLenum type, const GLvoid
>> *indirect,
>> + GLsizeiptr size, const char *name)
>> +{
>> +   if (!valid_elements_type(ctx, type, name))
>> +  return GL_FALSE;
>> +
>> +   /*
>> +* Unlike regular DrawElementsInstancedBaseVertex commands, the
>> indices
>> +* may not come from a client array and must come from an index
>> buffer.
>> +* If no element array buffer is bound, an INVALID_OPERATION error is
>> +* generated.
>> +*/
>> +   if (!_mesa_is_bufferobj(ctx->Array.ArrayObj->ElementArrayBufferObj))
>> {
>> +  _mesa_error(ctx, GL_INVALID_OPERATION,
>> +  "%s(no buffer bound to GL_ELEMENT_ARRAY_BUFFER)",
>> name);
>> +  return GL_FALSE;
>> +   }
>> +
>> +   return valid_draw_indirect(ctx, mode, indirect, size, name);
>> +}
>> +
>> +static inline GLboolean
>> +valid_draw_indirect_multi(struct gl_context *ctx,
>> +  GLsizei primcount, GLsizei stride,
>> + 

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

[Chad Versace]

On 11/05/2013 01:35 PM, Matt Turner wrote:

---
Chad has benchmark numbers, I think.


Put this in the commit message:

  Improves performance of RoboHornet's 2D Canvas toDataURL benchmark
  [http://www.robohornet.org/#e=canvastodataurl] by approximately 5x
  on Baytrail on ChromiumOS.



  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 88 +++
  1 file changed, 88 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 2f5e04f..17f0075 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -1774,6 +1774,86 @@ intel_miptree_unmap_blit(struct brw_context *brw,
 intel_miptree_release(&map->mt);
  }

+#ifdef __SSE4_1__
+/**
+ * "Map" a buffer by copying it to an untiled temporary using MOVNTDQA.
+ */
+static void
+intel_miptree_map_movntdqa(struct brw_context *brw,
+   struct intel_mipmap_tree *mt,
+   struct intel_miptree_map *map,
+   unsigned int level, unsigned int slice)
+{
+   assert(map->mode & GL_MAP_READ_BIT);
+   assert(!(map->mode & GL_MAP_WRITE_BIT));
+
+   DBG("%s: %d,%d %dx%d from mt %p (%s) %d,%d = %p/%d\n", __FUNCTION__,
+   map->x, map->y, map->w, map->h,
+   mt, _mesa_get_format_name(mt->format),
+   level, slice, map->ptr, map->stride);
+
+   /* Map the original image */
+   uint32_t image_x;
+   uint32_t image_y;
+   intel_miptree_get_image_offset(mt, level, slice, &image_x, &image_y);
+   image_x += map->x;
+   image_y += map->y;
+
+   void *src = intel_miptree_map_raw(brw, mt);
+   if (!src) {
+  _mesa_align_free(map->buffer);


I don't think _mesa_align_free() should be here. In fact, I see no
reason to free map->buffer here at all, because it has not yet been
allocated.


+  map->buffer = NULL;
+  map->ptr = NULL;
+  return;
+   }
+   src += image_y * mt->region->pitch;
+   src += image_x * mt->region->cpp;
+
+   /* Due to the pixel offsets for the particular image being mapped, our
+* src pointer may not be 16-byte aligned.  However, if the pitch is
+* divisible by 16, then the amount by which it's misaligned will remain
+* consistent from row to row.
+*/
+   assert((mt->region->pitch % 16) == 0);
+   const int misalignment = ((uintptr_t) src) & 15;

  ^
Thanks for using const. It makes it easier to reason about the code.


+
+   /* Create an untiled temporary buffer for the mapping. */
+   unsigned stride = _mesa_format_row_stride(mt->format, map->w);

  

Likewise, let's make that `const unsigned`.

Also, this is a nitpick that you can ignore. The variable `stride`
does not follow the conventions throughout the rest of Mesa. Stride
is the length of a row, including any padding. Yet, in this patch,
`stride` is the row length *without* padding, and `map->stride`
is the row length *with* padding. I'd like to see the variable renamed
to something that complies with the conventions in the rest of Mesa
and the miptree code. Maybe `width_bytes`.


+
+   map->stride = ALIGN(misalignment + stride, 16);
+
+   map->buffer = malloc(misalignment + map->stride * map->h * mt->region->cpp);

     

The presence of cpp in malloc causes the buffer to be too large. map->stride is 
in units
of bytes, so it already includes the cpp.

Also, I don't understand why `misalignment` is added to `map->stride * map->h`. 
map->stride
already includes padding for the misalignment.


+   /* Offset the destination so it has the same misalignment as src. */
+   map->ptr = map->buffer + misalignment;
+
+   assertuintptr_t) map->ptr) & 15) == misalignment);
+
+   for (uint32_t y = 0; y < map->h; y++) {
+  void *dst_ptr = map->ptr + y * map->stride;
+  void *src_ptr = src + y * mt->region->pitch;
+
+  _mesa_streaming_load_memcpy(dst_ptr, src_ptr, stride);
+
+  dst_ptr += stride;
+  src_ptr += stride;
+   }
+
+   intel_miptree_unmap_raw(brw, mt);
+}


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

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

[Colin Walters]

Hi Matt, thanks for the CC!

On Tue, 2013-11-05 at 15:14 -0800, Matt Turner wrote:
> We do support out of tree builds now.

Indeed, I added this patch on top of the 9.2 branch and ran it through
gnome-continuous, appears to build and work OK.

Tested-By: Colin Walters 


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

[Mesa-dev] Fwd: Bug#728053: [PATCH] mesa: FTBFS: invalid alignment assumptions

[Thorsten Glaser]

Hi everyone,

here’s a bugfix to make implicit alignment and padding
assumptions explicit, please apply.

Thanks,
//mirabilos
-- 
21:26⎜ cool cool, pitch ist zu hoch
21:26⎜ eingebauter chipmunk modus in dragonfly bsd │ I luv it ^^
21:31⎜«yofuh» ich glaube ich wuerde den rechner aussm fenster werfen,
 ⎜wenn er beim booten das chipmunks intro spielt

-- Forwarded message --
From: Julien Cristau 
Message-ID: <20131106151538.gg4...@betterave.cristau.org>
X-Spam-Status: No, hits=0.00 required=0.90
To: Thorsten Glaser , 728...@bugs.debian.org
Date: Wed, 6 Nov 2013 16:15:38 +0100
Subject: Re: Bug#728053: [PATCH] mesa: FTBFS: invalid alignment assumptions

On Fri, Nov  1, 2013 at 17:25:11 +, Thorsten Glaser wrote:

> tags 728053 + patch
> thanks
> 
> Dear Maintainers,
> 
> I’ve prepared the attached patch for mesa to fix this issue and
> built it once, fully, to test that it no longer FTBFSes with it
> applied. Please add this patch to the Debian package as well as
> forward it upstream.
> 
Please send it to mesa-dev@lists.freedesktop.org yourself.

Cheers,
Juliendiff -u mesa-9.2.2/debian/changelog mesa-9.2.2/debian/changelog
--- mesa-9.2.2/debian/changelog
+++ mesa-9.2.2/debian/changelog
@@ -1,3 +1,9 @@
+mesa (9.2.2-1+m68k.1) unreleased; urgency=low
+
+  * Fix struct alignment assumptions. (Closes: #728053)
+
+ -- Thorsten Glaser   Wed, 30 Oct 2013 18:05:12 +0100
+
 mesa (9.2.2-1) unstable; urgency=low
 
   * New upstream release.
diff -u mesa-9.2.2/debian/patches/series mesa-9.2.2/debian/patches/series
--- mesa-9.2.2/debian/patches/series
+++ mesa-9.2.2/debian/patches/series
@@ -1,3 +1,4 @@
+12-m68k-struct-alignment.diff
 01_gbm_egl.diff
 02_gbm_no_undefined.diff
 04_osmesa_version.diff
only in patch2:
unchanged:
--- mesa-9.2.2.orig/debian/patches/12-m68k-struct-alignment.diff
+++ mesa-9.2.2/debian/patches/12-m68k-struct-alignment.diff
@@ -0,0 +1,26 @@
+From: Thorsten Glaser ___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] mesa: Add a streaming load memcpy implementation.

[Chad Versace]

On 11/06/2013 02:44 PM, Eric Anholt wrote:

Matt Turner  writes:


Uses SSE 4.1's MOVNTDQA instruction (streaming load) to read from
uncached memory without polluting the cache.
---
We should add runtime detection support later.


I'd really like to see runtime detection with this.  Effectively not
supporting this on 32-bit sucks, and doing it this way will encourage
people to use compiler flags to get this path, even when those compiler
flags hurt performance in general (in my testing, at least).


This patch, as-is without runtime detection, benefits platform-specific
Linux builds such as ChromiumOS. Seeing that the patch benefits
immediately for some distros, I see no reason to block the patch for lack
of runtime detection.

I would also like to see runtime detection as a follow-up.

Patch 1 is
Reviewed-by: Chad Versace 

By the way, I tested this series by playing around on ChromiumOS,
but I don't believe that warrants a Tested-by.

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

Re: [Mesa-dev] [PATCH 02/11] mesa: implement GL_ARB_draw_indirect and GL_ARB_multi_draw_indirect

[Chris Forbes]

I'm hoping I don't need the save_ stuff at all, if I only enable this
in core contexts. Is that OK?

On Thu, Nov 7, 2013 at 1:44 PM, Paul Berry  wrote:
> On 4 November 2013 06:57, Brian Paul  wrote:
>>
>> On 11/04/2013 02:09 AM, Chris Forbes wrote:
>>>
>>> From: Christoph Bumiller 
>>>
>>>
>>> diff --git a/src/mapi/glapi/gen/ARB_draw_indirect.xml
>>> b/src/mapi/glapi/gen/ARB_draw_indirect.xml
>>> new file mode 100644
>>> index 000..7de03cd
>>> --- /dev/null
>>> +++ b/src/mapi/glapi/gen/ARB_draw_indirect.xml
>>> @@ -0,0 +1,45 @@
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>
>>
>> The use of GLvoid has been removed in glext.h and I'd be OK with doing the
>> same in the dispatch code.
>
>
> I'd be in favor of that too, but I think it should be done as a separate
> patch series--at the moment all the dispatch xml consistently uses GLvoid,
> so IMHO we should stay consistent for now, and then later switch everything
> over to "void" in one fell swoop.
>
>>
>>
>>
>>
>>> +
>>> +
>>> +>> exec="dynamic">
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +>> exec="dynamic">
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +>> exec="dynamic">
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> diff --git a/src/mapi/glapi/gen/Makefile.am
>>> b/src/mapi/glapi/gen/Makefile.am
>>> index cbbf659..0c67513 100644
>>> --- a/src/mapi/glapi/gen/Makefile.am
>>> +++ b/src/mapi/glapi/gen/Makefile.am
>>> @@ -98,6 +98,7 @@ API_XML = \
>>> ARB_draw_buffers.xml \
>>> ARB_draw_buffers_blend.xml \
>>> ARB_draw_elements_base_vertex.xml \
>>> +   ARB_draw_indirect.xml \
>>> ARB_draw_instanced.xml \
>>> ARB_ES2_compatibility.xml \
>>> ARB_ES3_compatibility.xml \
>>> diff --git a/src/mapi/glapi/gen/gl_API.xml
>>> b/src/mapi/glapi/gen/gl_API.xml
>>> index 69014c5..7cab5ba 100644
>>> --- a/src/mapi/glapi/gen/gl_API.xml
>>> +++ b/src/mapi/glapi/gen/gl_API.xml
>>> @@ -8241,6 +8241,8 @@
>>>
>>>   
>>>
>>> +>> xmlns:xi="http://www.w3.org/2001/XInclude"/>
>>> +
>>>   
>>> 
>>> 
>>> @@ -8466,7 +8468,7 @@
>>>
>>>   >> xmlns:xi="http://www.w3.org/2001/XInclude"/>
>>>
>>> -
>>> +
>>>
>>>   >> xmlns:xi="http://www.w3.org/2001/XInclude"/>
>>>
>>> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
>>> index f285c97..f3128cb 100644
>>> --- a/src/mesa/main/api_validate.c
>>> +++ b/src/mesa/main/api_validate.c
>>> @@ -837,3 +837,156 @@ _mesa_validate_DrawTransformFeedback(struct
>>> gl_context *ctx,
>>>
>>>  return GL_TRUE;
>>>   }
>>> +
>>
>>
>> Maybe put a comment on this describing what 'size' is.
>>
>>
>>> +static GLboolean
>>> +valid_draw_indirect(struct gl_context *ctx,
>>> +GLenum mode, const GLvoid *indirect,
>>> +GLsizei size, const char *name)
>>> +{
>>> +   const GLsizeiptr end = (GLsizeiptr)indirect + size;
>>> +
>>> +   if (!_mesa_valid_prim_mode(ctx, mode, name))
>>> +  return GL_FALSE;
>>> +
>>> +   if ((GLsizeiptr)indirect & (sizeof(GLuint) - 1)) {
>>> +  _mesa_error(ctx, GL_INVALID_OPERATION,
>>> +  "%s(indirect is not aligned)", name);
>>> +  return GL_FALSE;
>>> +   }
>>> +
>>> +   if (_mesa_is_bufferobj(ctx->DrawIndirectBuffer)) {
>>> +  if (_mesa_bufferobj_mapped(ctx->DrawIndirectBuffer)) {
>>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>>> + "%s(DRAW_INDIRECT_BUFFER is mapped)", name);
>>> + return GL_FALSE;
>>> +  }
>>> +  if (ctx->DrawIndirectBuffer->Size < end) {
>>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>>> + "%s(DRAW_INDIRECT_BUFFER too small)", name);
>>> + return GL_FALSE;
>>> +  }
>>> +   } else {
>>> +  if (ctx->API != API_OPENGL_COMPAT) {
>>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>>> + "%s: no buffer bound to DRAW_INDIRECT_BUFFER",
>>> name);
>>> + return GL_FALSE;
>>> +  }
>>> +   }
>>> +
>>> +   if (!check_valid_to_render(ctx, name))
>>> +  return GL_FALSE;
>>> +
>>> +   return GL_TRUE;
>>> +}
>>> +
>>> +static inline GLboolean
>>> +valid_draw_indirect_elements(struct gl_context *ctx,
>>> + GLenum mode, GLenum type, const GLvoid
>>> *indirect,
>>> + GLsizeiptr size, const char *name)
>>> +{
>>> +   if (!valid_elements_type(ctx, type, name))
>>> +  return GL_FALSE;
>>> +
>>> +   /*
>>> +* Unlike regular DrawElementsInstancedBaseVertex commands, the
>>> indices
>>> +* may not come from a client array and must come from an index
>>> buffer.
>>> +* If no element array buffer is bound, an INVALID_OPERATION error is
>>> +* generated.
>>> +*/
>>> +   if (!_mesa_is_bufferobj(ctx->Array.ArrayObj->ElementArrayBufferObj))
>>> {
>>> +  _mesa_error(ctx, G

Re: [Mesa-dev] Fwd: Bug#728053: [PATCH] mesa: FTBFS: invalid alignment assumptions

[Matt Turner]

On Wed, Nov 6, 2013 at 10:19 AM, Thorsten Glaser  wrote:
> Hi everyone,
>
> here’s a bugfix to make implicit alignment and padding
> assumptions explicit, please apply.

[sarcasm]How well does NV84 video decoding work on m68k these days
anyway?[/sarcasm]
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/11] mesa: implement GL_ARB_draw_indirect and GL_ARB_multi_draw_indirect

[Paul Berry]

On 6 November 2013 17:06, Chris Forbes  wrote:

> I'm hoping I don't need the save_ stuff at all, if I only enable this
> in core contexts. Is that OK?
>

Oh, yeah, I didn't think of that.  Yeah, that sounds reasonable to me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Dropping the xorg state tracker

[Matt Turner]

With the removal of the r600 and radeonsi xorg targets, the only ones
left are i915 and nouveau. Does anyone have a compelling reason to
keep them (and the state tracker code itself) around anymore?

Seems like VMware uses XA, which Rob might also use for freedreno.

I'd be happy to delete them tomorrow before the branch. :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Dropping the xorg state tracker

[Stéphane Marchesin]

On Wed, Nov 6, 2013 at 5:43 PM, Matt Turner  wrote:

> With the removal of the r600 and radeonsi xorg targets, the only ones
> left are i915 and nouveau. Does anyone have a compelling reason to
> keep them (and the state tracker code itself) around anymore?
>

I'm fine with removing the xorg target for i915g, I have never tested it
actually.

Stéphane


>
> Seems like VMware uses XA, which Rob might also use for freedreno.
>
> I'd be happy to delete them tomorrow before the branch. :)
> ___
> 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 2/3] i965/fs: Do instruction pre-scheduling just before register allocation.

[Eric Anholt]

Long ago, the HW_REG usage in assign_curb/urb_setup() were scheduling
barriers, so we had to run scheduler before them in order for it to be
able to do basically anything.  Now that that's fixed, we can delay the
scheduling until we go to allocate (which will make the next change less
scary).
---
 src/mesa/drivers/dri/i965/brw_fs.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index c332d4c..65fedfb 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3278,13 +3278,13 @@ fs_visitor::run()
 progress = compute_to_mrf() || progress;
   } while (progress);
 
-  schedule_instructions(false);
-
   lower_uniform_pull_constant_loads();
 
   assign_curb_setup();
   assign_urb_setup();
 
+  schedule_instructions(false);
+
   if (0)
 assign_regs_trivial();
   else {
-- 
1.8.4.rc3

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

[Mesa-dev] [PATCH 3/3] i965/fs: Try a different pre-scheduling heuristic if the first spills.

[Eric Anholt]

Since LIFO fails on some shaders in one particular way, and non-LIFO
systematically fails in another way on different kinds of shaders, try
them both. and pick whichever one successfully register allocates first.
Slightly prefer non-LIFO in case we produce extra dependencies in register
allocation, since it should start out with fewer stalls than LIFO.

This is madness, but I haven't come up with another way to get unigine
tropics to not spill while keeping other programs from not spilling and
retaining the non-unigine performance wins from texture-grf.

total instructions in shared programs: 1626728 -> 1626288 (-0.03%)
instructions in affected programs: 1015 -> 575 (-43.35%)
GAINED:50
LOST:  0
---
 src/mesa/drivers/dri/i965/brw_fs.cpp   | 25 +--
 src/mesa/drivers/dri/i965/brw_fs.h |  4 +-
 src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp  | 10 +--
 .../drivers/dri/i965/brw_schedule_instructions.cpp | 85 --
 src/mesa/drivers/dri/i965/brw_shader.h |  6 ++
 5 files changed, 76 insertions(+), 54 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 65fedfb..5d7 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3283,15 +3283,28 @@ fs_visitor::run()
   assign_curb_setup();
   assign_urb_setup();
 
-  schedule_instructions(false);
+  schedule_instructions(SCHEDULE_PRE_NON_LIFO);
 
   if (0)
 assign_regs_trivial();
   else {
-while (!assign_regs()) {
-   if (failed)
-  break;
-}
+ if (!assign_regs(false)) {
+/* Try a non-spilling register allocation again with a different
+ * scheduling heuristic.
+ */
+schedule_instructions(SCHEDULE_PRE_LIFO);
+if (!assign_regs(false)) {
+   if (dispatch_width == 16) {
+  fail("Failure to register allocate.  Reduce number of "
+   "live scalar values to avoid this.");
+   } else {
+  while (!assign_regs(true)) {
+ if (failed)
+break;
+  }
+   }
+}
+ }
   }
}
assert(force_uncompressed_stack == 0);
@@ -3306,7 +3319,7 @@ fs_visitor::run()
if (failed)
   return false;
 
-   schedule_instructions(true);
+   schedule_instructions(SCHEDULE_POST);
 
if (dispatch_width == 8) {
   c->prog_data.reg_blocks = brw_register_blocks(grf_used);
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
b/src/mesa/drivers/dri/i965/brw_fs.h
index 4f97a67..be86b15 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -291,7 +291,7 @@ public:
void assign_curb_setup();
void calculate_urb_setup();
void assign_urb_setup();
-   bool assign_regs();
+   bool assign_regs(bool allow_spilling);
void assign_regs_trivial();
void get_used_mrfs(bool *mrf_used);
void setup_payload_interference(struct ra_graph *g, int payload_reg_count,
@@ -322,7 +322,7 @@ public:
bool remove_dead_constants();
bool remove_duplicate_mrf_writes();
bool virtual_grf_interferes(int a, int b);
-   void schedule_instructions(bool post_reg_alloc);
+   void schedule_instructions(instruction_scheduler_mode mode);
void insert_gen4_send_dependency_workarounds();
void insert_gen4_pre_send_dependency_workarounds(fs_inst *inst);
void insert_gen4_post_send_dependency_workarounds(fs_inst *inst);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index d9e80d0..8567afd 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -417,7 +417,7 @@ fs_visitor::setup_mrf_hack_interference(struct ra_graph *g, 
int first_mrf_node)
 }
 
 bool
-fs_visitor::assign_regs()
+fs_visitor::assign_regs(bool allow_spilling)
 {
/* Most of this allocation was written for a reg_width of 1
 * (dispatch_width == 8).  In extending to 16-wide, the code was
@@ -496,14 +496,10 @@ fs_visitor::assign_regs()
   if (reg == -1) {
  fail("no register to spill:\n");
  dump_instructions();
-  } else if (dispatch_width == 16) {
-fail("Failure to register allocate.  Reduce number of live scalar "
-  "values to avoid this.");
-  } else {
-spill_reg(reg);
+  } else if (allow_spilling) {
+ spill_reg(reg);
   }
 
-
   ralloc_free(g);
 
   return false;
diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp 
b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
index 5710380..befea0a 100644
--- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
+++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
@@ -391,14 +39

[Mesa-dev] [PATCH 1/3] i965/fs: Ignore actual latency pre-reg-alloc.

[Eric Anholt]

We care about depth-until-program-end, as a proxy for "make sure I
schedule those early instructions that open up the other things that can
make progress while keeping register pressure low", not actual latency
(since we're relying on the post-register-alloc scheduling to actually
schedule for the hardware).

total instructions in shared programs: 1609931 -> 1609931 (0.00%)
instructions in affected programs: 0 -> 0
GAINED:55
LOST:  43
---
 .../drivers/dri/i965/brw_schedule_instructions.cpp | 50 +-
 1 file changed, 29 insertions(+), 21 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp 
b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
index 53fffa7..5710380 100644
--- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
+++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
@@ -56,29 +56,12 @@ using namespace brw;
 
 static bool debug = false;
 
+class instruction_scheduler;
+
 class schedule_node : public exec_node
 {
 public:
-   schedule_node(backend_instruction *inst, const struct brw_context *brw)
-   {
-  this->inst = inst;
-  this->child_array_size = 0;
-  this->children = NULL;
-  this->child_latency = NULL;
-  this->child_count = 0;
-  this->parent_count = 0;
-  this->unblocked_time = 0;
-  this->cand_generation = 0;
-
-  /* We can't measure Gen6 timings directly but expect them to be much
-   * closer to Gen7 than Gen4.
-   */
-  if (brw->gen >= 6)
- set_latency_gen7(brw->is_haswell);
-  else
- set_latency_gen4();
-   }
-
+   schedule_node(backend_instruction *inst, instruction_scheduler *sched);
void set_latency_gen4();
void set_latency_gen7(bool is_haswell);
 
@@ -607,10 +590,35 @@ 
vec4_instruction_scheduler::get_register_pressure_benefit(backend_instruction *b
return 0;
 }
 
+schedule_node::schedule_node(backend_instruction *inst,
+ instruction_scheduler *sched)
+{
+   struct brw_context *brw = sched->bv->brw;
+
+   this->inst = inst;
+   this->child_array_size = 0;
+   this->children = NULL;
+   this->child_latency = NULL;
+   this->child_count = 0;
+   this->parent_count = 0;
+   this->unblocked_time = 0;
+   this->cand_generation = 0;
+
+   /* We can't measure Gen6 timings directly but expect them to be much
+* closer to Gen7 than Gen4.
+*/
+   if (!sched->post_reg_alloc)
+  this->latency = 1;
+   else if (brw->gen >= 6)
+  set_latency_gen7(brw->is_haswell);
+   else
+  set_latency_gen4();
+}
+
 void
 instruction_scheduler::add_inst(backend_instruction *inst)
 {
-   schedule_node *n = new(mem_ctx) schedule_node(inst, bv->brw);
+   schedule_node *n = new(mem_ctx) schedule_node(inst, this);
 
assert(!inst->is_head_sentinel());
assert(!inst->is_tail_sentinel());
-- 
1.8.4.rc3

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

Re: [Mesa-dev] Dropping the xorg state tracker

[Jakob Bornecrantz]

On Thu, Nov 7, 2013 at 3:30 AM, Stéphane Marchesin
 wrote:
> On Wed, Nov 6, 2013 at 5:43 PM, Matt Turner  wrote:
>> With the removal of the r600 and radeonsi xorg targets, the only ones
>> left are i915 and nouveau. Does anyone have a compelling reason to
>> keep them (and the state tracker code itself) around anymore?
>
> I'm fine with removing the xorg target for i915g, I have never tested it
> actually.

Sad to see it go, but I'm okay with removing it.

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

Re: [Mesa-dev] [PATCH] Add DRM_MODE_PAGE_FLIP_ASYNC define

[Keith Packard]

Eric Anholt  writes:

> Keith Packard  writes:
>
>> This exposes the kernel API for performing asynchronous flips
>>
>> Signed-off-by: Keith Packard 
>
> Reviewed-by: Eric Anholt 

I've pushed this to master.

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


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

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

[bugzilla-daemon]

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

--- Comment #15 from James Cook  ---
I can reproduce the problem on my machine.

I'm using the tarball at
ftp://ftp.freedesktop.org/pub/mesa/${version}/MesaLib-${version}.tar.bz2 ,
where version is 9.2.2, with some distribution-specific patches and
configuration options (NixOS x-updates branch).  If you think these might be
interfering, let me know and I'll see if I can build without the changes.


Here's my output for GALLIUM_DUMP_CPU=1 ./lp_test_arit (with LD_LIBRARY_PATH
set for annoying reasons):

$
LD_LIBRARY_PATH=/tmp/nix-build-mesa-noglu-9.2.2.drv-0/Mesa-9.2.2/src/gallium/auxiliary/gallivm/.libs/lp_bld_init.o
GALLIUM_DUMP_CPU=1 ./lp_test_arit
util_cpu_caps.nr_cpus = 3
util_cpu_caps.x86_cpu_type = 9
util_cpu_caps.cacheline = 64
util_cpu_caps.has_tsc = 1
util_cpu_caps.has_mmx = 1
util_cpu_caps.has_mmx2 = 1
util_cpu_caps.has_sse = 1
util_cpu_caps.has_sse2 = 1
util_cpu_caps.has_sse3 = 1
util_cpu_caps.has_ssse3 = 0
util_cpu_caps.has_sse4_1 = 0
util_cpu_caps.has_sse4_2 = 0
util_cpu_caps.has_avx = 0
util_cpu_caps.has_3dnow = 1
util_cpu_caps.has_3dnow_ext = 1
util_cpu_caps.has_altivec = 0
floor(-0): ref = -1, out = 0, precision = -0.00 bits, FAIL
ceil(0): ref = 1, out = 0, precision = -0.00 bits, FAIL
fract(-0): ref = 0.9994, out = -0, precision = -0.00 bits, FAIL



Here's the end of the testing output, from before I ran the above command:

Testing PIPE_FORMAT_B4G4R4X4_UNORM (unorm8) ...
PASS: lp_test_format
floor(-0): ref = -1, out = 0, precision = -0.00 bits, FAIL
ceil(0): ref = 1, out = 0, precision = -0.00 bits, FAIL
fract(-0): ref = 0.9994, out = -0, precision = -0.00 bits, FAIL
FAIL: lp_test_arit
PASS: lp_test_blend
PASS: lp_test_conv
hello, world
print 5 6: 5 6
PASS: lp_test_printf

1 of 5 tests failed
Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa






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

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

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

Re: [Mesa-dev] [v2 3/6] glsl: ir_serializer class for the shader cache

[Tapani]

On 11/06/2013 10:55 PM, Paul Berry wrote:
On 5 November 2013 23:45, Tapani Pälli > wrote:


On 11/05/2013 07:36 PM, Paul Berry wrote:

On 1 November 2013 02:16, Tapani Pälli mailto:tapani.pa...@intel.com>> wrote:


+
+/**
+ * Function to create an unique string for a ir_variable.
This is
+ * used by variable dereferences to indicate the exact
ir_variable
+ * when deserialization happens.


I still don't understand why we don't just use the pointer for
this purpose.  It's unique, and it takes up much less storage
than _.


We need to construct a unique name to refer to when reading so
this is constructed here already. It could be also just a counter
like is used somewhere else (to have assignment_tmp@1,
assignment_tmp@2) but I wanted to keep this code minimal as it's
just unique naming.


I'm sorry, there's still something I'm not understanding.  Before 
serialization, the names are not unique.  So I don't see why we need 
to create unique names when reading.  The goal should be to reproduce 
the IR data structure that was saved as closely as possible.


It seems like storing the address of the ir_variable (or some other 
suitably determined unique numeric id) should be sufficient for this.  
When we serialize the ir_variable, we write out its unique numeric 
id.  When we serialize an ir_dereference_variable, we write out the 
unique numeric id of the ir_variable it refers to.  When deserializing 
an ir_variable, we store the mapping from its unique numeric id to its 
new address in memory in a hash table.  When deserializing an 
ir_dereference_variable, we look up the unique numeric id to find the 
address of the ir_variable that's already been deserialized.


It doesn't seem to me that uniqueness of names is necessary anywhere 
in that process.  What am I missing?


I think we are somewhat on the same page but the method you describe 
here is another way to solve the same problem. Problem is to get 
references to variables pointing to the exact correct variable. This 
cannot be detected by variable name, which I wanted to use for it to be 
very clear which variable we are referring to and I did not see any harm 
in using such 'unique name', ir_print_visitor does similar renaming in 
its output. I can change to use your method if renaming is no good 
(haven't seen any issues with this though), I guess using the hash 
should not affect the parsing performance, correct variable is anyway 
searched from a list when creating a reference.





+
+   for (unsigned i = 0; i < ir->num_state_slots; i++) {
+  blob.write_int32(&ir->state_slots[i].swizzle);


Swizzles are unsigned 8-bit values.  This should be write_uint8.


OK, maybe the struct could also be changed to have only 8 bits
instead of a int then.


I could get behind that change.




+   CACHE_DEBUG("write %d prototypes\n", total);

+
+   foreach_list_const(node, shader->ir) {
+  ir_instruction *const inst = (ir_instruction *) node;
+  if (inst->as_variable())
+ if (save(inst))
+goto write_errors;
+   }
+
+   foreach_list_const(node, shader->ir) {
+  ir_instruction *const inst = (ir_instruction *) node;
+  if (inst->as_function())
+ if (save(inst))
+goto write_errors;
+   }


Why is it necessary to save the variables and instructions first?


This is because during parsing we might encounter a call to a
function that does not exist yet, same goes for variable
references. Another way would be to modify the reading side so
that it makes 2 passes over the data but I took this way as
originally reader did not use mmap so it was just simpler.


Ok, I think you are correct about the functions.  But I believe for 
variables, the ir_variable always appears in the IR before any 
references to it.  Can someone confirm this? (Ken or Ian perhaps?)


This would be good to confirm. I'm pretty sure I did this to tackle a 
problem during parsing but I can't recall now  .. I will check this.


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

[Mesa-dev] [PATCH 2/3] xorg-nouveau: Delete.

[Matt Turner]

---
 configure.ac  |   3 +-
 src/gallium/targets/Makefile.am   |   4 -
 src/gallium/targets/xorg-nouveau/Makefile.am  |  68 
 src/gallium/targets/xorg-nouveau/nouveau_target.c |  20 ---
 src/gallium/targets/xorg-nouveau/nouveau_xorg.c   | 192 --
 5 files changed, 1 insertion(+), 286 deletions(-)
 delete mode 100644 src/gallium/targets/xorg-nouveau/Makefile.am
 delete mode 100644 src/gallium/targets/xorg-nouveau/nouveau_target.c
 delete mode 100644 src/gallium/targets/xorg-nouveau/nouveau_xorg.c

diff --git a/configure.ac b/configure.ac
index 17aed8c..6caa125 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1802,7 +1802,7 @@ if test "x$with_gallium_drivers" != x; then
 PKG_CHECK_MODULES([NOUVEAU], [libdrm_nouveau >= 
$LIBDRM_NOUVEAU_REQUIRED])
 gallium_require_drm_loader
 GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS nouveau"
-gallium_check_st "nouveau/drm" "dri-nouveau" "xorg-nouveau" "" 
"xvmc-nouveau" "vdpau-nouveau"
+gallium_check_st "nouveau/drm" "dri-nouveau" "" "" "xvmc-nouveau" 
"vdpau-nouveau"
 DRICOMMON_NEED_LIBDRM=yes
 ;;
 xfreedreno)
@@ -2038,7 +2038,6 @@ AC_CONFIG_FILES([Makefile
src/gallium/targets/vdpau-nouveau/Makefile
src/gallium/targets/xa-vmwgfx/Makefile
src/gallium/targets/xa-vmwgfx/xatracker.pc
-   src/gallium/targets/xorg-nouveau/Makefile
src/gallium/targets/xvmc-nouveau/Makefile
src/gallium/tests/trivial/Makefile
src/gallium/tests/unit/Makefile
diff --git a/src/gallium/targets/Makefile.am b/src/gallium/targets/Makefile.am
index 12756ee..e356020 100644
--- a/src/gallium/targets/Makefile.am
+++ b/src/gallium/targets/Makefile.am
@@ -101,10 +101,6 @@ if HAVE_DRI
 SUBDIRS += dri-nouveau
 endif
 
-if HAVE_ST_XORG
-SUBDIRS += xorg-nouveau
-endif
-
 if HAVE_ST_XVMC
 SUBDIRS += xvmc-nouveau
 endif
diff --git a/src/gallium/targets/xorg-nouveau/Makefile.am 
b/src/gallium/targets/xorg-nouveau/Makefile.am
deleted file mode 100644
index 210d4a2..000
--- a/src/gallium/targets/xorg-nouveau/Makefile.am
+++ /dev/null
@@ -1,68 +0,0 @@
-# Copyright © 2012 Intel Corporation
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice (including the next
-# paragraph) shall be included in all copies or substantial portions of the
-# Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
-# NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
-# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
-# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
-# DEALINGS IN THE SOFTWARE.
-
-include $(top_srcdir)/src/gallium/Automake.inc
-
-AM_CFLAGS = \
-   $(GALLIUM_CFLAGS) \
-   $(PTHREAD_CFLAGS) \
-   $(XORG_CFLAGS)
-AM_CPPFLAGS = \
-   -I$(top_srcdir)/src/gallium/drivers \
-   -I$(top_srcdir)/src/gallium/winsys \
-   -DHAVE_CONFIG_H \
-   -DGALLIUM_RBUG \
-   -DGALLIUM_TRACE
-
-xorgdir = $(XORG_DRIVER_INSTALL_DIR)
-xorg_LTLIBRARIES = nouveau2_drv.la
-
-nodist_EXTRA_nouveau2_drv_la_SOURCES = dummy.cpp
-nouveau2_drv_la_SOURCES = \
-   nouveau_target.c \
-   nouveau_xorg.c
-
-nouveau2_drv_la_LDFLAGS = -module -avoid-version -shared -no-undefined
-
-nouveau2_drv_la_LIBADD = \
-   $(top_builddir)/src/gallium/auxiliary/libgallium.la \
-   $(top_builddir)/src/gallium/state_trackers/xorg/libxorgtracker.la \
-   $(top_builddir)/src/gallium/winsys/nouveau/drm/libnouveaudrm.la \
-   $(top_builddir)/src/gallium/drivers/nouveau/libnouveau.la \
-   $(top_builddir)/src/gallium/drivers/trace/libtrace.la \
-   $(top_builddir)/src/gallium/drivers/rbug/librbug.la \
-   $(GALLIUM_DRI_LIB_DEPS) \
-   $(LIBDRM_XORG_LIBS) \
-   $(LIBKMS_XORG_LIBS) \
-   $(NOUVEAU_LIBS)
-
-if HAVE_MESA_LLVM
-AM_CFLAGS += $(LLVM_CFLAGS)
-nouveau2_drv_la_LDFLAGS += $(LLVM_LDFLAGS)
-nouveau2_drv_la_LIBADD += $(LLVM_LIBS)
-endif
-
-# Provide compatibility with scripts for the old Mesa build system for
-# a while by putting a link to the driver into /lib of the build tree.
-all-local: nouveau2_drv.la
-   $(MKDIR_P) $(top_builddir)/$(LIB_DIR)/gallium
-   ln -f .libs/nouveau2_drv.so 
$(top_builddir)/$(LI

[Mesa-dev] [PATCH 1/3] xorg-i915: Delete.

[Matt Turner]

Acked-by: Jakob Bornecrantz 
Acked-by: Stéphane Marchesin 
---
 configure.ac |   3 +-
 src/gallium/SConscript   |   5 -
 src/gallium/targets/Makefile.am  |   4 -
 src/gallium/targets/xorg-i915/Makefile.am|  76 --
 src/gallium/targets/xorg-i915/intel_target.c |  26 -
 src/gallium/targets/xorg-i915/intel_xorg.c   | 144 ---
 6 files changed, 1 insertion(+), 257 deletions(-)
 delete mode 100644 src/gallium/targets/xorg-i915/Makefile.am
 delete mode 100644 src/gallium/targets/xorg-i915/intel_target.c
 delete mode 100644 src/gallium/targets/xorg-i915/intel_xorg.c

diff --git a/configure.ac b/configure.ac
index 3d4da78..17aed8c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1751,7 +1751,7 @@ if test "x$with_gallium_drivers" != x; then
 GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS llvmpipe"
 fi
 GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS i915/sw"
-gallium_check_st "i915/drm" "dri-i915" "xorg-i915"
+gallium_check_st "i915/drm" "dri-i915"
 DRICOMMON_NEED_LIBDRM=yes
 ;;
 xilo)
@@ -2038,7 +2038,6 @@ AC_CONFIG_FILES([Makefile
src/gallium/targets/vdpau-nouveau/Makefile
src/gallium/targets/xa-vmwgfx/Makefile
src/gallium/targets/xa-vmwgfx/xatracker.pc
-   src/gallium/targets/xorg-i915/Makefile
src/gallium/targets/xorg-nouveau/Makefile
src/gallium/targets/xvmc-nouveau/Makefile
src/gallium/tests/trivial/Makefile
diff --git a/src/gallium/SConscript b/src/gallium/SConscript
index 9a25cca..f4f6df2 100644
--- a/src/gallium/SConscript
+++ b/src/gallium/SConscript
@@ -136,11 +136,6 @@ if not env['embedded']:
 'targets/dri-i915/SConscript',
 ])
 
-if env['xorg'] and env['drm']:
-SConscript([
-#'targets/xorg-i915/SConscript',
-])
-
 
 #
 # Unit tests & tools
diff --git a/src/gallium/targets/Makefile.am b/src/gallium/targets/Makefile.am
index 46d7ad0..12756ee 100644
--- a/src/gallium/targets/Makefile.am
+++ b/src/gallium/targets/Makefile.am
@@ -58,10 +58,6 @@ if HAVE_GALLIUM_I915
 if HAVE_DRI
 SUBDIRS += dri-i915
 endif
-
-if HAVE_ST_XORG
-SUBDIRS += xorg-i915
-endif
 endif
 
 if HAVE_GALLIUM_ILO
diff --git a/src/gallium/targets/xorg-i915/Makefile.am 
b/src/gallium/targets/xorg-i915/Makefile.am
deleted file mode 100644
index ed2ab8a..000
--- a/src/gallium/targets/xorg-i915/Makefile.am
+++ /dev/null
@@ -1,76 +0,0 @@
-# Copyright © 2012 Intel Corporation
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice (including the next
-# paragraph) shall be included in all copies or substantial portions of the
-# Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
-# NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
-# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
-# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
-# DEALINGS IN THE SOFTWARE.
-
-include $(top_srcdir)/src/gallium/Automake.inc
-
-AM_CFLAGS = \
-   $(GALLIUM_CFLAGS) \
-   $(PTHREAD_CFLAGS) \
-   $(XORG_CFLAGS)
-AM_CPPFLAGS = \
-   -I$(top_srcdir)/src/gallium/drivers \
-   -I$(top_srcdir)/src/gallium/winsys \
-   -DHAVE_CONFIG_H \
-   -DGALLIUM_RBUG \
-   -DGALLIUM_TRACE \
-   -DGALLIUM_GALAHAD
-
-xorgdir = $(XORG_DRIVER_INSTALL_DIR)
-xorg_LTLIBRARIES = i915_drv.la
-
-i915_drv_la_SOURCES = \
-   intel_target.c \
-   intel_xorg.c
-
-i915_drv_la_LDFLAGS = -module -avoid-version -shared -no-undefined
-
-i915_drv_la_LIBADD = \
-   $(top_builddir)/src/gallium/auxiliary/libgallium.la \
-   $(top_builddir)/src/gallium/state_trackers/xorg/libxorgtracker.la \
-   $(top_builddir)/src/gallium/winsys/i915/drm/libi915drm.la \
-   $(top_builddir)/src/gallium/drivers/i915/libi915.la \
-   $(top_builddir)/src/gallium/drivers/galahad/libgalahad.la \
-   $(top_builddir)/src/gallium/drivers/trace/libtrace.la \
-   $(top_builddir)/src/gallium/drivers/rbug/librbug.la \
-   $(GALLIUM_DRI_LIB_DEPS) \
-   $(LIBDRM_XORG_LIBS) \
-   $(LIBKMS_XORG_LIBS) \
-   $(INTEL_LIBS)
-
-if HAVE_MESA_LLVM
-i915_drv_la_LINK = $(CXXLINK) $(i915_drv_la_LD

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

[Matt Turner]

---
Deleted files diff removed.

 configure.ac |   56 +-
 src/gallium/SConscript   |3 -
 src/gallium/state_trackers/Makefile.am   |4 -
 src/gallium/state_trackers/xorg/Makefile.am  |   43 -
 src/gallium/state_trackers/xorg/Makefile.sources |   11 -
 src/gallium/state_trackers/xorg/SConscript   |   29 -
 src/gallium/state_trackers/xorg/compat-api.h |   99 --
 src/gallium/state_trackers/xorg/xorg_composite.c |  585 --
 src/gallium/state_trackers/xorg/xorg_composite.h |   36 -
 src/gallium/state_trackers/xorg/xorg_crtc.c  |  448 
 src/gallium/state_trackers/xorg/xorg_dri2.c  |  473 
 src/gallium/state_trackers/xorg/xorg_driver.c| 1323 --
 src/gallium/state_trackers/xorg/xorg_exa.c   | 1087 --
 src/gallium/state_trackers/xorg/xorg_exa.h   |   76 --
 src/gallium/state_trackers/xorg/xorg_exa_tgsi.c  |  690 ---
 src/gallium/state_trackers/xorg/xorg_exa_tgsi.h  |   59 -
 src/gallium/state_trackers/xorg/xorg_output.c|  331 --
 src/gallium/state_trackers/xorg/xorg_renderer.c  |  547 -
 src/gallium/state_trackers/xorg/xorg_renderer.h  |   81 --
 src/gallium/state_trackers/xorg/xorg_tracker.h   |  236 
 src/gallium/state_trackers/xorg/xorg_winsys.h|   50 -
 src/gallium/state_trackers/xorg/xorg_xv.c|  750 
 src/gallium/state_trackers/xorg/xorg_xvmc.c  |  119 --
 23 files changed, 11 insertions(+), 7125 deletions(-)
 delete mode 100644 src/gallium/state_trackers/xorg/Makefile.am
 delete mode 100644 src/gallium/state_trackers/xorg/Makefile.sources
 delete mode 100644 src/gallium/state_trackers/xorg/SConscript
 delete mode 100644 src/gallium/state_trackers/xorg/compat-api.h
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_composite.c
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_composite.h
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_crtc.c
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_dri2.c
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_driver.c
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_exa.c
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_exa.h
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_exa_tgsi.c
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_exa_tgsi.h
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_output.c
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_renderer.c
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_renderer.h
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_tracker.h
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_winsys.h
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_xv.c
 delete mode 100644 src/gallium/state_trackers/xorg/xorg_xvmc.c

diff --git a/configure.ac b/configure.ac
index 6caa125..28faf24 100644
--- a/configure.ac
+++ b/configure.ac
@@ -35,8 +35,6 @@ LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
 LIBDRM_FREEDRENO_REQUIRED=2.4.39
 DRI2PROTO_REQUIRED=2.6
 GLPROTO_REQUIRED=1.4.14
-LIBDRM_XORG_REQUIRED=2.4.24
-LIBKMS_XORG_REQUIRED=1.0.0
 
 dnl Check for progs
 AC_PROG_CPP
@@ -556,11 +554,6 @@ AC_ARG_ENABLE([egl],
 [enable_egl="$enableval"],
 [enable_egl=yes])
 
-AC_ARG_ENABLE([xorg],
-[AS_HELP_STRING([--enable-xorg],
-[enable support for X.Org DDX API @<:@default=no@:>@])],
-[enable_xorg="$enableval"],
-[enable_xorg=no])
 AC_ARG_ENABLE([xa],
 [AS_HELP_STRING([--enable-xa],
 [enable build of the XA X Acceleration API @<:@default=no@:>@])],
@@ -651,7 +644,6 @@ if test "x$enable_opengl" = xno -a \
 "x$enable_gles1" = xno -a \
 "x$enable_gles2" = xno -a \
 "x$enable_openvg" = xno -a \
-"x$enable_xorg" = xno -a \
 "x$enable_xa" = xno -a \
 "x$enable_xvmc" = xno -a \
 "x$enable_vdpau" = xno -a \
@@ -1236,20 +1228,6 @@ fi
 AM_CONDITIONAL(HAVE_GALLIUM_GBM, test "x$enable_gallium_gbm" = xyes)
 
 dnl
-dnl X.Org DDX configuration
-dnl
-if test "x$enable_xorg" = xyes; then
-PKG_CHECK_MODULES([XORG], [xorg-server >= 1.6.0])
-PKG_CHECK_MODULES([LIBDRM_XORG], [libdrm >= $LIBDRM_XORG_REQUIRED])
-PKG_CHECK_MODULES([LIBKMS_XORG], [libkms >= $LIBKMS_XORG_REQUIRED])
-PKG_CHECK_MODULES(XEXT, [xextproto >= 7.0.99.1],
-HAVE_XEXTPROTO_71="yes"; DEFINES="$DEFINES -DHAVE_XEXTPROTO_71",
-HAVE_XEXTPROTO_71="no")
-GALLIUM_STATE_TRACKERS_DIRS="xorg $GALLIUM_STATE_TRACKERS_DIRS"
-fi
-AM_CONDITIONAL(HAVE_ST_XORG, test "x$enable_xorg" = xyes)
-
-dnl
 dnl XA configuration
 dnl
 if test "x$enable_xa" = xyes; then
@@ -1487,13 +1465,6 @@ AC_ARG_WITH([egl-driver-dir],
 [EGL_DRIVER_INSTALL_DIR='${libdir}/egl'])
 AC_SUBST([EGL_DRIVER_INSTALL_DIR])
 
-AC_ARG_WITH([xorg-driver-dir],
-[AS_HELP_STRING([--with-xorg-driver-dir=DIR],
-[Default xorg driver 
directory[[default=${libdir}/xorg/modules/drivers]]]

[Mesa-dev] [PATCH V2 00/15] ARB_draw_indirect for i965

[Chris Forbes]

This series adds ARB_draw_indirect and ARB_multi_draw_indirect for i965 Gen7+.

Big changes from V1:

- Split up the old 2/11 into some more sensible pieces
- Discarded all the unused dlist stuff; this was a carryover from when draws
  were handled by the vtxfmt vtable rather than in the main dispatch table.
- Fixed the various clarity issues from the first round of review.

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

[Mesa-dev] [PATCH V2 01/15] mesa: add indirect drawing buffer parameter to draw functions

[Chris Forbes]

From: Christoph Bumiller 

Split from patch implementing ARB_draw_indirect.

v2: Const-qualify the struct gl_buffer_object *indirect argument.
v3: Fix up some more draw calls for new argument.
v4: Fix up rebase conflicts in i965.
---
 src/mesa/drivers/dri/i965/brw_draw.c  |  3 ++-
 src/mesa/drivers/dri/i965/brw_draw.h  |  3 ++-
 src/mesa/drivers/dri/i965/brw_primitive_restart.c |  2 +-
 src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c  | 13 -
 src/mesa/state_tracker/st_cb_rasterpos.c  |  2 +-
 src/mesa/state_tracker/st_draw.c  |  3 ++-
 src/mesa/state_tracker/st_draw.h  |  6 --
 src/mesa/state_tracker/st_draw_feedback.c |  3 ++-
 src/mesa/tnl/t_draw.c |  3 ++-
 src/mesa/tnl/tnl.h|  3 ++-
 src/mesa/vbo/vbo.h|  5 -
 src/mesa/vbo/vbo_exec_array.c |  8 
 src/mesa/vbo/vbo_exec_draw.c  |  2 +-
 src/mesa/vbo/vbo_primitive_restart.c  |  4 ++--
 src/mesa/vbo/vbo_rebase.c |  2 +-
 src/mesa/vbo/vbo_save_draw.c  |  2 +-
 src/mesa/vbo/vbo_split_copy.c |  2 +-
 src/mesa/vbo/vbo_split_inplace.c  |  2 +-
 18 files changed, 41 insertions(+), 27 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 7b33b76..e6c3508 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -463,7 +463,8 @@ void brw_draw_prims( struct gl_context *ctx,
 GLboolean index_bounds_valid,
 GLuint min_index,
 GLuint max_index,
-struct gl_transform_feedback_object *unused_tfb_object)
+struct gl_transform_feedback_object *unused_tfb_object,
+const struct gl_buffer_object *indirect )
 {
struct brw_context *brw = brw_context(ctx);
const struct gl_client_array **arrays = ctx->Array._DrawArrays;
diff --git a/src/mesa/drivers/dri/i965/brw_draw.h 
b/src/mesa/drivers/dri/i965/brw_draw.h
index fb96813..87fcf09 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.h
+++ b/src/mesa/drivers/dri/i965/brw_draw.h
@@ -41,7 +41,8 @@ void brw_draw_prims( struct gl_context *ctx,
 GLboolean index_bounds_valid,
 GLuint min_index,
 GLuint max_index,
-struct gl_transform_feedback_object *unused_tfb_object);
+struct gl_transform_feedback_object *unused_tfb_object,
+const struct gl_buffer_object *indirect );
 
 void brw_draw_init( struct brw_context *brw );
 void brw_draw_destroy( struct brw_context *brw );
diff --git a/src/mesa/drivers/dri/i965/brw_primitive_restart.c 
b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
index 2ee6055..a131151 100644
--- a/src/mesa/drivers/dri/i965/brw_primitive_restart.c
+++ b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
@@ -169,7 +169,7 @@ brw_handle_primitive_restart(struct gl_context *ctx,
   /* Cut index should work for primitive restart, so use it
*/
   brw->prim_restart.enable_cut_index = true;
-  brw_draw_prims(ctx, prims, nr_prims, ib, GL_FALSE, -1, -1, NULL);
+  brw_draw_prims(ctx, prims, nr_prims, ib, GL_FALSE, -1, -1, NULL, NULL);
   brw->prim_restart.enable_cut_index = false;
} else {
   /* Not all the primitive draw modes are supported by the cut index,
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c 
b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
index 436db32..e76ae34 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c
@@ -222,7 +222,8 @@ TAG(vbo_render_prims)(struct gl_context *ctx,
  const struct _mesa_index_buffer *ib,
  GLboolean index_bounds_valid,
  GLuint min_index, GLuint max_index,
- struct gl_transform_feedback_object *tfb_vertcount);
+ struct gl_transform_feedback_object *tfb_vertcount,
+ const struct gl_buffer_object *indirect);
 
 static GLboolean
 vbo_maybe_split(struct gl_context *ctx, const struct gl_client_array **arrays,
@@ -453,7 +454,8 @@ TAG(vbo_render_prims)(struct gl_context *ctx,
  const struct _mesa_index_buffer *ib,
  GLboolean index_bounds_valid,
  GLuint min_index, GLuint max_index,
- struct gl_transform_feedback_object *tfb_vertcount)
+ struct gl_transform_feedback_object *tfb_vertcount,
+ const struct gl_buffer_object *indirect)
 {
struct nouveau_render_state *render = to_render_state(ctx);
const struct gl_client_array **arrays = ctx->Array._DrawArrays;
@@ -489,7 +491,8 @@ TAG(vbo_check_render

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

[Chris Forbes]

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

diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index e6c3508..9f8ad45 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -323,7 +323,8 @@ static bool brw_try_draw_prims( struct gl_context *ctx,
 GLuint nr_prims,
 const struct _mesa_index_buffer *ib,
 GLuint min_index,
-GLuint max_index )
+GLuint max_index,
+const struct gl_buffer_object *indirect)
 {
struct brw_context *brw = brw_context(ctx);
bool retval = true;
@@ -377,6 +378,9 @@ static bool brw_try_draw_prims( struct gl_context *ctx,
brw->vb.max_index = max_index;
brw->state.dirty.brw |= BRW_NEW_VERTICES;
 
+   brw->indirect_buffer.indb = indirect;
+   brw->state.dirty.brw |= BRW_NEW_INDIRECT_BUFFER;
+
for (i = 0; i < nr_prims; i++) {
   int estimated_max_prim_size;
 
@@ -506,7 +510,7 @@ void brw_draw_prims( struct gl_context *ctx,
 * manage it.  swrast doesn't support our featureset, so we can't fall back
 * to it.
 */
-   brw_try_draw_prims(ctx, arrays, prims, nr_prims, ib, min_index, max_index);
+   brw_try_draw_prims(ctx, arrays, prims, nr_prims, ib, min_index, max_index, 
indirect);
 }
 
 void brw_draw_init( struct brw_context *brw )
-- 
1.8.4.2

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

[Mesa-dev] [PATCH V2 07/15] mesa: add is_indirect to _mesa_prim

[Chris Forbes]

Signed-off-by: Chris Forbes 
---
 src/mesa/vbo/vbo.h| 3 ++-
 src/mesa/vbo/vbo_exec_array.c | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/mesa/vbo/vbo.h b/src/mesa/vbo/vbo.h
index 113374a..942b34a 100644
--- a/src/mesa/vbo/vbo.h
+++ b/src/mesa/vbo/vbo.h
@@ -46,7 +46,8 @@ struct _mesa_prim {
GLuint end:1;
GLuint weak:1;
GLuint no_current_update:1;
-   GLuint pad:19;
+   GLuint is_indirect:1;
+   GLuint pad:18;
 
GLuint start;
GLuint count;
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 7aa0ad2..40c435d 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -965,6 +965,7 @@ vbo_validated_drawrangeelements(struct gl_context *ctx, 
GLenum mode,
prim[0].start = 0;
prim[0].count = count;
prim[0].indexed = 1;
+   prim[0].is_indirect = 0;
prim[0].basevertex = basevertex;
prim[0].num_instances = numInstances;
prim[0].base_instance = baseInstance;
@@ -1578,6 +1579,7 @@ vbo_validated_drawarraysindirect(struct gl_context *ctx,
prim[0].begin = 1;
prim[0].end = 1;
prim[0].mode = mode;
+   prim[0].is_indirect = 1;
prim[0].indirect_offset = (GLsizeiptr)indirect;
 
/* NOTE: We do NOT want to handle primitive restart here, nor perform any
@@ -1623,6 +1625,7 @@ vbo_validated_multidrawarraysindirect(struct gl_context 
*ctx,
for (i = 0; i < primcount; ++i, offset += stride) {
   prim[i].mode = mode;
   prim[i].indirect_offset = offset;
+  prim[i].is_indirect = 1;
}
 
check_buffers_are_unmapped(exec->array.inputs);
@@ -1660,6 +1663,7 @@ vbo_validated_drawelementsindirect(struct gl_context *ctx,
prim[0].mode = mode;
prim[0].indexed = 1;
prim[0].indirect_offset = (GLsizeiptr)indirect;
+   prim[0].is_indirect = 1;
 
check_buffers_are_unmapped(exec->array.inputs);
vbo->draw_prims(ctx, prim, 1,
@@ -1708,6 +1712,7 @@ vbo_validated_multidrawelementsindirect(struct gl_context 
*ctx,
   prim[i].mode = mode;
   prim[i].indexed = 1;
   prim[i].indirect_offset = offset;
+  prim[i].is_indirect = 1;
}
 
check_buffers_are_unmapped(exec->array.inputs);
-- 
1.8.4.2

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

[Mesa-dev] [PATCH V2 06/15] vbo: Flesh out implementation of indirect draws

[Chris Forbes]

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

Signed-off-by: Chris Forbes 
---
 src/mesa/vbo/vbo_exec_array.c | 216 ++
 1 file changed, 216 insertions(+)

diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 3f977fc..7aa0ad2 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -1564,6 +1564,164 @@ vbo_exec_DrawTransformFeedbackStreamInstanced(GLenum 
mode, GLuint name,
vbo_draw_transform_feedback(ctx, mode, obj, stream, primcount);
 }
 
+static void
+vbo_validated_drawarraysindirect(struct gl_context *ctx,
+ GLenum mode, const GLvoid *indirect)
+{
+   struct vbo_context *vbo = vbo_context(ctx);
+   struct vbo_exec_context *exec = &vbo->exec;
+   struct _mesa_prim prim[1];
+
+   vbo_bind_arrays(ctx);
+
+   memset(prim, 0, sizeof(prim));
+   prim[0].begin = 1;
+   prim[0].end = 1;
+   prim[0].mode = mode;
+   prim[0].indirect_offset = (GLsizeiptr)indirect;
+
+   /* NOTE: We do NOT want to handle primitive restart here, nor perform any
+* other checks that require knowledge of the values in the command buffer.
+* That would deafeat the whole purpose of this function.
+*/
+
+   check_buffers_are_unmapped(exec->array.inputs);
+   vbo->draw_prims(ctx, prim, 1,
+   NULL, GL_TRUE, 0, ~0,
+   NULL,
+   ctx->DrawIndirectBuffer);
+
+   if (MESA_DEBUG_FLAGS & DEBUG_ALWAYS_FLUSH)
+  _mesa_flush(ctx);
+}
+
+static void
+vbo_validated_multidrawarraysindirect(struct gl_context *ctx,
+  GLenum mode,
+  const GLvoid *indirect,
+  GLsizei primcount, GLsizei stride)
+{
+   struct vbo_context *vbo = vbo_context(ctx);
+   struct vbo_exec_context *exec = &vbo->exec;
+   struct _mesa_prim *prim;
+   GLsizei i;
+   GLsizeiptr offset = (GLsizeiptr)indirect;
+
+   if (primcount == 0)
+  return;
+   prim = calloc(1, primcount * sizeof(*prim));
+   if (prim == NULL) {
+  _mesa_error(ctx, GL_OUT_OF_MEMORY, "glMultiDrawArraysIndirect");
+  return;
+   }
+
+   vbo_bind_arrays(ctx);
+
+   memset(prim, 0, primcount * sizeof(*prim));
+   prim[0].begin = 1;
+   prim[primcount - 1].end = 1;
+   for (i = 0; i < primcount; ++i, offset += stride) {
+  prim[i].mode = mode;
+  prim[i].indirect_offset = offset;
+   }
+
+   check_buffers_are_unmapped(exec->array.inputs);
+   vbo->draw_prims(ctx, prim, primcount,
+   NULL, GL_TRUE, 0, ~0,
+   NULL,
+   ctx->DrawIndirectBuffer);
+
+   free(prim);
+
+   if (MESA_DEBUG_FLAGS & DEBUG_ALWAYS_FLUSH)
+  _mesa_flush(ctx);
+}
+
+static void
+vbo_validated_drawelementsindirect(struct gl_context *ctx,
+   GLenum mode, GLenum type,
+   const GLvoid *indirect)
+{
+   struct vbo_context *vbo = vbo_context(ctx);
+   struct vbo_exec_context *exec = &vbo->exec;
+   struct _mesa_index_buffer ib;
+   struct _mesa_prim prim[1];
+
+   vbo_bind_arrays(ctx);
+
+   ib.count = 0; /* unknown */
+   ib.type = type;
+   ib.obj = ctx->Array.ArrayObj->ElementArrayBufferObj;
+   ib.ptr = NULL;
+
+   memset(prim, 0, sizeof(prim));
+   prim[0].begin = 1;
+   prim[0].end = 1;
+   prim[0].mode = mode;
+   prim[0].indexed = 1;
+   prim[0].indirect_offset = (GLsizeiptr)indirect;
+
+   check_buffers_are_unmapped(exec->array.inputs);
+   vbo->draw_prims(ctx, prim, 1,
+   &ib, GL_TRUE, 0, ~0,
+   NULL,
+   ctx->DrawIndirectBuffer);
+
+   if (MESA_DEBUG_FLAGS & DEBUG_ALWAYS_FLUSH)
+  _mesa_flush(ctx);
+}
+
+static void
+vbo_validated_multidrawelementsindirect(struct gl_context *ctx,
+GLenum mode, GLenum type,
+const GLvoid *indirect,
+GLsizei primcount, GLsizei stride)
+{
+   struct vbo_context *vbo = vbo_context(ctx);
+   struct vbo_exec_context *exec = &vbo->exec;
+   struct _mesa_index_buffer ib;
+   struct _mesa_prim *prim;
+   GLsizei i;
+   GLsizeiptr offset = (GLsizeiptr)indirect;
+
+   if (primcount == 0)
+  return;
+   prim = calloc(1, primcount * sizeof(*prim));
+   if (prim == NULL) {
+  _mesa_error(ctx, GL_OUT_OF_MEMORY, "glMultiDrawElementsIndirect");
+  return;
+   }
+
+   vbo_bind_arrays(ctx);
+
+   /* NOTE: ElementArrayBufferObj is guaranteed to be a VBO. */
+
+   ib.count = 0; /* unknown */
+   ib.type = type;
+   ib.obj = ctx->Array.ArrayObj->ElementArrayBufferObj;
+   ib.ptr = NULL;
+
+   memset(prim, 0, primcount * sizeof(*prim));
+   prim[0].begin = 1;
+   prim[primcount - 1].end = 1;
+   for (i = 0; i < primcount; ++i, offset += stride) {
+  prim[i].mode = mode;
+  prim[i].indexed = 1;
+  prim[i].indirect_offset = offset;
+   }
+
+   check_buffers_are_unmapped(exec

[Mesa-dev] [PATCH V2 02/15] glapi: add plumbing for GL_ARB_draw_indirect and GL_ARB_multi_draw_indirect

[Chris Forbes]

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

Signed-off-by: Chris Forbes 
---
 src/mapi/glapi/gen/ARB_draw_indirect.xml | 45 
 src/mapi/glapi/gen/Makefile.am   |  1 +
 src/mapi/glapi/gen/gl_API.xml|  4 ++-
 src/mesa/main/tests/dispatch_sanity.cpp  |  8 +++---
 src/mesa/vbo/vbo_exec_array.c| 32 +++
 5 files changed, 85 insertions(+), 5 deletions(-)
 create mode 100644 src/mapi/glapi/gen/ARB_draw_indirect.xml

diff --git a/src/mapi/glapi/gen/ARB_draw_indirect.xml 
b/src/mapi/glapi/gen/ARB_draw_indirect.xml
new file mode 100644
index 000..7de03cd
--- /dev/null
+++ b/src/mapi/glapi/gen/ARB_draw_indirect.xml
@@ -0,0 +1,45 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/mapi/glapi/gen/Makefile.am b/src/mapi/glapi/gen/Makefile.am
index cbbf659..0c67513 100644
--- a/src/mapi/glapi/gen/Makefile.am
+++ b/src/mapi/glapi/gen/Makefile.am
@@ -98,6 +98,7 @@ API_XML = \
ARB_draw_buffers.xml \
ARB_draw_buffers_blend.xml \
ARB_draw_elements_base_vertex.xml \
+   ARB_draw_indirect.xml \
ARB_draw_instanced.xml \
ARB_ES2_compatibility.xml \
ARB_ES3_compatibility.xml \
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index 69014c5..7cab5ba 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -8241,6 +8241,8 @@
 
 
 
+http://www.w3.org/2001/XInclude"/>
+
 
   
   
@@ -8466,7 +8468,7 @@
 
 http://www.w3.org/2001/XInclude"/>
 
-
+
 
 http://www.w3.org/2001/XInclude"/>
 
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
b/src/mesa/main/tests/dispatch_sanity.cpp
index 58cff9b..e7fbcc5 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -667,8 +667,8 @@ const struct function gl_core_functions_possible[] = {
{ "glVertexAttribP3uiv", 43, -1 },
{ "glVertexAttribP4ui", 43, -1 },
{ "glVertexAttribP4uiv", 43, -1 },
-// { "glDrawArraysIndirect", 43, -1 },  // XXX: Add to xml
-// { "glDrawElementsIndirect", 43, -1 },// XXX: Add to xml
+   { "glDrawArraysIndirect", 43, -1 },
+   { "glDrawElementsIndirect", 43, -1 },
 // { "glUniform1d", 43, -1 },   // XXX: Add to xml
 // { "glUniform2d", 43, -1 },   // XXX: Add to xml
 // { "glUniform3d", 43, -1 },   // XXX: Add to xml
@@ -877,8 +877,8 @@ const struct function gl_core_functions_possible[] = {
{ "glInvalidateBufferData", 43, -1 },
{ "glInvalidateFramebuffer", 43, -1 },
{ "glInvalidateSubFramebuffer", 43, -1 },
-// { "glMultiDrawArraysIndirect", 43, -1 }, // XXX: Add to xml
-// { "glMultiDrawElementsIndirect", 43, -1 },   // XXX: Add to xml
+   { "glMultiDrawArraysIndirect", 43, -1 },
+   { "glMultiDrawElementsIndirect", 43, -1 },
 // { "glGetProgramInterfaceiv", 43, -1 },   // XXX: Add to xml
 // { "glGetProgramResourceIndex", 43, -1 }, // XXX: Add to xml
 // { "glGetProgramResourceName", 43, -1 },  // XXX: Add to xml
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 5e1f80c..3f977fc 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -1564,6 +1564,34 @@ vbo_exec_DrawTransformFeedbackStreamInstanced(GLenum 
mode, GLuint name,
vbo_draw_transform_feedback(ctx, mode, obj, stream, primcount);
 }
 
+/**
+ * Like [Multi]DrawArrays/Elements, but they take most arguments from
+ * a buffer object.
+ */
+static void GLAPIENTRY
+vbo_exec_DrawArraysIndirect(GLenum mode, const GLvoid *indirect)
+{
+}
+
+static void GLAPIENTRY
+vbo_exec_DrawElementsIndirect(GLenum mode, GLenum type,
+  const GLvoid *indirect)
+{
+}
+
+static void GLAPIENTRY
+vbo_exec_MultiDrawArraysIndirect(GLenum mode,
+ const GLvoid *indirect,
+ GLsizei primcount, GLsizei stride)
+{
+}
+
+static void GLAPIENTRY
+vbo_exec_MultiDrawElementsIndirect(GLenum mode, GLenum type,
+   const GLvoid *indirect,
+   GLsizei primcount, GLsizei stride)
+{
+}
 
 /**
  * Initialize the dispatch table with the VBO functions for drawing.
@@ -1595,6 +1623,10 @@ vbo_initialize_exec_dispatch(const struct gl_context 
*ctx,
   SET_DrawElementsInstancedBaseInstance(exec, 
vbo_exec_DrawElementsInstancedBaseInstance);
   SET_DrawElementsInstancedBaseVertex(exec, 
vbo_exec_DrawElementsInstancedBaseVertex);
   SET_DrawElementsInstancedBaseVertexBaseInstance(exec, 
vbo_exec_DrawElementsInstancedBaseVertexBaseInstance);
+  SET_DrawArraysIndirect(exec, vbo_exec_DrawArraysI