Re: [Mesa-dev] i965: On-demand render target flushing

[Pohjolainen, Topi]

Jason, Curro, do you have any opinion if this is worth pursuing?
I need something for blorp blits at least - using blorp for texture
uploads on top of current excessive flushing regresses perf.

When working on gpu hangs on SKL we also identified compute
flushing caches it shouldn't. I think those could be addressed
nicely here as well. I can respin if this is something we'd like
to have.

On Fri, Feb 17, 2017 at 09:32:03PM +0200, Topi Pohjolainen wrote:
> Currently:
> 
> 1) Blorp color clears and resolves emit unconditional render target
>flush + command stream after every clear/resolve (including
>regular non-fast clears).
> 
> 2) Blorp color clears, resolves and blits emit texture and constant
>cache resolves even in case only destination is dirty. This is
>because brw_render_cache_set_check_flush() does both render target
>flush as well as the top-of-pipe read cache flushes.
> 
> 3) Similarly to item 2, 3D and compute paths also flush texture and
>constant caches even if none of the texture surfaces are dirty.
> 
> 4) In case of multiple surfaces needing resolves, all render paths
>(blorp, 3D and compute) emit render target, texture and constant
>cache flushes after each resolve instead of just once after all
>resolves.
> 
> This series addresses all four cases. Good news are that even though
> the current setup isn't optimal, it doesn't actually get any better in
> most cases performance wise. There is modest gain in OglDrvRes which
> does heavy blorp blitting. I'm expecting this series also to make
> blorp tex uploads and blorp mipmap generation more competitive.
> 
> Bad news are in the final patch - it looks that current unconditional
> flushing/stalling has been hiding bugs elsewhere. There are cases
> which rely on the flushes after non-fast clears. Hunting the real
> cause is, however, difficult. I only saw them in CI system within
> full runs and was not able to reproduce them myself.
> 
> As first steps the series introduces end-of-pipe synchronization.
> This is a flush combined with stall and post-sync operation of
> writing a double word (32 bits). Until now this wasn't really
> needed as there was in many cases double flushing which in turn
> looks to take long enough to hide the need for the sync. I also
> noticed that one needs to be rather careful with it - performance
> gets decreased noticeably when used unneeded.
> 
> I don't really know if we want to go this way myself even. Current
> logic - while not ideal - is rather simple.
> 
> Topi Pohjolainen (16):
>   i965/miptree: Tell if anything got resolved
>   i965/gen6+: Implement end-of-pipe sync
>   i965: Hook end-of-pipe-sync after texture resolves
>   i965: Hook end-of-pipe-sync after image resolves
>   i965: Hook end-of-pipe-sync after framebuffer resolves
>   i965: Consider layered rt resolves along with other
>   i965: Add color resolve end-of-pipe-sync before switch to blit ring
>   i965/dri2: Add end-of-pipe-sync after color resolves
>   i965/miptree: Add color resolve end-of-pipe-sync before sharing
>   i965: Add end-of-pipe sync before non-gpu read of color resolves
>   i965/blorp: Do more fine grained flushing/syncing
>   i965/blorp/blit: Refactor hiz/ccs prep for blits
>   i965/blorp: Use conditional end-of-pipe-sync
>   i965: Consider surface resolves and sync after blorp ops
>   i965: Check if fast color clear state transition needs sync
>   i965/blorp: Drop unnecessary flushes after clear/resolve
> 
>  src/mesa/drivers/dri/i965/brw_blorp.c  | 187 ++
>  src/mesa/drivers/dri/i965/brw_compute.c|   2 +
>  src/mesa/drivers/dri/i965/brw_context.c| 333 
> +++--
>  src/mesa/drivers/dri/i965/brw_context.h|   3 +
>  src/mesa/drivers/dri/i965/brw_draw.c   |  36 +--
>  src/mesa/drivers/dri/i965/brw_pipe_control.c   |  91 +++
>  src/mesa/drivers/dri/i965/genX_blorp_exec.c|  11 -
>  src/mesa/drivers/dri/i965/intel_blit.c |  16 +-
>  src/mesa/drivers/dri/i965/intel_copy_image.c   |  10 +-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c  |  25 +-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h  |   2 +-
>  src/mesa/drivers/dri/i965/intel_pixel.c|   4 +
>  src/mesa/drivers/dri/i965/intel_pixel_bitmap.c |   5 +-
>  src/mesa/drivers/dri/i965/intel_pixel_read.c   |   7 +-
>  src/mesa/drivers/dri/i965/intel_tex_image.c|  10 +-
>  src/mesa/drivers/dri/i965/intel_tex_subimage.c |  11 +-
>  16 files changed, 557 insertions(+), 196 deletions(-)
> 
> -- 
> 2.5.5
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Use WARN_ONCE instead of open coding it.

[Jason Ekstrand]

Rb


On March 28, 2017 21:51:06 Kenneth Graunke  wrote:


---
 src/mesa/drivers/dri/i965/brw_compute.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compute.c 
b/src/mesa/drivers/dri/i965/brw_compute.c

index 16b5df7ca4e..21da2ad17b5 100644
--- a/src/mesa/drivers/dri/i965/brw_compute.c
+++ b/src/mesa/drivers/dri/i965/brw_compute.c
@@ -219,15 +219,10 @@ brw_dispatch_compute_common(struct gl_context *ctx)
  fail_next = true;
  goto retry;
   } else {
- if (intel_batchbuffer_flush(brw) == -ENOSPC) {
-static bool warned = false;
-
-if (!warned) {
-   fprintf(stderr, "i965: Single compute shader dispatch "
-   "exceeded available aperture space\n");
-   warned = true;
-}
- }
+ int ret = intel_batchbuffer_flush(brw);
+ WARN_ONCE(ret == -ENOSPC,
+   "i965: Single compute shader dispatch "
+   "exceeded available aperture space\n");
   }
}

--
2.12.1

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



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

Re: [Mesa-dev] [PATCH] i965: Combine intel_batchbuffer_reloc and intel_batchbuffer_reloc64

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 


On March 28, 2017 21:50:54 Kenneth Graunke  wrote:


These two functions do the exact same thing.  One returns a uint64_t,
and the other takes the same uint64_t and truncates it to a uint32_t.

We only need the uint64_t variant - the caller can truncate if it wants.
This patch gives us one function, intel_batchbuffer_reloc, that does
the 64-bit thing.
---
 src/mesa/drivers/dri/i965/genX_blorp_exec.c   | 15 +++-
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 22 +
 src/mesa/drivers/dri/i965/intel_batchbuffer.h | 35 +++
 3 files changed, 19 insertions(+), 53 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c 
b/src/mesa/drivers/dri/i965/genX_blorp_exec.c

index 35310fa03df..b8dcf9fd3b5 100644
--- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
+++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
@@ -48,31 +48,24 @@ blorp_emit_dwords(struct blorp_batch *batch, unsigned n)
 }

 static uint64_t
 blorp_emit_reloc(struct blorp_batch *batch,
  void *location, struct blorp_address address, uint32_t delta)
 {
assert(batch->blorp->driver_ctx == batch->driver_batch);
struct brw_context *brw = batch->driver_batch;

uint32_t offset = (char *)location - (char *)brw->batch.map;
-   if (brw->gen >= 8) {
-  return intel_batchbuffer_reloc64(>batch, address.buffer, offset,
-   address.read_domains,
-   address.write_domain,
-   address.offset + delta);
-   } else {
-  return intel_batchbuffer_reloc(>batch, address.buffer, offset,
- address.read_domains,
- address.write_domain,
- address.offset + delta);
-   }
+   return intel_batchbuffer_reloc(>batch, address.buffer, offset,
+  address.read_domains,
+  address.write_domain,
+  address.offset + delta);
 }

 static void
 blorp_surface_reloc(struct blorp_batch *batch, uint32_t ss_offset,
 struct blorp_address address, uint32_t delta)
 {
assert(batch->blorp->driver_ctx == batch->driver_batch);
struct brw_context *brw = batch->driver_batch;
drm_intel_bo *bo = address.buffer;

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c

index 49a00c12ba2..1599a2c2a53 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -569,61 +569,41 @@ _intel_batchbuffer_flush_fence(struct brw_context *brw,

/* Start a new batch buffer. */
brw_new_batch(brw);

return ret;
 }


 /*  This is the only way buffers get added to the validate list.
  */
-uint32_t
+uint64_t
 intel_batchbuffer_reloc(struct intel_batchbuffer *batch,
 drm_intel_bo *buffer, uint32_t offset,
 uint32_t read_domains, uint32_t write_domain,
 uint32_t delta)
 {
int ret;

ret = drm_intel_bo_emit_reloc(batch->bo, offset,
 buffer, delta,
 read_domains, write_domain);
assert(ret == 0);
(void)ret;

/* Using the old buffer offset, write in what the right data would be, in
 * case the buffer doesn't move and we can short-circuit the relocation
 * processing in the kernel
 */
return buffer->offset64 + delta;
 }

-uint64_t
-intel_batchbuffer_reloc64(struct intel_batchbuffer *batch,
-  drm_intel_bo *buffer, uint32_t offset,
-  uint32_t read_domains, uint32_t write_domain,
-  uint32_t delta)
-{
-   int ret = drm_intel_bo_emit_reloc(batch->bo, offset,
- buffer, delta,
- read_domains, write_domain);
-   assert(ret == 0);
-   (void) ret;
-
-   /* Using the old buffer offset, write in what the right data would be, in
-* case the buffer doesn't move and we can short-circuit the relocation
-* processing in the kernel
-*/
-   return buffer->offset64 + delta;
-}
-
-
 void
 intel_batchbuffer_data(struct brw_context *brw,
const void *data, GLuint bytes, enum brw_gpu_ring ring)
 {
assert((bytes & 3) == 0);
intel_batchbuffer_require_space(brw, bytes, ring);
memcpy(brw->batch.map_next, data, bytes);
brw->batch.map_next += bytes >> 2;
 }

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.h

index 01d48048a68..cf545ec1886 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
@@ -57,32 +57,26 @@ int _intel_batchbuffer_flush_fence(struct brw_context *brw,

[Mesa-dev] [PATCH 1/2] mesa/glthread: add async support to glProgramUniform*() functions

[Timothy Arceri]

---
 src/mapi/glapi/gen/ARB_separate_shader_objects.xml | 68 +++---
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/src/mapi/glapi/gen/ARB_separate_shader_objects.xml 
b/src/mapi/glapi/gen/ARB_separate_shader_objects.xml
index c9f481d..26a7afa 100644
--- a/src/mapi/glapi/gen/ARB_separate_shader_objects.xml
+++ b/src/mapi/glapi/gen/ARB_separate_shader_objects.xml
@@ -134,150 +134,150 @@
  
  
  
  
  
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
   
   
  
  
  
  
   
@@ -306,94 +306,94 @@
  
  
  
  
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   
   
  
  
  
- 
+ 
   

 
-- 
2.9.3

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

[Mesa-dev] [PATCH 2/2] mesa/glthread: fallback to sync if count validation fails

[Timothy Arceri]

The old code would sync and then throw a cryptic error message.
There is no need for a custome error, we can just fallback to
the real function and have it do proper validation.

Fixes piglit test:
glsl-uniform-out-of-bounds

Which was returning the wrong error code.
---
 src/mapi/glapi/gen/gl_marshal.py | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/src/mapi/glapi/gen/gl_marshal.py b/src/mapi/glapi/gen/gl_marshal.py
index 9639f9c..92bc0e4 100644
--- a/src/mapi/glapi/gen/gl_marshal.py
+++ b/src/mapi/glapi/gen/gl_marshal.py
@@ -197,71 +197,77 @@ class PrintCode(gl_XML.gl_print_base):
 out('{0} = NULL;'.format(p.name))
 out('else')
 with indent():
 out('variable_data += 
{0};'.format(p.size_string(False)))
 else:
 out('variable_data += 
{0};'.format(p.size_string(False)))
 
 self.print_sync_call(func)
 out('}')
 
-def validate_count_or_return(self, func):
+def validate_count_or_fallback(self, func):
 # Check that any counts for variable-length arguments might be < 0, in
 # which case the command alloc or the memcpy would blow up before we
 # get to the validation in Mesa core.
 for p in func.parameters:
 if p.is_variable_length():
 out('if (unlikely({0} < 0)) {{'.format(p.size_string()))
 with indent():
-out('_mesa_glthread_finish(ctx);')
-out('_mesa_error(ctx, GL_INVALID_VALUE, "{0}({1} < 
0)");'.format(func.name, p.size_string()))
-out('return;')
+out('goto fallback_to_sync;')
 out('}')
+return True
+return False
+
 
 def print_async_marshal(self, func):
+validate_count = False
 out('static void GLAPIENTRY')
 out('_mesa_marshal_{0}({1})'.format(
 func.name, func.get_parameter_string()))
 out('{')
 with indent():
 out('GET_CURRENT_CONTEXT(ctx);')
 struct = 'struct marshal_cmd_{0}'.format(func.name)
 size_terms = ['sizeof({0})'.format(struct)]
 for p in func.variable_params:
 size = p.size_string()
 if p.img_null_flag:
 size = '({0} ? {1} : 0)'.format(p.name, size)
 size_terms.append(size)
 out('size_t cmd_size = {0};'.format(' + '.join(size_terms)))
 out('{0} *cmd;'.format(struct))
 
 out('debug_print_marshal("{0}");'.format(func.name))
 
-self.validate_count_or_return(func)
+validate_count = self.validate_count_or_fallback(func)
 
 if func.marshal_fail:
 out('if ({0}) {{'.format(func.marshal_fail))
 with indent():
 out('_mesa_glthread_finish(ctx);')
 out('_mesa_glthread_restore_dispatch(ctx);')
 self.print_sync_dispatch(func)
 out('return;')
 out('}')
 
 out('if (cmd_size <= MARSHAL_MAX_CMD_SIZE) {')
 with indent():
 self.print_async_dispatch(func)
-out('} else {')
-with indent():
-self.print_sync_dispatch(func)
+out('return;')
 out('}')
 
+out('')
+if validate_count:
+out('fallback_to_sync:')
+with indent():
+self.print_sync_dispatch(func)
+
 out('}')
 
 def print_async_body(self, func):
 out('/* {0}: marshalled asynchronously */'.format(func.name))
 self.print_async_struct(func)
 self.print_async_unmarshal(func)
 self.print_async_marshal(func)
 out('')
 out('')
 
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH] AndroidIA: android: Pass sse4.1 flag as appropriate.

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

On 03/28/2017 09:38 PM, Harish Krupo wrote:

We have functions which depend on sse4.1 support but we didnt pass
the right compile flag for it. This patch fixes it.

Signed-off-by: Kalyan Kondapally 
Signed-off-by: Harish Krupo 
---
  src/mesa/Android.libmesa_sse41.mk | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/mesa/Android.libmesa_sse41.mk 
b/src/mesa/Android.libmesa_sse41.mk
index 8562da6019..da40f43df6 100644
--- a/src/mesa/Android.libmesa_sse41.mk
+++ b/src/mesa/Android.libmesa_sse41.mk
@@ -33,6 +33,9 @@ LOCAL_MODULE := libmesa_sse41
  LOCAL_SRC_FILES += \
$(X86_SSE41_FILES)
  
+LOCAL_CFLAGS := \

+   -msse4.1
+
  LOCAL_C_INCLUDES := \
$(MESA_TOP)/src/mapi \
$(MESA_TOP)/src/gallium/include \



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

[Mesa-dev] [PATCH] radv: move to using nir clip/cull merge pass.

[Dave Airlie]

From: Dave Airlie 

Doing this before tessellation makes doing some bits of
tessellation a bit cleaner. It also cleans up a bit of the
llvm generator code.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 144 ++--
 src/amd/vulkan/radv_pipeline.c  |   1 +
 2 files changed, 36 insertions(+), 109 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index f164d8f..78602fd 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -144,8 +144,6 @@ struct nir_to_llvm_context {
int num_locals;
LLVMValueRef *locals;
bool has_ddxy;
-   uint8_t num_input_clips;
-   uint8_t num_input_culls;
uint8_t num_output_clips;
uint8_t num_output_culls;
 
@@ -170,12 +168,9 @@ static unsigned shader_io_get_unique_index(gl_varying_slot 
slot)
return 0;
if (slot == VARYING_SLOT_PSIZ)
return 1;
-   if (slot == VARYING_SLOT_CLIP_DIST0 ||
-   slot == VARYING_SLOT_CULL_DIST0)
+   if (slot == VARYING_SLOT_CLIP_DIST0)
return 2;
-   if (slot == VARYING_SLOT_CLIP_DIST1 ||
-   slot == VARYING_SLOT_CULL_DIST1)
-   return 3;
+   /* 3 is reserved for clip dist as well */
if (slot >= VARYING_SLOT_VAR0 && slot <= VARYING_SLOT_VAR31)
return 4 + (slot - VARYING_SLOT_VAR0);
unreachable("illegal slot in get unique index\n");
@@ -2195,7 +2190,6 @@ load_gs_input(struct nir_to_llvm_context *ctx,
unsigned param, vtx_offset_param;
LLVMValueRef value[4], result;
unsigned vertex_index;
-   unsigned cull_offset = 0;
radv_get_deref_offset(ctx, >variables[0]->deref,
  false, _index,
  _index, _index);
@@ -2205,13 +2199,11 @@ load_gs_input(struct nir_to_llvm_context *ctx,
  LLVMConstInt(ctx->i32, 4, false), "");
 
param = 
shader_io_get_unique_index(instr->variables[0]->var->data.location);
-   if (instr->variables[0]->var->data.location == VARYING_SLOT_CULL_DIST0)
-   cull_offset += ctx->num_input_clips;
for (unsigned i = 0; i < instr->num_components; i++) {
 
args[0] = ctx->esgs_ring;
args[1] = vtx_offset;
-   args[2] = LLVMConstInt(ctx->i32, (param * 4 + i + const_index + 
cull_offset) * 256, false);
+   args[2] = LLVMConstInt(ctx->i32, (param * 4 + i + const_index) 
* 256, false);
args[3] = ctx->i32zero;
args[4] = ctx->i32one; /* OFFEN */
args[5] = ctx->i32zero; /* IDXEN */
@@ -2366,8 +2358,7 @@ visit_store_var(struct nir_to_llvm_context *ctx,
 
value = llvm_extract_elem(ctx, src, chan);
 
-   if (instr->variables[0]->var->data.location == 
VARYING_SLOT_CLIP_DIST0 ||
-   instr->variables[0]->var->data.location == 
VARYING_SLOT_CULL_DIST0)
+   if (instr->variables[0]->var->data.compact)
stride = 1;
if (indir_index) {
unsigned count = glsl_count_attribute_slots(
@@ -3143,7 +3134,7 @@ visit_emit_vertex(struct nir_to_llvm_context *ctx,
LLVMValueRef gs_next_vertex;
LLVMValueRef can_emit, kill;
int idx;
-   int clip_cull_slot = -1;
+
assert(instr->const_index[0] == 0);
/* Write vertex attribute values to GSVS ring */
gs_next_vertex = LLVMBuildLoad(ctx->builder,
@@ -3175,27 +3166,11 @@ visit_emit_vertex(struct nir_to_llvm_context *ctx,
if (!(ctx->output_mask & (1ull << i)))
continue;
 
-   if (i == VARYING_SLOT_CLIP_DIST1 ||
-   i == VARYING_SLOT_CULL_DIST1)
-   continue;
-
-   if (i == VARYING_SLOT_CLIP_DIST0 ||
-   i == VARYING_SLOT_CULL_DIST0) {
+   if (i == VARYING_SLOT_CLIP_DIST0) {
/* pack clip and cull into a single set of slots */
-   if (clip_cull_slot == -1) {
-   clip_cull_slot = idx;
-   if (ctx->num_output_clips + 
ctx->num_output_culls > 4)
-   slot_inc = 2;
-   } else {
-   slot = clip_cull_slot;
-   slot_inc = 0;
-   }
-   if (i == VARYING_SLOT_CLIP_DIST0)
-   length = ctx->num_output_clips;
-   if (i == VARYING_SLOT_CULL_DIST0) {
-   start = ctx->num_output_clips;
-   length = ctx->num_output_culls;
-   }
+   length = 

[Mesa-dev] [PATCH] i965: Use WARN_ONCE instead of open coding it.

[Kenneth Graunke]

---
 src/mesa/drivers/dri/i965/brw_compute.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compute.c 
b/src/mesa/drivers/dri/i965/brw_compute.c
index 16b5df7ca4e..21da2ad17b5 100644
--- a/src/mesa/drivers/dri/i965/brw_compute.c
+++ b/src/mesa/drivers/dri/i965/brw_compute.c
@@ -219,15 +219,10 @@ brw_dispatch_compute_common(struct gl_context *ctx)
  fail_next = true;
  goto retry;
   } else {
- if (intel_batchbuffer_flush(brw) == -ENOSPC) {
-static bool warned = false;
-
-if (!warned) {
-   fprintf(stderr, "i965: Single compute shader dispatch "
-   "exceeded available aperture space\n");
-   warned = true;
-}
- }
+ int ret = intel_batchbuffer_flush(brw);
+ WARN_ONCE(ret == -ENOSPC,
+   "i965: Single compute shader dispatch "
+   "exceeded available aperture space\n");
   }
}
 
-- 
2.12.1

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

[Mesa-dev] [PATCH] i965: Combine intel_batchbuffer_reloc and intel_batchbuffer_reloc64

[Kenneth Graunke]

These two functions do the exact same thing.  One returns a uint64_t,
and the other takes the same uint64_t and truncates it to a uint32_t.

We only need the uint64_t variant - the caller can truncate if it wants.
This patch gives us one function, intel_batchbuffer_reloc, that does
the 64-bit thing.
---
 src/mesa/drivers/dri/i965/genX_blorp_exec.c   | 15 +++-
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 22 +
 src/mesa/drivers/dri/i965/intel_batchbuffer.h | 35 +++
 3 files changed, 19 insertions(+), 53 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c 
b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
index 35310fa03df..b8dcf9fd3b5 100644
--- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
+++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
@@ -48,31 +48,24 @@ blorp_emit_dwords(struct blorp_batch *batch, unsigned n)
 }
 
 static uint64_t
 blorp_emit_reloc(struct blorp_batch *batch,
  void *location, struct blorp_address address, uint32_t delta)
 {
assert(batch->blorp->driver_ctx == batch->driver_batch);
struct brw_context *brw = batch->driver_batch;
 
uint32_t offset = (char *)location - (char *)brw->batch.map;
-   if (brw->gen >= 8) {
-  return intel_batchbuffer_reloc64(>batch, address.buffer, offset,
-   address.read_domains,
-   address.write_domain,
-   address.offset + delta);
-   } else {
-  return intel_batchbuffer_reloc(>batch, address.buffer, offset,
- address.read_domains,
- address.write_domain,
- address.offset + delta);
-   }
+   return intel_batchbuffer_reloc(>batch, address.buffer, offset,
+  address.read_domains,
+  address.write_domain,
+  address.offset + delta);
 }
 
 static void
 blorp_surface_reloc(struct blorp_batch *batch, uint32_t ss_offset,
 struct blorp_address address, uint32_t delta)
 {
assert(batch->blorp->driver_ctx == batch->driver_batch);
struct brw_context *brw = batch->driver_batch;
drm_intel_bo *bo = address.buffer;
 
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 49a00c12ba2..1599a2c2a53 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -569,61 +569,41 @@ _intel_batchbuffer_flush_fence(struct brw_context *brw,
 
/* Start a new batch buffer. */
brw_new_batch(brw);
 
return ret;
 }
 
 
 /*  This is the only way buffers get added to the validate list.
  */
-uint32_t
+uint64_t
 intel_batchbuffer_reloc(struct intel_batchbuffer *batch,
 drm_intel_bo *buffer, uint32_t offset,
 uint32_t read_domains, uint32_t write_domain,
 uint32_t delta)
 {
int ret;
 
ret = drm_intel_bo_emit_reloc(batch->bo, offset,
 buffer, delta,
 read_domains, write_domain);
assert(ret == 0);
(void)ret;
 
/* Using the old buffer offset, write in what the right data would be, in
 * case the buffer doesn't move and we can short-circuit the relocation
 * processing in the kernel
 */
return buffer->offset64 + delta;
 }
 
-uint64_t
-intel_batchbuffer_reloc64(struct intel_batchbuffer *batch,
-  drm_intel_bo *buffer, uint32_t offset,
-  uint32_t read_domains, uint32_t write_domain,
-  uint32_t delta)
-{
-   int ret = drm_intel_bo_emit_reloc(batch->bo, offset,
- buffer, delta,
- read_domains, write_domain);
-   assert(ret == 0);
-   (void) ret;
-
-   /* Using the old buffer offset, write in what the right data would be, in
-* case the buffer doesn't move and we can short-circuit the relocation
-* processing in the kernel
-*/
-   return buffer->offset64 + delta;
-}
-
-
 void
 intel_batchbuffer_data(struct brw_context *brw,
const void *data, GLuint bytes, enum brw_gpu_ring ring)
 {
assert((bytes & 3) == 0);
intel_batchbuffer_require_space(brw, bytes, ring);
memcpy(brw->batch.map_next, data, bytes);
brw->batch.map_next += bytes >> 2;
 }
 
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
index 01d48048a68..cf545ec1886 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
@@ -57,32 +57,26 @@ int _intel_batchbuffer_flush_fence(struct brw_context *brw,
   __FILE__, __LINE__)
 
 /* Unlike bmBufferData, this currently requires the buffer be 

[Mesa-dev] [Bug 100441] glsl/tests/optimization-test.sh regression

[bugzilla-daemon]

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

Bug ID: 100441
   Summary: glsl/tests/optimization-test.sh regression
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: glsl-compiler
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: intel-3d-b...@lists.freedesktop.org

mesa: 78ee8b3f849063e3e37db0767212397da522b6fa (master 17.1.0-devel)


   Mesa 17.1.0-devel: src/compiler/test-suite.log


# TOTAL: 10
# PASS:  9
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: glsl/tests/optimization-test.sh

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

[Mesa-dev] [PATCH] mesa/glthread: print out syncs when MARSHAL_MAX_CMD_SIZE is exceeded

[Timothy Arceri]

---
 src/mapi/glapi/gen/gl_marshal.py |  1 +
 src/mesa/main/marshal.h  | 13 +
 2 files changed, 14 insertions(+)

diff --git a/src/mapi/glapi/gen/gl_marshal.py b/src/mapi/glapi/gen/gl_marshal.py
index c89d397..9639f9c 100644
--- a/src/mapi/glapi/gen/gl_marshal.py
+++ b/src/mapi/glapi/gen/gl_marshal.py
@@ -84,20 +84,21 @@ class PrintCode(gl_XML.gl_print_base):
 def print_sync_call(self, func):
 call = 'CALL_{0}(ctx->CurrentServerDispatch, ({1}))'.format(
 func.name, func.get_called_parameter_string())
 if func.return_type == 'void':
 out('{0};'.format(call))
 else:
 out('return {0};'.format(call))
 
 def print_sync_dispatch(self, func):
 out('_mesa_glthread_finish(ctx);')
+out('debug_print_sync_fallback("{0}");'.format(func.name))
 self.print_sync_call(func)
 
 def print_sync_body(self, func):
 out('/* {0}: marshalled synchronously */'.format(func.name))
 out('static {0} GLAPIENTRY'.format(func.return_type))
 out('_mesa_marshal_{0}({1})'.format(func.name, 
func.get_parameter_string()))
 out('{')
 with indent():
 out('GET_CURRENT_CONTEXT(ctx);')
 out('_mesa_glthread_finish(ctx);')
diff --git a/src/mesa/main/marshal.h b/src/mesa/main/marshal.h
index 8ea303a..3ef5591 100644
--- a/src/mesa/main/marshal.h
+++ b/src/mesa/main/marshal.h
@@ -113,20 +113,33 @@ _mesa_glthread_is_non_vbo_vertex_attrib_pointer(const 
struct gl_context *ctx)
 static inline bool
 _mesa_glthread_is_non_vbo_draw_elements(const struct gl_context *ctx)
 {
return false;
 }
 
 #endif
 
 #define DEBUG_MARSHAL_PRINT_CALLS 0
 
+/**
+ * This is printed when we have fallen back to a sync. This can happen when
+ * MARSHAL_MAX_CMD_SIZE is exceeded.
+ */
+static inline void
+debug_print_sync_fallback(const char *func)
+{
+#if DEBUG_MARSHAL_PRINT_CALLS
+   printf("fallback to sync: %s\n", func);
+#endif
+}
+
+
 static inline void
 debug_print_sync(const char *func)
 {
 #if DEBUG_MARSHAL_PRINT_CALLS
printf("sync: %s\n", func);
 #endif
 }
 
 static inline void
 debug_print_marshal(const char *func)
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH v2 0/6] radv sparseBinding

[Dave Airlie]

On 29 March 2017 at 10:03, Bas Nieuwenhuizen  wrote:
> This series introduces the sparseBinding capability to radv.
>
> I've mostly rebased & clarified the core remapping algorithm in patch 1,
> as well as fixed some bugs that I found.
>
> No regressions on CTS, all new non-skipping tests (~400) pass.

For the series,

Reviewed-by: Dave Airlie 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 2/2] anv: Advertise larger heap sizes

[Jason Ekstrand]

Instead of just advertising the aperture size, we do something more
intelligent.  On systems with a full 48-bit PPGTT, we can address 100%
of the available system RAM from the GPU.  In order to keep clients from
burning 100% of your available RAM for graphics resources, we have a
nice little heuristic (which has received exactly zero tuning) to keep
things under a reasonable level of control.

Cc: Alex Smith 
---
 src/intel/vulkan/anv_device.c  | 61 +-
 src/intel/vulkan/anv_gem.c | 16 +++
 src/intel/vulkan/anv_private.h | 13 -
 3 files changed, 76 insertions(+), 14 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index f9d04ee..0e5e4b9 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -53,6 +54,48 @@ compiler_perf_log(void *data, const char *fmt, ...)
va_end(args);
 }
 
+static VkResult
+anv_compute_heap_size(int fd, uint64_t *heap_size)
+{
+   uint64_t gtt_size;
+   if (anv_gem_get_context_param(fd, 0, I915_CONTEXT_PARAM_GTT_SIZE,
+ _size) == -1) {
+  /* If, for whatever reason, we can't actually get the GTT size from the
+   * kernel (too old?) fall back to the aperture size.
+   */
+  anv_perf_warn("Failed to get I915_CONTEXT_PARAM_GTT_SIZE: %m");
+
+  if (anv_gem_get_aperture(fd, _size) == -1) {
+ return vk_errorf(VK_ERROR_INITIALIZATION_FAILED,
+  "failed to get aperture size: %m");
+  }
+   }
+
+   /* Query the total ram from the system */
+   struct sysinfo info;
+   sysinfo();
+
+   uint64_t total_ram = (uint64_t)info.totalram * (uint64_t)info.mem_unit;
+
+   /* We don't want to burn too much ram with the GPU.  If the user has 4GiB
+* or less, we use at most half.  If they have more than 4GiB, we use 3/4.
+*/
+   uint64_t available_ram;
+   if (total_ram <= 4ull * 1024ull * 1024ull * 1024ull)
+  available_ram = total_ram / 2;
+   else
+  available_ram = total_ram * 3 / 4;
+
+   /* We also want to leave some padding for things we allocate in the driver,
+* so don't go over 3/4 of the GTT either.
+*/
+   uint64_t available_gtt = gtt_size * 3 / 4;
+
+   *heap_size = MIN2(available_ram, available_gtt);
+
+   return VK_SUCCESS;
+}
+
 static bool
 anv_device_get_cache_uuid(void *uuid)
 {
@@ -124,12 +167,6 @@ anv_physical_device_init(struct anv_physical_device 
*device,
   }
}
 
-   if (anv_gem_get_aperture(fd, >aperture_size) == -1) {
-  result = vk_errorf(VK_ERROR_INITIALIZATION_FAILED,
- "failed to get aperture size: %m");
-  goto fail;
-   }
-
if (!anv_gem_get_param(fd, I915_PARAM_HAS_WAIT_TIMEOUT)) {
   result = vk_errorf(VK_ERROR_INITIALIZATION_FAILED,
  "kernel missing gem wait");
@@ -151,6 +188,10 @@ anv_physical_device_init(struct anv_physical_device 
*device,
 
device->supports_48bit_addresses = anv_gem_supports_48b_addresses(fd);
 
+   result = anv_compute_heap_size(fd, >heap_size);
+   if (result != VK_SUCCESS)
+  goto fail;
+
if (!anv_device_get_cache_uuid(device->uuid)) {
   result = vk_errorf(VK_ERROR_INITIALIZATION_FAILED,
  "cannot generate UUID");
@@ -731,12 +772,6 @@ void anv_GetPhysicalDeviceMemoryProperties(
 VkPhysicalDeviceMemoryProperties*   pMemoryProperties)
 {
ANV_FROM_HANDLE(anv_physical_device, physical_device, physicalDevice);
-   VkDeviceSize heap_size;
-
-   /* Reserve some wiggle room for the driver by exposing only 75% of the
-* aperture to the heap.
-*/
-   heap_size = 3 * physical_device->aperture_size / 4;
 
if (physical_device->info.has_llc) {
   /* Big core GPUs share LLC with the CPU and thus one memory type can be
@@ -773,7 +808,7 @@ void anv_GetPhysicalDeviceMemoryProperties(
 
pMemoryProperties->memoryHeapCount = 1;
pMemoryProperties->memoryHeaps[0] = (VkMemoryHeap) {
-  .size = heap_size,
+  .size = physical_device->heap_size,
   .flags = VK_MEMORY_HEAP_DEVICE_LOCAL_BIT,
};
 }
diff --git a/src/intel/vulkan/anv_gem.c b/src/intel/vulkan/anv_gem.c
index 3d45243..5f478b5 100644
--- a/src/intel/vulkan/anv_gem.c
+++ b/src/intel/vulkan/anv_gem.c
@@ -288,6 +288,22 @@ anv_gem_destroy_context(struct anv_device *device, int 
context)
 }
 
 int
+anv_gem_get_context_param(int fd, int context, uint32_t param, uint64_t *value)
+{
+   struct drm_i915_gem_context_param gp = {
+  .ctx_id = context,
+  .param = param,
+   };
+
+   int ret = anv_ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, );
+   if (ret == -1)
+  return -1;
+
+   *value = gp.value;
+   return 0;
+}
+
+int
 anv_gem_get_aperture(int fd, uint64_t *size)
 {
struct drm_i915_gem_get_aperture aperture = { 0 };
diff --git a/src/intel/vulkan/anv_private.h 

[Mesa-dev] [PATCH v2 1/2] anv: Add support for 48-bit addresses

[Jason Ekstrand]

This commit adds support for using the full 48-bit address space on
Broadwell and newer hardware.  Thanks to certain limitations, not all
objects can be placed above the 32-bit boundary.  In particular, general
and state base address need to live within 32 bits.  (See also
Wa32bitGeneralStateOffset and Wa32bitInstructionBaseOffset.)  In order
to handle this, we add a supports_48bit_address field to anv_bo and only
set EXEC_OBJECT_SUPPORTS_48B_ADDRESS if that bit is set.  We set the bit
for all client-allocated memory objects but leave it false for
driver-allocated objects.  While this is more conservative than needed,
all driver allocations should easily fit in the first 32 bits of address
space and keeps things simple because we don't have to think about
whether or not any given one of our allocation data structures will be
used in a 48-bit-unsafe way.
---
 src/intel/vulkan/anv_allocator.c   | 10 --
 src/intel/vulkan/anv_batch_chain.c | 14 ++
 src/intel/vulkan/anv_device.c  |  4 +++-
 src/intel/vulkan/anv_gem.c | 18 ++
 src/intel/vulkan/anv_intel.c   |  2 +-
 src/intel/vulkan/anv_private.h | 29 +++--
 6 files changed, 67 insertions(+), 10 deletions(-)

diff --git a/src/intel/vulkan/anv_allocator.c b/src/intel/vulkan/anv_allocator.c
index 45c663b..88c9c13 100644
--- a/src/intel/vulkan/anv_allocator.c
+++ b/src/intel/vulkan/anv_allocator.c
@@ -255,7 +255,7 @@ anv_block_pool_init(struct anv_block_pool *pool,
assert(util_is_power_of_two(block_size));
 
pool->device = device;
-   anv_bo_init(>bo, 0, 0);
+   anv_bo_init(>bo, 0, 0, false);
pool->block_size = block_size;
pool->free_list = ANV_FREE_LIST_EMPTY;
pool->back_free_list = ANV_FREE_LIST_EMPTY;
@@ -475,7 +475,13 @@ anv_block_pool_grow(struct anv_block_pool *pool, struct 
anv_block_state *state)
 * values back into pool. */
pool->map = map + center_bo_offset;
pool->center_bo_offset = center_bo_offset;
-   anv_bo_init(>bo, gem_handle, size);
+
+   /* Block pool BOs are marked as not supporting 48-bit addresses because
+* they are used to back STATE_BASE_ADDRESS.
+*
+* See also anv_bo::supports_48bit_address.
+*/
+   anv_bo_init(>bo, gem_handle, size, false);
pool->bo.map = map;
 
 done:
diff --git a/src/intel/vulkan/anv_batch_chain.c 
b/src/intel/vulkan/anv_batch_chain.c
index 5d7abc6..b098e4b 100644
--- a/src/intel/vulkan/anv_batch_chain.c
+++ b/src/intel/vulkan/anv_batch_chain.c
@@ -979,7 +979,8 @@ anv_execbuf_finish(struct anv_execbuf *exec,
 }
 
 static VkResult
-anv_execbuf_add_bo(struct anv_execbuf *exec,
+anv_execbuf_add_bo(struct anv_device *device,
+   struct anv_execbuf *exec,
struct anv_bo *bo,
struct anv_reloc_list *relocs,
const VkAllocationCallbacks *alloc)
@@ -1039,6 +1040,10 @@ anv_execbuf_add_bo(struct anv_execbuf *exec,
   obj->flags = bo->is_winsys_bo ? EXEC_OBJECT_WRITE : 0;
   obj->rsvd1 = 0;
   obj->rsvd2 = 0;
+
+  if (device->instance->physicalDevice.supports_48bit_addresses &&
+  bo->supports_48bit_address)
+ obj->flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
}
 
if (relocs != NULL && obj->relocation_count == 0) {
@@ -1052,7 +1057,7 @@ anv_execbuf_add_bo(struct anv_execbuf *exec,
   for (size_t i = 0; i < relocs->num_relocs; i++) {
  /* A quick sanity check on relocations */
  assert(relocs->relocs[i].offset < bo->size);
- anv_execbuf_add_bo(exec, relocs->reloc_bos[i], NULL, alloc);
+ anv_execbuf_add_bo(device, exec, relocs->reloc_bos[i], NULL, alloc);
   }
}
 
@@ -1264,7 +1269,8 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
adjust_relocations_from_state_pool(ss_pool, _buffer->surface_relocs,
   cmd_buffer->last_ss_pool_center);
VkResult result =
-  anv_execbuf_add_bo(, _pool->bo, _buffer->surface_relocs,
+  anv_execbuf_add_bo(device, , _pool->bo,
+ _buffer->surface_relocs,
  _buffer->pool->alloc);
if (result != VK_SUCCESS)
   return result;
@@ -1277,7 +1283,7 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
   adjust_relocations_to_state_pool(ss_pool, &(*bbo)->bo, &(*bbo)->relocs,
cmd_buffer->last_ss_pool_center);
 
-  anv_execbuf_add_bo(, &(*bbo)->bo, &(*bbo)->relocs,
+  anv_execbuf_add_bo(device, , &(*bbo)->bo, &(*bbo)->relocs,
  _buffer->pool->alloc);
}
 
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 4e4fa19..f9d04ee 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -149,6 +149,8 @@ anv_physical_device_init(struct anv_physical_device *device,
   goto fail;
}
 
+   device->supports_48bit_addresses = anv_gem_supports_48b_addresses(fd);
+
if 

[Mesa-dev] [PATCH v2 0/2] anv: Use the full 48-bit address space

[Jason Ekstrand]

This patch series is largely a re-send of the series with a couple of
tweaks to patch 1.  Most notably, I did a bunch of digging as to why
allowing dynamic and instruction state buffers to get a 48-bit address is
problematic.  The details are in the big fat comment I added to
anv_bo::supports_48bit_address.

Cc: Kristian H. Kristensen 
Cc: Chris Wilson 

Jason Ekstrand (2):
  anv: Add support for 48-bit addresses
  anv: Advertise larger heap sizes

 src/intel/vulkan/anv_allocator.c   | 10 --
 src/intel/vulkan/anv_batch_chain.c | 14 +---
 src/intel/vulkan/anv_device.c  | 65 ++
 src/intel/vulkan/anv_gem.c | 34 
 src/intel/vulkan/anv_intel.c   |  2 +-
 src/intel/vulkan/anv_private.h | 42 ++--
 6 files changed, 143 insertions(+), 24 deletions(-)

-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH v5 1/5] genxml: New generated header genX_bits.h (v5)

[Emil Velikov]

On 28 March 2017 at 20:43, Chad Versace  wrote:
> On Tue 28 Mar 2017, Emil Velikov wrote:
>> Hi Chad,
>>
>> On 25 March 2017 at 02:28, Chad Versace  wrote:
>> > genX_bits.h contains the sizes of bitfields in genxml instructions,
>> > structures, and registers. It also defines some functions to query those
>> > sizes.
>> >
>> > isl_surf_init() will use the new header to validate that requested
>> > pitches fit in their destination bitfields.
>> >
>> > What's currently in genX_bits.h:
>> >
>> >   - Each CONTAINER::Field from gen*.xml that has a bitsize has a macro
>> > in genX_bits.h:
>> >
>> > #define GEN{N}_CONTAINER_Field_bits {bitsize}
>> >
>> >   - For each set of macros whose name, after stripping the GEN prefix,
>> > is the same, genX_bits.h contains a query function:
>> >
>> >   static inline uint32_t __attribute__((pure))
>> >   CONTAINER_Field_bits(const struct gen_device_info *devinfo);
>> >
>> > v2 (Chad Versace):
>> >   - Parse the XML instead of scraping the generated gen*_pack.h headers.
>> >
>> > v3 (Dylan Baker):
>> >   - Port to Mako.
>> >
>> > v4 (Jason Ekstrand):
>> >   - Make the _bits functions take a gen_device_info.
>> >
>> > v5 (Chad Versace):
>> >   - Fix autotools out-of-tree build.
>> >   - Fix Android build. Tested with git://github.com/android-ia/manifest.
>> >   - Fix macro names. They were all missing the "_bits" suffix.
>> >   - Fix macros names more. Remove all double-underscores.
>> >   - Unindent all generated code. (It was floating in a sea of whitespace).
>> >   - Reformat header to appear human-written not machine-generated.
>> >   - Sort gens from high to low. Newest gens should come first because,
>> > when we read code, we likely want to read the gen8/9 code and ignore
>> > the gen4 code. So put the gen4 code at the bottom.
>> >   - Replace 'const' attributes with 'pure', because the functions now
>> > have a pointer parameter.
>> >   - Add --cpp-guard flag. Used by Android.
>> >   - Kill class FieldCollection. After Jason's rewrite, it was just
>> > a dict.
>> >
>> > Co-authored-by: Dylan Baker 
>> > Co-authored-by: Jason Ekstrand 
>> > ---
>> >  src/intel/Android.genxml.mk |   9 +-
>> >  src/intel/Makefile.genxml.am|   6 +-
>> >  src/intel/Makefile.sources  |   6 +-
>> >  src/intel/genxml/.gitignore |   1 +
>> >  src/intel/genxml/gen_bits_header.py | 281 
>> > 
>> >  5 files changed, 300 insertions(+), 3 deletions(-)
>> >  create mode 100644 src/intel/genxml/gen_bits_header.py
>> >
>> > diff --git a/src/intel/Android.genxml.mk b/src/intel/Android.genxml.mk
>> > index 79de7843801..842d0e13a33 100644
>> > --- a/src/intel/Android.genxml.mk
>> > +++ b/src/intel/Android.genxml.mk
>> > @@ -46,9 +46,16 @@ LOCAL_GENERATED_SOURCES += $(addprefix 
>> > $(intermediates)/, $(GENXML_GENERATED_FIL
>> >  define header-gen
>> > @mkdir -p $(dir $@)
>> > @echo "Gen Header: $(PRIVATE_MODULE) <= $(notdir $(@))"
>> > -   $(hide) $(PRIVATE_SCRIPT) $(PRIVATE_XML) > $@
>> > +   $(hide) $(PRIVATE_SCRIPT) $(PRIVATE_SCRIPT_FLAGS) $(PRIVATE_XML) > 
>> > $@
>> >  endef
>> >
>> > +$(intermediates)/genxml/genX_bits.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) 
>> > $(LOCAL_PATH)/genxml/gen_bits_header.py
>> > +$(intermediates)/genxml/genX_bits.h: PRIVATE_SCRIPT_FLAGS := 
>> > --cpp-guard=GENX_BITS_H
>> > +$(intermediates)/genxml/genX_bits.h: PRIVATE_XML := $(addprefix 
>> > $(LOCAL_PATH)/,$(GENXML_XML_FILES))
>> > +$(intermediates)/genxml/genX_bits.h: 
>> > $(LOCAL_PATH)/genxml/gen_bits_header.py
>> > +$(intermediates)/genxml/genX_bits.h: $(addprefix 
>> > $(LOCAL_PATH)/,$(GENXML_XML_FILES))
>> > +   $(call header-gen)
>> > +
>> >  $(intermediates)/genxml/gen4_pack.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) 
>> > $(LOCAL_PATH)/genxml/gen_pack_header.py
>> >  $(intermediates)/genxml/gen4_pack.h: PRIVATE_XML := 
>> > $(LOCAL_PATH)/genxml/gen4.xml
>> >  $(intermediates)/genxml/gen4_pack.h: $(LOCAL_PATH)/genxml/gen4.xml 
>> > $(LOCAL_PATH)/genxml/gen_pack_header.py
>
>
>
>> > +def parse_args():
>> > +p = argparse.ArgumentParser()
>> > +p.add_argument('-o', '--output', type=str,
>> > +   help="If OUTPUT is unset or '-', then it defaults to 
>> > '/dev/stdout'")
>> > +p.add_argument('--cpp-guard', type=str,
>> > +   help='If unset, then CPP_GUARD is derived from 
>> > OUTPUT.')
>
>> Admittedly --output should be enough for everyone, but I'm not sure
>> what issues you're getting with Android-IA.
>
> I didn't have any issues. I added the --cpp-guard option because it
> allowed me to re-use the same idiom in Android.genxml.mk used by the
> other generated headers. That is, the --cpp-guard option allowed me to
> re-use the Makefile's `header-gen` function instead of adding a custom
> rule just for genX_bits.h.
>
I see, quite an honourable idea.

[Mesa-dev] [Bug 100424] X hang (in kernel) after some event in Serious Sam Fusion using radv. 4.9/and-staging-4.9

[bugzilla-daemon]

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

--- Comment #3 from Darren Salt  ---
Happening with 4.11-rc4; essentially the same backtrace. I'll try bumping llvm
next (probably to 4.0~svn294803), although I expect little difference.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 100424] X hang (in kernel) after some event in Serious Sam Fusion using radv. 4.9/amd-staging-4.9

[bugzilla-daemon]

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

Darren Salt  changed:

   What|Removed |Added

Summary|X hang (in kernel) after|X hang (in kernel) after
   |some event in Serious Sam   |some event in Serious Sam
   |Fusion using radv.  |Fusion using radv.
   |4.9/and-staging-4.9 |4.9/amd-staging-4.9

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] anv/batch_chain: Handle another OOM in cmd_buffer_execbuf

[Jason Ekstrand]

Found by inspection while rebasing other patches.
---
 src/intel/vulkan/anv_batch_chain.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_batch_chain.c 
b/src/intel/vulkan/anv_batch_chain.c
index 5d7abc6..5a6c0ba 100644
--- a/src/intel/vulkan/anv_batch_chain.c
+++ b/src/intel/vulkan/anv_batch_chain.c
@@ -1277,8 +1277,10 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
   adjust_relocations_to_state_pool(ss_pool, &(*bbo)->bo, &(*bbo)->relocs,
cmd_buffer->last_ss_pool_center);
 
-  anv_execbuf_add_bo(, &(*bbo)->bo, &(*bbo)->relocs,
- _buffer->pool->alloc);
+  result = anv_execbuf_add_bo(, &(*bbo)->bo, &(*bbo)->relocs,
+  _buffer->pool->alloc);
+  if (result != VK_SUCCESS)
+ return result;
}
 
/* Now that we've adjusted all of the surface state relocations, we need to
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH v2 01/10] swr: [rasterizer codegen] Refactor codegen

[Emil Velikov]

Hi Tim,

On 27 March 2017 at 17:17, Tim Rowley  wrote:
> Move common codegen functions into gen_common.py.
>
> v2: change gen_knobs.py to find the template file internally, like
> the rest of the gen scripts.
Hard-coding file names and location inside generator scripts is bad
idea. I'd kindly urge you to avoid that.
That said, not my driver - not my call :-\

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 100438] glsl/ir.cpp:1376: ir_dereference_variable::ir_dereference_variable(ir_variable*): Assertion `var != NULL' failed.

[bugzilla-daemon]

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

--- Comment #1 from Timothy Arceri  ---
(In reply to Vinson Lee from comment #0)
> mesa: 7ee91af30074a4381e4353122319e3b4b3fe7cbd (master 17.1.0-devel)
> 
> This GLSL shader triggers an assert.
> 
> void main()
> {
>   a[b](c);
> }
> 
> 

Can you send as a piglit test if this is not happening in piglit currently?

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

[Mesa-dev] [PATCH v2 3/6] radv: Implement sparse image creation.

[Bas Nieuwenhuizen]

Signed-off-by: Bas Nieuwenhuizen 
---
 src/amd/vulkan/radv_image.c   | 23 +--
 src/amd/vulkan/radv_private.h |  1 +
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index dfd70a9eab8..3997e81acc1 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -636,6 +636,7 @@ radv_image_create(VkDevice _device,
image->samples = pCreateInfo->samples;
image->tiling = pCreateInfo->tiling;
image->usage = pCreateInfo->usage;
+   image->flags = pCreateInfo->flags;
 
image->exclusive = pCreateInfo->sharingMode == 
VK_SHARING_MODE_EXCLUSIVE;
if (pCreateInfo->sharingMode == VK_SHARING_MODE_CONCURRENT) {
@@ -676,6 +677,20 @@ radv_image_create(VkDevice _device,
image->surface.level[0].pitch_bytes = create_info->stride;
image->surface.level[0].slice_size = create_info->stride * 
image->surface.level[0].nblk_y;
}
+
+   if (pCreateInfo->flags & VK_IMAGE_CREATE_SPARSE_BINDING_BIT) {
+   image->alignment = MAX2(image->alignment, 4096);
+   image->size = align64(image->size, image->alignment);
+   image->offset = 0;
+
+   image->bo = device->ws->buffer_create(device->ws, image->size, 
image->alignment,
+ 0, RADEON_FLAG_VIRTUAL);
+   if (!image->bo) {
+   vk_free2(>alloc, alloc, image);
+   return vk_error(VK_ERROR_OUT_OF_DEVICE_MEMORY);
+   }
+   }
+
*pImage = radv_image_to_handle(image);
 
return VK_SUCCESS;
@@ -872,11 +887,15 @@ radv_DestroyImage(VkDevice _device, VkImage _image,
  const VkAllocationCallbacks *pAllocator)
 {
RADV_FROM_HANDLE(radv_device, device, _device);
+   RADV_FROM_HANDLE(radv_image, image, _image);
 
-   if (!_image)
+   if (!image)
return;
 
-   vk_free2(>alloc, pAllocator, radv_image_from_handle(_image));
+   if (image->flags & VK_IMAGE_CREATE_SPARSE_BINDING_BIT)
+   device->ws->buffer_destroy(image->bo);
+
+   vk_free2(>alloc, pAllocator, image);
 }
 
 void radv_GetImageSubresourceLayout(
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index c5b00f29f1f..31e08287c9c 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1070,6 +1070,7 @@ struct radv_image {
uint32_t samples; /**< VkImageCreateInfo::samples */
VkImageUsageFlags usage; /**< Superset of VkImageCreateInfo::usage. */
VkImageTiling tiling; /** VkImageCreateInfo::tiling */
+   VkImageCreateFlags flags; /** VkImageCreateInfo::flags */
 
VkDeviceSize size;
uint32_t alignment;
-- 
2.12.1

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

[Mesa-dev] [PATCH v2 4/6] radv: Implement sparse memory binding.

[Bas Nieuwenhuizen]

v2: Only submit when semaphores are specified.

Signed-off-by: Bas Nieuwenhuizen 
---
 src/amd/vulkan/radv_device.c | 84 +---
 1 file changed, 80 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index adcc63a8172..d10d420c3cf 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1959,13 +1959,89 @@ VkResult radv_BindImageMemory(
return VK_SUCCESS;
 }
 
-VkResult radv_QueueBindSparse(
-   VkQueue queue,
+
+static void
+radv_sparse_buffer_bind_memory(struct radv_device *device,
+   const VkSparseBufferMemoryBindInfo *bind)
+{
+   RADV_FROM_HANDLE(radv_buffer, buffer, bind->buffer);
+
+   for (uint32_t i = 0; i < bind->bindCount; ++i) {
+   struct radv_device_memory *mem = NULL;
+
+   if (bind->pBinds[i].memory != VK_NULL_HANDLE)
+   mem = 
radv_device_memory_from_handle(bind->pBinds[i].memory);
+
+   device->ws->buffer_virtual_bind(buffer->bo,
+   bind->pBinds[i].resourceOffset,
+   bind->pBinds[i].size,
+   mem ? mem->bo : NULL,
+   bind->pBinds[i].memoryOffset);
+   }
+}
+
+static void
+radv_sparse_image_opaque_bind_memory(struct radv_device *device,
+ const VkSparseImageOpaqueMemoryBindInfo 
*bind)
+{
+   RADV_FROM_HANDLE(radv_image, image, bind->image);
+
+   for (uint32_t i = 0; i < bind->bindCount; ++i) {
+   struct radv_device_memory *mem = NULL;
+
+   if (bind->pBinds[i].memory != VK_NULL_HANDLE)
+   mem = 
radv_device_memory_from_handle(bind->pBinds[i].memory);
+
+   device->ws->buffer_virtual_bind(image->bo,
+   bind->pBinds[i].resourceOffset,
+   bind->pBinds[i].size,
+   mem ? mem->bo : NULL,
+   bind->pBinds[i].memoryOffset);
+   }
+}
+
+ VkResult radv_QueueBindSparse(
+   VkQueue _queue,
uint32_tbindInfoCount,
const VkBindSparseInfo* pBindInfo,
-   VkFence fence)
+   VkFence _fence)
 {
-   stub_return(VK_ERROR_INCOMPATIBLE_DRIVER);
+   RADV_FROM_HANDLE(radv_fence, fence, _fence);
+   RADV_FROM_HANDLE(radv_queue, queue, _queue);
+   struct radeon_winsys_fence *base_fence = fence ? fence->fence : NULL;
+   bool fence_emitted = false;
+
+   for (uint32_t i = 0; i < bindInfoCount; ++i) {
+   for (uint32_t j = 0; j < pBindInfo[i].bufferBindCount; ++j) {
+   radv_sparse_buffer_bind_memory(queue->device,
+  
pBindInfo[i].pBufferBinds + j);
+   }
+
+   for (uint32_t j = 0; j < pBindInfo[i].imageOpaqueBindCount; 
++j) {
+   radv_sparse_image_opaque_bind_memory(queue->device,
+
pBindInfo[i].pImageOpaqueBinds + j);
+   }
+
+   if (pBindInfo[i].waitSemaphoreCount || 
pBindInfo[i].signalSemaphoreCount) {
+   queue->device->ws->cs_submit(queue->hw_ctx, 
queue->queue_idx,
+
>device->empty_cs[queue->queue_family_index],
+1, NULL, NULL,
+(struct radeon_winsys_sem 
**)pBindInfo[i].pWaitSemaphores,
+
pBindInfo[i].waitSemaphoreCount,
+(struct radeon_winsys_sem 
**)pBindInfo[i].pSignalSemaphores,
+
pBindInfo[i].signalSemaphoreCount,
+false, base_fence);
+   fence_emitted = true;
+   if (fence)
+   fence->submitted = true;
+   }
+   }
+
+   if (fence && !fence_emitted) {
+   fence->signalled = true;
+   }
+
+   return VK_SUCCESS;
 }
 
 VkResult radv_CreateFence(
-- 
2.12.1

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

[Mesa-dev] [PATCH v2 6/6] radv: Enable sparseBinding feature.

[Bas Nieuwenhuizen]

Signed-off-by: Bas Nieuwenhuizen 
---
 src/amd/vulkan/radv_device.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index d10d420c3cf..64970bd1b3a 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -489,6 +489,7 @@ void radv_GetPhysicalDeviceFeatures(
.shaderFloat64= true,
.shaderInt64  = false,
.shaderInt16  = false,
+   .sparseBinding= true,
.variableMultisampleRate  = false,
.inheritedQueries = false,
};
@@ -542,7 +543,7 @@ void radv_GetPhysicalDeviceProperties(
.maxMemoryAllocationCount = UINT32_MAX,
.maxSamplerAllocationCount= 64 * 1024,
.bufferImageGranularity   = 64, /* A cache line 
*/
-   .sparseAddressSpaceSize   = 0,
+   .sparseAddressSpaceSize   = 0xu, /* 
buffer max size */
.maxBoundDescriptorSets   = MAX_SETS,
.maxPerStageDescriptorSamplers= 64,
.maxPerStageDescriptorUniformBuffers  = 64,
@@ -687,8 +688,9 @@ static void 
radv_get_physical_device_queue_family_properties(
if (*pCount >= 1) {
*pQueueFamilyProperties[idx] = (VkQueueFamilyProperties) {
.queueFlags = VK_QUEUE_GRAPHICS_BIT |
-   VK_QUEUE_COMPUTE_BIT |
-   VK_QUEUE_TRANSFER_BIT,
+ VK_QUEUE_COMPUTE_BIT |
+ VK_QUEUE_TRANSFER_BIT |
+ VK_QUEUE_SPARSE_BINDING_BIT,
.queueCount = 1,
.timestampValidBits = 64,
.minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
@@ -701,7 +703,9 @@ static void 
radv_get_physical_device_queue_family_properties(
!(pdevice->instance->debug_flags & RADV_DEBUG_NO_COMPUTE_QUEUE)) {
if (*pCount > idx) {
*pQueueFamilyProperties[idx] = 
(VkQueueFamilyProperties) {
-   .queueFlags = VK_QUEUE_COMPUTE_BIT | 
VK_QUEUE_TRANSFER_BIT,
+   .queueFlags = VK_QUEUE_COMPUTE_BIT |
+ VK_QUEUE_TRANSFER_BIT |
+ VK_QUEUE_SPARSE_BINDING_BIT,
.queueCount = pdevice->rad_info.compute_rings,
.timestampValidBits = 64,
.minImageTransferGranularity = (VkExtent3D) { 
1, 1, 1 },
-- 
2.12.1

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

[Mesa-dev] [PATCH v2 5/6] radv/amdgpu: Use reference counting for bos.

[Bas Nieuwenhuizen]

Per the Vulkan spec, memory objects may be deleted before the buffers
and images using them are deleted, although those resources then
cannot be used except for deletion themselves.

For the virtual buffers, we need to access them on resource destruction
to unmap the regions, so this results in a use-after-free. Implement
reference counting to avoid this.

Signed-off-by: Bas Nieuwenhuizen 
---
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 10 ++
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c 
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
index 8e78ef75233..7b679450cbc 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
@@ -34,6 +34,11 @@
 #include 
 #include 
 
+#include "util/u_atomic.h"
+
+
+static void radv_amdgpu_winsys_bo_destroy(struct radeon_winsys_bo *_bo);
+
 static void
 radv_amdgpu_winsys_virtual_map(struct radv_amdgpu_winsys_bo *bo,
const struct radv_amdgpu_map_range *range)
@@ -43,6 +48,7 @@ radv_amdgpu_winsys_virtual_map(struct radv_amdgpu_winsys_bo 
*bo,
if (!range->bo)
return; /* TODO: PRT mapping */
 
+   p_atomic_inc(>bo->ref_count);
int r = amdgpu_bo_va_op(range->bo->bo, range->bo_offset, range->size,
range->offset + bo->va, 0, AMDGPU_VA_OP_MAP);
if (r)
@@ -62,6 +68,7 @@ radv_amdgpu_winsys_virtual_unmap(struct radv_amdgpu_winsys_bo 
*bo,
range->offset + bo->va, 0, AMDGPU_VA_OP_UNMAP);
if (r)
abort();
+   radv_amdgpu_winsys_bo_destroy((struct radeon_winsys_bo *)range->bo);
 }
 
 static void
@@ -212,6 +219,8 @@ static void radv_amdgpu_winsys_bo_destroy(struct 
radeon_winsys_bo *_bo)
 {
struct radv_amdgpu_winsys_bo *bo = radv_amdgpu_winsys_bo(_bo);
 
+   if (p_atomic_dec_return(>ref_count))
+   return;
if (bo->is_virtual) {
for (uint32_t i = 0; i < bo->range_count; ++i) {
radv_amdgpu_winsys_virtual_unmap(bo, bo->ranges + i);
@@ -273,6 +282,7 @@ radv_amdgpu_winsys_bo_create(struct radeon_winsys *_ws,
bo->size = size;
bo->ws = ws;
bo->is_virtual = !!(flags & RADEON_FLAG_VIRTUAL);
+   bo->ref_count = 1;
 
if (flags & RADEON_FLAG_VIRTUAL) {
bo->ranges = realloc(NULL, sizeof(struct 
radv_amdgpu_map_range));
diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h 
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h
index c7d484bc8dd..4512e76b333 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h
@@ -45,6 +45,7 @@ struct radv_amdgpu_winsys_bo {
uint64_t size;
struct radv_amdgpu_winsys *ws;
bool is_virtual;
+   int ref_count;
 
union {
/* physical bo */
-- 
2.12.1

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

[Mesa-dev] [PATCH v2 1/6] radv/amdgpu: Add winsys implementation of virtual buffers.

[Bas Nieuwenhuizen]

v2: - Added comments.
- Fixed a double unmap bug.
- Actually unmap the non-edge old ranges.

Signed-off-by: Bas Nieuwenhuizen 
---
 src/amd/vulkan/radv_radeon_winsys.h   |   5 +
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 237 +++---
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h |  35 +++-
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c |  98 ++-
 4 files changed, 349 insertions(+), 26 deletions(-)

diff --git a/src/amd/vulkan/radv_radeon_winsys.h 
b/src/amd/vulkan/radv_radeon_winsys.h
index a8a1d2e369f..9f2430f75de 100644
--- a/src/amd/vulkan/radv_radeon_winsys.h
+++ b/src/amd/vulkan/radv_radeon_winsys.h
@@ -47,6 +47,7 @@ enum radeon_bo_flag { /* bitfield */
RADEON_FLAG_GTT_WC =(1 << 0),
RADEON_FLAG_CPU_ACCESS =(1 << 1),
RADEON_FLAG_NO_CPU_ACCESS = (1 << 2),
+   RADEON_FLAG_VIRTUAL =   (1 << 3)
 };
 
 enum radeon_bo_usage { /* bitfield */
@@ -289,6 +290,10 @@ struct radeon_winsys {
 
void (*buffer_set_metadata)(struct radeon_winsys_bo *bo,
struct radeon_bo_metadata *md);
+
+   void (*buffer_virtual_bind)(struct radeon_winsys_bo *parent,
+   uint64_t offset, uint64_t size,
+   struct radeon_winsys_bo *bo, uint64_t 
bo_offset);
struct radeon_winsys_ctx *(*ctx_create)(struct radeon_winsys *ws);
void (*ctx_destroy)(struct radeon_winsys_ctx *ctx);
 
diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c 
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
index 7f7fc7ac1ad..8e78ef75233 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
@@ -34,19 +34,201 @@
 #include 
 #include 
 
+static void
+radv_amdgpu_winsys_virtual_map(struct radv_amdgpu_winsys_bo *bo,
+   const struct radv_amdgpu_map_range *range)
+{
+   assert(range->size);
+
+   if (!range->bo)
+   return; /* TODO: PRT mapping */
+
+   int r = amdgpu_bo_va_op(range->bo->bo, range->bo_offset, range->size,
+   range->offset + bo->va, 0, AMDGPU_VA_OP_MAP);
+   if (r)
+   abort();
+}
+
+static void
+radv_amdgpu_winsys_virtual_unmap(struct radv_amdgpu_winsys_bo *bo,
+ const struct radv_amdgpu_map_range *range)
+{
+   assert(range->size);
+
+   if (!range->bo)
+   return; /* TODO: PRT mapping */
+
+   int r = amdgpu_bo_va_op(range->bo->bo, range->bo_offset, range->size,
+   range->offset + bo->va, 0, AMDGPU_VA_OP_UNMAP);
+   if (r)
+   abort();
+}
+
+static void
+radv_amdgpu_winsys_rebuild_bo_list(struct radv_amdgpu_winsys_bo *bo)
+{
+   bo->bo_count = 0;
+   for (uint32_t i = 0; i < bo->range_count; ++i) {
+   bool found = false;
+   if (!bo->ranges[i].bo)
+   continue;
+
+   for(uint32_t j = 0; j <  bo->bo_count; ++j) {
+   if (bo->bos[j] == bo->ranges[i].bo) {
+   found = true;
+   break;
+   }
+   }
+
+   if (!found) {
+   if (bo->bo_capacity == bo->bo_count) {
+   bo->bos = realloc(bo->bos,
+ (bo->bo_capacity + 1) * 
sizeof(struct radv_amdgpu_bo *));
+   ++bo->bo_capacity;
+   }
+   bo->bos[bo->bo_count++] = bo->ranges[i].bo;
+   }
+   }
+}
+
+static void
+radv_amdgpu_winsys_bo_virtual_bind(struct radeon_winsys_bo *_parent,
+   uint64_t offset, uint64_t size,
+   struct radeon_winsys_bo *_bo, uint64_t 
bo_offset)
+{
+   struct radv_amdgpu_winsys_bo *parent = (struct radv_amdgpu_winsys_bo 
*)_parent;
+   struct radv_amdgpu_winsys_bo *bo = (struct radv_amdgpu_winsys_bo*)_bo;
+   int range_count_delta, new_idx;
+   int first = 0, last;
+   struct radv_amdgpu_map_range new_first, new_last;
+
+   assert(parent->is_virtual);
+   assert(!bo || !bo->is_virtual);
+
+   if (!size)
+   return;
+
+   /* We have at most 2 new ranges (1 by the bind, and another one by 
splitting a range that contains the newly bound range). */
+   if (parent->range_capacity - parent->range_count < 2) {
+   parent->range_capacity += 2;
+   parent->ranges = realloc(parent->ranges,
+parent->range_capacity * sizeof(struct 
radv_amdgpu_map_range));
+   }
+
+   /*
+* [first, last] is exactly the range of ranges that either overlap the
+* new parent, or are adjacent to it. This corresponds to the bind 
ranges
+* that may change.
+*/

[Mesa-dev] [PATCH v2 0/6] radv sparseBinding

[Bas Nieuwenhuizen]

This series introduces the sparseBinding capability to radv.

I've mostly rebased & clarified the core remapping algorithm in patch 1,
as well as fixed some bugs that I found.

No regressions on CTS, all new non-skipping tests (~400) pass.

Bas Nieuwenhuizen (6):
  radv/amdgpu: Add winsys implementation of virtual buffers.
  radv: Implement sparse buffer creation.
  radv: Implement sparse image creation.
  radv: Implement sparse memory binding.
  radv/amdgpu: Use reference counting for bos.
  radv: Enable sparseBinding feature.

 src/amd/vulkan/radv_device.c  | 118 ++--
 src/amd/vulkan/radv_image.c   |  23 ++-
 src/amd/vulkan/radv_private.h |   2 +
 src/amd/vulkan/radv_radeon_winsys.h   |   5 +
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 247 --
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h |  36 +++-
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c |  98 +-
 7 files changed, 491 insertions(+), 38 deletions(-)

-- 
2.12.1

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

[Mesa-dev] [PATCH v2 2/6] radv: Implement sparse buffer creation.

[Bas Nieuwenhuizen]

Signed-off-by: Bas Nieuwenhuizen 
---
 src/amd/vulkan/radv_device.c  | 22 --
 src/amd/vulkan/radv_private.h |  1 +
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index dcef1da7e3c..adcc63a8172 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1881,8 +1881,12 @@ void radv_GetBufferMemoryRequirements(
 
pMemoryRequirements->memoryTypeBits = (1u << RADV_MEM_TYPE_COUNT) - 1;
 
-   pMemoryRequirements->size = buffer->size;
-   pMemoryRequirements->alignment = 16;
+   if (buffer->flags & VK_BUFFER_CREATE_SPARSE_BINDING_BIT)
+   pMemoryRequirements->alignment = 4096;
+   else
+   pMemoryRequirements->alignment = 16;
+
+   pMemoryRequirements->size = align64(buffer->size, 
pMemoryRequirements->alignment);
 }
 
 void radv_GetImageMemoryRequirements(
@@ -2208,6 +2212,17 @@ VkResult radv_CreateBuffer(
buffer->usage = pCreateInfo->usage;
buffer->bo = NULL;
buffer->offset = 0;
+   buffer->flags = pCreateInfo->flags;
+
+   if (pCreateInfo->flags & VK_BUFFER_CREATE_SPARSE_BINDING_BIT) {
+   buffer->bo = device->ws->buffer_create(device->ws,
+  align64(buffer->size, 
4096),
+  4096, 0, 
RADEON_FLAG_VIRTUAL);
+   if (!buffer->bo) {
+   vk_free2(>alloc, pAllocator, buffer);
+   return vk_error(VK_ERROR_OUT_OF_DEVICE_MEMORY);
+   }
+   }
 
*pBuffer = radv_buffer_to_handle(buffer);
 
@@ -2225,6 +2240,9 @@ void radv_DestroyBuffer(
if (!buffer)
return;
 
+   if (buffer->flags & VK_BUFFER_CREATE_SPARSE_BINDING_BIT)
+   device->ws->buffer_destroy(buffer->bo);
+
vk_free2(>alloc, pAllocator, buffer);
 }
 
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index f587ee3ffd8..c5b00f29f1f 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -557,6 +557,7 @@ struct radv_buffer {
VkDeviceSize size;
 
VkBufferUsageFlags   usage;
+   VkBufferCreateFlags  flags;
 
/* Set when bound */
struct radeon_winsys_bo *  bo;
-- 
2.12.1

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

Re: [Mesa-dev] [PATCH 2/3] anv: Flush caches prior to PIPELINE_SELECT on all gens

[Jason Ekstrand]

On Tue, Mar 28, 2017 at 7:07 AM, Emil Velikov 
wrote:

> Hi all,
>
> On 15 March 2017 at 18:58, Jason Ekstrand  wrote:
> > The programming note that says we need to do this still exists in the
> > SkyLake PRM and, from looking at the bspec, seems to apply to all
> > hardware generations SNB+.  Also, this seems to be the cause of some of
> > the GPU hangs we've been seeing in GL with the "Car Chase" benchmark.
> >
> > Reported-by: Topi Pohjolainen 
> > Cc: "17.0 13.0" 
> > ---
> >  src/intel/vulkan/genX_cmd_buffer.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> > index 2e95b98..a23fcba 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -2040,8 +2040,8 @@ flush_pipeline_before_pipeline_select(struct
> anv_cmd_buffer *cmd_buffer,
> >  */
> > if (pipeline == GPGPU)
> >anv_batch_emit(_buffer->batch, GENX(3DSTATE_CC_STATE_POINTERS),
> t);
> > +#endif
> >
> > -#elif GEN_GEN <= 7
> > /* From "BXML » GT » MI » vol1a GPU Overview » [Instruction]
> >  * PIPELINE_SELECT [DevBWR+]":
> >  *
> > @@ -2067,7 +2067,6 @@ flush_pipeline_before_pipeline_select(struct
> anv_cmd_buffer *cmd_buffer,
> >pc.InstructionCacheInvalidateEnable = true;
> >pc.PostSyncOperation= NoWrite;
> > }
> > -#endif
>
> Seems like this patch has fallen through the cracks, right ?
>

Yes it did.  Thanks!  I just pushed it (with a better commit message)

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

Re: [Mesa-dev] [PATCH v2 04/18] util/vk: Add helpers for finding an extension struct

[Chad Versace]

Already upstream.

On Mon 13 Mar 2017, Jason Ekstrand wrote:
> ---
>  src/util/vk_util.h | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/src/util/vk_util.h b/src/util/vk_util.h
> index e0b5d0b..0b9cb47 100644
> --- a/src/util/vk_util.h
> +++ b/src/util/vk_util.h
> @@ -40,4 +40,21 @@ struct vk_struct_common {
> for (const struct vk_struct_common *__iter = (const struct 
> vk_struct_common *)(__start); \
>  __iter; __iter = __iter->pNext)
>  
> +static inline void *
> +__vk_find_struct(void *start, VkStructureType sType)
> +{
> +   vk_foreach_struct(s, start) {
> +  if (s->sType == sType)
> + return s;
> +   }
> +
> +   return NULL;
> +}
> +
> +#define vk_find_struct(__start, __sType) \
> +   __vk_find_struct((__start), VK_STRUCTURE_TYPE_##__sType)
> +
> +#define vk_find_struct_const(__start, __sType) \
> +   (const void *)__vk_find_struct((void *)(__start), 
> VK_STRUCTURE_TYPE_##__sType)
> +
>  #endif /* VK_UTIL_H */
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 03/18] anv/physical_device: Rename uuid to pipeline_cache_uuid

[Chad Versace]

On Mon 13 Mar 2017, Jason Ekstrand wrote:
> We're about to have more UUIDs for different things so this one really
> needs to be properly labeled.
> ---
>  src/intel/vulkan/anv_device.c | 5 +++--
>  src/intel/vulkan/anv_pipeline_cache.c | 4 ++--
>  src/intel/vulkan/anv_private.h| 2 +-
>  3 files changed, 6 insertions(+), 5 deletions(-)

Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 02/18] anv: Refactor device_get_cache_uuid into physical_device_init_uuids

[Chad Versace]

On Mon 13 Mar 2017, Jason Ekstrand wrote:
> ---
>  src/intel/vulkan/anv_device.c | 31 +--
>  1 file changed, 17 insertions(+), 14 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 5db0a6c..13c1c50 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -53,30 +53,34 @@ compiler_perf_log(void *data, const char *fmt, ...)
> va_end(args);
>  }
>  



> unsigned build_id_len = build_id_length(note);
> -   if (build_id_len < 20) /* It should be a SHA-1 */
> -  return false;
> +   if (build_id_len < 20) {
> +  return vk_errorf(VK_ERROR_INITIALIZATION_FAILED,
> +   "build-id too short.  It needs to be a SHA");

In above line, s/SHA/SHA-1/, to distinguish from SHA-2 and SHA-3 

With that nit fixed,
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Timothy Arceri]

On 29/03/17 03:59, Emil Velikov wrote:

Hi Chad,

On 24 March 2017 at 20:44, Chad Versace  wrote:

On Tue 21 Mar 2017, Matt Turner wrote:

On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  wrote:

On 20 March 2017 at 18:30, Matt Turner  wrote:

On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  wrote:



These projects have been getting closer to upstream and "forcing" the
extra obstacle is effectively giving them the middle finger.


No. Requiring us to compile with a 10 year old GCC is giving a middle finger.


Can we stop with the GCC thing ? Can we point to a place where we want
to use feature A introduced with GCC B and we don't ?


Are you freaking serious?!

This happens *all* the time. It happened like two days ago with commit
28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
happened at least once in the previous month, and every month before
that.


More examples:

- Jason and I wanted to use C11 generic expressions (that's what the
  C11 spec calls them) in anvil, but old GCC => !C11.


[snip]


freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | 
vulkan/anv_device.c:697:4: error: initializer element is not constant
freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | 
.minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
freenode.#dri-devel.log-2017-03-16 11:07:23 | imirkin_ | anyone seen 
this? i'm on HEAD
freenode.#dri-devel.log-2017-03-16 11:13:50 | vsyrjala | yep. gcc-4.9 
strikes again?
freenode.#dri-devel.log-2017-03-16 11:14:54 | imirkin_ | i'm definitely 
using gcc-4.9
freenode.#dri-devel.log-2017-03-16 11:15:16 | vsyrjala | that 
'(VkExtent3D)' looks very much pointless there
freenode.#dri-devel.log-2017-03-16 11:15:56 | imirkin_ | 4.9.4 as it happens, 
which is the "stable" gcc on gentoo
freenode.#dri-devel.log:2017-03-16 11:18:04 | vsyrjala | looks like 
chadv broke it


As mentioned elsewhere - if major stakeholders of $driver want to bump
the requirement, please do.
As an example: st/nine requires GCC 4.6 and st/clover GCC 4.7 for a
very long time.


That seems fine for optional state trackers but seems like a bad idea to 
encourage that for major drivers. It's likely to lead to features being 
used in common code.


I'm not actually against this, just pointing out the obvious.

Hopefully VMWARE will migrate to something newer at some stage. That 
seems to be the major blocker at this point in time.


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

[Mesa-dev] [Bug 100438] glsl/ir.cpp:1376: ir_dereference_variable::ir_dereference_variable(ir_variable*): Assertion `var != NULL' failed.

[bugzilla-daemon]

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

Bug ID: 100438
   Summary: glsl/ir.cpp:1376:
ir_dereference_variable::ir_dereference_variable(ir_va
riable*): Assertion `var != NULL' failed.
   Product: Mesa
   Version: 11.1
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: bisected, regression
  Severity: normal
  Priority: medium
 Component: glsl-compiler
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: intel-3d-b...@lists.freedesktop.org
CC: airl...@freedesktop.org, t_arc...@yahoo.com.au

mesa: 7ee91af30074a4381e4353122319e3b4b3fe7cbd (master 17.1.0-devel)

This GLSL shader triggers an assert.

void main()
{
  a[b](c);
}


$ ./src/compiler/glsl_compiler --version 110 test.frag 
glsl_compiler: glsl/ir.cpp:1376:
ir_dereference_variable::ir_dereference_variable(ir_variable*): Assertion `var
!= NULL' failed.
Aborted (core dumped)

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#1  0x7f4f4e7363ea in __GI_abort () at abort.c:89
#2  0x7f4f4e72cbb7 in __assert_fail_base (fmt=,
assertion=assertion@entry=0x56396212559c "var != NULL",
file=file@entry=0x56396210d127 "glsl/ir.cpp", line=line@entry=1376, 
function=function@entry=0x56396210dfa0

"ir_dereference_variable::ir_dereference_variable(ir_variable*)") at
assert.c:92
#3  0x7f4f4e72cc62 in __GI___assert_fail
(assertion=assertion@entry=0x56396212559c "var != NULL",
file=file@entry=0x56396210d127 "glsl/ir.cpp", line=line@entry=1376, 
function=function@entry=0x56396210dfa0

"ir_dereference_variable::ir_dereference_variable(ir_variable*)") at
assert.c:101
#4  0x563962038087 in ir_dereference_variable::ir_dereference_variable
(var=0x0, this=) at glsl/ir.cpp:1376
#5  0x563962077f67 in ir_dereference_variable::ir_dereference_variable
(var=0x0, this=) at ../../src/compiler/glsl/list.h:58
#6  ir_dereference_array::ir_dereference_array (this=0x56396387c710, var=0x0,
array_index=0x56396387c530) at glsl/ir.cpp:1399
#7  0x563962101144 in generate_array_index
(mem_ctx=mem_ctx@entry=0x56396386cc40,
instructions=instructions@entry=0x56396387c4a0,
state=state@entry=0x56396386cc40, loc=..., array=,
idx=, function_name=function_name@entry=0x7ffdbdfbcf50, 
actual_parameters=0x7ffdbdfbcfc0) at glsl/ast_function.cpp:668
#8  0x5639621051eb in ast_function_expression::hir (this=0x56396386df68,
instructions=0x56396387c4a0, state=0x56396386cc40) at
glsl/ast_function.cpp:2191
#9  0x5639620c2273 in ast_expression_statement::hir (this=,
instructions=, state=) at
glsl/ast_to_hir.cpp:2201
#10 0x5639620c22cf in ast_compound_statement::hir (this=0x56396386e0d8,
instructions=0x56396387c4a0, state=0x56396386cc40) at glsl/ast_to_hir.cpp:2217
#11 0x5639620c8a6c in ast_function_definition::hir (this=0x56396386e138,
instructions=, state=0x56396386cc40) at glsl/ast_to_hir.cpp:5845
#12 0x5639620bee28 in _mesa_ast_to_hir (instructions=0x56396386e8b0,
state=state@entry=0x56396386cc40) at glsl/ast_to_hir.cpp:155
#13 0x56396206ff5f in _mesa_glsl_compile_shader
(ctx=ctx@entry=0x5639623687a0 ,
shader=shader@entry=0x56396386ad10, dump_ast=,
dump_hir=, force_recompile=force_recompile@entry=true)
at glsl/glsl_parser_extras.cpp:1984
#14 0x56396203c2cc in compile_shader (ctx=ctx@entry=0x5639623687a0
, shader=shader@entry=0x56396386ad10) at
glsl/standalone.cpp:385
#15 0x56396203c6fb in standalone_compile_shader (_options=,
num_files=, files=) at glsl/standalone.cpp:488
#16 0x563962038cdb in main (argc=, argv=0x7ffdbdfbd498) at
glsl/main.cpp:92
(gdb) frame 4
#4  0x563962038087 in ir_dereference_variable::ir_dereference_variable
(var=0x0, this=) at glsl/ir.cpp:1376
1376   assert(var != NULL);
(gdb) print var
$1 = (ir_variable *) 0x0


fd01840c0bd3b22d058a65a17ad30e3b45813b60 is the first bad commit
commit fd01840c0bd3b22d058a65a17ad30e3b45813b60
Author: Timothy Arceri 
Date:   Wed Aug 5 15:49:22 2015 +1000

glsl: add AoA support to subroutines

process_parameters() will now be called earlier because we need
actual_parameters processed earlier so we can use it with
match_subroutine_by_name() to get the subroutine variable, we need
to do this inside the recursive function generate_array_index() because
we can't create the ir_dereference_array() until we have gotten to the
outermost array.

For the remainder of the array dimensions the type doesn't matter so we
can just use the existing _mesa_ast_array_index_to_hir() function to
process the ast.

Reviewed-by: Dave Airlie 

:04 04 

[Mesa-dev] [PATCH v3] swr: [rasterizer codegen] Fix windows build

[George Kyriazis]

Fix codegen build break that was introduced earlier

v2: update rules for gen_knobs.cpp and gen_knobs.h

v3: Introduce bldroot and revert generator file changes, making patch simpler.
---
 src/gallium/drivers/swr/SConscript | 38 +++---
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/swr/SConscript 
b/src/gallium/drivers/swr/SConscript
index ad16162..18d6c9b 100644
--- a/src/gallium/drivers/swr/SConscript
+++ b/src/gallium/drivers/swr/SConscript
@@ -47,20 +47,25 @@ if not env['msvc'] :
 ])
 
 swrroot = '#src/gallium/drivers/swr/'
+bldroot = Dir('.').abspath
 
 env.CodeGenerate(
 target = 'rasterizer/codegen/gen_knobs.cpp',
 script = swrroot + 'rasterizer/codegen/gen_knobs.py',
-source = 'rasterizer/codegen/templates/gen_knobs.cpp',
-command = python_cmd + ' $SCRIPT --input $SOURCE --output $TARGET 
--gen_cpp'
+source = '',
+command = python_cmd + ' $SCRIPT --output $TARGET --gen_cpp'
 )
+Depends('rasterizer/codegen/gen_knobs.cpp',
+swrroot + 'rasterizer/codegen/templates/gen_knobs.cpp')
 
 env.CodeGenerate(
 target = 'rasterizer/codegen/gen_knobs.h',
 script = swrroot + 'rasterizer/codegen/gen_knobs.py',
-source = 'rasterizer/codegen/templates/gen_knobs.cpp',
-command = python_cmd + ' $SCRIPT --input $SOURCE --output $TARGET --gen_h'
+source = '',
+command = python_cmd + ' $SCRIPT --output $TARGET --gen_h'
 )
+Depends('rasterizer/codegen/gen_knobs.cpp',
+swrroot + 'rasterizer/codegen/templates/gen_knobs.cpp')
 
 env.CodeGenerate(
 target = 'rasterizer/jitter/gen_state_llvm.h',
@@ -68,20 +73,26 @@ env.CodeGenerate(
 source = 'rasterizer/core/state.h',
 command = python_cmd + ' $SCRIPT --input $SOURCE --output $TARGET'
 )
+Depends('rasterizer/jitter/gen_state_llvm.h',
+swrroot + 'rasterizer/codegen/templates/gen_llvm.hpp')
 
 env.CodeGenerate(
 target = 'rasterizer/jitter/gen_builder.hpp',
 script = swrroot + 'rasterizer/codegen/gen_llvm_ir_macros.py',
 source = os.path.join(llvm_includedir, 'llvm/IR/IRBuilder.h'),
-command = python_cmd + ' $SCRIPT --input $SOURCE --output 
rasterizer/jitter --gen_h'
+command = python_cmd + ' $SCRIPT --input $SOURCE --output ' + bldroot + 
'/rasterizer/jitter --gen_h'
 )
+Depends('rasterizer/jitter/gen_builder.hpp',
+swrroot + 'rasterizer/codegen/templates/gen_builder.hpp')
 
 env.CodeGenerate(
 target = 'rasterizer/jitter/gen_builder_x86.hpp',
 script = swrroot + 'rasterizer/codegen/gen_llvm_ir_macros.py',
 source = '',
-command = python_cmd + ' $SCRIPT --output rasterizer/jitter --gen_x86_h'
+command = python_cmd + ' $SCRIPT --output ' + bldroot + 
'/rasterizer/jitter --gen_x86_h'
 )
+Depends('rasterizer/jitter/gen_builder.hpp',
+swrroot + 'rasterizer/codegen/templates/gen_builder.hpp')
 
 env.CodeGenerate(
 target = './gen_swr_context_llvm.h',
@@ -89,6 +100,8 @@ env.CodeGenerate(
 source = 'swr_context.h',
 command = python_cmd + ' $SCRIPT --input $SOURCE --output $TARGET'
 )
+Depends('rasterizer/jitter/gen_state_llvm.h',
+swrroot + 'rasterizer/codegen/templates/gen_llvm.hpp')
 
 env.CodeGenerate(
 target = 'rasterizer/archrast/gen_ar_event.hpp',
@@ -96,6 +109,8 @@ env.CodeGenerate(
 source = 'rasterizer/archrast/events.proto',
 command = python_cmd + ' $SCRIPT --proto $SOURCE --output $TARGET 
--gen_event_h'
 )
+Depends('rasterizer/jitter/gen_state_llvm.h',
+swrroot + 'rasterizer/codegen/templates/gen_ar_event.hpp')
 
 env.CodeGenerate(
 target = 'rasterizer/archrast/gen_ar_event.cpp',
@@ -103,6 +118,8 @@ env.CodeGenerate(
 source = 'rasterizer/archrast/events.proto',
 command = python_cmd + ' $SCRIPT --proto $SOURCE --output $TARGET 
--gen_event_cpp'
 )
+Depends('rasterizer/jitter/gen_state_llvm.h',
+swrroot + 'rasterizer/codegen/templates/gen_ar_event.cpp')
 
 env.CodeGenerate(
 target = 'rasterizer/archrast/gen_ar_eventhandler.hpp',
@@ -110,6 +127,8 @@ env.CodeGenerate(
 source = 'rasterizer/archrast/events.proto',
 command = python_cmd + ' $SCRIPT --proto $SOURCE --output $TARGET 
--gen_eventhandler_h'
 )
+Depends('rasterizer/jitter/gen_state_llvm.h',
+swrroot + 'rasterizer/codegen/templates/gen_ar_eventhandler.hpp')
 
 env.CodeGenerate(
 target = 'rasterizer/archrast/gen_ar_eventhandlerfile.hpp',
@@ -117,6 +136,8 @@ env.CodeGenerate(
 source = 'rasterizer/archrast/events.proto',
 command = python_cmd + ' $SCRIPT --proto $SOURCE --output $TARGET 
--gen_eventhandlerfile_h'
 )
+Depends('rasterizer/jitter/gen_state_llvm.h',
+swrroot + 'rasterizer/codegen/templates/gen_ar_eventhandlerfile.hpp')
 
 # 5 SWR_MULTISAMPLE_TYPE_COUNT
 # 2 SWR_MSAA_SAMPLE_PATTERN_COUNT
@@ -127,8 +148,11 @@ env.CodeGenerate(
 env.CodeGenerate(
 target = 'rasterizer/core/gen_BackendPixelRate0.cpp',
 script = swrroot + 'rasterizer/codegen/gen_backends.py',
-command = python_cmd + 

[Mesa-dev] [PATCH 2/2] anv: Query the kernel for reset status

[Jason Ekstrand]

When a client causes a GPU hang (or experiences issues due to a hang in
another client) we want to let it know as soon as possible.  In
particular, if it submits work with a fence and calls vkWaitForFences or
vkQueueQaitIdle and it returns VK_SUCCESS, then the client should be
able to trust the results of that rendering.  In order to provide this
guarantee, we have to ask the kernel for context status in a few key
locations.
---
 src/intel/vulkan/anv_device.c  | 78 ++
 src/intel/vulkan/anv_gem.c | 18 ++
 src/intel/vulkan/anv_private.h |  3 ++
 src/intel/vulkan/genX_query.c  | 11 ++
 4 files changed, 72 insertions(+), 38 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 5f0d00f..33d1984 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -884,8 +884,6 @@ anv_device_submit_simple_batch(struct anv_device *device,
struct anv_bo bo, *exec_bos[1];
VkResult result = VK_SUCCESS;
uint32_t size;
-   int64_t timeout;
-   int ret;
 
/* Kernel driver requires 8 byte aligned batch length */
size = align_u32(batch->next - batch->start, 8);
@@ -925,14 +923,7 @@ anv_device_submit_simple_batch(struct anv_device *device,
if (result != VK_SUCCESS)
   goto fail;
 
-   timeout = INT64_MAX;
-   ret = anv_gem_wait(device, bo.gem_handle, );
-   if (ret != 0) {
-  /* We don't know the real error. */
-  device->lost = true;
-  result = vk_errorf(VK_ERROR_DEVICE_LOST, "execbuf2 failed: %m");
-  goto fail;
-   }
+   result = anv_device_wait(device, , INT64_MAX);
 
  fail:
anv_bo_pool_free(>batch_bo_pool, );
@@ -1264,6 +1255,28 @@ anv_device_execbuf(struct anv_device *device,
return VK_SUCCESS;
 }
 
+VkResult
+anv_device_wait(struct anv_device *device, struct anv_bo *bo,
+int64_t timeout)
+{
+   int ret = anv_gem_wait(device, bo->gem_handle, );
+   if (ret == -1 && errno == ETIME) {
+  return VK_TIMEOUT;
+   } else if (ret == -1) {
+  /* We don't know the real error. */
+  device->lost = true;
+  return vk_errorf(VK_ERROR_DEVICE_LOST, "gem wait failed: %m");
+   }
+
+   if (anv_gem_gpu_has_reset(device)) {
+  device->lost = true;
+  return vk_errorf(VK_ERROR_DEVICE_LOST,
+   "GPU has hung with commands in-flight");
+   }
+
+   return VK_SUCCESS;
+}
+
 VkResult anv_QueueSubmit(
 VkQueue _queue,
 uint32_tsubmitCount,
@@ -1273,8 +1286,13 @@ VkResult anv_QueueSubmit(
ANV_FROM_HANDLE(anv_queue, queue, _queue);
ANV_FROM_HANDLE(anv_fence, fence, _fence);
struct anv_device *device = queue->device;
-   if (unlikely(device->lost))
+
+   if (unlikely(device->lost)) {
   return VK_ERROR_DEVICE_LOST;
+   } else if (anv_gem_gpu_has_reset(device)) {
+  device->lost = true;
+  return vk_error(VK_ERROR_DEVICE_LOST);
+   }
 
VkResult result = VK_SUCCESS;
 
@@ -1802,9 +1820,6 @@ VkResult anv_GetFenceStatus(
if (unlikely(device->lost))
   return VK_ERROR_DEVICE_LOST;
 
-   int64_t t = 0;
-   int ret;
-
switch (fence->state) {
case ANV_FENCE_STATE_RESET:
   /* If it hasn't even been sent off to the GPU yet, it's not ready */
@@ -1814,15 +1829,18 @@ VkResult anv_GetFenceStatus(
   /* It's been signaled, return success */
   return VK_SUCCESS;
 
-   case ANV_FENCE_STATE_SUBMITTED:
-  /* It's been submitted to the GPU but we don't know if it's done yet. */
-  ret = anv_gem_wait(device, fence->bo.gem_handle, );
-  if (ret == 0) {
+   case ANV_FENCE_STATE_SUBMITTED: {
+  VkResult result = anv_device_wait(device, >bo, 0);
+  switch (result) {
+  case VK_SUCCESS:
  fence->state = ANV_FENCE_STATE_SIGNALED;
  return VK_SUCCESS;
-  } else {
+  case VK_TIMEOUT:
  return VK_NOT_READY;
+  default:
+ return result;
   }
+   }
default:
   unreachable("Invalid fence status");
}
@@ -1884,20 +1902,20 @@ VkResult anv_WaitForFences(
 /* These are the fences we really care about.  Go ahead and wait
  * on it until we hit a timeout.
  */
-ret = anv_gem_wait(device, fence->bo.gem_handle, );
-if (ret == -1 && errno == ETIME) {
-   result = VK_TIMEOUT;
-   goto done;
-} else if (ret == -1) {
-   /* We don't know the real error. */
-device->lost = true;
-   return vk_errorf(VK_ERROR_DEVICE_LOST, "gem wait failed: %m");
-} else {
+result = anv_device_wait(device, >bo, 0);
+switch (result) {
+case VK_SUCCESS:
fence->state = ANV_FENCE_STATE_SIGNALED;
signaled_fences = true;
if (!waitAll)
-  return VK_SUCCESS;
-   continue;
+  goto done;
+   break;

[Mesa-dev] [PATCH 1/2] anv: Check for device loss at the end of WaitForFences

[Jason Ekstrand]

It's possible that the device could have been lost while we were
waiting.  We should let the user know if this has happened.
---
 src/intel/vulkan/anv_device.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 4e4fa19..5f0d00f 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1853,6 +1853,7 @@ VkResult anv_WaitForFences(
 */
int64_t timeout = MIN2(_timeout, INT64_MAX);
 
+   VkResult result = VK_SUCCESS;
uint32_t pending_fences = fenceCount;
while (pending_fences) {
   pending_fences = 0;
@@ -1873,8 +1874,10 @@ VkResult anv_WaitForFences(
 /* This fence is not pending.  If waitAll isn't set, we can return
  * early.  Otherwise, we have to keep going.
  */
-if (!waitAll)
-   return VK_SUCCESS;
+if (!waitAll) {
+   result = VK_SUCCESS;
+   goto done;
+}
 continue;
 
  case ANV_FENCE_STATE_SUBMITTED:
@@ -1883,7 +1886,8 @@ VkResult anv_WaitForFences(
  */
 ret = anv_gem_wait(device, fence->bo.gem_handle, );
 if (ret == -1 && errno == ETIME) {
-   return VK_TIMEOUT;
+   result = VK_TIMEOUT;
+   goto done;
 } else if (ret == -1) {
/* We don't know the real error. */
 device->lost = true;
@@ -1946,7 +1950,8 @@ VkResult anv_WaitForFences(
 
 if (time_elapsed >= timeout) {
pthread_mutex_unlock(>mutex);
-   return VK_TIMEOUT;
+   result = VK_TIMEOUT;
+   goto done;
 }
 
 timeout -= time_elapsed;
@@ -1956,7 +1961,11 @@ VkResult anv_WaitForFences(
   }
}
 
-   return VK_SUCCESS;
+done:
+   if (unlikely(device->lost))
+  return VK_ERROR_DEVICE_LOST;
+
+   return result;
 }
 
 // Queue semaphore functions
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [Bug 100201] llvmpipe Windows scons build with MSVC toolchain and LLVM 4.0 fails

[bugzilla-daemon]

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

--- Comment #7 from Jose Fonseca  ---
The links errors are possibly due to Mesa and LLVM not being built exactly with
the same compiler as Mesa, no?

Or perhaps we need to update mesa/scons/llvm.py with a special case for LLVM
4.0 with additional libraries?


I installed all the MSVC components, but still haven't figured out how to repro
the build logs you attached.


At any rate, your xtime fix is on the right track.  So I tweaked a bit and
pushed it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)

[Dylan Baker]

Quoting Jose Fonseca (2017-03-28 13:45:57)
> On 28/03/17 21:32, Dylan Baker wrote:
> > Quoting Jose Fonseca (2017-03-28 09:19:48)
> >> On 28/03/17 00:12, Dylan Baker wrote:
> >>> Quoting Jose Fonseca (2017-03-27 09:58:59)
>  On 27/03/17 17:42, Dylan Baker wrote:
> > Quoting Jose Fonseca (2017-03-27 09:31:04)
> >> On 27/03/17 17:24, Dylan Baker wrote:
> >>> Quoting Jose Fonseca (2017-03-26 14:53:50)
>  I've pushed the branch to mesa/demos, so we can all collaborate 
>  without
>  wasting time crossporting patches between private branches.
> 
> https://cgit.freedesktop.org/mesa/demos/commit/?h=meson
> 
>  Unfortunately, I couldn't actually go very far until I hit a wall, as
>  you can see in the last commit message.
> 
> 
>  The issue is that Windows has no standard paths for dependencies
>  includes/libraries (like /usr/include or /usr/lib), nor standard tool
>  for dependencies (no pkgconfig).  But it seems that Meson presumes 
>  any
>  unknown dependency can be resolved with pkgconfig.
> 
> 
>  The question is: how do I tell Meson where the GLEW headers/library 
>  for
>  MinGW are supposed to be found?
> 
> 
>  I know one solution might be Meson Wraps.  Is that the only way?
> 
> 
>  CMake makes it very easy to do it (via Cache files as explained in my
>  commit message.)  Is there a way to achieve the same, perhaps via
>  cross_file properties or something like that?
> 
> 
>  Jose
> >>>
> >>> I think there are two ways you could solve this:
> >>>
> >>> Wraps are probably the most generically correct method; what I mean 
> >>> by that is
> >>> that a proper wrap would solve the problem for everyone, on every 
> >>> operating
> >>> system, forever.
> >>
> >> Yeah, that sounded a good solution, particularly for windows where's so
> >> much easier to just build the dependencies as a subproject rather than
> >> fetch dependencies from somewhere, since MSVC RT versions have to match
> >> and so.
> >>
> >>  > That said, I took a look at GLEW and it doesn't look like a
> >>> straightforward project to port to meson, since it uses a huge pile 
> >>> of gnu
> >>> makefiles for compilation, without any autoconf/cmake/etc. I still 
> >>> might take a
> >>> swing at it since I want to know how hard it would be to write a wrap 
> >>> file for
> >>> something like GLEW (and it would probably be a pretty useful project 
> >>> to wrap)
> >>> where a meson build system is likely never going to go upstream.
> >>
> >> BTW, regarding GLEW, some time ago I actually prototyped using GLAD
> >> instead of GLEW for mesademos:
> >>
> >>https://cgit.freedesktop.org/~jrfonseca/mesademos/log/?h=glad
> >>
> >> I find GLAD much nicer that GLEW: it's easier to build, it uses 
> >> upstream
> >> XML files, it supports EGL, and it's easy to bundle.
> >>
> >> Maybe we could migrate mesademos to GLAD as part of this work instead 
> >> of
> >> trying to get glew "mesonfied".
> >>
> >>> The other option I think you can use use is cross properties[1], 
> >>> which I believe
> >>> is the closest thing meson has to cmake's cache files.
> >>>
> >>> I've pushed a couple of commits, the last one implements the cross 
> >>> properties
> >>> idea, which gets the build farther, but then it can't find the glut 
> >>> headers,
> >>> and I don't understand why, since "cc.has_header('GL/glut')" returns 
> >>> true. I
> >>> still think that wraps are a better plan, but I'll have to spend some 
> >>> time today
> >>> working on a glew wrap.
> >>>
> >>> [1] https://github.com/mesonbuild/meson/wiki/Cross-compilation (at 
> >>> the bottom
> >>> under the heading "Custom Data")
> >>
> >> I'm running out of time today, but I'll try to take a look tomorrow.
> >>
> >> Jose
> >>
> >
> > I'd had a similar thought, but thought of libpeoxy? It supports the 
> > platforms we
> > want, and already has a meson build system that works for windows.
> 
>  I have no experience with libepoxy.  I know GLAD is really easy to
>  understand, use and integrate.  It's completly agnostic to toolkits like
>  GLUT/GLFW/etc doesn't try to alias equivalent entrypoints, or anything
>  smart like libepoxy.
> 
>  In particular I don't fully understand libepoxy behavior regarding
>  wglMakeCurrent is, and whether that will create problems with GLUT,
>  since GLUT will call wglMakeCurrent..
> 
> 
>  Jose
> >>>
> >>> Okay, I have libepoxy working for windows. I also got libepoxy working as 
> >>> a
> >>> subproject, but it 

[Mesa-dev] [Bug 100425] glGenFramebuffersEXT appears to be null on (some?) Mesa 12.0.6 systems

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |WONTFIX

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)

[Jose Fonseca]

On 28/03/17 21:32, Dylan Baker wrote:

Quoting Jose Fonseca (2017-03-28 09:19:48)

On 28/03/17 00:12, Dylan Baker wrote:

Quoting Jose Fonseca (2017-03-27 09:58:59)

On 27/03/17 17:42, Dylan Baker wrote:

Quoting Jose Fonseca (2017-03-27 09:31:04)

On 27/03/17 17:24, Dylan Baker wrote:

Quoting Jose Fonseca (2017-03-26 14:53:50)

I've pushed the branch to mesa/demos, so we can all collaborate without
wasting time crossporting patches between private branches.

   https://cgit.freedesktop.org/mesa/demos/commit/?h=meson

Unfortunately, I couldn't actually go very far until I hit a wall, as
you can see in the last commit message.


The issue is that Windows has no standard paths for dependencies
includes/libraries (like /usr/include or /usr/lib), nor standard tool
for dependencies (no pkgconfig).  But it seems that Meson presumes any
unknown dependency can be resolved with pkgconfig.


The question is: how do I tell Meson where the GLEW headers/library for
MinGW are supposed to be found?


I know one solution might be Meson Wraps.  Is that the only way?


CMake makes it very easy to do it (via Cache files as explained in my
commit message.)  Is there a way to achieve the same, perhaps via
cross_file properties or something like that?


Jose


I think there are two ways you could solve this:

Wraps are probably the most generically correct method; what I mean by that is
that a proper wrap would solve the problem for everyone, on every operating
system, forever.


Yeah, that sounded a good solution, particularly for windows where's so
much easier to just build the dependencies as a subproject rather than
fetch dependencies from somewhere, since MSVC RT versions have to match
and so.

 > That said, I took a look at GLEW and it doesn't look like a

straightforward project to port to meson, since it uses a huge pile of gnu
makefiles for compilation, without any autoconf/cmake/etc. I still might take a
swing at it since I want to know how hard it would be to write a wrap file for
something like GLEW (and it would probably be a pretty useful project to wrap)
where a meson build system is likely never going to go upstream.


BTW, regarding GLEW, some time ago I actually prototyped using GLAD
instead of GLEW for mesademos:

   https://cgit.freedesktop.org/~jrfonseca/mesademos/log/?h=glad

I find GLAD much nicer that GLEW: it's easier to build, it uses upstream
XML files, it supports EGL, and it's easy to bundle.

Maybe we could migrate mesademos to GLAD as part of this work instead of
trying to get glew "mesonfied".


The other option I think you can use use is cross properties[1], which I believe
is the closest thing meson has to cmake's cache files.

I've pushed a couple of commits, the last one implements the cross properties
idea, which gets the build farther, but then it can't find the glut headers,
and I don't understand why, since "cc.has_header('GL/glut')" returns true. I
still think that wraps are a better plan, but I'll have to spend some time today
working on a glew wrap.

[1] https://github.com/mesonbuild/meson/wiki/Cross-compilation (at the bottom
under the heading "Custom Data")


I'm running out of time today, but I'll try to take a look tomorrow.

Jose



I'd had a similar thought, but thought of libpeoxy? It supports the platforms we
want, and already has a meson build system that works for windows.


I have no experience with libepoxy.  I know GLAD is really easy to
understand, use and integrate.  It's completly agnostic to toolkits like
GLUT/GLFW/etc doesn't try to alias equivalent entrypoints, or anything
smart like libepoxy.

In particular I don't fully understand libepoxy behavior regarding
wglMakeCurrent is, and whether that will create problems with GLUT,
since GLUT will call wglMakeCurrent..


Jose


Okay, I have libepoxy working for windows. I also got libepoxy working as a
subproject, but it took a bit of hacking on their build system (there's
some things they're doing that make them non-subproject safe, I'll send patches
and work that out with them.

https://github.com/dcbaker/libepoxy.git fix-suproject


Thanks.

GLEW is not the only one case though.  There's also FREEGLUT.  So we
can't really avoid the problem of external windows binaries/subprojects.

So I've been thinking, and I suspect is better if first get things
working with binary GLEW / FREGLUT projects, then try the glew ->
libepoxy in a 2nd step, so there's less to take in to merge meson into
master.


Clone that repo into $mesa-demos-root/subprojects and things should just work,
or mostly work. I got epoxy compiling, but ran into some issues in the mingw glu
header.

Dylan


I'm pretty sure the problem with MinGW glu is the lack of windows.h.  We
need to do the same as CMakeLists.txt snippet quoted below.

I'm running out of time today, but I'll look into porting this over to
meson tomorrow if you don't beat me to it.

Jose



if (WIN32)
 # Nobody likes to include windows.h:
 # - Microsoft's GL/gl.h header 

[Mesa-dev] [PATCH] st: Add cubeMapFace parameter to st_finalize_texture.

[Michal Srb]

st_finalize_texture always accesses image at face 0, but it may not be set if 
we are working with cubemap that had other face set.

This fixes crash in piglit 
same-attachment-glFramebufferTexture2D-GL_DEPTH_STENCIL_ATTACHMENT.
---
Hi, this is my attempt to fix crash in piglit test 
same-attachment-glFramebufferTexture2D-GL_DEPTH_STENCIL_ATTACHMENT ran with 
LIBGL_ALWAYS_INDIRECT=1.
I am not sure if it is the right approach. From what I found online rendering 
into a face of a cube texture that doesn't have all faces set would be invalid, 
but the test passes with other drivers, so maybe it's ok.
This makes it pass with software rendering as well.

 src/gallium/state_trackers/dri/dri2.c| 2 +-
 src/mesa/state_tracker/st_atom_image.c   | 2 +-
 src/mesa/state_tracker/st_atom_texture.c | 2 +-
 src/mesa/state_tracker/st_cb_fbo.c   | 2 +-
 src/mesa/state_tracker/st_cb_texture.c   | 5 +++--
 src/mesa/state_tracker/st_cb_texture.h   | 3 ++-
 src/mesa/state_tracker/st_gen_mipmap.c   | 2 +-
 7 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index b50e096..ed6004f 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1808,7 +1808,7 @@ dri2_interop_export_object(__DRIcontext *_ctx,
  return MESA_GLINTEROP_INVALID_MIP_LEVEL;
   }
 
-  if (!st_finalize_texture(ctx, st->pipe, obj)) {
+  if (!st_finalize_texture(ctx, st->pipe, obj, 0)) {
  mtx_unlock(>Shared->Mutex);
  return MESA_GLINTEROP_OUT_OF_RESOURCES;
   }
diff --git a/src/mesa/state_tracker/st_atom_image.c 
b/src/mesa/state_tracker/st_atom_image.c
index 5dd2cd6..4101552 100644
--- a/src/mesa/state_tracker/st_atom_image.c
+++ b/src/mesa/state_tracker/st_atom_image.c
@@ -64,7 +64,7 @@ st_bind_images(struct st_context *st, struct gl_program *prog,
   struct pipe_image_view *img = [i];
 
   if (!_mesa_is_image_unit_valid(st->ctx, u) ||
-  !st_finalize_texture(st->ctx, st->pipe, u->TexObj) ||
+  !st_finalize_texture(st->ctx, st->pipe, u->TexObj, 0) ||
   !stObj->pt) {
  memset(img, 0, sizeof(*img));
  continue;
diff --git a/src/mesa/state_tracker/st_atom_texture.c 
b/src/mesa/state_tracker/st_atom_texture.c
index 92023e0..5b481ec 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -73,7 +73,7 @@ update_single_texture(struct st_context *st,
}
stObj = st_texture_object(texObj);
 
-   retval = st_finalize_texture(ctx, st->pipe, texObj);
+   retval = st_finalize_texture(ctx, st->pipe, texObj, 0);
if (!retval) {
   /* out of mem */
   return GL_FALSE;
diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
b/src/mesa/state_tracker/st_cb_fbo.c
index 78433bf..dce4239 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -488,7 +488,7 @@ st_render_texture(struct gl_context *ctx,
struct st_renderbuffer *strb = st_renderbuffer(rb);
struct pipe_resource *pt;
 
-   if (!st_finalize_texture(ctx, pipe, att->Texture))
+   if (!st_finalize_texture(ctx, pipe, att->Texture, att->CubeMapFace))
   return;
 
pt = st_get_texobj_resource(att->Texture);
diff --git a/src/mesa/state_tracker/st_cb_texture.c 
b/src/mesa/state_tracker/st_cb_texture.c
index bc6f108..1b486d7 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -2434,7 +2434,8 @@ copy_image_data_to_texture(struct st_context *st,
 GLboolean
 st_finalize_texture(struct gl_context *ctx,
struct pipe_context *pipe,
-   struct gl_texture_object *tObj)
+   struct gl_texture_object *tObj,
+   GLuint cubeMapFace)
 {
struct st_context *st = st_context(ctx);
struct st_texture_object *stObj = st_texture_object(tObj);
@@ -2478,7 +2479,7 @@ st_finalize_texture(struct gl_context *ctx,
 
}
 
-   firstImage = st_texture_image_const(_mesa_base_tex_image(>base));
+   firstImage = 
st_texture_image_const(stObj->base.Image[cubeMapFace][stObj->base.BaseLevel]);
assert(firstImage);
 
/* If both firstImage and stObj point to a texture which can contain
diff --git a/src/mesa/state_tracker/st_cb_texture.h 
b/src/mesa/state_tracker/st_cb_texture.h
index 415d59f..f647b16 100644
--- a/src/mesa/state_tracker/st_cb_texture.h
+++ b/src/mesa/state_tracker/st_cb_texture.h
@@ -47,7 +47,8 @@ st_get_blit_mask(GLenum srcFormat, GLenum dstFormat);
 extern GLboolean
 st_finalize_texture(struct gl_context *ctx,
struct pipe_context *pipe, 
-   struct gl_texture_object *tObj);
+   struct gl_texture_object *tObj,
+   GLuint cubeMapFace);
 
 
 extern void
diff --git a/src/mesa/state_tracker/st_gen_mipmap.c 
b/src/mesa/state_tracker/st_gen_mipmap.c
index 10af11e..16b914a 100644
--- a/src/mesa/state_tracker/st_gen_mipmap.c
+++ 

Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound

[gregory hainaut]

On Mon, 27 Mar 2017 16:10:32 +0200
Gregory Hainaut  wrote:

> Hello,
> 
> Sorry I was in vacation. I will update my patch with a hash map to
> trace buffer creation/destruction.
> 
> Cheers,
> Gregory
> 
> On 3/20/17, Nicolai Hähnle  wrote:
> > On 20.03.2017 14:33, Markus Wick wrote:
> >> Am 2017-03-20 14:21, schrieb Nicolai Hähnle:
> >>> On 17.03.2017 18:59, gregory hainaut wrote:
>  If the application is badly/strangely coded, glthread will make it
>  worst.
>  The solution ought to be either fix the app or don't use glthread.
> >>>
> >>> It would be nice if glthread could handle this properly, but I don't
> >>> currently see how.
> >>
> >> The dispatcher thread needs a map of all valid buffer objects. So we
> >> need to update such a map on all glGenBuffers/glDeleteBuffers calls. So
> >> the overhead will be the map lookup on all affected glBindBuffer calls.
> >
> > You're right. Ridiculous details of the OpenGL spec make this
> > interesting, actually, because Section 6.1 (Creating and Binding Buffer
> > Objects) of the OpenGL 4.5 (Compability Profile) spec says:
> >
> > "A buffer object is created by binding an unused name to a buffer
> > target. The binding is effected by calling
> >
> >  void BindBuffer( enum target, uint buffer );
> >
> > target must be one of the targets listed in table 6.1. If the buffer
> > object named buffer has not been previously bound, or has been deleted
> > since the last binding, the GL creates a new state vector, initialized
> > with a zero-sized memory buffer and comprising all the state and with
> > the same initial values listed in table 6.2."
> >
> > But this language is different from that for core profiles, where a call
> > to glGenBuffers is required. So in this case, the compatibility profile
> > spec is actually better for performance :/
> >
> > Cheers,
> > Nicolai
> >

Hello,

Actually I found another issue on this patch. A deleted buffer is unbound from 
the context.
So validity must be updated accordingly.

However I have a tricky question, I think that it is possible to share buffers
between multiple contexts. Do we want to support it with glthread ? If yes, it 
will
require either
* to duplicate the reference counting logic
* Or to use a synchronous delete and peep into the context to check if the 
buffer is still alive
* Or any better idea ^^

Cheers,
Gregory


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

Re: [Mesa-dev] [PATCH] gbm/dri: Flush after unmap

[Eric Anholt]

Thomas Hellstrom  writes:

> Drivers may queue dma operations on the context at unmap time so we need
> to flush to make sure the data gets to the bo. Ideally the application
> would take care of this, but since there appears to be no exported gbm
> flush functionality we need to explicitly flush at unmap time.
>
> This fixes a problem where kmscube on vmwgfx in rgba textured mode would
> render using an uninitialized texture rather than the intended
> rgba pattern.
>
> Signed-off-by: Thomas Hellstrom 
> ---
>  src/gbm/backends/dri/gbm_dri.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
> index ac7ede8..6c2244c 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -243,7 +243,7 @@ struct dri_extension_match {
>  };
>  
>  static struct dri_extension_match dri_core_extensions[] = {
> -   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
> +   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
> { __DRI_IMAGE, 1, offsetof(struct gbm_dri_device, image) },
> { __DRI2_FENCE, 1, offsetof(struct gbm_dri_device, fence), 1 },
> { __DRI2_INTEROP, 1, offsetof(struct gbm_dri_device, interop), 1 },
> @@ -992,6 +992,13 @@ gbm_dri_bo_unmap(struct gbm_bo *_bo, void *map_data)
>return;
>  
> dri->image->unmapImage(dri->context, bo->image, map_data);
> +
> +   /*
> +* Not all DRI drivers use direct maps. They may queue up DMA operations
> +* on the mapping context. Since there is no explicit gbm flush
> +* mechanism. We need to flush here.

With the following change:

s/mechanism. We/mechanism, we/

Reviewed-by: Eric Anholt 

Reminder for anyone else looking at this patch: The context being
flushed here isn't some main GL context made by the app, it's this
little dummy context that was created internally in gbm so that these
kinds of GPU transfers could be done for the image mapping functions.

> +*/
> +   dri->flush->flush_with_flags(dri->context, NULL, __DRI2_FLUSH_CONTEXT, 0);
>  }


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)

[Dylan Baker]

Quoting Jose Fonseca (2017-03-28 09:19:48)
> On 28/03/17 00:12, Dylan Baker wrote:
> > Quoting Jose Fonseca (2017-03-27 09:58:59)
> >> On 27/03/17 17:42, Dylan Baker wrote:
> >>> Quoting Jose Fonseca (2017-03-27 09:31:04)
>  On 27/03/17 17:24, Dylan Baker wrote:
> > Quoting Jose Fonseca (2017-03-26 14:53:50)
> >> I've pushed the branch to mesa/demos, so we can all collaborate without
> >> wasting time crossporting patches between private branches.
> >>
> >>https://cgit.freedesktop.org/mesa/demos/commit/?h=meson
> >>
> >> Unfortunately, I couldn't actually go very far until I hit a wall, as
> >> you can see in the last commit message.
> >>
> >>
> >> The issue is that Windows has no standard paths for dependencies
> >> includes/libraries (like /usr/include or /usr/lib), nor standard tool
> >> for dependencies (no pkgconfig).  But it seems that Meson presumes any
> >> unknown dependency can be resolved with pkgconfig.
> >>
> >>
> >> The question is: how do I tell Meson where the GLEW headers/library for
> >> MinGW are supposed to be found?
> >>
> >>
> >> I know one solution might be Meson Wraps.  Is that the only way?
> >>
> >>
> >> CMake makes it very easy to do it (via Cache files as explained in my
> >> commit message.)  Is there a way to achieve the same, perhaps via
> >> cross_file properties or something like that?
> >>
> >>
> >> Jose
> >
> > I think there are two ways you could solve this:
> >
> > Wraps are probably the most generically correct method; what I mean by 
> > that is
> > that a proper wrap would solve the problem for everyone, on every 
> > operating
> > system, forever.
> 
>  Yeah, that sounded a good solution, particularly for windows where's so
>  much easier to just build the dependencies as a subproject rather than
>  fetch dependencies from somewhere, since MSVC RT versions have to match
>  and so.
> 
>   > That said, I took a look at GLEW and it doesn't look like a
> > straightforward project to port to meson, since it uses a huge pile of 
> > gnu
> > makefiles for compilation, without any autoconf/cmake/etc. I still 
> > might take a
> > swing at it since I want to know how hard it would be to write a wrap 
> > file for
> > something like GLEW (and it would probably be a pretty useful project 
> > to wrap)
> > where a meson build system is likely never going to go upstream.
> 
>  BTW, regarding GLEW, some time ago I actually prototyped using GLAD
>  instead of GLEW for mesademos:
> 
> https://cgit.freedesktop.org/~jrfonseca/mesademos/log/?h=glad
> 
>  I find GLAD much nicer that GLEW: it's easier to build, it uses upstream
>  XML files, it supports EGL, and it's easy to bundle.
> 
>  Maybe we could migrate mesademos to GLAD as part of this work instead of
>  trying to get glew "mesonfied".
> 
> > The other option I think you can use use is cross properties[1], which 
> > I believe
> > is the closest thing meson has to cmake's cache files.
> >
> > I've pushed a couple of commits, the last one implements the cross 
> > properties
> > idea, which gets the build farther, but then it can't find the glut 
> > headers,
> > and I don't understand why, since "cc.has_header('GL/glut')" returns 
> > true. I
> > still think that wraps are a better plan, but I'll have to spend some 
> > time today
> > working on a glew wrap.
> >
> > [1] https://github.com/mesonbuild/meson/wiki/Cross-compilation (at the 
> > bottom
> > under the heading "Custom Data")
> 
>  I'm running out of time today, but I'll try to take a look tomorrow.
> 
>  Jose
> 
> >>>
> >>> I'd had a similar thought, but thought of libpeoxy? It supports the 
> >>> platforms we
> >>> want, and already has a meson build system that works for windows.
> >>
> >> I have no experience with libepoxy.  I know GLAD is really easy to
> >> understand, use and integrate.  It's completly agnostic to toolkits like
> >> GLUT/GLFW/etc doesn't try to alias equivalent entrypoints, or anything
> >> smart like libepoxy.
> >>
> >> In particular I don't fully understand libepoxy behavior regarding
> >> wglMakeCurrent is, and whether that will create problems with GLUT,
> >> since GLUT will call wglMakeCurrent..
> >>
> >>
> >> Jose
> >
> > Okay, I have libepoxy working for windows. I also got libepoxy working as a
> > subproject, but it took a bit of hacking on their build system (there's
> > some things they're doing that make them non-subproject safe, I'll send 
> > patches
> > and work that out with them.
> >
> > https://github.com/dcbaker/libepoxy.git fix-suproject
> 
> Thanks.
> 
> GLEW is not the only one case though.  There's also FREEGLUT.  So we 
> can't really avoid the problem of external 

[Mesa-dev] [PATCH] radv: Assert when setting 0 registers in a sequence.

[Bas Nieuwenhuizen]

To catch more of those hangs early.

Signed-off-by: Bas Nieuwenhuizen 
---
 src/amd/vulkan/radv_cs.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/amd/vulkan/radv_cs.h b/src/amd/vulkan/radv_cs.h
index 2c8935f3065..8fcdad9dbbd 100644
--- a/src/amd/vulkan/radv_cs.h
+++ b/src/amd/vulkan/radv_cs.h
@@ -43,6 +43,7 @@ static inline void radeon_set_config_reg_seq(struct 
radeon_winsys_cs *cs, unsign
 {
 assert(reg < R600_CONTEXT_REG_OFFSET);
 assert(cs->cdw + 2 + num <= cs->max_dw);
+   assert(num);
 radeon_emit(cs, PKT3(PKT3_SET_CONFIG_REG, num, 0));
 radeon_emit(cs, (reg - R600_CONFIG_REG_OFFSET) >> 2);
 }
@@ -57,6 +58,7 @@ static inline void radeon_set_context_reg_seq(struct 
radeon_winsys_cs *cs, unsig
 {
 assert(reg >= R600_CONTEXT_REG_OFFSET);
 assert(cs->cdw + 2 + num <= cs->max_dw);
+   assert(num);
 radeon_emit(cs, PKT3(PKT3_SET_CONTEXT_REG, num, 0));
 radeon_emit(cs, (reg - R600_CONTEXT_REG_OFFSET) >> 2);
 }
@@ -83,6 +85,7 @@ static inline void radeon_set_sh_reg_seq(struct 
radeon_winsys_cs *cs, unsigned r
 {
assert(reg >= SI_SH_REG_OFFSET && reg < SI_SH_REG_END);
assert(cs->cdw + 2 + num <= cs->max_dw);
+   assert(num);
radeon_emit(cs, PKT3(PKT3_SET_SH_REG, num, 0));
radeon_emit(cs, (reg - SI_SH_REG_OFFSET) >> 2);
 }
@@ -97,6 +100,7 @@ static inline void radeon_set_uconfig_reg_seq(struct 
radeon_winsys_cs *cs, unsig
 {
assert(reg >= CIK_UCONFIG_REG_OFFSET && reg < CIK_UCONFIG_REG_END);
assert(cs->cdw + 2 + num <= cs->max_dw);
+   assert(num);
radeon_emit(cs, PKT3(PKT3_SET_UCONFIG_REG, num, 0));
radeon_emit(cs, (reg - CIK_UCONFIG_REG_OFFSET) >> 2);
 }
-- 
2.12.1

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

Re: [Mesa-dev] [PATCH 10/11] etnaviv: add support for rb swap

[Christian Gmeiner]

Hi Lucas


2017-03-27 10:40 GMT+02:00 Lucas Stach :
> Am Sonntag, den 26.03.2017, 16:13 +0200 schrieb Christian Gmeiner:
>> If we render to rb swapped format we will create a shader variant doing
>> the involved swizzing in the pixel shader.
>>
>> Signed-off-by: Christian Gmeiner 
>> ---
>>  src/gallium/drivers/etnaviv/etnaviv_compiler.c | 17 
>> +
>>  src/gallium/drivers/etnaviv/etnaviv_compiler_cmdline.c |  8 
>>  src/gallium/drivers/etnaviv/etnaviv_context.c  |  7 +++
>>  src/gallium/drivers/etnaviv/etnaviv_shader.h   |  6 ++
>>  4 files changed, 38 insertions(+)
>>
>> diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c 
>> b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
>> index ce8a651..eafb511 100644
>> --- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
>> +++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
>> @@ -1910,6 +1910,22 @@ etna_compile_add_z_div_if_needed(struct etna_compile 
>> *c)
>> }
>>  }
>>
>> +static void
>> +etna_compile_frag_rb_swap(struct etna_compile *c)
>> +{
>> +   if (c->info.processor == PIPE_SHADER_FRAGMENT && c->key->frag_rb_swap) {
>> +  /* find color out */
>> +  struct etna_reg_desc *color_reg =
>> + find_decl_by_semantic(c, TGSI_FILE_OUTPUT, TGSI_SEMANTIC_COLOR, 0);
>> +
>> +  emit_inst(c, &(struct etna_inst) {
>> + .opcode = INST_OPCODE_MOV,
>> + .dst = etna_native_to_dst(color_reg->native, INST_COMPS_X | 
>> INST_COMPS_Y | INST_COMPS_Z | INST_COMPS_W),
>> + .src[2] = etna_native_to_src(color_reg->native, SWIZZLE(Z, Y, X, 
>> W)),
>> +  });
>> +   }
>> +}
>> +
>>  /** add a NOP to the shader if
>>   * a) the shader is empty
>>   * or
>> @@ -2412,6 +2428,7 @@ etna_compile_shader(struct etna_shader_variant *v)
>> /* pass 3: generate instructions */
>> etna_compile_pass_generate_code(c);
>> etna_compile_add_z_div_if_needed(c);
>> +   etna_compile_frag_rb_swap(c);
>> etna_compile_add_nop_if_needed(c);
>> etna_compile_fill_in_labels(c);
>>
>> diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler_cmdline.c 
>> b/src/gallium/drivers/etnaviv/etnaviv_compiler_cmdline.c
>> index 1fea2d1..bdaa78e 100644
>> --- a/src/gallium/drivers/etnaviv/etnaviv_compiler_cmdline.c
>> +++ b/src/gallium/drivers/etnaviv/etnaviv_compiler_cmdline.c
>> @@ -91,6 +91,7 @@ print_usage(void)
>>  {
>> printf("Usage: etnaviv_compiler [OPTIONS]... FILE\n");
>> printf("--verbose - verbose compiler/debug messages\n");
>> +   printf("--frag-rb-swap- swap rb in color output (FRAG)\n");
>> printf("--help- show this message\n");
>>  }
>>
>> @@ -121,6 +122,13 @@ main(int argc, char **argv)
>>   continue;
>>}
>>
>> +  if (!strcmp(argv[n], "--frag-rb-swap")) {
>> + debug_printf(" %s", argv[n]);
>> + key.frag_rb_swap = true;
>
> frag_rb_swap is of type unsigned so assigning a bool is at least
> confusing, even if it maps to the same thing in the end.
>

Me likes it that way but that is probably personal taste :)
If you can live with it I will keep it as-is - else I could do a
key.frag_rb_swap = 1 but yeah.

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/11] etnaviv: adopt shader-db output for variant support

[Christian Gmeiner]

Hi Lucas

2017-03-27 10:43 GMT+02:00 Lucas Stach :
> Am Sonntag, den 26.03.2017, 16:13 +0200 schrieb Christian Gmeiner:
>> Signed-off-by: Christian Gmeiner 
>
> s/adopt/adapt in the subject
>

Fixed locally.

> Reviewed-by: Lucas Stach 
>

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 07/11] etnaviv: add etna_shader_key and generate variants if needed

[Christian Gmeiner]

Hi Lucas

>> diff --git a/src/gallium/drivers/etnaviv/etnaviv_shader.h 
>> b/src/gallium/drivers/etnaviv/etnaviv_shader.h
>> index 9f26bef..b0d97a7 100644
>> --- a/src/gallium/drivers/etnaviv/etnaviv_shader.h
>> +++ b/src/gallium/drivers/etnaviv/etnaviv_shader.h
>> @@ -32,6 +32,21 @@
>>  struct etna_context;
>>  struct etna_shader_variant;
>>
>> +struct etna_shader_key
>> +{
>> +   union {
>> +  struct {
>> +  };
>> +  uint32_t global;
>> +   };
>> +};
>
> There should probably be an assert somewhere in the code, which checks
> that sizeof(struct etna_shader_key) <= sizeof(etna_shader_key.global),
> to avoid the key getting ambiguous by overflowing global size.
>

Makes sense - what about something like this:

diff --git a/src/gallium/drivers/etnaviv/etnaviv_shader.h
b/src/gallium/drivers/etnaviv/etnaviv_shader.h
index 2b8618f..121d581 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_shader.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_shader.h
@@ -50,6 +50,8 @@ struct etna_shader_key
 static inline bool
 etna_shader_key_equal(struct etna_shader_key *a, struct etna_shader_key *b)
 {
+   STATIC_ASSERT(sizeof(struct etna_shader_key) <= sizeof(a->global));
+
return a->global == b->global;
 }

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 07/25] trace: add resource_commit pass-through

[Marek Olšák]

Patches 6 & 7 return void, but patch 5 defines the return type as
bool. With those fixed, patches 5-7 are:

Reviewed-by: Marek Olšák 

Marek

On Tue, Mar 28, 2017 at 11:11 AM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> ---
>  src/gallium/drivers/trace/tr_context.c | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/src/gallium/drivers/trace/tr_context.c 
> b/src/gallium/drivers/trace/tr_context.c
> index 81c1a46..75a3748 100644
> --- a/src/gallium/drivers/trace/tr_context.c
> +++ b/src/gallium/drivers/trace/tr_context.c
> @@ -1621,20 +1621,39 @@ trace_context_memory_barrier(struct pipe_context 
> *_context,
> trace_dump_call_begin("pipe_context", "memory_barrier");
> trace_dump_arg(ptr, context);
> trace_dump_arg(uint, flags);
> trace_dump_call_end();
>
> context->memory_barrier(context, flags);
>  }
>
>
>  static void
> +trace_context_resource_commit(struct pipe_context *_context,
> +  struct pipe_resource *resource,
> +  unsigned level, struct pipe_box *box, bool 
> commit)
> +{
> +   struct trace_context *tr_context = trace_context(_context);
> +   struct pipe_context *context = tr_context->pipe;
> +
> +   trace_dump_call_begin("pipe_context", "resource_commit");
> +   trace_dump_arg(ptr, context);
> +   trace_dump_arg(ptr, resource);
> +   trace_dump_arg(uint, level);
> +   trace_dump_arg(box, box);
> +   trace_dump_arg(bool, commit);
> +   trace_dump_call_end();
> +
> +   context->resource_commit(context, resource, level, box, commit);
> +}
> +
> +static void
>  trace_context_set_tess_state(struct pipe_context *_context,
>   const float default_outer_level[4],
>   const float default_inner_level[2])
>  {
> struct trace_context *tr_context = trace_context(_context);
> struct pipe_context *context = tr_context->pipe;
>
> trace_dump_call_begin("pipe_context", "set_tess_state");
> trace_dump_arg(ptr, context);
> trace_dump_arg_array(float, default_outer_level, 4);
> @@ -1793,20 +1812,21 @@ trace_context_create(struct trace_screen *tr_scr,
> TR_CTX_INIT(blit);
> TR_CTX_INIT(flush_resource);
> TR_CTX_INIT(clear);
> TR_CTX_INIT(clear_render_target);
> TR_CTX_INIT(clear_depth_stencil);
> TR_CTX_INIT(clear_texture);
> TR_CTX_INIT(flush);
> TR_CTX_INIT(generate_mipmap);
> TR_CTX_INIT(texture_barrier);
> TR_CTX_INIT(memory_barrier);
> +   TR_CTX_INIT(resource_commit);
> TR_CTX_INIT(set_tess_state);
> TR_CTX_INIT(set_shader_buffers);
> TR_CTX_INIT(launch_grid);
> TR_CTX_INIT(set_shader_images);
>
> TR_CTX_INIT(transfer_map);
> TR_CTX_INIT(transfer_unmap);
> TR_CTX_INIT(transfer_flush_region);
> TR_CTX_INIT(buffer_subdata);
> TR_CTX_INIT(texture_subdata);
> --
> 2.9.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] mesa: load a user defined drirc file specified via an environment variable

[Edmondo Tommasina]

On Tue, Mar 28, 2017 at 9:31 PM, Eric Anholt  wrote:
> Edmondo Tommasina  writes:
>
>> On Mon, Mar 27, 2017 at 11:32 PM, Eric Anholt  wrote:
>>> Edmondo Tommasina  writes:
>>>
 On Mon, Mar 27, 2017 at 6:05 PM, Eric Anholt  wrote:
> Edmondo Tommasina  writes:
>
>> Define a new MESA_USER_DRIRC environment variable to load a customized
>> drirc file.
>>
>> When the variable is not defined, nothing changes and the ${HOME}/.drirc
>> file will be loaded.
>>
>> If the variable is set to a file, this file will be loaded instead of
>> the the ${HOME}/.drirc.
>>
>> Example: MESA_USER_DRIRC=~/glthread.drirc glxgears
>>
>> If the variable is set to nothing, it avoids to load the ${HOME}/.drirc
>> file.
>>
>> Example: MESA_USER_DRIRC= glxgears
>
> Could you extend the commit message to describe what problem is being
> solved?  Why wouldn't you just customize your .drirc, since it's in your
> homedir already?

 I've posted a second version of the patch, trying to better document the
 possible generic usage of the variable.

 My use: I don't have a ~/.drirc file since I prefer to have my desktop
 running with the default mesa setting (/etc/drirc). If the ~/.drirc file
 would exist, it would impact all the applications started with my
 user and not only the one I want to test. This is potentially a little
 problem being solved.

 For me it's useful when I test/benchmark something: I like to use
 prepared config file just for this kind of test, instead of passing
 a list of env variables.
>>>
>>> So you want to set this environment variable so you can avoid passing
>>> things as environment variables?  That doesn't seem like a strong enough
>>> justification for the patch, to me.
>>
>> Right. But well, this was the weakest justification of the three I've
>> given. Anyways, I agree :)
>>
>> Any opinion about the possibility to skip the load of ~/.drirc with
>> the variable? Could this be useful?
>
> I don't see why, if you want to not have a .drirc, you don't just delete
> .drirc.  Or, if you have some settings in .drirc you don't want, you
> don't just remove them.

OK, let's forget this patch then. It doesn't seem worthy enough.

Thanks
edmondo
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 05/25] gallium: add sparse buffer interface and capability

[Marek Olšák]

On Tue, Mar 28, 2017 at 11:11 AM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> TODO fill out caps in all drivers
>
> v2:
> - explain the resource_commit interface in more detail
> ---
>  src/gallium/docs/source/context.rst  | 25 +
>  src/gallium/docs/source/screen.rst   |  3 +++
>  src/gallium/include/pipe/p_context.h | 13 +
>  src/gallium/include/pipe/p_defines.h |  2 ++
>  4 files changed, 43 insertions(+)
>
> diff --git a/src/gallium/docs/source/context.rst 
> b/src/gallium/docs/source/context.rst
> index a053193..5949ff2 100644
> --- a/src/gallium/docs/source/context.rst
> +++ b/src/gallium/docs/source/context.rst
> @@ -611,20 +611,45 @@ for both regular textures as well as for framebuffers 
> read via FBFETCH.
>  .. _memory_barrier:
>
>  memory_barrier
>  %%%
>
>  This function flushes caches according to which of the PIPE_BARRIER_* flags
>  are set.
>
>
>
> +.. _resource_commit:
> +
> +resource_commit
> +%%%
> +
> +This function changes the commit state of a part of a sparse resource. Sparse
> +resources are created by setting the ``PIPE_RESOURCE_FLAG_SPARSE`` flag when
> +calling ``resource_create``. Initially, sparse resources only reserve a 
> virtual
> +memory region that is not backed by memory (i.e., it is uncommitted). The
> +``resource_commit`` function can be called to commit or uncommit parts (or 
> all)
> +of a resource. The driver manages the underlying backing memory.
> +
> +The contents of newly committed memory regions are undefined. Calling this
> +function to commit an already committed memory region is allowed and leaves 
> its
> +content unchanged. Similarly, calling this function to uncommit an already
> +uncommitted memory region is allowed.
> +
> +For buffers, the given box must be aligned to multiples of
> +``PIPE_CAP_SPARSE_BUFFER_PAGE_SIZE``. As an exception to this rule, if the 
> size
> +of the buffer is not a multiple of the page size, changing the commit state 
> of
> +the last (partial) page requires a box that ends at the end of the buffer
> +(i.e., box->x + box->width == buffer->width0).
> +
> +
> +
>  .. _pipe_transfer:
>
>  PIPE_TRANSFER
>  ^
>
>  These flags control the behavior of a transfer object.
>
>  ``PIPE_TRANSFER_READ``
>Resource contents read back (or accessed directly) at transfer create time.
>
> diff --git a/src/gallium/docs/source/screen.rst 
> b/src/gallium/docs/source/screen.rst
> index 00c9503..8759639 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -369,20 +369,23 @@ The integer capabilities:
>opcode to retrieve the current value in the framebuffer.
>  * ``PIPE_CAP_TGSI_MUL_ZERO_WINS``: Whether TGSI shaders support the
>``TGSI_PROPERTY_MUL_ZERO_WINS`` shader property.
>  * ``PIPE_CAP_DOUBLES``: Whether double precision floating-point operations
>are supported.
>  * ``PIPE_CAP_INT64``: Whether 64-bit integer operations are supported.
>  * ``PIPE_CAP_INT64_DIVMOD``: Whether 64-bit integer division/modulo
>operations are supported.
>  * ``PIPE_CAP_TGSI_TEX_TXF_LZ``: Whether TEX_LZ and TXF_LZ opcodes are
>supported.
> +* ``PIPE_CAP_SPARSE_BUFFER_PAGE_SIZE``: The page size of sparse buffers in
> +  bytes, or 0 if sparse buffers are not supported. The page size must be at
> +  most 64KB.
>
>
>  .. _pipe_capf:
>
>  PIPE_CAPF_*
>  
>
>  The floating-point capabilities are:
>
>  * ``PIPE_CAPF_MAX_LINE_WIDTH``: The maximum width of a regular line.
> diff --git a/src/gallium/include/pipe/p_context.h 
> b/src/gallium/include/pipe/p_context.h
> index a29fff5..4d5535b 100644
> --- a/src/gallium/include/pipe/p_context.h
> +++ b/src/gallium/include/pipe/p_context.h
> @@ -578,20 +578,33 @@ struct pipe_context {
>  * Flush any pending framebuffer writes and invalidate texture caches.
>  */
> void (*texture_barrier)(struct pipe_context *, unsigned flags);
>
> /**
>  * Flush caches according to flags.
>  */
> void (*memory_barrier)(struct pipe_context *, unsigned flags);
>
> /**
> +* Change the commitment status of a part of the given resource, which 
> must
> +* have been created with the PIPE_RESOURCE_FLAG_SPARSE bit.
> +*
> +* \param level The texture level whose commitment should be changed.
> +* \param box The region of the resource whose commitment should be 
> changed.
> +* \param commit Whether memory should be committed or un-committed.
> +*
> +* \return false if out of memory, true on success.
> +*/
> +   bool (*resource_commit)(struct pipe_context *, struct pipe_resource *,
> +   unsigned level, struct pipe_box *box, bool 
> commit);

I wonder what the behavior for threaded gallium should be. Possibilities:
1) Sync the context thread and execute directly.
2) Ignore the return value, always return true, and execute it asynchronously.

If the "false" return 

Re: [Mesa-dev] [PATCH v5 1/5] genxml: New generated header genX_bits.h (v5)

[Chad Versace]

On Tue 28 Mar 2017, Emil Velikov wrote:
> Hi Chad,
> 
> On 25 March 2017 at 02:28, Chad Versace  wrote:
> > genX_bits.h contains the sizes of bitfields in genxml instructions,
> > structures, and registers. It also defines some functions to query those
> > sizes.
> >
> > isl_surf_init() will use the new header to validate that requested
> > pitches fit in their destination bitfields.
> >
> > What's currently in genX_bits.h:
> >
> >   - Each CONTAINER::Field from gen*.xml that has a bitsize has a macro
> > in genX_bits.h:
> >
> > #define GEN{N}_CONTAINER_Field_bits {bitsize}
> >
> >   - For each set of macros whose name, after stripping the GEN prefix,
> > is the same, genX_bits.h contains a query function:
> >
> >   static inline uint32_t __attribute__((pure))
> >   CONTAINER_Field_bits(const struct gen_device_info *devinfo);
> >
> > v2 (Chad Versace):
> >   - Parse the XML instead of scraping the generated gen*_pack.h headers.
> >
> > v3 (Dylan Baker):
> >   - Port to Mako.
> >
> > v4 (Jason Ekstrand):
> >   - Make the _bits functions take a gen_device_info.
> >
> > v5 (Chad Versace):
> >   - Fix autotools out-of-tree build.
> >   - Fix Android build. Tested with git://github.com/android-ia/manifest.
> >   - Fix macro names. They were all missing the "_bits" suffix.
> >   - Fix macros names more. Remove all double-underscores.
> >   - Unindent all generated code. (It was floating in a sea of whitespace).
> >   - Reformat header to appear human-written not machine-generated.
> >   - Sort gens from high to low. Newest gens should come first because,
> > when we read code, we likely want to read the gen8/9 code and ignore
> > the gen4 code. So put the gen4 code at the bottom.
> >   - Replace 'const' attributes with 'pure', because the functions now
> > have a pointer parameter.
> >   - Add --cpp-guard flag. Used by Android.
> >   - Kill class FieldCollection. After Jason's rewrite, it was just
> > a dict.
> >
> > Co-authored-by: Dylan Baker 
> > Co-authored-by: Jason Ekstrand 
> > ---
> >  src/intel/Android.genxml.mk |   9 +-
> >  src/intel/Makefile.genxml.am|   6 +-
> >  src/intel/Makefile.sources  |   6 +-
> >  src/intel/genxml/.gitignore |   1 +
> >  src/intel/genxml/gen_bits_header.py | 281 
> > 
> >  5 files changed, 300 insertions(+), 3 deletions(-)
> >  create mode 100644 src/intel/genxml/gen_bits_header.py
> >
> > diff --git a/src/intel/Android.genxml.mk b/src/intel/Android.genxml.mk
> > index 79de7843801..842d0e13a33 100644
> > --- a/src/intel/Android.genxml.mk
> > +++ b/src/intel/Android.genxml.mk
> > @@ -46,9 +46,16 @@ LOCAL_GENERATED_SOURCES += $(addprefix 
> > $(intermediates)/, $(GENXML_GENERATED_FIL
> >  define header-gen
> > @mkdir -p $(dir $@)
> > @echo "Gen Header: $(PRIVATE_MODULE) <= $(notdir $(@))"
> > -   $(hide) $(PRIVATE_SCRIPT) $(PRIVATE_XML) > $@
> > +   $(hide) $(PRIVATE_SCRIPT) $(PRIVATE_SCRIPT_FLAGS) $(PRIVATE_XML) > 
> > $@
> >  endef
> >
> > +$(intermediates)/genxml/genX_bits.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) 
> > $(LOCAL_PATH)/genxml/gen_bits_header.py
> > +$(intermediates)/genxml/genX_bits.h: PRIVATE_SCRIPT_FLAGS := 
> > --cpp-guard=GENX_BITS_H
> > +$(intermediates)/genxml/genX_bits.h: PRIVATE_XML := $(addprefix 
> > $(LOCAL_PATH)/,$(GENXML_XML_FILES))
> > +$(intermediates)/genxml/genX_bits.h: 
> > $(LOCAL_PATH)/genxml/gen_bits_header.py
> > +$(intermediates)/genxml/genX_bits.h: $(addprefix 
> > $(LOCAL_PATH)/,$(GENXML_XML_FILES))
> > +   $(call header-gen)
> > +
> >  $(intermediates)/genxml/gen4_pack.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) 
> > $(LOCAL_PATH)/genxml/gen_pack_header.py
> >  $(intermediates)/genxml/gen4_pack.h: PRIVATE_XML := 
> > $(LOCAL_PATH)/genxml/gen4.xml
> >  $(intermediates)/genxml/gen4_pack.h: $(LOCAL_PATH)/genxml/gen4.xml 
> > $(LOCAL_PATH)/genxml/gen_pack_header.py



> > +def parse_args():
> > +p = argparse.ArgumentParser()
> > +p.add_argument('-o', '--output', type=str,
> > +   help="If OUTPUT is unset or '-', then it defaults to 
> > '/dev/stdout'")
> > +p.add_argument('--cpp-guard', type=str,
> > +   help='If unset, then CPP_GUARD is derived from OUTPUT.')

> Admittedly --output should be enough for everyone, but I'm not sure
> what issues you're getting with Android-IA.

I didn't have any issues. I added the --cpp-guard option because it
allowed me to re-use the same idiom in Android.genxml.mk used by the
other generated headers. That is, the --cpp-guard option allowed me to
re-use the Makefile's `header-gen` function instead of adding a custom
rule just for genX_bits.h.

> For the future rather please, poke me/others for ideas/help. Be that
> on #dri-devel, #intel-gfx or #android-ia.

I don't understand. I tested the build on android-ia, and it worked. And
the hunk in Android.genxml.mk follows the 

[Mesa-dev] [PATCH] gbm/dri: Flush after unmap

[Thomas Hellstrom]

Drivers may queue dma operations on the context at unmap time so we need
to flush to make sure the data gets to the bo. Ideally the application
would take care of this, but since there appears to be no exported gbm
flush functionality we need to explicitly flush at unmap time.

This fixes a problem where kmscube on vmwgfx in rgba textured mode would
render using an uninitialized texture rather than the intended
rgba pattern.

Signed-off-by: Thomas Hellstrom 
---
 src/gbm/backends/dri/gbm_dri.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index ac7ede8..6c2244c 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -243,7 +243,7 @@ struct dri_extension_match {
 };
 
 static struct dri_extension_match dri_core_extensions[] = {
-   { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
+   { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
{ __DRI_IMAGE, 1, offsetof(struct gbm_dri_device, image) },
{ __DRI2_FENCE, 1, offsetof(struct gbm_dri_device, fence), 1 },
{ __DRI2_INTEROP, 1, offsetof(struct gbm_dri_device, interop), 1 },
@@ -992,6 +992,13 @@ gbm_dri_bo_unmap(struct gbm_bo *_bo, void *map_data)
   return;
 
dri->image->unmapImage(dri->context, bo->image, map_data);
+
+   /*
+* Not all DRI drivers use direct maps. They may queue up DMA operations
+* on the mapping context. Since there is no explicit gbm flush
+* mechanism. We need to flush here.
+*/
+   dri->flush->flush_with_flags(dri->context, NULL, __DRI2_FLUSH_CONTEXT, 0);
 }
 
 
-- 
2.5.0

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

Re: [Mesa-dev] [PATCH 4/5] r600g: use a clever alignment for index buffer uploads

[Marek Olšák]

Actually nevermind.

Patches 1-3:
Reviewed-by: Marek Olšák 

Patches 4-5:
These have no effect, because r600g hw doesn't use TC for index fetches.

Marek


On Tue, Mar 28, 2017 at 9:33 PM, Marek Olšák  wrote:
> BTW, I don't know if tcc_cache_line_size has the correct value for
> pre-GCN chips.
>
> Marek
>
> On Sun, Mar 26, 2017 at 5:36 PM, Constantine Kharlamov
>  wrote:
>> Stolen from radeonsi
>>
>> Signed-off-by: Constantine Kharlamov 
>> ---
>>  src/gallium/drivers/r600/r600_state_common.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/drivers/r600/r600_state_common.c 
>> b/src/gallium/drivers/r600/r600_state_common.c
>> index 961e04e9db..5293c4034f 100644
>> --- a/src/gallium/drivers/r600/r600_state_common.c
>> +++ b/src/gallium/drivers/r600/r600_state_common.c
>> @@ -1766,7 +1766,8 @@ static void r600_draw_vbo(struct pipe_context *ctx, 
>> const struct pipe_draw_info
>>  info->instance_count > 1 ||
>>  info->count*ib.index_size > 
>> 20)) {
>> u_upload_data(ctx->stream_uploader, 0,
>> -  info->count * ib.index_size, 256,
>> + info->count * ib.index_size,
>> + 
>> rctx->screen->b.info.tcc_cache_line_size,
>>   ib.user_buffer, , 
>> );
>> ib.user_buffer = NULL;
>> }
>> --
>> 2.12.0
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/5] r600g: use a clever alignment for index buffer uploads

[Constantine Kharlamov]

Ok, I can look it up. Is there some docs where I find the right alignment value?

On 28.03.2017 22:33, Marek Olšák wrote:
> BTW, I don't know if tcc_cache_line_size has the correct value for
> pre-GCN chips.
> 
> Marek
> 
> On Sun, Mar 26, 2017 at 5:36 PM, Constantine Kharlamov
>  wrote:
>> Stolen from radeonsi
>>
>> Signed-off-by: Constantine Kharlamov 
>> ---
>>  src/gallium/drivers/r600/r600_state_common.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/drivers/r600/r600_state_common.c 
>> b/src/gallium/drivers/r600/r600_state_common.c
>> index 961e04e9db..5293c4034f 100644
>> --- a/src/gallium/drivers/r600/r600_state_common.c
>> +++ b/src/gallium/drivers/r600/r600_state_common.c
>> @@ -1766,7 +1766,8 @@ static void r600_draw_vbo(struct pipe_context *ctx, 
>> const struct pipe_draw_info
>>  info->instance_count > 1 ||
>>  info->count*ib.index_size > 
>> 20)) {
>> u_upload_data(ctx->stream_uploader, 0,
>> -  info->count * ib.index_size, 256,
>> + info->count * ib.index_size,
>> + 
>> rctx->screen->b.info.tcc_cache_line_size,
>>   ib.user_buffer, , 
>> );
>> ib.user_buffer = NULL;
>> }
>> --
>> 2.12.0
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/5] r600g: use a clever alignment for index buffer uploads

[Marek Olšák]

BTW, I don't know if tcc_cache_line_size has the correct value for
pre-GCN chips.

Marek

On Sun, Mar 26, 2017 at 5:36 PM, Constantine Kharlamov
 wrote:
> Stolen from radeonsi
>
> Signed-off-by: Constantine Kharlamov 
> ---
>  src/gallium/drivers/r600/r600_state_common.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/r600_state_common.c 
> b/src/gallium/drivers/r600/r600_state_common.c
> index 961e04e9db..5293c4034f 100644
> --- a/src/gallium/drivers/r600/r600_state_common.c
> +++ b/src/gallium/drivers/r600/r600_state_common.c
> @@ -1766,7 +1766,8 @@ static void r600_draw_vbo(struct pipe_context *ctx, 
> const struct pipe_draw_info
>  info->instance_count > 1 ||
>  info->count*ib.index_size > 
> 20)) {
> u_upload_data(ctx->stream_uploader, 0,
> -  info->count * ib.index_size, 256,
> + info->count * ib.index_size,
> + 
> rctx->screen->b.info.tcc_cache_line_size,
>   ib.user_buffer, , );
> ib.user_buffer = NULL;
> }
> --
> 2.12.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] mesa: load a user defined drirc file specified via an environment variable

[Eric Anholt]

Edmondo Tommasina  writes:

> On Mon, Mar 27, 2017 at 11:32 PM, Eric Anholt  wrote:
>> Edmondo Tommasina  writes:
>>
>>> On Mon, Mar 27, 2017 at 6:05 PM, Eric Anholt  wrote:
 Edmondo Tommasina  writes:

> Define a new MESA_USER_DRIRC environment variable to load a customized
> drirc file.
>
> When the variable is not defined, nothing changes and the ${HOME}/.drirc
> file will be loaded.
>
> If the variable is set to a file, this file will be loaded instead of
> the the ${HOME}/.drirc.
>
> Example: MESA_USER_DRIRC=~/glthread.drirc glxgears
>
> If the variable is set to nothing, it avoids to load the ${HOME}/.drirc
> file.
>
> Example: MESA_USER_DRIRC= glxgears

 Could you extend the commit message to describe what problem is being
 solved?  Why wouldn't you just customize your .drirc, since it's in your
 homedir already?
>>>
>>> I've posted a second version of the patch, trying to better document the
>>> possible generic usage of the variable.
>>>
>>> My use: I don't have a ~/.drirc file since I prefer to have my desktop
>>> running with the default mesa setting (/etc/drirc). If the ~/.drirc file
>>> would exist, it would impact all the applications started with my
>>> user and not only the one I want to test. This is potentially a little
>>> problem being solved.
>>>
>>> For me it's useful when I test/benchmark something: I like to use
>>> prepared config file just for this kind of test, instead of passing
>>> a list of env variables.
>>
>> So you want to set this environment variable so you can avoid passing
>> things as environment variables?  That doesn't seem like a strong enough
>> justification for the patch, to me.
>
> Right. But well, this was the weakest justification of the three I've
> given. Anyways, I agree :)
>
> Any opinion about the possibility to skip the load of ~/.drirc with
> the variable? Could this be useful?

I don't see why, if you want to not have a .drirc, you don't just delete
.drirc.  Or, if you have some settings in .drirc you don't want, you
don't just remove them.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 03/11] etnaviv: add basic shader variant support

[Christian Gmeiner]

Hi Lucas,


2017-03-27 10:56 GMT+02:00 Lucas Stach :
> Am Sonntag, den 26.03.2017, 16:13 +0200 schrieb Christian Gmeiner:
>> This commit adds some basic infrastructure to handle shader
>> variants. We are still creating exactly one shader variant
>> for each shader.
>>
>> Signed-off-by: Christian Gmeiner 
>
> Nitpick inline, othwerwise:
>
> Reviewed-by: Lucas Stach 
>
>> ---
>>  src/gallium/drivers/etnaviv/etnaviv_compiler.h |  3 ++
>>  src/gallium/drivers/etnaviv/etnaviv_shader.c   | 49 
>> +++---
>>  src/gallium/drivers/etnaviv/etnaviv_shader.h   | 12 +++
>>  3 files changed, 60 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.h 
>> b/src/gallium/drivers/etnaviv/etnaviv_compiler.h
>> index 2a3b4f4..8de0126 100644
>> --- a/src/gallium/drivers/etnaviv/etnaviv_compiler.h
>> +++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.h
>> @@ -92,6 +92,9 @@ struct etna_shader_variant {
>>
>> /* unknown input property (XX_INPUT_COUNT, field UNK8) */
>> uint32_t input_count_unk8;
>> +
>> +   /* shader variants form a linked list */
>> +   struct etna_shader_variant *next;
>>  };
>>
>>  struct etna_varying {
>> diff --git a/src/gallium/drivers/etnaviv/etnaviv_shader.c 
>> b/src/gallium/drivers/etnaviv/etnaviv_shader.c
>> index 35084e5..d6bc9bc 100644
>> --- a/src/gallium/drivers/etnaviv/etnaviv_shader.c
>> +++ b/src/gallium/drivers/etnaviv/etnaviv_shader.c
>> @@ -31,6 +31,7 @@
>>  #include "etnaviv_debug.h"
>>  #include "etnaviv_util.h"
>>
>> +#include "tgsi/tgsi_parse.h"
>>  #include "util/u_math.h"
>>  #include "util/u_memory.h"
>>
>> @@ -266,25 +267,65 @@ etna_shader_update_vertex(struct etna_context *ctx)
>> ctx->vertex_elements);
>>  }
>>
>> +static struct etna_shader_variant *
>> +create_variant(struct etna_shader *shader)
>> +{
>> +   struct etna_shader_variant *v;
>> +
>> +   v = etna_compile_shader(shader->specs, shader->tokens);
>> +   if (!v) {
>> +  debug_error("compile failed!");
>> +  return NULL;
>> +   }
>> +
>> +   v->id = ++shader->variant_count;
>> +
>> +   return v;
>> +}
>> +
>>  static void *
>>  etna_create_shader_state(struct pipe_context *pctx,
>>   const struct pipe_shader_state *pss)
>>  {
>> struct etna_context *ctx = etna_context(pctx);
>> -   struct etna_shader_variant *shader = etna_compile_shader(>specs, 
>> pss->tokens);
>> +   struct etna_shader *shader = CALLOC_STRUCT(etna_shader);
>> +
>> +   if (!shader)
>> +  return NULL;
>>
>> static uint32_t id;
>> shader->id = id++;
>> +   shader->specs = >specs;
>> +   shader->tokens = tgsi_dup_tokens(pss->tokens);
>>
>> -   dump_shader_info(shader, >debug);
>> +   /* compile new variant */
>> +   struct etna_shader_variant *v;
>>
>> -   return shader;
>> +   v = create_variant(shader);
>> +   if (v) {
>> +  v->next = shader->variants;
>> +  shader->variants = v;
>> +  dump_shader_info(v, >debug);
>> +   }
>> +
>> +   return v;
>>  }
>>
>>  static void
>>  etna_delete_shader_state(struct pipe_context *pctx, void *ss)
>>  {
>> -   etna_destroy_shader(ss);
>> +   struct etna_shader *shader = ss;
>> +   struct etna_shader_variant *v, *t;
>> +
>> +   v = shader->variants;
>> +   while (v) {
>> +  t = v;
>> +  v = v->next;
>> +  etna_destroy_shader(t);
>> +   }
>> +
>> +   FREE((void *)shader->tokens);
>
> Is this cast really needed?
>

It is not needed - I have corrected that locally.

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/5] radv: move calculating fragment shader i/os to pipeline.

[Dave Airlie]

On 28 March 2017 at 21:05, Alex Smith  wrote:
> Hi Dave,
>
> This commit is causing some GPU hangs for us, on Polaris cards at least (470
> and 480).
>
> It also causes hangs in Dota 2 (on the initial logo screen at startup).
>
> Seems to be caused by the change to set the SPI_PS_INPUT_CNTL registers with
> radeon_set_context_reg_seq - changing that to use a separate
> radeon_set_context_reg call for each register avoids the hangs here, which
> seems... odd.
>
> Any idea?

Oops, fix pushed, it didn't handle the 0 case properly.

Thanks for reporting!

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

Re: [Mesa-dev] [PATCH 2/2] mesa: load a user defined drirc file specified via an environment variable

[Edmondo Tommasina]

On Mon, Mar 27, 2017 at 11:32 PM, Eric Anholt  wrote:
> Edmondo Tommasina  writes:
>
>> On Mon, Mar 27, 2017 at 6:05 PM, Eric Anholt  wrote:
>>> Edmondo Tommasina  writes:
>>>
 Define a new MESA_USER_DRIRC environment variable to load a customized
 drirc file.

 When the variable is not defined, nothing changes and the ${HOME}/.drirc
 file will be loaded.

 If the variable is set to a file, this file will be loaded instead of
 the the ${HOME}/.drirc.

 Example: MESA_USER_DRIRC=~/glthread.drirc glxgears

 If the variable is set to nothing, it avoids to load the ${HOME}/.drirc
 file.

 Example: MESA_USER_DRIRC= glxgears
>>>
>>> Could you extend the commit message to describe what problem is being
>>> solved?  Why wouldn't you just customize your .drirc, since it's in your
>>> homedir already?
>>
>> I've posted a second version of the patch, trying to better document the
>> possible generic usage of the variable.
>>
>> My use: I don't have a ~/.drirc file since I prefer to have my desktop
>> running with the default mesa setting (/etc/drirc). If the ~/.drirc file
>> would exist, it would impact all the applications started with my
>> user and not only the one I want to test. This is potentially a little
>> problem being solved.
>>
>> For me it's useful when I test/benchmark something: I like to use
>> prepared config file just for this kind of test, instead of passing
>> a list of env variables.
>
> So you want to set this environment variable so you can avoid passing
> things as environment variables?  That doesn't seem like a strong enough
> justification for the patch, to me.

Right. But well, this was the weakest justification of the three I've
given. Anyways, I agree :)

Any opinion about the possibility to skip the load of ~/.drirc with
the variable? Could this be useful?

This patch probably should have been an RFC. I'll post a v3 of the
patch later with the changes hinted by Gustaw.

Thanks
edmondo
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/nine: Fix support for ps 1.4 dw and dz modifiers

[Axel Davy]

This probably should be CC Mesa 17 stable. I'll add it before push.

On 26/03/2017 23:00, Axel Davy wrote:

RCP was used incorrectly to support NINED3DSPSM_DW and
NINED3DSPSM_DZ. src.x as used as input instead of src.w
or src.z.

Fixes: https://github.com/iXit/Mesa-3D/issues/271

Signed-off-by: Axel Davy 
---
  src/gallium/state_trackers/nine/nine_shader.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/nine/nine_shader.c 
b/src/gallium/state_trackers/nine/nine_shader.c
index 818d136ec0..8d6583fc44 100644
--- a/src/gallium/state_trackers/nine/nine_shader.c
+++ b/src/gallium/state_trackers/nine/nine_shader.c
@@ -1127,14 +1127,14 @@ tx_src_param(struct shader_translator *tx, const struct 
sm1_src_param *param)
  case NINED3DSPSM_DW:
  tmp = tx_scratch(tx);
  /* NOTE: app is not allowed to read w with this modifier */
-ureg_RCP(ureg, ureg_writemask(tmp, NINED3DSP_WRITEMASK_3), src);
+ureg_RCP(ureg, ureg_writemask(tmp, NINED3DSP_WRITEMASK_3), 
ureg_scalar(src, TGSI_SWIZZLE_W));
  ureg_MUL(ureg, tmp, src, ureg_swizzle(ureg_src(tmp), 
NINE_SWIZZLE4(W,W,W,W)));
  src = ureg_src(tmp);
  break;
  case NINED3DSPSM_DZ:
  tmp = tx_scratch(tx);
  /* NOTE: app is not allowed to read z with this modifier */
-ureg_RCP(ureg, ureg_writemask(tmp, NINED3DSP_WRITEMASK_2), src);
+ureg_RCP(ureg, ureg_writemask(tmp, NINED3DSP_WRITEMASK_2), 
ureg_scalar(src, TGSI_SWIZZLE_Z));
  ureg_MUL(ureg, tmp, src, ureg_swizzle(ureg_src(tmp), 
NINE_SWIZZLE4(Z,Z,Z,Z)));
  src = ureg_src(tmp);
  break;



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

Re: [Mesa-dev] [PATCH v2 1/2] intel: android: remove libdrm_intel requirement

[Kenneth Graunke]

On Tuesday, March 28, 2017 7:47:39 AM PDT Emil Velikov wrote:
> From: Emil Velikov 
> 
> The only part which requires libdrm_intel tools/aubinator is not built
> on Android.
> 
> Signed-off-by: Emil Velikov 
> ---
> What was 1/3 of the series has superseded by Ken with commit
> 0c3fbf8028b6f44a341548d341fa660e6b120647

These two are:
Reviewed-by: Kenneth Graunke 


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

Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: Reduce number of max descriptor sets to 4.

[Bas Nieuwenhuizen]

On Tue, Mar 28, 2017 at 4:12 PM, Emil Velikov  wrote:
> On 17 March 2017 at 08:42, Bas Nieuwenhuizen  wrote:
>> We never supported more, as we can run out of user SGPRs on the VS.
>>
>> Fixes: f4e499ec791 ("radv: add initial non-conformant radv vulkan driver")
>> Signed-off-by: Bas Nieuwenhuizen 
>> CC: 
>> CC: James Legg 
>> ---
>>  src/amd/vulkan/radv_descriptor_set.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/amd/vulkan/radv_descriptor_set.h 
>> b/src/amd/vulkan/radv_descriptor_set.h
>> index c373489ccb3..d512fbdd51a 100644
>> --- a/src/amd/vulkan/radv_descriptor_set.h
>> +++ b/src/amd/vulkan/radv_descriptor_set.h
>> @@ -26,7 +26,7 @@
>>
>>  #include 
>>
>> -#define MAX_SETS 8
>> +#define MAX_SETS 4
>>
> FTR, seems like the patch was superseded by the one below.
> Please let me know if that's not the case and we need it in stable.

The issue contained in this patch is still present, but given that it
is only a corner case that is unlikely to be hit,  somewhat reduced
exposed capabilities and lack of interest from reviewers I'm going to
let it rest.

Thanks for inquiring,
Bas

>
> commit e88cac1df03d01a9e8a1de1a4a2ee888149e727a
> Author: James Legg 
> Date:   Thu Mar 16 17:48:13 2017 +
>
> radv: Fix using more than 4 bound descriptor sets
>
>
>
> Thanks
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: Invalidate L2 for TRANSFER_WRITE barriers

[Bas Nieuwenhuizen]

On Tue, Mar 28, 2017 at 6:31 PM, Alex Smith  wrote:
> On 28 March 2017 at 17:09, Emil Velikov  wrote:
>>
>> On 22 March 2017 at 10:06, Bas Nieuwenhuizen 
>> wrote:
>> > On Tue, Mar 21, 2017 at 1:02 PM, Alex Smith
>> >  wrote:
>> >> CP DMA and PKT3_WRITE_DATA (in CmdUpdateBuffer) don't (currently) write
>> >> through L2. Therefore, to make these writes visible to later accesses
>> >> we must invalidate L2 rather than just writing it back, to avoid the
>> >> possibility that stale data is read through L2.
>> >>
>> >> Cc: "17.0" 
>> >> Signed-off-by: Alex Smith 
>> >> ---
>> >> It's possible for both CP DMA and PKT3_WRITE_DATA to write through L2
>> >> as far as I can see, and changing things so that they do also solves
>> >> the problems that this patch fixes.
>> >>
>> >> However, I don't know what the exact consequences of doing so are, or
>> >> whether there are any situations where that shouldn't be done, so I've
>> >> gone with this fix instead as it seems like a safer option for now.
>> >
>> > Yeah we should be able to. I'm more comfortable sending this patch to
>> > stable though, so this patch is
>> >
>> Bas, others,
>>
>> Patch addresses radv_{src,dst}_access_flush() which landed with commit
>> 6dbb0eaccc3, after the 17.0 branchpoint.
>
>
> Oops, my mistake.
>
> I think radv_CmdPipelineBarrier on the 17.0 branch still needs
> RADV_CMD_FLAG_INV_GLOBAL_L2 added for TRANSFER_WRITE barriers at least. Bas,
> do you think that should be added in a separate patch just for stable, or
> would you prefer to push those later changes to stable as well? Looks like
> there's some fixes in those as well.

I'd prefer to backport this patch. The other patches IMO contain too
much risk for regression and are actually mostly for optimizations.
>
> Alex
>
>>
>>
>> From a quick look, the functions has been fixed/enhanced with the
>> following 7 commits. Some of which require additional patches.
>> If we want this in stable, please provide a backport or branch based
>> on top of mesa-17.0.2.
>>
>> Thanks
>> Emil
>>
>> 40e0dbf96c4d812be940561f5732b1b0e44b5e1d
>> f3dc318464b786c2696e650e7c69984b5453624b
>> b075eb7d476eb750092f72e7ec65bc41003fa658
>> dd094e4ff9ff0967b515a4330e40feca55247e25
>> 7a600bbc8186fef9475bedfe6d58a54011a8022b
>> 0567ab0407e4058c108443b90b7c23a40c391c3b
>> f92a118434452df201cda6d9ec2405aca669b104
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)

[Brian Paul]

On 03/28/2017 11:19 AM, Dylan Baker wrote:

Quoting Jose Fonseca (2017-03-28 09:19:48)

On 28/03/17 00:12, Dylan Baker wrote:


Okay, I have libepoxy working for windows. I also got libepoxy working as a
subproject, but it took a bit of hacking on their build system (there's
some things they're doing that make them non-subproject safe, I'll send patches
and work that out with them.

https://github.com/dcbaker/libepoxy.git fix-suproject


Thanks.

GLEW is not the only one case though.  There's also FREEGLUT.  So we
can't really avoid the problem of external windows binaries/subprojects.

So I've been thinking, and I suspect is better if first get things
working with binary GLEW / FREGLUT projects, then try the glew ->
libepoxy in a 2nd step, so there's less to take in to merge meson into
master.


Is freeglut a hard requirement? At least in autoconf we have logic to look for
both, and use #defines to enable freeglut only features.


Nearly all the Mesa demos require GLUT / freeglut.

-Brian


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

Re: [Mesa-dev] [PATCH 0/7] Adding more documentation to the release process

[Emil Velikov]

Hi Andres,

Thanks for the corrections/updates.

On 27 March 2017 at 19:48, Andres Gomez  wrote:
> A series of patches adding more details to the release process.
>
> Andres Gomez (7):
>   docs/releasing: format/style homogenization
>   docs/releasing: check in master for forgotten nomination candidates
>   docs/releasing: further explain the build/check testing process
>   docs/releasing: if possible, do some every day use on the RC
>   docs/releasing: added relevant people for build/check with Windows
>   docs/releasing: added relevant people for build/check with Android
>   docs/releasing: added relevant people for build/check with MacOSX
>
I'm not sold if we want the last three - I'll defer that to the
referenced people.

The series is:
Reviewed-by: Emil Velikov 

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

[Mesa-dev] [Bug 100425] glGenFramebuffersEXT appears to be null on (some?) Mesa 12.0.6 systems

[bugzilla-daemon]

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

--- Comment #4 from Kai Ninomiya  ---
Thanks Timothy and Timo, if this isn't a major, widely-seen regression in
12.0.6 then there isn't much we can do. If Chromium added a workaround it would
also be a few months before the fix is out, so the xenial-updates push will be
best.

I'm fine with marking WONTFIX.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 1/5] genxml: New generated header genX_bits.h (v5)

[Dylan Baker]

Quoting Chad Versace (2017-03-28 09:37:56)
> On Sat 25 Mar 2017, Dylan Baker wrote:
> > 
> > This is just a suggestion, feel free to ignore
> > 
> > I forgot to do something here, but this is one case where using
> > argparse.FileType might actually be the right thing to do.
> > 
> > it would like like:
> > p.add_argument('-o', '--output', type=argparse.FileType('wb'), 
> > default=sys.stdout, ...)
> > 
> > Then you could drop the hunk above and the 'with open(...)' in the main
> > function. It's also more portable.
> 
> I just tried the suggestion, and it behaves badly IMO for output files.  It's
> probably fine for input files. The problem is that ArgumentParser creates the
> file as soon as it parses the -o option, even when there is a usage error or
> the --help option is given.
> 
> Example 1:
>   $ ./gen_bits_header.py -o bad-output1 --bad-option
>   usage: gen_bits_header.py [-h] [-o OUTPUT] [--cpp-guard CPP_GUARD]
>   XML_SOURCE [XML_SOURCE ...]
>   gen_bits_header.py: error: too few arguments
>   $ echo $?
>   2
>   $ ls
>   ... bad-output1
> 
> Example 2:
>   $ ./gen_bits_header.py -o bad-output2 --help
>   usage: gen_bits_header.py [-h] [-o OUTPUT] [--cpp-guard CPP_GUARD]
>   XML_SOURCE [XML_SOURCE ...]
>   $ echo $?
>   0
>   $ ls
>   ... bad-output2

Yup, there are some painful corners to argparse.FileType that make me almost
never use it, which is why it was just a suggestion :)

Dylan


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

Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)

[Dylan Baker]

Quoting Jose Fonseca (2017-03-28 09:19:48)
> On 28/03/17 00:12, Dylan Baker wrote:
> >
> > Okay, I have libepoxy working for windows. I also got libepoxy working as a
> > subproject, but it took a bit of hacking on their build system (there's
> > some things they're doing that make them non-subproject safe, I'll send 
> > patches
> > and work that out with them.
> >
> > https://github.com/dcbaker/libepoxy.git fix-suproject
> 
> Thanks.
> 
> GLEW is not the only one case though.  There's also FREEGLUT.  So we 
> can't really avoid the problem of external windows binaries/subprojects.
> 
> So I've been thinking, and I suspect is better if first get things 
> working with binary GLEW / FREGLUT projects, then try the glew -> 
> libepoxy in a 2nd step, so there's less to take in to merge meson into 
> master.

Is freeglut a hard requirement? At least in autoconf we have logic to look for
both, and use #defines to enable freeglut only features.

> 
> > Clone that repo into $mesa-demos-root/subprojects and things should just 
> > work,
> > or mostly work. I got epoxy compiling, but ran into some issues in the 
> > mingw glu
> > header.
> >
> > Dylan
> 
> I'm pretty sure the problem with MinGW glu is the lack of windows.h.  We 
> need to do the same as CMakeLists.txt snippet quoted below.
> 
> I'm running out of time today, but I'll look into porting this over to 
> meson tomorrow if you don't beat me to it.
> 
> Jose
> 
> 
> 
> if (WIN32)
>  # Nobody likes to include windows.h:
>  # - Microsoft's GL/gl.h header depends on windows.h but doesn't 
> include it;
>  # - GLEW temporarily defines the necessary defines but 
> undefines them later
>  # - certain GLUT distributions don't include it;
>  # - most of our programs are meant to be portable so don't 
> include it.
>  #
>  # We could try to replicate the windows.h definitions required by
>  # GL/gl.h, but the build time savings don't compensate the constant
>  # headaches that brings, so instead we force windows.h to be 
> included
>  # on every file.
>  if (MSVC)
>  add_definitions (-FIwindows.h)
>  else (MSVC)
>  add_definitions (--include windows.h)
>  endif (MSVC)
> 
>  # Don't define min/max macros
>  add_definitions (-DNOMINMAX)
> 
>  # MSVC & MinGW only define & use APIENTRY
>  add_definitions (-DGLAPIENTRY=__stdcall)
> 
>  link_libraries (winmm)
> endif (WIN32)
> 

I assumed it was probably something like that. I'll have a look.

Dylan


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

Re: [Mesa-dev] [PATCH v2 2/4] si_compute: check NULL return from u_upload_alloc

[Marek Olšák]

On Tue, Mar 28, 2017 at 6:52 PM, Julien Isorce  wrote:
> -   if (program->input_size || program->ir_type ==
> PIPE_SHADER_IR_NATIVE)
> -   si_upload_compute_input(sctx, code_object, info);
> +   if ((program->input_size ||
> +program->ir_type == PIPE_SHADER_IR_NATIVE) &&
> +unlikely(!si_upload_compute_input(sctx, code_object, info))) {
> +   return false;
> +   }
>
> is the indentation ok ?

The "unlikely" line should have one less space character at the beginning.

Marek

>
>
> On 27 March 2017 at 16:39, Marek Olšák  wrote:
>>
>> "&&" at the end of the previous line please.
>>
>> Reviewed-by: Marek Olšák 
>>
>> Marek
>>
>> On Mon, Mar 27, 2017 at 3:46 PM, Julien Isorce 
>> wrote:
>> > Signed-off-by: Julien Isorce 
>> > ---
>> >  src/gallium/drivers/radeonsi/si_compute.c | 13 ++---
>> >  1 file changed, 10 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
>> > b/src/gallium/drivers/radeonsi/si_compute.c
>> > index 46476b6..a38138f 100644
>> > --- a/src/gallium/drivers/radeonsi/si_compute.c
>> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
>> > @@ -579,7 +579,7 @@ static void si_setup_user_sgprs_co_v2(struct
>> > si_context *sctx,
>> > }
>> >  }
>> >
>> > -static void si_upload_compute_input(struct si_context *sctx,
>> > +static bool si_upload_compute_input(struct si_context *sctx,
>> > const amd_kernel_code_t
>> > *code_object,
>> > const struct pipe_grid_info *info)
>> >  {
>> > @@ -602,6 +602,9 @@ static void si_upload_compute_input(struct
>> > si_context *sctx,
>> >_args_offset,
>> >(struct pipe_resource**)_buffer,
>> > _args_ptr);
>> >
>> > +   if (unlikely(!kernel_args_ptr))
>> > +   return false;
>> > +
>> > kernel_args = (uint32_t*)kernel_args_ptr;
>> > kernel_args_va = input_buffer->gpu_address + kernel_args_offset;
>> >
>> > @@ -636,6 +639,8 @@ static void si_upload_compute_input(struct
>> > si_context *sctx,
>> > }
>> >
>> > r600_resource_reference(_buffer, NULL);
>> > +
>> > +   return true;
>> >  }
>> >
>> >  static void si_setup_tgsi_grid(struct si_context *sctx,
>> > @@ -790,8 +795,10 @@ static void si_launch_grid(
>> > si_set_atom_dirty(sctx, sctx->atoms.s.render_cond,
>> > false);
>> > }
>> >
>> > -   if (program->input_size || program->ir_type ==
>> > PIPE_SHADER_IR_NATIVE)
>> > -   si_upload_compute_input(sctx, code_object, info);
>> > +   if ((program->input_size || program->ir_type ==
>> > PIPE_SHADER_IR_NATIVE)
>> > +&& unlikely(!si_upload_compute_input(sctx, code_object,
>> > info))) {
>> > +   return false;
>> > +   }
>> >
>> > /* Global buffers */
>> > for (i = 0; i < MAX_GLOBAL_BUFFERS; i++) {
>> > --
>> > 2.7.4
>> >
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 100430] [radv] graphical glitches on dolphin emulator

[bugzilla-daemon]

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

--- Comment #5 from jdr...@gmail.com ---
Created attachment 130506
  --> https://bugs.freedesktop.org/attachment.cgi?id=130506=edit
Screen part missing (fifo)

Last one recorded with dolphin's fifo player.
Hope it helps.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

Hi Chad,

On 24 March 2017 at 20:44, Chad Versace  wrote:
> On Tue 21 Mar 2017, Matt Turner wrote:
>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  
>> wrote:
>> > On 20 March 2017 at 18:30, Matt Turner  wrote:
>> >> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>> >> wrote:
>
>> >>> These projects have been getting closer to upstream and "forcing" the
>> >>> extra obstacle is effectively giving them the middle finger.
>> >>
>> >> No. Requiring us to compile with a 10 year old GCC is giving a middle 
>> >> finger.
>> >>
>> > Can we stop with the GCC thing ? Can we point to a place where we want
>> > to use feature A introduced with GCC B and we don't ?
>>
>> Are you freaking serious?!
>>
>> This happens *all* the time. It happened like two days ago with commit
>> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
>> happened at least once in the previous month, and every month before
>> that.
>
> More examples:
>
> - Jason and I wanted to use C11 generic expressions (that's what the
>   C11 spec calls them) in anvil, but old GCC => !C11.
>
[snip]
>
> freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | 
> vulkan/anv_device.c:697:4: error: initializer element is not constant
> freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | 
> .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
> freenode.#dri-devel.log-2017-03-16 11:07:23 | imirkin_ | anyone seen 
> this? i'm on HEAD
> freenode.#dri-devel.log-2017-03-16 11:13:50 | vsyrjala | yep. gcc-4.9 
> strikes again?
> freenode.#dri-devel.log-2017-03-16 11:14:54 | imirkin_ | i'm 
> definitely using gcc-4.9
> freenode.#dri-devel.log-2017-03-16 11:15:16 | vsyrjala | that 
> '(VkExtent3D)' looks very much pointless there
> freenode.#dri-devel.log-2017-03-16 11:15:56 | imirkin_ | 4.9.4 as it 
> happens, which is the "stable" gcc on gentoo
> freenode.#dri-devel.log:2017-03-16 11:18:04 | vsyrjala | looks like 
> chadv broke it

As mentioned elsewhere - if major stakeholders of $driver want to bump
the requirement, please do.
As an example: st/nine requires GCC 4.6 and st/clover GCC 4.7 for a
very long time.

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 100430] [radv] graphical glitches on dolphin emulator

[bugzilla-daemon]

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

--- Comment #4 from jdr...@gmail.com ---
Created attachment 130505
  --> https://bugs.freedesktop.org/attachment.cgi?id=130505=edit
White Square on MarioKart (fifo)

Same: 3 pictures saved

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/4] si_compute: check NULL return from u_upload_alloc

[Julien Isorce]

Oops it should be just "return;" here.

On 28 March 2017 at 17:52, Julien Isorce  wrote:

> -   if (program->input_size || program->ir_type ==
> PIPE_SHADER_IR_NATIVE)
> -   si_upload_compute_input(sctx, code_object, info);
> +   if ((program->input_size ||
> +program->ir_type == PIPE_SHADER_IR_NATIVE) &&
> +unlikely(!si_upload_compute_input(sctx, code_object, info)))
> {
> +   return false;
> +   }
>
> is the indentation ok ?
>
>
> On 27 March 2017 at 16:39, Marek Olšák  wrote:
>
>> "&&" at the end of the previous line please.
>>
>> Reviewed-by: Marek Olšák 
>>
>> Marek
>>
>> On Mon, Mar 27, 2017 at 3:46 PM, Julien Isorce 
>> wrote:
>> > Signed-off-by: Julien Isorce 
>> > ---
>> >  src/gallium/drivers/radeonsi/si_compute.c | 13 ++---
>> >  1 file changed, 10 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
>> b/src/gallium/drivers/radeonsi/si_compute.c
>> > index 46476b6..a38138f 100644
>> > --- a/src/gallium/drivers/radeonsi/si_compute.c
>> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
>> > @@ -579,7 +579,7 @@ static void si_setup_user_sgprs_co_v2(struct
>> si_context *sctx,
>> > }
>> >  }
>> >
>> > -static void si_upload_compute_input(struct si_context *sctx,
>> > +static bool si_upload_compute_input(struct si_context *sctx,
>> > const amd_kernel_code_t
>> *code_object,
>> > const struct pipe_grid_info *info)
>> >  {
>> > @@ -602,6 +602,9 @@ static void si_upload_compute_input(struct
>> si_context *sctx,
>> >_args_offset,
>> >(struct pipe_resource**)_buffer,
>> _args_ptr);
>> >
>> > +   if (unlikely(!kernel_args_ptr))
>> > +   return false;
>> > +
>> > kernel_args = (uint32_t*)kernel_args_ptr;
>> > kernel_args_va = input_buffer->gpu_address + kernel_args_offset;
>> >
>> > @@ -636,6 +639,8 @@ static void si_upload_compute_input(struct
>> si_context *sctx,
>> > }
>> >
>> > r600_resource_reference(_buffer, NULL);
>> > +
>> > +   return true;
>> >  }
>> >
>> >  static void si_setup_tgsi_grid(struct si_context *sctx,
>> > @@ -790,8 +795,10 @@ static void si_launch_grid(
>> > si_set_atom_dirty(sctx, sctx->atoms.s.render_cond,
>> false);
>> > }
>> >
>> > -   if (program->input_size || program->ir_type ==
>> PIPE_SHADER_IR_NATIVE)
>> > -   si_upload_compute_input(sctx, code_object, info);
>> > +   if ((program->input_size || program->ir_type ==
>> PIPE_SHADER_IR_NATIVE)
>> > +&& unlikely(!si_upload_compute_input(sctx, code_object,
>> info))) {
>> > +   return false;
>> > +   }
>> >
>> > /* Global buffers */
>> > for (i = 0; i < MAX_GLOBAL_BUFFERS; i++) {
>> > --
>> > 2.7.4
>> >
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 100430] [radv] graphical glitches on dolphin emulator

[bugzilla-daemon]

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

--- Comment #3 from jdr...@gmail.com ---
Created attachment 130504
  --> https://bugs.freedesktop.org/attachment.cgi?id=130504=edit
bad colors on MarioKart (fifo)

I used the fifo player included in dolphin to record 3 images.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/4] si_compute: check NULL return from u_upload_alloc

[Julien Isorce]

-   if (program->input_size || program->ir_type ==
PIPE_SHADER_IR_NATIVE)
-   si_upload_compute_input(sctx, code_object, info);
+   if ((program->input_size ||
+program->ir_type == PIPE_SHADER_IR_NATIVE) &&
+unlikely(!si_upload_compute_input(sctx, code_object, info))) {
+   return false;
+   }

is the indentation ok ?


On 27 March 2017 at 16:39, Marek Olšák  wrote:

> "&&" at the end of the previous line please.
>
> Reviewed-by: Marek Olšák 
>
> Marek
>
> On Mon, Mar 27, 2017 at 3:46 PM, Julien Isorce 
> wrote:
> > Signed-off-by: Julien Isorce 
> > ---
> >  src/gallium/drivers/radeonsi/si_compute.c | 13 ++---
> >  1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> b/src/gallium/drivers/radeonsi/si_compute.c
> > index 46476b6..a38138f 100644
> > --- a/src/gallium/drivers/radeonsi/si_compute.c
> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
> > @@ -579,7 +579,7 @@ static void si_setup_user_sgprs_co_v2(struct
> si_context *sctx,
> > }
> >  }
> >
> > -static void si_upload_compute_input(struct si_context *sctx,
> > +static bool si_upload_compute_input(struct si_context *sctx,
> > const amd_kernel_code_t *code_object,
> > const struct pipe_grid_info *info)
> >  {
> > @@ -602,6 +602,9 @@ static void si_upload_compute_input(struct
> si_context *sctx,
> >_args_offset,
> >(struct pipe_resource**)_buffer,
> _args_ptr);
> >
> > +   if (unlikely(!kernel_args_ptr))
> > +   return false;
> > +
> > kernel_args = (uint32_t*)kernel_args_ptr;
> > kernel_args_va = input_buffer->gpu_address + kernel_args_offset;
> >
> > @@ -636,6 +639,8 @@ static void si_upload_compute_input(struct
> si_context *sctx,
> > }
> >
> > r600_resource_reference(_buffer, NULL);
> > +
> > +   return true;
> >  }
> >
> >  static void si_setup_tgsi_grid(struct si_context *sctx,
> > @@ -790,8 +795,10 @@ static void si_launch_grid(
> > si_set_atom_dirty(sctx, sctx->atoms.s.render_cond,
> false);
> > }
> >
> > -   if (program->input_size || program->ir_type ==
> PIPE_SHADER_IR_NATIVE)
> > -   si_upload_compute_input(sctx, code_object, info);
> > +   if ((program->input_size || program->ir_type ==
> PIPE_SHADER_IR_NATIVE)
> > +&& unlikely(!si_upload_compute_input(sctx, code_object,
> info))) {
> > +   return false;
> > +   }
> >
> > /* Global buffers */
> > for (i = 0; i < MAX_GLOBAL_BUFFERS; i++) {
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 1/5] genxml: New generated header genX_bits.h (v5)

[Emil Velikov]

Hi Chad,

On 25 March 2017 at 02:28, Chad Versace  wrote:
> genX_bits.h contains the sizes of bitfields in genxml instructions,
> structures, and registers. It also defines some functions to query those
> sizes.
>
> isl_surf_init() will use the new header to validate that requested
> pitches fit in their destination bitfields.
>
> What's currently in genX_bits.h:
>
>   - Each CONTAINER::Field from gen*.xml that has a bitsize has a macro
> in genX_bits.h:
>
> #define GEN{N}_CONTAINER_Field_bits {bitsize}
>
>   - For each set of macros whose name, after stripping the GEN prefix,
> is the same, genX_bits.h contains a query function:
>
>   static inline uint32_t __attribute__((pure))
>   CONTAINER_Field_bits(const struct gen_device_info *devinfo);
>
> v2 (Chad Versace):
>   - Parse the XML instead of scraping the generated gen*_pack.h headers.
>
> v3 (Dylan Baker):
>   - Port to Mako.
>
> v4 (Jason Ekstrand):
>   - Make the _bits functions take a gen_device_info.
>
> v5 (Chad Versace):
>   - Fix autotools out-of-tree build.
>   - Fix Android build. Tested with git://github.com/android-ia/manifest.
>   - Fix macro names. They were all missing the "_bits" suffix.
>   - Fix macros names more. Remove all double-underscores.
>   - Unindent all generated code. (It was floating in a sea of whitespace).
>   - Reformat header to appear human-written not machine-generated.
>   - Sort gens from high to low. Newest gens should come first because,
> when we read code, we likely want to read the gen8/9 code and ignore
> the gen4 code. So put the gen4 code at the bottom.
>   - Replace 'const' attributes with 'pure', because the functions now
> have a pointer parameter.
>   - Add --cpp-guard flag. Used by Android.
>   - Kill class FieldCollection. After Jason's rewrite, it was just
> a dict.
>
> Co-authored-by: Dylan Baker 
> Co-authored-by: Jason Ekstrand 
> ---
>  src/intel/Android.genxml.mk |   9 +-
>  src/intel/Makefile.genxml.am|   6 +-
>  src/intel/Makefile.sources  |   6 +-
>  src/intel/genxml/.gitignore |   1 +
>  src/intel/genxml/gen_bits_header.py | 281 
> 
>  5 files changed, 300 insertions(+), 3 deletions(-)
>  create mode 100644 src/intel/genxml/gen_bits_header.py
>
> diff --git a/src/intel/Android.genxml.mk b/src/intel/Android.genxml.mk
> index 79de7843801..842d0e13a33 100644
> --- a/src/intel/Android.genxml.mk
> +++ b/src/intel/Android.genxml.mk
> @@ -46,9 +46,16 @@ LOCAL_GENERATED_SOURCES += $(addprefix $(intermediates)/, 
> $(GENXML_GENERATED_FIL
>  define header-gen
> @mkdir -p $(dir $@)
> @echo "Gen Header: $(PRIVATE_MODULE) <= $(notdir $(@))"
> -   $(hide) $(PRIVATE_SCRIPT) $(PRIVATE_XML) > $@
> +   $(hide) $(PRIVATE_SCRIPT) $(PRIVATE_SCRIPT_FLAGS) $(PRIVATE_XML) > $@
>  endef
>
> +$(intermediates)/genxml/genX_bits.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) 
> $(LOCAL_PATH)/genxml/gen_bits_header.py
> +$(intermediates)/genxml/genX_bits.h: PRIVATE_SCRIPT_FLAGS := 
> --cpp-guard=GENX_BITS_H
> +$(intermediates)/genxml/genX_bits.h: PRIVATE_XML := $(addprefix 
> $(LOCAL_PATH)/,$(GENXML_XML_FILES))
> +$(intermediates)/genxml/genX_bits.h: $(LOCAL_PATH)/genxml/gen_bits_header.py
> +$(intermediates)/genxml/genX_bits.h: $(addprefix 
> $(LOCAL_PATH)/,$(GENXML_XML_FILES))
> +   $(call header-gen)
> +
>  $(intermediates)/genxml/gen4_pack.h: PRIVATE_SCRIPT := $(MESA_PYTHON2) 
> $(LOCAL_PATH)/genxml/gen_pack_header.py
>  $(intermediates)/genxml/gen4_pack.h: PRIVATE_XML := 
> $(LOCAL_PATH)/genxml/gen4.xml
>  $(intermediates)/genxml/gen4_pack.h: $(LOCAL_PATH)/genxml/gen4.xml 
> $(LOCAL_PATH)/genxml/gen_pack_header.py
> diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
> index 01a02b63b44..474b751f5fd 100644
> --- a/src/intel/Makefile.genxml.am
> +++ b/src/intel/Makefile.genxml.am
> @@ -30,7 +30,7 @@ EXTRA_DIST += \
>
>  SUFFIXES = _pack.h _xml.h .xml
>
> -$(GENXML_GENERATED_FILES): genxml/gen_pack_header.py
> +$(GENXML_GENERATED_PACK_FILES): genxml/gen_pack_header.py
>
>  .xml_pack.h:
> $(MKDIR_GEN)
> @@ -42,6 +42,10 @@ $(AUBINATOR_GENERATED_FILES): genxml/gen_zipped_file.py
> $(MKDIR_GEN)
> $(AM_V_GEN) $(PYTHON2) $(srcdir)/genxml/gen_zipped_file.py $< > $@ || 
> ($(RM) $@; false)
>
> +genxml/genX_bits.h: genxml/gen_bits_header.py $(GENXML_XML_FILES)
> +   $(MKDIR_GEN)
> +   $(PYTHON_GEN) $< -o $@ $(addprefix $(srcdir)/,$(GENXML_XML_FILES))
> +
>  EXTRA_DIST += \
> genxml/genX_pack.h \
> genxml/gen_macros.h \
> diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
> index 88bcf60f6e3..c56891643ce 100644
> --- a/src/intel/Makefile.sources
> +++ b/src/intel/Makefile.sources
> @@ -119,7 +119,7 @@ GENXML_XML_FILES = \
> genxml/gen8.xml \
> genxml/gen9.xml
>
> -GENXML_GENERATED_FILES = \
> +GENXML_GENERATED_PACK_FILES = \
> 

[Mesa-dev] [Bug 100430] [radv] graphical glitches on dolphin emulator

[bugzilla-daemon]

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

jdr...@gmail.com changed:

   What|Removed |Added

 CC||jdr...@gmail.com

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

Re: [Mesa-dev] [PATCH v5 1/5] genxml: New generated header genX_bits.h (v5)

[Chad Versace]

On Sat 25 Mar 2017, Dylan Baker wrote:
> Oh, for what it's worth (since I wrote part of this), with the one .keys() 
> thing
> changed:
> Reviewed-by: Dylan Baker 

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

Re: [Mesa-dev] [PATCH v5 1/5] genxml: New generated header genX_bits.h (v5)

[Chad Versace]

On Sat 25 Mar 2017, Dylan Baker wrote:
> Quoting Chad Versace (2017-03-24 19:28:23)
> > genX_bits.h contains the sizes of bitfields in genxml instructions,
> > structures, and registers. It also defines some functions to query those
> > sizes.
> > 
> > isl_surf_init() will use the new header to validate that requested
> > pitches fit in their destination bitfields.
> > 
> > What's currently in genX_bits.h:
> > 
> >   - Each CONTAINER::Field from gen*.xml that has a bitsize has a macro
> > in genX_bits.h:
> > 
> > #define GEN{N}_CONTAINER_Field_bits {bitsize}
> > 
> >   - For each set of macros whose name, after stripping the GEN prefix,
> > is the same, genX_bits.h contains a query function:
> > 
> >   static inline uint32_t __attribute__((pure))
> >   CONTAINER_Field_bits(const struct gen_device_info *devinfo);
> > 
> > v2 (Chad Versace):
> >   - Parse the XML instead of scraping the generated gen*_pack.h headers.
> > 
> > v3 (Dylan Baker):
> >   - Port to Mako.
> > 
> > v4 (Jason Ekstrand):
> >   - Make the _bits functions take a gen_device_info.
> > 
> > v5 (Chad Versace):
> >   - Fix autotools out-of-tree build.
> >   - Fix Android build. Tested with git://github.com/android-ia/manifest.
> >   - Fix macro names. They were all missing the "_bits" suffix.
> >   - Fix macros names more. Remove all double-underscores.
> >   - Unindent all generated code. (It was floating in a sea of whitespace).
> 
> I really think this is a bad design decision, and feels rather like the tail
> wagging the dog. You're sacrificing the readability and editability of the 
> code
> that humans are actually supposed to edit, to gain something that the compiler
> doesn't care about (the most common path), and the indent command can solve in
> the cases where one wants to carefully read the generated code.

I would normally agree with you here, on the topic of generated code,
but this time...

I think you have the head and tail confused :)

Then generated gen*_pack.h headers, I read and search them very
frequently. vim+ctags is always bringing me there. As I'm coding,
they're my first go-to reference for the hardware.  But the generator
script? I've never opened it, not once, until I wrote this patch series.

> >   - Reformat header to appear human-written not machine-generated.
> >   - Sort gens from high to low. Newest gens should come first because,
> > when we read code, we likely want to read the gen8/9 code and ignore
> > the gen4 code. So put the gen4 code at the bottom.
> >   - Replace 'const' attributes with 'pure', because the functions now
> > have a pointer parameter.
> >   - Add --cpp-guard flag. Used by Android.
> >   - Kill class FieldCollection. After Jason's rewrite, it was just
> > a dict.
> > 
> > Co-authored-by: Dylan Baker 
> > Co-authored-by: Jason Ekstrand 
> > ---
> >  src/intel/Android.genxml.mk |   9 +-
> >  src/intel/Makefile.genxml.am|   6 +-
> >  src/intel/Makefile.sources  |   6 +-
> >  src/intel/genxml/.gitignore |   1 +
> >  src/intel/genxml/gen_bits_header.py | 281 
> > 
> >  5 files changed, 300 insertions(+), 3 deletions(-)
> >  create mode 100644 src/intel/genxml/gen_bits_header.py


> > +def end_element(self, name):
> > +if name == 'genxml':
> > +self.gen = None
> > +elif name in ('instruction', 'struct', 'register'):
> > +self.container_name = None
> > +else:
> > +pass
> 
> else: pass is a bit of a pointless statement

I wanted the code here to explicitly emphasize "we're not parsing those
other elements". I could've added a comment, but the else/pass does
a better job at the emphasis.

> > +key = (self.container_name, field_name)
> > +if key not in self.fields.keys():
> 
> key key not in self.feilds
> 
> Which does the same thing, but doesn't build an intermediate list to check.

Nice. I'll fix that.

> > +self.fields[key] = Field(self.container_name, field_name)
> > +self.fields[key].add_gen(self.gen, attrs)
> > +
> > +def parse_args():
> > +p = argparse.ArgumentParser()
> > +p.add_argument('-o', '--output', type=str,
> > +   help="If OUTPUT is unset or '-', then it defaults to 
> > '/dev/stdout'")
> > +p.add_argument('--cpp-guard', type=str,
> > +   help='If unset, then CPP_GUARD is derived from OUTPUT.')
> > +p.add_argument('xml_sources', metavar='XML_SOURCE', nargs='+')
> > +
> > +pargs = p.parse_args()
> > +
> > +if pargs.output in (None, '-'):
> > +pargs.output = '/dev/stdout'
> 
> This is just a suggestion, feel free to ignore
> 
> I forgot to do something here, but this is one case where using
> argparse.FileType might actually be the right thing to do.
> 
> it would like like:
> p.add_argument('-o', '--output', type=argparse.FileType('wb'), 
> default=sys.stdout, ...)
> 
> 

[Mesa-dev] [Bug 100430] [radv] graphical glitches on dolphin emulator

[bugzilla-daemon]

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

--- Comment #2 from Ilia Mirkin  ---
I suspect you'll greatly increase the likelihood of getting this issue
investigated if you include a dolphin fifo log which can be used to reproduce
the issue. [Not sure how those are recorded, I'm sure the dolphin guys will
know though.]

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: Invalidate L2 for TRANSFER_WRITE barriers

[Alex Smith]

On 28 March 2017 at 17:09, Emil Velikov  wrote:

> On 22 March 2017 at 10:06, Bas Nieuwenhuizen 
> wrote:
> > On Tue, Mar 21, 2017 at 1:02 PM, Alex Smith 
> wrote:
> >> CP DMA and PKT3_WRITE_DATA (in CmdUpdateBuffer) don't (currently) write
> >> through L2. Therefore, to make these writes visible to later accesses
> >> we must invalidate L2 rather than just writing it back, to avoid the
> >> possibility that stale data is read through L2.
> >>
> >> Cc: "17.0" 
> >> Signed-off-by: Alex Smith 
> >> ---
> >> It's possible for both CP DMA and PKT3_WRITE_DATA to write through L2
> >> as far as I can see, and changing things so that they do also solves
> >> the problems that this patch fixes.
> >>
> >> However, I don't know what the exact consequences of doing so are, or
> >> whether there are any situations where that shouldn't be done, so I've
> >> gone with this fix instead as it seems like a safer option for now.
> >
> > Yeah we should be able to. I'm more comfortable sending this patch to
> > stable though, so this patch is
> >
> Bas, others,
>
> Patch addresses radv_{src,dst}_access_flush() which landed with commit
> 6dbb0eaccc3, after the 17.0 branchpoint.
>

Oops, my mistake.

I think radv_CmdPipelineBarrier on the 17.0 branch still needs
RADV_CMD_FLAG_INV_GLOBAL_L2
added for TRANSFER_WRITE barriers at least. Bas, do you think that should
be added in a separate patch just for stable, or would you prefer to push
those later changes to stable as well? Looks like there's some fixes in
those as well.

Alex


>
> From a quick look, the functions has been fixed/enhanced with the
> following 7 commits. Some of which require additional patches.
> If we want this in stable, please provide a backport or branch based
> on top of mesa-17.0.2.
>
> Thanks
> Emil
>
> 40e0dbf96c4d812be940561f5732b1b0e44b5e1d
> f3dc318464b786c2696e650e7c69984b5453624b
> b075eb7d476eb750092f72e7ec65bc41003fa658
> dd094e4ff9ff0967b515a4330e40feca55247e25
> 7a600bbc8186fef9475bedfe6d58a54011a8022b
> 0567ab0407e4058c108443b90b7c23a40c391c3b
> f92a118434452df201cda6d9ec2405aca669b104
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 2/5] isl: Validate the calculated row pitch (v4)

[Jason Ekstrand]

On Tue, Mar 28, 2017 at 9:15 AM, Chad Versace 
wrote:

> On Sat 25 Mar 2017, Jason Ekstrand wrote:
> >
> >
> > On March 24, 2017 7:29:05 PM Chad Versace 
> wrote:
> >
> > > Validate that isl_surf::row_pitch fits in the below bitfields,
> > > if applicable based on isl_surf::usage.
> > >
> > > RENDER_SURFACE_STATE::SurfacePitch
> > > RENDER_SURFACE_STATE::AuxiliarySurfacePitch
> > > 3DSTATE_DEPTH_BUFFER::SurfacePitch
> > > 3DSTATE_HIER_DEPTH_BUFFER::SurfacePitch
> > >
> > > v2:
> > >   -Add a Makefile dependency on generated header genX_bits.h.
> > > v3:
> > >   - Test ISL_SURF_USAGE_STORAGE_BIT too. [for jekstrand]
> > >   - Drop explicity dependency on generated header. [for emil]
> > > v4:
> > >   - Rebase for new gen_bits_header.py script.
> > >   - Replace gen_10x with gen_device_info*.
> > > ---
> > >  src/intel/isl/isl.c | 71 ++
> ++-
> > >  1 file changed, 65 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> > > index 81f40b6a6fb..4777113de84 100644
>
>
>
> > > +   if (dim_layout == ISL_DIM_LAYOUT_GEN9_1D) {
> > > +  /* SurfacePitch is ignored for this layout.How should we
> validate it? */
> > > +  isl_finishme("validate row pitch for ISL_DIM_LAYOUT_GEN9_1D");
> >
> > We validate qpitch if anything.  But the regular pitch isn't just
> ignored,
> > it's meaningless.  I think we can drop the finishme.
>
> Done.
>
> > > +   if (((surf_info->usage & ISL_SURF_USAGE_RENDER_TARGET_BIT) ||
> > > +(surf_info->usage & ISL_SURF_USAGE_TEXTURE_BIT) ||
> > > +(surf_info->usage & ISL_SURF_USAGE_STORAGE_BIT)) &&
> > > +   !pitch_in_range(row_pitch,
> > > RENDER_SURFACE_STATE_SurfacePitch_bits(dev->info)))
> > > +  return false;
> >
> > You know... "(thing & foo) || (thing & bar)" is equivalent to "thing &
> (foo
> > | bar)".  Not that you need to change but sometimes its a but nicer.
>
> I know :). I think my style looks nicer, and the compiler should emit
> the same code. But I changed it to use '|' locally so that it matches
> the style in other Intel code.
>

I don't really care all that much.  In my brain one is a "does it have this
bit or does it have this bit or does it have that bit" vs. "does it have
one of these bits".  It really doesn't matter...


> > > +
> > > +   if (((surf_info->usage & ISL_SURF_USAGE_CCS_BIT) ||
> > > +(surf_info->usage & ISL_SURF_USAGE_MCS_BIT)) &&
> > > +   !pitch_in_range(row_pitch_tiles,
> > > RENDER_SURFACE_STATE_AuxiliarySurfacePitch_bits(dev->info)))
> > > +  return false;
> > > +
> > > +   if ((surf_info->usage & ISL_SURF_USAGE_DEPTH_BIT) &&
> > > +   !pitch_in_range(row_pitch,
> > > _3DSTATE_DEPTH_BUFFER_SurfacePitch_bits(dev->info)))
> > > +  return false;
> > > +
> > > +   if ((surf_info->usage & ISL_SURF_USAGE_HIZ_BIT) &&
> > > +   !pitch_in_range(row_pitch,
> > > _3DSTATE_HIER_DEPTH_BUFFER_SurfacePitch_bits(dev->info)))
> >
> > On gen8+, if the surface has the TEXTURE bit set we should check it
> against
> > AuxiliarySurfacePitch as well.
>
> Good catch.
>
> I've already test the branch as-is, so I hesitate to add this fixup. It
> can come as an immediate follow-up patch.
>

That's fine.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Meson mesademos (Was: [RFC libdrm 0/2] Replace the build system with meson)

[Jose Fonseca]

On 28/03/17 00:12, Dylan Baker wrote:

Quoting Jose Fonseca (2017-03-27 09:58:59)

On 27/03/17 17:42, Dylan Baker wrote:

Quoting Jose Fonseca (2017-03-27 09:31:04)

On 27/03/17 17:24, Dylan Baker wrote:

Quoting Jose Fonseca (2017-03-26 14:53:50)

I've pushed the branch to mesa/demos, so we can all collaborate without
wasting time crossporting patches between private branches.

   https://cgit.freedesktop.org/mesa/demos/commit/?h=meson

Unfortunately, I couldn't actually go very far until I hit a wall, as
you can see in the last commit message.


The issue is that Windows has no standard paths for dependencies
includes/libraries (like /usr/include or /usr/lib), nor standard tool
for dependencies (no pkgconfig).  But it seems that Meson presumes any
unknown dependency can be resolved with pkgconfig.


The question is: how do I tell Meson where the GLEW headers/library for
MinGW are supposed to be found?


I know one solution might be Meson Wraps.  Is that the only way?


CMake makes it very easy to do it (via Cache files as explained in my
commit message.)  Is there a way to achieve the same, perhaps via
cross_file properties or something like that?


Jose


I think there are two ways you could solve this:

Wraps are probably the most generically correct method; what I mean by that is
that a proper wrap would solve the problem for everyone, on every operating
system, forever.


Yeah, that sounded a good solution, particularly for windows where's so
much easier to just build the dependencies as a subproject rather than
fetch dependencies from somewhere, since MSVC RT versions have to match
and so.

 > That said, I took a look at GLEW and it doesn't look like a

straightforward project to port to meson, since it uses a huge pile of gnu
makefiles for compilation, without any autoconf/cmake/etc. I still might take a
swing at it since I want to know how hard it would be to write a wrap file for
something like GLEW (and it would probably be a pretty useful project to wrap)
where a meson build system is likely never going to go upstream.


BTW, regarding GLEW, some time ago I actually prototyped using GLAD
instead of GLEW for mesademos:

   https://cgit.freedesktop.org/~jrfonseca/mesademos/log/?h=glad

I find GLAD much nicer that GLEW: it's easier to build, it uses upstream
XML files, it supports EGL, and it's easy to bundle.

Maybe we could migrate mesademos to GLAD as part of this work instead of
trying to get glew "mesonfied".


The other option I think you can use use is cross properties[1], which I believe
is the closest thing meson has to cmake's cache files.

I've pushed a couple of commits, the last one implements the cross properties
idea, which gets the build farther, but then it can't find the glut headers,
and I don't understand why, since "cc.has_header('GL/glut')" returns true. I
still think that wraps are a better plan, but I'll have to spend some time today
working on a glew wrap.

[1] https://github.com/mesonbuild/meson/wiki/Cross-compilation (at the bottom
under the heading "Custom Data")


I'm running out of time today, but I'll try to take a look tomorrow.

Jose



I'd had a similar thought, but thought of libpeoxy? It supports the platforms we
want, and already has a meson build system that works for windows.


I have no experience with libepoxy.  I know GLAD is really easy to
understand, use and integrate.  It's completly agnostic to toolkits like
GLUT/GLFW/etc doesn't try to alias equivalent entrypoints, or anything
smart like libepoxy.

In particular I don't fully understand libepoxy behavior regarding
wglMakeCurrent is, and whether that will create problems with GLUT,
since GLUT will call wglMakeCurrent..


Jose


Okay, I have libepoxy working for windows. I also got libepoxy working as a
subproject, but it took a bit of hacking on their build system (there's
some things they're doing that make them non-subproject safe, I'll send patches
and work that out with them.

https://github.com/dcbaker/libepoxy.git fix-suproject


Thanks.

GLEW is not the only one case though.  There's also FREEGLUT.  So we 
can't really avoid the problem of external windows binaries/subprojects.


So I've been thinking, and I suspect is better if first get things 
working with binary GLEW / FREGLUT projects, then try the glew -> 
libepoxy in a 2nd step, so there's less to take in to merge meson into 
master.



Clone that repo into $mesa-demos-root/subprojects and things should just work,
or mostly work. I got epoxy compiling, but ran into some issues in the mingw glu
header.

Dylan


I'm pretty sure the problem with MinGW glu is the lack of windows.h.  We 
need to do the same as CMakeLists.txt snippet quoted below.


I'm running out of time today, but I'll look into porting this over to 
meson tomorrow if you don't beat me to it.


Jose



if (WIN32)
# Nobody likes to include windows.h:
# - Microsoft's GL/gl.h header depends on windows.h but doesn't 
include it;
# - GLEW temporarily 

Re: [Mesa-dev] [PATCH v5 2/5] isl: Validate the calculated row pitch (v4)

[Chad Versace]

On Sat 25 Mar 2017, Jason Ekstrand wrote:
> 
> 
> On March 24, 2017 7:29:05 PM Chad Versace  wrote:
> 
> > Validate that isl_surf::row_pitch fits in the below bitfields,
> > if applicable based on isl_surf::usage.
> > 
> > RENDER_SURFACE_STATE::SurfacePitch
> > RENDER_SURFACE_STATE::AuxiliarySurfacePitch
> > 3DSTATE_DEPTH_BUFFER::SurfacePitch
> > 3DSTATE_HIER_DEPTH_BUFFER::SurfacePitch
> > 
> > v2:
> >   -Add a Makefile dependency on generated header genX_bits.h.
> > v3:
> >   - Test ISL_SURF_USAGE_STORAGE_BIT too. [for jekstrand]
> >   - Drop explicity dependency on generated header. [for emil]
> > v4:
> >   - Rebase for new gen_bits_header.py script.
> >   - Replace gen_10x with gen_device_info*.
> > ---
> >  src/intel/isl/isl.c | 71 
> > -
> >  1 file changed, 65 insertions(+), 6 deletions(-)
> > 
> > diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> > index 81f40b6a6fb..4777113de84 100644



> > +   if (dim_layout == ISL_DIM_LAYOUT_GEN9_1D) {
> > +  /* SurfacePitch is ignored for this layout.How should we validate 
> > it? */
> > +  isl_finishme("validate row pitch for ISL_DIM_LAYOUT_GEN9_1D");
> 
> We validate qpitch if anything.  But the regular pitch isn't just ignored,
> it's meaningless.  I think we can drop the finishme.

Done.

> > +   if (((surf_info->usage & ISL_SURF_USAGE_RENDER_TARGET_BIT) ||
> > +(surf_info->usage & ISL_SURF_USAGE_TEXTURE_BIT) ||
> > +(surf_info->usage & ISL_SURF_USAGE_STORAGE_BIT)) &&
> > +   !pitch_in_range(row_pitch,
> > RENDER_SURFACE_STATE_SurfacePitch_bits(dev->info)))
> > +  return false;
> 
> You know... "(thing & foo) || (thing & bar)" is equivalent to "thing & (foo
> | bar)".  Not that you need to change but sometimes its a but nicer.

I know :). I think my style looks nicer, and the compiler should emit
the same code. But I changed it to use '|' locally so that it matches
the style in other Intel code.

> > +
> > +   if (((surf_info->usage & ISL_SURF_USAGE_CCS_BIT) ||
> > +(surf_info->usage & ISL_SURF_USAGE_MCS_BIT)) &&
> > +   !pitch_in_range(row_pitch_tiles,
> > RENDER_SURFACE_STATE_AuxiliarySurfacePitch_bits(dev->info)))
> > +  return false;
> > +
> > +   if ((surf_info->usage & ISL_SURF_USAGE_DEPTH_BIT) &&
> > +   !pitch_in_range(row_pitch,
> > _3DSTATE_DEPTH_BUFFER_SurfacePitch_bits(dev->info)))
> > +  return false;
> > +
> > +   if ((surf_info->usage & ISL_SURF_USAGE_HIZ_BIT) &&
> > +   !pitch_in_range(row_pitch,
> > _3DSTATE_HIER_DEPTH_BUFFER_SurfacePitch_bits(dev->info)))
> 
> On gen8+, if the surface has the TEXTURE bit set we should check it against
> AuxiliarySurfacePitch as well.

Good catch.

I've already test the branch as-is, so I hesitate to add this fixup. It
can come as an immediate follow-up patch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: Invalidate L2 for TRANSFER_WRITE barriers

[Emil Velikov]

On 22 March 2017 at 10:06, Bas Nieuwenhuizen  wrote:
> On Tue, Mar 21, 2017 at 1:02 PM, Alex Smith  
> wrote:
>> CP DMA and PKT3_WRITE_DATA (in CmdUpdateBuffer) don't (currently) write
>> through L2. Therefore, to make these writes visible to later accesses
>> we must invalidate L2 rather than just writing it back, to avoid the
>> possibility that stale data is read through L2.
>>
>> Cc: "17.0" 
>> Signed-off-by: Alex Smith 
>> ---
>> It's possible for both CP DMA and PKT3_WRITE_DATA to write through L2
>> as far as I can see, and changing things so that they do also solves
>> the problems that this patch fixes.
>>
>> However, I don't know what the exact consequences of doing so are, or
>> whether there are any situations where that shouldn't be done, so I've
>> gone with this fix instead as it seems like a safer option for now.
>
> Yeah we should be able to. I'm more comfortable sending this patch to
> stable though, so this patch is
>
Bas, others,

Patch addresses radv_{src,dst}_access_flush() which landed with commit
6dbb0eaccc3, after the 17.0 branchpoint.

From a quick look, the functions has been fixed/enhanced with the
following 7 commits. Some of which require additional patches.
If we want this in stable, please provide a backport or branch based
on top of mesa-17.0.2.

Thanks
Emil

40e0dbf96c4d812be940561f5732b1b0e44b5e1d
f3dc318464b786c2696e650e7c69984b5453624b
b075eb7d476eb750092f72e7ec65bc41003fa658
dd094e4ff9ff0967b515a4330e40feca55247e25
7a600bbc8186fef9475bedfe6d58a54011a8022b
0567ab0407e4058c108443b90b7c23a40c391c3b
f92a118434452df201cda6d9ec2405aca669b104
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] anv: Use subpass dependencies for flushes

[Jason Ekstrand]

Nanley,
Mind taking a look at these?

On Tue, Mar 14, 2017 at 7:55 AM, Jason Ekstrand 
wrote:

> Instead of figuring it all out ourselves, just use the information given
> to us by the client.
> ---
>  src/intel/vulkan/anv_blorp.c   | 88 --
> 
>  src/intel/vulkan/genX_cmd_buffer.c | 10 +
>  2 files changed, 18 insertions(+), 80 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index 8de339c..41966d6 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -1070,80 +1070,6 @@ enum subpass_stage {
>  };
>
>  static bool
> -attachment_needs_flush(struct anv_cmd_buffer *cmd_buffer,
> -   struct anv_render_pass_attachment *att,
> -   enum subpass_stage stage)
> -{
> -   struct anv_render_pass *pass = cmd_buffer->state.pass;
> -   const uint32_t subpass_idx = anv_get_subpass_id(_buffer->state);
> -
> -   /* We handle this subpass specially based on the current stage */
> -   enum anv_subpass_usage usage = att->subpass_usage[subpass_idx];
> -   switch (stage) {
> -   case SUBPASS_STAGE_LOAD:
> -  if (usage & (ANV_SUBPASS_USAGE_INPUT |
> ANV_SUBPASS_USAGE_RESOLVE_SRC))
> - return true;
> -  break;
> -
> -   case SUBPASS_STAGE_DRAW:
> -  if (usage & ANV_SUBPASS_USAGE_RESOLVE_SRC)
> - return true;
> -  break;
> -
> -   default:
> -  break;
> -   }
> -
> -   for (uint32_t s = subpass_idx + 1; s < pass->subpass_count; s++) {
> -  usage = att->subpass_usage[s];
> -
> -  /* If this attachment is going to be used as an input in this or any
> -   * future subpass, then we need to flush its cache and invalidate
> the
> -   * texture cache.
> -   */
> -  if (att->subpass_usage[s] & ANV_SUBPASS_USAGE_INPUT)
> - return true;
> -
> -  if (usage & (ANV_SUBPASS_USAGE_DRAW | ANV_SUBPASS_USAGE_RESOLVE_DST))
> {
> - /* We found another subpass that draws to this attachment.  We'll
> -  * wait to resolve until then.
> -  */
> - return false;
> -  }
> -   }
> -
> -   return false;
> -}
> -
> -static void
> -anv_cmd_buffer_flush_attachments(struct anv_cmd_buffer *cmd_buffer,
> - enum subpass_stage stage)
> -{
> -   struct anv_subpass *subpass = cmd_buffer->state.subpass;
> -   struct anv_render_pass *pass = cmd_buffer->state.pass;
> -
> -   for (uint32_t i = 0; i < subpass->color_count; ++i) {
> -  uint32_t att = subpass->color_attachments[i].attachment;
> -  assert(att < pass->attachment_count);
> -  if (attachment_needs_flush(cmd_buffer, >attachments[att],
> stage)) {
> - cmd_buffer->state.pending_pipe_bits |=
> -ANV_PIPE_TEXTURE_CACHE_INVALIDATE_BIT |
> -ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT;
> -  }
> -   }
> -
> -   if (subpass->depth_stencil_attachment.attachment !=
> VK_ATTACHMENT_UNUSED) {
> -  uint32_t att = subpass->depth_stencil_attachment.attachment;
> -  assert(att < pass->attachment_count);
> -  if (attachment_needs_flush(cmd_buffer, >attachments[att],
> stage)) {
> - cmd_buffer->state.pending_pipe_bits |=
> -ANV_PIPE_TEXTURE_CACHE_INVALIDATE_BIT |
> -ANV_PIPE_DEPTH_CACHE_FLUSH_BIT;
> -  }
> -   }
> -}
> -
> -static bool
>  subpass_needs_clear(const struct anv_cmd_buffer *cmd_buffer)
>  {
> const struct anv_cmd_state *cmd_state = _buffer->state;
> @@ -1327,8 +1253,6 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer
> *cmd_buffer)
> }
>
> blorp_batch_finish();
> -
> -   anv_cmd_buffer_flush_attachments(cmd_buffer, SUBPASS_STAGE_LOAD);
>  }
>
>  static void
> @@ -1554,9 +1478,15 @@ anv_cmd_buffer_resolve_subpass(struct
> anv_cmd_buffer *cmd_buffer)
>   subpass->color_attachments[i].attachment);
> }
>
> -   anv_cmd_buffer_flush_attachments(cmd_buffer, SUBPASS_STAGE_DRAW);
> -
> if (subpass->has_resolve) {
> +  /* We are about to do some MSAA resolves.  We need to flush so that
> the
> +   * result of writes to the MSAA color attachments show up in the
> sampler
> +   * when we blit to the single-sampled resolve target.
> +   */
> +  cmd_buffer->state.pending_pipe_bits |=
> + ANV_PIPE_TEXTURE_CACHE_INVALIDATE_BIT |
> + ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT;
> +
>for (uint32_t i = 0; i < subpass->color_count; ++i) {
>   uint32_t src_att = subpass->color_attachments[i].attachment;
>   uint32_t dst_att = subpass->resolve_attachments[i].attachment;
> @@ -1594,8 +1524,6 @@ anv_cmd_buffer_resolve_subpass(struct
> anv_cmd_buffer *cmd_buffer)
>
>   ccs_resolve_attachment(cmd_buffer, , dst_att);
>}
> -
> -  anv_cmd_buffer_flush_attachments(cmd_buffer,
> SUBPASS_STAGE_RESOLVE);
> }
>
> blorp_batch_finish();
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> 

[Mesa-dev] [Bug 100430] [radv] graphical glitches on dolphin emulator

[bugzilla-daemon]

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

Christian Lanig  changed:

   What|Removed |Added

 CC||freedesktop@lanig.email

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

Re: [Mesa-dev] [PATCH] tests/cache_test: allow crossing mount points

[Juan A. Suarez Romero]

On Tue, 2017-03-28 at 17:50 +0200, Nicolai Hähnle wrote:
>  The crossing happens because I'm running it inside a docker container,
> > which uses internally an overlayfs. This means that some of those
> > subdirectories can be in one mountpoint and others in other mountpoint.
> >   This seems to be how nftw() call handles this overlayfs.
> 
> I still don't quite get it. My understanding is that overlayfs allows 
> you to merge two directory trees, e.g. for setups where you have a 
> read-only base, and a writable "overlay" which gets used during some 
> operation and then thrown away.
> 
> If ntfw fails to remove some files, then which ones are in the overlay 
> and which ones in the "underlay"?
> 
> Or... oh wait. Here's what the kernel docs say:
> 
>     This approach is 'hybrid' because the objects that appear in the
>     filesystem do not all appear to belong to that filesystem.  In many
>     cases an object accessed in the union will be indistinguishable
>     from accessing the corresponding object from the original filesystem.
>     This is most obvious from the 'st_dev' field returned by stat(2).
> 
> So it seems the issue is that the directories themselves are considered 
> to belong to the overlayfs itself, while the created files of the cache 
> belong to the "overlay" (temporary) filesystem? That's annoying, but 
> there's nothing we can do about it. The patch is:
> 


Yeah, seems so. It's a nasty bug, but as nftw() is only used in the
test, I think it is safe to remove the flag.

Thanks for reviewing it!

> Reviewed-by: Nicolai Hähnle 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] tests/cache_test: allow crossing mount points

[Nicolai Hähnle]

On 28.03.2017 17:32, Juan A. Suarez Romero wrote:

On Tue, 2017-03-28 at 16:53 +0200, Nicolai Hähnle wrote:

On 25.03.2017 01:40, Juan A. Suarez Romero wrote:

When using an overlayfs system (like a Docker container), rmrf_local()
fails because part of the files to be removed are in different mount
points (layouts). And thus cache-test fails.


Can you explain a bit more how this can happen? I thought the test does

mkdir(CACHE_TEST_TMP, 0755);

...

rmrf_local(CACHE_TEST_TMP);

How does this end up crossing mounts?



Between both calls, we create the disk cache, which creates
subdirectories and files inside.


The crossing happens because I'm running it inside a docker container,
which uses internally an overlayfs. This means that some of those
subdirectories can be in one mountpoint and others in other mountpoint.
 This seems to be how nftw() call handles this overlayfs.


I still don't quite get it. My understanding is that overlayfs allows 
you to merge two directory trees, e.g. for setups where you have a 
read-only base, and a writable "overlay" which gets used during some 
operation and then thrown away.


If ntfw fails to remove some files, then which ones are in the overlay 
and which ones in the "underlay"?


Or... oh wait. Here's what the kernel docs say:

   This approach is 'hybrid' because the objects that appear in the
   filesystem do not all appear to belong to that filesystem.  In many
   cases an object accessed in the union will be indistinguishable
   from accessing the corresponding object from the original filesystem.
   This is most obvious from the 'st_dev' field returned by stat(2).

So it seems the issue is that the directories themselves are considered 
to belong to the overlayfs itself, while the created files of the cache 
belong to the "overlay" (temporary) filesystem? That's annoying, but 
there's nothing we can do about it. The patch is:


Reviewed-by: Nicolai Hähnle 





J.A.







Letting crossing mount points is not a big problem, specially because
this is just for a test, not to be used in real code.
---
 src/compiler/glsl/tests/cache_test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/glsl/tests/cache_test.c 
b/src/compiler/glsl/tests/cache_test.c
index 2302f44..ac60197 100644
--- a/src/compiler/glsl/tests/cache_test.c
+++ b/src/compiler/glsl/tests/cache_test.c
@@ -124,7 +124,7 @@ rmrf_local(const char *path)
if (path == NULL || *path == '\0' || *path != '.')
   return -1;

-   return nftw(path, remove_entry, 64, FTW_DEPTH | FTW_PHYS | FTW_MOUNT);
+   return nftw(path, remove_entry, 64, FTW_DEPTH | FTW_PHYS);
 }

 static void







--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 100430] [radv] graphical glitches on dolphin emulator

[bugzilla-daemon]

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

--- Comment #1 from Christian Lanig  ---
I confirm this bug.

Dolphin 5.0-741d230-dirty
Ubuntu 17.04 with MESA git and Kernel 4.11 RC4
Ryzen 7 1700X
RX 480 8GiB
32 DDR4 2933 MHz ECC

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/mesa: EGLImageTarget* error handling

[Nicolai Hähnle]

On 27.03.2017 12:11, Philipp Zabel wrote:

Stop trying to specify texture or renderbuffer objects for unsupported
EGL images. Generate the error codes specified in the OES_EGL_image
extension.

EGLImageTargetTexture2D and EGLImageTargetRenderbuffer would call
the pipe driver's create_surface callback without ever checking that
the given EGL image is actually compatible with the chosen target
texture or renderbuffer. This patch adds a call to the pipe driver's
is_format_supported callback and generates an INVALID_OPERATION error
for unsupported EGL images. If the EGL image handle does not describe
a valid EGL image, an INVALID_VALUE error is generated.

Signed-off-by: Philipp Zabel 
---
 src/mesa/state_tracker/st_cb_eglimage.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_eglimage.c 
b/src/mesa/state_tracker/st_cb_eglimage.c
index e1fc9bff75..30b177731e 100644
--- a/src/mesa/state_tracker/st_cb_eglimage.c
+++ b/src/mesa/state_tracker/st_cb_eglimage.c
@@ -25,6 +25,7 @@
  *Chia-I Wu 
  */

+#include "main/errors.h"
 #include "main/texobj.h"
 #include "main/teximage.h"
 #include "util/u_inlines.h"
@@ -44,9 +45,11 @@
  * FIXME: I think this should operate on resources, not surfaces
  */
 static struct pipe_surface *
-st_egl_image_get_surface(struct gl_context *ctx, GLeglImageOES image_handle)
+st_egl_image_get_surface(struct gl_context *ctx, GLeglImageOES image_handle,
+ unsigned usage, const char *error)
 {
struct st_context *st = st_context(ctx);
+   struct pipe_screen *screen = st->pipe->screen;
struct st_manager *smapi =
   (struct st_manager *) st->iface.st_context_private;
struct st_egl_image stimg;
@@ -56,8 +59,19 @@ st_egl_image_get_surface(struct gl_context *ctx, 
GLeglImageOES image_handle)
   return NULL;

memset(, 0, sizeof(stimg));
-   if (!smapi->get_egl_image(smapi, (void *) image_handle, ))
+   if (!smapi->get_egl_image(smapi, (void *) image_handle, )) {
+  /* image_handle does not refer to a valid EGL image object */
+  _mesa_error(ctx, GL_INVALID_VALUE, error);
   return NULL;
+   }
+
+   if (!screen->is_format_supported(screen, stimg.format, PIPE_TEXTURE_2D,
+stimg.texture->nr_samples,
+PIPE_BIND_RENDER_TARGET)) {
+  /* unable to specify a texture object using the specified EGL image */
+  _mesa_error(ctx, GL_INVALID_OPERATION, 
"glEGLImageTargetRenderbufferStorage");


This block still needs to be changed to use the usage and error 
parameters instead of hard-coded values. With that fixed, the series is


Reviewed-by: Nicolai Hähnle 



+  return NULL;
+   }

u_surface_default_template(_tmpl, stimg.texture);
surf_tmpl.format = stimg.format;
@@ -108,7 +122,8 @@ st_egl_image_target_renderbuffer_storage(struct gl_context 
*ctx,
struct st_renderbuffer *strb = st_renderbuffer(rb);
struct pipe_surface *ps;

-   ps = st_egl_image_get_surface(ctx, image_handle);
+   ps = st_egl_image_get_surface(ctx, image_handle, PIPE_BIND_RENDER_TARGET,
+"glEGLImageTargetRenderbufferStorage");
if (ps) {
   strb->Base.Width = ps->width;
   strb->Base.Height = ps->height;
@@ -192,7 +207,8 @@ st_egl_image_target_texture_2d(struct gl_context *ctx, 
GLenum target,
 {
struct pipe_surface *ps;

-   ps = st_egl_image_get_surface(ctx, image_handle);
+   ps = st_egl_image_get_surface(ctx, image_handle, PIPE_BIND_SAMPLER_VIEW,
+"glEGLImageTargetTexture2D");
if (ps) {
   st_bind_surface(ctx, target, texObj, texImage, ps);
   pipe_surface_reference(, NULL);




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] tests/cache_test: allow crossing mount points

[Juan A. Suarez Romero]

On Tue, 2017-03-28 at 16:53 +0200, Nicolai Hähnle wrote:
> On 25.03.2017 01:40, Juan A. Suarez Romero wrote:
> > When using an overlayfs system (like a Docker container), rmrf_local()
> > fails because part of the files to be removed are in different mount
> > points (layouts). And thus cache-test fails.
> 
> Can you explain a bit more how this can happen? I thought the test does
> 
> mkdir(CACHE_TEST_TMP, 0755);
> 
> ...
> 
> rmrf_local(CACHE_TEST_TMP);
> 
> How does this end up crossing mounts?
> 

Between both calls, we create the disk cache, which creates
subdirectories and files inside.


The crossing happens because I'm running it inside a docker container,
which uses internally an overlayfs. This means that some of those
subdirectories can be in one mountpoint and others in other mountpoint.
 This seems to be how nftw() call handles this overlayfs.


J.A.


> 
> 
> > 
> > Letting crossing mount points is not a big problem, specially because
> > this is just for a test, not to be used in real code.
> > ---
> >  src/compiler/glsl/tests/cache_test.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/compiler/glsl/tests/cache_test.c 
> > b/src/compiler/glsl/tests/cache_test.c
> > index 2302f44..ac60197 100644
> > --- a/src/compiler/glsl/tests/cache_test.c
> > +++ b/src/compiler/glsl/tests/cache_test.c
> > @@ -124,7 +124,7 @@ rmrf_local(const char *path)
> > if (path == NULL || *path == '\0' || *path != '.')
> >return -1;
> > 
> > -   return nftw(path, remove_entry, 64, FTW_DEPTH | FTW_PHYS | FTW_MOUNT);
> > +   return nftw(path, remove_entry, 64, FTW_DEPTH | FTW_PHYS);
> >  }
> > 
> >  static void
> > 
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] nir: Add support for 8 and 16-bit types

[Jason Ekstrand]

Sorry I haven't gotten back on this.  It got lost somehow.

On Fri, Mar 10, 2017 at 1:56 AM, Iago Toral  wrote:

> On Thu, 2017-03-09 at 14:05 -0800, Jason Ekstrand wrote:
> > ---
> >  src/compiler/nir/nir.h   |  4 
> >  src/compiler/nir/nir_constant_expressions.py | 16 +++-
> >  src/compiler/nir/nir_opcodes.py  |  6 +-
> >  3 files changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> > index 57b8be3..eaa103d 100644
> > --- a/src/compiler/nir/nir.h
> > +++ b/src/compiler/nir/nir.h
> > @@ -105,6 +105,10 @@ typedef enum {
> >  typedef union {
> > float f32[4];
> > double f64[4];
> > +   int8_t i8[4];
> > +   uint8_t u8[4];
> > +   int16_t i16[4];
> > +   uint16_t u16[4];
> > int32_t i32[4];
> > uint32_t u32[4];
> > int64_t i64[4];
> >
> > diff --git a/src/compiler/nir/nir_constant_expressions.py
> > b/src/compiler/nir/nir_constant_expressions.py
> > index aecca8b..cbda4b1 100644
> > --- a/src/compiler/nir/nir_constant_expressions.py
> > +++ b/src/compiler/nir/nir_constant_expressions.py
> > @@ -14,8 +14,10 @@ def type_size(type_):
> >  def type_sizes(type_):
> >  if type_has_size(type_):
> >  return [type_size(type_)]
> > +elif type_ == 'float':
> > +return [16, 32, 64]
> >  else:
> > -return [32, 64]
> > +return [8, 16, 32, 64]
> >
> >  def type_add_size(type_, size):
> >  if type_has_size(type_):
> > @@ -34,6 +36,8 @@ def op_bit_sizes(op):
> >  def get_const_field(type_):
> >  if type_ == "bool32":
> >  return "u32"
> > +elif type_ == "float16":
> > +return "u16"
>
> I was wondering why not have a f16 field with type float16_t
> in nir_const_value instead,  but reading the rest of the patch it seems
> we really want to work with 32-bit floats and then encode results back to
> 16-bit values? Is it because there are some operations that we can't
> implement directly with half-floats?
>

Yes.  CPUs cannot, in general, work with 16-bit floats so there is no
actual float16_t type in C.  We typedef float to float16_t below just
because it makes the codegen easier.  In reality, all 16-bit operations
have to be done in 32-bit with a manual conversion to/from 16-bit float on
both sides.


> Iago
>
> >  else:
> >  m = type_split_re.match(type_)
> >  if not m:
> > @@ -246,6 +250,7 @@ unpack_half_1x16(uint16_t u)
> >  }
> >
> >  /* Some typed vector structures to make things like src0.y work */
> > +typedef float float16_t;
> >  typedef float float32_t;
> >  typedef double float64_t;
> >  typedef bool bool32_t;
> > @@ -297,6 +302,8 @@ evaluate_${name}(MAYBE_UNUSED unsigned
> > num_components, unsigned bit_size,
> >   % for k in range(op.input_sizes[j]):
> >  % if input_types[j] == "bool32":
> > _src[${j}].u32[${k}] != 0,
> > +% elif input_types[j] == "float16":
> > +   _mesa_half_to_float(_src[${j}].u16[${k}]),
> >  % else:
> > _src[${j}].${get_const_field(input_types[j])}[${k}],
> >  % endif
> > @@ -322,6 +329,9 @@ evaluate_${name}(MAYBE_UNUSED unsigned
> > num_components, unsigned bit_size,
> ><% continue %>
> > % elif input_types[j] == "bool32":
> >const bool src${j} = _src[${j}].u32[_i] != 0;
> > +   % elif input_types[j] == "float16":
> > +  const float src${j} =
> > + _mesa_half_to_float(_src[${j}].u16[_i]);
> > % else:
> >const ${input_types[j]}_t src${j} =
> >   _src[${j}].${get_const_field(input_types[j])}[_
> > i];
> > @@ -344,6 +354,8 @@ evaluate_${name}(MAYBE_UNUSED unsigned
> > num_components, unsigned bit_size,
> >  % if output_type == "bool32":
> > ## Sanitize the C value to a proper NIR bool
> > _dst_val.u32[_i] = dst ? NIR_TRUE : NIR_FALSE;
> > +% elif output_type == "float16":
> > +   _dst_val.u16[_i] = _mesa_float_to_half(dst);
> >  % else:
> > _dst_val.${get_const_field(output_type)}[_i] = dst;
> >  % endif
> > @@ -371,6 +383,8 @@ evaluate_${name}(MAYBE_UNUSED unsigned
> > num_components, unsigned bit_size,
> >  % if output_type == "bool32":
> > ## Sanitize the C value to a proper NIR bool
> > _dst_val.u32[${k}] = dst.${"xyzw"[k]} ? NIR_TRUE :
> > NIR_FALSE;
> > +% elif output_type == "float16":
> > +   _dst_val.u16[${k}] =
> > _mesa_float_to_half(dst.${"xyzw"[k]});
> >  % else:
> > _dst_val.${get_const_field(output_type)}[${k}] =
> > dst.${"xyzw"[k]};
> >  % endif
> > diff --git a/src/compiler/nir/nir_opcodes.py
> > b/src/compiler/nir/nir_opcodes.py
> > index 53e9aff..37c655b 100644
> > --- 

Re: [Mesa-dev] [RFC 1/3] dri: add support for CONTEXT_FLAG_NO_ERROR_BIT_KHR

[Nicolai Hähnle]

On 28.03.2017 06:35, Timothy Arceri wrote:

The KHR_no_error spec says:

   "CONTEXT_FLAG_NO_ERROR_BIT_KHR is only supported if the
   OpenGL version has support for context flags (as defined
   in the OpenGL 4.5 core spec) or an  extension supporting
   equivalent functionality is exposed."

But the OpenGL 4.5 core spec just has referenced to
{WGL,GLX}_ARB_create_context. There is also no
GLX_create_context_no_error so I'm unsure if the text from
the spec implies that it extends {WGL,GLX}_ARB_create_context
or if a new extension is actually required.


WGL/GLX extensions for this are in progress and should be released 
reasonably soon.


Cheers,
Nicolai


---
 include/GL/internal/dri_interface.h|  2 ++
 src/mesa/drivers/dri/common/dri_util.c | 16 +++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 86efd1b..44840a9 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1041,20 +1041,22 @@ struct __DRIdri2LoaderExtensionRec {
 #define __DRI_CTX_ATTRIB_RESET_STRATEGY3

 #define __DRI_CTX_FLAG_DEBUG   0x0001
 #define __DRI_CTX_FLAG_FORWARD_COMPATIBLE  0x0002

 /**
  * \requires __DRI2_ROBUSTNESS.
  */
 #define __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS0x0004

+#define __DRI_CTX_FLAG_NO_ERROR0x0008
+
 /**
  * \name Context reset strategies.
  */
 /*@{*/
 #define __DRI_CTX_RESET_NO_NOTIFICATION0
 #define __DRI_CTX_RESET_LOSE_CONTEXT   1
 /*@}*/

 /**
  * \name Reasons that __DRIdri2Extension::createContextAttribs might fail
diff --git a/src/mesa/drivers/dri/common/dri_util.c 
b/src/mesa/drivers/dri/common/dri_util.c
index f6df488..6d7f1df 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -418,21 +418,22 @@ driCreateContextAttribs(__DRIscreen *screen, int api,
  * requested API to API_OPENGL_CORE.
  *
  * In Mesa, a debug context is the same as a regular context.
  */
 if ((flags & __DRI_CTX_FLAG_FORWARD_COMPATIBLE) != 0) {
mesa_api = API_OPENGL_CORE;
 }

 const uint32_t allowed_flags = (__DRI_CTX_FLAG_DEBUG
 | __DRI_CTX_FLAG_FORWARD_COMPATIBLE
-| __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS);
+| __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS
+| __DRI_CTX_FLAG_NO_ERROR);
 if (flags & ~allowed_flags) {
*error = __DRI_CTX_ERROR_UNKNOWN_FLAG;
return NULL;
 }

 if (!validate_context_version(screen, mesa_api,
   major_version, minor_version, error))
return NULL;

 context = calloc(1, sizeof *context);
@@ -459,20 +460,33 @@ driCreateContextAttribs(__DRIscreen *screen, int api,
 }

 void
 driContextSetFlags(struct gl_context *ctx, uint32_t flags)
 {
 if ((flags & __DRI_CTX_FLAG_FORWARD_COMPATIBLE) != 0)
 ctx->Const.ContextFlags |= GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT;
 if ((flags & __DRI_CTX_FLAG_DEBUG) != 0) {
_mesa_set_debug_state_int(ctx, GL_DEBUG_OUTPUT, GL_TRUE);
 ctx->Const.ContextFlags |= GL_CONTEXT_FLAG_DEBUG_BIT;
+} else if ((flags & __DRI_CTX_FLAG_NO_ERROR) != 0) {
+/* From Issue (1) of the KHR_no_error spec:
+ *
+ *"How does this extension interact with KHR_robustness and debug
+ *contexts?
+ *
+ *RESOLVED: The EGL/WGL/GLX layers should prevent these features
+ *from being enabled at the same time.  However, if they are
+ *somehow enabled at the same time this extension should be
+ *ignored."
+ */
+if ((flags & __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS) == 0)
+   ctx->Const.ContextFlags |= GL_CONTEXT_FLAG_NO_ERROR_BIT_KHR;
 }
 }

 static __DRIcontext *
 driCreateNewContextForAPI(__DRIscreen *screen, int api,
   const __DRIconfig *config,
   __DRIcontext *shared, void *data)
 {
 unsigned error;





--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] tests/cache_test: allow crossing mount points

[Nicolai Hähnle]

On 25.03.2017 01:40, Juan A. Suarez Romero wrote:

When using an overlayfs system (like a Docker container), rmrf_local()
fails because part of the files to be removed are in different mount
points (layouts). And thus cache-test fails.


Can you explain a bit more how this can happen? I thought the test does

mkdir(CACHE_TEST_TMP, 0755);

...

rmrf_local(CACHE_TEST_TMP);

How does this end up crossing mounts?

Nicolai





Letting crossing mount points is not a big problem, specially because
this is just for a test, not to be used in real code.
---
 src/compiler/glsl/tests/cache_test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/glsl/tests/cache_test.c 
b/src/compiler/glsl/tests/cache_test.c
index 2302f44..ac60197 100644
--- a/src/compiler/glsl/tests/cache_test.c
+++ b/src/compiler/glsl/tests/cache_test.c
@@ -124,7 +124,7 @@ rmrf_local(const char *path)
if (path == NULL || *path == '\0' || *path != '.')
   return -1;

-   return nftw(path, remove_entry, 64, FTW_DEPTH | FTW_PHYS | FTW_MOUNT);
+   return nftw(path, remove_entry, 64, FTW_DEPTH | FTW_PHYS);
 }

 static void




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 1/2] intel: android: remove libdrm_intel requirement

[Emil Velikov]

From: Emil Velikov 

The only part which requires libdrm_intel tools/aubinator is not built
on Android.

Signed-off-by: Emil Velikov 
---
What was 1/3 of the series has superseded by Ken with commit
0c3fbf8028b6f44a341548d341fa660e6b120647
---
 src/intel/Android.blorp.mk|  2 --
 src/intel/Android.compiler.mk |  3 ---
 src/intel/Android.vulkan.mk   | 13 ++---
 3 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/src/intel/Android.blorp.mk b/src/intel/Android.blorp.mk
index 5297af2b7c3..e1aa908706e 100644
--- a/src/intel/Android.blorp.mk
+++ b/src/intel/Android.blorp.mk
@@ -41,7 +41,5 @@ LOCAL_C_INCLUDES := \
 
 LOCAL_STATIC_LIBRARIES := libmesa_nir
 
-LOCAL_SHARED_LIBRARIES := libdrm_intel
-
 include $(MESA_COMMON_MK)
 include $(BUILD_STATIC_LIBRARY)
diff --git a/src/intel/Android.compiler.mk b/src/intel/Android.compiler.mk
index 81209f4ed0a..37d75b5679e 100644
--- a/src/intel/Android.compiler.mk
+++ b/src/intel/Android.compiler.mk
@@ -46,9 +46,6 @@ LOCAL_C_INCLUDES := \
$(MESA_TOP)/src/intel/compiler \
$(MESA_TOP)/src/compiler/nir
 
-LOCAL_SHARED_LIBRARIES := \
-   libdrm_intel
-
 brw_nir_trig_workarounds_deps := \
$(LOCAL_PATH)/compiler/brw_nir_trig_workarounds.py \
$(MESA_TOP)/src/compiler/nir/nir_algebraic.py
diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index cc0b5dff044..831b6584dc8 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -66,7 +66,7 @@ $(intermediates)/vulkan/anv_entrypoints.h: 
$(intermediates)/vulkan/dummy.c
 LOCAL_EXPORT_C_INCLUDE_DIRS := \
 $(intermediates)
 
-LOCAL_SHARED_LIBRARIES := libdrm_intel
+LOCAL_SHARED_LIBRARIES := libdrm
 
 include $(MESA_COMMON_MK)
 include $(BUILD_STATIC_LIBRARY)
@@ -112,7 +112,7 @@ LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
 LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
 
-LOCAL_SHARED_LIBRARIES := libdrm_intel
+LOCAL_SHARED_LIBRARIES := libdrm
 
 include $(MESA_COMMON_MK)
 include $(BUILD_STATIC_LIBRARY)
@@ -132,7 +132,7 @@ LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
 LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
 
-LOCAL_SHARED_LIBRARIES := libdrm_intel
+LOCAL_SHARED_LIBRARIES := libdrm
 
 include $(MESA_COMMON_MK)
 include $(BUILD_STATIC_LIBRARY)
@@ -152,7 +152,7 @@ LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
 LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
 
-LOCAL_SHARED_LIBRARIES := libdrm_intel
+LOCAL_SHARED_LIBRARIES := libdrm
 
 include $(MESA_COMMON_MK)
 include $(BUILD_STATIC_LIBRARY)
@@ -191,7 +191,7 @@ $(intermediates)/vulkan/anv_entrypoints.c:
--xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
--outdir $(dir $@)
 
-LOCAL_SHARED_LIBRARIES := libdrm_intel
+LOCAL_SHARED_LIBRARIES := libdrm
 
 include $(MESA_COMMON_MK)
 include $(BUILD_STATIC_LIBRARY)
@@ -231,8 +231,7 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_intel_compiler \
libmesa_anv_entrypoints
 
-LOCAL_SHARED_LIBRARIES := \
-   libdrm_intel
+LOCAL_SHARED_LIBRARIES := libdrm
 
 include $(MESA_COMMON_MK)
 include $(BUILD_SHARED_LIBRARY)
-- 
2.11.1

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

[Mesa-dev] [PATCH v2 2/2] intel: automake: move INTEL_CFLAGS as applicable

[Emil Velikov]

From: Emil Velikov 

Only common/decoder.[ch] requires it [for intel_aub.h].

v2: The code was moved to from intel/tools to intel/common,
update accordingly.

Signed-off-by: Emil Velikov 
---
 src/intel/Makefile.am| 1 -
 src/intel/Makefile.common.am | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/Makefile.am b/src/intel/Makefile.am
index 63bfd45fdd1..269d73dfcb0 100644
--- a/src/intel/Makefile.am
+++ b/src/intel/Makefile.am
@@ -37,7 +37,6 @@ AM_CPPFLAGS = \
-I$(top_srcdir)/src/mesa \
-I$(top_srcdir)/src/gallium/auxiliary \
-I$(top_srcdir)/src/gallium/include \
-   $(INTEL_CFLAGS) \
$(VALGRIND_CFLAGS) \
$(DEFINES)
 
diff --git a/src/intel/Makefile.common.am b/src/intel/Makefile.common.am
index 848598457ca..a772b5fcd12 100644
--- a/src/intel/Makefile.common.am
+++ b/src/intel/Makefile.common.am
@@ -21,4 +21,5 @@
 
 noinst_LTLIBRARIES += common/libintel_common.la
 
+common_libintel_common_la_CFLAGS = $(AM_CFLAGS) $(LIBDRM_CFLAGS)
 common_libintel_common_la_SOURCES = $(COMMON_FILES) $(DECODER_FILES)
-- 
2.11.1

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

Re: [Mesa-dev] [PATCH 2/2] gallium/util: libunwind support

[Nicolai Hähnle]

On 24.03.2017 22:21, Rob Clark wrote:

It's kinda sad that (a) we don't have debug_backtrace support on !X86
and that (b) we re-invent our own crude backtrace support in the first
place.  If available, use libunwind instead.  The backtrace format is
based on what xserver and weston use, since it is nice not to have to
figure out a different format.


I'm not familiar with libunwind, but this does look reasonable to me, 
and would certainly be a nice improvement where it's used. Series is


Acked-by: Nicolai Hähnle 



Signed-off-by: Rob Clark 
---
 configure.ac   | 24 
 src/gallium/Automake.inc   |  1 +
 src/gallium/auxiliary/util/u_debug_stack.c | 91 ++
 src/gallium/auxiliary/util/u_debug_stack.h | 15 -
 4 files changed, 129 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index a99684b..5046acb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1025,6 +1025,30 @@ AC_SUBST([LLVM_LIBS])
 AC_SUBST([LLVM_LDFLAGS])
 AC_SUBST([LLVM_INCLUDEDIR])

+dnl
+dnl libunwind
+dnl
+AC_ARG_ENABLE([libunwind],
+[AS_HELP_STRING([--enable-libunwind],
+[Use libunwind for backtracing (default: auto)])],
+[LIBUNWIND="$enableval"],
+[LIBUNWIND="auto"])
+
+PKG_CHECK_MODULES(LIBUNWIND, libunwind, [HAVE_LIBUNWIND=yes], 
[HAVE_LIBUNWIND=no])
+if test "x$LIBUNWIND" = "xauto"; then
+LIBUNWIND="$HAVE_LIBUNWIND"
+fi
+
+if test "x$LIBUNWIND" = "xyes"; then
+if test "x$HAVE_LIBUNWIND" != "xyes"; then
+AC_MSG_ERROR([libunwind requested but not installed.])
+fi
+AC_DEFINE(HAVE_LIBUNWIND, 1, [Have libunwind support])
+fi
+
+AM_CONDITIONAL(HAVE_LIBUNWIND, [test "x$LIBUNWIND" = xyes])
+
+
 dnl Options for APIs
 AC_ARG_ENABLE([opengl],
 [AS_HELP_STRING([--disable-opengl],
diff --git a/src/gallium/Automake.inc b/src/gallium/Automake.inc
index a01fa54..48b5a44 100644
--- a/src/gallium/Automake.inc
+++ b/src/gallium/Automake.inc
@@ -46,6 +46,7 @@ GALLIUM_TARGET_CFLAGS = \

 GALLIUM_COMMON_LIB_DEPS = \
-lm \
+   $(LIBUNWIND_LIBS) \
$(LIBSENSORS_LIBS) \
$(CLOCK_LIB) \
$(PTHREAD_LIBS) \
diff --git a/src/gallium/auxiliary/util/u_debug_stack.c 
b/src/gallium/auxiliary/util/u_debug_stack.c
index f941234..cf05f13 100644
--- a/src/gallium/auxiliary/util/u_debug_stack.c
+++ b/src/gallium/auxiliary/util/u_debug_stack.c
@@ -36,6 +36,95 @@
 #include "u_debug_symbol.h"
 #include "u_debug_stack.h"

+#if defined(HAVE_LIBUNWIND)
+
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE
+#endif
+#include 
+
+void
+debug_backtrace_capture(struct debug_stack_frame *backtrace,
+unsigned start_frame,
+unsigned nr_frames)
+{
+   unw_cursor_t cursor;
+   unw_context_t context;
+   unw_proc_info_t pip;
+   unsigned i = 0;
+   int ret;
+
+   pip.unwind_info = NULL;
+
+   unw_getcontext();
+   unw_init_local(, );
+
+   while ((start_frame > 0) && (unw_step() > 0))
+  start_frame--;
+
+   while (unw_step() > 0) {
+  char procname[256];
+  const char *filename;
+  unw_word_t off;
+  Dl_info dlinfo;
+
+  unw_get_proc_info(, );
+
+  ret = unw_get_proc_name(, procname, 256, );
+  if (ret && ret != -UNW_ENOMEM) {
+ procname[0] = '?';
+ procname[1] = 0;
+  }
+
+   if (dladdr((void *)(uintptr_t)(pip.start_ip + off), ) && 
dlinfo.dli_fname &&
+   *dlinfo.dli_fname)
+   filename = dlinfo.dli_fname;
+   else
+   filename = "?";
+
+  snprintf(backtrace[i].buf, sizeof(backtrace[i].buf),
+"%u: %s (%s%s+0x%x) [%p]", i, filename, procname,
+ret == -UNW_ENOMEM ? "..." : "", (int)off,
+(void *)(uintptr_t)(pip.start_ip + off));
+
+  i++;
+   }
+
+   while (i < nr_frames) {
+  backtrace[i].buf[0] = '\0';
+  i++;
+   }
+}
+
+void
+debug_backtrace_dump(const struct debug_stack_frame *backtrace,
+ unsigned nr_frames)
+{
+   unsigned i;
+
+   for (i = 0; i < nr_frames; ++i) {
+  if (backtrace[i].buf[0] == '\0')
+ break;
+  debug_printf("\t%s\n", backtrace[i].buf);
+   }
+}
+
+void
+debug_backtrace_print(FILE *f,
+  const struct debug_stack_frame *backtrace,
+  unsigned nr_frames)
+{
+   unsigned i;
+
+   for (i = 0; i < nr_frames; ++i) {
+  if (backtrace[i].buf[0] == '\0')
+ break;
+  fprintf(f, "\t%s\n", backtrace[i].buf);
+   }
+}
+
+#else /* ! HAVE_LIBUNWIND */
+
 #if defined(PIPE_OS_WINDOWS)
 #include 
 #endif
@@ -179,3 +268,5 @@ debug_backtrace_print(FILE *f,
  fprintf(f, "%s\n", symbol);
}
 }
+
+#endif /* HAVE_LIBUNWIND */
diff --git a/src/gallium/auxiliary/util/u_debug_stack.h 
b/src/gallium/auxiliary/util/u_debug_stack.h
index 04eba08..0effcbe 100644
--- a/src/gallium/auxiliary/util/u_debug_stack.h
+++ b/src/gallium/auxiliary/util/u_debug_stack.h
@@ -30,6 +30,11 @@