date:20180118


Tested-by: Dieter Nützel 

on RX580 with UH, UV, glmark2 and Blender 2.79

UH and UV crash for 'wireframe' (as expected - not implemented, yet) ;-)

BTW
Find an interesting hang with Unigine_Superposition-1.0 with and 
_without_ NIR in very high mode. NIR is _much_ better. Hang only appears 
at 8K on downsampled (?) HD 1920x1080 desktop (native monitor mode). 
GLSL hang first under 1080p extreme mode. Both paths have a memory leak, 
but NIR _much_ later? Nothing in the logs. Only reboot works. It happens 
at the last scene (fading out into the dark). I can 'see' some little 
rest of the engine. But the hang is unrelated to these latest patches. 
;-)


That's why I'm cc'ed Andrey.

Need some sleep...

Dieter

Am 18.01.2018 08:17, schrieb Timothy Arceri:

This is what radeonsi does. Fixes remaing piglit subtest in:

./bin/arb_shader_image_size-builtin --quick -auto -fbo
---
 src/amd/common/ac_nir_to_llvm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c 
b/src/amd/common/ac_nir_to_llvm.c

index d5b8bea44f..ac6bbe02f1 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3788,7 +3788,8 @@ static LLVMValueRef visit_image_size(struct
ac_nir_context *ctx,
const nir_variable *var = instr->variables[0]->var;
const struct glsl_type *type = instr->variables[0]->var->type;
bool da = glsl_sampler_type_is_array(var->type) ||
- glsl_get_sampler_dim(var->type) == GLSL_SAMPLER_DIM_CUBE;
+ glsl_get_sampler_dim(var->type) == GLSL_SAMPLER_DIM_CUBE ||
+ glsl_get_sampler_dim(var->type) == GLSL_SAMPLER_DIM_3D;
if(instr->variables[0]->deref.child)
type = instr->variables[0]->deref.child->type;

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

Re: [Mesa-dev] [PATCH] i965: Rename 'aux' to 'prog_data' in program cache.

2018-01-18 Thread Iago Toral

Reviewed-by: Iago Toral Quiroga 

On Thu, 2018-01-18 at 14:03 -0800, Kenneth Graunke wrote:
> 'aux' is a very generic name, suggesting it can be a bunch of things.
> However, it's always the brw_*_prog_data structure.  So, call it
> that.
> ---
>  src/mesa/drivers/dri/i965/brw_program_cache.c | 31 ++---
> --
>  1 file changed, 16 insertions(+), 15 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_program_cache.c
> b/src/mesa/drivers/dri/i965/brw_program_cache.c
> index adb0cd5a23b..9266273b5da 100644
> --- a/src/mesa/drivers/dri/i965/brw_program_cache.c
> +++ b/src/mesa/drivers/dri/i965/brw_program_cache.c
> @@ -69,7 +69,7 @@ struct brw_cache_item {
>  
> /** for variable-sized keys */
> GLuint key_size;
> -   GLuint aux_size;
> +   GLuint prog_data_size;
> const void *key;
>  
> uint32_t offset;
> @@ -182,7 +182,7 @@ bool
>  brw_search_cache(struct brw_cache *cache,
>   enum brw_cache_id cache_id,
>   const void *key, GLuint key_size,
> - uint32_t *inout_offset, void *inout_aux)
> + uint32_t *inout_offset, void *inout_prog_data)
>  {
> struct brw_context *brw = cache->brw;
> struct brw_cache_item *item;
> @@ -200,12 +200,13 @@ brw_search_cache(struct brw_cache *cache,
> if (item == NULL)
>return false;
>  
> -   void *aux = ((char *) item->key) + item->key_size;
> +   void *prog_data = ((char *) item->key) + item->key_size;
>  
> -   if (item->offset != *inout_offset || aux != *((void **)
> inout_aux)) {
> +   if (item->offset != *inout_offset ||
> +   prog_data != *((void **) inout_prog_data)) {
>brw->ctx.NewDriverState |= (1 << cache_id);
>*inout_offset = item->offset;
> -  *((void **) inout_aux) = aux;
> +  *((void **) inout_prog_data) = prog_data;
> }
>  
> return true;
> @@ -320,10 +321,10 @@ brw_upload_cache(struct brw_cache *cache,
>   GLuint key_size,
>   const void *data,
>   GLuint data_size,
> - const void *aux,
> - GLuint aux_size,
> + const void *prog_data,
> + GLuint prog_data_size,
>   uint32_t *out_offset,
> - void *out_aux)
> + void *out_prog_data)
>  {
> struct brw_cache_item *item = CALLOC_STRUCT(brw_cache_item);
> const struct brw_cache_item *matching_data =
> @@ -335,7 +336,7 @@ brw_upload_cache(struct brw_cache *cache,
> item->size = data_size;
> item->key = key;
> item->key_size = key_size;
> -   item->aux_size = aux_size;
> +   item->prog_data_size = prog_data_size;
> hash = hash_key(item);
> item->hash = hash;
>  
> @@ -354,11 +355,11 @@ brw_upload_cache(struct brw_cache *cache,
>memcpy(cache->map + item->offset, data, data_size);
> }
>  
> -   /* Set up the memory containing the key and aux_data */
> -   tmp = malloc(key_size + aux_size);
> +   /* Set up the memory containing the key and prog_data */
> +   tmp = malloc(key_size + prog_data_size);
>  
> memcpy(tmp, key, key_size);
> -   memcpy(tmp + key_size, aux, aux_size);
> +   memcpy(tmp + key_size, prog_data, prog_data_size);
>  
> item->key = tmp;
>  
> @@ -371,7 +372,7 @@ brw_upload_cache(struct brw_cache *cache,
> cache->n_items++;
>  
> *out_offset = item->offset;
> -   *(void **)out_aux = (void *)((char *)item->key + item->key_size);
> +   *(void **)out_prog_data = (void *)((char *)item->key + item-
> >key_size);
> cache->brw->ctx.NewDriverState |= 1 << cache_id;
>  }
>  
> @@ -412,8 +413,8 @@ brw_clear_cache(struct brw_context *brw, struct
> brw_cache *cache)
>   c->cache_id == BRW_CACHE_GS_PROG ||
>   c->cache_id == BRW_CACHE_FS_PROG ||
>   c->cache_id == BRW_CACHE_CS_PROG) {
> -const void *item_aux = c->key + c->key_size;
> -brw_stage_prog_data_free(item_aux);
> +const void *item_prog_data = c->key + c->key_size;
> +brw_stage_prog_data_free(item_prog_data);
>   }
>   free((void *)c->key);
>   free(c);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Drop render_target_start from binding table struct.

2018-01-18 Thread Iago Toral

On Thu, 2018-01-18 at 15:49 -0800, Kenneth Graunke wrote:
> We have to start render targets at binding table index 0 in order to
> use
> headerless FB write messages, and in fact already assume this in a
> bunch
> of places in the code.  Let's finish that off, and not bother storing
> 0
> in a struct to pretend to add it in a few places.
> ---
>  src/intel/blorp/blorp.c | 1 -
>  src/intel/compiler/brw_compiler.h   | 1 -
>  src/intel/compiler/brw_fs_generator.cpp | 6 ++
>  src/mesa/drivers/dri/i965/brw_wm.c  | 1 -
>  4 files changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
> index e8a2c6135f5..b7238306eb1 100644
> --- a/src/intel/blorp/blorp.c
> +++ b/src/intel/blorp/blorp.c
> @@ -177,7 +177,6 @@ blorp_compile_fs(struct blorp_context *blorp,
> void *mem_ctx,
> wm_prog_data->base.param = NULL;
>  
> /* BLORP always just uses the first two binding table entries */
> -   wm_prog_data->biable.render_target_start =
> BLORP_RENDERBUFFER_BT_INDEX;
> wm_prog_data->base.binding_table.texture_start =
> BLORP_TEXTURE_BT_INDEX;

Since the comment says that blorp uses the first two entries but it
then only assigns one, maybe it would be nice to update the comment
above to state that we assume render targets start at binding table
index 0.

> nir = brw_preprocess
> Wouldn't it be better to keep the assert? We still needs
> render_target_start to be 0_nir(compiler, nir);
> diff --git a/src/intel/compiler/brw_compiler.h
> b/src/intel/compiler/brw_compiler.h
> index 0060c381c0d..b1086bbcee5 100644
> --- a/src/intel/compiler/brw_compiler.h
> +++ b/src/intel/compiler/brw_compiler.h
> @@ -681,7 +681,6 @@ struct brw_wm_prog_data {
>/** @{
> * surface indices the WM-specific surfaces
> */
> -  uint32_t render_target_start;
>uint32_t render_target_read_start;
>/** @} */
> } binding_table;
> diff --git a/src/intel/compiler/brw_fs_generator.cpp
> b/src/intel/compiler/brw_fs_generator.cpp
> index 91bf0643084..cd5be054f69 100644
> --- a/src/intel/compiler/brw_fs_generator.cpp
> +++ b/src/intel/compiler/brw_fs_generator.cpp
> @@ -287,8 +287,6 @@ fs_generator::fire_fb_write(fs_inst *inst,
>  * messages set "Render Target Index" to 0.  Using a different
> binding
>  * table index would make it impossible to use headerless
> messages.
>  */
> -   assert(prog_data->binding_table.render_target_start == 0);
> -
> const uint32_t surf_index = inst->target;
>  
> bool last_render_target = inst->eot ||
> @@ -427,8 +425,8 @@ fs_generator::generate_fb_read(fs_inst *inst,
> struct brw_reg dst,
>  {
> assert(inst->size_written % REG_SIZE == 0);
> struct brw_wm_prog_data *prog_data = brw_wm_prog_data(this-
> >prog_data);
> -   const unsigned surf_index =
> -  prog_data->binding_table.render_target_start + inst->target;
> +   /* We assume that render targets start at binding table index 0.
> */
> +   const unsigned surf_index = inst->target;
>  
> gen9_fb_READ(p, dst, payload, surf_index,
>  inst->header_size, inst->size_written / REG_SIZE,
> diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
> b/src/mesa/drivers/dri/i965/brw_wm.c
> index 08bacebd571..755a76eec71 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm.c
> @@ -51,7 +51,6 @@ assign_fs_binding_table_offsets(const struct
> gen_device_info *devinfo,
> /* If there are no color regions, we still perform an FB write to
> a null
>  * renderbuffer, which we place at surface index 0.
>  */
> -   prog_data->binding_table.render_target_start =
> next_binding_table_offset;
> next_binding_table_offset += MAX2(key->nr_color_regions, 1);

Since we are no longer assigning next_binding_table_offset with value
of  0, we might as well drop the initialization to that value (or just
initialize the variable directly to the value right after the line you
remove here).

Either way:
Reviewed-by: Iago Toral Quiroga 


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

Re: [Mesa-dev] [PATCH 8/8] st/glsl_to_nir: disable io lowering and forced indirect array splitting in fs


For the series:

Tested-by: Dieter Nützel 

on RX580 with UH, UV, glmark2 and Blender 2.79

UH and UV crash for 'wireframe' (as expected - not implemented, yet) ;-)

Dieter

Am 15.01.2018 04:46, schrieb Timothy Arceri:

We need this to be able to support the interpolateAt builtins in a
sane way. It also leads to the generation of more optimal code.

The lowering and splitting is made conditional on glsl 400 because
vc4 and freedreno both expect these passes to be enabled and niether
support glsl 400 so don't need to deal with the interpolateAt builtins.

We leave the other stages for now as to avoid regressions.
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 6e3a1548f4..bc55c5b7db 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -461,7 +461,9 @@ st_nir_get_mesa_program(struct gl_context *ctx,
 struct gl_linked_shader *shader)
 {
struct st_context *st = st_context(ctx);
+   struct pipe_screen *screen = st->pipe->screen;
struct gl_program *prog;
+   unsigned glsl_version = screen->get_param(screen,
PIPE_CAP_GLSL_FEATURE_LEVEL);

validate_ir_tree(shader->ir);

@@ -491,11 +493,14 @@ st_nir_get_mesa_program(struct gl_context *ctx,
prog->nir = nir;

if (nir->info.stage != MESA_SHADER_TESS_CTRL &&
-   nir->info.stage != MESA_SHADER_TESS_EVAL) {
+   nir->info.stage != MESA_SHADER_TESS_EVAL &&
+   (nir->info.stage != MESA_SHADER_FRAGMENT ||
+(glsl_version < 400 && nir->info.stage == 
MESA_SHADER_FRAGMENT))) {

   NIR_PASS_V(nir, nir_lower_io_to_temporaries,
  nir_shader_get_entrypoint(nir),
  true, true);
}
+
NIR_PASS_V(nir, nir_lower_global_vars_to_local);
NIR_PASS_V(nir, nir_split_var_copies);
NIR_PASS_V(nir, nir_lower_var_copies);
@@ -665,12 +670,16 @@ st_finalize_nir(struct st_context *st, struct
gl_program *prog,
 struct gl_shader_program *shader_program, nir_shader 
*nir)

 {
struct pipe_screen *screen = st->pipe->screen;
+   unsigned glsl_version = screen->get_param(screen,
PIPE_CAP_GLSL_FEATURE_LEVEL);

NIR_PASS_V(nir, nir_split_var_copies);
NIR_PASS_V(nir, nir_lower_var_copies);
if (nir->info.stage != MESA_SHADER_TESS_CTRL &&
-   nir->info.stage != MESA_SHADER_TESS_EVAL)
+   nir->info.stage != MESA_SHADER_TESS_EVAL &&
+   (nir->info.stage != MESA_SHADER_FRAGMENT ||
+(glsl_version < 400 && nir->info.stage == 
MESA_SHADER_FRAGMENT))) {

   NIR_PASS_V(nir, nir_lower_io_arrays_to_elements_no_indirects);
+   }

if (nir->info.stage == MESA_SHADER_VERTEX) {
   /* Needs special handling so drvloc matches the vbo state: */

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

Re: [Mesa-dev] [PATCH] intel: Add Geminilake brand strings

On Wednesday, January 17, 2018 1:31:53 PM PST Anuj Phogat wrote:
> Signed-off-by: Anuj Phogat 
> ---
>  include/pci_ids/i965_pci_ids.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
> index 9616f7de21..e947b026bd 100644
> --- a/include/pci_ids/i965_pci_ids.h
> +++ b/include/pci_ids/i965_pci_ids.h
> @@ -163,8 +163,8 @@ CHIPSET(0x5923, kbl_gt3, "Intel(R) Kabylake GT3")
>  CHIPSET(0x5926, kbl_gt3, "Intel(R) Iris Plus Graphics 640 (Kaby Lake GT3e)")
>  CHIPSET(0x5927, kbl_gt3, "Intel(R) Iris Plus Graphics 650 (Kaby Lake GT3e)")
>  CHIPSET(0x593B, kbl_gt4, "Intel(R) Kabylake GT4")
> -CHIPSET(0x3184, glk, "Intel(R) HD Graphics (Geminilake)")
> -CHIPSET(0x3185, glk_2x6, "Intel(R) HD Graphics (Geminilake 2x6)")
> +CHIPSET(0x3184, glk, "Intel(R) UHD Graphics 605 (Geminilake)")
> +CHIPSET(0x3185, glk_2x6, "Intel(R) UHD Graphics 600 (Geminilake 2x6)")
>  CHIPSET(0x3E90, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
>  CHIPSET(0x3E93, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
>  CHIPSET(0x3E99, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
> 

I haven't verified these but it seems like a good idea to update them.

Acked-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] [PATCH] egl: do not expose EGL_EXT_pixel_format_float yet




On 01/18/2018 03:31 PM, Emil Velikov wrote:

On 18 January 2018 at 06:05, Tapani Pälli  wrote:



On 01/17/2018 11:59 PM, Rob Herring wrote:


On Wed, Jan 17, 2018 at 12:27 PM, Tapani Pälli 
wrote:


Let's expose this only when we have formats. There are some
known issues when this is exposed without formats (on Android).



This is fixed now at least for master.



OK cool .. then I guess we don't really need to disable this.


Here is the patch [1] in case your tree/checkout doesn't have it.

-Emil

[1] https://android-review.googlesource.com/c/platform/frameworks/base/+/550746



Thanks! We should probably pick this up to Android-IA.

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

[Mesa-dev] [PATCH v2] egl: add support for EGL_ANDROID_blob_cache

v2: cleanup, move callbacks to _egl_display struct (Emil Velikov)

Signed-off-by: Tapani Pälli 
---
 src/egl/drivers/dri2/egl_dri2.c | 39 +++
 src/egl/drivers/dri2/egl_dri2.h |  1 +
 src/egl/main/eglapi.c   | 30 ++
 src/egl/main/eglapi.h   |  4 
 src/egl/main/egldisplay.h   |  4 
 src/egl/main/eglentrypoint.h|  1 +
 6 files changed, 79 insertions(+)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index d5a4f72e86..c323a4989d 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -458,6 +458,7 @@ static const struct dri2_extension_match 
optional_core_extensions[] = {
{ __DRI2_INTEROP, 1, offsetof(struct dri2_egl_display, interop) },
{ __DRI_IMAGE, 1, offsetof(struct dri2_egl_display, image) },
{ __DRI2_FLUSH_CONTROL, 1, offsetof(struct dri2_egl_display, flush_control) 
},
+   { __DRI2_BLOB, 1, offsetof(struct dri2_egl_display, blob) },
{ NULL, 0, 0 }
 };
 
@@ -727,6 +728,9 @@ dri2_setup_screen(_EGLDisplay *disp)
   }
}
 
+   if (dri2_dpy->blob)
+  disp->Extensions.ANDROID_blob_cache = EGL_TRUE;
+
disp->Extensions.KHR_reusable_sync = EGL_TRUE;
 
if (dri2_dpy->image) {
@@ -1470,6 +1474,28 @@ dri2_surf_update_fence_fd(_EGLContext *ctx,
dri2_surface_set_out_fence_fd(surf, fence_fd);
 }
 
+static void
+update_blob_cache_functions( _EGLDisplay *disp, _EGLContext *ctx)
+{
+   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+   struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
+
+   if (!ctx)
+  return;
+
+   /* No blob support. */
+   if (!dri2_dpy->blob)
+  return;
+
+   /* No functions to set. */
+   if (!disp->BlobCacheSet)
+  return;
+
+   dri2_dpy->blob->set_cache_funcs(dri2_ctx->dri_context,
+   disp->BlobCacheSet,
+   disp->BlobCacheGet);
+}
+
 /**
  * Called via eglMakeCurrent(), drv->API.MakeCurrent().
  */
@@ -1499,6 +1525,9 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *dsurf,
if (old_ctx)
   dri2_gl_flush();
 
+   /* Make sure cache functions are set for new context. */
+   update_blob_cache_functions(disp, ctx);
+
ddraw = (dsurf) ? dri2_dpy->vtbl->get_dri_drawable(dsurf) : NULL;
rdraw = (rsurf) ? dri2_dpy->vtbl->get_dri_drawable(rsurf) : NULL;
cctx = (dri2_ctx) ? dri2_ctx->dri_context : NULL;
@@ -3016,6 +3045,15 @@ dri2_dup_native_fence_fd(_EGLDriver *drv, _EGLDisplay 
*dpy, _EGLSync *sync)
return dup(sync->SyncFd);
 }
 
+static void
+dri2_set_blob_cache_funcs(_EGLDriver *drv, _EGLDisplay *dpy,
+  EGLSetBlobFuncANDROID set,
+  EGLGetBlobFuncANDROID get)
+{
+   _EGLContext *ctx = _eglGetCurrentContext();
+   update_blob_cache_functions(dpy, ctx);
+}
+
 static EGLint
 dri2_client_wait_sync(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSync *sync,
   EGLint flags, EGLTime timeout)
@@ -3234,6 +3272,7 @@ _eglBuiltInDriver(void)
dri2_drv->API.GLInteropQueryDeviceInfo = dri2_interop_query_device_info;
dri2_drv->API.GLInteropExportObject = dri2_interop_export_object;
dri2_drv->API.DupNativeFenceFDANDROID = dri2_dup_native_fence_fd;
+   dri2_drv->API.SetBlobCacheFuncsANDROID = dri2_set_blob_cache_funcs;
 
dri2_drv->Name = "DRI2";
 
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index cc76c73eab..c49156fbb6 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -171,6 +171,7 @@ struct dri2_egl_display
const __DRInoErrorExtension*no_error;
const __DRI2configQueryExtension *config;
const __DRI2fenceExtension *fence;
+   const __DRI2blobExtension *blob;
const __DRI2rendererQueryExtension *rendererQuery;
const __DRI2interopExtension *interop;
int   fd;
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 5110688f2d..f2ba260060 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -476,6 +476,7 @@ _eglCreateExtensionsString(_EGLDisplay *dpy)
char *exts = dpy->ExtensionsString;
 
/* Please keep these sorted alphabetically. */
+   _EGL_CHECK_EXTENSION(ANDROID_blob_cache);
_EGL_CHECK_EXTENSION(ANDROID_framebuffer_target);
_EGL_CHECK_EXTENSION(ANDROID_image_native_buffer);
_EGL_CHECK_EXTENSION(ANDROID_native_fence_sync);
@@ -2522,6 +2523,35 @@ eglQueryDmaBufModifiersEXT(EGLDisplay dpy, EGLint 
format, EGLint max_modifiers,
RETURN_EGL_EVAL(disp, ret);
 }
 
+static void EGLAPIENTRY
+eglSetBlobCacheFuncsANDROID(EGLDisplay *dpy, EGLSetBlobFuncANDROID set,
+EGLGetBlobFuncANDROID get)
+{
+   _EGLDisplay *disp = _eglLockDisplay(dpy);
+   _EGLDriver *drv = _eglCheckDisplay(disp, __func__);
+
+   if (!set || !get) {
+  _eglError(EGL_BAD_PARAMETER,
+"eglSetBlobCacheFuncsANDROID: NULL

Re: [Mesa-dev] [PATCH 2/7] egl: add support for EGL_ANDROID_blob_cache




On 01/18/2018 04:55 PM, Emil Velikov wrote:

On 17 January 2018 at 16:11, Tapani Pälli  wrote:



On 17.01.2018 13:28, Nicolai Hähnle wrote:


On 16.01.2018 18:45, Emil Velikov wrote:


Hi Tapani,

On 15 January 2018 at 12:31, Tapani Pälli  wrote:


+static void
+update_blob_cache_functions(struct dri2_egl_display *dri2_dpy,
+struct dri2_egl_context *dri2_ctx)
+{
+   if (!dri2_dpy || !dri2_ctx)
+  return;


AFAICT dri2_dpy can never be NULL.


+
+   /* No blob support. */
+   if (!dri2_dpy->blob)
+  return;
+
+   /* No functions to set. */
+   if (!dri2_dpy->blob_cache_set)
+  return;
+
+   dri2_dpy->blob->set_cache_funcs(dri2_ctx->dri_context,
+   dri2_dpy->blob_cache_set,
+   dri2_dpy->blob_cache_get);
+}
+


I'm wondering why you opted to make set_cache_funcs dri_context
specific as opposed to dri_screen.
The latter seems to align better to EGLDisplay.

Plus doing so will simplify the existing code - no hunk in
dri2_make_current, no dri2_dpy->blob/blob_cache_set checks, etc.



Yes, please make it a screen thing. It just makes more sense, and there's
precedent in Gallium, where the disk-cache is a per-pipe_screen object as
well.



I chose context because eventually I need to access disk_cache which is part
of gl_context. I'm not sure how would I propagate the set/get there from
dri_screen?


Gallium does the following during create_context. I'm not sure if
there's any particular reason why i965 cannot do the same.
Tim, you've worked a fair bit in the area do you see any drawbacks?

ctx->Cache = pipe->screen->det_dist_shader_cache(pipe->screen);



One problem is that client might set the callbacks only after context 
creation so we need to be able to do this during set_cache_funcs(). Now 
it works fine because we pass context there.


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

Re: [Mesa-dev] [PATCH 6/7] android: ignore MESA_GLSL_CACHE_DISABLE setting




On 01/18/2018 04:59 PM, Emil Velikov wrote:

On 17 January 2018 at 08:12, Tapani Pälli  wrote:



On 16.01.2018 11:02, Jordan Justen wrote:


On 2018-01-15 04:31:42, Tapani Pälli wrote:


Signed-off-by: Tapani Pälli 
---
   src/mesa/drivers/dri/i965/brw_disk_cache.c | 2 ++
   src/util/disk_cache.c  | 2 ++
   2 files changed, 4 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_disk_cache.c
b/src/mesa/drivers/dri/i965/brw_disk_cache.c
index 65bb52726e..4df4504666 100644
--- a/src/mesa/drivers/dri/i965/brw_disk_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_disk_cache.c
@@ -405,8 +405,10 @@ void
   brw_disk_cache_init(struct brw_context *brw)
   {
   #ifdef ENABLE_SHADER_CACHE
+#ifndef ANDROID
  if (env_var_as_boolean("MESA_GLSL_CACHE_DISABLE", true))
 return;
+#endif



Arguably, if we don't want to enable the shader cache in i965, then we
probably wouldn't want to enable EGL_ANDROID_blob_cache that hits the
same paths.

Since the 18.0 branch is happening soon, two questions arise:

1. Should we enable the shader cache on i965 by default in the 18.0
 release.

2. If not, should we enable it on master after the 18.0 branch.

I guess if neither of these are yes, we could discuss whether it is
okay to enable this Android feature even though we don't want to
enable the shader cache on i965.


  char renderer[10];
  MAYBE_UNUSED int len = snprintf(renderer, sizeof(renderer),
"i965_%04x",
diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index d7891e3b70..3c98089e69 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -208,9 +208,11 @@ disk_cache_create(const char *gpu_name, const char
*timestamp,
  if (local == NULL)
 goto fail;
   +#ifndef ANDROID
  /* At user request, disable shader cache entirely. */
  if (env_var_as_boolean("MESA_GLSL_CACHE_DISABLE", false))
 goto fail;
+#endif



This just allows someone to force the cache feature off. This should
be safe, so I think we should leave it.



True, will change the patch. This patch was actually a bit of extra and does
not need to land on master, we can enable it on master at same time as for
Linux desktop (whenever that happens). If Android-IA wants to enable it,
they can use this patch or similar.


Setting the env. variable might be easier than patching it out.
Adds the benefit of toggling on/off via a simple config file change,
instead of building a complete image ;-)

Or perhaps the Android security model is blocking envvar manipulation?


This environment variable would need to be there when Surfaceflinger 
starts, so I guess it means having that in init.environ.rc. I can try if 
it gets propagated to everyone from there. Then one needs to do only 
stop/start cycle or reboot and no need to build and copy new mesa library.


One flexible option would be also to use drirc (which we do have), but 
then you need to do start/stop cycle as well.


In any case, I think this patch should be scrapped, toggling it on can 
be separate patch in Android tree.


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

[Mesa-dev] [PATCH] mesa: Only require independent blending for GLES 3.2.

We've been requiring this since GLES 3.0 was introduced, but the GLES 3.2
spec is the one that has "Supporting blending on a per-draw-buffer basis"
in the new features.  V3D 3.3 would require lowering blending to shader
code to implement independent blending.
---
 src/mesa/main/version.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 68079f4ebbba..1fce8fe7ca9c 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -516,7 +516,6 @@ compute_version_es2(const struct gl_extensions *extensions,
  extensions->ARB_texture_float &&
  extensions->ARB_texture_rg &&
  extensions->ARB_depth_buffer_float &&
- extensions->EXT_draw_buffers2 &&
  /* extensions->ARB_framebuffer_object && */
  extensions->EXT_framebuffer_sRGB &&
  extensions->EXT_packed_float &&
@@ -546,6 +545,7 @@ compute_version_es2(const struct gl_extensions *extensions,
  extensions->ARB_gpu_shader5 &&
  extensions->EXT_shader_integer_mix);
const bool ver_3_2 = (ver_3_1 &&
+ extensions->EXT_draw_buffers2 &&
  extensions->KHR_blend_equation_advanced &&
  extensions->KHR_robustness &&
  extensions->KHR_texture_compression_astc_ldr &&
-- 
2.15.0

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

Re: [Mesa-dev] Logging infrastructure?


Hi;

On 01/18/2018 11:44 PM, Chuck Atkins wrote:
Is there a logging infrastructure currently available to drivers in 
Mesa?  I was looking to clean up some of swr's debug / info output and 
have it conditional on the MESA_DEBUG and LIBGL_DEBUG variables but then 
I realized that it's really something useful all across mesa so there 
may already be something there for it.  If not though, I'd be interested 
in adding some very light weight functions for just that purpose could 
be used by any driver rather than just fprintf(stderr, ...);




IMO infrastructure in src/intel/common/intel_log.h by Chad could be 
moved to src/util as a 'common Mesa thing'?


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

[Mesa-dev] [PATCH v2] ac: remove arrays when when querying sampler info

Fixes the following ARB_arrays_of_arrays piglit tests:

basic-imagestore-const-uniform-index
basic-imagestore-mixed-const-non-const-uniform-index
basic-imagestore-mixed-const-non-const-uniform-index2
basic-imagestore-non-const-uniform-index
---
 src/amd/common/ac_nir_to_llvm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 4f240db4ac..e88f64fb3b 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3516,9 +3516,7 @@ static LLVMValueRef 
adjust_sample_index_using_fmask(struct ac_llvm_context *ctx,
 static LLVMValueRef get_image_coords(struct ac_nir_context *ctx,
 const nir_intrinsic_instr *instr)
 {
-   const struct glsl_type *type = instr->variables[0]->var->type;
-   if(instr->variables[0]->deref.child)
-   type = instr->variables[0]->deref.child->type;
+   const struct glsl_type *type = 
glsl_without_array(instr->variables[0]->var->type);
 
LLVMValueRef src0 = get_src(ctx, instr->src[0]);
LLVMValueRef coords[4];
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH 7/7] android: set '/sdcard/' as MESA_GLSL_CACHE_DIR by default




On 01/18/2018 08:18 PM, Jordan Justen wrote:

On 2018-01-15 04:31:43, Tapani Pälli wrote:

This can/should be modified depending on needs. AFAIK by default,
this is the only path that can be read/written to by anyone.

Signed-off-by: Tapani Pälli 
---
  Android.common.mk | 1 +
  1 file changed, 1 insertion(+)

diff --git a/Android.common.mk b/Android.common.mk
index 52dc7bff3b..7edbbfc0f2 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -47,6 +47,7 @@ LOCAL_CFLAGS += \
  LOCAL_CFLAGS += \
 -DANDROID_API_LEVEL=$(PLATFORM_SDK_VERSION) \
 -DENABLE_SHADER_CACHE \
+   -DMESA_GLSL_CACHE_DIR="/sdcard" \


Is this used when EGL_ANDROID_blob_cache is being used?

My thought is that if we are running under android with
EGL_ANDROID_blob_cache, then we should never attempt to write any
files with src/util/disk_cache.c. This might cause a little rework,
since the shader cache want to write/manage the index file, but can we
skip this and only use the blob cache read/write function when
EGL_ANDROID_blob_cache is available?


I'm a bit pessimistic about that. Since cache location depends on 
running app that would mean every app has it's own index (that not 
really a problem though but is different from desktop). The big problem 
I see there that index will be then 'just another cache entry', I'll 
have to get more familiar with Android's implementation to see if there 
would be way to make this entry 'special' so that it would not touch it.


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

Re: [Mesa-dev] [PATCH 3/4] i965/bufmgr: Add a set_tiling helper

On Thursday, January 18, 2018 7:05:46 PM PST Jason Ekstrand wrote:
> On Thu, Jan 18, 2018 at 4:30 PM, Kenneth Graunke 
> wrote:
> 
> > On Friday, January 12, 2018 1:28:00 AM PST Chris Wilson wrote:
> > > Quoting Jason Ekstrand (2018-01-12 01:40:52)
> > > > This helper should be used carefully as setting tiling is a racy
> > > > operation since it potentially interacts with other processes.  Still,
> > > > it is a useful thing to be able to do.
> > > >
> > > > Cc: mesa-sta...@lists.freedesktop.org
> > > > ---
> > > >  src/mesa/drivers/dri/i965/brw_bufmgr.c | 27
> > +++
> > > >  src/mesa/drivers/dri/i965/brw_bufmgr.h | 10 ++
> > > >  2 files changed, 37 insertions(+)
> > > >
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > > > index 469895e..dbd13dd 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > > > +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > > > @@ -1133,6 +1133,33 @@ brw_bo_get_tiling(struct brw_bo *bo, uint32_t
> > *tiling_mode,
> > > > return 0;
> > > >  }
> > > >
> > > > +int
> > > > +brw_bo_set_tiling(struct brw_bo *bo, uint32_t tiling_mode,
> > > > +  uint32_t stride)
> > > > +{
> > > > +   struct brw_bufmgr *bufmgr = bo->bufmgr;
> > > > +
> > > > +   mtx_lock(>lock);
> > >
> > > This mutex protects the buffer cache, which should not be containing
> > > this bo. Changing the tiling of a shared active bo also should not
> > > happen because the other parties will have already derived state from
> > > the older tiling. So I don't see the purpose of this mutex here.
> > >
> > > If we will need exclusive access to a bo, let's have a bo->lock.
> > > -Chris
> >
> > I agree with Chris, I don't like this locking.  Looking more closely,
> > I don't think patches 3-4 are what you want at all.
> >
> > intel_create_image_from_fds_common calls brw_bo_gem_create_from_prime.
> > It's the only caller of that function.
> >
> > brw_bo_gem_create_from_prime allocates a new BO, does GET_TILING, and
> > inserts it into the cache.  This is pointless after your patch 4,
> > because you immediately whack it.
> >
> > So...instead...just make brw_bo_gem_create_from_prime take a tiling,
> > and SET_TILING it...don't bother with GET_TILING at all.  Then, your
> > BO isn't in the cache yet (or you have the cache locked), and it's
> > safe without a race and redundant work.
> >
> 
> I can rework things to do it that way.  I thought about it briefly but I
> got hung up on how to handle the "use the tiling from the BO" case.  I
> think I can use an int and pass -1 or something.  Or maybe add a
> create_from_prime_tiled helper.
> 
> --Jason

Hmm, right...I was thinking the obvious solution would be to have
intel_create_image_from_fds_common do GET_TILING if modifier ==
DRM_FORMAT_MOD_INVALID.  But, it doesn't have the GEM handle.

Passing -1 for the tiling to mean "get the BO tiling" seems fine to me.

--Ken


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] [PATCH 0/7] EGL_ANDROID_blob_cache




On 01/18/2018 05:49 PM, Nicolai Hähnle wrote:

On 17.01.2018 17:10, Tapani Pälli wrote:



On 17.01.2018 13:34, Nicolai Hähnle wrote:

On 15.01.2018 13:31, Tapani Pälli wrote:

Hello;

Here's a refactored series of EGL_ANDROID_blob_cache. Now cache
functions are stored in disk_cache struct and the functionality
called within existing disk_cache put/get code. Problems/errors
that existed with earlier series are gone.

On Android cache index file is created to MESA_GLSL_CACHE_DIR
and blobs are  generated under '/data/user_de/0' in application
specific paths:


Can't we let the "cache index" be managed by the ANDROID_blob_cache 
as well? That seems to me more in the spirit of what that extension 
is about, and would avoid polluting stuff like /sdcard.


The cache index file is used for two purposes:

- Keeping track of the size of the cache. This use is obsoleted 
enterely by ANDROID_blob_cache.


- Keeping track of keys where only their presence is relevant and no 
data is associated. These could easily be treated as empty (0 byte 
sized) blobs.


I guess it could be possible, for every app we would create index when 
disk_cache gets created. I guess only issue could be that Android 
might go and remove the index from cache when it decides to resize it 
and then we would loose it even though there would be items in cache. 
I can try how this would work.


Entries can be kicked out of the on-disk index (which is really a bit of 
a misnomer) as well if there's a hash collision.


I believe this functionality is only used as a marker to indicate that 
the GLSL compile step can be skipped. So losing an entry in there 
shouldn't cause any damage.


What I meant is that if we would store index by using set() function, 
the index itself would be just another entry for Android's cache, it can 
decide to remove it when it manages cache size.



Cheers,
Nicolai






Cheers,
Nicolai





androidia_64:/ # find /data/user_de/0/ -name *shader*
/data/user_de/0/com.android.settings/code_cache/com.android.opengl.shaders_cache 

/data/user_de/0/com.android.gallery3d/code_cache/com.android.opengl.shaders_cache 

/data/user_de/0/com.android.systemui/code_cache/com.android.opengl.shaders_cache 

/data/user_de/0/com.rovio.angrybirdsspace.ads/code_cache/com.android.opengl.shaders_cache 



(this part is managed by Android but may be interesting to know).

Also SurfaceFlinger manages its own cache as seen in the log output:
01-15 07:40:26.329  2129  2129 D SurfaceFlinger: shader cache 
generated - 24 shaders in 57.687504 ms


I'm not sure if /sdcard is sane default but I've tried everything
else (/cache, /data/cache) and failed because of permission errors.

Thanks;

Tapani Pälli (7):
   dri: add interface for EGL_ANDROID_blob_cache extension
   egl: add support for EGL_ANDROID_blob_cache
   disk cache: add callback functionality
   disk cache: support setting MESA_GLSL_CACHE_DIR at compile time
   i965: add __DRI2_BLOB support and set cache functions
   android: ignore MESA_GLSL_CACHE_DISABLE setting
   android: set '/sdcard/' as MESA_GLSL_CACHE_DIR by default

  Android.common.mk  |  1 +
  include/GL/internal/dri_interface.h    | 26 +-
  src/egl/drivers/dri2/egl_dri2.c    | 43 


  src/egl/drivers/dri2/egl_dri2.h    |  4 +++
  src/egl/main/eglapi.c  | 29 
  src/egl/main/eglapi.h  |  4 +++
  src/egl/main/egldisplay.h  |  3 ++
  src/egl/main/eglentrypoint.h   |  1 +
  src/mesa/drivers/dri/i965/brw_disk_cache.c |  2 ++
  src/mesa/drivers/dri/i965/intel_screen.c   | 21 
  src/util/disk_cache.c  | 54 
+-

  src/util/disk_cache.h  | 19 +++
  12 files changed, 205 insertions(+), 2 deletions(-)








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

[Mesa-dev] [PATCH 2/2] glsl: add image and sampler (un)packing support to glsl to nir

This is needed for ARB_bindless_texture support.
---
 src/compiler/glsl/glsl_to_nir.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index 4e3e9c4610..1a579f41cd 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -1645,11 +1645,15 @@ nir_visitor::visit(ir_expression *ir)
case ir_unop_unpack_half_2x16:
   result = nir_unpack_half_2x16(, srcs[0]);
   break;
+   case ir_unop_pack_sampler_2x32:
+   case ir_unop_pack_image_2x32:
case ir_unop_pack_double_2x32:
case ir_unop_pack_int_2x32:
case ir_unop_pack_uint_2x32:
   result = nir_pack_64_2x32(, srcs[0]);
   break;
+   case ir_unop_unpack_sampler_2x32:
+   case ir_unop_unpack_image_2x32:
case ir_unop_unpack_double_2x32:
case ir_unop_unpack_int_2x32:
case ir_unop_unpack_uint_2x32:
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH] radv/winsys: replace bo list searchs with a hash table.


Ping!
Any progress?

Am 11.01.2018 04:53, schrieb Dave Airlie:

From: Dave Airlie 

This should make the merging of cmd buffers less CPU intensive,
note I said *should* :)
---
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c | 47 
---

 1 file changed, 20 insertions(+), 27 deletions(-)

diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
index 0ee56f91447..9a39d237ae8 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
@@ -33,6 +33,7 @@
 #include "radv_amdgpu_bo.h"
 #include "sid.h"

+#include "util/hash_table.h"

 enum {
VIRTUAL_BUFFER_HASH_TABLE_SIZE = 1024
@@ -584,6 +585,9 @@ static int radv_amdgpu_create_bo_list(struct
radv_amdgpu_winsys *ws,
priorities[0] = 8;
}

+		struct hash_table *ht = _mesa_hash_table_create(NULL, 
_mesa_hash_pointer,

+   
_mesa_key_pointer_equal);
+
for (unsigned i = 0; i < count + !!extra_cs; ++i) {
struct radv_amdgpu_cs *cs;

@@ -595,50 +599,39 @@ static int radv_amdgpu_create_bo_list(struct
radv_amdgpu_winsys *ws,
if (!cs->num_buffers)
continue;

-   if (unique_bo_count == 0) {
-memcpy(handles, cs->handles, cs->num_buffers * 
sizeof(amdgpu_bo_handle));
-memcpy(priorities, cs->priorities, cs->num_buffers * 
sizeof(uint8_t));

-   unique_bo_count = cs->num_buffers;
-   continue;
-   }
-   int unique_bo_so_far = unique_bo_count;
for (unsigned j = 0; j < cs->num_buffers; ++j) {
-   bool found = false;
-   for (unsigned k = 0; k < unique_bo_so_far; ++k) 
{
-   if (handles[k] == cs->handles[j]) {
-   found = true;
-   priorities[k] = 
MAX2(priorities[k],
-
cs->priorities[j]);
-   break;
-   }
-   }
-   if (!found) {
+   struct hash_entry *entry = 
_mesa_hash_table_search(ht, (void
*)cs->handles[j]);
+   if (!entry) {
+   _mesa_hash_table_insert(ht, (void 
*)cs->handles[j], (void
*)(uintptr_t)unique_bo_count);
handles[unique_bo_count] = 
cs->handles[j];
priorities[unique_bo_count] = 
cs->priorities[j];
++unique_bo_count;
+   } else {
+   int bo_idx = (uint32_t)(unsigned 
long)entry->data;
+   priorities[bo_idx] = 
MAX2(priorities[bo_idx],
+ 
cs->priorities[j]);
}
}
for (unsigned j = 0; j < cs->num_virtual_buffers; ++j) {
struct radv_amdgpu_winsys_bo *virtual_bo =
radv_amdgpu_winsys_bo(cs->virtual_buffers[j]);
for(unsigned k = 0; k < virtual_bo->bo_count; 
++k) {
struct radv_amdgpu_winsys_bo *bo = 
virtual_bo->bos[k];
-   bool found = false;
-   for (unsigned m = 0; m < 
unique_bo_count; ++m) {
-   if (handles[m] == bo->bo) {
-   found = true;
-   priorities[m] = 
MAX2(priorities[m],
-   
cs->virtual_buffer_priorities[j]);
-   break;
-   }
-   }
-   if (!found) {
+
+	struct hash_entry *entry = _mesa_hash_table_search(ht, (void 
*)bo->bo);

+   if (!entry) {
+   _mesa_hash_table_insert(ht, (void 
*)bo->bo, (void
*)(uintptr_t)unique_bo_count);
handles[unique_bo_count] = 
bo->bo;
priorities[unique_bo_count] = 
cs->virtual_buffer_priorities[j];
++unique_bo_count;
+

[Mesa-dev] [PATCH 1/2] nir: add image and smapler type to glsl_get_bit_size()

These are needed for ARB_bindless_texture support.
---
 src/compiler/nir_types.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compiler/nir_types.h b/src/compiler/nir_types.h
index 4397c2406f..e2dfd1ef5b 100644
--- a/src/compiler/nir_types.h
+++ b/src/compiler/nir_types.h
@@ -102,6 +102,8 @@ glsl_get_bit_size(const struct glsl_type *type)
case GLSL_TYPE_DOUBLE:
case GLSL_TYPE_INT64:
case GLSL_TYPE_UINT64:
+   case GLSL_TYPE_IMAGE:
+   case GLSL_TYPE_SAMPLER:
   return 64;
 
default:
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH 3/4] i965/bufmgr: Add a set_tiling helper

2018-01-18 Thread Jason Ekstrand

On Thu, Jan 18, 2018 at 4:30 PM, Kenneth Graunke 
wrote:

> On Friday, January 12, 2018 1:28:00 AM PST Chris Wilson wrote:
> > Quoting Jason Ekstrand (2018-01-12 01:40:52)
> > > This helper should be used carefully as setting tiling is a racy
> > > operation since it potentially interacts with other processes.  Still,
> > > it is a useful thing to be able to do.
> > >
> > > Cc: mesa-sta...@lists.freedesktop.org
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_bufmgr.c | 27
> +++
> > >  src/mesa/drivers/dri/i965/brw_bufmgr.h | 10 ++
> > >  2 files changed, 37 insertions(+)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > > index 469895e..dbd13dd 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > > @@ -1133,6 +1133,33 @@ brw_bo_get_tiling(struct brw_bo *bo, uint32_t
> *tiling_mode,
> > > return 0;
> > >  }
> > >
> > > +int
> > > +brw_bo_set_tiling(struct brw_bo *bo, uint32_t tiling_mode,
> > > +  uint32_t stride)
> > > +{
> > > +   struct brw_bufmgr *bufmgr = bo->bufmgr;
> > > +
> > > +   mtx_lock(>lock);
> >
> > This mutex protects the buffer cache, which should not be containing
> > this bo. Changing the tiling of a shared active bo also should not
> > happen because the other parties will have already derived state from
> > the older tiling. So I don't see the purpose of this mutex here.
> >
> > If we will need exclusive access to a bo, let's have a bo->lock.
> > -Chris
>
> I agree with Chris, I don't like this locking.  Looking more closely,
> I don't think patches 3-4 are what you want at all.
>
> intel_create_image_from_fds_common calls brw_bo_gem_create_from_prime.
> It's the only caller of that function.
>
> brw_bo_gem_create_from_prime allocates a new BO, does GET_TILING, and
> inserts it into the cache.  This is pointless after your patch 4,
> because you immediately whack it.
>
> So...instead...just make brw_bo_gem_create_from_prime take a tiling,
> and SET_TILING it...don't bother with GET_TILING at all.  Then, your
> BO isn't in the cache yet (or you have the cache locked), and it's
> safe without a race and redundant work.
>

I can rework things to do it that way.  I thought about it briefly but I
got hung up on how to handle the "use the tiling from the BO" case.  I
think I can use an int and pass -1 or something.  Or maybe add a
create_from_prime_tiled helper.

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

[Mesa-dev] [PATCH] ac: fix ac_build_varying_gather_values() for packed layouts

This fixes a segfault for varyings not starting at component 0.
---
 src/amd/common/ac_llvm_build.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 3467bba693..6615a269f8 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -413,7 +413,7 @@ ac_build_varying_gather_values(struct ac_llvm_context *ctx, 
LLVMValueRef *values
for (unsigned i = component; i < value_count + component; i++) {
LLVMValueRef value = values[i];
 
-   if (!i)
+   if (i == component)
vec = LLVMGetUndef( LLVMVectorType(LLVMTypeOf(value), 
value_count));
LLVMValueRef index = LLVMConstInt(ctx->i32, i - component, 
false);
vec = LLVMBuildInsertElement(ctx->builder, vec, value, index, 
"");
-- 
2.14.3

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

Re: [Mesa-dev] radeonsi nir arb_vertex_attrib_64bit fixes


Ping!
2 & 3 are missing r-b.
Welcome home, Nicolai -- Did you had nice vacation? ;-)

Am 08.01.2018 01:35, schrieb Timothy Arceri:

This series fixes all of the failing arb_vertex_attrib_64bit
piglit tests ~1000.

___
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] radeonsi: don't ignore pitch for imported textures


Ping!

Am 11.01.2018 04:45, schrieb Dieter Nützel:

Tested-by: Dieter Nützel 

on RX580 with UH, UV, glmark2 and Blender 2.79 with and without nir.

Dieter

Am 10.01.2018 20:49, schrieb Marek Olšák:

From: Marek Olšák 

Cc: 17.2 17.3 
---
 src/gallium/drivers/radeon/r600_texture.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index 34b3ab0..36eff40 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -291,25 +291,35 @@ static int r600_init_surface(struct si_screen 
*sscreen,

flags |= RADEON_SURF_IMPORTED | RADEON_SURF_SHAREABLE;
if (!(ptex->flags & R600_RESOURCE_FLAG_FORCE_TILING))
flags |= RADEON_SURF_OPTIMIZE_FOR_SPACE;

r = sscreen->ws->surface_init(sscreen->ws, ptex, flags, bpe,
  array_mode, surface);
if (r) {
return r;
}

+   unsigned pitch = pitch_in_bytes_override / bpe;
+
if (sscreen->info.chip_class >= GFX9) {
-   assert(!pitch_in_bytes_override ||
-		   pitch_in_bytes_override == surface->u.gfx9.surf_pitch * 
bpe);

+   if (pitch) {
+   surface->u.gfx9.surf_pitch = pitch;
+   surface->u.gfx9.surf_slice_size =
+   (uint64_t)pitch * surface->u.gfx9.surf_height * 
bpe;
+   }
surface->u.gfx9.surf_offset = offset;
} else {
+   if (pitch) {
+   surface->u.legacy.level[0].nblk_x = pitch;
+   surface->u.legacy.level[0].slice_size_dw =
+   ((uint64_t)pitch * 
surface->u.legacy.level[0].nblk_y * bpe) / 4;
+   }
if (offset) {
for (i = 0; i < ARRAY_SIZE(surface->u.legacy.level); 
++i)
surface->u.legacy.level[i].offset += offset;
}
}
return 0;
 }

 static void r600_texture_init_metadata(struct si_screen *sscreen,
   struct r600_texture *rtex,

___
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] docs: move untar line in basic testing instructions for coherence

On Thursday, 2018-01-18 23:06:40 +, Andres Gomez wrote:
> For scons, windows/mingw dealing with LLVM_CONFIG is done before
> untarring.

Isn't this a no-op change?

> This is also more convenient for copy and paste.

No objection though, this and the rest of the series is
Reviewed-by: Eric Engestrom 

> 
> Cc: Emil Velikov 
> Cc: Juan A. Suarez Romero 
> Signed-off-by: Andres Gomez 
> ---
>  docs/releasing.html | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/docs/releasing.html b/docs/releasing.html
> index f65d6d4173d..d105bc96f6a 100644
> --- a/docs/releasing.html
> +++ b/docs/releasing.html
> @@ -474,9 +474,9 @@ Here is one solution that I've been using.
>   cd ..  rm -rf mesa-$__version
>  
>   # Test the automake binaries
> - tar -xaf mesa-$__version.tar.xz  cd mesa-$__version
>   # Restore LLVM_CONFIG, if applicable:
>   # export LLVM_CONFIG=`echo $save_LLVM_CONFIG`; unset save_LLVM_CONFIG
> + tar -xaf mesa-$__version.tar.xz  cd mesa-$__version
>   ./configure \
>   --with-dri-drivers=i965,swrast \
>   --with-gallium-drivers=swrast \
> -- 
> 2.15.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] ac/nir: fix user sgpr allocations on gfx9

From: Dave Airlie 

The code to decide how to allocate sgprs didn't take into
account the merged shaders on gfx9.

This updates the code to count the correct number of requires
sgprs, which means we should be able to enable push const
inlining easier.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 38 +++---
 1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 02a46dab4db..7560b61e99b 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -565,8 +565,21 @@ static bool needs_view_index_sgpr(struct 
nir_to_llvm_context *ctx,
return false;
 }
 
+static int add_vertex_user_sgprs(const struct ac_shader_info *shader_info)
+{
+   int sgpr_count = 0;
+   sgpr_count += shader_info->vs.has_vertex_buffers ? 2 : 0;
+   if (shader_info->vs.needs_draw_id) {
+   sgpr_count += 3;
+   } else {
+   sgpr_count += 2;
+   }
+   return sgpr_count;
+}
+
 static void allocate_user_sgprs(struct nir_to_llvm_context *ctx,
gl_shader_stage stage,
+   bool has_previous_stage, gl_shader_stage 
previous_stage,
bool needs_view_index,
struct user_sgpr_info *user_sgpr_info)
 {
@@ -589,7 +602,6 @@ static void allocate_user_sgprs(struct nir_to_llvm_context 
*ctx,
user_sgpr_info->sgpr_count += 2;
}
 
-   /* FIXME: fix the number of user sgprs for merged shaders on GFX9 */
switch (stage) {
case MESA_SHADER_COMPUTE:
if (ctx->shader_info->info.cs.uses_grid_size)
@@ -599,24 +611,28 @@ static void allocate_user_sgprs(struct 
nir_to_llvm_context *ctx,
user_sgpr_info->sgpr_count += 
ctx->shader_info->info.ps.needs_sample_positions;
break;
case MESA_SHADER_VERTEX:
-   if (!ctx->is_gs_copy_shader) {
-   user_sgpr_info->sgpr_count += 
ctx->shader_info->info.vs.has_vertex_buffers ? 2 : 0;
-   if (ctx->shader_info->info.vs.needs_draw_id) {
-   user_sgpr_info->sgpr_count += 3;
-   } else {
-   user_sgpr_info->sgpr_count += 2;
-   }
-   }
+   if (!ctx->is_gs_copy_shader)
+   user_sgpr_info->sgpr_count += 
add_vertex_user_sgprs(>shader_info->info);
if (ctx->options->key.vs.as_ls)
user_sgpr_info->sgpr_count++;
break;
case MESA_SHADER_TESS_CTRL:
-   user_sgpr_info->sgpr_count += 4;
+   if (has_previous_stage) {
+   user_sgpr_info->sgpr_count += 
add_vertex_user_sgprs(>shader_info->info);
+   user_sgpr_info->sgpr_count += 5;
+   } else
+   user_sgpr_info->sgpr_count += 4;
break;
case MESA_SHADER_TESS_EVAL:
user_sgpr_info->sgpr_count += 1;
break;
case MESA_SHADER_GEOMETRY:
+   if (has_previous_stage) {
+   if (previous_stage == MESA_SHADER_VERTEX)
+   user_sgpr_info->sgpr_count += 
add_vertex_user_sgprs(>shader_info->info);
+   else if (previous_stage == MESA_SHADER_TESS_EVAL)
+   user_sgpr_info->sgpr_count += 1;
+   }
user_sgpr_info->sgpr_count += 2;
break;
default:
@@ -798,7 +814,7 @@ static void create_function(struct nir_to_llvm_context *ctx,
struct arg_info args = {};
LLVMValueRef desc_sets;
bool needs_view_index = needs_view_index_sgpr(ctx, stage);
-   allocate_user_sgprs(ctx, stage, needs_view_index, _sgpr_info);
+   allocate_user_sgprs(ctx, stage, has_previous_stage, stage, 
needs_view_index, _sgpr_info);
 
if (user_sgpr_info.need_ring_offsets && !ctx->options->supports_spill) {
add_arg(, ARG_SGPR, const_array(ctx->ac.v4i32, 16),
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH] radeonsi: don't ignore pitch for imported textures

2018-01-18 Thread Marek Olšák

I know. It's not been formally reviewed yet though.

marek

On Fri, Jan 19, 2018 at 4:34 AM, Dieter Nützel  wrote:
> Ping!
>
>
> Am 11.01.2018 04:45, schrieb Dieter Nützel:
>>
>> Tested-by: Dieter Nützel 
>>
>> on RX580 with UH, UV, glmark2 and Blender 2.79 with and without nir.
>>
>> Dieter
>>
>> Am 10.01.2018 20:49, schrieb Marek Olšák:
>>>
>>> From: Marek Olšák 
>>>
>>> Cc: 17.2 17.3 
>>> ---
>>>  src/gallium/drivers/radeon/r600_texture.c | 14 --
>>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/gallium/drivers/radeon/r600_texture.c
>>> b/src/gallium/drivers/radeon/r600_texture.c
>>> index 34b3ab0..36eff40 100644
>>> --- a/src/gallium/drivers/radeon/r600_texture.c
>>> +++ b/src/gallium/drivers/radeon/r600_texture.c
>>> @@ -291,25 +291,35 @@ static int r600_init_surface(struct si_screen
>>> *sscreen,
>>> flags |= RADEON_SURF_IMPORTED | RADEON_SURF_SHAREABLE;
>>> if (!(ptex->flags & R600_RESOURCE_FLAG_FORCE_TILING))
>>> flags |= RADEON_SURF_OPTIMIZE_FOR_SPACE;
>>>
>>> r = sscreen->ws->surface_init(sscreen->ws, ptex, flags, bpe,
>>>   array_mode, surface);
>>> if (r) {
>>> return r;
>>> }
>>>
>>> +   unsigned pitch = pitch_in_bytes_override / bpe;
>>> +
>>> if (sscreen->info.chip_class >= GFX9) {
>>> -   assert(!pitch_in_bytes_override ||
>>> -  pitch_in_bytes_override ==
>>> surface->u.gfx9.surf_pitch * bpe);
>>> +   if (pitch) {
>>> +   surface->u.gfx9.surf_pitch = pitch;
>>> +   surface->u.gfx9.surf_slice_size =
>>> +   (uint64_t)pitch *
>>> surface->u.gfx9.surf_height * bpe;
>>> +   }
>>> surface->u.gfx9.surf_offset = offset;
>>> } else {
>>> +   if (pitch) {
>>> +   surface->u.legacy.level[0].nblk_x = pitch;
>>> +   surface->u.legacy.level[0].slice_size_dw =
>>> +   ((uint64_t)pitch *
>>> surface->u.legacy.level[0].nblk_y * bpe) / 4;
>>> +   }
>>> if (offset) {
>>> for (i = 0; i <
>>> ARRAY_SIZE(surface->u.legacy.level); ++i)
>>> surface->u.legacy.level[i].offset +=
>>> offset;
>>> }
>>> }
>>> return 0;
>>>  }
>>>
>>>  static void r600_texture_init_metadata(struct si_screen *sscreen,
>>>struct r600_texture *rtex,
>>
>> ___
>> 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] [PATCH] i965: Drop render_target_start from binding table struct.

We have to start render targets at binding table index 0 in order to use
headerless FB write messages, and in fact already assume this in a bunch
of places in the code.  Let's finish that off, and not bother storing 0
in a struct to pretend to add it in a few places.
---
 src/intel/blorp/blorp.c | 1 -
 src/intel/compiler/brw_compiler.h   | 1 -
 src/intel/compiler/brw_fs_generator.cpp | 6 ++
 src/mesa/drivers/dri/i965/brw_wm.c  | 1 -
 4 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
index e8a2c6135f5..b7238306eb1 100644
--- a/src/intel/blorp/blorp.c
+++ b/src/intel/blorp/blorp.c
@@ -177,7 +177,6 @@ blorp_compile_fs(struct blorp_context *blorp, void *mem_ctx,
wm_prog_data->base.param = NULL;
 
/* BLORP always just uses the first two binding table entries */
-   wm_prog_data->binding_table.render_target_start = 
BLORP_RENDERBUFFER_BT_INDEX;
wm_prog_data->base.binding_table.texture_start = BLORP_TEXTURE_BT_INDEX;
 
nir = brw_preprocess_nir(compiler, nir);
diff --git a/src/intel/compiler/brw_compiler.h 
b/src/intel/compiler/brw_compiler.h
index 0060c381c0d..b1086bbcee5 100644
--- a/src/intel/compiler/brw_compiler.h
+++ b/src/intel/compiler/brw_compiler.h
@@ -681,7 +681,6 @@ struct brw_wm_prog_data {
   /** @{
* surface indices the WM-specific surfaces
*/
-  uint32_t render_target_start;
   uint32_t render_target_read_start;
   /** @} */
} binding_table;
diff --git a/src/intel/compiler/brw_fs_generator.cpp 
b/src/intel/compiler/brw_fs_generator.cpp
index 91bf0643084..cd5be054f69 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -287,8 +287,6 @@ fs_generator::fire_fb_write(fs_inst *inst,
 * messages set "Render Target Index" to 0.  Using a different binding
 * table index would make it impossible to use headerless messages.
 */
-   assert(prog_data->binding_table.render_target_start == 0);
-
const uint32_t surf_index = inst->target;
 
bool last_render_target = inst->eot ||
@@ -427,8 +425,8 @@ fs_generator::generate_fb_read(fs_inst *inst, struct 
brw_reg dst,
 {
assert(inst->size_written % REG_SIZE == 0);
struct brw_wm_prog_data *prog_data = brw_wm_prog_data(this->prog_data);
-   const unsigned surf_index =
-  prog_data->binding_table.render_target_start + inst->target;
+   /* We assume that render targets start at binding table index 0. */
+   const unsigned surf_index = inst->target;
 
gen9_fb_READ(p, dst, payload, surf_index,
 inst->header_size, inst->size_written / REG_SIZE,
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c 
b/src/mesa/drivers/dri/i965/brw_wm.c
index 08bacebd571..755a76eec71 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -51,7 +51,6 @@ assign_fs_binding_table_offsets(const struct gen_device_info 
*devinfo,
/* If there are no color regions, we still perform an FB write to a null
 * renderbuffer, which we place at surface index 0.
 */
-   prog_data->binding_table.render_target_start = next_binding_table_offset;
next_binding_table_offset += MAX2(key->nr_color_regions, 1);
 
next_binding_table_offset =
-- 
2.15.1

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

Re: [Mesa-dev] [PATCH 3/4] i965/bufmgr: Add a set_tiling helper

On Friday, January 12, 2018 1:28:00 AM PST Chris Wilson wrote:
> Quoting Jason Ekstrand (2018-01-12 01:40:52)
> > This helper should be used carefully as setting tiling is a racy
> > operation since it potentially interacts with other processes.  Still,
> > it is a useful thing to be able to do.
> > 
> > Cc: mesa-sta...@lists.freedesktop.org
> > ---
> >  src/mesa/drivers/dri/i965/brw_bufmgr.c | 27 +++
> >  src/mesa/drivers/dri/i965/brw_bufmgr.h | 10 ++
> >  2 files changed, 37 insertions(+)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
> > b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > index 469895e..dbd13dd 100644
> > --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > @@ -1133,6 +1133,33 @@ brw_bo_get_tiling(struct brw_bo *bo, uint32_t 
> > *tiling_mode,
> > return 0;
> >  }
> >  
> > +int
> > +brw_bo_set_tiling(struct brw_bo *bo, uint32_t tiling_mode,
> > +  uint32_t stride)
> > +{
> > +   struct brw_bufmgr *bufmgr = bo->bufmgr;
> > +
> > +   mtx_lock(>lock);
> 
> This mutex protects the buffer cache, which should not be containing
> this bo. Changing the tiling of a shared active bo also should not
> happen because the other parties will have already derived state from
> the older tiling. So I don't see the purpose of this mutex here.
> 
> If we will need exclusive access to a bo, let's have a bo->lock.
> -Chris

I agree with Chris, I don't like this locking.  Looking more closely,
I don't think patches 3-4 are what you want at all.

intel_create_image_from_fds_common calls brw_bo_gem_create_from_prime.
It's the only caller of that function.

brw_bo_gem_create_from_prime allocates a new BO, does GET_TILING, and
inserts it into the cache.  This is pointless after your patch 4,
because you immediately whack it.

So...instead...just make brw_bo_gem_create_from_prime take a tiling,
and SET_TILING it...don't bother with GET_TILING at all.  Then, your
BO isn't in the cache yet (or you have the cache locked), and it's
safe without a race and redundant work.

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

[Mesa-dev] [Bug 104677] radv_generate_graphics_pipeline_key reads input rate from incorrect binding

2018-01-18 Thread bugzilla-daemon

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

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Bas Nieuwenhuizen  ---
Fixed on git by

https://cgit.freedesktop.org/mesa/mesa/commit/?id=bd5c942cefc9f58aa6e8f6a9452f65e9d0d9d93a

-- 
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] mesa-dev mailing list is not listing the archived mails properly since January 2018 (?)

Hi,

maybe it has been mentioned and I have overlooked it. In that case,
sorry for the redundant mail.

I'm checking:
https://lists.freedesktop.org/archives/mesa-dev/2018-January/

And it seems very few messages are listed. Notice that you can access
directly to them, though.

I don't know if there is some work ongoing at freedesktop.org that has
made this happen or whether it is related to:
https://lists.freedesktop.org/archives/freedesktop/2018-January/000354.html

But I wanted to mention, just in case.

-- 
Br,

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

[Mesa-dev] [PATCH 4/5] docs: move untar line in basic testing instructions for coherence

For scons, windows/mingw dealing with LLVM_CONFIG is done before
untarring. This is also more convenient for copy and paste.

Cc: Emil Velikov 
Cc: Juan A. Suarez Romero 
Signed-off-by: Andres Gomez 
---
 docs/releasing.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/releasing.html b/docs/releasing.html
index f65d6d4173d..d105bc96f6a 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -474,9 +474,9 @@ Here is one solution that I've been using.
cd ..  rm -rf mesa-$__version
 
# Test the automake binaries
-   tar -xaf mesa-$__version.tar.xz  cd mesa-$__version
# Restore LLVM_CONFIG, if applicable:
# export LLVM_CONFIG=`echo $save_LLVM_CONFIG`; unset save_LLVM_CONFIG
+   tar -xaf mesa-$__version.tar.xz  cd mesa-$__version
./configure \
--with-dri-drivers=i965,swrast \
--with-gallium-drivers=swrast \
-- 
2.15.1

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

Re: [Mesa-dev] [PATCH] gallivm: avx-512 changes for texel fetcher

Am 18.01.2018 um 20:26 schrieb Kyriazis, George:
>> On Jan 18, 2018, at 1:10 PM, Roland Scheidegger > > wrote:
>>
>> Am 17.01.2018 um 23:33 schrieb George Kyriazis:
>>> The texture swizzle was not doing the right thing for avx512-style
>>> 16-wide loads.
>>>
>>> Special-case the post-load swizzle operations for avx512 so that we move
>>> the xyzw components correctly to the outputs.
>>>
>>> cc: Jose Fonseca >
>>> ---
>>> src/gallium/auxiliary/gallivm/lp_bld_pack.c | 40
>>> +++--
>>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
>>> b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
>>> index e8d4fcd..7879826 100644
>>> --- a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
>>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
>>> @@ -129,6 +129,31 @@ lp_build_const_unpack_shuffle_half(struct
>>> gallivm_state *gallivm,
>>> }
>>>
>>> /**
>>> + * Similar to lp_build_const_unpack_shuffle_half, but for AVX512
>>> + * See comment above lp_build_interleave2_half for more details.
>>> + */
>>> +static LLVMValueRef
>>> +lp_build_const_unpack_shuffle_16wide(struct gallivm_state *gallivm,
>>> + unsigned lo_hi)
>>> +{
>>> +   LLVMValueRef elems[LP_MAX_VECTOR_LENGTH];
>>> +   unsigned i, j;
>>> +
>>> +   assert(lo_hi < 2);
>>> +
>>> +   // for the following lo_hi setting, convert 0 -> f to:
>>> +   // 0: 0 16 4 20  8 24 12 28 1 17 5 21  9 25 13 29
>>> +   // 1: 2 18 6 22 10 26 14 30 3 19 7 23 11 27 15 31
>>> +   for (i = 0; i < 16; i++) {
>>> +  j = ((i&0x06)<<1) + ((i&1)<<4) + (i>>3) + (lo_hi<<1);
>>> +
>>> +  elems[i] = lp_build_const_int32(gallivm, j);
>>> +   }
>>> +
>>> +   return LLVMConstVector(elems, 16);
>>> +}
>>> +
>>> +/**
>>>  * Build shuffle vectors that match PACKxx (SSE) instructions or
>>>  * VPERM (Altivec).
>>>  */
>>> @@ -325,8 +350,8 @@ lp_build_interleave2(struct gallivm_state *gallivm,
>>> }
>>>
>>> /**
>>> - * Interleave vector elements but with 256 bit,
>>> - * treats it as interleave with 2 concatenated 128 bit vectors.
>>> + * Interleave vector elements but with 256 (or 512) bit,
>>> + * treats it as interleave with 2 concatenated 128 (or 256) bit vectors.
>>>  *
>>>  * This differs to lp_build_interleave2 as that function would do the
>>> following (for lo):
>>>  * a0 b0 a1 b1 a2 b2 a3 b3, and this does not compile into an AVX
>>> unpack instruction.
>>> @@ -343,6 +368,14 @@ lp_build_interleave2(struct gallivm_state *gallivm,
>>>  *
>>>  * And interleave-hi would result in:
>>>  *   a2 b2 a3 b3 a6 b6 a7 b7
>>> + *
>>> + * For 512 bits, the following are true:
>>> + *
>>> + * Interleave-lo would result in (capital letters denote hex indices):
>>> + *   a0 b0 a1 b1 a4 b4 a5 b5 a8 b8 a9 b9 aC bC aD bD
>>> + *
>>> + * Interleave-hi would result in:
>>> + *   a2 b2 a3 b3 a6 b6 a7 b7 aA bA aB bB aE bE aF bF
>>>  */
>>> LLVMValueRef
>>> lp_build_interleave2_half(struct gallivm_state *gallivm,
>>> @@ -354,6 +387,9 @@ lp_build_interleave2_half(struct gallivm_state
>>> *gallivm,
>>>    if (type.length * type.width == 256) {
>>>   LLVMValueRef shuffle =
>>> lp_build_const_unpack_shuffle_half(gallivm, type.length, lo_hi);
>>>   return LLVMBuildShuffleVector(gallivm->builder, a, b, shuffle, "");
>>> +   } else if ((type.length == 16) && (type.width == 32)) {
>>> +  LLVMValueRef shuffle =
>>> lp_build_const_unpack_shuffle_16wide(gallivm, lo_hi);
>>> +  return LLVMBuildShuffleVector(gallivm->builder, a, b, shuffle,
>>> "");
>> This is not really "interleave_half", more like "interleave_quarter"...
>> That said, avx512 certainly follows the same rules as avx256, so 128bit
>> pieces are treated independently. So maybe this should be renamed like
>> "interleave_native" or something like that.
>> Also, I believe it is definitely a mistake to restrict this to dword
>> interleaves here. You should handle all type widths, just like the
>> 256bit case can handle all widths.
>> And I'm not sure through which paths you reach this, but I'm not sure
>> why you don't need the corresponding unpack2_native and pack2_native
>> adjustments - it should not really be a special case, avx512 should
>> generally handle things like this (if you'd want to extend the gallivm
>> code to use avx512...). For that matter, the commit log and shortlog is
>> confusing, because this isn't directly related to texture fetching.
>>
> 
> Thanks Roland,
> 
> This check-in is a prerequisite for some avx-512 changes I am about to
> check in to the swr driver.  I’ve hit this for piglit test
> vs-texelfetch-isampler1d and similar ones that try to fetch from a
> texture from a VS.  You are right, there are probably other cases where
> this gets hit, but that was the place where I’ve hit it first.  If you
> could recommend some tests that hit the other width cases, it would be
> great to fix them too; since

[Mesa-dev] [PATCH] ac: add support for gl_HelperInvocation

---
 src/amd/common/ac_nir_to_llvm.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index cf0b3d998c..4f240db4ac 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3914,6 +3914,17 @@ static void emit_discard(struct ac_nir_context *ctx,
ac_build_kill_if_false(>ac, cond);
 }
 
+static LLVMValueRef
+visit_load_helper_invocation(struct ac_nir_context *ctx)
+{
+   LLVMValueRef result = ac_build_intrinsic(>ac,
+"llvm.amdgcn.ps.live",
+ctx->ac.i1, NULL, 0,
+AC_FUNC_ATTR_READNONE);
+   result = LLVMBuildNot(ctx->ac.builder, result, "");
+   return LLVMBuildSExt(ctx->ac.builder, result, ctx->ac.i32, "");
+}
+
 static LLVMValueRef
 visit_load_local_invocation_index(struct nir_to_llvm_context *ctx)
 {
@@ -4316,6 +4327,9 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
case nir_intrinsic_load_front_face:
result = ctx->abi->front_face;
break;
+   case nir_intrinsic_load_helper_invocation:
+   result = visit_load_helper_invocation(ctx);
+   break;
case nir_intrinsic_load_instance_id:
result = ctx->abi->instance_id;
break;
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH 5/7] report.py: Add option to only display measurements that have changes

On Friday, January 12, 2018 12:06:59 PM PST Ian Romanick wrote:
> From: Ian Romanick 
> 
> This is useful for preparing data to go in a Mesa commit message.
> 
> Signed-off-by: Ian Romanick 
> ---
>  report.py | 53 +++--
>  1 file changed, 31 insertions(+), 22 deletions(-)
> 
> diff --git a/report.py b/report.py
> index e0068bc..72752c1 100755
> --- a/report.py
> +++ b/report.py
> @@ -62,6 +62,8 @@ def main():
>  help="comma-separated list of measurements to 
> report")
>  parser.add_argument("--summary-only", "-s", action="store_true", 
> default=False,
>  help="do not show the per-shader helped / hurt data")
> +parser.add_argument("--changes-only", "-c", action="store_true", 
> default=False,
> +help="only show measurements that have changes")
>  parser.add_argument("before", type=get_results, help="the output of the 
> original code")
>  parser.add_argument("after", type=get_results, help="the output of the 
> new code")
>  args = parser.parse_args()
> @@ -116,14 +118,14 @@ def main():
>  if len(helped) > 0:
>  print("")
>  
> -hurt.sort(
> -key=lambda k: args.after[k][m] if args.before[k][m] == 0 
> else float(args.after[k][m] - args.before[k][m]) / args.before[k][m])
> -for p in hurt:
> -namestr = p[0] + " " + p[1]
> -print(m + " HURT:   " + get_result_string(
> -namestr, args.before[p][m], args.after[p][m]))
> -if len(hurt) > 0:
> -print("")
> +hurt.sort(
> +key=lambda k: args.after[k][m] if args.before[k][m] == 0 
> else float(args.after[k][m] - args.before[k][m]) / args.before[k][m])
> +for p in hurt:
> +namestr = p[0] + " " + p[1]
> +print(m + " HURT:   " + get_result_string(
> +namestr, args.before[p][m], args.after[p][m]))
> +if len(hurt) > 0:
> +print("")

Assuming you squash this back into patch 4 where it belongs, and take
Dylan's feedback, then patches 1-6 are:

Reviewed-by: Kenneth Graunke 

You mentioned that patch 7 is no good, so I don't plan to look at it.


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

[Mesa-dev] [PATCH 3.5/7] report.py: Don't use 'len(x) > 0' to check list emptiness

2018-01-18 Thread Ian Romanick

From: Ian Romanick 

Signed-off-by: Ian Romanick 
Suggested-by: Dylan Baker 
---
 report.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/report.py b/report.py
index 003a1ee..185b585 100755
--- a/report.py
+++ b/report.py
@@ -110,7 +110,7 @@ def main():
 namestr = p[0] + " " + p[1]
 print(m + " helped:   " + get_result_string(
 namestr, args.before[p][m], args.after[p][m]))
-if len(helped) > 0:
+if helped:
 print("")
 
 hurt.sort(
@@ -119,7 +119,7 @@ def main():
 namestr = p[0] + " " + p[1]
 print(m + " HURT:   " + get_result_string(
 namestr, args.before[p][m], args.after[p][m]))
-if len(hurt) > 0:
+if hurt:
 print("")
 
 num_helped[m] = len(helped)
@@ -140,13 +140,13 @@ def main():
 lost.sort()
 for p in lost:
 print("LOST:   " + p)
-if len(lost) > 0:
+if lost:
 print("")
 
 gained.sort()
 for p in gained:
 print("GAINED: " + p)
-if len(gained) > 0:
+if gained:
 print("")
 
 for m in args.measurements:
-- 
2.9.5

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

[Mesa-dev] [PATCH 3/3] ac/radeonsi: add emit primitive to the abi

---
 src/amd/common/ac_nir_to_llvm.c  | 6 --
 src/amd/common/ac_shader_abi.h   | 3 +++
 src/gallium/drivers/radeonsi/si_shader.c | 1 +
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 9709514532..cf0b3d998c 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -4206,8 +4206,9 @@ visit_emit_vertex(struct ac_shader_abi *abi, unsigned 
stream, LLVMValueRef *addr
 }
 
 static void
-visit_end_primitive(struct nir_to_llvm_context *ctx, unsigned stream)
+visit_end_primitive(struct ac_shader_abi *abi, unsigned stream)
 {
+   struct nir_to_llvm_context *ctx = nir_to_llvm_context_from_abi(abi);
ac_build_sendmsg(>ac, AC_SENDMSG_GS_OP_CUT | AC_SENDMSG_GS | 
(stream << 8), ctx->gs_wave_id);
 }
 
@@ -4419,7 +4420,7 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
ctx->abi->emit_vertex(ctx->abi, 0, ctx->outputs);
break;
case nir_intrinsic_end_primitive:
-   visit_end_primitive(ctx->nctx, nir_intrinsic_stream_id(instr));
+   ctx->abi->emit_primitive(ctx->abi, 
nir_intrinsic_stream_id(instr));
break;
case nir_intrinsic_load_tess_coord: {
LLVMTypeRef type = ctx->nctx ?
@@ -6766,6 +6767,7 @@ LLVMModuleRef 
ac_translate_nir_to_llvm(LLVMTargetMachineRef tm,
ctx.gs_next_vertex = ac_build_alloca(, 
ctx.ac.i32, "gs_next_vertex");
ctx.gs_max_out_vertices = 
shaders[i]->info.gs.vertices_out;
ctx.abi.load_inputs = load_gs_input;
+   ctx.abi.emit_primitive = visit_end_primitive;
} else if (shaders[i]->info.stage == MESA_SHADER_TESS_CTRL) {
ctx.tcs_outputs_read = shaders[i]->info.outputs_read;
ctx.tcs_patch_outputs_read = 
shaders[i]->info.patch_outputs_read;
diff --git a/src/amd/common/ac_shader_abi.h b/src/amd/common/ac_shader_abi.h
index c0f8ad26f4..d9bb5a1e32 100644
--- a/src/amd/common/ac_shader_abi.h
+++ b/src/amd/common/ac_shader_abi.h
@@ -70,6 +70,9 @@ struct ac_shader_abi {
unsigned stream,
LLVMValueRef *addrs);
 
+   void (*emit_primitive)(struct ac_shader_abi *abi,
+  unsigned stream);
+
LLVMValueRef (*load_inputs)(struct ac_shader_abi *abi,
unsigned location,
unsigned driver_location,
diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 04d3280051..38bb85a2dd 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -6037,6 +6037,7 @@ static bool si_compile_tgsi_main(struct si_shader_context 
*ctx,
bld_base->emit_fetch_funcs[TGSI_FILE_INPUT] = fetch_input_gs;
ctx->abi.load_inputs = si_nir_load_input_gs;
ctx->abi.emit_vertex = si_llvm_emit_vertex;
+   ctx->abi.emit_primitive = si_llvm_emit_primitive;
ctx->abi.emit_outputs = si_llvm_emit_gs_epilogue;
bld_base->emit_epilogue = si_tgsi_emit_gs_epilogue;
break;
-- 
2.14.3

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

[Mesa-dev] [PATCH] ac: fix emit vertex stream parameter

Fixes the following piglit test on radeonsi:

./bin/arb_enhanced_layouts-gs-stream-location-aliasing
---
 src/amd/common/ac_nir_to_llvm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index e88f64fb3b..a204182792 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -4159,6 +4159,8 @@ visit_emit_vertex(struct ac_shader_abi *abi, unsigned 
stream, LLVMValueRef *addr
int idx;
struct nir_to_llvm_context *ctx = nir_to_llvm_context_from_abi(abi);
 
+   assert(stream == 0);
+
/* Write vertex attribute values to GSVS ring */
gs_next_vertex = LLVMBuildLoad(ctx->builder,
   ctx->gs_next_vertex,
@@ -4428,8 +4430,7 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
result = visit_interp(ctx, instr);
break;
case nir_intrinsic_emit_vertex:
-   assert(instr->const_index[0] == 0);
-   ctx->abi->emit_vertex(ctx->abi, 0, ctx->outputs);
+   ctx->abi->emit_vertex(ctx->abi, instr->const_index[0], 
ctx->outputs);
break;
case nir_intrinsic_end_primitive:
ctx->abi->emit_primitive(ctx->abi, 
nir_intrinsic_stream_id(instr));
-- 
2.14.3

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

[Mesa-dev] [PATCH] ac: remove arrays when when querying sampler info

Fixes the following ARB_arrays_of_arrays piglit tests:

basic-imagestore-const-uniform-index
basic-imagestore-mixed-const-non-const-uniform-index
basic-imagestore-mixed-const-non-const-uniform-index2
basic-imagestore-non-const-uniform-index
---
 src/amd/common/ac_nir_to_llvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 4f240db4ac..345954c8b2 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3530,8 +3530,8 @@ static LLVMValueRef get_image_coords(struct 
ac_nir_context *ctx,
LLVMValueRef sample_index = ac_llvm_extract_elem(>ac, get_src(ctx, 
instr->src[1]), 0);
 
int count;
-   enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
-   bool is_array = glsl_sampler_type_is_array(type);
+   enum glsl_sampler_dim dim = 
glsl_get_sampler_dim(glsl_without_array(type));
+   bool is_array = glsl_sampler_type_is_array(glsl_without_array(type));
bool add_frag_pos = (dim == GLSL_SAMPLER_DIM_SUBPASS ||
 dim == GLSL_SAMPLER_DIM_SUBPASS_MS);
bool is_ms = (dim == GLSL_SAMPLER_DIM_MS ||
-- 
2.14.3

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

[Mesa-dev] [PATCH 3/5] docs: add a notice whenever a release is the final in a series

Cc: Emil Velikov 
Cc: Juan A. Suarez Romero 
Signed-off-by: Andres Gomez 
---
 docs/releasing.html | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/docs/releasing.html b/docs/releasing.html
index c7f5dfe5d2b..f65d6d4173d 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -272,6 +272,11 @@ It is followed by a brief period (normally 24 or 48 hours) 
before the actual
 release is made.
 
 
+
+Be aware to add a note to warn about a final release in a series, if
+that is the case.
+
+
 Terminology used
 
 Nominated
@@ -311,6 +316,10 @@ The candidate for the Mesa X.Y.Z is now available. 
Currently we have:
  - NUMBER nominated (outstanding)
  - and NUMBER rejected patches
 
+[If applicable:
+Note: this is the final anticipated release in the SERIES series. Users are
+encouraged to migrate to the NEXT_SERIES series in order to obtain future 
fixes.]
+
 BRIEF SUMMARY OF CHANGES
 
 Take a look at section "Mesa stable queue" for more information.
@@ -594,7 +603,8 @@ Something like the following steps will do the trick:
 
 
 Also, edit docs/relnotes.html to add a link to the new release notes,
-edit docs/index.html to add a news entry, and remove the version from
+edit docs/index.html to add a news entry and a note in case of the
+last release in a series, and remove the version from
 docs/release-calendar.html. Then commit and push:
 
 
@@ -610,6 +620,11 @@ docs/release-calendar.html. Then commit and push:
 Use the generated template during the releasing process.
 
 
+
+Again, pay attention to add a note to warn about a final release in a
+series, if that is the case.
+
+
 
 Update the mesa3d.org website
 
-- 
2.15.1

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

[Mesa-dev] [PATCH 2/5] docs: add final release note for 17.2.8

Cc: Emil Velikov 
Cc: Juan A. Suarez Romero 
Signed-off-by: Andres Gomez 
---
 docs/index.html | 4 
 1 file changed, 4 insertions(+)

diff --git a/docs/index.html b/docs/index.html
index 95a07150644..075956499d4 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -26,6 +26,10 @@ This is a bug-fix release.
 
 Mesa 17.2.8 is released.
 This is a bug-fix release.
+
+NOTE: It is anticipated that 17.2.8 will be the final release in the
+17.2 series. Users of 17.2 are encouraged to migrate to the 17.3
+series in order to obtain future fixes.
 
 
 December 21, 2017
-- 
2.15.1

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

Re: [Mesa-dev] [PATCH 4/4] vbo: fix VBO optimization regression

2018-01-18 Thread Brian Paul

I just pushed it and updated 
https://bugs.freedesktop.org/show_bug.cgi?id=104690


-Brian

On 01/18/2018 03:10 PM, Ian Romanick wrote:

Mark: Can you check that this fixes the G33 regression that you
mentioned to me this morning?

On 01/17/2018 02:57 PM, Brian Paul wrote:

The optimization in change 8e4efdc895ea ("vbo: optimize some display
list drawing") missed the loopback case.  This is used when the
glBegin/End primitive doesn't have a uniform set of vertex attributes.
The new Piglit gl-1.0-dlist-materials test hits this.

So check the aligned_vertex_buffer_offset(list) value and adjust the
buffer offset accordingly.

We also need to remove the 'start == 0' assertion in the loopback
code since it no longer applies.
---
  src/mesa/vbo/vbo_save_draw.c | 5 -
  src/mesa/vbo/vbo_save_loopback.c | 6 +++---
  2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index 6bccc85..a63e067 100644
--- a/src/mesa/vbo/vbo_save_draw.c
+++ b/src/mesa/vbo/vbo_save_draw.c
@@ -240,8 +240,11 @@ loopback_vertex_list(struct gl_context *ctx,
   list->vertex_store->bufferobj,
   MAP_INTERNAL);
  
+   unsigned buffer_offset =

+  aligned_vertex_buffer_offset(list) ? 0 : list->buffer_offset;
+
 vbo_loopback_vertex_list(ctx,
-(const GLfloat *)(buffer + list->buffer_offset),
+(const GLfloat *) (buffer + buffer_offset),
  list->attrsz,
  list->prims,
  list->prim_count,
diff --git a/src/mesa/vbo/vbo_save_loopback.c b/src/mesa/vbo/vbo_save_loopback.c
index 1dae91b..9c0e937 100644
--- a/src/mesa/vbo/vbo_save_loopback.c
+++ b/src/mesa/vbo/vbo_save_loopback.c
@@ -107,17 +107,17 @@ loopback_prim(struct gl_context *ctx,
 GLuint k;
  
 if (0)

-  printf("loopback prim %s(%s,%s) verts %d..%d\n",
+  printf("loopback prim %s(%s,%s) verts %d..%d  vsize %d\n",
   _mesa_lookup_prim_by_nr(prim->mode),
   prim->begin ? "begin" : "..",
   prim->end ? "end" : "..",
- start, end);
+ start, end,
+ vertex_size);
  
 if (prim->begin) {

CALL_Begin(GET_DISPATCH(), (prim->mode));
 }
 else {
-  assert(start == 0);
start += wrap_count;
 }
  





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

Re: [Mesa-dev] [PATCH v2] meson: Don't confuse the install and search paths for dri drivers

On Thursday, 2018-01-18 17:09:33 +, Dylan Baker wrote:
> Currently there is not a separate option for setting the search path of
> DRI drivers in meson, like there is in scons and autotools. This is an
> oversight and needs to be fixed. This adds an extra option
> `dri-search-path`, which will default to the value of
> `dri-drivers-path`, like autotools does.
> 
> v2: - Split input list before joining.
> 
> Reported-by: Ilia Mirkin 
> Signed-off-by: Dylan Baker 
> ---
>  meson.build | 6 ++
>  meson_options.txt   | 8 +++-
>  src/egl/meson.build | 2 +-
>  src/gbm/meson.build | 2 +-
>  src/glx/meson.build | 3 ++-
>  5 files changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index f3179c38062..8bab43681e9 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -57,6 +57,12 @@ dri_drivers_path = get_option('dri-drivers-path')
>  if dri_drivers_path == ''
>dri_drivers_path = join_paths(get_option('libdir'), 'dri')
>  endif
> +_search = get_option('dri-search-path')
> +if _search != ''
> +  dri_search_path = ';'.join(_search.split(','))

s/;/:/

Reviewed-by: Eric Engestrom 

> +else
> +  dri_search_path = dri_drivers_path
> +endif
>  
>  with_gles1 = get_option('gles1')
>  with_gles2 = get_option('gles2')
> diff --git a/meson_options.txt b/meson_options.txt
> index 894378985fd..e541659733f 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -41,7 +41,13 @@ option(
>'dri-drivers-path',
>type : 'string',
>value : '',
> -  description : 'Location of dri drivers. Default: $libdir/dri.'
> +  description : 'Location to install dri drivers. Default: $libdir/dri.'
> +)
> +option(
> +  'dri-search-path',
> +  type : 'string',
> +  value : '',
> +  description : 'Locations to search for dri drivers, passed as comma 
> separated list. Default: dri-drivers-path.'
>  )
>  option(
>'gallium-drivers',
> diff --git a/src/egl/meson.build b/src/egl/meson.build
> index df6e8b49dac..6cd04567b0d 100644
> --- a/src/egl/meson.build
> +++ b/src/egl/meson.build
> @@ -160,7 +160,7 @@ libegl = shared_library(
>c_args : [
>  c_vis_args,
>  c_args_for_egl,
> -'-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_driver_dir),
> +'-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path),
>  '-D_EGL_BUILT_IN_DRIVER_DRI2',
>  
> '-D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_@0@'.format(egl_native_platform.to_upper()),
>],
> diff --git a/src/gbm/meson.build b/src/gbm/meson.build
> index 14b9e960360..2f5d1c6ddd7 100644
> --- a/src/gbm/meson.build
> +++ b/src/gbm/meson.build
> @@ -38,7 +38,7 @@ incs_gbm = [
>  if with_dri2
>files_gbm += files('backends/dri/gbm_dri.c', 'backends/dri/gbm_driint.h')
>deps_gbm += dep_libdrm # TODO: pthread-stubs
> -  args_gbm += '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_driver_dir)
> +  args_gbm += '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path)
>  endif
>  if with_platform_wayland
>deps_gbm += dep_wayland_server
> diff --git a/src/glx/meson.build b/src/glx/meson.build
> index 04cd647ee49..508e7583ee5 100644
> --- a/src/glx/meson.build
> +++ b/src/glx/meson.build
> @@ -128,7 +128,8 @@ else
>  endif
>  
>  gl_lib_cargs = [
> -  '-D_REENTRANT', '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_driver_dir),
> +  '-D_REENTRANT',
> +  '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path),
>  ]
>  
>  if dep_xxf86vm != [] and dep_xxf86vm.found()
> -- 
> 2.15.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 4/4] vbo: fix VBO optimization regression

2018-01-18 Thread Ian Romanick

Mark: Can you check that this fixes the G33 regression that you
mentioned to me this morning?

On 01/17/2018 02:57 PM, Brian Paul wrote:
> The optimization in change 8e4efdc895ea ("vbo: optimize some display
> list drawing") missed the loopback case.  This is used when the
> glBegin/End primitive doesn't have a uniform set of vertex attributes.
> The new Piglit gl-1.0-dlist-materials test hits this.
> 
> So check the aligned_vertex_buffer_offset(list) value and adjust the
> buffer offset accordingly.
> 
> We also need to remove the 'start == 0' assertion in the loopback
> code since it no longer applies.
> ---
>  src/mesa/vbo/vbo_save_draw.c | 5 -
>  src/mesa/vbo/vbo_save_loopback.c | 6 +++---
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
> index 6bccc85..a63e067 100644
> --- a/src/mesa/vbo/vbo_save_draw.c
> +++ b/src/mesa/vbo/vbo_save_draw.c
> @@ -240,8 +240,11 @@ loopback_vertex_list(struct gl_context *ctx,
>   list->vertex_store->bufferobj,
>   MAP_INTERNAL);
>  
> +   unsigned buffer_offset =
> +  aligned_vertex_buffer_offset(list) ? 0 : list->buffer_offset;
> +
> vbo_loopback_vertex_list(ctx,
> -(const GLfloat *)(buffer + list->buffer_offset),
> +(const GLfloat *) (buffer + buffer_offset),
>  list->attrsz,
>  list->prims,
>  list->prim_count,
> diff --git a/src/mesa/vbo/vbo_save_loopback.c 
> b/src/mesa/vbo/vbo_save_loopback.c
> index 1dae91b..9c0e937 100644
> --- a/src/mesa/vbo/vbo_save_loopback.c
> +++ b/src/mesa/vbo/vbo_save_loopback.c
> @@ -107,17 +107,17 @@ loopback_prim(struct gl_context *ctx,
> GLuint k;
>  
> if (0)
> -  printf("loopback prim %s(%s,%s) verts %d..%d\n",
> +  printf("loopback prim %s(%s,%s) verts %d..%d  vsize %d\n",
>   _mesa_lookup_prim_by_nr(prim->mode),
>   prim->begin ? "begin" : "..",
>   prim->end ? "end" : "..",
> - start, end);
> + start, end,
> + vertex_size);
>  
> if (prim->begin) {
>CALL_Begin(GET_DISPATCH(), (prim->mode));
> }
> else {
> -  assert(start == 0);
>start += wrap_count;
> }
>  
> 

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

[Mesa-dev] [PATCH 5/5] docs: correct a typo in releasing instructions

Cc: Emil Velikov 
Cc: Juan A. Suarez Romero 
Signed-off-by: Andres Gomez 
---
 docs/releasing.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/releasing.html b/docs/releasing.html
index d105bc96f6a..a022d0c484b 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -96,7 +96,7 @@ described in the same section.
 
 
 Nomination happens in the mesa-stable@ mailing list. However,
-maintainer is resposible of checking for forgotten candidates in the
+maintainer is responsible of checking for forgotten candidates in the
 master branch. This is achieved by a combination of ad-hoc scripts and
 a casual search for terms such as regression, fix, broken and similar.
 
-- 
2.15.1

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

[Mesa-dev] [PATCH 2/3] radeonsi: add generic emit primitive helper

This will be shared by the tgsi and nir backends.
---
 src/gallium/drivers/radeonsi/si_shader.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 57b4a21a2a..04d3280051 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -4395,18 +4395,25 @@ static void si_tgsi_emit_vertex(
 }
 
 /* Cut one primitive from the geometry shader */
-static void si_llvm_emit_primitive(
+static void si_llvm_emit_primitive(struct ac_shader_abi *abi,
+  unsigned stream)
+{
+   struct si_shader_context *ctx = si_shader_context_from_abi(abi);
+
+   /* Signal primitive cut */
+   ac_build_sendmsg(>ac, AC_SENDMSG_GS_OP_CUT | AC_SENDMSG_GS | 
(stream << 8),
+si_get_gs_wave_id(ctx));
+}
+
+/* Cut one primitive from the geometry shader */
+static void si_tgsi_emit_primitive(
const struct lp_build_tgsi_action *action,
struct lp_build_tgsi_context *bld_base,
struct lp_build_emit_data *emit_data)
 {
struct si_shader_context *ctx = si_shader_context(bld_base);
-   unsigned stream;
 
-   /* Signal primitive cut */
-   stream = si_llvm_get_stream(bld_base, emit_data);
-   ac_build_sendmsg(>ac, AC_SENDMSG_GS_OP_CUT | AC_SENDMSG_GS | 
(stream << 8),
-si_get_gs_wave_id(ctx));
+   si_llvm_emit_primitive(>abi, si_llvm_get_stream(bld_base, 
emit_data));
 }
 
 static void si_llvm_emit_barrier(const struct lp_build_tgsi_action *action,
@@ -5917,7 +5924,7 @@ static void si_init_shader_ctx(struct si_shader_context 
*ctx,
bld_base->op_actions[TGSI_OPCODE_READ_INVOC].emit = read_lane_emit;
 
bld_base->op_actions[TGSI_OPCODE_EMIT].emit = si_tgsi_emit_vertex;
-   bld_base->op_actions[TGSI_OPCODE_ENDPRIM].emit = si_llvm_emit_primitive;
+   bld_base->op_actions[TGSI_OPCODE_ENDPRIM].emit = si_tgsi_emit_primitive;
bld_base->op_actions[TGSI_OPCODE_BARRIER].emit = si_llvm_emit_barrier;
 }
 
-- 
2.14.3

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

[Mesa-dev] [PATCH 1/3] ac: add stream handling to visit_end_primitive()

---
 src/amd/common/ac_nir_to_llvm.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 12353943a5..9709514532 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -4206,10 +4206,9 @@ visit_emit_vertex(struct ac_shader_abi *abi, unsigned 
stream, LLVMValueRef *addr
 }
 
 static void
-visit_end_primitive(struct nir_to_llvm_context *ctx,
-   const nir_intrinsic_instr *instr)
+visit_end_primitive(struct nir_to_llvm_context *ctx, unsigned stream)
 {
-   ac_build_sendmsg(>ac, AC_SENDMSG_GS_OP_CUT | AC_SENDMSG_GS | (0 << 
8), ctx->gs_wave_id);
+   ac_build_sendmsg(>ac, AC_SENDMSG_GS_OP_CUT | AC_SENDMSG_GS | 
(stream << 8), ctx->gs_wave_id);
 }
 
 static LLVMValueRef
@@ -4420,7 +4419,7 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
ctx->abi->emit_vertex(ctx->abi, 0, ctx->outputs);
break;
case nir_intrinsic_end_primitive:
-   visit_end_primitive(ctx->nctx, instr);
+   visit_end_primitive(ctx->nctx, nir_intrinsic_stream_id(instr));
break;
case nir_intrinsic_load_tess_coord: {
LLVMTypeRef type = ctx->nctx ?
-- 
2.14.3

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

[Mesa-dev] [ANNOUNCE] mesa 17.3.3

2018-01-18 Thread Juan A. Suarez Romero

Mesa 17.3.3 is now available.

In this release we have:

The RADV driver gets several fixes around the resolve pass. It also gets fixes
to solve a mpv hang, pipeline statistics, and other few issues.

Worth to note that several of these the fixes improves the RADV VEGA support.

Intel's ANV driver is also getting different fixes. Couple of this fixes solves
several issues related with GPU hangs and rendering errors. Others fixes minor
issues.

We have a fix related with DRI3 that avoids freeing renderbuffers when they are
in use, which was causing several issues.

Finally, the etnaviv, swrast and radeonsi are getting a few fixes each.

Alex Smith (3):
anv: Add missing unlock in anv_scratch_pool_alloc
anv: Take write mask into account in has_color_buffer_write_enabled
anv: Make sure state on primary is correct after CmdExecuteCommands

Andres Gomez (1):
anv: Import mako templates only during execution of anv_extensions

Bas Nieuwenhuizen (11):
radv: Invert condition for all samples identical during resolve.
radv: Flush caches before subpass resolve.
radv: Fix fragment resolve destination offset.
radv: Use correct framebuffer size for partial FS resolves.
radv: Always use fragment resolve if dest uses DCC.
Revert "radv/gfx9: fix block compression texture views."
radv: Use correct HTILE expanded words.
radv: Allow writing 0 scissors.
ac/nir: Handle loading data from compact arrays.
radv: Invalidate L1 for VK_ACCESS_VERTEX_ATTRIBUTE_READ_BIT.
ac/nir: Sanitize location_frac for local variables.

Dave Airlie (8):
radv: fix events on compute queues.
radv: fix pipeline statistics end query on compute queue
radv/gfx9: fix 3d image to image transfers on compute queues.
radv/gfx9: fix 3d image clears on compute queues
radv/gfx9: fix buffer to image for 3d images on compute queues
radv/gfx9: fix block compression texture views.
radv/gfx9: use a bigger hammer to flush cb/db caches.
radv/gfx9: use correct swizzle parameter to work out border swizzle.

Emil Velikov (1):
docs: add sha256 checksums for 17.3.2

Florian Will (1):
glsl: Respect std430 layout in lower_buffer_access

Juan A. Suarez Romero (7):
cherry-ignore: intel/fs: Use the original destination region for int MUL
lowering
cherry-ignore: i965/fs: Use UW types when using V immediates
cherry-ignore: main: Clear shader program data whenever ProgramBinary is
called
cherry-ignore: egl: pass the dri2_dpy to the $plat_teardown functions
cherry-ignore: vulkan/wsi: free cmd pools
Update version to 17.3.3
docs: add release notes for 17.3.3

Józef Kucia (1):
radeonsi: fix alpha-to-coverage if color writes are disabled

Kenneth Graunke (2):
i965: Require space for MI_BATCHBUFFER_END.
i965: Torch public intel_batchbuffer_emit_dword/float helpers.

Lucas Stach (1):
etnaviv: disable in-place resolve for non-supertiled surfaces

Samuel Iglesias Gonsálvez (1):
anv: VkDescriptorSetLayoutBinding can have descriptorCount == 0

Thomas Hellstrom (1):
loader/dri3: Avoid freeing renderbuffers in use

Tim Rowley (1):
swr/rast: fix invalid sign masks in avx512 simdlib code

git tag: mesa-17.3.3

https://mesa.freedesktop.org/archive/mesa-17.3.3.tar.gz
MD5: 3063544c6db2421e0b295e05a0d01f88 mesa-17.3.3.tar.gz
SHA1: b0c775938c1bc9fc61531b814b6716cb1a45063d mesa-17.3.3.tar.gz
SHA256: c733d37a161501cd81dc9b309ccb613753b98eafc6d35e0847548a6642749772
mesa-17.3.3.tar.gz
SHA512:
74641a409ddad11bf3eee011e59bd95cbb92de47a1f4a242a6cd04f7d97d3fd68d0d47e7a893345ebef01d9ebc8915c715b0691de82e357e85282bcf5fb95e45
mesa-17.3.3.tar.gz
PGP: https://mesa.freedesktop.org/archive/mesa-17.3.3.tar.gz.sig

https://mesa.freedesktop.org/archive/mesa-17.3.3.tar.xz
MD5: 139b5f608b371c0d4395596162f88791 mesa-17.3.3.tar.xz
SHA1: 346f7813f493b1daf9d9079826a13dbd722b86ab mesa-17.3.3.tar.xz
SHA256: 41bac5de0ef6adc1f41a1ec0f80c19e361298ce02fa81b5f9ba4fdca33a9379b
mesa-17.3.3.tar.xz
SHA512:
7ac8ecdcf3b2b43239835bc2c5da7f2730f80a2db945fe00df03d1548920fbc074dd4806ddd345a1ce682fd29d75b2209ef81b6b06e657f9c8ae8622a34a03c1
mesa-17.3.3.tar.xz
PGP: https://mesa.freedesktop.org/archive/mesa-17.3.3.tar.xz.sig

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

[Mesa-dev] Logging infrastructure?

Is there a logging infrastructure currently available to drivers in Mesa?
I was looking to clean up some of swr's debug / info output and have it
conditional on the MESA_DEBUG and LIBGL_DEBUG variables but then I realized
that it's really something useful all across mesa so there may already be
something there for it.  If not though, I'd be interested in adding some
very light weight functions for just that purpose could be used by any
driver rather than just fprintf(stderr, ...);


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

[Mesa-dev] [PATCH] i965: Rename 'aux' to 'prog_data' in program cache.

'aux' is a very generic name, suggesting it can be a bunch of things.
However, it's always the brw_*_prog_data structure.  So, call it that.
---
 src/mesa/drivers/dri/i965/brw_program_cache.c | 31 ++-
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_program_cache.c 
b/src/mesa/drivers/dri/i965/brw_program_cache.c
index adb0cd5a23b..9266273b5da 100644
--- a/src/mesa/drivers/dri/i965/brw_program_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_program_cache.c
@@ -69,7 +69,7 @@ struct brw_cache_item {
 
/** for variable-sized keys */
GLuint key_size;
-   GLuint aux_size;
+   GLuint prog_data_size;
const void *key;
 
uint32_t offset;
@@ -182,7 +182,7 @@ bool
 brw_search_cache(struct brw_cache *cache,
  enum brw_cache_id cache_id,
  const void *key, GLuint key_size,
- uint32_t *inout_offset, void *inout_aux)
+ uint32_t *inout_offset, void *inout_prog_data)
 {
struct brw_context *brw = cache->brw;
struct brw_cache_item *item;
@@ -200,12 +200,13 @@ brw_search_cache(struct brw_cache *cache,
if (item == NULL)
   return false;
 
-   void *aux = ((char *) item->key) + item->key_size;
+   void *prog_data = ((char *) item->key) + item->key_size;
 
-   if (item->offset != *inout_offset || aux != *((void **) inout_aux)) {
+   if (item->offset != *inout_offset ||
+   prog_data != *((void **) inout_prog_data)) {
   brw->ctx.NewDriverState |= (1 << cache_id);
   *inout_offset = item->offset;
-  *((void **) inout_aux) = aux;
+  *((void **) inout_prog_data) = prog_data;
}
 
return true;
@@ -320,10 +321,10 @@ brw_upload_cache(struct brw_cache *cache,
  GLuint key_size,
  const void *data,
  GLuint data_size,
- const void *aux,
- GLuint aux_size,
+ const void *prog_data,
+ GLuint prog_data_size,
  uint32_t *out_offset,
- void *out_aux)
+ void *out_prog_data)
 {
struct brw_cache_item *item = CALLOC_STRUCT(brw_cache_item);
const struct brw_cache_item *matching_data =
@@ -335,7 +336,7 @@ brw_upload_cache(struct brw_cache *cache,
item->size = data_size;
item->key = key;
item->key_size = key_size;
-   item->aux_size = aux_size;
+   item->prog_data_size = prog_data_size;
hash = hash_key(item);
item->hash = hash;
 
@@ -354,11 +355,11 @@ brw_upload_cache(struct brw_cache *cache,
   memcpy(cache->map + item->offset, data, data_size);
}
 
-   /* Set up the memory containing the key and aux_data */
-   tmp = malloc(key_size + aux_size);
+   /* Set up the memory containing the key and prog_data */
+   tmp = malloc(key_size + prog_data_size);
 
memcpy(tmp, key, key_size);
-   memcpy(tmp + key_size, aux, aux_size);
+   memcpy(tmp + key_size, prog_data, prog_data_size);
 
item->key = tmp;
 
@@ -371,7 +372,7 @@ brw_upload_cache(struct brw_cache *cache,
cache->n_items++;
 
*out_offset = item->offset;
-   *(void **)out_aux = (void *)((char *)item->key + item->key_size);
+   *(void **)out_prog_data = (void *)((char *)item->key + item->key_size);
cache->brw->ctx.NewDriverState |= 1 << cache_id;
 }
 
@@ -412,8 +413,8 @@ brw_clear_cache(struct brw_context *brw, struct brw_cache 
*cache)
  c->cache_id == BRW_CACHE_GS_PROG ||
  c->cache_id == BRW_CACHE_FS_PROG ||
  c->cache_id == BRW_CACHE_CS_PROG) {
-const void *item_aux = c->key + c->key_size;
-brw_stage_prog_data_free(item_aux);
+const void *item_prog_data = c->key + c->key_size;
+brw_stage_prog_data_free(item_prog_data);
  }
  free((void *)c->key);
  free(c);
-- 
2.15.1

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

[Mesa-dev] [PATCH v2] autotools: include meson build files in tarball

This adds the meson.build, meson_options.txt, and a few scripts that are
used exclusively by the meson build.

v2: - Remove accidentally included changes needed to test make dist with
  LLVM > 3.9

Signed-off-by: Dylan Baker 
Acked-by: Eric Engestrom 
---
 Makefile.am |  7 ++-
 src/Makefile.am |  2 +-
 src/amd/Makefile.am |  9 -
 src/amd/vulkan/Makefile.am  |  3 ++-
 src/broadcom/Makefile.am|  7 ++-
 src/compiler/Makefile.am|  9 -
 src/egl/Makefile.am |  3 ++-
 src/egl/wayland/wayland-drm/Makefile.am |  2 +-
 src/egl/wayland/wayland-egl/Makefile.am |  2 +-
 src/gallium/Makefile.am |  3 ++-
 src/gallium/auxiliary/Makefile.am   |  3 ++-
 src/gallium/auxiliary/pipe-loader/Makefile.am   |  2 +-
 src/gallium/drivers/ddebug/Makefile.am  |  2 ++
 src/gallium/drivers/etnaviv/Makefile.am |  2 ++
 src/gallium/drivers/freedreno/Makefile.am   |  2 ++
 src/gallium/drivers/i915/Makefile.am|  2 +-
 src/gallium/drivers/llvmpipe/Makefile.am|  2 +-
 src/gallium/drivers/noop/Makefile.am|  2 +-
 src/gallium/drivers/nouveau/Makefile.am |  2 +-
 src/gallium/drivers/r300/Makefile.am|  3 ++-
 src/gallium/drivers/r600/Makefile.am|  3 ++-
 src/gallium/drivers/radeon/Makefile.am  |  2 ++
 src/gallium/drivers/radeonsi/Makefile.am|  1 +
 src/gallium/drivers/rbug/Makefile.am|  2 +-
 src/gallium/drivers/softpipe/Makefile.am|  2 +-
 src/gallium/drivers/svga/Makefile.am|  3 ++-
 src/gallium/drivers/swr/Makefile.am |  2 ++
 src/gallium/drivers/trace/Makefile.am   |  3 ++-
 src/gallium/drivers/vc4/Makefile.am |  2 +-
 src/gallium/drivers/vc5/Makefile.am |  2 ++
 src/gallium/drivers/virgl/Makefile.am   |  2 ++
 src/gallium/state_trackers/clover/Makefile.am   |  2 +-
 src/gallium/state_trackers/dri/Makefile.am  |  2 +-
 src/gallium/state_trackers/glx/xlib/Makefile.am |  2 +-
 src/gallium/state_trackers/nine/Makefile.am |  2 +-
 src/gallium/state_trackers/omx_bellagio/Makefile.am |  2 ++
 src/gallium/state_trackers/osmesa/Makefile.am   |  2 +-
 src/gallium/state_trackers/va/Makefile.am   |  2 ++
 src/gallium/state_trackers/vdpau/Makefile.am|  2 ++
 src/gallium/state_trackers/xa/Makefile.am   |  2 +-
 src/gallium/state_trackers/xvmc/Makefile.am |  2 ++
 src/gallium/targets/d3dadapter9/Makefile.am |  2 +-
 src/gallium/targets/dri/Makefile.am |  1 +
 src/gallium/targets/libgl-xlib/Makefile.am  |  2 +-
 src/gallium/targets/omx-bellagio/Makefile.am|  2 +-
 src/gallium/targets/opencl/Makefile.am  |  2 +-
 src/gallium/targets/osmesa/Makefile.am  |  3 ++-
 src/gallium/targets/pipe-loader/Makefile.am |  2 +-
 src/gallium/targets/va/Makefile.am  |  2 +-
 src/gallium/targets/vdpau/Makefile.am   |  3 ++-
 src/gallium/targets/xa/Makefile.am  |  2 +-
 src/gallium/targets/xvmc/Makefile.am|  2 +-
 src/gallium/winsys/amdgpu/drm/Makefile.am   |  2 ++
 src/gallium/winsys/etnaviv/drm/Makefile.am  |  2 ++
 src/gallium/winsys/freedreno/drm/Makefile.am|  2 ++
 src/gallium/winsys/i915/drm/Makefile.am |  2 ++
 src/gallium/winsys/imx/drm/Makefile.am  |  2 ++
 src/gallium/winsys/nouveau/drm/Makefile.am  |  2 ++
 src/gallium/winsys/pl111/drm/Makefile.am|  2 ++
 src/gallium/winsys/radeon/drm/Makefile.am   |  2 ++
 src/gallium/winsys/svga/drm/Makefile.am |  2 +-
 src/gallium/winsys/sw/dri/Makefile.am   |  2 +-
 src/gallium/winsys/sw/kms-dri/Makefile.am   |  2 ++
 src/gallium/winsys/sw/null/Makefile.am  |  2 +-
 src/gallium/winsys/sw/wrapper/Makefile.am   |  2 +-
 src/gallium/winsys/sw/xlib/Makefile.am  |  2 +-
 src/gallium/winsys/vc4/drm/Makefile.am  |  2 ++
 src/gallium/winsys/vc5/drm/Makefile.am  |  2 ++
 src/gallium/winsys/virgl/drm/Makefile.am|  2 ++
 src/gallium/winsys/virgl/vtest/Makefile.am  |  2 ++
 src/gbm/Makefile.am |  2 +-
 src/glx/Makefile.am |  2 +-
 src/glx/tests/Makefile.am   |  2 +-
 src/glx/windows/Makefile.am |  2 ++
 src/gtest/Makefile.am   |  3 ++-
 src/intel/Makefile.am   | 10 +-

Re: [Mesa-dev] [PATCH 1/4] i965/miptree: Add an explicit tiling parameter to create_for_bo

On Thursday, January 11, 2018 5:40:50 PM PST Jason Ekstrand wrote:
> From: Jason Ekstrand 
> 
> Otherwise, create_for_bo will just grab the tiling from the BO which is
> not what we want when using modifiers.
> 
> Cc: mesa-sta...@lists.freedesktop.org

Patches 1-2 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] [PATCH] autotools: include meson build files in tarball

Quoting Eric Engestrom (2018-01-18 13:04:00)
> On Thursday, 2018-01-18 17:09:04 +, Dylan Baker wrote:
> > This adds the meson.build, meson_options.txt, and a few scripts that are
> > used exclusively by the meson build.
> > 
> > Signed-off-by: Dylan Baker 
> 
> I could've sworn we already some $(shell find -name meson.build) thing
> for this?
> 
> One note below (in src/gallium/drivers/swr/Makefile.am), but with that
> fixed:
> Acked-by: Eric Engestrom 
> 
> > ---
> >  Makefile.am |  7 ++-
> >  src/Makefile.am |  2 +-
> >  src/amd/Makefile.am |  9 -
> >  src/amd/vulkan/Makefile.am  |  3 ++-
> >  src/broadcom/Makefile.am|  7 ++-
> >  src/compiler/Makefile.am|  9 -
> >  src/egl/Makefile.am |  3 ++-
> >  src/egl/wayland/wayland-drm/Makefile.am |  2 +-
> >  src/egl/wayland/wayland-egl/Makefile.am |  2 +-
> >  src/gallium/Makefile.am |  3 ++-
> >  src/gallium/auxiliary/Makefile.am   |  3 ++-
> >  src/gallium/auxiliary/pipe-loader/Makefile.am   |  2 +-
> >  src/gallium/drivers/ddebug/Makefile.am  |  2 ++
> >  src/gallium/drivers/etnaviv/Makefile.am |  2 ++
> >  src/gallium/drivers/freedreno/Makefile.am   |  2 ++
> >  src/gallium/drivers/i915/Makefile.am|  2 +-
> >  src/gallium/drivers/llvmpipe/Makefile.am|  2 +-
> >  src/gallium/drivers/noop/Makefile.am|  2 +-
> >  src/gallium/drivers/nouveau/Makefile.am |  2 +-
> >  src/gallium/drivers/r300/Makefile.am|  3 ++-
> >  src/gallium/drivers/r600/Makefile.am|  3 ++-
> >  src/gallium/drivers/radeon/Makefile.am  |  2 ++
> >  src/gallium/drivers/radeonsi/Makefile.am|  1 +
> >  src/gallium/drivers/rbug/Makefile.am|  2 +-
> >  src/gallium/drivers/softpipe/Makefile.am|  2 +-
> >  src/gallium/drivers/svga/Makefile.am|  3 ++-
> >  src/gallium/drivers/swr/Makefile.am |  9 ++---
> >  src/gallium/drivers/trace/Makefile.am   |  3 ++-
> >  src/gallium/drivers/vc4/Makefile.am |  2 +-
> >  src/gallium/drivers/vc5/Makefile.am |  2 ++
> >  src/gallium/drivers/virgl/Makefile.am   |  2 ++
> >  src/gallium/state_trackers/clover/Makefile.am   |  2 +-
> >  src/gallium/state_trackers/dri/Makefile.am  |  2 +-
> >  src/gallium/state_trackers/glx/xlib/Makefile.am |  2 +-
> >  src/gallium/state_trackers/nine/Makefile.am |  2 +-
> >  src/gallium/state_trackers/omx_bellagio/Makefile.am |  2 ++
> >  src/gallium/state_trackers/osmesa/Makefile.am   |  2 +-
> >  src/gallium/state_trackers/va/Makefile.am   |  2 ++
> >  src/gallium/state_trackers/vdpau/Makefile.am|  2 ++
> >  src/gallium/state_trackers/xa/Makefile.am   |  2 +-
> >  src/gallium/state_trackers/xvmc/Makefile.am |  2 ++
> >  src/gallium/targets/d3dadapter9/Makefile.am |  2 +-
> >  src/gallium/targets/dri/Makefile.am |  1 +
> >  src/gallium/targets/libgl-xlib/Makefile.am  |  2 +-
> >  src/gallium/targets/omx-bellagio/Makefile.am|  2 +-
> >  src/gallium/targets/opencl/Makefile.am  |  2 +-
> >  src/gallium/targets/osmesa/Makefile.am  |  3 ++-
> >  src/gallium/targets/pipe-loader/Makefile.am |  2 +-
> >  src/gallium/targets/va/Makefile.am  |  2 +-
> >  src/gallium/targets/vdpau/Makefile.am   |  3 ++-
> >  src/gallium/targets/xa/Makefile.am  |  2 +-
> >  src/gallium/targets/xvmc/Makefile.am|  2 +-
> >  src/gallium/winsys/amdgpu/drm/Makefile.am   |  2 ++
> >  src/gallium/winsys/etnaviv/drm/Makefile.am  |  2 ++
> >  src/gallium/winsys/freedreno/drm/Makefile.am|  2 ++
> >  src/gallium/winsys/i915/drm/Makefile.am |  2 ++
> >  src/gallium/winsys/imx/drm/Makefile.am  |  2 ++
> >  src/gallium/winsys/nouveau/drm/Makefile.am  |  2 ++
> >  src/gallium/winsys/pl111/drm/Makefile.am|  2 ++
> >  src/gallium/winsys/radeon/drm/Makefile.am   |  2 ++
> >  src/gallium/winsys/svga/drm/Makefile.am |  2 +-
> >  src/gallium/winsys/sw/dri/Makefile.am   |  2 +-
> >  src/gallium/winsys/sw/kms-dri/Makefile.am   |  2 ++
> >  src/gallium/winsys/sw/null/Makefile.am  |  2 +-
> >  src/gallium/winsys/sw/wrapper/Makefile.am   |  2 +-
> >  src/gallium/winsys/sw/xlib/Makefile.am  |  2 +-
> >  src/gallium/winsys/vc4/drm/Makefile.am  |  2 ++
> >  src/gallium/winsys/vc5/drm/Makefile.am  |  2 ++
> >

[Mesa-dev] [PATCH] ac/nir: Fix TCS output LDS offsets.

2018-01-18 Thread Bas Nieuwenhuizen

When a channel was not set we also did not increase the LDS address,
while that obviously should happen.

The output loading code was inadvertently fixed which resulted in a
mismatch causing the SaschaWillems tessellation demo to result
in corrupt rendering.

Fixes: 7898eb9a60 "ac: rework load_tcs_{inputs,outputs}"
---
 src/amd/common/ac_nir_to_llvm.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index cd400376a0..0bebfea972 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2968,16 +2968,17 @@ store_tcs_output(struct ac_shader_abi *abi,
continue;
LLVMValueRef value = ac_llvm_extract_elem(>ac, src, chan - 
component);
 
-   if (store_lds || is_tess_factor)
-   ac_lds_store(>ac, dw_addr, value);
+   if (store_lds || is_tess_factor) {
+   LLVMValueRef dw_addr_chan =
+   LLVMBuildAdd(ctx->builder, dw_addr,
+  
LLVMConstInt(ctx->ac.i32, chan, false), "");
+   ac_lds_store(>ac, dw_addr_chan, value);
+   }
 
if (!is_tess_factor && writemask != 0xF)
ac_build_buffer_store_dword(>ac, 
ctx->hs_ring_tess_offchip, value, 1,
buf_addr, ctx->oc_lds,
4 * (base + chan), 1, 0, 
true, false);
-
-   dw_addr = LLVMBuildAdd(ctx->builder, dw_addr,
-  ctx->ac.i32_1, "");
}
 
if (writemask == 0xF) {
-- 
2.15.1

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

Re: [Mesa-dev] [PATCH] autotools: include meson build files in tarball

On Thursday, 2018-01-18 17:09:04 +, Dylan Baker wrote:
> This adds the meson.build, meson_options.txt, and a few scripts that are
> used exclusively by the meson build.
> 
> Signed-off-by: Dylan Baker 

I could've sworn we already some $(shell find -name meson.build) thing
for this?

One note below (in src/gallium/drivers/swr/Makefile.am), but with that
fixed:
Acked-by: Eric Engestrom 

> ---
>  Makefile.am |  7 ++-
>  src/Makefile.am |  2 +-
>  src/amd/Makefile.am |  9 -
>  src/amd/vulkan/Makefile.am  |  3 ++-
>  src/broadcom/Makefile.am|  7 ++-
>  src/compiler/Makefile.am|  9 -
>  src/egl/Makefile.am |  3 ++-
>  src/egl/wayland/wayland-drm/Makefile.am |  2 +-
>  src/egl/wayland/wayland-egl/Makefile.am |  2 +-
>  src/gallium/Makefile.am |  3 ++-
>  src/gallium/auxiliary/Makefile.am   |  3 ++-
>  src/gallium/auxiliary/pipe-loader/Makefile.am   |  2 +-
>  src/gallium/drivers/ddebug/Makefile.am  |  2 ++
>  src/gallium/drivers/etnaviv/Makefile.am |  2 ++
>  src/gallium/drivers/freedreno/Makefile.am   |  2 ++
>  src/gallium/drivers/i915/Makefile.am|  2 +-
>  src/gallium/drivers/llvmpipe/Makefile.am|  2 +-
>  src/gallium/drivers/noop/Makefile.am|  2 +-
>  src/gallium/drivers/nouveau/Makefile.am |  2 +-
>  src/gallium/drivers/r300/Makefile.am|  3 ++-
>  src/gallium/drivers/r600/Makefile.am|  3 ++-
>  src/gallium/drivers/radeon/Makefile.am  |  2 ++
>  src/gallium/drivers/radeonsi/Makefile.am|  1 +
>  src/gallium/drivers/rbug/Makefile.am|  2 +-
>  src/gallium/drivers/softpipe/Makefile.am|  2 +-
>  src/gallium/drivers/svga/Makefile.am|  3 ++-
>  src/gallium/drivers/swr/Makefile.am |  9 ++---
>  src/gallium/drivers/trace/Makefile.am   |  3 ++-
>  src/gallium/drivers/vc4/Makefile.am |  2 +-
>  src/gallium/drivers/vc5/Makefile.am |  2 ++
>  src/gallium/drivers/virgl/Makefile.am   |  2 ++
>  src/gallium/state_trackers/clover/Makefile.am   |  2 +-
>  src/gallium/state_trackers/dri/Makefile.am  |  2 +-
>  src/gallium/state_trackers/glx/xlib/Makefile.am |  2 +-
>  src/gallium/state_trackers/nine/Makefile.am |  2 +-
>  src/gallium/state_trackers/omx_bellagio/Makefile.am |  2 ++
>  src/gallium/state_trackers/osmesa/Makefile.am   |  2 +-
>  src/gallium/state_trackers/va/Makefile.am   |  2 ++
>  src/gallium/state_trackers/vdpau/Makefile.am|  2 ++
>  src/gallium/state_trackers/xa/Makefile.am   |  2 +-
>  src/gallium/state_trackers/xvmc/Makefile.am |  2 ++
>  src/gallium/targets/d3dadapter9/Makefile.am |  2 +-
>  src/gallium/targets/dri/Makefile.am |  1 +
>  src/gallium/targets/libgl-xlib/Makefile.am  |  2 +-
>  src/gallium/targets/omx-bellagio/Makefile.am|  2 +-
>  src/gallium/targets/opencl/Makefile.am  |  2 +-
>  src/gallium/targets/osmesa/Makefile.am  |  3 ++-
>  src/gallium/targets/pipe-loader/Makefile.am |  2 +-
>  src/gallium/targets/va/Makefile.am  |  2 +-
>  src/gallium/targets/vdpau/Makefile.am   |  3 ++-
>  src/gallium/targets/xa/Makefile.am  |  2 +-
>  src/gallium/targets/xvmc/Makefile.am|  2 +-
>  src/gallium/winsys/amdgpu/drm/Makefile.am   |  2 ++
>  src/gallium/winsys/etnaviv/drm/Makefile.am  |  2 ++
>  src/gallium/winsys/freedreno/drm/Makefile.am|  2 ++
>  src/gallium/winsys/i915/drm/Makefile.am |  2 ++
>  src/gallium/winsys/imx/drm/Makefile.am  |  2 ++
>  src/gallium/winsys/nouveau/drm/Makefile.am  |  2 ++
>  src/gallium/winsys/pl111/drm/Makefile.am|  2 ++
>  src/gallium/winsys/radeon/drm/Makefile.am   |  2 ++
>  src/gallium/winsys/svga/drm/Makefile.am |  2 +-
>  src/gallium/winsys/sw/dri/Makefile.am   |  2 +-
>  src/gallium/winsys/sw/kms-dri/Makefile.am   |  2 ++
>  src/gallium/winsys/sw/null/Makefile.am  |  2 +-
>  src/gallium/winsys/sw/wrapper/Makefile.am   |  2 +-
>  src/gallium/winsys/sw/xlib/Makefile.am  |  2 +-
>  src/gallium/winsys/vc4/drm/Makefile.am  |  2 ++
>  src/gallium/winsys/vc5/drm/Makefile.am  |  2 ++
>  src/gallium/winsys/virgl/drm/Makefile.am|  2 ++
>  src/gallium/winsys/virgl/vtest/Makefile.am  |  2 ++
>  src/gbm/Makefile.am |  2 +-
>  src/glx/Makefile.am

[Mesa-dev] [PATCH 0/5] docs: add missing final release of series notes

Just a series to add the missing "final release" note for 17.1.10 and
17.2.8, as commented at:
https://lists.freedesktop.org/archives/mesa-dev/2018-January/182322.html

Additionally, update the releasing documentation to make explicit
mention of the need to mention the final release of a series.

Finally, I'm throwing in a nitpick and a small typo fix.

Andres Gomez (5):
  docs: add final release note for 17.1.10
  docs: add final release note for 17.2.8
  docs: add a notice whenever a release is the final in a series
  docs: move untar line in basic testing instructions for coherence
  docs: correct a typo in releasing instructions

 docs/index.html |  8 
 docs/releasing.html | 21 ++---
 2 files changed, 26 insertions(+), 3 deletions(-)

-- 
2.15.1

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

[Mesa-dev] [PATCH 1/5] docs: add final release note for 17.1.10

Cc: Emil Velikov 
Cc: Juan A. Suarez Romero 
Signed-off-by: Andres Gomez 
---
 docs/index.html | 4 
 1 file changed, 4 insertions(+)

diff --git a/docs/index.html b/docs/index.html
index 75a39d797d4..95a07150644 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -81,6 +81,10 @@ This is a bug-fix release.
 
 Mesa 17.1.10 is released.
 This is a bug-fix release.
+
+NOTE: It is anticipated that 17.1.10 will be the final release in the
+17.1 series. Users of 17.1 are encouraged to migrate to the 17.2
+series in order to obtain future fixes.
 
 
 September 17, 2017
-- 
2.15.1

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

Re: [Mesa-dev] [PATCH 00/14] BSD portability (Meson, ANV, RADV, VC4/5, SWR)

Quoting Emil Velikov (2018-01-18 10:57:02)
> On 18 January 2018 at 18:29, Greg V  wrote:
> >
> > On 01/18/2018 21:18, Emil Velikov wrote:
> >>
> >> Hi Greg,
> >>
> >> On 31 December 2017 at 16:55, Greg V  wrote:
> >>>
> >>> Hello everyone and happy new year! :)
> >>>
> >>> This set of patches makes the Meson build work on FreeBSD, including
> >>> RADV, ANV, wayland-egl, VAAPI, VDPAU.
> >>
> >> Huge thanks for beating these into shape and sending them.
> >>
> >> Based on the sysconf patch it seems like the series isn't based again
> >> master.
> >> Can you please rebase?
> >>
> >> I've made a few suggestions about moving stuff into helpers, although
> >> those are not a requirement.
> >> We can merge the current ones, as long as you promise to address fix
> >> them up as follow-up ;-)
> >
> > I'm working on the helpers, yeah.
> >
> > I've rebased and updated the meson patches, sent as v2.
> > I'll send everything else as v2 with the helpers stuff.
> >
> > Sorry if I'm doing something wrong with series and stuff, I'm still a bit
> > confused with this patch emailing thing, I'm used to GitHub and similar
> > services :)
> >
> No worries - every project is different ;-)
> 
> The first google hit for "mesa submitting patches" is the correct one [1].
> Although in practise you've handled everything very well, already.
> 
> [1] https://www.mesa3d.org/submittingpatches.html
> 
> >> It would be amazing if FreeBSD used the ETIME fallback in their
> >> toolchain. Otherwise things break quite often, as you can see.
> >> That's more of a dream of mine, so don't read too much into it.
> >
> > Did you get Dylan's reply about defining ETIME in meson/autotools?
> 
> AFAICT the approach is semi-magic, hence my day-dreaming on the topic.
> I'll try to cook up some magic, but it will be very fragile.
> 
> -Emil

I'm willing to defer to you on this, if you think that checking headers for
ETIME is too fragile then we can leave it (you definitely have more experience
in these things). I'm just concerned it's going to turn into an endless
whack-a-mole game.


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 2/2] st/vdpau: release held lock in error path

2018-01-18 Thread Grazvydas Ignotas

Anyone cares about vdpau?

Gražvydas

On Tue, Jan 16, 2018 at 12:03 AM, Grazvydas Ignotas  wrote:
> Signed-off-by: Grazvydas Ignotas 
> ---
>  src/gallium/state_trackers/vdpau/surface.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/vdpau/surface.c 
> b/src/gallium/state_trackers/vdpau/surface.c
> index c678eb7..012d303 100644
> --- a/src/gallium/state_trackers/vdpau/surface.c
> +++ b/src/gallium/state_trackers/vdpau/surface.c
> @@ -367,12 +367,14 @@ vlVdpVideoSurfacePutBitsYCbCr(VdpVideoSurface surface,
>
> if (pformat != p_surf->video_buffer->buffer_format) {
>if (pformat == PIPE_FORMAT_YV12 &&
>p_surf->video_buffer->buffer_format == PIPE_FORMAT_NV12)
>   conversion = CONVERSION_YV12_TO_NV12;
> -  else
> +  else {
> + mtx_unlock(_surf->device->mutex);
>   return VDP_STATUS_NO_IMPLEMENTATION;
> +  }
> }
>
> sampler_views = 
> p_surf->video_buffer->get_sampler_view_planes(p_surf->video_buffer);
> if (!sampler_views) {
>mtx_unlock(_surf->device->mutex);
> --
> 2.7.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/10] nouveau: Remove no-op nvgl_logicop_func function

2018-01-18 Thread Francisco Jerez

Ian Romanick  writes:

> From: Ian Romanick 
>
> The values that this function returned were always the values passed
> in.  The only thing that happened was either an assertion or undefined
> results when an unknown value was passed in.  This doesn't seem that
> useful.  Most of nouveau_gldefs.h could be removed in this manner.
>
> Signed-off-by: Ian Romanick 

Reviewed-by: Francisco Jerez 

> ---
>  src/mesa/drivers/dri/nouveau/nouveau_gldefs.h| 41 
> 
>  src/mesa/drivers/dri/nouveau/nv10_state_raster.c |  2 +-
>  src/mesa/drivers/dri/nouveau/nv20_state_raster.c |  2 +-
>  3 files changed, 2 insertions(+), 43 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_gldefs.h 
> b/src/mesa/drivers/dri/nouveau/nouveau_gldefs.h
> index 7df04c1..11c3dbd 100644
> --- a/src/mesa/drivers/dri/nouveau/nouveau_gldefs.h
> +++ b/src/mesa/drivers/dri/nouveau/nouveau_gldefs.h
> @@ -86,47 +86,6 @@ nvgl_blend_eqn(unsigned eqn)
>  }
>  
>  static inline unsigned
> -nvgl_logicop_func(unsigned func)
> -{
> - switch (func) {
> - case GL_CLEAR:
> - return 0x1500;
> - case GL_NOR:
> - return 0x1508;
> - case GL_AND_INVERTED:
> - return 0x1504;
> - case GL_COPY_INVERTED:
> - return 0x150c;
> - case GL_AND_REVERSE:
> - return 0x1502;
> - case GL_INVERT:
> - return 0x150a;
> - case GL_XOR:
> - return 0x1506;
> - case GL_NAND:
> - return 0x150e;
> - case GL_AND:
> - return 0x1501;
> - case GL_EQUIV:
> - return 0x1509;
> - case GL_NOOP:
> - return 0x1505;
> - case GL_OR_INVERTED:
> - return 0x150d;
> - case GL_COPY:
> - return 0x1503;
> - case GL_OR_REVERSE:
> - return 0x150b;
> - case GL_OR:
> - return 0x1507;
> - case GL_SET:
> - return 0x150f;
> - default:
> - assert(0);
> - }
> -}
> -
> -static inline unsigned
>  nvgl_comparison_op(unsigned op)
>  {
>   switch (op) {
> diff --git a/src/mesa/drivers/dri/nouveau/nv10_state_raster.c 
> b/src/mesa/drivers/dri/nouveau/nv10_state_raster.c
> index d537f7b..047f539 100644
> --- a/src/mesa/drivers/dri/nouveau/nv10_state_raster.c
> +++ b/src/mesa/drivers/dri/nouveau/nv10_state_raster.c
> @@ -126,7 +126,7 @@ nv10_emit_logic_opcode(struct gl_context *ctx, int emit)
>  
>   BEGIN_NV04(push, NV11_3D(COLOR_LOGIC_OP_ENABLE), 2);
>   PUSH_DATAb(push, ctx->Color.ColorLogicOpEnabled);
> - PUSH_DATA (push, nvgl_logicop_func(ctx->Color.LogicOp));
> + PUSH_DATA (push, ctx->Color.LogicOp);
>  }
>  
>  void
> diff --git a/src/mesa/drivers/dri/nouveau/nv20_state_raster.c 
> b/src/mesa/drivers/dri/nouveau/nv20_state_raster.c
> index 4856053..c24c5bb 100644
> --- a/src/mesa/drivers/dri/nouveau/nv20_state_raster.c
> +++ b/src/mesa/drivers/dri/nouveau/nv20_state_raster.c
> @@ -38,5 +38,5 @@ nv20_emit_logic_opcode(struct gl_context *ctx, int emit)
>  
>   BEGIN_NV04(push, NV20_3D(COLOR_LOGIC_OP_ENABLE), 2);
>   PUSH_DATAb(push, ctx->Color.ColorLogicOpEnabled);
> - PUSH_DATA (push, nvgl_logicop_func(ctx->Color.LogicOp));
> + PUSH_DATA (push, ctx->Color.LogicOp);
>  }
> -- 
> 2.9.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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] ac/nir: account for view index in the user sgpr allocation.

2018-01-18 Thread Samuel Pitoiset


Reviewed-by: Samuel Pitoiset 

On 01/18/2018 03:37 AM, Dave Airlie wrote:

From: Dave Airlie 

The view index user sgpr wasn't being accounted for properly,
this refactors out the code to decide if it's required and then
uses that info to account for it.

Fixes: 180c1b924e (ac/nir: Add shader support for multiviews.)
Signed-off-by: Dave Airlie 
---
  src/amd/common/ac_nir_to_llvm.c | 42 +
  1 file changed, 34 insertions(+), 8 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index e07330ca5c8..e31d771025b 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -543,8 +543,31 @@ struct user_sgpr_info {
bool indirect_all_descriptor_sets;
  };
  
+static bool needs_view_index_sgpr(struct nir_to_llvm_context *ctx,

+ gl_shader_stage stage)
+{
+   switch (stage) {
+   case MESA_SHADER_VERTEX:
+   if (ctx->shader_info->info.needs_multiview_view_index ||
+   (!ctx->options->key.vs.as_es && !ctx->options->key.vs.as_ls && 
ctx->options->key.has_multiview_view_index))
+   return true;
+   break;
+   case MESA_SHADER_TESS_EVAL:
+   if (ctx->shader_info->info.needs_multiview_view_index || 
(!ctx->options->key.tes.as_es && ctx->options->key.has_multiview_view_index))
+   return true;
+   case MESA_SHADER_GEOMETRY:
+   case MESA_SHADER_TESS_CTRL:
+   if (ctx->shader_info->info.needs_multiview_view_index)
+   return true;
+   default:
+   break;
+   }
+   return false;
+}
+
  static void allocate_user_sgprs(struct nir_to_llvm_context *ctx,
gl_shader_stage stage,
+   bool needs_view_index,
struct user_sgpr_info *user_sgpr_info)
  {
memset(user_sgpr_info, 0, sizeof(struct user_sgpr_info));
@@ -600,6 +623,9 @@ static void allocate_user_sgprs(struct nir_to_llvm_context 
*ctx,
break;
}
  
+	if (needs_view_index)

+   user_sgpr_info->sgpr_count++;
+
if (ctx->shader_info->info.loads_push_constants)
user_sgpr_info->sgpr_count += 2;
  
@@ -771,8 +797,8 @@ static void create_function(struct nir_to_llvm_context *ctx,

struct user_sgpr_info user_sgpr_info;
struct arg_info args = {};
LLVMValueRef desc_sets;
-
-   allocate_user_sgprs(ctx, stage, _sgpr_info);
+   bool needs_view_index = needs_view_index_sgpr(ctx, stage);
+   allocate_user_sgprs(ctx, stage, needs_view_index, _sgpr_info);
  
  	if (user_sgpr_info.need_ring_offsets && !ctx->options->supports_spill) {

add_arg(, ARG_SGPR, const_array(ctx->ac.v4i32, 16),
@@ -810,7 +836,7 @@ static void create_function(struct nir_to_llvm_context *ctx,
declare_vs_specific_input_sgprs(ctx, stage, has_previous_stage,
previous_stage, );
  
-		if (ctx->shader_info->info.needs_multiview_view_index || (!ctx->options->key.vs.as_es && !ctx->options->key.vs.as_ls && ctx->options->key.has_multiview_view_index))

+   if (needs_view_index)
add_arg(, ARG_SGPR, ctx->ac.i32, >view_index);
if (ctx->options->key.vs.as_es)
add_arg(, ARG_SGPR, ctx->ac.i32,
@@ -854,7 +880,7 @@ static void create_function(struct nir_to_llvm_context *ctx,
>tcs_out_layout);
add_arg(, ARG_SGPR, ctx->ac.i32,
>tcs_in_layout);
-   if (ctx->shader_info->info.needs_multiview_view_index)
+   if (needs_view_index)
add_arg(, ARG_SGPR, ctx->ac.i32,
>view_index);
  
@@ -879,7 +905,7 @@ static void create_function(struct nir_to_llvm_context *ctx,

>tcs_out_layout);
add_arg(, ARG_SGPR, ctx->ac.i32,
>tcs_in_layout);
-   if (ctx->shader_info->info.needs_multiview_view_index)
+   if (needs_view_index)
add_arg(, ARG_SGPR, ctx->ac.i32,
>view_index);
  
@@ -898,7 +924,7 @@ static void create_function(struct nir_to_llvm_context *ctx,

   , _sets);
  
  		add_arg(, ARG_SGPR, ctx->ac.i32, >tcs_offchip_layout);

-   if (ctx->shader_info->info.needs_multiview_view_index || 
(!ctx->options->key.tes.as_es && ctx->options->key.has_multiview_view_index))
+   if (needs_view_index)
add_arg(, ARG_SGPR, ctx->ac.i32, >view_index);
  
  		if

Re: [Mesa-dev] [PATCH v2 0/4] Fix unm_sampes and some warnings

2018-01-18 Thread Ian Romanick

Patches 2, 3, and 4 are

Reviewed-by: Ian Romanick 

I send out a lot of patches that fix warnings.  I like to copy-and-paste
the warnings that are eliminated into the commit message.  It's not
required, but I feel like it helps.  The only trick is to make sure the
console you copy from is 80-columns. :)

On 01/18/2018 12:57 AM, Gert Wollny wrote:
> with the pointers that Emil gave me I prepared a second version of 
> the series:  
> 
> Changes in v2: 
> 
> Patch 1: 
> * split the first patch into gallium and mesa part (as suggested) 
> * also correct the according parameter of st_new_renderbuffer_fb 
> Patch 2 & 3 (now 3 & 4) 
> * instead of annotating the unused parameter I remove it (as suggested)
>   since these patches now touch more files I kept them separate, 
> 
> Many thanks, 
> Gert
> --
> 
> Gert Wollny (4):
>   gallium: Make (num_)samples an unsigned int (part 1)
>   mesa: Make numSamples an unsigned int (part 2)
>   mesa/program/prog_execute.c: Silence -Wunused-param
>   mesa/program: Fix -Wunused-param warning
> 
>  src/gallium/include/state_tracker/st_api.h| 2 +-
>  src/gallium/state_trackers/glx/xlib/glx_api.c | 8 ++--
>  src/mesa/main/context.c   | 4 ++--
>  src/mesa/main/context.h   | 4 ++--
>  src/mesa/main/mtypes.h| 2 +-
>  src/mesa/main/multisample.c   | 2 +-
>  src/mesa/program/arbprogparse.c   | 2 +-
>  src/mesa/program/ir_to_mesa.cpp   | 2 +-
>  src/mesa/program/prog_execute.c   | 9 +++--
>  src/mesa/program/prog_optimize.c  | 3 +--
>  src/mesa/program/prog_optimize.h  | 3 +--
>  src/mesa/state_tracker/st_cb_fbo.c| 2 +-
>  src/mesa/state_tracker/st_cb_fbo.h| 2 +-
>  13 files changed, 22 insertions(+), 23 deletions(-)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: ensure that xmlpool_options.h is generated for targets that need it

Dylan Baker  writes:

> Currently a couple of gallium targets race with xmlpool_options.h being
> generated, don't do that.

Reviewed-by: Eric Anholt 


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] radv: Use correct bindings for inputRate in key generation.

2018-01-18 Thread Samuel Pitoiset


Reviewed-by: Samuel Pitoiset 

On 01/18/2018 03:55 PM, Bas Nieuwenhuizen wrote:

The bindings also have an index field.

Fixes: 49d035122e "radv: Add single pipeline cache key."
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104677
---
  src/amd/vulkan/radv_pipeline.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index c3c17af850..5f824796fe 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1726,10 +1726,16 @@ radv_generate_graphics_pipeline_key(struct 
radv_pipeline *pipeline,
  
  	key.has_multiview_view_index = has_view_index;
  
+	uint32_t binding_input_rate = 0;

+   for (unsigned i = 0; i < input_state->vertexBindingDescriptionCount; 
++i) {
+   if (input_state->pVertexBindingDescriptions[i].inputRate)
+   binding_input_rate |= 1u << 
input_state->pVertexBindingDescriptions[i].binding;
+   }
+
for (unsigned i = 0; i < input_state->vertexAttributeDescriptionCount; 
++i) {
unsigned binding;
binding = input_state->pVertexAttributeDescriptions[i].binding;
-   if (input_state->pVertexBindingDescriptions[binding].inputRate)
+   if (binding_input_rate & (1u << binding))
key.instance_rate_inputs |= 1u << 
input_state->pVertexAttributeDescriptions[i].location;
}
  


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

Re: [Mesa-dev] [PATCH 12/14] swr: build on FreeBSD/DragonFlyBSD

Hi Emil, Greg,



> > (Needs CPU topology detection to actually work)
>

Does it?  Or does it just need the topology detection for the current
"default" behavior for thread placement?  The default behavior for swr is
to use the cpu topology info to place one thread per core and pin it to
that core.  However, if you instead set the env var
KNOB_MAX_WORKER_THREADS=N, it will use a thread pool of N threads with no
regard to CPU topology (this is actually the mode I typically use it in
actually for HPC environments where we run multiple processes per node).


IMHO it might be better to drop the patch, until its actually working.
> There's little point in building it if one cannot use it.
>

I would suggest instead of going through the hoops to determine topology,
simply disable or ignore the topology settings on FreeBSD and just use the
floating thread-pool configuration exclusively.


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

Re: [Mesa-dev] [PATCH 2/2] radv: Replace an assert with unreachable.

2018-01-18 Thread Samuel Pitoiset


Series is:

Reviewed-by: Samuel Pitoiset 

On 01/17/2018 11:25 PM, Bas Nieuwenhuizen wrote:

Otherwise we get uninitialized variable warnings for es_vgpr_comp_cnt.
---
  src/amd/vulkan/radv_shader.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 9819a522d7..3bcaac168a 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -424,7 +424,7 @@ radv_fill_shader_variant(struct radv_device *device,
} else if (es_type == MESA_SHADER_TESS_EVAL) {
es_vgpr_comp_cnt = 3;
} else {
-   assert(!"invalid shader ES type");
+   unreachable("invalid shader ES type");
}
  
  		/* If offsets 4, 5 are used, GS_VGPR_COMP_CNT is ignored and



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

Re: [Mesa-dev] [PATCH] r600: enable ARB_enhanced_layouts

On 19 January 2018 at 06:09, Roland Scheidegger  wrote:
> Am 18.01.2018 um 20:35 schrieb Dave Airlie:
>> On 19 January 2018 at 04:30, Roland Scheidegger  wrote:
>>> Looks good to me, seems like you're nearly done with gl 4.5 ;-)
>>
>> Thanks,
>>
>> I've mostly written qbo support I think (the 64-bit int divide is the
>> biggest thing left),
>>
>> However we'll have to keep restricted to GL4.3 until we can show some 
>> attempt at
>> passing conformance, my first attempt at that crashed a lot, so we
>> have a bit to go :-)
>
> My card is 3.3 only anyway, so no need to hurry :-).

softfp64 is trickling along. I just knocked over min/max support today.

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

Re: [Mesa-dev] [PATCH 1/2] swr: (autoconf) allow a single swr architecture to be builtin

2018-01-18 Thread Cherniak, Bruce

Thanks Chuck!
Reviewed-by: Bruce Cherniak  

> On Jan 18, 2018, at 1:57 PM, Chuck Atkins  wrote:
> 
> Part 1 of 2 (part 1 is autoconf changes, part 2 is C++ changes)
> 
> When only a single SWR architecture is being used, this allows that
> architecture to be builtin rather than as a separate libswrARCH.so that
> gets loaded via dlopen.  Since there are now several different code
> paths for each detected CPU architecture, the log output is also
> adjusted to convey where the backend is getting loaded from.
> 
> This allows SWR to be used for static mesa builds which are still
> important for large HPC environments where shared libraries can impose
> unacceptable application startup times as hundreds of thousands of copies
> of the libs are loaded from a shared parallel filesystem.
> 
> Based on an initial implementation by Tim Rowley.
> 
> v2: Fix comment placement pointed out by Bruce C.
> 
> Signed-off-by: Chuck Atkins 
> Reviewed-by: Bruce Cherniak 
> CC: Tim Rowley 
> ---
> configure.ac| 12 -
> src/gallium/drivers/swr/Makefile.am | 50 +
> 2 files changed, 50 insertions(+), 12 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index e236a3c54f..7c1fbe0ed1 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2640,6 +2640,11 @@ if test -n "$with_gallium_drivers"; then
>AC_MSG_ERROR([swr enabled but no swr architectures selected])
> fi
> 
> +# test if more than one swr arch configured
> +if test `echo $swr_archs | wc -w` -eq 1; then
> +HAVE_SWR_BUILTIN=yes
> +fi
> +
> HAVE_GALLIUM_SWR=yes
> ;;
> xvc4)
> @@ -2689,6 +2694,7 @@ AM_CONDITIONAL(HAVE_SWR_AVX, test "x$HAVE_SWR_AVX" = 
> xyes)
> AM_CONDITIONAL(HAVE_SWR_AVX2, test "x$HAVE_SWR_AVX2" = xyes)
> AM_CONDITIONAL(HAVE_SWR_KNL, test "x$HAVE_SWR_KNL" = xyes)
> AM_CONDITIONAL(HAVE_SWR_SKX, test "x$HAVE_SWR_SKX" = xyes)
> +AM_CONDITIONAL(HAVE_SWR_BUILTIN, test "x$HAVE_SWR_BUILTIN" = xyes)
> 
> dnl We need to validate some needed dependencies for renderonly drivers.
> 
> @@ -3153,7 +3159,11 @@ fi
> 
> echo ""
> if test "x$HAVE_GALLIUM_SWR" != x; then
> -echo "SWR archs:   $swr_archs"
> +if test "x$HAVE_SWR_BUILTIN" = xyes; then
> +echo "SWR archs:   $swr_archs (builtin)"
> +else
> +echo "SWR archs:   $swr_archs"
> +fi
> fi
> 
> dnl Libraries
> diff --git a/src/gallium/drivers/swr/Makefile.am 
> b/src/gallium/drivers/swr/Makefile.am
> index c995f1b84a..ace4e1d4e4 100644
> --- a/src/gallium/drivers/swr/Makefile.am
> +++ b/src/gallium/drivers/swr/Makefile.am
> @@ -26,13 +26,9 @@ AM_CXXFLAGS = $(GALLIUM_DRIVER_CFLAGS) $(CXX11_CXXFLAGS)
> 
> noinst_LTLIBRARIES = libmesaswr.la
> 
> -# gen_knobs.* included here to provide driver access to swr configuration
> libmesaswr_la_SOURCES = \
>   $(CXX_SOURCES) \
> - $(COMMON_CXX_SOURCES) \
>   $(JITTER_CXX_SOURCES) \
> - rasterizer/codegen/gen_knobs.cpp \
> - rasterizer/codegen/gen_knobs.h \
>   $(LOADER_SOURCES)
> 
> COMMON_CXXFLAGS = \
> @@ -243,8 +239,6 @@ COMMON_LDFLAGS = \
> lib_LTLIBRARIES =
> 
> if HAVE_SWR_AVX
> -lib_LTLIBRARIES += libswrAVX.la
> -
> libswrAVX_la_CXXFLAGS = \
>   $(PTHREAD_CFLAGS) \
>   $(SWR_AVX_CXXFLAGS) \
> @@ -262,7 +256,6 @@ libswrAVX_la_LDFLAGS = \
> endif
> 
> if HAVE_SWR_AVX2
> -lib_LTLIBRARIES += libswrAVX2.la
> libswrAVX2_la_CXXFLAGS = \
>   $(PTHREAD_CFLAGS) \
>   $(SWR_AVX2_CXXFLAGS) \
> @@ -280,8 +273,6 @@ libswrAVX2_la_LDFLAGS = \
> endif
> 
> if HAVE_SWR_KNL
> -lib_LTLIBRARIES += libswrKNL.la
> -
> libswrKNL_la_CXXFLAGS = \
>   $(PTHREAD_CFLAGS) \
>   $(SWR_KNL_CXXFLAGS) \
> @@ -299,8 +290,6 @@ libswrKNL_la_LDFLAGS = \
> endif
> 
> if HAVE_SWR_SKX
> -lib_LTLIBRARIES += libswrSKX.la
> -
> libswrSKX_la_CXXFLAGS = \
>   $(PTHREAD_CFLAGS) \
>   $(SWR_SKX_CXXFLAGS) \
> @@ -317,6 +306,45 @@ libswrSKX_la_LDFLAGS = \
>   $(COMMON_LDFLAGS)
> endif
> 
> +if HAVE_SWR_BUILTIN
> +libmesaswr_la_CXXFLAGS += -DHAVE_SWR_BUILTIN
> +libmesaswr_la_LIBADD =
> +if HAVE_SWR_AVX
> +noinst_LTLIBRARIES += libswrAVX.la
> +libmesaswr_la_LIBADD += libswrAVX.la
> +endif
> +if HAVE_SWR_AVX2
> +noinst_LTLIBRARIES += libswrAVX2.la
> +libmesaswr_la_LIBADD += libswrAVX2.la
> +endif
> +if HAVE_SWR_KNL
> +noinst_LTLIBRARIES += libswrKNL.la
> +libmesaswr_la_LIBADD += libswrKNL.la
> +endif
> +if HAVE_SWR_SKX
> +noinst_LTLIBRARIES += libswrSKX.la
> +libmesaswr_la_LIBADD += libswrSKX.la
> +endif
> +else # !HAVE_SWR_BUILTIN
> +# gen_knobs.* included here to provide driver access to swr configuration
> +libmesaswr_la_SOURCES += \
> +   $(COMMON_CXX_SOURCES) \
> +   rasterizer/codegen/gen_knobs.cpp \
> +   rasterizer/codegen/gen_knobs.h
> +if HAVE_SWR_AVX
>

Re: [Mesa-dev] [PATCH 2/2] swr: allow a single swr architecture to be builtin

2018-01-18 Thread Cherniak, Bruce


Thanks Chuck!
Reviewed-by: Bruce Cherniak 

> On Jan 18, 2018, at 1:57 PM, Chuck Atkins  wrote:
> 
> Part 2 of 2 (part 1 is autoconf changes, part 2 is C++ changes)
> 
> When only a single SWR architecture is being used, this allows that
> architecture to be builtin rather than as a separate libswrARCH.so that
> gets loaded via dlopen.  Since there are now several different code
> paths for each detected CPU architecture, the log output is also
> adjusted to convey where the backend is getting loaded from.
> 
> This allows SWR to be used for static mesa builds which are still
> important for large HPC environments where shared libraries can impose
> unacceptable application startup times as hundreds of thousands of copies
> of the libs are loaded from a shared parallel filesystem.
> 
> Based on an initial implementation by Tim Rowley.
> 
> v2: Refactor repetitive preprocessor checks to reduce code duplication
> v3: Formatting changes per Bruce C. Also delay screen creation until end
>to avoid leaks when failure conditions are hit.
> 
> Signed-off-by: Chuck Atkins 
> Reviewed-by: Bruce Cherniak 
> CC: Tim Rowley 
> ---
> src/gallium/drivers/swr/swr_loader.cpp | 84 --
> 1 file changed, 49 insertions(+), 35 deletions(-)
> 
> diff --git a/src/gallium/drivers/swr/swr_loader.cpp 
> b/src/gallium/drivers/swr/swr_loader.cpp
> index 9d6f918e34..7f28bdb536 100644
> --- a/src/gallium/drivers/swr/swr_loader.cpp
> +++ b/src/gallium/drivers/swr/swr_loader.cpp
> @@ -28,81 +28,95 @@
> 
> #include 
> 
> +// Helper function to resolve the backend filename based on architecture
> +inline void get_swr_arch_filename(const char arch[], char filename[])
> +{
> +#ifdef HAVE_SWR_BUILTIN
> +   strcpy(filename , "builtin");
> +#else
> +   sprintf(filename, "%sswr%s%s", UTIL_DL_PREFIX, arch, UTIL_DL_EXT);
> +#endif
> +}
> +
> struct pipe_screen *
> swr_create_screen(struct sw_winsys *winsys)
> {
>char filename[256] = { 0 };
> -   fprintf(stderr, "SWR detected ");
> -
> -   util_dl_library *pLibrary = nullptr;
> +   bool found = false;
> +   bool is_knl = false;
> +   PFNSwrGetInterface pfnSwrGetInterface = nullptr;
> 
>util_cpu_detect();
> 
> -   bool is_knl = false;
> -
> -   if (!strlen(filename) &&
> -   util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er) {
> -#if HAVE_SWR_KNL
> -  fprintf(stderr, "KNL ");
> -  sprintf(filename, "%s%s%s", UTIL_DL_PREFIX, "swrKNL", UTIL_DL_EXT);
> -  is_knl = true;
> +   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er) {
> +  fprintf(stderr, "SWR detected KNL instruction support ");
> +#ifndef HAVE_SWR_KNL
> +  fprintf(stderr, "(skipping not built).\n");
> #else
> -  fprintf(stderr, "KNL (not built) ");
> +  get_swr_arch_filename("KNL", filename);
> +  found = true;
> +  is_knl = true;
> #endif
>}
> 
> -   if (!strlen(filename) &&
> -   util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw) {
> -#if HAVE_SWR_SKX
> -  fprintf(stderr, "SKX ");
> -  sprintf(filename, "%s%s%s", UTIL_DL_PREFIX, "swrSKX", UTIL_DL_EXT);
> +   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw) {
> +  fprintf(stderr, "SWR detected SKX instruction support ");
> +#ifndef HAVE_SWR_SKX
> +  fprintf(stderr, "(skipping not built).\n");
> #else
> -  fprintf(stderr, "SKX (not built) ");
> +  get_swr_arch_filename("SKX", filename);
> +  found = true;
> #endif
>}
> 
> -   if (!strlen(filename) && util_cpu_caps.has_avx2) {
> -#if HAVE_SWR_AVX2
> -  fprintf(stderr, "AVX2 ");
> -  sprintf(filename, "%s%s%s", UTIL_DL_PREFIX, "swrAVX2", UTIL_DL_EXT);
> +   if (!found && util_cpu_caps.has_avx2) {
> +  fprintf(stderr, "SWR detected AVX2 instruction support ");
> +#ifndef HAVE_SWR_AVX2
> +  fprintf(stderr, "(skipping not built).\n");
> #else
> -  fprintf(stderr, "AVX2 (not built) ");
> +  get_swr_arch_filename("AVX2", filename);
> +  found = true;
> #endif
>}
> 
> -   if (!strlen(filename) && util_cpu_caps.has_avx) {
> -#if HAVE_SWR_AVX
> -  fprintf(stderr, "AVX ");
> -  sprintf(filename, "%s%s%s", UTIL_DL_PREFIX, "swrAVX", UTIL_DL_EXT);
> +   if (!found && util_cpu_caps.has_avx) {
> +  fprintf(stderr, "SWR detected AVX instruction support ");
> +#ifndef HAVE_SWR_AVX
> +  fprintf(stderr, "(skipping not built).\n");
> #else
> -  fprintf(stderr, "AVX (not built) ");
> +  get_swr_arch_filename("AVX", filename);
> +  found = true;
> #endif
>}
> 
> -   if (!strlen(filename)) {
> -  fprintf(stderr, "- no appropriate swr architecture library.  
> Aborting!\n");
> +   if (!found) {
> +  fprintf(stderr, "SWR could not detect a supported CPU 
> architecture.\n");
>   exit(-1);
> -   } else {
> -  fprintf(stderr, "\n");
>}
> 
> -   pLibrary = util_dl_open(filename);
>

Re: [Mesa-dev] [PATCH] r600: enable ARB_enhanced_layouts

Am 18.01.2018 um 20:35 schrieb Dave Airlie:
> On 19 January 2018 at 04:30, Roland Scheidegger  wrote:
>> Looks good to me, seems like you're nearly done with gl 4.5 ;-)
> 
> Thanks,
> 
> I've mostly written qbo support I think (the 64-bit int divide is the
> biggest thing left),
> 
> However we'll have to keep restricted to GL4.3 until we can show some attempt 
> at
> passing conformance, my first attempt at that crashed a lot, so we
> have a bit to go :-)

My card is 3.3 only anyway, so no need to hurry :-).

Roland

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

Re: [Mesa-dev] [PATCH 12/14] swr: build on FreeBSD/DragonFlyBSD

Quoting Emil Velikov (2018-01-18 10:50:05)
> On 18 January 2018 at 18:09, Greg V  wrote:
> > On 01/18/2018 21:01, Emil Velikov wrote:
> >>
> >> On 31 December 2017 at 16:55, Greg V  wrote:
> >>>
> >>> (Needs CPU topology detection to actually work)
> >>
> >> IMHO it might be better to drop the patch, until its actually working.
> >> There's little point in building it if one cannot use it.
> >>
> >> What do you think?
> >
> > Yeah, I guess I only mentioned that in the cover letter or somewhere — I
> > have written that code and tested swr.
> >
> > Problem is, the topology is exposed as an XML string, so I used TinyXML2 to
> > parse it.
> > But I couldn't even figure out how to add that dependency to autotools, and
> > meson doesn't build swr yet.
> > Also not sure if that dependency is acceptable for Mesa.
> > (I guess it's technically possible to use Expat, which is already a
> > dependency, but ugh nope.)
> 
> My bad - I should have thoroughly read the cover letter first.
> Expat would be amazing (long term), although in the short term
> TinyXML2 would do.
> 
> Handling autotools is trivial
> 
> configure.ac:
> // go to the if building SWR hunk
> PKG_CHECK_MODULES([symbolic_name], [tinyxml2 >= $min_required version]
> 
> Then use symbolic_name_CFLAGS and symbolic_name_LIBS in the
> appropriate places...
> Without seeing the patch cannot tell you where exactly, since SWR is a
> bit funky and produces five binaries.

We do build swr in meson now, something like:
dep_tinyxml2 = dependency('tinyxml2', version : '>= $min_required')

And then add it to the `dependencies :` argument in the relevant libraries. It
would be nice to use expat, since we basically always require that.

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


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

[Mesa-dev] [Bug 104214] Dota crashes when switching from game to desktop

2018-01-18 Thread bugzilla-daemon

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

--- Comment #55 from Juan A. Suarez  ---
Is this bug already fixed? With commit:

commit 897c54d522ab960a879b763a15e489f630c491ee
Author: Thomas Hellstrom 
Date:   Thu Jan 11 10:19:23 2018 +0100

loader/dri3: Avoid freeing renderbuffers in use

-- 
You are receiving this mail because:
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 1/2] swr: (autoconf) allow a single swr architecture to be builtin

Part 1 of 2 (part 1 is autoconf changes, part 2 is C++ changes)

When only a single SWR architecture is being used, this allows that
architecture to be builtin rather than as a separate libswrARCH.so that
gets loaded via dlopen.  Since there are now several different code
paths for each detected CPU architecture, the log output is also
adjusted to convey where the backend is getting loaded from.

This allows SWR to be used for static mesa builds which are still
important for large HPC environments where shared libraries can impose
unacceptable application startup times as hundreds of thousands of copies
of the libs are loaded from a shared parallel filesystem.

Based on an initial implementation by Tim Rowley.

v2: Fix comment placement pointed out by Bruce C.

Signed-off-by: Chuck Atkins 
Reviewed-by: Bruce Cherniak 
CC: Tim Rowley 
---
 configure.ac| 12 -
 src/gallium/drivers/swr/Makefile.am | 50 +
 2 files changed, 50 insertions(+), 12 deletions(-)

diff --git a/configure.ac b/configure.ac
index e236a3c54f..7c1fbe0ed1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2640,6 +2640,11 @@ if test -n "$with_gallium_drivers"; then
AC_MSG_ERROR([swr enabled but no swr architectures selected])
 fi
 
+# test if more than one swr arch configured
+if test `echo $swr_archs | wc -w` -eq 1; then
+HAVE_SWR_BUILTIN=yes
+fi
+
 HAVE_GALLIUM_SWR=yes
 ;;
 xvc4)
@@ -2689,6 +2694,7 @@ AM_CONDITIONAL(HAVE_SWR_AVX, test "x$HAVE_SWR_AVX" = xyes)
 AM_CONDITIONAL(HAVE_SWR_AVX2, test "x$HAVE_SWR_AVX2" = xyes)
 AM_CONDITIONAL(HAVE_SWR_KNL, test "x$HAVE_SWR_KNL" = xyes)
 AM_CONDITIONAL(HAVE_SWR_SKX, test "x$HAVE_SWR_SKX" = xyes)
+AM_CONDITIONAL(HAVE_SWR_BUILTIN, test "x$HAVE_SWR_BUILTIN" = xyes)
 
 dnl We need to validate some needed dependencies for renderonly drivers.
 
@@ -3153,7 +3159,11 @@ fi
 
 echo ""
 if test "x$HAVE_GALLIUM_SWR" != x; then
-echo "SWR archs:   $swr_archs"
+if test "x$HAVE_SWR_BUILTIN" = xyes; then
+echo "SWR archs:   $swr_archs (builtin)"
+else
+echo "SWR archs:   $swr_archs"
+fi
 fi
 
 dnl Libraries
diff --git a/src/gallium/drivers/swr/Makefile.am 
b/src/gallium/drivers/swr/Makefile.am
index c995f1b84a..ace4e1d4e4 100644
--- a/src/gallium/drivers/swr/Makefile.am
+++ b/src/gallium/drivers/swr/Makefile.am
@@ -26,13 +26,9 @@ AM_CXXFLAGS = $(GALLIUM_DRIVER_CFLAGS) $(CXX11_CXXFLAGS)
 
 noinst_LTLIBRARIES = libmesaswr.la
 
-# gen_knobs.* included here to provide driver access to swr configuration
 libmesaswr_la_SOURCES = \
$(CXX_SOURCES) \
-   $(COMMON_CXX_SOURCES) \
$(JITTER_CXX_SOURCES) \
-   rasterizer/codegen/gen_knobs.cpp \
-   rasterizer/codegen/gen_knobs.h \
$(LOADER_SOURCES)
 
 COMMON_CXXFLAGS = \
@@ -243,8 +239,6 @@ COMMON_LDFLAGS = \
 lib_LTLIBRARIES =
 
 if HAVE_SWR_AVX
-lib_LTLIBRARIES += libswrAVX.la
-
 libswrAVX_la_CXXFLAGS = \
$(PTHREAD_CFLAGS) \
$(SWR_AVX_CXXFLAGS) \
@@ -262,7 +256,6 @@ libswrAVX_la_LDFLAGS = \
 endif
 
 if HAVE_SWR_AVX2
-lib_LTLIBRARIES += libswrAVX2.la
 libswrAVX2_la_CXXFLAGS = \
$(PTHREAD_CFLAGS) \
$(SWR_AVX2_CXXFLAGS) \
@@ -280,8 +273,6 @@ libswrAVX2_la_LDFLAGS = \
 endif
 
 if HAVE_SWR_KNL
-lib_LTLIBRARIES += libswrKNL.la
-
 libswrKNL_la_CXXFLAGS = \
$(PTHREAD_CFLAGS) \
$(SWR_KNL_CXXFLAGS) \
@@ -299,8 +290,6 @@ libswrKNL_la_LDFLAGS = \
 endif
 
 if HAVE_SWR_SKX
-lib_LTLIBRARIES += libswrSKX.la
-
 libswrSKX_la_CXXFLAGS = \
$(PTHREAD_CFLAGS) \
$(SWR_SKX_CXXFLAGS) \
@@ -317,6 +306,45 @@ libswrSKX_la_LDFLAGS = \
$(COMMON_LDFLAGS)
 endif
 
+if HAVE_SWR_BUILTIN
+libmesaswr_la_CXXFLAGS += -DHAVE_SWR_BUILTIN
+libmesaswr_la_LIBADD =
+if HAVE_SWR_AVX
+noinst_LTLIBRARIES += libswrAVX.la
+libmesaswr_la_LIBADD += libswrAVX.la
+endif
+if HAVE_SWR_AVX2
+noinst_LTLIBRARIES += libswrAVX2.la
+libmesaswr_la_LIBADD += libswrAVX2.la
+endif
+if HAVE_SWR_KNL
+noinst_LTLIBRARIES += libswrKNL.la
+libmesaswr_la_LIBADD += libswrKNL.la
+endif
+if HAVE_SWR_SKX
+noinst_LTLIBRARIES += libswrSKX.la
+libmesaswr_la_LIBADD += libswrSKX.la
+endif
+else # !HAVE_SWR_BUILTIN
+# gen_knobs.* included here to provide driver access to swr configuration
+libmesaswr_la_SOURCES += \
+   $(COMMON_CXX_SOURCES) \
+   rasterizer/codegen/gen_knobs.cpp \
+   rasterizer/codegen/gen_knobs.h
+if HAVE_SWR_AVX
+lib_LTLIBRARIES += libswrAVX.la
+endif
+if HAVE_SWR_AVX2
+lib_LTLIBRARIES += libswrAVX2.la
+endif
+if HAVE_SWR_KNL
+lib_LTLIBRARIES += libswrKNL.la
+endif
+if HAVE_SWR_SKX
+lib_LTLIBRARIES += libswrSKX.la
+endif
+endif
+
 include $(top_srcdir)/install-gallium-links.mk
 
 # Generated gen_builder.hpp is not backwards compatible. So ship only one
-- 
2.14.3

[Mesa-dev] [PATCH 2/2] swr: allow a single swr architecture to be builtin

Part 2 of 2 (part 1 is autoconf changes, part 2 is C++ changes)

When only a single SWR architecture is being used, this allows that
architecture to be builtin rather than as a separate libswrARCH.so that
gets loaded via dlopen.  Since there are now several different code
paths for each detected CPU architecture, the log output is also
adjusted to convey where the backend is getting loaded from.

This allows SWR to be used for static mesa builds which are still
important for large HPC environments where shared libraries can impose
unacceptable application startup times as hundreds of thousands of copies
of the libs are loaded from a shared parallel filesystem.

Based on an initial implementation by Tim Rowley.

v2: Refactor repetitive preprocessor checks to reduce code duplication
v3: Formatting changes per Bruce C. Also delay screen creation until end
to avoid leaks when failure conditions are hit.

Signed-off-by: Chuck Atkins 
Reviewed-by: Bruce Cherniak 
CC: Tim Rowley 
---
 src/gallium/drivers/swr/swr_loader.cpp | 84 --
 1 file changed, 49 insertions(+), 35 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_loader.cpp 
b/src/gallium/drivers/swr/swr_loader.cpp
index 9d6f918e34..7f28bdb536 100644
--- a/src/gallium/drivers/swr/swr_loader.cpp
+++ b/src/gallium/drivers/swr/swr_loader.cpp
@@ -28,81 +28,95 @@
 
 #include 
 
+// Helper function to resolve the backend filename based on architecture
+inline void get_swr_arch_filename(const char arch[], char filename[])
+{
+#ifdef HAVE_SWR_BUILTIN
+   strcpy(filename , "builtin");
+#else
+   sprintf(filename, "%sswr%s%s", UTIL_DL_PREFIX, arch, UTIL_DL_EXT);
+#endif
+}
+
 struct pipe_screen *
 swr_create_screen(struct sw_winsys *winsys)
 {
char filename[256] = { 0 };
-   fprintf(stderr, "SWR detected ");
-
-   util_dl_library *pLibrary = nullptr;
+   bool found = false;
+   bool is_knl = false;
+   PFNSwrGetInterface pfnSwrGetInterface = nullptr;
 
util_cpu_detect();
 
-   bool is_knl = false;
-
-   if (!strlen(filename) &&
-   util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er) {
-#if HAVE_SWR_KNL
-  fprintf(stderr, "KNL ");
-  sprintf(filename, "%s%s%s", UTIL_DL_PREFIX, "swrKNL", UTIL_DL_EXT);
-  is_knl = true;
+   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512er) {
+  fprintf(stderr, "SWR detected KNL instruction support ");
+#ifndef HAVE_SWR_KNL
+  fprintf(stderr, "(skipping not built).\n");
 #else
-  fprintf(stderr, "KNL (not built) ");
+  get_swr_arch_filename("KNL", filename);
+  found = true;
+  is_knl = true;
 #endif
}
 
-   if (!strlen(filename) &&
-   util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw) {
-#if HAVE_SWR_SKX
-  fprintf(stderr, "SKX ");
-  sprintf(filename, "%s%s%s", UTIL_DL_PREFIX, "swrSKX", UTIL_DL_EXT);
+   if (!found && util_cpu_caps.has_avx512f && util_cpu_caps.has_avx512bw) {
+  fprintf(stderr, "SWR detected SKX instruction support ");
+#ifndef HAVE_SWR_SKX
+  fprintf(stderr, "(skipping not built).\n");
 #else
-  fprintf(stderr, "SKX (not built) ");
+  get_swr_arch_filename("SKX", filename);
+  found = true;
 #endif
}
 
-   if (!strlen(filename) && util_cpu_caps.has_avx2) {
-#if HAVE_SWR_AVX2
-  fprintf(stderr, "AVX2 ");
-  sprintf(filename, "%s%s%s", UTIL_DL_PREFIX, "swrAVX2", UTIL_DL_EXT);
+   if (!found && util_cpu_caps.has_avx2) {
+  fprintf(stderr, "SWR detected AVX2 instruction support ");
+#ifndef HAVE_SWR_AVX2
+  fprintf(stderr, "(skipping not built).\n");
 #else
-  fprintf(stderr, "AVX2 (not built) ");
+  get_swr_arch_filename("AVX2", filename);
+  found = true;
 #endif
}
 
-   if (!strlen(filename) && util_cpu_caps.has_avx) {
-#if HAVE_SWR_AVX
-  fprintf(stderr, "AVX ");
-  sprintf(filename, "%s%s%s", UTIL_DL_PREFIX, "swrAVX", UTIL_DL_EXT);
+   if (!found && util_cpu_caps.has_avx) {
+  fprintf(stderr, "SWR detected AVX instruction support ");
+#ifndef HAVE_SWR_AVX
+  fprintf(stderr, "(skipping not built).\n");
 #else
-  fprintf(stderr, "AVX (not built) ");
+  get_swr_arch_filename("AVX", filename);
+  found = true;
 #endif
}
 
-   if (!strlen(filename)) {
-  fprintf(stderr, "- no appropriate swr architecture library.  
Aborting!\n");
+   if (!found) {
+  fprintf(stderr, "SWR could not detect a supported CPU architecture.\n");
   exit(-1);
-   } else {
-  fprintf(stderr, "\n");
}
 
-   pLibrary = util_dl_open(filename);
+   fprintf(stderr, "(using %s).\n", filename);
 
+#ifdef HAVE_SWR_BUILTIN
+   pfnSwrGetInterface = SwrGetInterface;
+#else
+   util_dl_library *pLibrary = util_dl_open(filename);
if (!pLibrary) {
   fprintf(stderr, "SWR library load failure: %s\n", util_dl_error());
   exit(-1);
}
 
util_dl_proc pApiProc = util_dl_get_proc_address(pLibrary, 
"SwrGetInterface");
-
if

Re: [Mesa-dev] [PATCH] gallivm: avx-512 changes for texel fetcher

2018-01-18 Thread Kyriazis, George


On Jan 18, 2018, at 1:10 PM, Roland Scheidegger 
> wrote:

Am 17.01.2018 um 23:33 schrieb George Kyriazis:
The texture swizzle was not doing the right thing for avx512-style
16-wide loads.

Special-case the post-load swizzle operations for avx512 so that we move
the xyzw components correctly to the outputs.

cc: Jose Fonseca >
---
src/gallium/auxiliary/gallivm/lp_bld_pack.c | 40 +++--
1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_pack.c 
b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
index e8d4fcd..7879826 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
@@ -129,6 +129,31 @@ lp_build_const_unpack_shuffle_half(struct gallivm_state 
*gallivm,
}

/**
+ * Similar to lp_build_const_unpack_shuffle_half, but for AVX512
+ * See comment above lp_build_interleave2_half for more details.
+ */
+static LLVMValueRef
+lp_build_const_unpack_shuffle_16wide(struct gallivm_state *gallivm,
+ unsigned lo_hi)
+{
+   LLVMValueRef elems[LP_MAX_VECTOR_LENGTH];
+   unsigned i, j;
+
+   assert(lo_hi < 2);
+
+   // for the following lo_hi setting, convert 0 -> f to:
+   // 0: 0 16 4 20  8 24 12 28 1 17 5 21  9 25 13 29
+   // 1: 2 18 6 22 10 26 14 30 3 19 7 23 11 27 15 31
+   for (i = 0; i < 16; i++) {
+  j = ((i&0x06)<<1) + ((i&1)<<4) + (i>>3) + (lo_hi<<1);
+
+  elems[i] = lp_build_const_int32(gallivm, j);
+   }
+
+   return LLVMConstVector(elems, 16);
+}
+
+/**
 * Build shuffle vectors that match PACKxx (SSE) instructions or
 * VPERM (Altivec).
 */
@@ -325,8 +350,8 @@ lp_build_interleave2(struct gallivm_state *gallivm,
}

/**
- * Interleave vector elements but with 256 bit,
- * treats it as interleave with 2 concatenated 128 bit vectors.
+ * Interleave vector elements but with 256 (or 512) bit,
+ * treats it as interleave with 2 concatenated 128 (or 256) bit vectors.
 *
 * This differs to lp_build_interleave2 as that function would do the following 
(for lo):
 * a0 b0 a1 b1 a2 b2 a3 b3, and this does not compile into an AVX unpack 
instruction.
@@ -343,6 +368,14 @@ lp_build_interleave2(struct gallivm_state *gallivm,
 *
 * And interleave-hi would result in:
 *   a2 b2 a3 b3 a6 b6 a7 b7
+ *
+ * For 512 bits, the following are true:
+ *
+ * Interleave-lo would result in (capital letters denote hex indices):
+ *   a0 b0 a1 b1 a4 b4 a5 b5 a8 b8 a9 b9 aC bC aD bD
+ *
+ * Interleave-hi would result in:
+ *   a2 b2 a3 b3 a6 b6 a7 b7 aA bA aB bB aE bE aF bF
 */
LLVMValueRef
lp_build_interleave2_half(struct gallivm_state *gallivm,
@@ -354,6 +387,9 @@ lp_build_interleave2_half(struct gallivm_state *gallivm,
   if (type.length * type.width == 256) {
  LLVMValueRef shuffle = lp_build_const_unpack_shuffle_half(gallivm, 
type.length, lo_hi);
  return LLVMBuildShuffleVector(gallivm->builder, a, b, shuffle, "");
+   } else if ((type.length == 16) && (type.width == 32)) {
+  LLVMValueRef shuffle = lp_build_const_unpack_shuffle_16wide(gallivm, 
lo_hi);
+  return LLVMBuildShuffleVector(gallivm->builder, a, b, shuffle, "");
This is not really "interleave_half", more like "interleave_quarter"...
That said, avx512 certainly follows the same rules as avx256, so 128bit
pieces are treated independently. So maybe this should be renamed like
"interleave_native" or something like that.
Also, I believe it is definitely a mistake to restrict this to dword
interleaves here. You should handle all type widths, just like the
256bit case can handle all widths.
And I'm not sure through which paths you reach this, but I'm not sure
why you don't need the corresponding unpack2_native and pack2_native
adjustments - it should not really be a special case, avx512 should
generally handle things like this (if you'd want to extend the gallivm
code to use avx512...). For that matter, the commit log and shortlog is
confusing, because this isn't directly related to texture fetching.

Roland

Roland,

The stack trace that I am seeing is the following:

(gdb) bt
#0  lp_build_const_unpack_shuffle_16wide (gallivm=0x168b690, lo_hi=0)
at ../../../../src/gallium/auxiliary/gallivm/lp_bld_pack.c:138
#1  0x762786de in lp_build_interleave2_half (gallivm=0x168b690,
type=..., a=0x16a7378, b=0x16a7d38, lo_hi=0)
at ../../../../src/gallium/auxiliary/gallivm/lp_bld_pack.c:391
#2  0x7629585f in lp_build_transpose_aos (gallivm=0x168b690,
single_type_lp=..., src=0x7fff32e0, dst=0x7fff3300)
at ../../../../src/gallium/auxiliary/gallivm/lp_bld_swizzle.c:664
#3  0x7626a887 in lp_build_fetch_rgba_soa (gallivm=0x168b690,
format_desc=0x767fe9a0 ,
type=..., aligned=1 '\001', base_ptr=0x16a3218, offset=0x16a6890,
i=0xf87a90, j=0xf87a90, cache=0x0, rgba_out=0x7fff4280)
at ../../../../src/gallium/auxiliary/gallivm/lp_bld_format_soa.c:635
#4

Re: [Mesa-dev] [PATCH 02/14] vc4, vc5: add ETIME fallback define

Quoting Emil Velikov (2018-01-18 10:40:40)
> On 18 January 2018 at 17:13, Dylan Baker  wrote:
> > I'm not sure how Emil feels about this (and the related patches) but I 
> > think it
> > might be better to handle this at the build system level, for meson it would
> > look something like (in the top level meson.build):
> >
> > if cc.get_define('ETIME') == ''
> >   pre_args += '-DETIME=ETIMEDOUT'
> > endif
> >
> > Which should be a permanent fix. Emil can probably provide an autotools
> > equivalent.
> >
> I'm not sure how the above works on meson - the define can come from
> multiple places.
> Surely meson does not check every header available on the system?

It doesn't, it checks for defines the preprocessor knows about, if you need to
check specific headers there's `has_header_symbol`.

Maybe this isn't feasible, but it really feels like having to define ETIME all
over the tree if it's not defined is fragile and ugly. I'm with you and Eric
that FreeBSD really should solve this themselves.

> 
> FWIW I've spent hours over the years looking at this ETIME workaround.
> Due to $reasons various projects define the macro, some even without
> checking if it's already set.
> Memory is fuzzy, but I believe I've seen projects installing headers
> with the redefine.
> 
> I sincerely hope that the FreeBSD devs can see waste of time this is
> causing them and consider a more pragmatic solution.
> 
> -Emil


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] radv: Use correct bindings for inputRate in key generation.

On 19 January 2018 at 00:55, Bas Nieuwenhuizen  wrote:
> The bindings also have an index field.

Make sense,

Reviewed-by: Dave Airlie 

>
> Fixes: 49d035122e "radv: Add single pipeline cache key."
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104677
> ---
>  src/amd/vulkan/radv_pipeline.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index c3c17af850..5f824796fe 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -1726,10 +1726,16 @@ radv_generate_graphics_pipeline_key(struct 
> radv_pipeline *pipeline,
>
> key.has_multiview_view_index = has_view_index;
>
> +   uint32_t binding_input_rate = 0;
> +   for (unsigned i = 0; i < input_state->vertexBindingDescriptionCount; 
> ++i) {
> +   if (input_state->pVertexBindingDescriptions[i].inputRate)
> +   binding_input_rate |= 1u << 
> input_state->pVertexBindingDescriptions[i].binding;
> +   }
> +
> for (unsigned i = 0; i < 
> input_state->vertexAttributeDescriptionCount; ++i) {
> unsigned binding;
> binding = 
> input_state->pVertexAttributeDescriptions[i].binding;
> -   if 
> (input_state->pVertexBindingDescriptions[binding].inputRate)
> +   if (binding_input_rate & (1u << binding))
> key.instance_rate_inputs |= 1u << 
> input_state->pVertexAttributeDescriptions[i].location;
> }
>
> --
> 2.15.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 v2] egl/android: Implement the eglSwapinterval for Android.

On Thursday, 2018-01-18 19:07:06 +, Emil Velikov wrote:
> On 18 January 2018 at 17:43, Eric Engestrom  wrote:
> > On Thursday, 2018-01-18 07:52:42 +, Zhongmin Wu wrote:
> >> Implement the eglSwapinterval for Android platform to
> >> enable the async mode for some GFX benchmarks such as
> >> Daimler C217, CityBench.
> >>
> >> Signed-off-by: Zhongmin Wu 
> >> ---
> >>  src/egl/drivers/dri2/platform_android.c | 21 +
> >>  1 file changed, 21 insertions(+)
> >>
> >> diff --git a/src/egl/drivers/dri2/platform_android.c 
> >> b/src/egl/drivers/dri2/platform_android.c
> >> index f6a24cd..3a64689 100644
> >> --- a/src/egl/drivers/dri2/platform_android.c
> >> +++ b/src/egl/drivers/dri2/platform_android.c
> >> @@ -476,6 +476,20 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay 
> >> *disp, _EGLSurface *surf)
> >> return EGL_TRUE;
> >>  }
> >>
> >> +static EGLBoolean
> >> +droid_swap_interval(_EGLDriver *drv, _EGLDisplay *dpy,
> >> +   _EGLSurface *surf, EGLint interval)
> >> +{
> >> +   struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surf);
> >> +   struct ANativeWindow *window = dri2_surf->window;
> >> +
> >> +   if (window->setSwapInterval(window, interval))
> >> +  return EGL_FALSE;
> >> +
> >> +   surf->SwapInterval = interval;
> >> +   return EGL_TRUE;
> >> +}
> >> +
> >>  static int
> >>  update_buffers(struct dri2_egl_surface *dri2_surf)
> >>  {
> >> @@ -1300,6 +1314,7 @@ static const struct dri2_egl_display_vtbl 
> >> droid_display_vtbl = {
> >> .swap_buffers = droid_swap_buffers,
> >> .swap_buffers_with_damage = dri2_fallback_swap_buffers_with_damage, /* 
> >> Android implements the function */
> >> .swap_buffers_region = dri2_fallback_swap_buffers_region,
> >> +   .swap_interval = droid_swap_interval,
> >>  #if ANDROID_API_LEVEL >= 23
> >> .set_damage_region = droid_set_damage_region,
> >>  #else
> >> @@ -1443,6 +1458,12 @@ dri2_initialize_android(_EGLDriver *drv, 
> >> _EGLDisplay *dpy)
> >>
> >> dri2_setup_screen(dpy);
> >>
> >> +   /* we set the maximum swap interval as 1 for Android platform, Since
> >> +   it is the maximum value supported by Android according to the
> >> +   value of ANativeWindow::maxSwapInterval.
> >> +   */
> >> +   dri2_setup_swap_interval(dpy, 1);
> >
> > My C<->C++ interaction skills are more than rusty, but is it possible to
> > use `ANativeWindow.maxSwapInterval` or something like this?
> >
> > Given that the dEQP tests all pass, whether with the current comment or
> > the class field directly used in the code, this patch is:
> > Reviewed-by: Eric Engestrom 
> >
> > I'll push it for you in a couple days if no one objects :)
> >
> My current checkout shows the struct is nicely separated for inclusion
> in both C and C++ sources.
> The C++ vfuncs are wrapped in a ifdef _cplusplus block, so the ABI
> should be identical across both.
> 
> I'm suspecting that maxSwapInterval > 1 will require additional
> changes, so I'd keep it as-is

That's actually a good point; this should indeed stay hard coded, with
this comment.

> (nit the comment style and adding dEQP stats in the commit message).

I was going to do this before pushing, but you're right to point it out :)

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

Re: [Mesa-dev] [PATCH v2 3/4] meson: fix getting cflags from pkg-config

Quoting Emil Velikov (2018-01-18 10:26:20)
> On 17 January 2018 at 20:54, Greg V  wrote:
> > get_pkgconfig_variable('cflags') always returns an empty list, it's a
> > function for getting *custom* variables.
> >
> > Meson does not yet support asking for cflags, so explicitly invoke
> > pkg-config for now.
> That sounds unfortunate ;-(

Indeed, I'm hoping this will be resolved in 0.45

> Is the proposed solution going to work correctly if one explicitly
> asks for gallium-vdpau, yet the vdpau package is missing?
> 
> -Emil

Yes, you'll have a hard error before that, since in the vdpau == 'true' case if
you don't have vdpau then you'll have a hard error.


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] meson: Don't confuse the install and search paths for dri drivers

Dylan Baker  writes:

> Currently there is not a separate option for setting the search path of
> DRI drivers in meson, like there is in scons and autotools. This is an
> oversight and needs to be fixed. This adds an extra option
> `dri-search-path`, which will default to the value of
> `dri-drivers-path`, like autotools does.
>
> v2: - Split input list before joining.
>
> Reported-by: Ilia Mirkin 
> Signed-off-by: Dylan Baker 

Reviewed-by: Eric Anholt 


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 0/6] meson: fix gallium media target linkage

Quoting Emil Velikov (2018-01-18 11:12:30)
> On 17 January 2018 at 18:34, Dylan Baker  wrote:
> > The linkage of all of the gallium media targets is broken in various
> > ways in the meson build. This series should correct that by doing more
> > what the autotools build does.
> >
> Above all and slightly unrelated, can I ask you about the rather
> unusual gallium- prefix for vdpau and friends?
> Can we drop it, please?

Since vdpau, nine, va, etc depend on gallium it makes sense to me to give them
gallium based names. *shrug*

> 
> AFAICT there are a few corner cases, plus patches tends to do a few
> somewhat unrelated things.
> Can you please wait up until tomorrow (have to run for the final bus
> home in 5 mins) I'll share some tips making the build scripts shorter
> and more robust.
> 
> Obviously, the patches are suitable material after the branch point,
> so please don't rush to get everything merged by tomorrow.
> 
> Thanks
> Emil


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] r600: enable ARB_enhanced_layouts

On 19 January 2018 at 04:30, Roland Scheidegger  wrote:
> Looks good to me, seems like you're nearly done with gl 4.5 ;-)

Thanks,

I've mostly written qbo support I think (the 64-bit int divide is the
biggest thing left),

However we'll have to keep restricted to GL4.3 until we can show some attempt at
passing conformance, my first attempt at that crashed a lot, so we
have a bit to go :-)

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

Re: [Mesa-dev] [PATCH] gallivm: avx-512 changes for texel fetcher

2018-01-18 Thread Kyriazis, George

On Jan 18, 2018, at 1:10 PM, Roland Scheidegger 
> wrote:

Am 17.01.2018 um 23:33 schrieb George Kyriazis:
The texture swizzle was not doing the right thing for avx512-style
16-wide loads.

Special-case the post-load swizzle operations for avx512 so that we move
the xyzw components correctly to the outputs.

cc: Jose Fonseca >
---
src/gallium/auxiliary/gallivm/lp_bld_pack.c | 40 +++--
1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_pack.c 
b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
index e8d4fcd..7879826 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
@@ -129,6 +129,31 @@ lp_build_const_unpack_shuffle_half(struct gallivm_state 
*gallivm,
}

/**
+ * Similar to lp_build_const_unpack_shuffle_half, but for AVX512
+ * See comment above lp_build_interleave2_half for more details.
+ */
+static LLVMValueRef
+lp_build_const_unpack_shuffle_16wide(struct gallivm_state *gallivm,
+ unsigned lo_hi)
+{
+   LLVMValueRef elems[LP_MAX_VECTOR_LENGTH];
+   unsigned i, j;
+
+   assert(lo_hi < 2);
+
+   // for the following lo_hi setting, convert 0 -> f to:
+   // 0: 0 16 4 20  8 24 12 28 1 17 5 21  9 25 13 29
+   // 1: 2 18 6 22 10 26 14 30 3 19 7 23 11 27 15 31
+   for (i = 0; i < 16; i++) {
+  j = ((i&0x06)<<1) + ((i&1)<<4) + (i>>3) + (lo_hi<<1);
+
+  elems[i] = lp_build_const_int32(gallivm, j);
+   }
+
+   return LLVMConstVector(elems, 16);
+}
+
+/**
 * Build shuffle vectors that match PACKxx (SSE) instructions or
 * VPERM (Altivec).
 */
@@ -325,8 +350,8 @@ lp_build_interleave2(struct gallivm_state *gallivm,
}

/**
- * Interleave vector elements but with 256 bit,
- * treats it as interleave with 2 concatenated 128 bit vectors.
+ * Interleave vector elements but with 256 (or 512) bit,
+ * treats it as interleave with 2 concatenated 128 (or 256) bit vectors.
 *
 * This differs to lp_build_interleave2 as that function would do the following 
(for lo):
 * a0 b0 a1 b1 a2 b2 a3 b3, and this does not compile into an AVX unpack 
instruction.
@@ -343,6 +368,14 @@ lp_build_interleave2(struct gallivm_state *gallivm,
 *
 * And interleave-hi would result in:
 *   a2 b2 a3 b3 a6 b6 a7 b7
+ *
+ * For 512 bits, the following are true:
+ *
+ * Interleave-lo would result in (capital letters denote hex indices):
+ *   a0 b0 a1 b1 a4 b4 a5 b5 a8 b8 a9 b9 aC bC aD bD
+ *
+ * Interleave-hi would result in:
+ *   a2 b2 a3 b3 a6 b6 a7 b7 aA bA aB bB aE bE aF bF
 */
LLVMValueRef
lp_build_interleave2_half(struct gallivm_state *gallivm,
@@ -354,6 +387,9 @@ lp_build_interleave2_half(struct gallivm_state *gallivm,
   if (type.length * type.width == 256) {
  LLVMValueRef shuffle = lp_build_const_unpack_shuffle_half(gallivm, 
type.length, lo_hi);
  return LLVMBuildShuffleVector(gallivm->builder, a, b, shuffle, "");
+   } else if ((type.length == 16) && (type.width == 32)) {
+  LLVMValueRef shuffle = lp_build_const_unpack_shuffle_16wide(gallivm, 
lo_hi);
+  return LLVMBuildShuffleVector(gallivm->builder, a, b, shuffle, "");
This is not really "interleave_half", more like "interleave_quarter"...
That said, avx512 certainly follows the same rules as avx256, so 128bit
pieces are treated independently. So maybe this should be renamed like
"interleave_native" or something like that.
Also, I believe it is definitely a mistake to restrict this to dword
interleaves here. You should handle all type widths, just like the
256bit case can handle all widths.
And I'm not sure through which paths you reach this, but I'm not sure
why you don't need the corresponding unpack2_native and pack2_native
adjustments - it should not really be a special case, avx512 should
generally handle things like this (if you'd want to extend the gallivm
code to use avx512...). For that matter, the commit log and shortlog is
confusing, because this isn't directly related to texture fetching.


Thanks Roland,

This check-in is a prerequisite for some avx-512 changes I am about to check in 
to the swr driver.  I’ve hit this for piglit test vs-texelfetch-isampler1d and 
similar ones that try to fetch from a texture from a VS.  You are right, there 
are probably other cases where this gets hit, but that was the place where I’ve 
hit it first.  If you could recommend some tests that hit the other width 
cases, it would be great to fix them too; since didn’t know where those cases 
would be hit, I decided to make this “surgical” change.

My follow-on changes depend on this change for correctness, and I’d like to get 
the the other changes in before the mesa 18.0 date (tomorrow).  AVX512 support 
is an ongoing effort on our side, so they will definitely be additional 
check-ins along the same lines.

Thoughts on checking in as-is for 18.0, with upcoming changes slowly creeping 
in to fix additional issues, and

Re: [Mesa-dev] [PATCH v2 2/4] meson: handle LLVM 'x.x.xgit-revision' versions

Quoting Emil Velikov (2018-01-18 10:22:50)
> On 17 January 2018 at 20:54, Greg V  wrote:
> > When LLVM is built inside of a git repo (even way below, e.g. 
> > /usr/ports/.git
> > exists, and LLVM is built in /usr/ports/devel/llvm50/work), its version
> > becomes something like 5.0.0git-f8ab206b2176.
> >
> > New meson versions already handle this, but we support older versions too.
> >
> Crazy idea:
> Using a grep-like solution analogous to autotools [1]. That will work
> with old/new Meson, svn, git, plus any other suffix as LLVM devs
> decide to change it.
> 
> -Emil
> 
> [1] llvm-config --version | egrep -o '^[0-9]+'
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

That is a much nicer idea. I've submitted a meson patch to do this instead of
specifically stripping svn.* and git.*


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 02/14] vc4, vc5: add ETIME fallback define

Dylan Baker  writes:

> [ Unknown signature status ]
> I'm not sure how Emil feels about this (and the related patches) but I think 
> it
> might be better to handle this at the build system level, for meson it would
> look something like (in the top level meson.build):
>
> if cc.get_define('ETIME') == ''
>   pre_args += '-DETIME=ETIMEDOUT'
> endif
>
> Which should be a permanent fix. Emil can probably provide an autotools
> equivalent.
>
> Quoting Greg V (2017-12-31 08:55:16)
>> FreeBSD only has ETIMEDOUT, not ETIME

Agreed, that if FreeBSD can't sort out the portability issue on their
end (which they really should), it should at least be a global
workaround in Mesa and not per-file.


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 0/6] meson: fix gallium media target linkage

On 17 January 2018 at 18:34, Dylan Baker  wrote:
> The linkage of all of the gallium media targets is broken in various
> ways in the meson build. This series should correct that by doing more
> what the autotools build does.
>
Above all and slightly unrelated, can I ask you about the rather
unusual gallium- prefix for vdpau and friends?
Can we drop it, please?

AFAICT there are a few corner cases, plus patches tends to do a few
somewhat unrelated things.
Can you please wait up until tomorrow (have to run for the final bus
home in 5 mins) I'll share some tips making the build scripts shorter
and more robust.

Obviously, the patches are suitable material after the branch point,
so please don't rush to get everything merged by tomorrow.

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

Re: [Mesa-dev] [PATCH] gallivm: avx-512 changes for texel fetcher

Am 17.01.2018 um 23:33 schrieb George Kyriazis:
> The texture swizzle was not doing the right thing for avx512-style
> 16-wide loads.
> 
> Special-case the post-load swizzle operations for avx512 so that we move
> the xyzw components correctly to the outputs.
> 
> cc: Jose Fonseca 
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_pack.c | 40 
> +++--
>  1 file changed, 38 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_pack.c 
> b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
> index e8d4fcd..7879826 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_pack.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_pack.c
> @@ -129,6 +129,31 @@ lp_build_const_unpack_shuffle_half(struct gallivm_state 
> *gallivm,
>  }
>  
>  /**
> + * Similar to lp_build_const_unpack_shuffle_half, but for AVX512
> + * See comment above lp_build_interleave2_half for more details.
> + */
> +static LLVMValueRef
> +lp_build_const_unpack_shuffle_16wide(struct gallivm_state *gallivm,
> + unsigned lo_hi)
> +{
> +   LLVMValueRef elems[LP_MAX_VECTOR_LENGTH];
> +   unsigned i, j;
> +
> +   assert(lo_hi < 2);
> +
> +   // for the following lo_hi setting, convert 0 -> f to:
> +   // 0: 0 16 4 20  8 24 12 28 1 17 5 21  9 25 13 29
> +   // 1: 2 18 6 22 10 26 14 30 3 19 7 23 11 27 15 31
> +   for (i = 0; i < 16; i++) {
> +  j = ((i&0x06)<<1) + ((i&1)<<4) + (i>>3) + (lo_hi<<1);
> +
> +  elems[i] = lp_build_const_int32(gallivm, j);
> +   }
> +
> +   return LLVMConstVector(elems, 16);
> +}
> +
> +/**
>   * Build shuffle vectors that match PACKxx (SSE) instructions or
>   * VPERM (Altivec).
>   */
> @@ -325,8 +350,8 @@ lp_build_interleave2(struct gallivm_state *gallivm,
>  }
>  
>  /**
> - * Interleave vector elements but with 256 bit,
> - * treats it as interleave with 2 concatenated 128 bit vectors.
> + * Interleave vector elements but with 256 (or 512) bit,
> + * treats it as interleave with 2 concatenated 128 (or 256) bit vectors.
>   *
>   * This differs to lp_build_interleave2 as that function would do the 
> following (for lo):
>   * a0 b0 a1 b1 a2 b2 a3 b3, and this does not compile into an AVX unpack 
> instruction.
> @@ -343,6 +368,14 @@ lp_build_interleave2(struct gallivm_state *gallivm,
>   *
>   * And interleave-hi would result in:
>   *   a2 b2 a3 b3 a6 b6 a7 b7
> + *
> + * For 512 bits, the following are true:
> + *
> + * Interleave-lo would result in (capital letters denote hex indices):
> + *   a0 b0 a1 b1 a4 b4 a5 b5 a8 b8 a9 b9 aC bC aD bD
> + *
> + * Interleave-hi would result in:
> + *   a2 b2 a3 b3 a6 b6 a7 b7 aA bA aB bB aE bE aF bF
>   */
>  LLVMValueRef
>  lp_build_interleave2_half(struct gallivm_state *gallivm,
> @@ -354,6 +387,9 @@ lp_build_interleave2_half(struct gallivm_state *gallivm,
> if (type.length * type.width == 256) {
>LLVMValueRef shuffle = lp_build_const_unpack_shuffle_half(gallivm, 
> type.length, lo_hi);
>return LLVMBuildShuffleVector(gallivm->builder, a, b, shuffle, "");
> +   } else if ((type.length == 16) && (type.width == 32)) {
> +  LLVMValueRef shuffle = lp_build_const_unpack_shuffle_16wide(gallivm, 
> lo_hi);
> +  return LLVMBuildShuffleVector(gallivm->builder, a, b, shuffle, "");
This is not really "interleave_half", more like "interleave_quarter"...
That said, avx512 certainly follows the same rules as avx256, so 128bit
pieces are treated independently. So maybe this should be renamed like
"interleave_native" or something like that.
Also, I believe it is definitely a mistake to restrict this to dword
interleaves here. You should handle all type widths, just like the
256bit case can handle all widths.
And I'm not sure through which paths you reach this, but I'm not sure
why you don't need the corresponding unpack2_native and pack2_native
adjustments - it should not really be a special case, avx512 should
generally handle things like this (if you'd want to extend the gallivm
code to use avx512...). For that matter, the commit log and shortlog is
confusing, because this isn't directly related to texture fetching.

Roland





> } else {
>return lp_build_interleave2(gallivm, type, a, b, lo_hi);
> }
> 

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

Re: [Mesa-dev] [PATCH v2] egl/android: Implement the eglSwapinterval for Android.

On 18 January 2018 at 17:43, Eric Engestrom  wrote:
> On Thursday, 2018-01-18 07:52:42 +, Zhongmin Wu wrote:
>> Implement the eglSwapinterval for Android platform to
>> enable the async mode for some GFX benchmarks such as
>> Daimler C217, CityBench.
>>
>> Signed-off-by: Zhongmin Wu 
>> ---
>>  src/egl/drivers/dri2/platform_android.c | 21 +
>>  1 file changed, 21 insertions(+)
>>
>> diff --git a/src/egl/drivers/dri2/platform_android.c 
>> b/src/egl/drivers/dri2/platform_android.c
>> index f6a24cd..3a64689 100644
>> --- a/src/egl/drivers/dri2/platform_android.c
>> +++ b/src/egl/drivers/dri2/platform_android.c
>> @@ -476,6 +476,20 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay 
>> *disp, _EGLSurface *surf)
>> return EGL_TRUE;
>>  }
>>
>> +static EGLBoolean
>> +droid_swap_interval(_EGLDriver *drv, _EGLDisplay *dpy,
>> +   _EGLSurface *surf, EGLint interval)
>> +{
>> +   struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surf);
>> +   struct ANativeWindow *window = dri2_surf->window;
>> +
>> +   if (window->setSwapInterval(window, interval))
>> +  return EGL_FALSE;
>> +
>> +   surf->SwapInterval = interval;
>> +   return EGL_TRUE;
>> +}
>> +
>>  static int
>>  update_buffers(struct dri2_egl_surface *dri2_surf)
>>  {
>> @@ -1300,6 +1314,7 @@ static const struct dri2_egl_display_vtbl 
>> droid_display_vtbl = {
>> .swap_buffers = droid_swap_buffers,
>> .swap_buffers_with_damage = dri2_fallback_swap_buffers_with_damage, /* 
>> Android implements the function */
>> .swap_buffers_region = dri2_fallback_swap_buffers_region,
>> +   .swap_interval = droid_swap_interval,
>>  #if ANDROID_API_LEVEL >= 23
>> .set_damage_region = droid_set_damage_region,
>>  #else
>> @@ -1443,6 +1458,12 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay 
>> *dpy)
>>
>> dri2_setup_screen(dpy);
>>
>> +   /* we set the maximum swap interval as 1 for Android platform, Since
>> +   it is the maximum value supported by Android according to the
>> +   value of ANativeWindow::maxSwapInterval.
>> +   */
>> +   dri2_setup_swap_interval(dpy, 1);
>
> My C<->C++ interaction skills are more than rusty, but is it possible to
> use `ANativeWindow.maxSwapInterval` or something like this?
>
> Given that the dEQP tests all pass, whether with the current comment or
> the class field directly used in the code, this patch is:
> Reviewed-by: Eric Engestrom 
>
> I'll push it for you in a couple days if no one objects :)
>
My current checkout shows the struct is nicely separated for inclusion
in both C and C++ sources.
The C++ vfuncs are wrapped in a ifdef _cplusplus block, so the ABI
should be identical across both.

I'm suspecting that maxSwapInterval > 1 will require additional
changes, so I'd keep it as-is (nit the comment style and adding dEQP
stats in the commit message).
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH 13/14] swr: fix clang 5 null cast warning

2018-01-18 Thread Cherniak, Bruce

Apologies for not seeing this over the holidays.

Reviewed-by: Bruce Cherniak 
>

On Jan 18, 2018, at 12:03 PM, Emil Velikov 
> wrote:

On 31 December 2017 at 16:55, Greg V 
> wrote:
---
src/gallium/drivers/swr/rasterizer/memory/TilingFunctions.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/memory/TilingFunctions.h 
b/src/gallium/drivers/swr/rasterizer/memory/TilingFunctions.h
index 6c801c7ff6..abb0c53ec4 100644
--- a/src/gallium/drivers/swr/rasterizer/memory/TilingFunctions.h
+++ b/src/gallium/drivers/swr/rasterizer/memory/TilingFunctions.h
@@ -624,7 +624,7 @@ uint32_t TileSwizzle2D(uint32_t xOffsetBytes, uint32_t 
yOffsetRows, const SWR_SU
case SWR_TILE_MODE_WMAJOR: return 
ComputeTileSwizzle2D >(xOffsetBytes, 
yOffsetRows, pState);
default: SWR_INVALID("Unsupported tiling mode");
}
-return (uint32_t) NULL;
+return 0;
}

//
@@ -644,7 +644,7 @@ uint32_t TileSwizzle3D(uint32_t xOffsetBytes, uint32_t 
yOffsetRows, uint32_t zOf
case SWR_TILE_MODE_YMAJOR: return 
ComputeTileSwizzle3D >(xOffsetBytes, 
yOffsetRows, zOffsetSlices, pState);
default: SWR_INVALID("Unsupported tiling mode");
}
-return (uint32_t) NULL;
+return 0;
}

template
@@ -677,7 +677,7 @@ uint32_t ComputeSurfaceOffset(uint32_t x, uint32_t y, 
uint32_t z, uint32_t array
default: SWR_INVALID("Unsupported format");
}

-return (uint32_t) NULL;
+return 0;
}

[Adding a couple of SWR devs]

Patch looks good, although there might be some subtle reason behind
the current approach.
Reviewed-by: Emil Velikov 
>

-Emil

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

Re: [Mesa-dev] [PATCH 00/14] BSD portability (Meson, ANV, RADV, VC4/5, SWR)

On 18 January 2018 at 18:29, Greg V  wrote:
>
> On 01/18/2018 21:18, Emil Velikov wrote:
>>
>> Hi Greg,
>>
>> On 31 December 2017 at 16:55, Greg V  wrote:
>>>
>>> Hello everyone and happy new year! :)
>>>
>>> This set of patches makes the Meson build work on FreeBSD, including
>>> RADV, ANV, wayland-egl, VAAPI, VDPAU.
>>
>> Huge thanks for beating these into shape and sending them.
>>
>> Based on the sysconf patch it seems like the series isn't based again
>> master.
>> Can you please rebase?
>>
>> I've made a few suggestions about moving stuff into helpers, although
>> those are not a requirement.
>> We can merge the current ones, as long as you promise to address fix
>> them up as follow-up ;-)
>
> I'm working on the helpers, yeah.
>
> I've rebased and updated the meson patches, sent as v2.
> I'll send everything else as v2 with the helpers stuff.
>
> Sorry if I'm doing something wrong with series and stuff, I'm still a bit
> confused with this patch emailing thing, I'm used to GitHub and similar
> services :)
>
No worries - every project is different ;-)

The first google hit for "mesa submitting patches" is the correct one [1].
Although in practise you've handled everything very well, already.

[1] https://www.mesa3d.org/submittingpatches.html

>> It would be amazing if FreeBSD used the ETIME fallback in their
>> toolchain. Otherwise things break quite often, as you can see.
>> That's more of a dream of mine, so don't read too much into it.
>
> Did you get Dylan's reply about defining ETIME in meson/autotools?

AFAICT the approach is semi-magic, hence my day-dreaming on the topic.
I'll try to cook up some magic, but it will be very fragile.

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

Re: [Mesa-dev] [PATCH 2/2] swr: suppress debug output from loader unless LIBGL_DEBUG is set.

On Tuesday, 2018-01-16 19:38:25 +, Chuck Atkins wrote:
> > > +#define debug_printf(...) if(mesa_debug) { fprintf(stderr,
> > __VA_ARGS__); }
> >
> > `do {} while(0)`
> >
> 
> Forgive me but I don't understand, what you're saying here.

Sorry, I guess I could've used a few more characters to type my message :)

I meant that you could add a `do { X; } while(0)` loop around the `if`
in your macro, so as to avoid the common if/else bug, eg.:

  if (foo)
debug_printf("foo");
  else
debug_printf("not foo");

Without the `do{}while(0)` trick, this expands into:

  if (foo)
if (mesa_debug)
{
  fprintf(stderr, "foo");
}
else
  if (mesa_debug)
  {
fprintf(stderr, "not foo");
  }

and you'll never print "not foo".

The usual fix for this class of bugs is to add the `do{}while(0)` loop
as follows:

  #define debug_printf(...) \
do { \
  if (mesa_debug) { \
fprintf(stderr, __VA_ARGS__); \
  } \
} while(0)

> 
> 
> 
> > Why only replace some of the printfs?
> >
> 
> The fprintf's I replaced with debug_printf are informational status
> messages, while the ones I left are actual error messages.

My bad, I didn't actually look at them, just noticed they existed :)

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

Re: [Mesa-dev] [PATCH 12/14] swr: build on FreeBSD/DragonFlyBSD

On 18 January 2018 at 18:09, Greg V  wrote:
> On 01/18/2018 21:01, Emil Velikov wrote:
>>
>> On 31 December 2017 at 16:55, Greg V  wrote:
>>>
>>> (Needs CPU topology detection to actually work)
>>
>> IMHO it might be better to drop the patch, until its actually working.
>> There's little point in building it if one cannot use it.
>>
>> What do you think?
>
> Yeah, I guess I only mentioned that in the cover letter or somewhere — I
> have written that code and tested swr.
>
> Problem is, the topology is exposed as an XML string, so I used TinyXML2 to
> parse it.
> But I couldn't even figure out how to add that dependency to autotools, and
> meson doesn't build swr yet.
> Also not sure if that dependency is acceptable for Mesa.
> (I guess it's technically possible to use Expat, which is already a
> dependency, but ugh nope.)

My bad - I should have thoroughly read the cover letter first.
Expat would be amazing (long term), although in the short term
TinyXML2 would do.

Handling autotools is trivial

configure.ac:
// go to the if building SWR hunk
PKG_CHECK_MODULES([symbolic_name], [tinyxml2 >= $min_required version]

Then use symbolic_name_CFLAGS and symbolic_name_LIBS in the
appropriate places...
Without seeing the patch cannot tell you where exactly, since SWR is a
bit funky and produces five binaries.

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

Re: [Mesa-dev] [PATCH 02/14] vc4, vc5: add ETIME fallback define

On 18 January 2018 at 17:13, Dylan Baker  wrote:
> I'm not sure how Emil feels about this (and the related patches) but I think 
> it
> might be better to handle this at the build system level, for meson it would
> look something like (in the top level meson.build):
>
> if cc.get_define('ETIME') == ''
>   pre_args += '-DETIME=ETIMEDOUT'
> endif
>
> Which should be a permanent fix. Emil can probably provide an autotools
> equivalent.
>
I'm not sure how the above works on meson - the define can come from
multiple places.
Surely meson does not check every header available on the system?

FWIW I've spent hours over the years looking at this ETIME workaround.
Due to $reasons various projects define the macro, some even without
checking if it's already set.
Memory is fuzzy, but I believe I've seen projects installing headers
with the redefine.

I sincerely hope that the FreeBSD devs can see waste of time this is
causing them and consider a more pragmatic solution.

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

Re: [Mesa-dev] [PATCH 00/14] BSD portability (Meson, ANV, RADV, VC4/5, SWR)

2018-01-18 Thread Greg V



On 01/18/2018 21:18, Emil Velikov wrote:

Hi Greg,

On 31 December 2017 at 16:55, Greg V  wrote:

Hello everyone and happy new year! :)

This set of patches makes the Meson build work on FreeBSD, including
RADV, ANV, wayland-egl, VAAPI, VDPAU.

Huge thanks for beating these into shape and sending them.

Based on the sysconf patch it seems like the series isn't based again master.
Can you please rebase?

I've made a few suggestions about moving stuff into helpers, although
those are not a requirement.
We can merge the current ones, as long as you promise to address fix
them up as follow-up ;-)

I'm working on the helpers, yeah.

I've rebased and updated the meson patches, sent as v2.
I'll send everything else as v2 with the helpers stuff.

Sorry if I'm doing something wrong with series and stuff, I'm still a 
bit confused with this patch emailing thing, I'm used to GitHub and 
similar services :)



It would be amazing if FreeBSD used the ETIME fallback in their
toolchain. Otherwise things break quite often, as you can see.
That's more of a dream of mine, so don't read too much into it.

Did you get Dylan's reply about defining ETIME in meson/autotools?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/14] util: fix ElfW macro

2018-01-18 Thread Greg V


On 01/18/2018 19:57, Emil Velikov wrote:

On 31 December 2017 at 16:55, Greg V  wrote:

Elf64_Nhdr exists, Elf_Nhdr does not.

Can you please add a typedef in FreeBSD sources, pretty please?
I'm not a committer :) raised an issue in bugzilla: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225302


But after it gets added, old versions of FreeBSD won't go away instantly.
I guess we can keep the patch local to FreeBSD Ports though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 12/14] swr: build on FreeBSD/DragonFlyBSD

2018-01-18 Thread Greg V


On 01/18/2018 21:01, Emil Velikov wrote:

On 31 December 2017 at 16:55, Greg V  wrote:

(Needs CPU topology detection to actually work)

IMHO it might be better to drop the patch, until its actually working.
There's little point in building it if one cannot use it.

What do you think?
Yeah, I guess I only mentioned that in the cover letter or somewhere — I 
have written that code and tested swr.


Problem is, the topology is exposed as an XML string, so I used TinyXML2 
to parse it.
But I couldn't even figure out how to add that dependency to autotools, 
and meson doesn't build swr yet.

Also not sure if that dependency is acceptable for Mesa.
(I guess it's technically possible to use Expat, which is already a 
dependency, but ugh nope.)

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

Re: [Mesa-dev] [PATCH 01/14] util: fix ElfW macro

On 18 January 2018 at 17:59, Greg V  wrote:
> On 01/18/2018 19:57, Emil Velikov wrote:
>>
>> On 31 December 2017 at 16:55, Greg V  wrote:
>>>
>>> Elf64_Nhdr exists, Elf_Nhdr does not.
>>
>> Can you please add a typedef in FreeBSD sources, pretty please?
>
> I'm not a committer :) raised an issue in bugzilla:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225302
>
> But after it gets added, old versions of FreeBSD won't go away instantly.
> I guess we can keep the patch local to FreeBSD Ports though.

Bug reports are nice, patches are better ;-)

Please document the current patch - say add a BZ link, if you end up using it.
This way you/others will have a quick reference.

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

Re: [Mesa-dev] [PATCH] r600: enable ARB_enhanced_layouts

Looks good to me, seems like you're nearly done with gl 4.5 ;-)

Reviewed-by: Roland Scheidegger 

Am 18.01.2018 um 05:11 schrieb Dave Airlie:
> From: Dave Airlie 
> 
> Only one piglit test fails,
> sso-vs-gs-fs-array-interleave
> 
> There are 3 tests using ssbo without checking sizes failing also
> but those are test bugs.
> 
> Signed-off-by: Dave Airlie 
> ---
>  docs/features.txt| 4 ++--
>  docs/relnotes/17.4.0.html| 1 +
>  src/gallium/drivers/r600/r600_pipe.c | 2 +-
>  3 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/features.txt b/docs/features.txt
> index e9b7be5..4b2bf2c 100644
> --- a/docs/features.txt
> +++ b/docs/features.txt
> @@ -193,11 +193,11 @@ GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, nvc0, 
> radeonsi
>GL_MAX_VERTEX_ATTRIB_STRIDE   DONE (all drivers)
>GL_ARB_buffer_storage DONE (freedreno, 
> i965, nv50, r600, llvmpipe, swr)
>GL_ARB_clear_texture  DONE (i965, nv50, 
> r600, llvmpipe, softpipe, swr)
> -  GL_ARB_enhanced_layouts   DONE (i965, nv50, 
> llvmpipe, softpipe)
> +  GL_ARB_enhanced_layouts   DONE (i965, nv50, 
> r600, llvmpipe, softpipe)
>- compile-time constant expressions   DONE
>- explicit byte offsets for blocksDONE
>- forced alignment within blocks  DONE
> -  - specified vec4-slot component numbers   DONE (i965, nv50, 
> llvmpipe, softpipe)
> +  - specified vec4-slot component numbers   DONE
>- specified transform/feedback layout DONE
>- input/output block locationsDONE
>GL_ARB_multi_bind DONE (all drivers)
> diff --git a/docs/relnotes/17.4.0.html b/docs/relnotes/17.4.0.html
> index 1adbb3e..412c0fc 100644
> --- a/docs/relnotes/17.4.0.html
> +++ b/docs/relnotes/17.4.0.html
> @@ -50,6 +50,7 @@ Note: some of the new features are only available with 
> certain drivers.
>  GL_ARB_shader_storage_buffer_object on r600/evergreen+
>  GL_ARB_compute_shader on r600/evergreen+
>  GL_ARB_cull_distance on r600/evergreen+
> +GL_ARB_enhanced_layouts on r600/evergreen+
>  GL_ARB_bindless_texture on nvc0/kepler
>  OpenGL 4.3 on r600/evergreen with hw fp64 support
>  Support 1 binary format for GL_ARB_get_program_binary on i965
> diff --git a/src/gallium/drivers/r600/r600_pipe.c 
> b/src/gallium/drivers/r600/r600_pipe.c
> index c146383..e7f8ae8 100644
> --- a/src/gallium/drivers/r600/r600_pipe.c
> +++ b/src/gallium/drivers/r600/r600_pipe.c
> @@ -351,6 +351,7 @@ static int r600_get_param(struct pipe_screen* pscreen, 
> enum pipe_cap param)
>   case PIPE_CAP_SAMPLER_VIEW_TARGET:
>   case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
>   case PIPE_CAP_TGSI_CLOCK:
> + case PIPE_CAP_TGSI_ARRAY_COMPONENTS:
>   return family >= CHIP_CEDAR ? 1 : 0;
>   case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
>   return family >= CHIP_CEDAR ? 4 : 0;
> @@ -387,7 +388,6 @@ static int r600_get_param(struct pipe_screen* pscreen, 
> enum pipe_cap param)
>   case PIPE_CAP_PRIMITIVE_RESTART_FOR_PATCHES:
>   case PIPE_CAP_TGSI_VOTE:
>   case PIPE_CAP_MAX_WINDOW_RECTANGLES:
> - case PIPE_CAP_TGSI_ARRAY_COMPONENTS:
>   case PIPE_CAP_TGSI_CAN_READ_OUTPUTS:
>   case PIPE_CAP_NATIVE_FENCE_FD:
>   case PIPE_CAP_GLSL_OPTIMIZE_CONSERVATIVELY:
> 

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

Re: [Mesa-dev] [PATCH v2 3/4] meson: fix getting cflags from pkg-config

On 17 January 2018 at 20:54, Greg V  wrote:
> get_pkgconfig_variable('cflags') always returns an empty list, it's a
> function for getting *custom* variables.
>
> Meson does not yet support asking for cflags, so explicitly invoke
> pkg-config for now.
That sounds unfortunate ;-(

Is the proposed solution going to work correctly if one explicitly
asks for gallium-vdpau, yet the vdpau package is missing?

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

Re: [Mesa-dev] [PATCH v2 2/4] meson: handle LLVM 'x.x.xgit-revision' versions

On 17 January 2018 at 20:54, Greg V  wrote:
> When LLVM is built inside of a git repo (even way below, e.g. /usr/ports/.git
> exists, and LLVM is built in /usr/ports/devel/llvm50/work), its version
> becomes something like 5.0.0git-f8ab206b2176.
>
> New meson versions already handle this, but we support older versions too.
>
Crazy idea:
Using a grep-like solution analogous to autotools [1]. That will work
with old/new Meson, svn, git, plus any other suffix as LLVM devs
decide to change it.

-Emil

[1] llvm-config --version | egrep -o '^[0-9]+'
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] anv_icd.py: improve reproducible builds