Re: [Mesa-dev] [PATCH] glsl: Don't convert reductions of ivec to a dot-product

2014-06-25 Thread Christoph Brill
Reviewed-by: Christoph Brill egore...@gmail.com
Am 25.06.2014 04:15 schrieb Ian Romanick i...@freedesktop.org:

 From: Ian Romanick ian.d.roman...@intel.com

 Mesa has an optimization that converts expressions like v.x + v.y + v.z
 + v.w into dot(v, 1.0).  And therein lies the rub: the other operand to
 the dot-product is always a float... even if the vector is an ivec or
 uvec.  This results in an assertion failure in ir_builder.

 If the base type of the operand is not float, don't try the
 optimization.  Dot-product is not valid on integer data.

 Fixes piglit vs-integer-reduction.shader_test and OpenGL ES conformance
 test ES2-CTS.gtf.GL2Tests.glGetUniform.glGetUniform.

 Signed-off-by: Ian Romanick ian.d.roman...@intel.com
 Cc: Matt Turner matts...@gmail.com
 ---
  src/glsl/opt_algebraic.cpp | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
 index 448af6b..ac7514a 100644
 --- a/src/glsl/opt_algebraic.cpp
 +++ b/src/glsl/opt_algebraic.cpp
 @@ -124,7 +124,9 @@ static ir_expression *
  try_replace_with_dot(ir_expression *expr0, ir_expression *expr1, void
 *mem_ctx)
  {
 if (expr0  expr0-operation == ir_binop_add 
 -   expr1  expr1-operation == ir_binop_add) {
 +   expr0-type-is_float() 
 +   expr1  expr1-operation == ir_binop_add 
 +   expr1-type-is_float()) {
ir_swizzle *x = expr0-operands[0]-as_swizzle();
ir_swizzle *y = expr0-operands[1]-as_swizzle();
ir_swizzle *z = expr1-operands[0]-as_swizzle();
 --
 1.8.1.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 2/3] ra: Create a reg_belongs_to_class() helper function.

2014-03-18 Thread Christoph Brill
It's a bit picky as compilers are likely to detect this themselves, but an
'inline' might be nice.

Nonetheless I'm in favor for everything that improves code readability, so:

Reviewed-By: Christoph Brill egore...@gmail.com

Am 17.03.2014 21:32 schrieb Kenneth Graunke kenn...@whitecape.org:

 This is a little easier to read.

 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 ---
  src/mesa/program/register_allocate.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

 diff --git a/src/mesa/program/register_allocate.c
b/src/mesa/program/register_allocate.c
 index edde730..c763b96 100644
 --- a/src/mesa/program/register_allocate.c
 +++ b/src/mesa/program/register_allocate.c
 @@ -284,6 +284,15 @@ ra_class_add_reg(struct ra_regs *regs, unsigned int
c, unsigned int r)
  }

  /**
 + * Returns true if the register belongs to the given class.
 + */
 +static bool
 +reg_belongs_to_class(unsigned int r, struct ra_class *c)
 +{
 +   return c-regs[r];
 +}
 +
 +/**
   * Must be called after all conflicts and register classes have been
   * set up and before the register set is used for allocation.
   * To avoid costly q value computation, use the q_values paramater
 @@ -319,7 +328,7 @@ ra_set_finalize(struct ra_regs *regs, unsigned int
**q_values)
 int conflicts = 0;
 int i;

 -   if (!regs-classes[c]-regs[rc])
 +if (!reg_belongs_to_class(rc, regs-classes[c]))
continue;

 for (i = 0; i  regs-regs[rc].num_conflicts; i++) {
 @@ -479,7 +488,7 @@ ra_select(struct ra_graph *g)
 */
for (ri = 0; ri  g-regs-count; ri++) {
   r = (start_search_reg + ri) % g-regs-count;
 -if (!c-regs[r])
 + if (!reg_belongs_to_class(r, c))
 continue;

  /* Check if any of our neighbors conflict with this register
choice. */
 --
 1.9.0

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

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


Re: [Mesa-dev] [PATCH 1/9] gallivm: add a lp_build_intrinsic_map_trinary() function

2014-01-05 Thread Christoph Brill
Am 05.01.2014 00:42 schrieb Maxence Le Doré maxence.led...@gmail.com:

 From: Maxence Le Doré Maxence Le Doré

It appears that something in your bit setup might be wrong. Normally you
should have your mail address in between  and not your name. You might
want run something like 'git config user.email maxence.led...@gmail.com'.

 ---
  src/gallium/auxiliary/gallivm/lp_bld_intr.c | 16 
  src/gallium/auxiliary/gallivm/lp_bld_intr.h |  9 +
  2 files changed, 25 insertions(+)

 diff --git a/src/gallium/auxiliary/gallivm/lp_bld_intr.c
b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
 index 2bf1211..d501be1 100644
 --- a/src/gallium/auxiliary/gallivm/lp_bld_intr.c
 +++ b/src/gallium/auxiliary/gallivm/lp_bld_intr.c
 @@ -276,3 +276,19 @@ lp_build_intrinsic_map_binary(struct gallivm_state
*gallivm,
  }


 +LLVMValueRef
 +lp_build_intrinsic_map_trinary(struct gallivm_state *gallivm,
 +   const char *name,
 +   LLVMTypeRef ret_type,
 +   LLVMValueRef a,
 +   LLVMValueRef b,
 +   LLVMValueRef c)
 +{
 +   LLVMValueRef args[3];
 +
 +   args[0] = a;
 +   args[1] = b;
 +   args[2] = c;
 +
 +   return lp_build_intrinsic_map(gallivm, name, ret_type, args, 3);
 +}
 diff --git a/src/gallium/auxiliary/gallivm/lp_bld_intr.h
b/src/gallium/auxiliary/gallivm/lp_bld_intr.h
 index 38c5c29..c9f911c 100644
 --- a/src/gallium/auxiliary/gallivm/lp_bld_intr.h
 +++ b/src/gallium/auxiliary/gallivm/lp_bld_intr.h
 @@ -109,4 +109,13 @@ lp_build_intrinsic_map_binary(struct gallivm_state
*gallivm,
LLVMValueRef b);


 +LLVMValueRef
 +lp_build_intrinsic_map_trinary(struct gallivm_state *gallivm,
 +   const char *name,
 +   LLVMTypeRef ret_type,
 +   LLVMValueRef a,
 +   LLVMValueRef b,
 +   LLVMValueRef c);
 +
 +
  #endif /* !LP_BLD_INTR_H */
 --
 1.8.5.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 01/10] radeon: move some functions to r600_buffer.c

2013-11-29 Thread Christoph Brill
Reviewed-by: Christoph Brill egore...@gmail.com


2013/11/29 Marek Olšák mar...@gmail.com

 From: Marek Olšák marek.ol...@amd.com

 ---
  src/gallium/drivers/radeon/Makefile.sources   |   1 +
  src/gallium/drivers/radeon/r600_buffer.c  | 133
 ++
  src/gallium/drivers/radeon/r600_pipe_common.c | 106 
  3 files changed, 134 insertions(+), 106 deletions(-)
  create mode 100644 src/gallium/drivers/radeon/r600_buffer.c

 diff --git a/src/gallium/drivers/radeon/Makefile.sources
 b/src/gallium/drivers/radeon/Makefile.sources
 index 894f22a..bd06ed8 100644
 --- a/src/gallium/drivers/radeon/Makefile.sources
 +++ b/src/gallium/drivers/radeon/Makefile.sources
 @@ -1,4 +1,5 @@
  C_SOURCES := \
 +   r600_buffer.c \
 r600_pipe_common.c \
 r600_streamout.c \
  r600_texture.c \
 diff --git a/src/gallium/drivers/radeon/r600_buffer.c
 b/src/gallium/drivers/radeon/r600_buffer.c
 new file mode 100644
 index 000..13d11bd
 --- /dev/null
 +++ b/src/gallium/drivers/radeon/r600_buffer.c
 @@ -0,0 +1,133 @@
 +/*
 + * Copyright 2013 Advanced Micro Devices, Inc.
 + *
 + * Permission is hereby granted, free of charge, to any person obtaining a
 + * copy of this software and associated documentation files (the
 Software),
 + * to deal in the Software without restriction, including without
 limitation
 + * on the rights to use, copy, modify, merge, publish, distribute, sub
 + * license, and/or sell copies of the Software, and to permit persons to
 whom
 + * the Software is furnished to do so, subject to the following
 conditions:
 + *
 + * The above copyright notice and this permission notice (including the
 next
 + * paragraph) shall be included in all copies or substantial portions of
 the
 + * Software.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
 EXPRESS OR
 + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 MERCHANTABILITY,
 + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT
 SHALL
 + * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
 + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
 + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
 THE
 + * USE OR OTHER DEALINGS IN THE SOFTWARE.
 + *
 + * Authors:
 + *  Marek Olšák
 + */
 +
 +#include r600_cs.h
 +
 +void *r600_buffer_map_sync_with_rings(struct r600_common_context *ctx,
 +  struct r600_resource *resource,
 +  unsigned usage)
 +{
 +   enum radeon_bo_usage rusage = RADEON_USAGE_READWRITE;
 +
 +   if (usage  PIPE_TRANSFER_UNSYNCHRONIZED) {
 +   return ctx-ws-buffer_map(resource-cs_buf, NULL, usage);
 +   }
 +
 +   if (!(usage  PIPE_TRANSFER_WRITE)) {
 +   /* have to wait for the last write */
 +   rusage = RADEON_USAGE_WRITE;
 +   }
 +
 +   if (ctx-rings.gfx.cs-cdw 
 +   ctx-ws-cs_is_buffer_referenced(ctx-rings.gfx.cs,
 +resource-cs_buf, rusage)) {
 +   if (usage  PIPE_TRANSFER_DONTBLOCK) {
 +   ctx-rings.gfx.flush(ctx, RADEON_FLUSH_ASYNC);
 +   return NULL;
 +   } else {
 +   ctx-rings.gfx.flush(ctx, 0);
 +   }
 +   }
 +   if (ctx-rings.dma.cs 
 +   ctx-rings.dma.cs-cdw 
 +   ctx-ws-cs_is_buffer_referenced(ctx-rings.dma.cs,
 +resource-cs_buf, rusage)) {
 +   if (usage  PIPE_TRANSFER_DONTBLOCK) {
 +   ctx-rings.dma.flush(ctx, RADEON_FLUSH_ASYNC);
 +   return NULL;
 +   } else {
 +   ctx-rings.dma.flush(ctx, 0);
 +   }
 +   }
 +
 +   if (ctx-ws-buffer_is_busy(resource-buf, rusage)) {
 +   if (usage  PIPE_TRANSFER_DONTBLOCK) {
 +   return NULL;
 +   } else {
 +   /* We will be wait for the GPU. Wait for any
 offloaded
 +* CS flush to complete to avoid busy-waiting in
 the winsys. */
 +   ctx-ws-cs_sync_flush(ctx-rings.gfx.cs);
 +   if (ctx-rings.dma.cs)
 +   ctx-ws-cs_sync_flush(ctx-rings.dma.cs);
 +   }
 +   }
 +
 +   return ctx-ws-buffer_map(resource-cs_buf, NULL, usage);
 +}
 +
 +bool r600_init_resource(struct r600_common_screen *rscreen,
 +   struct r600_resource *res,
 +   unsigned size, unsigned alignment,
 +   bool use_reusable_pool, unsigned usage)
 +{
 +   uint32_t initial_domain, domains;
 +
 +   switch(usage) {
 +   case PIPE_USAGE_STAGING:
 +   /* Staging resources participate in transfers, i.e. are
 used
 +* for uploads and downloads from regular resources

Re: [Mesa-dev] [PATCH 02/17] Modified softpipe to return 64 in case of PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT.

2013-11-25 Thread Christoph Brill
Am 25.11.2013 06:36 schrieb Siavash Eliasi siavashser...@gmail.com:

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

 diff --git a/src/gallium/drivers/softpipe/sp_screen.c
b/src/gallium/drivers/softpipe/sp_screen.c
 index 47ef20e..022b5bf 100644
 --- a/src/gallium/drivers/softpipe/sp_screen.c
 +++ b/src/gallium/drivers/softpipe/sp_screen.c
 @@ -169,7 +169,7 @@ softpipe_get_param(struct pipe_screen *screen, enum
pipe_cap param)
 case PIPE_CAP_START_INSTANCE:
 case PIPE_CAP_TEXTURE_MULTISAMPLE:
 case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT:
 -  return 0;
 +  return 64;

This would return 64 for PIPE_CAP_START_INSTANCE,
PIPE_CAP_TEXTURE_MULTISAMPLE, etc. as well, which likely is wrong.

 case PIPE_CAP_QUERY_TIMESTAMP:
 case PIPE_CAP_CUBE_MAP_ARRAY:
return 1;
 --
 1.8.4.2

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

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


Re: [Mesa-dev] [PATCH 04/17] Modified llvmpipe to return 64 in case of PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT.

2013-11-25 Thread Christoph Brill
Am 25.11.2013 06:36 schrieb Siavash Eliasi siavashser...@gmail.com:

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

 diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
 index f61df98..8be1779 100644
 --- a/src/gallium/drivers/llvmpipe/lp_screen.c
 +++ b/src/gallium/drivers/llvmpipe/lp_screen.c
 @@ -220,6 +220,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum
pipe_cap param)
 case PIPE_CAP_START_INSTANCE:
 case PIPE_CAP_TEXTURE_MULTISAMPLE:
 case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT:
 +  return 64;

Same issue here as with the other patch.

 case PIPE_CAP_CUBE_MAP_ARRAY:
return 0;
 case PIPE_CAP_TEXTURE_BUFFER_OBJECTS:
 --
 1.8.4.2

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

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


Re: [Mesa-dev] [PATCH 5/6] i965/vs: implement ir_query_levels

2013-10-05 Thread Christoph Brill
2013/10/5 Chris Forbes chr...@ijw.co.nz

 Signed-off-by: Chris Forbes chr...@ijw.co.nz
 ---
  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

 diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
 b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
 index 9e6cc78..1112b23 100644
 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
 +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
 @@ -2192,6 +2192,10 @@ vec4_visitor::visit(ir_texture *ir)
lod = this-result;
lod_type = ir-lod_info.lod-type;
break;
 +   case ir_query_levels:
 +  lod = src_reg(0);
 +  lod_type = glsl_type::int_type;
 +  break;
 case ir_txf_ms:
ir-lod_info.sample_index-accept(this);
sample_index = this-result;
 @@ -2232,6 +2236,8 @@ vec4_visitor::visit(ir_texture *ir)
break;
 case ir_tg4:
inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TG4);


I think you are missing a break; here.


 +   case ir_query_levels:
 +  inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXS);
break;
 case ir_txb:
assert(!TXB is not valid for vertex shaders.);
 @@ -2264,7 +2270,7 @@ vec4_visitor::visit(ir_texture *ir)
 /* MRF for the first parameter */
 int param_base = inst-base_mrf + inst-header_present;

 -   if (ir-op == ir_txs) {
 +   if (ir-op == ir_txs || ir-op == ir_query_levels) {
int writemask = brw-gen == 4 ? WRITEMASK_W : WRITEMASK_X;
emit(MOV(dst_reg(MRF, param_base, lod_type, writemask), lod));
 } else {
 @@ -2415,6 +2421,13 @@ vec4_visitor::swizzle_result(ir_texture *ir,
 src_reg orig_val, int sampler)
 this-result = src_reg(this, ir-type);
 dst_reg swizzled_result(this-result);

 +   if (ir-op == ir_query_levels) {
 +  /* # levels is in .w */
 +  orig_val.swizzle = BRW_SWIZZLE4(SWIZZLE_W, SWIZZLE_W, SWIZZLE_W,
 SWIZZLE_W);
 +  emit(MOV(swizzled_result, orig_val));
 +  return;
 +   }
 +
 if (ir-op == ir_txs || ir-type == glsl_type::float_type
 || s == SWIZZLE_NOOP || ir-op == ir_tg4) {
emit(MOV(swizzled_result, orig_val));
 --
 1.8.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 0/4] RFC: gl_shader cache

2013-09-20 Thread Christoph Brill
2013/9/20 Tapani Pälli tapani.pa...@intel.com

 Hello;

 This is RFC for shader cache implementation, goal is to optimize
 application
 startup time. The implementation is based on idea that Kenneth had on a
 Mesa
 branch for memory based cache. These patches implement a 'behind the
 scenes'
 cache for shader compiler storing gl_shader struct to the disk. Later on my
 goal is to implement OES_get_program_binary extension using some of this
 implementation as the basis.

 There are already number of TODO's and issues mentioned in commit msgs,
 please check these first. Then, there are probably bugs and missing things
 that I'm not aware of, please let me know about any of these. One big TODO
 is to rewrite the serialization to happen to memory area first (not
 directly
 to the disk), this will make serialization more robust with more
 centralized
 error handling but also makes it more usable for OES_get_program_binary
 implementation. I haven't paid much attention to the portability of this
 code
 so I would be interested to know also how well this would work with windows
 and others.

 One big TODO/goal is to move this all to happen after linking to cache
 all shaders in a gl program. This will give far better optimization for
 startup time. Currently rough approx 1/4 time is spent during compilation
 but much more after linking and optimizations done after linking (this is
 based on analysis done with particular app and callgrind). I have already
 somewhat promising results from this cache, for example compiling L4D2
 shaders and shader-db runs are faster..

 On my SNB desktop machine shader-db takes ~2.4secs without cache, with
 cache
 it takes ~1.8secs (~2.7 when cache gets generated) (values are avg from 100
 runs compiling all the shaders). Shader-db creates 266 blobs eating 46M of
 disk space when using cache.


This sounds that we will need a configure option to disable the cache on
platforms with
a low amount of disk space (thinking of phones/embedded devices here).


 Any comments greatly appreciated!

 Tapani Pälli (4):
   glsl: add ir_cache class for IR serialization (WIP)
   mesa: gl_shader_cache class (WIP)
   glsl: export populate_symbol_table
   glsl: use gl_shader_cache when compiling (WIP)

  src/glsl/Makefile.sources |   2 +
  src/glsl/glsl_parser_extras.cpp   |  40 ++
  src/glsl/ir_cache.h   | 535 +
  src/glsl/ir_cache_serialize.cpp   | 603 
  src/glsl/ir_cache_unserialize.cpp | 969
 ++
  src/glsl/linker.cpp   |   2 +-
  src/glsl/linker.h |   3 +
  src/mesa/Makefile.sources |   1 +
  src/mesa/main/context.c   |   2 +
  src/mesa/main/mtypes.h|   4 +
  src/mesa/main/shadercache.cpp | 198 
  src/mesa/main/shadercache.h   |  68 +++
  12 files changed, 2426 insertions(+), 1 deletion(-)
  create mode 100644 src/glsl/ir_cache.h
  create mode 100644 src/glsl/ir_cache_serialize.cpp
  create mode 100644 src/glsl/ir_cache_unserialize.cpp
  create mode 100644 src/mesa/main/shadercache.cpp
  create mode 100644 src/mesa/main/shadercache.h

 --
 1.8.1.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