Re: [Mesa-dev] [PATCH 1/7] nir: add bindless to nir data
This patch is: Reviewed-by: Iago Toral QuirogaOn 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
Reviewed-by: Iago Toral QuirogaOn 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
pthread-stubs is no longer required on OpenBSD and has been removed. libpthread parts involved moved to libc. Signed-off-by: Jonathan GrayCc: 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
From: Dave AirlieThis 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
--- 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
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()
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
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
From: Dave AirlieThis 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.
From: Dave AirliedEQP-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.
From: Dave AirlieWe 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
From: Dave AirlieJust 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
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
--- 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
--- 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
--- 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
--- 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
--- 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.
From: Dave AirlieThis 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
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
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
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 VelikovConfigure 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
On Mon, Feb 19, 2018 at 6:28 PM, Emil Velikovwrote: > 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
On Thu, 2018-02-15 at 22:50 -0800, Francisco Jerez wrote: > Jan Veselywrites: > > > 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
On 19 February 2018 at 18:40, Alexander von Gluck IVwrote: > 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
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
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
--- 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
--- .../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
--- 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
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
On Mon, Feb 19, 2018 at 8:35 AM, Emil Velikovwrote: > 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
https://bugs.freedesktop.org/show_bug.cgi?id=105161 Kenneth Graunkechanged: 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
On 17 February 2018 at 15:04, Bas Nieuwenhuizenwrote: > (-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
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änzerConfigure 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
On 19 February 2018 at 10:54, Iago Toral Quirogawrote: > 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
Rb On February 19, 2018 02:54:57 Iago Toral Quirogawrote: 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
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
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
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
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
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
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
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
For the series: Reviewed-by: Marek OlšákMarek 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
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
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
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
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
Looks good to me : Reviewed-by: Lionel LandwerlinOn 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
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