Re: [Mesa-dev] [PATCH 1/7] nir: add bindless to nir data

2018-02-19 Thread Iago Toral
This patch is:

Reviewed-by: Iago Toral Quiroga 

On Tue, 2018-02-20 at 14:42 +1100, Timothy Arceri wrote:
> ---
>  src/compiler/glsl/glsl_to_nir.cpp | 1 +
>  src/compiler/nir/nir.h| 6 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/src/compiler/glsl/glsl_to_nir.cpp
> b/src/compiler/glsl/glsl_to_nir.cpp
> index 7a9d15015e..49d66c173c 100644
> --- a/src/compiler/glsl/glsl_to_nir.cpp
> +++ b/src/compiler/glsl/glsl_to_nir.cpp
> @@ -434,6 +434,7 @@ nir_visitor::visit(ir_variable *ir)
> var->data.index = ir->data.index;
> var->data.descriptor_set = 0;
> var->data.binding = ir->data.binding;
> +   var->data.bindless = ir->data.bindless;
> var->data.offset = ir->data.offset;
> var->data.image.read_only = ir->data.memory_read_only;
> var->data.image.write_only = ir->data.memory_write_only;
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 2acd9511f5..c6541f0a6f 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -249,6 +249,12 @@ typedef struct nir_variable {
> */
>unsigned fb_fetch_output:1;
>  
> +  /**
> +   * Non-zero if this variable is considered bindless as defined
> by
> +   * ARB_bindless_texture.
> +   */
> +  unsigned bindless:1;
> +
>/**
> * \brief Layout qualifier for gl_FragDepth.
> *
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] glsl: Parse 'layout' as a token with advanced blending or bindless

2018-02-19 Thread Iago Toral
Reviewed-by: Iago Toral Quiroga 

On Mon, 2018-02-19 at 21:28 -0800, Kenneth Graunke wrote:
> Both KHR_blend_equation_advanced and ARB_bindless_texture provide
> layout qualifiers, and are exposed in compatibility contexts.  We
> need to parse the layout qualifier as a token in order for those
> to work, but forgot to extend this check.
> 
> ARB_shader_image_load_store would need a similar treatment, but we
> don't expose that in legacy OpenGL contexts.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105161
> ---
>  src/compiler/glsl/glsl_lexer.ll | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/compiler/glsl/glsl_lexer.ll
> b/src/compiler/glsl/glsl_lexer.ll
> index 4b36574b73a..ed7a80a2bb1 100644
> --- a/src/compiler/glsl/glsl_lexer.ll
> +++ b/src/compiler/glsl/glsl_lexer.ll
> @@ -491,6 +491,8 @@ void  return VOID_TOK;
>  
>  layout   {
> if ((yyextra->is_version(140, 300))
> +   || yyextra->ARB_bindless_texture_enable
> +   || yyextra->KHR_blend_equation_advanced_enable
> || yyextra->AMD_conservative_depth_enable
> || yyextra->ARB_conservative_depth_enable
> || yyextra-
> >ARB_explicit_attrib_location_enable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] configure.ac: pthread-stubs not present on OpenBSD

2018-02-19 Thread Jonathan Gray
pthread-stubs is no longer required on OpenBSD and has been removed.
libpthread parts involved moved to libc.

Signed-off-by: Jonathan Gray 
Cc: 17.3 18.0 
---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 89c5e74127..30a3377582 100644
--- a/configure.ac
+++ b/configure.ac
@@ -967,10 +967,10 @@ dnl In practise that should be sufficient for all 
platforms, since any
 dnl platforms build with GCC and Clang support the flag.
 PTHREAD_LIBS="$PTHREAD_LIBS -pthread"
 
-dnl pthread-stubs is mandatory on BSD platforms, due to the nature of the
+dnl pthread-stubs is mandatory on some BSD platforms, due to the nature of the
 dnl project. Even then there's a notable issue as described in the project 
README
 case "$host_os" in
-linux* | cygwin* | darwin* | solaris* | *-gnu* | gnu*)
+linux* | cygwin* | darwin* | solaris* | *-gnu* | gnu* | openbsd*)
 pthread_stubs_possible="no"
 ;;
 * )
-- 
2.16.0

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


[Mesa-dev] [PATCH 2/5] ac/radv: remove total_vertices variable

2018-02-19 Thread Dave Airlie
From: Dave Airlie 

This just removes an unneeded variable.

Signed-off-by: Dave Airlie 
---
 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 31cab3b..d0394d3 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2769,14 +2769,12 @@ static LLVMValueRef get_tcs_tes_buffer_address(struct 
radv_shader_context *ctx,
LLVMValueRef vertex_index,
LLVMValueRef param_index)
 {
-   LLVMValueRef base_addr, vertices_per_patch, num_patches, total_vertices;
+   LLVMValueRef base_addr, vertices_per_patch, num_patches;
LLVMValueRef param_stride, constant16;
LLVMValueRef rel_patch_id = get_rel_patch_id(ctx);
 
vertices_per_patch = unpack_param(>ac, ctx->tcs_offchip_layout, 9, 
6);
num_patches = unpack_param(>ac, ctx->tcs_offchip_layout, 0, 9);
-   total_vertices = LLVMBuildMul(ctx->ac.builder, vertices_per_patch,
- num_patches, "");
 
constant16 = LLVMConstInt(ctx->ac.i32, 16, false);
if (vertex_index) {
@@ -2786,7 +2784,8 @@ static LLVMValueRef get_tcs_tes_buffer_address(struct 
radv_shader_context *ctx,
base_addr = LLVMBuildAdd(ctx->ac.builder, base_addr,
 vertex_index, "");
 
-   param_stride = total_vertices;
+   param_stride = LLVMBuildMul(ctx->ac.builder, vertices_per_patch,
+   num_patches, "");
} else {
base_addr = rel_patch_id;
param_stride = num_patches;
-- 
2.9.5

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


[Mesa-dev] [PATCH 6/7] radeonsi/nir: add initial bindless image support

2018-02-19 Thread Timothy Arceri
---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 41 +++-
 1 file changed, 34 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index c2036a1509..e3e71c6eb6 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -771,6 +771,21 @@ si_nir_lookup_interp_param(struct ac_shader_abi *abi,
LLVMGetParam(ctx->main_fn, interp_param_idx) : NULL;
 }
 
+static LLVMValueRef
+get_bindless_index(struct ac_shader_abi *abi,
+   struct si_shader_context *ctx, LLVMValueRef index)
+{
+   LLVMValueRef offset =
+   LLVMBuildMul(ctx->ac.builder, index, LLVMConstInt(ctx->i32, 16, 
0), "");
+
+   index = abi->load_ubo(abi, ctx->ac.i32_0);
+
+   LLVMValueRef ret = ac_build_buffer_load(>ac, index, 1, NULL, 
offset,
+   NULL, 0, false, false, true, 
true);
+
+   return LLVMBuildBitCast(ctx->ac.builder, ret, ctx->i32, "");
+}
+
 static LLVMValueRef
 si_nir_load_sampler_desc(struct ac_shader_abi *abi,
 unsigned descriptor_set, unsigned base_index,
@@ -780,8 +795,10 @@ si_nir_load_sampler_desc(struct ac_shader_abi *abi,
 {
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
LLVMBuilderRef builder = ctx->ac.builder;
-   LLVMValueRef list = LLVMGetParam(ctx->main_fn, 
ctx->param_samplers_and_images);
LLVMValueRef index = dynamic_index;
+   LLVMValueRef list = bindless ?
+   LLVMGetParam(ctx->main_fn, 
ctx->param_bindless_samplers_and_images) :
+   LLVMGetParam(ctx->main_fn, ctx->param_samplers_and_images);
 
assert(!descriptor_set);
 
@@ -794,14 +811,24 @@ si_nir_load_sampler_desc(struct ac_shader_abi *abi,
 
if (image) {
assert(desc_type == AC_DESC_IMAGE || desc_type == 
AC_DESC_BUFFER);
-   assert(base_index + constant_index < ctx->num_images);
 
-   if (dynamic_index)
-   index = si_llvm_bound_index(ctx, index, 
ctx->num_images);
+   if (bindless) {
+   LLVMValueRef ret = get_bindless_index(abi, ctx, index);
 
-   index = LLVMBuildSub(ctx->gallivm.builder,
-LLVMConstInt(ctx->i32, SI_NUM_IMAGES - 1, 
0),
-index, "");
+   /* For simplicity, bindless image descriptors use fixed
+* 16-dword slots for now.
+*/
+   index = LLVMBuildMul(ctx->ac.builder, ret,
+LLVMConstInt(ctx->i32, 2, 0), "");
+   } else {
+   assert(base_index + constant_index < ctx->num_images);
+   if (dynamic_index)
+   index = si_llvm_bound_index(ctx, index, 
ctx->num_images);
+
+   index = LLVMBuildSub(ctx->gallivm.builder,
+LLVMConstInt(ctx->i32, 
SI_NUM_IMAGES - 1, 0),
+index, "");
+   }
 
/* TODO: be smarter about when we use dcc_off */
return si_load_image_desc(ctx, list, index, desc_type, write);
-- 
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/3] meson: Only GLX_USE_TLS when glx is in use

2018-02-19 Thread Alexander von Gluck IV
February 19, 2018 3:00 PM, "Emil Velikov"  wrote:

> On 19 February 2018 at 18:40, Alexander von Gluck IV
>> Thanks to Dylan for figuring this one out.
>> 
>> This was discussed previously on the ML
>> "
>> This can be applied to all GLX implementations, and in autotools this is
>> guarded only by the --enable-glx-tls flag. Since this is on by default
>> in autotools, and is strictly better than being off, the meson build
>> doesn't even have a toggle for it.
>> "
>> 
>> Since the GLX_USE_TLS reaches beyond GLX, i'm guarding it with_glx after
>> the glx auto-detection tri-state (which can disable it)
> 
> Note: the GLX in the name is for historical purposes - toggle applies
> to glapi and the way one (GLX, EGL and DRI modules in particular)
> makes use of it.
> 
> That said - we had serious issues with people tinkering with the
> toggle, so Dylan's decision of omit it is spot on.
> For Haiku, I would suggest the following:
> - open a bug/other issue about the missing static TLS support
> - set the macro for non-haiku platforms, with a clear reference to
> the above report.

Ah. Yup, just found an enhancement for it:
https://dev.haiku-os.org/ticket/13294

I'll adjust to be a Haiku check and notate that ticket.

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


[Mesa-dev] [PATCH 5/7] ac/radeonsi: pass bindless bool to load_sampler_desc()

2018-02-19 Thread Timothy Arceri
We also fix the base_index for bindless by using the driver
location.
---
 src/amd/common/ac_nir_to_llvm.c  | 14 +++---
 src/amd/common/ac_shader_abi.h   |  3 ++-
 src/gallium/drivers/radeonsi/si_shader_nir.c |  2 +-
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index fc89779c12..9f55be0d45 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -4664,7 +4664,8 @@ static LLVMValueRef radv_get_sampler_desc(struct 
ac_shader_abi *abi,
  unsigned constant_index,
  LLVMValueRef index,
  enum ac_descriptor_type desc_type,
- bool image, bool write)
+ bool image, bool write,
+ bool bindless)
 {
struct radv_shader_context *ctx = radv_shader_context_from_abi(abi);
LLVMValueRef list = ctx->descriptor_sets[descriptor_set];
@@ -4744,6 +4745,7 @@ static LLVMValueRef get_sampler_desc(struct 
ac_nir_context *ctx,
unsigned constant_index = 0;
unsigned descriptor_set;
unsigned base_index;
+   bool bindless = false;
 
if (!deref) {
assert(tex_instr && !image);
@@ -4777,14 +4779,20 @@ static LLVMValueRef get_sampler_desc(struct 
ac_nir_context *ctx,
tail = >deref;
}
descriptor_set = deref->var->data.descriptor_set;
-   base_index = deref->var->data.binding;
+
+   if (deref->var->data.bindless) {
+   bindless = deref->var->data.bindless;
+   base_index = deref->var->data.driver_location;
+   } else {
+   base_index = deref->var->data.binding;
+   }
}
 
return ctx->abi->load_sampler_desc(ctx->abi,
  descriptor_set,
  base_index,
  constant_index, index,
- desc_type, image, write);
+ desc_type, image, write, bindless);
 }
 
 static void set_tex_fetch_args(struct ac_llvm_context *ctx,
diff --git a/src/amd/common/ac_shader_abi.h b/src/amd/common/ac_shader_abi.h
index 62b8b7a5dc..de3034e32f 100644
--- a/src/amd/common/ac_shader_abi.h
+++ b/src/amd/common/ac_shader_abi.h
@@ -156,7 +156,8 @@ struct ac_shader_abi {
  unsigned constant_index,
  LLVMValueRef index,
  enum ac_descriptor_type desc_type,
- bool image, bool write);
+ bool image, bool write,
+ bool bindless);
 
/**
 * Load a Vulkan-specific resource.
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 7a5acd3ff1..c2036a1509 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -776,7 +776,7 @@ si_nir_load_sampler_desc(struct ac_shader_abi *abi,
 unsigned descriptor_set, unsigned base_index,
 unsigned constant_index, LLVMValueRef dynamic_index,
 enum ac_descriptor_type desc_type, bool image,
-bool write)
+bool write, bool bindless)
 {
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
LLVMBuilderRef builder = ctx->ac.builder;
-- 
2.14.3

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


[Mesa-dev] radv prep for removing tess specific user sgprs

2018-02-19 Thread Dave Airlie
These are just some cleanups that popped out of a series I was working
on to remove all the tcs/tes user sgprs stuff.

I've got the full patchset working on VI, just need to test on Vega now.

Dave.

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


[Mesa-dev] [PATCH 4/5] radv/tess: don't need to look in constant for vertices_per_patch

2018-02-19 Thread Dave Airlie
From: Dave Airlie 

This just avoids passing this value via user sgprs.

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

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 611bde4..9839f1c 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -127,6 +127,7 @@ struct radv_shader_context {
 
uint32_t tcs_patch_outputs_read;
uint64_t tcs_outputs_read;
+   uint32_t tcs_vertices_per_patch;
 };
 
 static inline struct radv_shader_context *
@@ -2779,7 +2780,7 @@ static LLVMValueRef get_tcs_tes_buffer_address(struct 
radv_shader_context *ctx,
LLVMValueRef param_stride, constant16;
LLVMValueRef rel_patch_id = get_rel_patch_id(ctx);
 
-   vertices_per_patch = unpack_param(>ac, ctx->tcs_offchip_layout, 9, 
6);
+   vertices_per_patch = LLVMConstInt(ctx->ac.i32, 
ctx->tcs_vertices_per_patch, false);
num_patches = unpack_param(>ac, ctx->tcs_offchip_layout, 0, 9);
 
constant16 = LLVMConstInt(ctx->ac.i32, 16, false);
@@ -6903,11 +6904,13 @@ LLVMModuleRef 
ac_translate_nir_to_llvm(LLVMTargetMachineRef tm,
ctx.abi.load_tess_varyings = load_tcs_varyings;
ctx.abi.load_patch_vertices_in = load_patch_vertices_in;
ctx.abi.store_tcs_outputs = store_tcs_output;
+   ctx.tcs_vertices_per_patch = 
shaders[i]->info.tess.tcs_vertices_out;
} else if (shaders[i]->info.stage == MESA_SHADER_TESS_EVAL) {
ctx.tes_primitive_mode = 
shaders[i]->info.tess.primitive_mode;
ctx.abi.load_tess_varyings = load_tes_input;
ctx.abi.load_tess_coord = load_tess_coord;
ctx.abi.load_patch_vertices_in = load_patch_vertices_in;
+   ctx.tcs_vertices_per_patch = 
shaders[i]->info.tess.tcs_vertices_out;
} else if (shaders[i]->info.stage == MESA_SHADER_VERTEX) {
if (shader_info->info.vs.needs_instance_id) {
if (ctx.options->key.vs.as_ls) {
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 88646fd..a2dec0e 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1391,7 +1391,7 @@ calculate_tess_state(struct radv_pipeline *pipeline,
tess.tcs_out_offsets = (output_patch0_offset / 16) |
((perpatch_output_offset / 16) << 16);
tess.offchip_layout = (pervertex_output_patch_size * num_patches << 16) 
|
-   (num_tcs_output_cp << 9) | num_patches;
+   num_patches;
 
tess.ls_hs_config = S_028B58_NUM_PATCHES(num_patches) |
S_028B58_HS_NUM_INPUT_CP(num_tcs_input_cp) |
-- 
2.9.5

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


[Mesa-dev] [PATCH] ac/nir: to integer the args to bcsel.

2018-02-19 Thread Dave Airlie
From: Dave Airlie 

dEQP-VK.tessellation.invariance.outer_edge_symmetry.triangles_equal_spacing_ccw
was hitting an llvm assert due to one value being an int and the
other a float.

This just casts both values to integer and fixes the test.

Fixes: 
dEQP-VK.tessellation.invariance.outer_edge_symmetry.triangles_equal_spacing_ccw
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Dave Airlie 
---
 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 dc471de..8906418 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1312,7 +1312,8 @@ static LLVMValueRef emit_bcsel(struct ac_llvm_context 
*ctx,
 {
LLVMValueRef v = LLVMBuildICmp(ctx->builder, LLVMIntNE, src0,
   ctx->i32_0, "");
-   return LLVMBuildSelect(ctx->builder, v, src1, src2, "");
+   return LLVMBuildSelect(ctx->builder, v, ac_to_integer(ctx, src1),
+  ac_to_integer(ctx, src2), "");
 }
 
 static LLVMValueRef emit_minmax_int(struct ac_llvm_context *ctx,
-- 
2.9.5

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


[Mesa-dev] [PATCH 5/5] radv: don't send num_tcs_input_cp to sgprs.

2018-02-19 Thread Dave Airlie
From: Dave Airlie 

We never use it in the shaders.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_pipeline.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index a2dec0e..9990a3e 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -68,7 +68,6 @@ struct radv_tessellation_state {
uint32_t offchip_layout;
unsigned num_patches;
unsigned lds_size;
-   unsigned num_tcs_input_cp;
uint32_t tf_param;
 };
 
@@ -1397,7 +1396,6 @@ calculate_tess_state(struct radv_pipeline *pipeline,
S_028B58_HS_NUM_INPUT_CP(num_tcs_input_cp) |
S_028B58_HS_NUM_OUTPUT_CP(num_tcs_output_cp);
tess.num_patches = num_patches;
-   tess.num_tcs_input_cp = num_tcs_input_cp;
 
struct radv_shader_variant *tes = radv_get_tess_eval_shader(pipeline);
unsigned type = 0, partitioning = 0, topology = 0, distribution_mode = 
0;
@@ -2621,8 +2619,7 @@ radv_pipeline_generate_tess_shaders(struct 
radeon_winsys_cs *cs,
radeon_set_sh_reg_seq(cs, base_reg + loc->sgpr_idx * 4, 4);
radeon_emit(cs, tess->offchip_layout);
radeon_emit(cs, tess->tcs_out_offsets);
-   radeon_emit(cs, tess->tcs_out_layout |
-   tess->num_tcs_input_cp << 26);
+   radeon_emit(cs, tess->tcs_out_layout);
radeon_emit(cs, tess->tcs_in_layout);
}
 
-- 
2.9.5

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


[Mesa-dev] [PATCH 3/5] ac/radv: cleanup some tcs output values access

2018-02-19 Thread Dave Airlie
From: Dave Airlie 

Just consolidates some code to make it easier to change.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 10 --
 1 file 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 d0394d3..611bde4 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -383,6 +383,12 @@ get_tcs_out_patch_stride(struct radv_shader_context *ctx)
 }
 
 static LLVMValueRef
+get_tcs_out_vertex_stride(struct radv_shader_context *ctx)
+{
+   return unpack_param(>ac, ctx->tcs_out_layout, 13, 8);
+}
+
+static LLVMValueRef
 get_tcs_out_patch0_offset(struct radv_shader_context *ctx)
 {
return LLVMBuildMul(ctx->ac.builder,
@@ -2897,7 +2903,7 @@ load_tcs_varyings(struct ac_shader_abi *abi,
dw_addr = get_tcs_in_current_patch_offset(ctx);
} else {
if (!is_patch) {
-   stride = unpack_param(>ac, ctx->tcs_out_layout, 
13, 8);
+   stride = get_tcs_out_vertex_stride(ctx);
dw_addr = get_tcs_out_current_patch_offset(ctx);
} else {
dw_addr = get_tcs_out_current_patch_data_offset(ctx);
@@ -2953,7 +2959,7 @@ store_tcs_output(struct ac_shader_abi *abi,
}
 
if (!is_patch) {
-   stride = unpack_param(>ac, ctx->tcs_out_layout, 13, 8);
+   stride = get_tcs_out_vertex_stride(ctx);
dw_addr = get_tcs_out_current_patch_offset(ctx);
} else {
dw_addr = get_tcs_out_current_patch_data_offset(ctx);
-- 
2.9.5

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


[Mesa-dev] [PATCH] glsl: Parse 'layout' as a token with advanced blending or bindless

2018-02-19 Thread Kenneth Graunke
Both KHR_blend_equation_advanced and ARB_bindless_texture provide
layout qualifiers, and are exposed in compatibility contexts.  We
need to parse the layout qualifier as a token in order for those
to work, but forgot to extend this check.

ARB_shader_image_load_store would need a similar treatment, but we
don't expose that in legacy OpenGL contexts.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105161
---
 src/compiler/glsl/glsl_lexer.ll | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compiler/glsl/glsl_lexer.ll b/src/compiler/glsl/glsl_lexer.ll
index 4b36574b73a..ed7a80a2bb1 100644
--- a/src/compiler/glsl/glsl_lexer.ll
+++ b/src/compiler/glsl/glsl_lexer.ll
@@ -491,6 +491,8 @@ voidreturn VOID_TOK;
 
 layout {
  if ((yyextra->is_version(140, 300))
+ || yyextra->ARB_bindless_texture_enable
+ || yyextra->KHR_blend_equation_advanced_enable
  || yyextra->AMD_conservative_depth_enable
  || yyextra->ARB_conservative_depth_enable
  || yyextra->ARB_explicit_attrib_location_enable
-- 
2.16.1

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


[Mesa-dev] [PATCH 4/7] st/glsl_to_nir: set driver location for bindless images and samplers

2018-02-19 Thread Timothy Arceri
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 760aee1af6..47f369a889 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -241,7 +241,8 @@ st_nir_assign_uniform_locations(struct gl_program *prog,
   uniform->interface_type != NULL)
  continue;
 
-  if (uniform->type->is_sampler() || uniform->type->is_image()) {
+  if (!uniform->data.bindless &&
+  (uniform->type->is_sampler() || uniform->type->is_image())) {
  if (uniform->type->is_sampler())
 loc = shaderidx++;
  else
-- 
2.14.3

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


[Mesa-dev] [PATCH 7/7] radeonsi/nir: add initial bindless sampler support

2018-02-19 Thread Timothy Arceri
---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index e3e71c6eb6..3294019cea 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -834,13 +834,16 @@ si_nir_load_sampler_desc(struct ac_shader_abi *abi,
return si_load_image_desc(ctx, list, index, desc_type, write);
}
 
-   assert(base_index + constant_index < ctx->num_samplers);
-
-   if (dynamic_index)
-   index = si_llvm_bound_index(ctx, index, ctx->num_samplers);
-
-   index = LLVMBuildAdd(ctx->gallivm.builder, index,
-LLVMConstInt(ctx->i32, SI_NUM_IMAGES / 2, 0), "");
+   if (bindless) {
+   index = get_bindless_index(abi, ctx, index);
+   } else {
+   assert(base_index + constant_index < ctx->num_samplers);
+   if (dynamic_index)
+   index = si_llvm_bound_index(ctx, index, 
ctx->num_samplers);
+
+   index = LLVMBuildAdd(ctx->gallivm.builder, index,
+LLVMConstInt(ctx->i32, SI_NUM_IMAGES / 2, 
0), "");
+   }
 
return si_load_sampler_desc(ctx, list, index, desc_type);
 }
-- 
2.14.3

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


[Mesa-dev] [PATCH 2/7] radeonsi/nir: set uses_bindless_images for images

2018-02-19 Thread Timothy Arceri
---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index ea9f2076da..974068b88f 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -134,7 +134,11 @@ static void scan_instruction(struct tgsi_shader_info *info,
case nir_intrinsic_image_atomic_or:
case nir_intrinsic_image_atomic_xor:
case nir_intrinsic_image_atomic_exchange:
-   case nir_intrinsic_image_atomic_comp_swap:
+   case nir_intrinsic_image_atomic_comp_swap: {
+   nir_variable *var = intr->variables[0]->var;
+   if (var->data.bindless)
+   info->uses_bindless_images = true;
+   }
case nir_intrinsic_store_ssbo:
case nir_intrinsic_ssbo_atomic_add:
case nir_intrinsic_ssbo_atomic_imin:
-- 
2.14.3

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


[Mesa-dev] [PATCH 1/7] nir: add bindless to nir data

2018-02-19 Thread Timothy Arceri
---
 src/compiler/glsl/glsl_to_nir.cpp | 1 +
 src/compiler/nir/nir.h| 6 ++
 2 files changed, 7 insertions(+)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index 7a9d15015e..49d66c173c 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -434,6 +434,7 @@ nir_visitor::visit(ir_variable *ir)
var->data.index = ir->data.index;
var->data.descriptor_set = 0;
var->data.binding = ir->data.binding;
+   var->data.bindless = ir->data.bindless;
var->data.offset = ir->data.offset;
var->data.image.read_only = ir->data.memory_read_only;
var->data.image.write_only = ir->data.memory_write_only;
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 2acd9511f5..c6541f0a6f 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -249,6 +249,12 @@ typedef struct nir_variable {
*/
   unsigned fb_fetch_output:1;
 
+  /**
+   * Non-zero if this variable is considered bindless as defined by
+   * ARB_bindless_texture.
+   */
+  unsigned bindless:1;
+
   /**
* \brief Layout qualifier for gl_FragDepth.
*
-- 
2.14.3

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


[Mesa-dev] [PATCH 3/7] radeonsi/nir: set uses_bindless_samplers for samplers

2018-02-19 Thread Timothy Arceri
---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 974068b88f..7a5acd3ff1 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -62,6 +62,9 @@ static void scan_instruction(struct tgsi_shader_info *info,
if (!tex->texture) {
info->samplers_declared |=
u_bit_consecutive(tex->sampler_index, 1);
+   } else {
+   if (tex->texture->var->data.bindless)
+   info->uses_bindless_samplers = true;
}
 
switch (tex->op) {
-- 
2.14.3

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


[Mesa-dev] [PATCH 1/5] ac/radv: don't mark tess inner as used if we don't use it.

2018-02-19 Thread Dave Airlie
From: Dave Airlie 

This just avoids marking it as a used output if we don't
actually use it.

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

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 8906418..31cab3b 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -6358,8 +6358,8 @@ write_tess_factors(struct radv_shader_context *ctx)
struct ac_build_if_state if_ctx, inner_if_ctx;
LLVMValueRef invocation_id = unpack_param(>ac, 
ctx->abi.tcs_rel_ids, 8, 5);
LLVMValueRef rel_patch_id = unpack_param(>ac, 
ctx->abi.tcs_rel_ids, 0, 8);
-   unsigned tess_inner_index, tess_outer_index;
-   LLVMValueRef lds_base, lds_inner, lds_outer, byteoffset, buffer;
+   unsigned tess_inner_index = 0, tess_outer_index;
+   LLVMValueRef lds_base, lds_inner = NULL, lds_outer, byteoffset, buffer;
LLVMValueRef out[6], vec0, vec1, tf_base, inner[4], outer[4];
int i;
emit_barrier(>ac, ctx->stage);
@@ -6388,14 +6388,17 @@ write_tess_factors(struct radv_shader_context *ctx)
LLVMBuildICmp(ctx->ac.builder, LLVMIntEQ,
  invocation_id, ctx->ac.i32_0, ""));
 
-   tess_inner_index = 
shader_io_get_unique_index(VARYING_SLOT_TESS_LEVEL_INNER);
-   tess_outer_index = 
shader_io_get_unique_index(VARYING_SLOT_TESS_LEVEL_OUTER);
+   lds_base = get_tcs_out_current_patch_data_offset(ctx);
+
+   if (inner_comps) {
+   tess_inner_index = 
shader_io_get_unique_index(VARYING_SLOT_TESS_LEVEL_INNER);
+   mark_tess_output(ctx, true, tess_inner_index);
+   lds_inner = LLVMBuildAdd(ctx->ac.builder, lds_base,
+LLVMConstInt(ctx->ac.i32, 
tess_inner_index * 4, false), "");
+   }
 
-   mark_tess_output(ctx, true, tess_inner_index);
+   tess_outer_index = 
shader_io_get_unique_index(VARYING_SLOT_TESS_LEVEL_OUTER);
mark_tess_output(ctx, true, tess_outer_index);
-   lds_base = get_tcs_out_current_patch_data_offset(ctx);
-   lds_inner = LLVMBuildAdd(ctx->ac.builder, lds_base,
-LLVMConstInt(ctx->ac.i32, tess_inner_index * 
4, false), "");
lds_outer = LLVMBuildAdd(ctx->ac.builder, lds_base,
 LLVMConstInt(ctx->ac.i32, tess_outer_index * 
4, false), "");
 
-- 
2.9.5

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


Re: [Mesa-dev] clover: Fix build after llvm r325155 and r325160

2018-02-19 Thread Jan Vesely
On Fri, 2018-02-16 at 05:49 +0100, Dieter Nützel wrote:
> Hello Jan,
> 
> something semilar is needed fro libclc, too.
> 
> LLVM-CC nvptx64--nvidiacl/lib/geometric/dot.cl.bc
> ./utils/prepare-builtins.cpp:108:3: error: no matching function for call 
> to 'WriteBitcodeToFile'
>WriteBitcodeToFile(M, Out->os());
>^~
> /usr/local/include/llvm/Bitcode/BitcodeWriter.h:129:8: note: candidate 
> function not viable: no known
>conversion from 'llvm::Module *' to 'const llvm::Module' for 1st 
> argument; dereference the
>argument with *
>void WriteBitcodeToFile(const Module , raw_ostream ,
> ^

patch is now posted at:
https://lists.llvm.org/pipermail/libclc-dev/2018-February/002800.html

Jan

> 
> Greetings,
> Dieter


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] [ANNOUNCE] mesa 17.3.5

2018-02-19 Thread Emil Velikov
Mesa 17.3.5 is now available.

This is a emergency release fixing major a issue in the RADV driver.


Emil Velikov (3):
  docs: add sha256 checksums for 17.3.4
  Update version to 17.3.5
  docs: add release notes for 17.3.5

James Legg (1):
  ac/nir: Fix conflict resolution typo in handle_vs_input_decl

git tag: mesa-17.3.5

https://mesa.freedesktop.org/archive/mesa-17.3.5.tar.gz
MD5:  a7a624fa35cb97b96187e7f9be6483fa  mesa-17.3.5.tar.gz
SHA1: 24067122461772872a15eb71f3fe989a8d505646  mesa-17.3.5.tar.gz
SHA256: bc1ee20366aae2affc37c89228f871f438136f70252005e9f842169bde976788
 mesa-17.3.5.tar.gz
SHA512: 
85f2e779b3684c0e63c411c4209ac986b5fe5b1bf279f5da14213ab3ccadf561cc7389369bcfe178daea89bee7307215a0257ea85194fb05f7d580f70ec35b65
 mesa-17.3.5.tar.gz
PGP:  https://mesa.freedesktop.org/archive/mesa-17.3.5.tar.gz.sig

https://mesa.freedesktop.org/archive/mesa-17.3.5.tar.xz
MD5:  bf73288c33cf12abe62045c25e2196b4  mesa-17.3.5.tar.xz
SHA1: 5168471ad19945a2f76a14c842b8273e4c29aba4  mesa-17.3.5.tar.xz
SHA256: eb9228fc8aaa71e0205c1481c5b157752ebaec9b646b030d27478e25a6d7936a
 mesa-17.3.5.tar.xz
SHA512: 
39ada2480aa12c42bbff6a1b5c957f99934193d19eb5f44e102ef8302d26f777cee63af1140aa8623bbc1ebd6d69e172cecca798780b8eb594f2ebbb217afd29
 mesa-17.3.5.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-17.3.5.tar.xz.sig
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [AppVeyor] mesa 17.3 #6956 completed

2018-02-19 Thread AppVeyor


Build mesa 6956 completed



Commit 2529d77179 by Emil Velikov on 2/19/2018 10:01 PM:

docs: add release notes for 17.3.5\n\nSigned-off-by: Emil Velikov 


Configure your notification preferences

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


Re: [Mesa-dev] [ANNOUNCE] mesa 17.3.4

2018-02-19 Thread Bas Nieuwenhuizen
On Mon, Feb 19, 2018 at 6:28 PM, Emil Velikov  wrote:
> On 17 February 2018 at 15:04, Bas Nieuwenhuizen  
> wrote:
>> (-mesa-announce + Mark, Dave and James)
>>
>> Hi Emil,
>>
>> radv is broken for nearly all commercial games in 17.3.4. The cause is
>>
>> commit ad764e365beb8a119369b97f5cb95fc7ea8c
>> Author: Bas Nieuwenhuizen 
>> Date:   Mon Jan 22 09:01:29 2018 +0100
>>
>> ac/nir: Use instance_rate_inputs per attribute, not per variable.
>>
>> This did the wrong thing if we had e.g. an array for which only some
>> of the attributes use the instance index. Tripped up some new CTS
>> tests.
>>
>> CC: 
>> Reviewed-by: Samuel Pitoiset 
>> Reviewed-by: Dave Airlie 
>> (cherry picked from commit 5a4dc285002e1924dbc8c72d17481a3dbc4c0142)
>>
>> Conflicts:
>> src/amd/common/ac_nir_to_llvm.c
>>
>> A typo was introduced during the conflict resolution while
>> cherrypicking to 17.3.
>>
>> First things first, can we mitigate this? Would it be possible to get
>> a 17.3.5 with this fixed ASAP? This can be fixed by either rolling
>> back ad764e365beb8a119369b97f5cb95fc7ea8c or by applying
>> https://patchwork.freedesktop.org/patch/204260/ (obviously not applied
>> to master as the issue did not occur there).
>>
> I'll do a 17.3.5 momentarily, including only the above fix.
>
>> Secondly, I'd like to talk about process and how to prevent this in
>> the future. Bugfix releases are supposed to be stable so downstream
>> maintainers don't have to to deal with this kind of stuff happening,
>> so I think that breaking radv pretty much completely is particularly
>> egregious and we should look at how to prevent this happnening another
>> time.
>>
> Sadly James' fix went below the radar since:
>  - it wasn't merged in master - understandably so
>  - I mistook his reply as some lovely emails that mesa-announce is
> throwing at me
>
> A few things come to mind:
>  - on my end - resolve the mesa-announce noise, ensure replies are highlighted
>  - having regular reply [to the RC email] with negative and positive
> testing results will be great

Thanks, I'll work on getting the release candidates tested in a timely
manner and making sure we send these replies from the radv side.

>  - wire up some Vulkan games into the LunarG*/other test rig
>
> I've been going through * since it's inception, as the only means of
> checking non Intel hardware.
>
> -Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Adding a SPIR-V target to libclc

2018-02-19 Thread Jan Vesely
On Thu, 2018-02-15 at 22:50 -0800, Francisco Jerez wrote:
> Jan Vesely  writes:
> 
> > On Thu, 2018-02-15 at 20:36 -0800, Francisco Jerez wrote:
> > > Jan Vesely  writes:
> > > 
> > > > On Thu, 2018-02-08 at 15:56 -0800, Francisco Jerez wrote:
> > > > > Jan Vesely  writes:
> > > > > 
> > > > > > On Thu, 2018-02-08 at 23:16 +0100, Pierre Moreau wrote:
> > > > > > > (Moving the conversation to its own thread.)
> > > > > > > 
> > > > > > > > target agnostic libclc is rather difficult to do. CLC includes 
> > > > > > > > 3 levels
> > > > > > > > of precision on float (fp32) operands; full, half, native. The
> > > > > > > > implementation of each depends on capabilites of specific 
> > > > > > > > device (e.g.
> > > > > > > > vega(VI+?) can do 1 ULP log2/exp2 in hw, other targets need sw
> > > > > > > > implementation to meet CLC requirement of 3ulp). Any conversion 
> > > > > > > > backend
> > > > > > > > would thus need to implement sw versions of math builtins for 
> > > > > > > > targets
> > > > > > > > that can't perform the op in HW.
> > > > > > > 
> > > > > > > My initial thought for the target agnostic libclc, was to just 
> > > > > > > provide some
> > > > > > > (fake?) implementations of OpenCL built-in functions to make 
> > > > > > > clang happy and
> > > > > > > let me compile kernels using “get_global_id()”, as well as 
> > > > > > > include headers
> > > > > > > defining OpenCL specific types like “float4” or others. If there 
> > > > > > > is another
> > > > > > > (better?) way to achieve this, I am all ears. (There is probably 
> > > > > > > one, as I had
> > > > > > > no issues when using the Khronos LLVM/clang fork rather than 
> > > > > > > Tomeu’s
> > > > > > > out-of-tree module, the former having also some bits and pieces 
> > > > > > > in clang.)
> > > > > > 
> > > > > > I don't think you need libclc for this. workitem IDs are
> > > > > > platform/device specific, and iiuc SPIR-V builtins should handle it 
> > > > > > in
> > > > > > an abstract way [0]. any conversion consuming SPIR-V needs to 
> > > > > > replace
> > > > > > those with device/platform specific way of obtaining the 
> > > > > > information.
> > > > > > you can also use clang's clc header to provide data types [1].
> > > > > > 
> > > > > > 
> > > > > > [0] 
> > > > > > https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#B
> > > > > > uiltIn
> > > > > > [1] 
> > > > > > https://github.com/llvm-mirror/clang/blob/master/lib/Headers/opencl
> > > > > > -c.h
> > > > > > 
> > > > > > > 
> > > > > > > > Extending the current libclc to provide target specific SPIR-V 
> > > > > > > > binaries
> > > > > > > > in addition to/in place of LLVM IR is rather straightforward. 
> > > > > > > > Adding
> > > > > > > > additional targets it's more work since it relies on clang to 
> > > > > > > > support
> > > > > > > > those targets.
> > > > > > > 
> > > > > > > I’m curious how those target specific SPIR-V binaries would look 
> > > > > > > like. I can
> > > > > > > imagine how some functions like “OpSign” could be implemented 
> > > > > > > using other
> > > > > > > SPIR-V functions, but how would you handle something like 
> > > > > > > “get_local_id()”? If
> > > > > > > you define it as the built-in “LocalInvocationId” and don’t 
> > > > > > > supply an
> > > > > > > implementation of it, then you lose the target specificness. On 
> > > > > > > the other hand,
> > > > > > > if you want to keep it device-specific, how would you express 
> > > > > > > that in SPIR-V?
> > > > > > 
> > > > > > getting IDs is not a problem. SPIR-V should provide builtins for 
> > > > > > that.
> > > > > > 
> > > > > > The problem I had in mind is when SPIR-V binary calls e.g. exp2(). 
> > > > > > You
> > > > > > can either assume that the op needs CLC precision (3 ulp), or device
> > > > > > native precision.
> > > > > 
> > > > > That's up to the SPIR-V extended instruction set specification to 
> > > > > define
> > > > > what precision the exp2 built-in is supposed to have.  
> > > > > 
> > > > > > SPIR-V binary can also call exp2(fp64), which does not have an
> > > > > > equivalent GPU instruction.
> > > > > 
> > > > > Then it should probably be lowered by the SPIR-V front-end, right?
> > > > 
> > > > I'm not sure what you mean by "spir-v frontend". If it's the tool that
> > > > generates SPIR-V, then no, not really. 
> > > 
> > > No, I meant the SPIR-V front-end of the driver (or whatever translation
> > > pass in control of the driver is translating machine-agnostic SPIR-V
> > > into some other more hardware-specific representation of the program).
> > 
> > OK. my question still stands. How does generic SPIR-V based libclc
> > help the process?
> > 
> 
> That I can think of now, it would remove the need for maintaining any
> target-specific knowledge in libclc, for plumbing target-specific
> information in order to select the right libclc flavour at link time,

it would 

Re: [Mesa-dev] [PATCH 3/3] meson: Only GLX_USE_TLS when glx is in use

2018-02-19 Thread Emil Velikov
On 19 February 2018 at 18:40, Alexander von Gluck IV
 wrote:
> February 19, 2018 12:25 PM, "Alexander von Gluck IV"  
> wrote:
>
>> ---
>> meson.build | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/meson.build b/meson.build
>> index 6fc7ec7fc9..54572a5bb8 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -331,7 +331,6 @@ if with_egl and not (with_platform_drm or 
>> with_platform_surfaceless)
>> endif
>> endif
>>
>> -pre_args += '-DGLX_USE_TLS'
>> if with_glx != 'disabled'
>> if not (with_platform_x11 and with_any_opengl)
>> if with_glx == 'auto'
>> @@ -365,6 +364,10 @@ if with_glvnd
>> endif
>> endif
>>
>> +if with_glx != 'disabled'
>> + pre_args += '-DGLX_USE_TLS'
>> +endif
>> +
>> # TODO: toggle for this
>> with_glx_direct = true
>
> Some comments on this one. I was seeing problems loading static TLS binaries
> on Haiku, turns out GLX_USE_TLS impacts more than just GLX. I'm guessing our
> (non-glx) libGL.so is getting it via libglapi linkages.
>
> https://kallisti5.keybase.pub/Screenshots/meson_build_tls.png
>
> Thanks to Dylan for figuring this one out.
>
> This was discussed previously on the ML
> "
> This can be applied to all GLX implementations, and in autotools this is
> guarded only by the --enable-glx-tls flag. Since this is on by default
> in autotools, and is strictly better than being off, the meson build
> doesn't even have a toggle for it.
> "
>
> Since the GLX_USE_TLS reaches beyond GLX, i'm guarding it with_glx after
> the glx auto-detection tri-state (which can disable it)
>
>
Note: the GLX in the name is for historical purposes - toggle applies
to glapi and the way one (GLX, EGL and DRI modules in particular)
makes use of it.

That said - we had serious issues with people tinkering with the
toggle, so Dylan's decision of omit it is spot on.
For Haiku, I would suggest the following:
 - open a bug/other issue about the missing static TLS support
 - set the macro for non-haiku platforms, with a clear reference to
the above report.

> I noticed under Fedora the Meson-built libGL differs from the system's
> in terms of TLS.. not sure if relevant (or an issue)
>
There are a few features missing from the Meson build so I wouldn't be
too surprised.
For now I'd call it a non-issue ;-)

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


Re: [Mesa-dev] [PATCH 3/3] meson: Only GLX_USE_TLS when glx is in use

2018-02-19 Thread Alexander von Gluck IV
February 19, 2018 12:25 PM, "Alexander von Gluck IV"  
wrote:

> ---
> meson.build | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 6fc7ec7fc9..54572a5bb8 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -331,7 +331,6 @@ if with_egl and not (with_platform_drm or 
> with_platform_surfaceless)
> endif
> endif
> 
> -pre_args += '-DGLX_USE_TLS'
> if with_glx != 'disabled'
> if not (with_platform_x11 and with_any_opengl)
> if with_glx == 'auto'
> @@ -365,6 +364,10 @@ if with_glvnd
> endif
> endif
> 
> +if with_glx != 'disabled'
> + pre_args += '-DGLX_USE_TLS'
> +endif
> +
> # TODO: toggle for this
> with_glx_direct = true

Some comments on this one. I was seeing problems loading static TLS binaries
on Haiku, turns out GLX_USE_TLS impacts more than just GLX. I'm guessing our
(non-glx) libGL.so is getting it via libglapi linkages.

https://kallisti5.keybase.pub/Screenshots/meson_build_tls.png

Thanks to Dylan for figuring this one out.

This was discussed previously on the ML
"
This can be applied to all GLX implementations, and in autotools this is
guarded only by the --enable-glx-tls flag. Since this is on by default
in autotools, and is strictly better than being off, the meson build
doesn't even have a toggle for it.
"

Since the GLX_USE_TLS reaches beyond GLX, i'm guarding it with_glx after
the glx auto-detection tri-state (which can disable it)


I noticed under Fedora the Meson-built libGL differs from the system's
in terms of TLS.. not sure if relevant (or an issue)

meson-compiled HEAD:
$ readelf -a ./src/glx/libGL.so | grep TLS
L (link order), O (extra OS processing required), G (group), T (TLS),
TLS0x00068d68 0x00268d68 0x00268d68
   0x001e (FLAGS)  SYMBOLIC STATIC_TLS
 214:  0 TLS GLOBAL DEFAULT  UND _glapi_tls_Dispatch
 934:  8 TLS LOCAL  DEFAULT   17 __glX_tls_Context
2900:  0 TLS GLOBAL DEFAULT  UND _glapi_tls_Dispatch


mesa-libGL-17.2.4-3.fc27.x86_64:
  $ readelf -a /usr/lib/libGL.so.1.0.0 | grep TLS
L (link order), O (extra OS processing required), G (group), T (TLS),
   0x001e (FLAGS)  BIND_NOW STATIC_TLS
  0005fff4  110e R_386_TLS_TPOFF      _glapi_tls_Current
  17:  0 TLS GLOBAL DEFAULT  UND _glapi_tls_Current


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


Re: [Mesa-dev] [PATCH 4/6] i965/tex_image: Reference the renderbuffer miptree in setTexBuffer2

2018-02-19 Thread Chad Versace
On Wed 24 Jan 2018, Jason Ekstrand wrote:
> The old code made a new miptree that referenced the same BO as the
> renderbuffer and just trusted in the memory aliasing to work.  There are
> only two ways in which the new miptree is liable to differ from the one
> in the renderbuffer and neither of them matter:
> 
>  1) It may have a different target.  The only targets that we can ever
> see in intelSetTexBuffer2 are GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE
> and the difference between the two doesn't matter as far as the
> miptree is concerned; genX(update_sampler_state) only looks at the
> gl_texture_object and not the miptree when determining whether or
> not to use normalized coordinates.
> 
>  2) It may have a very slightly different format.  Again, this doesn't
> matter because we've supported texture views for quite some time so
> we always look at the gl_texture_object format instead of the
> miptree format for hardware setup anyway.
> 
> On the other hand, because we were recreating the miptree, we were using
> intel_miptree_create_for_bo which doesn't understand modifiers.  We
> really want this function to work without doing a resolve so long as you
> have modifiers so we need to fix that.
> 
> Reviewed-by: Kenneth Graunke 
> Cc: "17.3" 
> ---
>  src/mesa/drivers/dri/i965/intel_tex_image.c | 19 +--
>  1 file changed, 5 insertions(+), 14 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c 
> b/src/mesa/drivers/dri/i965/intel_tex_image.c
> index 9d2ede1..a4e7f81 100644
> --- a/src/mesa/drivers/dri/i965/intel_tex_image.c
> +++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
> @@ -405,6 +405,7 @@ static void
>  intel_set_texture_image_mt(struct brw_context *brw,
> struct gl_texture_image *image,
> GLenum internal_format,
> +   mesa_format format,
> struct intel_mipmap_tree *mt)
>  
>  {
> @@ -415,7 +416,7 @@ intel_set_texture_image_mt(struct brw_context *brw,
> _mesa_init_teximage_fields(>ctx, image,
>mt->surf.logical_level0_px.width,
>mt->surf.logical_level0_px.height, 1,
> -  0, internal_format, mt->format);
> +  0, internal_format, format);
>  
> brw->ctx.Driver.FreeTextureImageBuffer(>ctx, image);
>  
> @@ -442,7 +443,6 @@ intelSetTexBuffer2(__DRIcontext *pDRICtx, GLint target,
> struct gl_texture_object *texObj;
> struct gl_texture_image *texImage;
> mesa_format texFormat = MESA_FORMAT_NONE;
> -   struct intel_mipmap_tree *mt;
> GLenum internal_format = 0;
>  
> texObj = _mesa_get_current_tex_object(ctx, target);
> @@ -488,20 +488,11 @@ intelSetTexBuffer2(__DRIcontext *pDRICtx, GLint target,
> }
>  
> intel_miptree_make_shareable(brw, rb->mt);
> -   mt = intel_miptree_create_for_bo(brw, rb->mt->bo, texFormat, 0,
> -rb->Base.Base.Width,
> -rb->Base.Base.Height,
> -1, rb->mt->surf.row_pitch,
> -rb->mt->surf.tiling,
> -MIPTREE_CREATE_DEFAULT);
> -   if (mt == NULL)
> -   return;
> -   mt->target = target;
>  
> _mesa_lock_texture(>ctx, texObj);
> texImage = _mesa_get_tex_image(ctx, texObj, target, 0);
> -   intel_set_texture_image_mt(brw, texImage, internal_format, mt);
> -   intel_miptree_release();
> +   intel_set_texture_image_mt(brw, texImage, internal_format,
> +  texFormat, rb->mt);
> _mesa_unlock_texture(>ctx, texObj);
>  }
>  
> @@ -594,7 +585,7 @@ intel_image_target_texture_2d(struct gl_context *ctx, 
> GLenum target,
> const GLenum internal_format =
>image->internal_format != 0 ?
>image->internal_format : _mesa_get_format_base_format(mt->format);
> -   intel_set_texture_image_mt(brw, texImage, internal_format, mt);
> +   intel_set_texture_image_mt(brw, texImage, internal_format, mt->format, 
> mt);

I was unsure whether this hunk should've used mt->format or image->format.
After digging, I discovered that for EGLImages, image->format should == 
mt->format except
(1) for depth-stencil formats, which we don't care about and (2) when
intel_miptree_create_for_dri_image() does a rgbx->rgba fallback, in
which case we definitely want mt->format instead of image->format.

The hunk looks correct to me.

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


[Mesa-dev] [PATCH 1/3] hgl: Correct glheader.h context inline with glx

2018-02-19 Thread Alexander von Gluck IV
---
 src/hgl/GLDispatcher.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/hgl/GLDispatcher.h b/src/hgl/GLDispatcher.h
index 8aaf58a623..7a4bcd3329 100644
--- a/src/hgl/GLDispatcher.h
+++ b/src/hgl/GLDispatcher.h
@@ -15,7 +15,7 @@
 #include 
 #include 
 
-#include "glheader.h"
+#include "main/glheader.h"
 
 #include "glapi/glapi.h"
 
-- 
2.14.3

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


[Mesa-dev] [PATCH 2/3] haiku-softpipe: Build fix, drop un-needed flip

2018-02-19 Thread Alexander von Gluck IV
---
 .../targets/haiku-softpipe/GalliumContext.cpp  | 25 --
 1 file changed, 25 deletions(-)

diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp 
b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
index 0356f65417..3922fa61b2 100644
--- a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
+++ b/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
@@ -338,31 +338,6 @@ GalliumContext::SwapBuffers(context_id contextID)
 
context->st->flush(context->st, ST_FLUSH_FRONT, NULL);
 
-   struct st_context *stContext = (struct st_context*)context->st;
-
-   unsigned nColorBuffers = stContext->state.framebuffer.nr_cbufs;
-   for (unsigned i = 0; i < nColorBuffers; i++) {
-   pipe_surface* surface = stContext->state.framebuffer.cbufs[i];
-   if (!surface) {
-   ERROR("%s: Color buffer %d invalid!\n", __func__, i);
-   continue;
-   }
-
-   TRACE("%s: Flushing color buffer #%d\n", __func__, i);
-
-   // We pass our destination bitmap to flush_fronbuffer which 
passes it
-   // to the private winsys display call.
-   fScreen->flush_frontbuffer(fScreen, surface->texture, 0, 0,
-   context->bitmap, NULL);
-   }
-
-   #if 0
-   // TODO... should we flush the z stencil buffer?
-   pipe_surface* zSurface = stContext->state.framebuffer.zsbuf;
-   fScreen->flush_frontbuffer(fScreen, zSurface->texture, 0, 0,
-   context->bitmap, NULL);
-   #endif
-
return B_OK;
 }
 
-- 
2.14.3

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


[Mesa-dev] [PATCH 3/3] meson: Only GLX_USE_TLS when glx is in use

2018-02-19 Thread Alexander von Gluck IV
---
 meson.build | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 6fc7ec7fc9..54572a5bb8 100644
--- a/meson.build
+++ b/meson.build
@@ -331,7 +331,6 @@ if with_egl and not (with_platform_drm or 
with_platform_surfaceless)
   endif
 endif
 
-pre_args += '-DGLX_USE_TLS'
 if with_glx != 'disabled'
   if not (with_platform_x11 and with_any_opengl)
 if with_glx == 'auto'
@@ -365,6 +364,10 @@ if with_glvnd
   endif
 endif
 
+if with_glx != 'disabled'
+  pre_args += '-DGLX_USE_TLS'
+endif
+
 # TODO: toggle for this
 with_glx_direct = true
 
-- 
2.14.3

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


Re: [Mesa-dev] [PATCH 1/6] i965/state: Ignore intel_obj->_Format for depth/stencil and ETC2

2018-02-19 Thread Chad Versace
On Wed 24 Jan 2018, Jason Ekstrand wrote:
> We're about to start letting the intel_obj->_Format be the "real"
> texture format.  For depth/stencil textures, this may be a combined
> depth stencil format.  For ETC2 on gen7 and earlier, this will be the
> actual ETC2 format.  This makes a bit more GL sense but means we have to
> be careful in state upload.

What is the "real" format? It's not a rhetorical question. Throughout
Mesa, I never know what's real and what's not. By "real", do you mean
the untranslated user-specified glTextureView(internalformat) and
glTexImage2D(internalformat)?  Or do you mean simply "more real than
before" ;)

> ---
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> index 38af6bc..844c23b 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -507,7 +507,21 @@ brw_update_texture_surface(struct gl_context *ctx,
>const unsigned swizzle = (unlikely(alpha_depth) ? SWIZZLE_XYZW :
>  brw_get_texture_swizzle(>ctx, obj));
>  
> -  mesa_format mesa_fmt = plane == 0 ? intel_obj->_Format : mt->format;
> +  mesa_format mesa_fmt;
> +  if (firstImage->_BaseFormat == GL_DEPTH_STENCIL ||
> +  firstImage->_BaseFormat == GL_DEPTH_COMPONENT) {
> + /* The format from intel_obj may be a combined depth stencil format
> +  * when we just want depth.  Pull it from the miptree instead.  This
> +  * is safe because texture views aren't allowed on depth/stencil.
> +  */
> + mesa_fmt = mt->format;
> +  } else if (mt->etc_format != MESA_FORMAT_NONE) {
> + mesa_fmt = mt->format;

This looks like it would break ETC2 texture views on hw where we decode
the ETC2 on upload (Ivybridge?), if such views worked. I suspect such
texture views never worked.

> +  } else if (plane > 0) {
> + mesa_fmt = mt->format;
> +  } else {
> + mesa_fmt = intel_obj->_Format;
> +  }
>enum isl_format format = translate_tex_format(brw, mesa_fmt,
>  for_txf ? GL_DECODE_EXT :
>  sampler->sRGBDecode);

I want to give a r-b, but want to first hear your reply regarding the
"real" format.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] anv/entrypoints: make vkGetDeviceProcAddr return NULL for instance commands

2018-02-19 Thread Jason Ekstrand
On Mon, Feb 19, 2018 at 8:35 AM, Emil Velikov 
wrote:

> On 19 February 2018 at 10:54, Iago Toral Quiroga 
> wrote:
> > The Vulkan working group has recently clarified that this is the intended
> > behavior and accepted spec language changes to make this clear.
> > ---
> >  src/intel/vulkan/anv_entrypoints_gen.py | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/intel/vulkan/anv_entrypoints_gen.py
> b/src/intel/vulkan/anv_entrypoints_gen.py
> > index c5a654f19b2..34ffedb1165 100644
> > --- a/src/intel/vulkan/anv_entrypoints_gen.py
> > +++ b/src/intel/vulkan/anv_entrypoints_gen.py
> > @@ -225,7 +225,7 @@ anv_entrypoint_is_enabled(int index, uint32_t
> core_version,
> >return ${e.core_version.c_vk_version()} <= core_version;
> > % elif e.extension:
> >% if e.extension.type == 'instance':
> > -  return instance->${e.extension.name[3:]};
> > +  return !device && instance->${e.extension.name[3:]};
>
>
> Out of curiosity - is this documented in the loader <> ICD interface spec?
> Haven't looked recently: perhaps we should bump the version advertised?
>
> Might also be applicable for the (return NULL) fixes from Jason.
>

No, it's documented in the Vulkan spec itself.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 105161] Validation of KHR_blend_equation_advanced stricter than NVidia

2018-02-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105161

Kenneth Graunke  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|mesa-dev@lists.freedesktop. |kenn...@whitecape.org
   |org |

--- Comment #5 from Kenneth Graunke  ---
Yep, the error is correct and required by the spec.  That's a bug in the NVIDIA
drivers, and it would be good to have a VK-GL-CTS test to enforce it.

The fact that layout qualifiers don't parse correctly in legacy shading
language versions is our bug.  I'll send a patch shortly.

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


Re: [Mesa-dev] [ANNOUNCE] mesa 17.3.4

2018-02-19 Thread Emil Velikov
On 17 February 2018 at 15:04, Bas Nieuwenhuizen  
wrote:
> (-mesa-announce + Mark, Dave and James)
>
> Hi Emil,
>
> radv is broken for nearly all commercial games in 17.3.4. The cause is
>
> commit ad764e365beb8a119369b97f5cb95fc7ea8c
> Author: Bas Nieuwenhuizen 
> Date:   Mon Jan 22 09:01:29 2018 +0100
>
> ac/nir: Use instance_rate_inputs per attribute, not per variable.
>
> This did the wrong thing if we had e.g. an array for which only some
> of the attributes use the instance index. Tripped up some new CTS
> tests.
>
> CC: 
> Reviewed-by: Samuel Pitoiset 
> Reviewed-by: Dave Airlie 
> (cherry picked from commit 5a4dc285002e1924dbc8c72d17481a3dbc4c0142)
>
> Conflicts:
> src/amd/common/ac_nir_to_llvm.c
>
> A typo was introduced during the conflict resolution while
> cherrypicking to 17.3.
>
> First things first, can we mitigate this? Would it be possible to get
> a 17.3.5 with this fixed ASAP? This can be fixed by either rolling
> back ad764e365beb8a119369b97f5cb95fc7ea8c or by applying
> https://patchwork.freedesktop.org/patch/204260/ (obviously not applied
> to master as the issue did not occur there).
>
I'll do a 17.3.5 momentarily, including only the above fix.

> Secondly, I'd like to talk about process and how to prevent this in
> the future. Bugfix releases are supposed to be stable so downstream
> maintainers don't have to to deal with this kind of stuff happening,
> so I think that breaking radv pretty much completely is particularly
> egregious and we should look at how to prevent this happnening another
> time.
>
Sadly James' fix went below the radar since:
 - it wasn't merged in master - understandably so
 - I mistook his reply as some lovely emails that mesa-announce is
throwing at me

A few things come to mind:
 - on my end - resolve the mesa-announce noise, ensure replies are highlighted
 - having regular reply [to the RC email] with negative and positive
testing results will be great
 - wire up some Vulkan games into the LunarG*/other test rig

I've been going through * since it's inception, as the only means of
checking non Intel hardware.

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


[Mesa-dev] [AppVeyor] mesa master #6955 failed

2018-02-19 Thread AppVeyor



Build mesa 6955 failed


Commit f78fe98fff by Marek Olšák on 2/19/2018 4:55 PM:

radeonsi: fix regression from 32-bit pointers on CI\n\nTested-by: Michel Dänzer 


Configure your notification preferences

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


Re: [Mesa-dev] [PATCH] anv/entrypoints: make vkGetDeviceProcAddr return NULL for instance commands

2018-02-19 Thread Emil Velikov
On 19 February 2018 at 10:54, Iago Toral Quiroga  wrote:
> The Vulkan working group has recently clarified that this is the intended
> behavior and accepted spec language changes to make this clear.
> ---
>  src/intel/vulkan/anv_entrypoints_gen.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/anv_entrypoints_gen.py 
> b/src/intel/vulkan/anv_entrypoints_gen.py
> index c5a654f19b2..34ffedb1165 100644
> --- a/src/intel/vulkan/anv_entrypoints_gen.py
> +++ b/src/intel/vulkan/anv_entrypoints_gen.py
> @@ -225,7 +225,7 @@ anv_entrypoint_is_enabled(int index, uint32_t 
> core_version,
>return ${e.core_version.c_vk_version()} <= core_version;
> % elif e.extension:
>% if e.extension.type == 'instance':
> -  return instance->${e.extension.name[3:]};
> +  return !device && instance->${e.extension.name[3:]};


Out of curiosity - is this documented in the loader <> ICD interface spec?
Haven't looked recently: perhaps we should bump the version advertised?

Might also be applicable for the (return NULL) fixes from Jason.

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


Re: [Mesa-dev] [PATCH] anv/entrypoints: make vkGetDeviceProcAddr return NULL for instance commands

2018-02-19 Thread Jason Ekstrand

Rb


On February 19, 2018 02:54:57 Iago Toral Quiroga  wrote:


The Vulkan working group has recently clarified that this is the intended
behavior and accepted spec language changes to make this clear.
---
 src/intel/vulkan/anv_entrypoints_gen.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_entrypoints_gen.py 
b/src/intel/vulkan/anv_entrypoints_gen.py

index c5a654f19b2..34ffedb1165 100644
--- a/src/intel/vulkan/anv_entrypoints_gen.py
+++ b/src/intel/vulkan/anv_entrypoints_gen.py
@@ -225,7 +225,7 @@ anv_entrypoint_is_enabled(int index, uint32_t core_version,
   return ${e.core_version.c_vk_version()} <= core_version;
% elif e.extension:
   % if e.extension.type == 'instance':
-  return instance->${e.extension.name[3:]};
+  return !device && instance->${e.extension.name[3:]};
   % else:
   return !device || device->${e.extension.name[3:]};
   % endif
--
2.14.1




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


[Mesa-dev] [Bug 105132] glxSwapBuffers has no effect

2018-02-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105132

--- Comment #5 from Michel Dänzer  ---
(In reply to Julien Isorce from comment #4)
> The attached experimental patch builds and runs but
> "xcb_poll_for_special_event" does not return any event [...]

That's not surprising, since there are no DRI2 special events. :)

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


[Mesa-dev] [Bug 105161] Validation of KHR_blend_equation_advanced stricter than NVidia

2018-02-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105161

--- Comment #4 from Ilia Mirkin  ---
Specifically, the ext spec says,

"""
A draw-time error will be generated in the OpenGL API if an application
attempts to render using an advanced blending equation without having a
matching layout qualifier specified in the active fragment shader.
"""

So pretty sure mesa is in the right here, and NVIDIA is buggy. (And as an
aside, the mesa implementation relies on the options being supplied properly,
since code is inserted conditionally into the shader. I'm guessing NVIDIA just
has a global library and doesn't care.)

-- 
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] [Bug 105161] Validation of KHR_blend_equation_advanced stricter than NVidia

2018-02-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105161

--- Comment #3 from Ilia Mirkin  ---
The specification is available at

https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_blend_equation_advanced.txt

If you find the NVIDIA drivers doing something different than what's written
there, feel free to report the bug to them.

If you find mesa drivers doing something different, please do let us know.

If either implementation has a bug, it would also make sense to request a
VK-GL-CTS test that enforces the correct behavior
(https://github.com/KhronosGroup/VK-GL-CTS/issues).

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


Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v4

2018-02-19 Thread Eric Engestrom
On Monday, 2018-02-19 11:20:37 +, Eric Engestrom wrote:
> On Friday, 2018-02-16 14:27:03 -0600, Alexander von Gluck IV wrote:
> > ---
> >  include/meson.build|  8 +
> >  meson.build| 16 +++---
> >  src/egl/meson.build| 36 +++---
> >  src/gallium/meson.build|  9 ++
> >  src/gallium/state_trackers/hgl/meson.build | 41 
> > ++
> >  src/gallium/targets/haiku-softpipe/meson.build | 40 
> > +
> >  src/gallium/winsys/sw/hgl/meson.build  | 29 ++
> >  src/hgl/meson.build| 36 ++
> >  src/mapi/es1api/meson.build|  2 +-
> >  src/mapi/es2api/meson.build|  2 +-
> >  src/meson.build|  7 -
> >  11 files changed, 209 insertions(+), 17 deletions(-)
> >  create mode 100644 src/gallium/state_trackers/hgl/meson.build
> >  create mode 100644 src/gallium/targets/haiku-softpipe/meson.build
> >  create mode 100644 src/gallium/winsys/sw/hgl/meson.build
> >  create mode 100644 src/hgl/meson.build
> > 
> > diff --git a/include/meson.build b/include/meson.build
> > index 1cbc68182c..28ffb33215 100644
> > --- a/include/meson.build
> > +++ b/include/meson.build
> > @@ -22,6 +22,7 @@ inc_drm_uapi = include_directories('drm-uapi')
> >  inc_vulkan = include_directories('vulkan')
> >  inc_d3d9 = include_directories('D3D9')
> >  inc_gl_internal = include_directories('GL/internal')
> > +inc_haikugl = include_directories('HaikuGL')
> >  
> >  if with_gles1
> >install_headers(
> > @@ -80,6 +81,13 @@ if with_gallium_st_nine
> >)
> >  endif
> >  
> > +if with_platform_haiku
> > +  install_headers(
> > +'HaikuGL/GLRenderer.h', 'HaikuGL/GLView.h', 'HaikuGL/OpenGLKit.h',
> > +subdir : 'opengl',
> > +  )
> > +endif
> > +
> >  # Only install the headers if we are building a stand alone implementation 
> > and
> >  # not an ICD enabled implementation
> >  if with_gallium_opencl and not with_opencl_icd
> > diff --git a/meson.build b/meson.build
> > index d6ffa30d9e..120042fb24 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -99,7 +99,7 @@ if _drivers == 'auto'
> >  else
> >error('Unknown architecture. Please pass -Ddri-drivers to set driver 
> > options. Patches gladly accepted to fix this.')
> >  endif
> > -  elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
> > +  elif ['darwin', 'windows', 'cygwin', 
> > 'haiku'].contains(host_machine.system())
> >  # only swrast would make sense here, but gallium swrast is a much 
> > better default
> >  _drivers = ''
> >else
> > @@ -144,7 +144,7 @@ if _drivers == 'auto'
> >  else
> >error('Unknown architecture. Please pass -Dgallium-drivers to set 
> > driver options. Patches gladly accepted to fix this.')
> >  endif
> > -  elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
> > +  elif ['darwin', 'windows', 'cygwin', 
> > 'haiku'].contains(host_machine.system())
> >  _drivers = 'swrast'
> >else
> >  error('Unknown OS. Please pass -Dgallium-drivers to set driver 
> > options. Patches gladly accepted to fix this.')
> > @@ -181,7 +181,7 @@ if _vulkan_drivers == 'auto'
> >  else
> >error('Unknown architecture. Please pass -Dvulkan-drivers to set 
> > driver options. Patches gladly accepted to fix this.')
> >  endif
> > -  elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
> > +  elif ['darwin', 'windows', 'cygwin', 
> > 'haiku'].contains(host_machine.system())
> >  # No vulkan driver supports windows or macOS currently
> >  _vulkan_drivers = ''
> >else
> > @@ -242,6 +242,8 @@ if _platforms == 'auto'
> >  _platforms = 'x11,wayland,drm,surfaceless'
> >elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
> >  _platforms = 'x11,surfaceless'
> > +  elif ['haiku'].contains(host_machine.system())
> > +_platforms = 'haiku'
> >else
> >  error('Unknown OS. Please pass -Dplatforms to set platforms. Patches 
> > gladly accepted to fix this.')
> >endif
> > @@ -252,6 +254,7 @@ if _platforms != ''
> >with_platform_x11 = _split.contains('x11')
> >with_platform_wayland = _split.contains('wayland')
> >with_platform_drm = _split.contains('drm')
> > +  with_platform_haiku = _split.contains('haiku')
> >with_platform_surfaceless = _split.contains('surfaceless')
> >egl_native_platform = _split[0]
> >  endif
> > @@ -260,6 +263,8 @@ with_glx = get_option('glx')
> >  if with_glx == 'auto'
> >if with_dri
> >  with_glx = 'dri'
> > +  elif with_platform_haiku
> > +with_glx = 'disabled'
> >elif with_gallium
> >  # Even when building just gallium drivers the user probably wants dri
> >  with_glx = 'dri'
> > @@ -375,7 +380,7 @@ if with_any_vk and 

[Mesa-dev] [Bug 105132] glxSwapBuffers has no effect

2018-02-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105132

--- Comment #4 from Julien Isorce  ---
Created attachment 137438
  --> https://bugs.freedesktop.org/attachment.cgi?id=137438=edit
wip-not-working: poll special dri2 events

As Scott also mentioned, mesa/src/glx/dri2.c::DRI2WireToEvent is never called
when xcb owns the Xlib event queue or as soon as xcb_poll_for_event is called
from the app client.

I was curious of what is done for present extension in
src/loader/loader_dri3_helper.c, so I mimic that solution, i.e. poll special
events by calling "xcb_register_for_special_xge(xcb_dri2_id)" and
"xcb_poll_for_special_event".

The attached experimental patch builds and runs but
"xcb_poll_for_special_event" does not return any event but it was worth a try.
(I am not sending it to mesa-dev as it is an experimentation)

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


Re: [Mesa-dev] [PATCH] r600/sb: fix rotated register in while loop

2018-02-19 Thread Gert Wollny
Am Montag, den 19.02.2018, 14:06 +1000 schrieb Dave Airlie:
> On 15 February 2018 at 01:26, Gert Wollny 
> wrote:
> > Am Mittwoch, den 14.02.2018, 17:18 +1000 schrieb Dave Airlie:
> > > From: Dave Airlie 
> > > 
> > > A bunch of CTS tests led me to write
> > > tests/shaders/ssa/fs-while-loop-rotate-value.shader_test
> > > which r600/sb always fell over on.
> > > 
> > > This patch fixes it, but I'll probably never be 100% sure why.
> 
> I've gone back to this approach, I've spot tested and I don't see
> as many regressions.

For me most of the assertion failures don't come up anymore, but in
total the numer of regressions is still quite high, i.e. 1 assertion
failure and 13 normal failures. 

  vs-struct-nonconst-non-opaque-members fails with   

  b/sb_sched.cpp:931:process_fetch: 
  Assertion `f->parent->count() ==  1' failed.

and the list of normal failures is very similar to you first patch, the
only change is that 
  glsl-1.10/execution/variable-indexing/vs-output-array-float-index-wr 
no longer fails, but instead 
  glsl-1.50/execution/geometry/dynamic_input_array_index
fails, 

Best, 
Gert


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


[Mesa-dev] [Bug 105161] Validation of KHR_blend_equation_advanced stricter than NVidia

2018-02-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105161

--- Comment #2 from Allan Sandfeld Jensen  ---
Note. I have been unable to get it to work at all in compatibility-mode desktop
OpenGL. The following code only works in core mode: 

#ifdef GL_KHR_blend_equation_advanced
#extension GL_KHR_blend_equation_advanced : require
layout(blend_support_all_equations) out;
#endif

because layout is not identified in basic OpenGL 2.0, and while

#ifdef GL_KHR_blend_equation_advanced
#extension GL_ARB_explicit_attrib_location : enable
#extension GL_KHR_blend_equation_advanced : require
layout(blend_support_all_equations) out;
#endif

parses, it doesn't actually change anything. Mesa still reports: 
Mesa: User error: GL_INVALID_OPERATION in fragment shader does not allow
advanced blending mode (GL_MULTIPLY)

With NVidia drivers, I don't need any changes to fragment shaders.

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


Re: [Mesa-dev] [PATCH 3/3] st/shader_cache: copy nir pointer to gl_program after deserializing

2018-02-19 Thread Marek Olšák
For the series:

Reviewed-by: Marek Olšák 

Marek

On Fri, Feb 16, 2018 at 1:55 AM, Timothy Arceri  wrote:
> This fixes a crash when running the arb_get_program_binary-api-errors
> piglit test twice.
> ---
>  src/mesa/state_tracker/st_shader_cache.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_shader_cache.c 
> b/src/mesa/state_tracker/st_shader_cache.c
> index 6ff404220a..3ca3fef1df 100644
> --- a/src/mesa/state_tracker/st_shader_cache.c
> +++ b/src/mesa/state_tracker/st_shader_cache.c
> @@ -215,6 +215,7 @@ st_deserialise_ir_program(struct gl_context *ctx,
>   stvp->tgsi.type = PIPE_SHADER_IR_NIR;
>   stvp->shader_program = shProg;
>   stvp->tgsi.ir.nir = nir_deserialize(NULL, options, _reader);
> + prog->nir = stvp->tgsi.ir.nir;
>} else {
>   read_tgsi_from_cache(_reader, >tgsi.tokens,
>>num_tgsi_tokens);
> @@ -237,6 +238,7 @@ st_deserialise_ir_program(struct gl_context *ctx,
>   sttcp->tgsi.type = PIPE_SHADER_IR_NIR;
>   sttcp->shader_program = shProg;
>   sttcp->tgsi.ir.nir = nir_deserialize(NULL, options, _reader);
> + prog->nir = sttcp->tgsi.ir.nir;
>} else {
>   read_tgsi_from_cache(_reader, >tgsi.tokens,
>>num_tgsi_tokens);
> @@ -259,6 +261,7 @@ st_deserialise_ir_program(struct gl_context *ctx,
>   sttep->tgsi.type = PIPE_SHADER_IR_NIR;
>   sttep->shader_program = shProg;
>   sttep->tgsi.ir.nir = nir_deserialize(NULL, options, _reader);
> + prog->nir = sttep->tgsi.ir.nir;
>} else {
>   read_tgsi_from_cache(_reader, >tgsi.tokens,
>>num_tgsi_tokens);
> @@ -281,6 +284,7 @@ st_deserialise_ir_program(struct gl_context *ctx,
>   stgp->tgsi.type = PIPE_SHADER_IR_NIR;
>   stgp->shader_program = shProg;
>   stgp->tgsi.ir.nir = nir_deserialize(NULL, options, _reader);
> + prog->nir = stgp->tgsi.ir.nir;
>} else {
>   read_tgsi_from_cache(_reader, >tgsi.tokens,
>>num_tgsi_tokens);
> @@ -300,6 +304,7 @@ st_deserialise_ir_program(struct gl_context *ctx,
>   stfp->tgsi.type = PIPE_SHADER_IR_NIR;
>   stfp->shader_program = shProg;
>   stfp->tgsi.ir.nir = nir_deserialize(NULL, options, _reader);
> + prog->nir = stfp->tgsi.ir.nir;
>} else {
>   read_tgsi_from_cache(_reader, >tgsi.tokens,
>>num_tgsi_tokens);
> @@ -319,6 +324,7 @@ st_deserialise_ir_program(struct gl_context *ctx,
>   stcp->tgsi.ir_type = PIPE_SHADER_IR_NIR;
>   stcp->shader_program = shProg;
>   stcp->tgsi.prog = nir_deserialize(NULL, options, _reader);
> + prog->nir = (nir_shader *) stcp->tgsi.prog;
>} else {
>   read_tgsi_from_cache(_reader,
>(const struct tgsi_token**) >tgsi.prog,
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 0/8] The 2nd version for UVD HEVC encode

2018-02-19 Thread James Zhu



On 2018-02-16 01:31 PM, Mark Thompson wrote:

On 16/02/18 17:53, James Zhu wrote:

Hi Mark,

I couldn't reproduce the issue on my Polaris 11 to run mpv / ffmpeg about 1.5 
hours.

one terminal run:

ffmpeg -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 
-hwaccel_output_format vaapi -i video/Mr.Right.mp4 -an -c:v hevc_vaapi -bf 0 
out.mp4

the other  terminal run:

mpv --fs --loop --no-audio --vo gpu --gpu-context=x11egl --hwdec=vaapi 
video/Mr.Right.mp4
But it has some failure with vaDeriveImage. I am not  sure if this failure 
matters, the video still can play without any other error,

If it's calling vaDeriveImage() at all that suggests it isn't using the proper 
interop path, and may be falling back to software decode.  This should work in 
recent versions of mpv with git Mesa and libva - maybe have a look at the 
verbose output and see what it's actually doing?
I think you are right, it should fall back to software decode. During 
the weekend test, my system hung also with legacy VAAPI test output setting.



mpv --fs --loop --no-audio --vo vaapi  --hwdec=vaapi video/Mr.Right.mp4

No error reported with this command line.

I haven't tried the legacy VAAPI test output, I'll try later to see if that 
also triggers the failure for me.


I don't think that this sort of issue should block the patches in Mesa because 
it looks likely that it is a kernel issue somehow - userspace shouldn't be able 
to nuke the GPU at all.  Still, the feature is essentially unusable for me 
because of this problem, and I imagine it will apply to at least some other 
people with setups which are match mine in some way as yet unknown.
Yeah, if there are no more comments from the community. We will push the 
patches to the upstream tomorrow.


Thanks,

- Mark


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


[Mesa-dev] [Bug 105161] Validation of KHR_blend_equation_advanced stricter than NVidia

2018-02-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105161

--- Comment #1 from Allan Sandfeld Jensen  ---
I traced the issue to this commit:

commit acf57fcf7ff7e60c3550da7b6dda7ad8b69195bd
Author: Kenneth Graunke 
Date:   Sat Aug 20 12:51:03 2016 -0700

mesa: Add draw time validation for advanced blending modes.

v2: Add null checks (requested by Curro).

Signed-off-by: Kenneth Graunke 
Reviewed-by: Francisco Jerez 

-- 
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] [Bug 105161] Validation of KHR_blend_equation_advanced stricter than NVidia

2018-02-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105161

Bug ID: 105161
   Summary: Validation of KHR_blend_equation_advanced stricter
than NVidia
   Product: Mesa
   Version: 17.3
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: k...@carewolf.com
QA Contact: mesa-dev@lists.freedesktop.org

I noticed your drivers are advertising support for blend_advanced and
blend_advanced_coherent, but couldn't understand why it still didn't work. I
traced it down to you enforcing that fragment shaders needs to enable which
advanced blend equation they work with, something the NVidia driver does not.

I think it would be in your best interest to only warn on that and not abort
the operation. If you can't do it correctly without that hint, that is of
course acceptable, it is there for a reason, but it seems you are only doing
the validation for the sake of strictness, and that is hurting your drivers
compatibility.

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


Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v4

2018-02-19 Thread Eric Engestrom
On Friday, 2018-02-16 14:27:03 -0600, Alexander von Gluck IV wrote:
> ---
>  include/meson.build|  8 +
>  meson.build| 16 +++---
>  src/egl/meson.build| 36 +++---
>  src/gallium/meson.build|  9 ++
>  src/gallium/state_trackers/hgl/meson.build | 41 
> ++
>  src/gallium/targets/haiku-softpipe/meson.build | 40 +
>  src/gallium/winsys/sw/hgl/meson.build  | 29 ++
>  src/hgl/meson.build| 36 ++
>  src/mapi/es1api/meson.build|  2 +-
>  src/mapi/es2api/meson.build|  2 +-
>  src/meson.build|  7 -
>  11 files changed, 209 insertions(+), 17 deletions(-)
>  create mode 100644 src/gallium/state_trackers/hgl/meson.build
>  create mode 100644 src/gallium/targets/haiku-softpipe/meson.build
>  create mode 100644 src/gallium/winsys/sw/hgl/meson.build
>  create mode 100644 src/hgl/meson.build
> 
> diff --git a/include/meson.build b/include/meson.build
> index 1cbc68182c..28ffb33215 100644
> --- a/include/meson.build
> +++ b/include/meson.build
> @@ -22,6 +22,7 @@ inc_drm_uapi = include_directories('drm-uapi')
>  inc_vulkan = include_directories('vulkan')
>  inc_d3d9 = include_directories('D3D9')
>  inc_gl_internal = include_directories('GL/internal')
> +inc_haikugl = include_directories('HaikuGL')
>  
>  if with_gles1
>install_headers(
> @@ -80,6 +81,13 @@ if with_gallium_st_nine
>)
>  endif
>  
> +if with_platform_haiku
> +  install_headers(
> +'HaikuGL/GLRenderer.h', 'HaikuGL/GLView.h', 'HaikuGL/OpenGLKit.h',
> +subdir : 'opengl',
> +  )
> +endif
> +
>  # Only install the headers if we are building a stand alone implementation 
> and
>  # not an ICD enabled implementation
>  if with_gallium_opencl and not with_opencl_icd
> diff --git a/meson.build b/meson.build
> index d6ffa30d9e..120042fb24 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -99,7 +99,7 @@ if _drivers == 'auto'
>  else
>error('Unknown architecture. Please pass -Ddri-drivers to set driver 
> options. Patches gladly accepted to fix this.')
>  endif
> -  elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
> +  elif ['darwin', 'windows', 'cygwin', 
> 'haiku'].contains(host_machine.system())
>  # only swrast would make sense here, but gallium swrast is a much better 
> default
>  _drivers = ''
>else
> @@ -144,7 +144,7 @@ if _drivers == 'auto'
>  else
>error('Unknown architecture. Please pass -Dgallium-drivers to set 
> driver options. Patches gladly accepted to fix this.')
>  endif
> -  elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
> +  elif ['darwin', 'windows', 'cygwin', 
> 'haiku'].contains(host_machine.system())
>  _drivers = 'swrast'
>else
>  error('Unknown OS. Please pass -Dgallium-drivers to set driver options. 
> Patches gladly accepted to fix this.')
> @@ -181,7 +181,7 @@ if _vulkan_drivers == 'auto'
>  else
>error('Unknown architecture. Please pass -Dvulkan-drivers to set 
> driver options. Patches gladly accepted to fix this.')
>  endif
> -  elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
> +  elif ['darwin', 'windows', 'cygwin', 
> 'haiku'].contains(host_machine.system())
>  # No vulkan driver supports windows or macOS currently
>  _vulkan_drivers = ''
>else
> @@ -242,6 +242,8 @@ if _platforms == 'auto'
>  _platforms = 'x11,wayland,drm,surfaceless'
>elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
>  _platforms = 'x11,surfaceless'
> +  elif ['haiku'].contains(host_machine.system())
> +_platforms = 'haiku'
>else
>  error('Unknown OS. Please pass -Dplatforms to set platforms. Patches 
> gladly accepted to fix this.')
>endif
> @@ -252,6 +254,7 @@ if _platforms != ''
>with_platform_x11 = _split.contains('x11')
>with_platform_wayland = _split.contains('wayland')
>with_platform_drm = _split.contains('drm')
> +  with_platform_haiku = _split.contains('haiku')
>with_platform_surfaceless = _split.contains('surfaceless')
>egl_native_platform = _split[0]
>  endif
> @@ -260,6 +263,8 @@ with_glx = get_option('glx')
>  if with_glx == 'auto'
>if with_dri
>  with_glx = 'dri'
> +  elif with_platform_haiku
> +with_glx = 'disabled'
>elif with_gallium
>  # Even when building just gallium drivers the user probably wants dri
>  with_glx = 'dri'
> @@ -375,7 +380,7 @@ if with_any_vk and (with_platform_x11 and not with_dri3)
>error('Vulkan drivers require dri3 for X11 support')
>  endif
>  if with_dri or with_gallium
> -  if with_glx == 'disabled' and not with_egl
> +  if with_glx == 'disabled' and not with_egl and not with_platform_haiku
>  error('building dri or gallium drivers 

Re: [Mesa-dev] [PATCH] anv/entrypoints: make vkGetDeviceProcAddr return NULL for instance commands

2018-02-19 Thread Lionel Landwerlin

Looks good to me :

Reviewed-by: Lionel Landwerlin 

On 19/02/18 10:54, Iago Toral Quiroga wrote:

The Vulkan working group has recently clarified that this is the intended
behavior and accepted spec language changes to make this clear.
---
  src/intel/vulkan/anv_entrypoints_gen.py | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_entrypoints_gen.py 
b/src/intel/vulkan/anv_entrypoints_gen.py
index c5a654f19b2..34ffedb1165 100644
--- a/src/intel/vulkan/anv_entrypoints_gen.py
+++ b/src/intel/vulkan/anv_entrypoints_gen.py
@@ -225,7 +225,7 @@ anv_entrypoint_is_enabled(int index, uint32_t core_version,
return ${e.core_version.c_vk_version()} <= core_version;
 % elif e.extension:
% if e.extension.type == 'instance':
-  return instance->${e.extension.name[3:]};
+  return !device && instance->${e.extension.name[3:]};
% else:
return !device || device->${e.extension.name[3:]};
% endif



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


[Mesa-dev] [PATCH] anv/entrypoints: make vkGetDeviceProcAddr return NULL for instance commands

2018-02-19 Thread Iago Toral Quiroga
The Vulkan working group has recently clarified that this is the intended
behavior and accepted spec language changes to make this clear.
---
 src/intel/vulkan/anv_entrypoints_gen.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_entrypoints_gen.py 
b/src/intel/vulkan/anv_entrypoints_gen.py
index c5a654f19b2..34ffedb1165 100644
--- a/src/intel/vulkan/anv_entrypoints_gen.py
+++ b/src/intel/vulkan/anv_entrypoints_gen.py
@@ -225,7 +225,7 @@ anv_entrypoint_is_enabled(int index, uint32_t core_version,
   return ${e.core_version.c_vk_version()} <= core_version;
% elif e.extension:
   % if e.extension.type == 'instance':
-  return instance->${e.extension.name[3:]};
+  return !device && instance->${e.extension.name[3:]};
   % else:
   return !device || device->${e.extension.name[3:]};
   % endif
-- 
2.14.1

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