Re: [Mesa-dev] [PATCH mesa 2/6] nouveau: silence paranoid compiler's -Wclass-memaccess
Based on the various fixes, warning seems bogus -- is the proper
solution -Wno-class-memaccess? (Or however one disables such
things...)
On Fri, Sep 21, 2018 at 9:50 AM, Eric Engestrom
wrote:
> Signed-off-by: Eric Engestrom
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir.cpp| 2 +-
> src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> index 49425b98b9137058c986..62ebc2d24069b7b5f523 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> @@ -905,7 +905,7 @@ Instruction::isCommutationLegal(const Instruction *i)
> const
> TexInstruction::TexInstruction(Function *fn, operation op)
> : Instruction(fn, op, TYPE_F32)
> {
> - memset(&tex, 0, sizeof(tex));
> + memset(static_cast(&tex), 0, sizeof(tex));
>
> tex.rIndirectSrc = -1;
> tex.sIndirectSrc = -1;
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> index 9193a01f189874a7fb38..b6b9b42964bec670079c 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> @@ -454,7 +454,7 @@ CodeEmitter::addInterp(int ipa, int reg, FixupApply apply)
>if (!fixupInfo)
> return false;
>if (n == 0)
> - memset(fixupInfo, 0, sizeof(FixupInfo));
> + memset(static_cast(fixupInfo), 0, sizeof(FixupInfo));
> }
> ++fixupInfo->count;
>
> --
> Cheers,
> Eric
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi: add a workaround for bitfield_extract when count is 0
This ports the fix from 3d41757788ac. Both LLVM 7 & 8 continue
to have this problem.
It fixes rendering issues in some menu and loading screens of
Civ VI which can be seen in the trace from bug 104602.
Note: This does not fix the black triangles on Vega for bug
104602.
Cc: mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104602
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107276
---
.../drivers/radeonsi/si_shader_tgsi_alu.c | 41 ++-
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
index f54d025aec0..814362bc963 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
@@ -494,18 +494,37 @@ static void emit_bfe(const struct lp_build_tgsi_action
*action,
struct lp_build_emit_data *emit_data)
{
struct si_shader_context *ctx = si_shader_context(bld_base);
- LLVMValueRef bfe_sm5;
- LLVMValueRef cond;
-
- bfe_sm5 = ac_build_bfe(&ctx->ac, emit_data->args[0],
- emit_data->args[1], emit_data->args[2],
- emit_data->info->opcode == TGSI_OPCODE_IBFE);
- /* Correct for GLSL semantics. */
- cond = LLVMBuildICmp(ctx->ac.builder, LLVMIntUGE, emit_data->args[2],
-LLVMConstInt(ctx->i32, 32, 0), "");
- emit_data->output[emit_data->chan] =
- LLVMBuildSelect(ctx->ac.builder, cond, emit_data->args[0],
bfe_sm5, "");
+ if (HAVE_LLVM < 0x0700) {
+ LLVMValueRef bfe_sm5 =
+ ac_build_bfe(&ctx->ac, emit_data->args[0],
+emit_data->args[1], emit_data->args[2],
+emit_data->info->opcode ==
TGSI_OPCODE_IBFE);
+
+ /* Correct for GLSL semantics. */
+ LLVMValueRef cond = LLVMBuildICmp(ctx->ac.builder, LLVMIntUGE,
emit_data->args[2],
+ LLVMConstInt(ctx->i32, 32,
0), "");
+ emit_data->output[emit_data->chan] =
+ LLVMBuildSelect(ctx->ac.builder, cond,
emit_data->args[0], bfe_sm5, "");
+ } else {
+ /* FIXME: LLVM 7 returns incorrect result when count is 0.
+* https://bugs.freedesktop.org/show_bug.cgi?id=107276
+*/
+ LLVMValueRef zero = ctx->i32_0;
+ LLVMValueRef bfe_sm5 =
+ ac_build_bfe(&ctx->ac, emit_data->args[0],
+emit_data->args[1], emit_data->args[2],
+emit_data->info->opcode ==
TGSI_OPCODE_IBFE);
+
+ /* Correct for GLSL semantics. */
+ LLVMValueRef cond = LLVMBuildICmp(ctx->ac.builder, LLVMIntUGE,
emit_data->args[2],
+ LLVMConstInt(ctx->i32, 32,
0), "");
+ LLVMValueRef cond2 = LLVMBuildICmp(ctx->ac.builder, LLVMIntEQ,
emit_data->args[2],
+ zero, "");
+ bfe_sm5 = LLVMBuildSelect(ctx->ac.builder, cond,
emit_data->args[0], bfe_sm5, "");
+ emit_data->output[emit_data->chan] =
+ LLVMBuildSelect(ctx->ac.builder, cond2, zero, bfe_sm5,
"");
+ }
}
/* this is ffs in C */
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106833] glLinkProgram is expected to fail when vertex attribute aliasing happens on ES3.0 context or later
https://bugs.freedesktop.org/show_bug.cgi?id=106833 --- Comment #8 from Mark Janes --- Tapani, is there a piglit test for this? -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/compiler: Export TCS passthrough creation
Wiring up TCS in some other driver?
Acked-by: Jason Ekstrand
On September 21, 2018 22:30:25 Caio Marcelo de Oliveira Filho
wrote:
Move create_passthrough_tcs() from i965 so can be used in other
contexts.
---
src/intel/compiler/brw_nir.c| 81
src/intel/compiler/brw_nir.h| 5 ++
src/mesa/drivers/dri/i965/brw_tcs.c | 83 +
3 files changed, 87 insertions(+), 82 deletions(-)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index b38c3ba383d..f61baee230a 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -958,3 +958,84 @@ brw_glsl_base_type_for_nir_type(nir_alu_type type)
unreachable("bad type");
}
}
+
+nir_shader *
+brw_nir_create_passthrough_tcs(void *mem_ctx, const struct brw_compiler
*compiler,
+ const nir_shader_compiler_options *options,
+ const struct brw_tcs_prog_key *key)
+{
+ nir_builder b;
+ nir_builder_init_simple_shader(&b, mem_ctx, MESA_SHADER_TESS_CTRL,
+ options);
+ nir_shader *nir = b.shader;
+ nir_variable *var;
+ nir_intrinsic_instr *load;
+ nir_intrinsic_instr *store;
+ nir_ssa_def *zero = nir_imm_int(&b, 0);
+ nir_ssa_def *invoc_id =
+ nir_load_system_value(&b, nir_intrinsic_load_invocation_id, 0);
+
+ nir->info.inputs_read = key->outputs_written &
+ ~(VARYING_BIT_TESS_LEVEL_INNER | VARYING_BIT_TESS_LEVEL_OUTER);
+ nir->info.outputs_written = key->outputs_written;
+ nir->info.tess.tcs_vertices_out = key->input_vertices;
+ nir->info.name = ralloc_strdup(nir, "passthrough");
+ nir->num_uniforms = 8 * sizeof(uint32_t);
+
+ var = nir_variable_create(nir, nir_var_uniform, glsl_vec4_type(), "hdr_0");
+ var->data.location = 0;
+ var = nir_variable_create(nir, nir_var_uniform, glsl_vec4_type(), "hdr_1");
+ var->data.location = 1;
+
+ /* Write the patch URB header. */
+ for (int i = 0; i <= 1; i++) {
+ load = nir_intrinsic_instr_create(nir, nir_intrinsic_load_uniform);
+ load->num_components = 4;
+ load->src[0] = nir_src_for_ssa(zero);
+ nir_ssa_dest_init(&load->instr, &load->dest, 4, 32, NULL);
+ nir_intrinsic_set_base(load, i * 4 * sizeof(uint32_t));
+ nir_builder_instr_insert(&b, &load->instr);
+
+ store = nir_intrinsic_instr_create(nir, nir_intrinsic_store_output);
+ store->num_components = 4;
+ store->src[0] = nir_src_for_ssa(&load->dest.ssa);
+ store->src[1] = nir_src_for_ssa(zero);
+ nir_intrinsic_set_base(store, VARYING_SLOT_TESS_LEVEL_INNER - i);
+ nir_intrinsic_set_write_mask(store, WRITEMASK_XYZW);
+ nir_builder_instr_insert(&b, &store->instr);
+ }
+
+ /* Copy inputs to outputs. */
+ uint64_t varyings = nir->info.inputs_read;
+
+ while (varyings != 0) {
+ const int varying = ffsll(varyings) - 1;
+
+ load = nir_intrinsic_instr_create(nir,
+nir_intrinsic_load_per_vertex_input);
+ load->num_components = 4;
+ load->src[0] = nir_src_for_ssa(invoc_id);
+ load->src[1] = nir_src_for_ssa(zero);
+ nir_ssa_dest_init(&load->instr, &load->dest, 4, 32, NULL);
+ nir_intrinsic_set_base(load, varying);
+ nir_builder_instr_insert(&b, &load->instr);
+
+ store = nir_intrinsic_instr_create(nir,
+
nir_intrinsic_store_per_vertex_output);
+ store->num_components = 4;
+ store->src[0] = nir_src_for_ssa(&load->dest.ssa);
+ store->src[1] = nir_src_for_ssa(invoc_id);
+ store->src[2] = nir_src_for_ssa(zero);
+ nir_intrinsic_set_base(store, varying);
+ nir_intrinsic_set_write_mask(store, WRITEMASK_XYZW);
+ nir_builder_instr_insert(&b, &store->instr);
+
+ varyings &= ~BITFIELD64_BIT(varying);
+ }
+
+ nir_validate_shader(nir);
+
+ nir = brw_preprocess_nir(compiler, nir);
+
+ return nir;
+}
diff --git a/src/intel/compiler/brw_nir.h b/src/intel/compiler/brw_nir.h
index 06f0e8690e4..2ff8c72b94f 100644
--- a/src/intel/compiler/brw_nir.h
+++ b/src/intel/compiler/brw_nir.h
@@ -164,6 +164,11 @@ nir_shader *brw_nir_optimize(nir_shader *nir,
bool is_scalar,
bool allow_copies);
+nir_shader *brw_nir_create_passthrough_tcs(void *mem_ctx,
+ const struct brw_compiler
*compiler,
+ const
nir_shader_compiler_options *options,
+ const struct brw_tcs_prog_key
*key);
+
#define BRW_NIR_FRAG_OUTPUT_INDEX_SHIFT 0
#define BRW_NIR_FRAG_OUTPUT_INDEX_MASK INTEL_MASK(0, 0)
#define BRW_NIR_FRAG_OUTPUT_LOCATION_SHIFT 1
diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c
b/src/mesa/drivers/dri/i965/brw_tcs.c
index 823933ef77f..17f4130c095 100644
--- a/src/mesa/drivers/dri/i965/brw_tcs.c
+++ b/src/mesa/drivers/dri/i965/brw_tcs.c
@@ -34,87 +34,6
[Mesa-dev] [PATCH] intel/compiler: Export TCS passthrough creation
Move create_passthrough_tcs() from i965 so can be used in other
contexts.
---
src/intel/compiler/brw_nir.c| 81
src/intel/compiler/brw_nir.h| 5 ++
src/mesa/drivers/dri/i965/brw_tcs.c | 83 +
3 files changed, 87 insertions(+), 82 deletions(-)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index b38c3ba383d..f61baee230a 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -958,3 +958,84 @@ brw_glsl_base_type_for_nir_type(nir_alu_type type)
unreachable("bad type");
}
}
+
+nir_shader *
+brw_nir_create_passthrough_tcs(void *mem_ctx, const struct brw_compiler
*compiler,
+ const nir_shader_compiler_options *options,
+ const struct brw_tcs_prog_key *key)
+{
+ nir_builder b;
+ nir_builder_init_simple_shader(&b, mem_ctx, MESA_SHADER_TESS_CTRL,
+ options);
+ nir_shader *nir = b.shader;
+ nir_variable *var;
+ nir_intrinsic_instr *load;
+ nir_intrinsic_instr *store;
+ nir_ssa_def *zero = nir_imm_int(&b, 0);
+ nir_ssa_def *invoc_id =
+ nir_load_system_value(&b, nir_intrinsic_load_invocation_id, 0);
+
+ nir->info.inputs_read = key->outputs_written &
+ ~(VARYING_BIT_TESS_LEVEL_INNER | VARYING_BIT_TESS_LEVEL_OUTER);
+ nir->info.outputs_written = key->outputs_written;
+ nir->info.tess.tcs_vertices_out = key->input_vertices;
+ nir->info.name = ralloc_strdup(nir, "passthrough");
+ nir->num_uniforms = 8 * sizeof(uint32_t);
+
+ var = nir_variable_create(nir, nir_var_uniform, glsl_vec4_type(), "hdr_0");
+ var->data.location = 0;
+ var = nir_variable_create(nir, nir_var_uniform, glsl_vec4_type(), "hdr_1");
+ var->data.location = 1;
+
+ /* Write the patch URB header. */
+ for (int i = 0; i <= 1; i++) {
+ load = nir_intrinsic_instr_create(nir, nir_intrinsic_load_uniform);
+ load->num_components = 4;
+ load->src[0] = nir_src_for_ssa(zero);
+ nir_ssa_dest_init(&load->instr, &load->dest, 4, 32, NULL);
+ nir_intrinsic_set_base(load, i * 4 * sizeof(uint32_t));
+ nir_builder_instr_insert(&b, &load->instr);
+
+ store = nir_intrinsic_instr_create(nir, nir_intrinsic_store_output);
+ store->num_components = 4;
+ store->src[0] = nir_src_for_ssa(&load->dest.ssa);
+ store->src[1] = nir_src_for_ssa(zero);
+ nir_intrinsic_set_base(store, VARYING_SLOT_TESS_LEVEL_INNER - i);
+ nir_intrinsic_set_write_mask(store, WRITEMASK_XYZW);
+ nir_builder_instr_insert(&b, &store->instr);
+ }
+
+ /* Copy inputs to outputs. */
+ uint64_t varyings = nir->info.inputs_read;
+
+ while (varyings != 0) {
+ const int varying = ffsll(varyings) - 1;
+
+ load = nir_intrinsic_instr_create(nir,
+nir_intrinsic_load_per_vertex_input);
+ load->num_components = 4;
+ load->src[0] = nir_src_for_ssa(invoc_id);
+ load->src[1] = nir_src_for_ssa(zero);
+ nir_ssa_dest_init(&load->instr, &load->dest, 4, 32, NULL);
+ nir_intrinsic_set_base(load, varying);
+ nir_builder_instr_insert(&b, &load->instr);
+
+ store = nir_intrinsic_instr_create(nir,
+
nir_intrinsic_store_per_vertex_output);
+ store->num_components = 4;
+ store->src[0] = nir_src_for_ssa(&load->dest.ssa);
+ store->src[1] = nir_src_for_ssa(invoc_id);
+ store->src[2] = nir_src_for_ssa(zero);
+ nir_intrinsic_set_base(store, varying);
+ nir_intrinsic_set_write_mask(store, WRITEMASK_XYZW);
+ nir_builder_instr_insert(&b, &store->instr);
+
+ varyings &= ~BITFIELD64_BIT(varying);
+ }
+
+ nir_validate_shader(nir);
+
+ nir = brw_preprocess_nir(compiler, nir);
+
+ return nir;
+}
diff --git a/src/intel/compiler/brw_nir.h b/src/intel/compiler/brw_nir.h
index 06f0e8690e4..2ff8c72b94f 100644
--- a/src/intel/compiler/brw_nir.h
+++ b/src/intel/compiler/brw_nir.h
@@ -164,6 +164,11 @@ nir_shader *brw_nir_optimize(nir_shader *nir,
bool is_scalar,
bool allow_copies);
+nir_shader *brw_nir_create_passthrough_tcs(void *mem_ctx,
+ const struct brw_compiler *compiler,
+ const nir_shader_compiler_options
*options,
+ const struct brw_tcs_prog_key *key);
+
#define BRW_NIR_FRAG_OUTPUT_INDEX_SHIFT 0
#define BRW_NIR_FRAG_OUTPUT_INDEX_MASK INTEL_MASK(0, 0)
#define BRW_NIR_FRAG_OUTPUT_LOCATION_SHIFT 1
diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c
b/src/mesa/drivers/dri/i965/brw_tcs.c
index 823933ef77f..17f4130c095 100644
--- a/src/mesa/drivers/dri/i965/brw_tcs.c
+++ b/src/mesa/drivers/dri/i965/brw_tcs.c
@@ -34,87 +34,6 @@
#include "program/prog_parameter.h"
#include "nir_builder.h"
-static nir_shader *
-create_passthrough_tcs(void *mem_ctx, cons
Re: [Mesa-dev] [PATCH v2 4/5] gitlab-ci: update base + llvm images with scheduled pipelines
"Juan A. Suarez Romero" writes: > On Thu, 2018-09-20 at 16:53 -0700, Eric Anholt wrote: >> "Juan A. Suarez Romero" writes: >> >> > On Tue, 2018-09-04 at 08:19 -0700, Eric Anholt wrote: >> > > "Juan A. Suarez Romero" writes: >> > > >> > > > Use scheduled pipelines to update both the base and the LLVM images. >> > > > >> > > > This way allows to have an updated version of the base images even when >> > > > the respect Rockerfiles keep the same. >> > > >> > > I'm curious: does the scheduled build end up only updating the image >> > > used by the normal CI path if the scheduled build passed tests? >> > >> > Yes, it only updates the base + llvm base images; it does not execute any >> > other >> > task. >> >> That sounds like you're actually saying "no" -- the scheduled build >> would upload a new image, even if the new image with updated packages >> can't build Mesa any more. > > Ah, yes, you're right. It only updates the base images, it doesn't try to > check > if Mesa builds or not. As it only updates the packages, and we are using an > LTS > distro in the base, hopefully it shouldn't break the build too many times. And > if this happens, next push in Mesa will expose the problem. > > We have been using approach for several months in our side, and so far we > never > had this situation. But yes, could happen. OK, if it's LTS I'm a lot less worried, though at that point it feels a little silly to even bother. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 0/5] Use GitLab CI to build Mesa
Hi Juan, On Wed, 29 Aug 2018 at 11:13, Juan A. Suarez Romero wrote: > This is a first part, version 2, of a more complete proposal to use GitLab CI > to > build and test Mesa. This first part just adds the required pieces to build > Mesa, using the different supported tools (meson, autotools, and scons). > > A second part, to be sent in the future, will use the results of the former to > run different tests and verify everything works fine. > > An example of the pipeline that will result from this patchset can be seen at > https://gitlab.freedesktop.org/jasuarez/mesa/pipelines/3070. > > I hope I can explain here all the rationale behind this proposal. Any question > is welcomed. I still have an open NAK since this would DoS our existing fd.o CI runner infrastructure; GitLab itself is fine, but subjecting our elderly build machine with a flaky network on the wrong continent to this would be too much. I'm pretty sure that I'll be able to stand up two sets of runners - one still based in the UK, but on modern and dedicated machines with better network; another on a US-based cloud provider, matching our us-east GitLab master location - before XDC starts, so during XDC we could get those as dedicated runners for a fork of the Mesa project and try to gather some stats and profiles on how they actually perform. Hopefully if it goes well then we should be able to switch them on almost immediately. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 0/6] Let's get rid of 99% of warnings :)
On Fri, 21 Sep 2018 at 19:48, Jason Ekstrand wrote: > You should try building with clang. 😜 > If only there was some way we could do both, in some kind of automated fashion! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 0/6] Let's get rid of 99% of warnings :)
You should try building with clang. 😜 On September 21, 2018 15:51:31 Eric Engestrom wrote: After this, I only see one last warning [1] in all of Mesa \o/ (building with GCC8, YMMV of course, especially with old compilers) [1] nvc0_surface.c:501 the switch doesn't initialise dst_fmt in the `case 12`; I don't really have the time to figure this out though. Eric Engestrom (6): glsl_to_tgsi: silence paranoid compiler's -Wclass-memaccess nouveau: silence paranoid compiler's -Wclass-memaccess r600: silence paranoid compiler's -Wclass-memaccess gallivm: ensure string is null-terminated instead of assert()ing meson: make it trivial to add other -Wno-foo CFLAGS meson+autotools: get rid of spammy GCC warning -Wformat-truncation configure.ac | 2 ++ meson.build | 11 +++ src/gallium/auxiliary/gallivm/lp_bld_printf.c | 4 +--- src/gallium/drivers/nouveau/codegen/nv50_ir.cpp | 2 +- .../drivers/nouveau/codegen/nv50_ir_target.cpp| 2 +- src/gallium/drivers/r600/sb/sb_expr.cpp | 10 +- src/gallium/drivers/r600/sb/sb_if_conversion.cpp | 4 ++-- src/gallium/drivers/r600/sb/sb_ir.h | 2 +- src/gallium/drivers/r600/sb/sb_peephole.cpp | 4 ++-- src/mesa/state_tracker/st_glsl_to_tgsi.cpp| 10 +- 10 files changed, 27 insertions(+), 24 deletions(-) -- Cheers, Eric ___ 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] Lets talk about autotools
On Fri, Sep 21, 2018 at 11:38 AM Emil Velikov wrote: > > On 20 September 2018 at 19:19, Dylan Baker wrote: > > Quoting Eric Engestrom (2018-09-20 07:56:45) > >> On Thursday, 2018-09-20 15:28:09 +0100, Emil Velikov wrote: > >> > Hi Chuck, > >> > > >> > On 18 September 2018 at 16:00, Chuck Atkins > >> > wrote: > >> > > First, I'm fully in support of killing off autotools woo-hoo to that. > >> > > And > >> > > given the substantial investment already put into the meson build that > >> > > certainly seems like a good direction to go. > >> > > > >> > > That being said, the way "auto" is currently implemented leaves quite > >> > > a bit > >> > > to be desired. One of the nice features of the Autotools build was how > >> > > auto-enabled options were treated in that the dependencies were > >> > > searched for > >> > > and if they were all found and met then the option would be enabled. > >> > > My > >> > > experience so far with the meson build has shown this not to be the > >> > > case and > >> > > a "configure" with no options has yet to be successful for me. Many > >> > > of the > >> > > 'auto' options are treated as 'set to true if your platform supports > >> > > it' > >> > > regardless of whether your system has the requisite dependencies > >> > > available. > >> > > For example" > >> > > > >> > > The 'gallium-va' option defaults to 'auto' but the implementation ends > >> > > up > >> > > setting the '_va' option to true if the other option conditions are > >> > > met, > >> > > long before libva is searched for. So then when libva isn't found one > >> > > gets > >> > > an error. > >> > > > >> > > if set to auto then missing the libva dependencies should be a > >> > > failure, it > >> > > should just disable the gallium va state tracker > >> > > > >> > > The platform options set to 'auto' has a set of checks to determine > >> > > which > >> > > platforms are enabled as required. If the system_has_kms_drm check is > >> > > true > >> > > then Wayland is enabled as required. Later if the check for wayland > >> > > dependencies fails, an error occurs. > >> > > > >> > > If platforms are set to auto then a failure to locate dependencies for > >> > > a > >> > > given platform should disable the platform. > >> > > > >> > > I realize these are just two specific examples, each of which can be > >> > > readily > >> > > dealt with in their own specific way so I'm not asking "how to I > >> > > address #1 > >> > > and #2?" because I can certainly do that. These are just two > >> > > instances of > >> > > many though in the way "auto" is dealt with. My point is really a > >> > > broader > >> > > one that before meson becomes the primary build then the behavior of > >> > > "auto" > >> > > should create a successful configure out of the box without additional > >> > > options. > >> > > > >> > I would like to revive an idea from a few years ago: > >> > Drop the "auto" all-together. > >> > > >> > It adds a _ton_ of complexity while making the build semi-magical/not > >> > as deterministic. > >> > IIRC the Gnome people have been actively working for removing such > >> > autodetection in their packages. > >> > > >> > The only downside is that we may need to tweak our scripts _once_ to > >> > list exactly what we want to build ;-) > >> > >> _Once_ for you, because you have everything already set up, but for all > >> the new users this means that nothing will work out of the box, they'll > >> need to understand each and every options and figure out what they need > >> them set to, before they can even start. > >> > >> That sounds like a huge step backwards to me :/ > > > > Especially when one of the explicit goals was to support 4 OS families > > (Unix-like, windows, mac, haiku). To make that all work out of the box we'd > > end > > up building *nothing* by default. > > > As mentioned elsewhere - if you don't know what you're doing (it's > fine to admit that), simply follow your distribution. > If you do not trust your distribution ... well. Otherwise - read. This would generate so many unnecessary support requests. I argued for the same thing years ago, and I've come to agree that automatically picking sane defaults is the best solution for everyone, users and developers alike (for different reasons). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv/cmd_buffer: Require HiZ for WM_HZ_OP stencil clears
Rb. This also fixes simulation errors on gen9; might be worth mentioning that.
On September 21, 2018 19:12:28 Nanley Chery wrote:
Avoid an ICL fulsim failure. Makes 336 crucible tests under
func.depthstencil.stencil-triangles.clear-0x17.ref-0x17.* go from fail
to pass with the simulator.
Fixes: 2cc3445eb24af469537911277f7bc4e73a6c5670
("anv/cmd_buffer: Decide whether or not to HiZ clear up-front")
---
src/intel/vulkan/genX_cmd_buffer.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index a9a8a41ac9d..5f5f2c114ff 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -374,12 +374,6 @@ depth_stencil_attachment_compute_aux_usage(struct
anv_device *device,
return;
}
- if (!(att_state->pending_clear_aspects & VK_IMAGE_ASPECT_DEPTH_BIT)) {
- /* If we're just clearing stencil, we can always HiZ clear */
- att_state->fast_clear = true;
- return;
- }
-
/* Default to false for now */
att_state->fast_clear = false;
@@ -387,6 +381,12 @@ depth_stencil_attachment_compute_aux_usage(struct
anv_device *device,
if (!(iview->image->aspects & VK_IMAGE_ASPECT_DEPTH_BIT))
return;
+ if (att_state->pending_clear_aspects == VK_IMAGE_ASPECT_STENCIL_BIT) {
+ /* If we're just clearing stencil, we can always HiZ clear */
+ att_state->fast_clear = true;
+ return;
+ }
+
const enum isl_aux_usage first_subpass_aux_usage =
anv_layout_to_aux_usage(&device->info, iview->image,
VK_IMAGE_ASPECT_DEPTH_BIT,
--
2.19.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107313] Meson instructions on web site are non-optimal
https://bugs.freedesktop.org/show_bug.cgi?id=107313 Dylan Baker changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/11] util: Add macro to get number of elements in dynarray
On Fri, Sep 21, 2018 at 09:28:53AM +0200, Christian Gmeiner wrote: > Am Sa., 15. Sep. 2018 um 07:45 Uhr schrieb Caio Marcelo de Oliveira > Filho : > > > > --- > > > > I've ended up not using this macro in this series, but it is useful > > for other cases, so kept it here. > > > > I could make use of it. > > Reviewed-by: Christian Gmeiner Nice. Applied it. Thanks, Caio ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] anv/cmd_buffer: Require HiZ for WM_HZ_OP stencil clears
Avoid an ICL fulsim failure. Makes 336 crucible tests under
func.depthstencil.stencil-triangles.clear-0x17.ref-0x17.* go from fail
to pass with the simulator.
Fixes: 2cc3445eb24af469537911277f7bc4e73a6c5670
("anv/cmd_buffer: Decide whether or not to HiZ clear up-front")
---
src/intel/vulkan/genX_cmd_buffer.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index a9a8a41ac9d..5f5f2c114ff 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -374,12 +374,6 @@ depth_stencil_attachment_compute_aux_usage(struct
anv_device *device,
return;
}
- if (!(att_state->pending_clear_aspects & VK_IMAGE_ASPECT_DEPTH_BIT)) {
- /* If we're just clearing stencil, we can always HiZ clear */
- att_state->fast_clear = true;
- return;
- }
-
/* Default to false for now */
att_state->fast_clear = false;
@@ -387,6 +381,12 @@ depth_stencil_attachment_compute_aux_usage(struct
anv_device *device,
if (!(iview->image->aspects & VK_IMAGE_ASPECT_DEPTH_BIT))
return;
+ if (att_state->pending_clear_aspects == VK_IMAGE_ASPECT_STENCIL_BIT) {
+ /* If we're just clearing stencil, we can always HiZ clear */
+ att_state->fast_clear = true;
+ return;
+ }
+
const enum isl_aux_usage first_subpass_aux_usage =
anv_layout_to_aux_usage(&device->info, iview->image,
VK_IMAGE_ASPECT_DEPTH_BIT,
--
2.19.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: Fix driver UUID SHA1 init.
Quoting Emil Velikov (2018-09-21 09:07:58) > On 21 September 2018 at 16:55, Dylan Baker wrote: > > Quoting Emil Velikov (2018-09-21 08:47:30) > >> On 21 September 2018 at 08:19, Juan A. Suarez Romero > >> wrote: > >> > On Thu, 2018-09-20 at 20:16 +0200, Bas Nieuwenhuizen wrote: > >> >> On Thu, Sep 20, 2018 at 7:33 PM Eric Engestrom > >> >> wrote: > >> >> > > >> >> > On Thursday, 2018-09-20 19:17:57 +0200, Bas Nieuwenhuizen wrote: > >> >> > > Was missing the init, found by Emil. > >> >> > > > >> >> > > Fixes: d17443a4593 "radv: Use build ID if available for cache UUID." > >> >> > > >> >> > Reviewed-by: Eric Engestrom > >> >> > > >> >> > > CC: > >> >> > > >> >> > Cc'ing mesa-stable has no effect when you're already adding the > >> >> > proper Fixes: tag :) > >> >> > >> >> Last time I asked about the difference between Fixes and CC, the > >> >> conclusion I got that Fixes is only best effort for the stable > >> >> branches and that if it does not apply it will be dropped silently, > >> >> while for the CC ones the release manager will notify you. > >> >> > >> > > >> > In previous releases that was the way it worked: we always our best > >> > effort to > >> > apply CC and Fixes patches. The difference was that if we couldn't apply > >> > the > >> > patch, then we were only notifying in the pre-announcement "Rejected" > >> > section > >> > about the CC, and silently ignoring the Fixes. > >> > > >> > > >> > But nowadays, we notify about all the candidates to stable, which are CC > >> > and > >> > Fixes. > >> > > >> Here is an alternative wording, hopefully it will make things clearer: > >> > >> Both CC and Fixes work and having both does not hurt. > >> > >> Fixes provides clear indication when/where the problem originates. > >> Cc _explicitly_ requests the patch to be in stable - that's why we > >> have the list + late nominations. > >> > >> It _explicit_ nomination does _not_ apply then the nominator is informed. > >> > >> -Emil > > > > Yeah, that's not useful. We don't need a "you can put this in if you want > > but > > don't tell me if you didn't". Either it's nominated or it's not. If Fixes: > > doesn't mean "I want this in any stable branch with commit X" then we should > > stop using the tag. > > > Fixes means "I want this _anywhere_ with commit X". No idea how you > read my comment otherwise ;-) > > -Emil Where you said CC is _explicit_ but fixes isn't. Having two ways to do the same thing that are subtly different seems like a bad idea to me. I'm going to admit this is just another reason that I feel like our whole stable process is rather fragile and tedious. We have three ways to nominate a patch that are all subtly different, but those differences are not clearly documented. Fixes apparently means "best effort only", Cc means "this must be applied", and Ccing a patch after the fact isn't picked up by the scripts and instad requires the stable maintainer to manually browse a mailing list, which has a very high noise bias in signal to noise ratio. Can we just use gitlab pull requests for stable branches? No fixes tags, no cc stable. If someone wants a patch *any* patch in stable just make a PR. gitlab will tell that person the patch doesn't apply cleanly immediately, and a pipeline can be used to tell them if the patch compiles. I spend at least an hour a day pulling patches, reading mesa-stable, trying to resolve merge conflicts, compile testing, and pushing things through our CI. Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: Fix driver UUID SHA1 init.
On 21 September 2018 at 17:07, Emil Velikov wrote: > On 21 September 2018 at 16:55, Dylan Baker wrote: >> Quoting Emil Velikov (2018-09-21 08:47:30) >>> On 21 September 2018 at 08:19, Juan A. Suarez Romero >>> wrote: >>> > On Thu, 2018-09-20 at 20:16 +0200, Bas Nieuwenhuizen wrote: >>> >> On Thu, Sep 20, 2018 at 7:33 PM Eric Engestrom >>> >> wrote: >>> >> > >>> >> > On Thursday, 2018-09-20 19:17:57 +0200, Bas Nieuwenhuizen wrote: >>> >> > > Was missing the init, found by Emil. >>> >> > > >>> >> > > Fixes: d17443a4593 "radv: Use build ID if available for cache UUID." >>> >> > >>> >> > Reviewed-by: Eric Engestrom >>> >> > >>> >> > > CC: >>> >> > >>> >> > Cc'ing mesa-stable has no effect when you're already adding the >>> >> > proper Fixes: tag :) >>> >> >>> >> Last time I asked about the difference between Fixes and CC, the >>> >> conclusion I got that Fixes is only best effort for the stable >>> >> branches and that if it does not apply it will be dropped silently, >>> >> while for the CC ones the release manager will notify you. >>> >> >>> > >>> > In previous releases that was the way it worked: we always our best >>> > effort to >>> > apply CC and Fixes patches. The difference was that if we couldn't apply >>> > the >>> > patch, then we were only notifying in the pre-announcement "Rejected" >>> > section >>> > about the CC, and silently ignoring the Fixes. >>> > >>> > >>> > But nowadays, we notify about all the candidates to stable, which are CC >>> > and >>> > Fixes. >>> > >>> Here is an alternative wording, hopefully it will make things clearer: >>> >>> Both CC and Fixes work and having both does not hurt. >>> >>> Fixes provides clear indication when/where the problem originates. >>> Cc _explicitly_ requests the patch to be in stable - that's why we >>> have the list + late nominations. >>> >>> It _explicit_ nomination does _not_ apply then the nominator is informed. >>> >>> -Emil >> >> Yeah, that's not useful. We don't need a "you can put this in if you want but >> don't tell me if you didn't". Either it's nominated or it's not. If Fixes: >> doesn't mean "I want this in any stable branch with commit X" then we should >> stop using the tag. >> > Fixes means "I want this _anywhere_ with commit X". No idea how you > read my comment otherwise ;-) > Err that should be "everywhere". -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: Fix driver UUID SHA1 init.
On 21 September 2018 at 16:55, Dylan Baker wrote: > Quoting Emil Velikov (2018-09-21 08:47:30) >> On 21 September 2018 at 08:19, Juan A. Suarez Romero >> wrote: >> > On Thu, 2018-09-20 at 20:16 +0200, Bas Nieuwenhuizen wrote: >> >> On Thu, Sep 20, 2018 at 7:33 PM Eric Engestrom >> >> wrote: >> >> > >> >> > On Thursday, 2018-09-20 19:17:57 +0200, Bas Nieuwenhuizen wrote: >> >> > > Was missing the init, found by Emil. >> >> > > >> >> > > Fixes: d17443a4593 "radv: Use build ID if available for cache UUID." >> >> > >> >> > Reviewed-by: Eric Engestrom >> >> > >> >> > > CC: >> >> > >> >> > Cc'ing mesa-stable has no effect when you're already adding the >> >> > proper Fixes: tag :) >> >> >> >> Last time I asked about the difference between Fixes and CC, the >> >> conclusion I got that Fixes is only best effort for the stable >> >> branches and that if it does not apply it will be dropped silently, >> >> while for the CC ones the release manager will notify you. >> >> >> > >> > In previous releases that was the way it worked: we always our best effort >> > to >> > apply CC and Fixes patches. The difference was that if we couldn't apply >> > the >> > patch, then we were only notifying in the pre-announcement "Rejected" >> > section >> > about the CC, and silently ignoring the Fixes. >> > >> > >> > But nowadays, we notify about all the candidates to stable, which are CC >> > and >> > Fixes. >> > >> Here is an alternative wording, hopefully it will make things clearer: >> >> Both CC and Fixes work and having both does not hurt. >> >> Fixes provides clear indication when/where the problem originates. >> Cc _explicitly_ requests the patch to be in stable - that's why we >> have the list + late nominations. >> >> It _explicit_ nomination does _not_ apply then the nominator is informed. >> >> -Emil > > Yeah, that's not useful. We don't need a "you can put this in if you want but > don't tell me if you didn't". Either it's nominated or it's not. If Fixes: > doesn't mean "I want this in any stable branch with commit X" then we should > stop using the tag. > Fixes means "I want this _anywhere_ with commit X". No idea how you read my comment otherwise ;-) -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: Fix driver UUID SHA1 init.
Quoting Emil Velikov (2018-09-21 08:47:30) > On 21 September 2018 at 08:19, Juan A. Suarez Romero > wrote: > > On Thu, 2018-09-20 at 20:16 +0200, Bas Nieuwenhuizen wrote: > >> On Thu, Sep 20, 2018 at 7:33 PM Eric Engestrom > >> wrote: > >> > > >> > On Thursday, 2018-09-20 19:17:57 +0200, Bas Nieuwenhuizen wrote: > >> > > Was missing the init, found by Emil. > >> > > > >> > > Fixes: d17443a4593 "radv: Use build ID if available for cache UUID." > >> > > >> > Reviewed-by: Eric Engestrom > >> > > >> > > CC: > >> > > >> > Cc'ing mesa-stable has no effect when you're already adding the > >> > proper Fixes: tag :) > >> > >> Last time I asked about the difference between Fixes and CC, the > >> conclusion I got that Fixes is only best effort for the stable > >> branches and that if it does not apply it will be dropped silently, > >> while for the CC ones the release manager will notify you. > >> > > > > In previous releases that was the way it worked: we always our best effort > > to > > apply CC and Fixes patches. The difference was that if we couldn't apply the > > patch, then we were only notifying in the pre-announcement "Rejected" > > section > > about the CC, and silently ignoring the Fixes. > > > > > > But nowadays, we notify about all the candidates to stable, which are CC and > > Fixes. > > > Here is an alternative wording, hopefully it will make things clearer: > > Both CC and Fixes work and having both does not hurt. > > Fixes provides clear indication when/where the problem originates. > Cc _explicitly_ requests the patch to be in stable - that's why we > have the list + late nominations. > > It _explicit_ nomination does _not_ apply then the nominator is informed. > > -Emil Yeah, that's not useful. We don't need a "you can put this in if you want but don't tell me if you didn't". Either it's nominated or it's not. If Fixes: doesn't mean "I want this in any stable branch with commit X" then we should stop using the tag. Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: Use build ID if available for cache UUID.
On 20 September 2018 at 18:24, Bas Nieuwenhuizen
wrote:
> On Thu, Sep 20, 2018 at 1:29 PM Emil Velikov wrote:
>>
>> On 16 September 2018 at 01:58, Bas Nieuwenhuizen
>> wrote:
>> > To get an useful UUID for systems that have a non-useful mtime
>> > for the binaries.
>> >
>> > I started using using SHA1 to ensure we get reasonable mixing
>> > in the various possibilities and the various build id lengths.
>> >
>> > CC:
>> > ---
>> > src/amd/vulkan/radv_device.c | 43 +---
>> > 1 file changed, 35 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
>> > index 8989ec3553f..a2a73089f27 100644
>> > --- a/src/amd/vulkan/radv_device.c
>> > +++ b/src/amd/vulkan/radv_device.c
>> > @@ -45,22 +45,49 @@
>> > #include "sid.h"
>> > #include "gfx9d.h"
>> > #include "addrlib/gfx9/chip/gfx9_enum.h"
>> > +#include "util/build_id.h"
>> > #include "util/debug.h"
>> > +#include "util/mesa-sha1.h"
>> > +
>> > +static bool
>> > +radv_get_build_id(void *ptr, struct mesa_sha1 *ctx)
>> > +{
>> > + uint32_t timestamp;
>> > +
>> > +#ifdef HAVE_DL_ITERATE_PHDR
>> > + const struct build_id_note *note = NULL;
>> > + if ((note = build_id_find_nhdr_for_addr(ptr))) {
>> > + _mesa_sha1_update(ctx, build_id_data(note),
>> > build_id_length(note));
>> > + } else
>> > +#endif
>> > + if (disk_cache_get_function_timestamp(ptr, ×tamp)) {
>> > + if (!timestamp) {
>> > + fprintf(stderr, "radv: The provided filesystem
>> > timestamp for the cache is bogus!\n");
>> > + }
>> > +
>> > + _mesa_sha1_update(ctx, ×tamp, sizeof(timestamp));
>> > + } else
>> > + return false;
>> > + return true;
>> > +}
>> >
>> > static int
>> > radv_device_get_cache_uuid(enum radeon_family family, void *uuid)
>> > {
>> > - uint32_t mesa_timestamp, llvm_timestamp;
>> > - uint16_t f = family;
>> > + struct mesa_sha1 ctx;
>> > + unsigned char sha1[20];
>> > + unsigned ptr_size = sizeof(void*);
>> > memset(uuid, 0, VK_UUID_SIZE);
>> > - if (!disk_cache_get_function_timestamp(radv_device_get_cache_uuid,
>> > &mesa_timestamp) ||
>> > -
>> > !disk_cache_get_function_timestamp(LLVMInitializeAMDGPUTargetInfo,
>> > &llvm_timestamp))
>> > +
>> > + if (!radv_get_build_id(radv_device_get_cache_uuid, &ctx) ||
>> > + !radv_get_build_id(LLVMInitializeAMDGPUTargetInfo, &ctx))
>> > return -1;
>> >
>> > - memcpy(uuid, &mesa_timestamp, 4);
>> > - memcpy((char*)uuid + 4, &llvm_timestamp, 4);
>> > - memcpy((char*)uuid + 8, &f, 2);
>> > - snprintf((char*)uuid + 10, VK_UUID_SIZE - 10, "radv%zd",
>> > sizeof(void *));
>> > + _mesa_sha1_update(&ctx, &family, sizeof(family));
>> > + _mesa_sha1_update(&ctx, &ptr_size, sizeof(ptr_size));
>> > + _mesa_sha1_final(&ctx, sha1);
>> > +
>> A slightly more important thing I did not notice:
>> The _mesa_sha1_init() call is missing, so we're working on an
>> uninitialized stack variable.
>
> wow I missed that, thanks!
>
I'm surprised there was no compiler warning :-\
>>
>> Even then, skimming at radv wrt anv:
>> - driver_uuid is never set, rather fortunately sincep
>> ac_compute_driver_uuid() returns a fixed "AMD-MESA-DRV"
>> ANV does sha1_update(build_id) + sha1_update(chipset_id)
>
>
>>
>> - device_uuid produces a "unique ID" of the bus location, not the device
>> Ideally you'd want bus location + chipset_id + driver specific options.
>> ANV only lacks the bus location, since the device is fixed ;-)
>
> why would we need chipset id? Can there be multiple devices on a bus location?
From the Vulkan spec:
deviceUUID must be immutable for a given device across instances,
processes, driver APIs, driver versions, and system reboots
If you place another card in the came slow (say old one has died) the
UUID will stay the same.
I'm suggesting both bus and chipset since you can have varying
restrictions on the different slots, resulting in perf. or feature
changes.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: Fix driver UUID SHA1 init.
On 21 September 2018 at 08:19, Juan A. Suarez Romero wrote: > On Thu, 2018-09-20 at 20:16 +0200, Bas Nieuwenhuizen wrote: >> On Thu, Sep 20, 2018 at 7:33 PM Eric Engestrom >> wrote: >> > >> > On Thursday, 2018-09-20 19:17:57 +0200, Bas Nieuwenhuizen wrote: >> > > Was missing the init, found by Emil. >> > > >> > > Fixes: d17443a4593 "radv: Use build ID if available for cache UUID." >> > >> > Reviewed-by: Eric Engestrom >> > >> > > CC: >> > >> > Cc'ing mesa-stable has no effect when you're already adding the >> > proper Fixes: tag :) >> >> Last time I asked about the difference between Fixes and CC, the >> conclusion I got that Fixes is only best effort for the stable >> branches and that if it does not apply it will be dropped silently, >> while for the CC ones the release manager will notify you. >> > > In previous releases that was the way it worked: we always our best effort to > apply CC and Fixes patches. The difference was that if we couldn't apply the > patch, then we were only notifying in the pre-announcement "Rejected" section > about the CC, and silently ignoring the Fixes. > > > But nowadays, we notify about all the candidates to stable, which are CC and > Fixes. > Here is an alternative wording, hopefully it will make things clearer: Both CC and Fixes work and having both does not hurt. Fixes provides clear indication when/where the problem originates. Cc _explicitly_ requests the patch to be in stable - that's why we have the list + late nominations. It _explicit_ nomination does _not_ apply then the nominator is informed. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH v2] docs: Update FAQ with respect to s3tc support
On 20 September 2018 at 08:12, Stuart Young wrote:
> It's just over 10 months since 17.3.0 was released with s3tc support enabled.
> Probably a good idea to update the FAQ page.
>
Hey, the note to the release notes is there though ;-)
If anyone beats be to it, feel free to add
Fixes: 04396a134f0 ("mesa: Import libtxc_dxtn sources")
Reviewed-by: Emil Velikov
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: Fix driver UUID SHA1 init.
On 20 September 2018 at 18:17, Bas Nieuwenhuizen wrote: > Was missing the init, found by Emil. > > Fixes: d17443a4593 "radv: Use build ID if available for cache UUID." > CC: Reviewed-by: Emil Velikov -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Lets talk about autotools
On 20 September 2018 at 19:19, Dylan Baker wrote: > Quoting Eric Engestrom (2018-09-20 07:56:45) >> On Thursday, 2018-09-20 15:28:09 +0100, Emil Velikov wrote: >> > Hi Chuck, >> > >> > On 18 September 2018 at 16:00, Chuck Atkins >> > wrote: >> > > First, I'm fully in support of killing off autotools woo-hoo to that. >> > > And >> > > given the substantial investment already put into the meson build that >> > > certainly seems like a good direction to go. >> > > >> > > That being said, the way "auto" is currently implemented leaves quite a >> > > bit >> > > to be desired. One of the nice features of the Autotools build was how >> > > auto-enabled options were treated in that the dependencies were searched >> > > for >> > > and if they were all found and met then the option would be enabled. My >> > > experience so far with the meson build has shown this not to be the case >> > > and >> > > a "configure" with no options has yet to be successful for me. Many of >> > > the >> > > 'auto' options are treated as 'set to true if your platform supports it' >> > > regardless of whether your system has the requisite dependencies >> > > available. >> > > For example" >> > > >> > > The 'gallium-va' option defaults to 'auto' but the implementation ends up >> > > setting the '_va' option to true if the other option conditions are met, >> > > long before libva is searched for. So then when libva isn't found one >> > > gets >> > > an error. >> > > >> > > if set to auto then missing the libva dependencies should be a failure, >> > > it >> > > should just disable the gallium va state tracker >> > > >> > > The platform options set to 'auto' has a set of checks to determine >> > > which >> > > platforms are enabled as required. If the system_has_kms_drm check is >> > > true >> > > then Wayland is enabled as required. Later if the check for wayland >> > > dependencies fails, an error occurs. >> > > >> > > If platforms are set to auto then a failure to locate dependencies for a >> > > given platform should disable the platform. >> > > >> > > I realize these are just two specific examples, each of which can be >> > > readily >> > > dealt with in their own specific way so I'm not asking "how to I address >> > > #1 >> > > and #2?" because I can certainly do that. These are just two instances >> > > of >> > > many though in the way "auto" is dealt with. My point is really a >> > > broader >> > > one that before meson becomes the primary build then the behavior of >> > > "auto" >> > > should create a successful configure out of the box without additional >> > > options. >> > > >> > I would like to revive an idea from a few years ago: >> > Drop the "auto" all-together. >> > >> > It adds a _ton_ of complexity while making the build semi-magical/not >> > as deterministic. >> > IIRC the Gnome people have been actively working for removing such >> > autodetection in their packages. >> > >> > The only downside is that we may need to tweak our scripts _once_ to >> > list exactly what we want to build ;-) >> >> _Once_ for you, because you have everything already set up, but for all >> the new users this means that nothing will work out of the box, they'll >> need to understand each and every options and figure out what they need >> them set to, before they can even start. >> >> That sounds like a huge step backwards to me :/ > > Especially when one of the explicit goals was to support 4 OS families > (Unix-like, windows, mac, haiku). To make that all work out of the box we'd > end > up building *nothing* by default. > As mentioned elsewhere - if you don't know what you're doing (it's fine to admit that), simply follow your distribution. If you do not trust your distribution ... well. Otherwise - read. No my call - you'll be fixing corner-cases in meson ;-) -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 4/6] gallivm: ensure string is null-terminated instead of assert()ing
Quoting Eric Engestrom (2018-09-21 06:50:39)
> Signed-off-by: Eric Engestrom
> ---
> src/gallium/auxiliary/gallivm/lp_bld_printf.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_printf.c
> b/src/gallium/auxiliary/gallivm/lp_bld_printf.c
> index 575ebdfdf65b7fd43b94..cbfa278728b4ec8f4624 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_printf.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_printf.c
> @@ -108,9 +108,7 @@ lp_build_print_value(struct gallivm_state *gallivm,
>type_fmt[5] = '\0';
> } else if (type_kind == LLVMIntegerTypeKind) {
>if (LLVMGetIntTypeWidth(type_ref) == 64) {
> - unsigned flen = strlen(PRId64);
> - assert(flen <= 3);
> - strncpy(type_fmt + 2, PRId64, flen);
> + snprintf(type_fmt + 2, 3, "%s", PRId64);
I think you need to use util_snprintf here since this code can be used on
windows.
>} else if (LLVMGetIntTypeWidth(type_ref) == 8) {
> type_fmt[2] = 'u';
>} else {
> --
> Cheers,
> Eric
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 1/2] docs: update repo URLs after GitLab move
Quoting Emil Velikov (2018-09-21 08:29:48) > On 21 September 2018 at 14:46, Eric Engestrom > wrote: > > I also updated the developer instructions; presumably someone who's been > > given commit rights already knows how to clone a repository :) > > > > A more useful thing is to show how to update the pushurl, and how to use > > access tokens to push over HTTPS (especially for us at Intel, where > > non-http traffic is a pain). > > > Personally I'd omit the Intel mention (in the documentation), but it's > your call. I'd drop the Intel mention. Either way: Reviewed-by: Dylan Baker > For the series: > Reviewed-by: Emil Velikov > > Unrelated: I wish gitlab would stop redirecting when the clone URL is > missing the .git at the end. > The redirection message git throws is fairly annoying :-\ > > Thanks > Emil > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions
On 21 September 2018 at 00:42, Timothy Arceri wrote: > On 20/9/18 11:09 pm, Ian Romanick wrote: >> >> On 09/19/2018 11:36 PM, Federico Dossena wrote: >>> >>> As most of you are probably aware of, id2 and id3 games store GL >>> extensions in a buffer that's too small for modern systems. This usually >>> leads to a crash when MESA_EXTENSION_MAX_YEAR is not set, but what the >>> creator of this commit didn't know is that some id3 games (the more >>> "recent" ones) don't crash, they just truncate the string. As a result >>> of this commit, these games can't detect some extensions and therefore >>> don't work properly. >> >> >> It sounds like the problem is still that MESA_EXTENSION_MAX_YEAR is not >> set, so why not just set it? Doesn't that fix the problem? > > > There is no driconfig option for this currently. Personally I'd rather just > sort the extensions (even if it was only for 32bit builds of Mesa) rather > than adding a bunch of code and extra entry's into driconfig. > > Or are you saying you would prefer we do nothing and people should use > MESA_EXTENSION_MAX_YEAR be required to use? > As mentioned in my other reply there seems to be two type of problems when dealing with some idtech games: - blind copy - leading to crashes - copy + truncation - leading to "missing" extensions Ideally we'll get some driconfig machinery for at least the former. But in the meanwhile feel free to revert my patch. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions
Hi all, On 20 September 2018 at 15:22, Roland Scheidegger wrote: > Am 20.09.2018 um 16:10 schrieb Ian Romanick: >> On 09/20/2018 07:04 AM, Roland Scheidegger wrote: >>> Am 20.09.2018 um 15:09 schrieb Ian Romanick: On 09/19/2018 11:36 PM, Federico Dossena wrote: > As most of you are probably aware of, id2 and id3 games store GL > extensions in a buffer that's too small for modern systems. This usually > leads to a crash when MESA_EXTENSION_MAX_YEAR is not set, but what the > creator of this commit didn't know is that some id3 games (the more > "recent" ones) don't crash, they just truncate the string. As a result > of this commit, these games can't detect some extensions and therefore > don't work properly. It sounds like the problem is still that MESA_EXTENSION_MAX_YEAR is not set, so why not just set it? Doesn't that fix the problem? >>> Yes it does. >>> It is however not really obvious why an app is failing (in this case the >>> game still ran, just shadows were broken - I suppose they were not >>> tested without some extensions being available). >>> I suppose we could try detecting affected apps by name, but I have no >>> idea which are (possibly some later published games using id tech 3 have >>> it fixed for real, I have no idea). >>> It is not a mesa specific problem neither, since apparently windows AMD >>> drivers suffer from the same issue. Maybe nvidia always reorders >>> extensions (or recognizes affected apps). >> >> Or maybe NVIDIA changes the extension string based on the app? > Yes, that's what I basically meant. They could reorder (or cut down) the > string based on app detection. Or they do it always. > Here is the official note from NVIDIA https://download.nvidia.com/XFree86/Linux-x86/340.106/README/knownissues.html#extension_string_size In brief - games will crash (likely due to buffer overflow), workaround by 'selecting' the driver version number. This is more or less what our comment way saying. They are likely to be using a quirks database and applying those locally, Ideally we'll do the same. That said, Star Trek Voyager Elite Force (2000) is doing something slightly different (changes strcpy to strncpy perhaps?), so reverting the patch makes sense. As others have said though - please document things though. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 1/2] docs: update repo URLs after GitLab move
On 21 September 2018 at 14:46, Eric Engestrom wrote: > I also updated the developer instructions; presumably someone who's been > given commit rights already knows how to clone a repository :) > > A more useful thing is to show how to update the pushurl, and how to use > access tokens to push over HTTPS (especially for us at Intel, where > non-http traffic is a pain). > Personally I'd omit the Intel mention (in the documentation), but it's your call. For the series: Reviewed-by: Emil Velikov Unrelated: I wish gitlab would stop redirecting when the clone URL is missing the .git at the end. The redirection message git throws is fairly annoying :-\ Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 6/6] meson+autotools: get rid of spammy GCC warning -Wformat-truncation
On 21 September 2018 at 14:50, Eric Engestrom wrote:
> That warning fires every time a string function takes an argument that
> could possibly be longer than its max output, which triggers all over
> the place, especially when working with file paths ("what if every file
> path is MAX_PATH long?" is what GCC is saying, which is really annoying
> when we *know* that "/dev/dri/cardN" is not gonna be 4096 char long and
> it's safe to store it in a 32-char array).
>
> Anyway, we either add a ton of dead code all over the place to make GCC
> happy, or we get rid of its spam. I chose the latter.
>
This is my preference as well. Thanks
Reviewed-by: Emil Velikov
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107786] [DXVK] MSAA reflections are broken in GTA V
https://bugs.freedesktop.org/show_bug.cgi?id=107786 Samuel Pitoiset changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Samuel Pitoiset --- Should be fixed with https://cgit.freedesktop.org/mesa/mesa/commit/?id=fe3f13cc5a8b70dfb27f8b26c059272e251da390 -- 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] [PATCH mesa 3/6] r600: silence paranoid compiler's -Wclass-memaccess
Signed-off-by: Eric Engestrom
---
src/gallium/drivers/r600/sb/sb_expr.cpp | 10 +-
src/gallium/drivers/r600/sb/sb_if_conversion.cpp | 4 ++--
src/gallium/drivers/r600/sb/sb_ir.h | 2 +-
src/gallium/drivers/r600/sb/sb_peephole.cpp | 4 ++--
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_expr.cpp
b/src/gallium/drivers/r600/sb/sb_expr.cpp
index 05674ff24b88eaaae523..d30fb736c669a0f33df4 100644
--- a/src/gallium/drivers/r600/sb/sb_expr.cpp
+++ b/src/gallium/drivers/r600/sb/sb_expr.cpp
@@ -719,7 +719,7 @@ bool expr_handler::fold_assoc(alu_node *n) {
n->src[0] = n->src[2];
n->bc.src[0] = n->bc.src[2];
n->src[1] = sh.get_const_value(cr);
- memset(&n->bc.src[1], 0, sizeof(bc_alu_src));
+ memset(static_cast(&n->bc.src[1]), 0,
sizeof(bc_alu_src));
n->src.resize(2);
n->bc.set_op(ALU_OP2_ADD);
@@ -729,7 +729,7 @@ bool expr_handler::fold_assoc(alu_node *n) {
n->bc.src[0] = a->bc.src[last_arg];
n->bc.src[0].neg ^= cur_neg;
n->src[1] = sh.get_const_value(cr);
- memset(&n->bc.src[1], 0, sizeof(bc_alu_src));
+ memset(static_cast(&n->bc.src[1]), 0,
sizeof(bc_alu_src));
}
return false;
@@ -770,7 +770,7 @@ bool expr_handler::fold_alu_op2(alu_node& n) {
case ALU_OP2_ADD: // (ADD x, x) => (MUL x, 2)
if (!sh.safe_math) {
n.src[1] = sh.get_const_value(2.0f);
- memset(&n.bc.src[1], 0,
sizeof(bc_alu_src));
+
memset(static_cast(&n.bc.src[1]), 0, sizeof(bc_alu_src));
n.bc.set_op(ALU_OP2_MUL);
return fold_alu_op2(n);
}
@@ -1070,7 +1070,7 @@ bool expr_handler::fold_alu_op3(alu_node& n) {
}
n.src[1] = t;
- memset(&n.bc.src[1], 0, sizeof(bc_alu_src));
+ memset(static_cast(&n.bc.src[1]), 0,
sizeof(bc_alu_src));
n.src.resize(2);
@@ -1101,7 +1101,7 @@ bool expr_handler::fold_alu_op3(alu_node& n) {
dv = cv0.f * cv1.f;
n.bc.set_op(ALU_OP2_ADD);
n.src[0] = sh.get_const_value(dv);
- memset(&n.bc.src[0], 0, sizeof(bc_alu_src));
+ memset(static_cast(&n.bc.src[0]), 0,
sizeof(bc_alu_src));
n.src[1] = n.src[2];
n.bc.src[1] = n.bc.src[2];
n.src.resize(2);
diff --git a/src/gallium/drivers/r600/sb/sb_if_conversion.cpp
b/src/gallium/drivers/r600/sb/sb_if_conversion.cpp
index 017153434fcaaf6e500f..a5813625f920c59ba230 100644
--- a/src/gallium/drivers/r600/sb/sb_if_conversion.cpp
+++ b/src/gallium/drivers/r600/sb/sb_if_conversion.cpp
@@ -99,8 +99,8 @@ void if_conversion::convert_kill_instructions(region_node *r,
a->src[0] = cnd;
a->src[1] = sh.get_const_value(0);
// clear modifiers
- memset(&a->bc.src[0], 0, sizeof(bc_alu_src));
- memset(&a->bc.src[1], 0, sizeof(bc_alu_src));
+ memset(static_cast(&a->bc.src[0]), 0,
sizeof(bc_alu_src));
+ memset(static_cast(&a->bc.src[1]), 0,
sizeof(bc_alu_src));
} else {
// kill with constant 'false' condition, this shouldn't
happen
// but remove it anyway
diff --git a/src/gallium/drivers/r600/sb/sb_ir.h
b/src/gallium/drivers/r600/sb/sb_ir.h
index c7a94fcb930ecd9d9570..4435cbca83013819496b 100644
--- a/src/gallium/drivers/r600/sb/sb_ir.h
+++ b/src/gallium/drivers/r600/sb/sb_ir.h
@@ -1012,7 +1012,7 @@ class cf_node : public container_node {
class alu_node : public node {
protected:
- alu_node() : node(NT_OP, NST_ALU_INST) { memset(&bc, 0,
sizeof(bc_alu)); };
+ alu_node() : node(NT_OP, NST_ALU_INST) {
memset(static_cast(&bc), 0, sizeof(bc_alu)); };
public:
bc_alu bc;
diff --git a/src/gallium/drivers/r600/sb/sb_peephole.cpp
b/src/gallium/drivers/r600/sb/sb_peephole.cpp
index 4390a8f525c87749e2d4..8bbbfa7b1a1f24368cd0 100644
--- a/src/gallium/drivers/r600/sb/sb_peephole.cpp
+++ b/src/gallium/drivers/r600/sb/sb_peephole.cpp
@@ -131,8 +131,8 @@ void peephole::optimize_cc_op2(alu_node* a) {
std::swap(a->src[0],a->src[1]);
swapped = true;
// clear modifiers
- memset(&a->bc.src[0],
[Mesa-dev] [PATCH mesa 5/6] meson: make it trivial to add other -Wno-foo CFLAGS
Signed-off-by: Eric Engestrom
---
meson.build | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meson.build b/meson.build
index 7b7bf4d8e609c92bbd06..863962186caa6afe8ae4 100644
--- a/meson.build
+++ b/meson.build
@@ -790,9 +790,12 @@ foreach a : ['-Wall',
'-Werror=implicit-function-declaration',
c_args += a
endif
endforeach
-if cc.has_argument('-Wmissing-field-initializers')
- c_args += '-Wno-missing-field-initializers'
-endif
+
+foreach a : ['missing-field-initializers']
+ if cc.has_argument('-W' + a)
+c_args += '-Wno-' + a
+ endif
+endforeach
c_vis_args = []
if cc.has_argument('-fvisibility=hidden')
--
Cheers,
Eric
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 6/6] meson+autotools: get rid of spammy GCC warning -Wformat-truncation
That warning fires every time a string function takes an argument that
could possibly be longer than its max output, which triggers all over
the place, especially when working with file paths ("what if every file
path is MAX_PATH long?" is what GCC is saying, which is really annoying
when we *know* that "/dev/dri/cardN" is not gonna be 4096 char long and
it's safe to store it in a 32-char array).
Anyway, we either add a ton of dead code all over the place to make GCC
happy, or we get rid of its spam. I chose the latter.
Signed-off-by: Eric Engestrom
---
configure.ac | 2 ++
meson.build | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 7583a375ad75454215e5..34689826c98e116d4ee7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -307,6 +307,7 @@ AX_CHECK_COMPILE_FLAG([-Werror=missing-prototypes],
[CFLAGS="$CFLAGS
AX_CHECK_COMPILE_FLAG([-Wmissing-prototypes],
[CFLAGS="$CFLAGS -Wmissing-prototypes"])
dnl Dylan Baker: gcc and clang always accepr -Wno-*, hence check for the
original warning, then set the no-* flag
AX_CHECK_COMPILE_FLAG([-Wmissing-field-initializers],
[CFLAGS="$CFLAGS -Wno-missing-field-initializers"])
+AX_CHECK_COMPILE_FLAG([-Wformat-truncation],
[CFLAGS="$CFLAGS -Wno-format-truncation"])
AX_CHECK_COMPILE_FLAG([-fno-math-errno],
[CFLAGS="$CFLAGS -fno-math-errno"])
AX_CHECK_COMPILE_FLAG([-fno-trapping-math],
[CFLAGS="$CFLAGS -fno-trapping-math"])
@@ -321,6 +322,7 @@ AX_CHECK_COMPILE_FLAG([-fno-math-errno],
[CXXFLAGS="$CXXFL
AX_CHECK_COMPILE_FLAG([-fno-trapping-math],
[CXXFLAGS="$CXXFLAGS -fno-trapping-math"])
AX_CHECK_COMPILE_FLAG([-fvisibility=hidden],
[VISIBILITY_CXXFLAGS="-fvisibility=hidden"])
AX_CHECK_COMPILE_FLAG([-Wmissing-field-initializers],
[CXXFLAGS="$CXXFLAGS -Wno-missing-field-initializers"])
+AX_CHECK_COMPILE_FLAG([-Wformat-truncation],
[CXXFLAGS="$CXXFLAGS -Wno-format-truncation"])
AC_LANG_POP([C++])
# Flags to help ensure that certain portions of the code -- and only those
diff --git a/meson.build b/meson.build
index 863962186caa6afe8ae4..094242692d9f9d03440e 100644
--- a/meson.build
+++ b/meson.build
@@ -791,7 +791,7 @@ foreach a : ['-Wall',
'-Werror=implicit-function-declaration',
endif
endforeach
-foreach a : ['missing-field-initializers']
+foreach a : ['missing-field-initializers', 'format-truncation']
if cc.has_argument('-W' + a)
c_args += '-Wno-' + a
endif
@@ -814,7 +814,7 @@ endforeach
# For some reason, the test for -Wno-foo always succeeds with gcc, even if the
# option is not supported. Hence, check for -Wfoo instead.
-foreach a : ['non-virtual-dtor', 'missing-field-initializers']
+foreach a : ['non-virtual-dtor', 'missing-field-initializers',
'format-truncation']
if cpp.has_argument('-W' + a)
cpp_args += '-Wno-' + a
endif
--
Cheers,
Eric
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 4/6] gallivm: ensure string is null-terminated instead of assert()ing
Signed-off-by: Eric Engestrom
---
src/gallium/auxiliary/gallivm/lp_bld_printf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_printf.c
b/src/gallium/auxiliary/gallivm/lp_bld_printf.c
index 575ebdfdf65b7fd43b94..cbfa278728b4ec8f4624 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_printf.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_printf.c
@@ -108,9 +108,7 @@ lp_build_print_value(struct gallivm_state *gallivm,
type_fmt[5] = '\0';
} else if (type_kind == LLVMIntegerTypeKind) {
if (LLVMGetIntTypeWidth(type_ref) == 64) {
- unsigned flen = strlen(PRId64);
- assert(flen <= 3);
- strncpy(type_fmt + 2, PRId64, flen);
+ snprintf(type_fmt + 2, 3, "%s", PRId64);
} else if (LLVMGetIntTypeWidth(type_ref) == 8) {
type_fmt[2] = 'u';
} else {
--
Cheers,
Eric
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 2/6] nouveau: silence paranoid compiler's -Wclass-memaccess
Signed-off-by: Eric Engestrom
---
src/gallium/drivers/nouveau/codegen/nv50_ir.cpp| 2 +-
src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
index 49425b98b9137058c986..62ebc2d24069b7b5f523 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
@@ -905,7 +905,7 @@ Instruction::isCommutationLegal(const Instruction *i) const
TexInstruction::TexInstruction(Function *fn, operation op)
: Instruction(fn, op, TYPE_F32)
{
- memset(&tex, 0, sizeof(tex));
+ memset(static_cast(&tex), 0, sizeof(tex));
tex.rIndirectSrc = -1;
tex.sIndirectSrc = -1;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
index 9193a01f189874a7fb38..b6b9b42964bec670079c 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
@@ -454,7 +454,7 @@ CodeEmitter::addInterp(int ipa, int reg, FixupApply apply)
if (!fixupInfo)
return false;
if (n == 0)
- memset(fixupInfo, 0, sizeof(FixupInfo));
+ memset(static_cast(fixupInfo), 0, sizeof(FixupInfo));
}
++fixupInfo->count;
--
Cheers,
Eric
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 0/6] Let's get rid of 99% of warnings :)
After this, I only see one last warning [1] in all of Mesa \o/ (building with GCC8, YMMV of course, especially with old compilers) [1] nvc0_surface.c:501 the switch doesn't initialise dst_fmt in the `case 12`; I don't really have the time to figure this out though. Eric Engestrom (6): glsl_to_tgsi: silence paranoid compiler's -Wclass-memaccess nouveau: silence paranoid compiler's -Wclass-memaccess r600: silence paranoid compiler's -Wclass-memaccess gallivm: ensure string is null-terminated instead of assert()ing meson: make it trivial to add other -Wno-foo CFLAGS meson+autotools: get rid of spammy GCC warning -Wformat-truncation configure.ac | 2 ++ meson.build | 11 +++ src/gallium/auxiliary/gallivm/lp_bld_printf.c | 4 +--- src/gallium/drivers/nouveau/codegen/nv50_ir.cpp | 2 +- .../drivers/nouveau/codegen/nv50_ir_target.cpp| 2 +- src/gallium/drivers/r600/sb/sb_expr.cpp | 10 +- src/gallium/drivers/r600/sb/sb_if_conversion.cpp | 4 ++-- src/gallium/drivers/r600/sb/sb_ir.h | 2 +- src/gallium/drivers/r600/sb/sb_peephole.cpp | 4 ++-- src/mesa/state_tracker/st_glsl_to_tgsi.cpp| 10 +- 10 files changed, 27 insertions(+), 24 deletions(-) -- Cheers, Eric ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 1/6] glsl_to_tgsi: silence paranoid compiler's -Wclass-memaccess
Signed-off-by: Eric Engestrom
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 5a7e25a274cbfced4b10..602ca4b22c05601f3902 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -2084,7 +2084,7 @@ glsl_to_tgsi_visitor::visit_expression(ir_expression* ir,
st_src_reg *op)
emit_asm(ir, TGSI_OPCODE_USHR, st_dst_reg(index_reg), offset,
st_src_reg_for_int(4));
cbuf.reladdr = ralloc(mem_ctx, st_src_reg);
-memcpy(cbuf.reladdr, &index_reg, sizeof(index_reg));
+memcpy(static_cast(cbuf.reladdr), &index_reg,
sizeof(index_reg));
}
if (const_uniform_block) {
@@ -2093,7 +2093,7 @@ glsl_to_tgsi_visitor::visit_expression(ir_expression* ir,
st_src_reg *op)
} else {
/* Relative/variable constant buffer */
cbuf.reladdr2 = ralloc(mem_ctx, st_src_reg);
-memcpy(cbuf.reladdr2, &op[0], sizeof(st_src_reg));
+memcpy(static_cast(cbuf.reladdr2), &op[0],
sizeof(st_src_reg));
}
cbuf.has_index2 = true;
@@ -2804,12 +2804,12 @@ glsl_to_tgsi_visitor::visit(ir_dereference_array *ir)
if (is_2D) {
src.reladdr2 = ralloc(mem_ctx, st_src_reg);
- memcpy(src.reladdr2, &index_reg, sizeof(index_reg));
+ memcpy(static_cast(src.reladdr2), &index_reg,
sizeof(index_reg));
src.index2D = 0;
src.has_index2 = true;
} else {
src.reladdr = ralloc(mem_ctx, st_src_reg);
- memcpy(src.reladdr, &index_reg, sizeof(index_reg));
+ memcpy(static_cast(src.reladdr), &index_reg,
sizeof(index_reg));
}
}
@@ -4146,7 +4146,7 @@ glsl_to_tgsi_visitor::get_deref_offsets(ir_dereference
*ir,
unsigned location = 0;
ir_variable *var = ir->variable_referenced();
- memset(reladdr, 0, sizeof(*reladdr));
+ memset(static_cast(reladdr), 0, sizeof(*reladdr));
reladdr->file = PROGRAM_UNDEFINED;
*base = 0;
--
Cheers,
Eric
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 2/2] docs: fix couple typos/outdated info
`git-branch` doesn't exist, and mesa3d-dev hasn't been used in a great many years :) Signed-off-by: Eric Engestrom --- docs/repository.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/repository.html b/docs/repository.html index 4f2b02d10f14da948c7b..b8a2a440ddc3b89a1525 100644 --- a/docs/repository.html +++ b/docs/repository.html @@ -142,12 +142,12 @@ Development Branches -The command git-branch will list all available branches. +The command git branch will list all available branches. Questions about branch status/activity should be posted to the -mesa3d-dev mailing list. +mesa-dev mailing list. Developer Git Tips -- Cheers, Eric ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 1/2] docs: update repo URLs after GitLab move
I also updated the developer instructions; presumably someone who's been given commit rights already knows how to clone a repository :) A more useful thing is to show how to update the pushurl, and how to use access tokens to push over HTTPS (especially for us at Intel, where non-http traffic is a pain). Signed-off-by: Eric Engestrom --- docs/download.html | 6 +++--- docs/helpwanted.html | 2 +- docs/repository.html | 35 ++- docs/shading.html | 2 +- docs/sourcedocs.html | 2 +- docs/utilities.html| 2 +- docs/vmware-guest.html | 4 ++-- 7 files changed, 23 insertions(+), 30 deletions(-) diff --git a/docs/download.html b/docs/download.html index 6b2b60cd606cb1c86868..86b4d5063c590bd69aae 100644 --- a/docs/download.html +++ b/docs/download.html @@ -102,9 +102,9 @@ Demos, GLUT, and GLU Mesa releases. But since GLUT, GLU and the demos change infrequently, they were split off into their own git repositories: -https://cgit.freedesktop.org/mesa/glut/";>GLUT, -https://cgit.freedesktop.org/mesa/glu/";>GLU and -https://cgit.freedesktop.org/mesa/demos/";>Demos, +https://gitlab.freedesktop.org/mesa/glut";>GLUT, +https://gitlab.freedesktop.org/mesa/glu";>GLU and +https://gitlab.freedesktop.org/mesa/demos";>Demos, diff --git a/docs/helpwanted.html b/docs/helpwanted.html index 9b7b5e000467f7196349..f9583e6761a33538ba43 100644 --- a/docs/helpwanted.html +++ b/docs/helpwanted.html @@ -47,7 +47,7 @@ Help Wanted / To-Do List Common To-Do lists: - https://cgit.freedesktop.org/mesa/mesa/tree/docs/features.txt";> + https://gitlab.freedesktop.org/mesa/mesa/blob/master/docs/features.txt";> features.txt - Status of OpenGL 3.x / 4.x features in Mesa. diff --git a/docs/repository.html b/docs/repository.html index 802c9a235cb28fa4e801..4f2b02d10f14da948c7b 100644 --- a/docs/repository.html +++ b/docs/repository.html @@ -35,9 +35,9 @@ Code Repository You may also -https://cgit.freedesktop.org/mesa/mesa/"; +https://gitlab.freedesktop.org/mesa/mesa"; >browse the main Mesa git repository and the -https://cgit.freedesktop.org/mesa/demos"; +https://gitlab.freedesktop.org/mesa/demos"; >Mesa demos and tests git repository. @@ -52,7 +52,7 @@ Anonymous git Access Install the git software on your computer if needed. Get an initial, local copy of the repository with: -git clone git://anongit.freedesktop.org/git/mesa/mesa +git clone https://gitlab.freedesktop.org/mesa/mesa.git Later, you can update your tree from the master repository with: @@ -60,7 +60,7 @@ Anonymous git Access If you also want the Mesa demos/tests repository: -git clone git://anongit.freedesktop.org/git/mesa/demos +git clone https://gitlab.freedesktop.org/mesa/demos.git @@ -98,24 +98,17 @@ Developer git Access -Once your account is established: - +Once your account is established, you can update your push url to use SSH: + +git remote set-url --push origin g...@gitlab.freedesktop.org:mesa/mesa.git + - -Get an initial, local copy of the repository with: - -git clone git+ssh://usern...@git.freedesktop.org/git/mesa/mesa - -Replace username with your actual login name. -Later, you can update your tree from the master repository with: - -git pull origin - -If you also want the Mesa demos/tests repository: - -git clone git+ssh://usern...@git.freedesktop.org/git/mesa/demos - - +You can also use https://gitlab.freedesktop.org/profile/personal_access_tokens";>personal access tokens +to push over HTTPS instead (useful for people behind strict proxies, like Intel). +In this case, create a token, and put it in the url as shown here: + +git remote set-url --push origin https://USER:TOKEN@gitlab.freedesktop.org/mesa/mesa.git + Windows Users diff --git a/docs/shading.html b/docs/shading.html index a0bbe997c1b8eeea572f..9e3c7218e31e5ad8385c 100644 --- a/docs/shading.html +++ b/docs/shading.html @@ -85,7 +85,7 @@ Capturing Shaders Setting MESA_SHADER_CAPTURE_PATH to a directory will cause the compiler to write .shader_test files for use with -https://cgit.freedesktop.org/mesa/shader-db";>shader-db, a tool +https://gitlab.freedesktop.org/mesa/shader-db";>shader-db, a tool which compiler developers can use to gather statistics about shaders (instructions, cycles, memory accesses, and so on). diff --git a/docs/sourcedocs.html b/docs/sourcedocs.html index 660dcb2ef0eba3f3c061..10a0810ad22b4e31b201 100644 --- a/docs/sourcedocs.html +++ b/docs/sourcedocs.html @@ -31,7 +31,7 @@ Source Code Documentation For an example of Doxygen usage in Mesa, see a recent source file -such as https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/bufferobj.c";>bufferobj.c. +such as https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/main/bufferobj.c";>bufferobj.c. diff --git a/docs/utilities.html b/docs/utilities.html index 222e73438974eb29cb69..5d7cb17f9dccfca64498 10
Re: [Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions
Am 21.09.2018 um 14:55 schrieb Ian Romanick: > On 09/21/2018 05:36 AM, Federico Dossena wrote: >> Do you know of other applications that are affected by the order or >> extensions? This is the first time I encounter this problem. > > Just the idTech2 and idTech3 games. One thing I think we can do... for > the game where you hit this, can you provide the output of 'strings > game_executable | grep 'GL_[A-Z3]' ? I'll make a piglit test that > verifies that all the supported extensions from that list occur in the > first 4k of the extension string. Having tests will help prevent this > issue from coming back. FWIW the game seems to print out all extensions it can potentially use (not many...). Of course it could theoretically try to use more without printing them out... And apparently the limit at least for star trek voyager appears to be only 2kB (the extension string it prints out is truncated right there at least). From log files Federico sent to me: mesa 17.3.9: Initializing OpenGL driver ...getting DC: succeeded ...GLW_ChoosePFD( 32, 24, 8 ) ...47 PFDs found ...hardware acceleration found ...PIXELFORMAT 45 selected ...creating GL context: succeeded ...making context current: succeeded Initializing OpenGL extensions ...GL_S3_s3tc available ...GL_EXT_texture_compression_s3tc available ...ignoring texture compression ...using GL_EXT_texture_env_add ...GL_EXT_texture_filter_anisotropic not found ...Using GL_EXT_texture_edge_clamp ...using WGL_EXT_swap_control ...using GL_ARB_multitexture ...using GL_EXT_compiled_vertex_array ...WGL_3DFX_gamma_control not found GL_VENDOR: VMware, Inc. GL_RENDERER: llvmpipe (LLVM 6.0, 256 bits) GL_VERSION: 3.0 Mesa 17.3.9 GL_EXTENSIONS: GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture GL_EXT_polygon_offset GL_EXT_subtexture GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters GL_EXT_draw_range_elements GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB GL_ARB_multitexture GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_transpose_matrix GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_secondary_color GL_EXT_texture_env_add GL_EXT_texture_lod_bias GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_S3_s3tc GL_SUN_multi_draw_arrays GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_EXT_framebuffer_object GL_EXT_texture_compression_s3tc GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_MESA_window_pos GL_NV_packed_depth_stencil GL_NV_texture_rectangle GL_ARB_depth_texture GL_ARB_occlusion_query GL_ARB_shadow GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_window_pos GL_ATI_fragment_shader GL_EXT_stencil_two_side GL_EXT_texture_cube_map GL_NV_depth_clamp GL_NV_fog_distance GL_APPLE_packed_pixels GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_shader_objects GL_ARB_vertex_program GL_ARB_vertex_shader GL_ATI_draw_buffers GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_NV_primitive_restart GL_ARB_depth_clamp GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel GL_ARB_occlusion_query2 GL_ARB_point_sprite GL_ARB_sha GL_MAX_TEXTURE_SIZE: 8192 GL_MAX_ACTIVE_TEXTURES_ARB: 8 PIXELFORMAT: color(32-bits) Z(24-bit) stencil(8-bits) MODE: 6, 1024 x 768 fullscreen hz:60 GAMMA: hardware w/ 0 overbright bits CPU: Intel Pentium IV rendering primitives: single glDrawElements texturemode: GL_LINEAR_MIPMAP_NEAREST picmip: 1 picmipmin: 8 texture bits: 0 lightmap texture bits: 0 multitexture: enabled compiled vertex arrays: enabled texenv add: enabled compressed textures: disabled compressed lightmaps: disabled texture compression method: None anisotropic filtering: disabled Forcing glFinish Initializing Shaders - finished R_Init - mesa 18.2.0: Initializing OpenGL driver ...getting DC: succeeded ...GLW_ChoosePFD( 32, 24, 8 ) ...47 PFDs found ...hardware acceleration found ...PIXELFORMAT 45 selected ...creating GL context: succeeded ...making context current: succeeded Initializing OpenGL extensions ...ignoring texture compression ...GL_EXT_texture_env_add not found ...GL_EXT_texture_filter_anisotropic not found ...using WGL_EXT_swap_control ...using GL_ARB_multitexture ...GL_EXT_compiled_vertex_array not found ...WGL_3DFX_gamma_control not found GL_VENDOR: VMware, Inc. GL_RENDERER: llvmpipe (LLVM 6.0, 256 bits) GL_VERSION: 3.1 Mesa 18.2.0 GL_EXTEN
[Mesa-dev] [PATCH v3] mesa: rotation of 0-vector
Specification doesn't define behaviour for rotation of 0-vector.
In https://github.com/KhronosGroup/OpenGL-API/issues/41 said that
behaviour is undefined and agreed that it would be fine for
implementation to do something useful for this.
Windows and Nvidia drivers have a workaround for that.
For compatibility proposed optimized version of computations.
Specification defines a formula of rotation (see "OpenGL 4.6
(Compatibility Profile) - May 14, 2018", paragraph "12.1.1 Matrices").
Optimized formula will look so:
R = cos(angle) * I
That is equavalent to logic that magnitude of (0,0,0)-vector is 1.0.
-v2: logic moved to _math_matrix_rotate
-v3: general optimization of computations
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100960
Signed-off-by: Sergii Romantsov
---
src/mesa/math/m_matrix.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
index 57a4953..3eef122 100644
--- a/src/mesa/math/m_matrix.c
+++ b/src/mesa/math/m_matrix.c
@@ -824,6 +824,18 @@ _math_matrix_rotate( GLmatrix *mat,
M(1,0) = s;
}
}
+ else {
+/* https://bugs.freedesktop.org/show_bug.cgi?id=100960
+ * https://github.com/KhronosGroup/OpenGL-API/issues/41
+ * Here we will treat magnitude as 1.0 if it really 0.0.
+ * So that is kind of workaround for empty-vectors to have
+ * compatibility with Windows and Nvidia drivers.
+ */
+optimized = GL_TRUE;
+M(0,0) = c;
+M(1,1) = c;
+M(2,2) = c;
+ }
}
else if (z == 0.0F) {
optimized = GL_TRUE;
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 108012] Compiler crashes on access of non-existent member incremental operations
https://bugs.freedesktop.org/show_bug.cgi?id=108012 Bug ID: 108012 Summary: Compiler crashes on access of non-existent member incremental operations Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: normal Priority: medium Component: glsl-compiler Assignee: mesa-dev@lists.freedesktop.org Reporter: kevin.rogo...@intel.com QA Contact: intel-3d-b...@lists.freedesktop.org Created attachment 141673 --> https://bugs.freedesktop.org/attachment.cgi?id=141673&action=edit Compiler crashes on incremental of non-existent struct members Compiler crashes on incremental of non-existent struct members, for example having in GLSL code: some_struct.foo += 5; if the type which some_struct is does not contain the member foo. It appears that most (if not all) incremental operator cause a crash in Mesa regardless of the RHS type. All that is needed is that the member of the struct does not exist for Mesa to crash. Crash appeared on current master (git-ab80889e92) and also on Ubuntu 18.04 Mesa (18.0.5) and likely has been in Mesa for quite some time. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions
On 09/21/2018 05:36 AM, Federico Dossena wrote: > Do you know of other applications that are affected by the order or > extensions? This is the first time I encounter this problem. Just the idTech2 and idTech3 games. One thing I think we can do... for the game where you hit this, can you provide the output of 'strings game_executable | grep 'GL_[A-Z3]' ? I'll make a piglit test that verifies that all the supported extensions from that list occur in the first 4k of the extension string. Having tests will help prevent this issue from coming back. > On 2018-09-21 13:56, Ian Romanick wrote: >> On 09/20/2018 04:42 PM, Timothy Arceri wrote: >>> On 20/9/18 11:09 pm, Ian Romanick wrote: On 09/19/2018 11:36 PM, Federico Dossena wrote: > As most of you are probably aware of, id2 and id3 games store GL > extensions in a buffer that's too small for modern systems. This > usually > leads to a crash when MESA_EXTENSION_MAX_YEAR is not set, but what the > creator of this commit didn't know is that some id3 games (the more > "recent" ones) don't crash, they just truncate the string. As a result > of this commit, these games can't detect some extensions and therefore > don't work properly. It sounds like the problem is still that MESA_EXTENSION_MAX_YEAR is not set, so why not just set it? Doesn't that fix the problem? >>> There is no driconfig option for this currently. Personally I'd rather >>> just sort the extensions (even if it was only for 32bit builds of Mesa) >>> rather than adding a bunch of code and extra entry's into driconfig. >>> >>> Or are you saying you would prefer we do nothing and people should use >>> MESA_EXTENSION_MAX_YEAR be required to use? >> I was mostly trying to feel out the current (and possible future) extent >> of the problem space. I've never been fond of the by-year sorting, but >> I don't hate it either. My biggest annoyance is that it feels like >> we've made a bunch of changes to this area over the years without really >> thinking it through... and now we're back here. I don't want to be back >> here in another 2 years. :) >> > I discovered this while trying to figure out why dynamic lights in > Star > Trek Voyager Elite Force (2000) suddenly broke with Mesa 18. I > discussed > this with Ronald Scheidegger, who's been very helpful and helped me > figure out what was going on. > > Personally, I see nothing wrong with reverting this commit and keeping > the extensions sorted by year, it doesn't impact performance and it > doesn't break anything modern. What do you think about it? > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions
On 09/20/2018 04:42 PM, Timothy Arceri wrote: > On 20/9/18 11:09 pm, Ian Romanick wrote: >> On 09/19/2018 11:36 PM, Federico Dossena wrote: >>> As most of you are probably aware of, id2 and id3 games store GL >>> extensions in a buffer that's too small for modern systems. This usually >>> leads to a crash when MESA_EXTENSION_MAX_YEAR is not set, but what the >>> creator of this commit didn't know is that some id3 games (the more >>> "recent" ones) don't crash, they just truncate the string. As a result >>> of this commit, these games can't detect some extensions and therefore >>> don't work properly. >> >> It sounds like the problem is still that MESA_EXTENSION_MAX_YEAR is not >> set, so why not just set it? Doesn't that fix the problem? > > There is no driconfig option for this currently. Personally I'd rather > just sort the extensions (even if it was only for 32bit builds of Mesa) > rather than adding a bunch of code and extra entry's into driconfig. > > Or are you saying you would prefer we do nothing and people should use > MESA_EXTENSION_MAX_YEAR be required to use? I was mostly trying to feel out the current (and possible future) extent of the problem space. I've never been fond of the by-year sorting, but I don't hate it either. My biggest annoyance is that it feels like we've made a bunch of changes to this area over the years without really thinking it through... and now we're back here. I don't want to be back here in another 2 years. :) >>> I discovered this while trying to figure out why dynamic lights in Star >>> Trek Voyager Elite Force (2000) suddenly broke with Mesa 18. I discussed >>> this with Ronald Scheidegger, who's been very helpful and helped me >>> figure out what was going on. >>> >>> Personally, I see nothing wrong with reverting this commit and keeping >>> the extensions sorted by year, it doesn't impact performance and it >>> doesn't break anything modern. What do you think about it? >>> >>> >>> ___ >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Lets talk about autotools
On Tuesday, 2018-09-18 13:43:25 -0700, Dylan Baker wrote:
> Quoting Kai Wasserbäch (2018-09-18 11:14:19)
> > Dylan Baker wrote on 9/18/18 6:40 PM:
> > > Quoting Kai Wasserbäch (2018-09-18 08:56:30)
> > >> Dylan Baker wrote on 9/18/18 5:35 PM:
> > >>> [...]
> > >>>
> > >>> This is something we've discussed upstream several times. I will freely
> > >>> admit
> > >>> that llvm-config is a huge pain in the ass to deal with for a ton of
> > >>> reasons,
> > >>> and since we don't use it at Intel
> > >>
> > >> Since there's now an „APU“ from Intel with an AMD GPU, I guess that is
> > >> no longer
> > >> the case?
> > >
> > > Our relationship with the KBL-G is complicated :)
> >
> > Well, there's also SWR from Intel, which also relies on LLVM...
> >
> > >>> it hasn't been on the top of my list of
> > >>> things to do, and also because the solution upstream wants is very
> > >>> non-trival to
> > >>> implement. This has come up already and I am working on it right now.
> > >>
> > >> If upstream support is unreasonable, I'd like to see a similar solution
> > >> to
> > >> LLVM_CONFIG as it's in autotools today. It must be possible to
> > >> mangle/override
> > >> the meson variables right? (This might be totally ignorant, because I
> > >> was able
> > >> to avoid Meson so far and all other build systems I've worked with, have
> > >> one or
> > >> more options to set variables. Either by having an option in the build
> > >> files or
> > >> by passing some option into the configure step.)
> > >
> > > It really isn't, the only way we could really override this today is to
> > > allow
> > > you to pass a version requirement. One of the guiding ideas of meson is
> > > that
> > > complicated logic like "how the hell do you make a tool as
> > > broken-by-design-and-implementation as llvm-config work" should be part
> > > of meson
> > > itself and not in the local build-system. The downside of that is that
> > > upstream
> > > really wants you to think about how you handle things like overriding a
> > > specific
> > > binary like llvm-config because it has to live with that decision for a
> > > long
> > > time.
> >
> > I'm for the hiding, but why not do it in an easy to change way like the
> > "Find${FOO}.cmake" scripts? As long as you get certain variables populated
> > downstream is happy and an occasional change can be managed, if it should
> > become
> > necessary. Having everything "in the core" sounds rather inflexible to me.
> > Or
> > I'm misunderstanding you. Anyway, this isn't really the topic here.
> >
> > >>> The other option you have it to set the $PATH variable, as long as the
> > >>> llvm-config you want returns the highest version things will work as
> > >>> you expect.
> > >>
> > >> This might do as a workaround, though I'm not too keen on extending
> > >> $PATH. But
> > >> as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain
> > >> that
> > >> versions binaries, putting it first into the path could work.
> > >
> > > meson will cache the llvm-config values, so you should be able to just do
> > > something like:
> > >
> > > PATH=/path/to/my/llvm meson build-with-my-llvm
> >
> > Ok. Where's the cache? In the build directory or is this something, that's
> > kept
> > globally and needs potential clearing? A quick search for this feature
> > yielded
> > . That makes it sound
> > like
> > it is global, which I would almost consider broken design. Or is it local
> > but
> > kept between multiple invocations of meson? That also sounds like a recipe
> > for
> > disaster, though it would be easier to deal with: just nuke the build
> > directory.
>
> It's per build directory, and is kept on subsequent rebuilds. The idea is that
> if you need to reconfigure a build (say meson.build changes) when you do a
> `git
> pull` that pkg-config, llvm-config, and fiends don't get reinvoked, it makes
> the
> rebuild faster. I don't think there is a cache-invalidation method, though
> that
> would be a nice feature to have.
There is :)
$ meson --internal regenerate
>
> Dylan
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107786] [DXVK] MSAA reflections are broken in GTA V
https://bugs.freedesktop.org/show_bug.cgi?id=107786 --- Comment #7 from Gregor Münch --- I can confirm this patch fixes the issue with Dirt3. Cant test GTA V. MSAA is still very slow though, while it has just a small impact on Windows. Thank you very much for the fix! Tested-by: Gregor Münch -- 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] [ANNOUNCE] mesa 18.2.1
Mesa 18.2.1 is now available. In this release we have: Vulkan headers are now updated to 1.1.84. Lot of fixes for Vulkan drivers. In RADV driver there are fixes for crashes in the CTS testsuite, GPU hangs when using indirect descriptors, fixes for VK_EXT_conditional_rendering extension, and some other fixes. On the other hand, ANV driver also contains several fixes related with vertex attributes, disabling cache in SKL GT4 tessellation shader, clamping scissors in framebuffer, support for v3 in VK_EXT_vertex_attribute_divisor extension, and several other fixes. Other fixes are also available for Broadcom's Android driver, radeonsi, r600, v3d, and so on. Meson also gets a couple of fixes, including fixes when compiling 32bit Intel drivers. Andres Gomez (3): docs: add sha256 checksums for 18.2.0 Revert "Revert "glsl: skip stringification in preprocessor if in unreachable branch"" cherry-ignore: i965/tools: 32bit compilation with meson Andrii Simiklit (4): apple/glx/log: added missing va_end() after va_copy() mesa/util: don't use the same 'va_list' instance twice mesa/util: don't ignore NULL returned from 'malloc' mesa/util: add missing va_end() after va_copy() Bas Nieuwenhuizen (5): radv: Support v3 of VK_EXT_vertex_attribute_divisor. radv: Set the user SGPR MSB for Vega. radv: Only allow 16 user SGPRs for compute on GFX9+. radv: Use build ID if available for cache UUID. radv: Fix driver UUID SHA1 init. Christopher Egert (1): radeon: fix ColorMask Dave Airlie (1): virgl: don't send a shader create with no data. (v2) Dylan Baker (1): meson: Print a message about why a libdrm version was selected Eric Anholt (2): v3d: Fix SRC_ALPHA_SATURATE blending for RTs without alpha. v3d: Fix setup of the VCM cache size. Erik Faye-Lund (2): winsys/virgl: avoid unintended behavior virgl: adjust strides when mapping temp-resources Fritz Koenig (2): mesa: Additional FlipY applications mesa: FramebufferParameteri parameter checking Gert Wollny (2): winsys/virgl: correct resource and handle allocation (v2) mesa/texture: Also check for LA texture when querying intensity component size Ian Romanick (1): i965/fs: Don't propagate conditional modifiers from integer compares to adds Jason Ekstrand (11): anv/pipeline: Only consider double elements which actually exist i965: Workaround the gen9 hw astc5x5 sampler bug anv: Re-emit vertex buffers when the pipeline changes anv: Disable the vertex cache when tessellating on SKL GT4 anv: Clamp scissors to the framebuffer boundary vulkan: Update the XML and headers to 1.1.84 anv: Support v3 of VK_EXT_vertex_attribute_divisor anv/query: Write both dwords in emit_zero_queries nir: Add a small pass to rematerialize derefs per-block nir/loop_unroll: Re-materialize derefs in use blocks before unrolling nir/opt_if: Re-materialize derefs in use blocks before peeling loops Josh Pieper (1): st/mesa: Validate the result of pipe_transfer_map in make_texture (v2) Juan A. Suarez Romero (3): cherry-ignore: radv: fix descriptor pool allocation size Update version to 18.2.1 docs: add release notes for 18.2.1 Kenneth Feng (1): amd: Add Picasso device id Marek Olšák (5): radeonsi: fix HTILE for NPOT textures with mipmapping on SI/CI winsys/radeon: fix CMASK fast clear for NPOT textures with mipmapping on SI/CI r600: fix HTILE for NPOT textures with mipmapping radeonsi: fix printing a BO list into ddebug reports ac: revert new LLVM 7.0 behavior for fdiv Mathias Fröhlich (1): tnl: Fix green gun regression in xonotic. Mauro Rossi (3): android: broadcom/genxml: fix collision with intel/genxml header-gen macro android: broadcom/cle: add gallium include path android: broadcom/cle: export the broadcom top level path headers Michel Dänzer (1): loader/dri3: Only wait for back buffer fences in dri3_get_buffer Pierre Moreau (1): nvir: Always split 64-bit IMAD/IMUL operations Samuel Pitoiset (7): radv: fix function names for VK_EXT_conditional_rendering radv: fix VK_EXT_conditional_rendering visibility radv: bump the maximum number of arguments to 64 radv: handle loc->indirect correctly for the first descriptor radv: fix GPU hangs with 32-bit indirect descriptors radv: fix flushing indirect descriptors radv: fix setting global locations for indirect descriptors Sergii Romantsov (3): intel: compiler option msse2 and mstackrealign i965/tools: 32bit compilation with meson mesa/meson: 32bit xmlconfig linkage Timothy Arceri (2): glsl: fixer lexer for unreachable defines Revert "radeonsi: avoid syncing the driver thread in si_fence_finish" git tag: mesa-18.2.1 https://mesa.freedesktop.org/archive/mesa-18.2.1.tar.gz MD5
[Mesa-dev] [Bug 107810] The 'va_end' call is missed after 'va_copy' in 'util_vsnprintf' function under windows
https://bugs.freedesktop.org/show_bug.cgi?id=107810 Juan A. Suarez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Juan A. Suarez --- This landed upstream. Closing. -- 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 107832] Gallium picking A16L16 formats when emulating INTENSITY16 conflicts with mesa
https://bugs.freedesktop.org/show_bug.cgi?id=107832 --- Comment #1 from Juan A. Suarez --- A patch to fix this landed in upstream: commit 47e01e77d8b658606527f048cda786440f7fbe85 Author: Gert Wollny Date: Mon Sep 10 12:39:44 2018 +0200 mesa/texture: Also check for LA texture when querying intensity component size Gallium may pick L16A16_FLOAT to represent GL_INTENSITY16F if no intensity format is provided by the driver. However, when calling glGetTexLevelParameteriv(..., GL_TEXTURE_INTENSITY_SIZE, ...) mesa will return a zero size because the actually used format has no intensity channel and as a fallback only the sizes of the red/green channels are checked. Also checking for LA sizes in the allocated texture resolves this problem. v2: Only check alpha channel size and return it (Marek) L and A size are always the same in this case. Fixes (on virgl): ext_framebuffer_multisample-fast-clear GL_ARB_texture_float * Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107832 Signed-off-by: Gert Wollny Reviewed-by: Marek Olšák src/mesa/main/texparam.c | 5 + 1 file changed, 5 insertions(+) Can you check if this fixes the problem? -- 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 107786] [DXVK] MSAA reflections are broken in GTA V
https://bugs.freedesktop.org/show_bug.cgi?id=107786 --- Comment #6 from Samuel Pitoiset --- This should fix the rendering problem when MSAA is on https://patchwork.freedesktop.org/patch/251674/ I can't confirm for DIRT3 because I don't have the game. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: use the resolve compute path if dest uses multiple layers
The hardware path doesn't support resolving layers, for both
source and destination images.
This fixes a reflection issue when MSAA is enabled which
affects GTA V and probably DIRT3.
CC:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107786
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_meta_resolve.c
b/src/amd/vulkan/radv_meta_resolve.c
index 309c7a5be0..7ce36b1df6 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -346,7 +346,8 @@ static void radv_pick_resolve_method_images(struct
radv_image *src_image,
*method = RESOLVE_COMPUTE;
else if (vk_format_is_int(src_image->vk_format))
*method = RESOLVE_COMPUTE;
- else if (src_image->info.array_size > 1)
+ else if (src_image->info.array_size > 1 ||
+dest_image->info.array_size > 1)
*method = RESOLVE_COMPUTE;
if (radv_layout_dcc_compressed(dest_image, dest_image_layout,
queue_mask)) {
--
2.19.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107786] [DXVK] MSAA reflections are broken in GTA V
https://bugs.freedesktop.org/show_bug.cgi?id=107786 --- Comment #5 from Samuel Pitoiset --- Can you upload a renderdoc capture when MSAA is off and CmdCopyImage() used please? -- 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] [ANNOUNCE] Mesa 18.2.1 release candidate
On Thu, 2018-09-20 at 19:21 +0200, Bas Nieuwenhuizen wrote: > On Wed, Sep 19, 2018 at 11:43 PM Juan A. Suarez Romero > wrote: > > > > Hello list, > > > > The candidate for the Mesa 18.2.1 is now available. Currently we have: > > - 57 queued (+1 squashed) > > - 0 nominated (outstanding) > > - and 2 rejected patches > > > > The current queue consists of: > > > > Vulkan headers are now updated to 1.1.84. > > > > Lot of fixes for Vulkan drivers. > > > > In RADV driver there are fixes for crashes in the CTS testsuite, GPU hangs > > when > > using indirect descriptors, fixes for VK_EXT_conditional_rendering > > extension, > > and some other fixes. > > > > On the other hand, ANV driver also contains several fixes related with > > vertex > > attributes, disabling cache in SKL GT4 tessellation shader, clamping > > scissors in > > framebuffer, support for v3 in VK_EXT_vertex_attribute_divisor extension, > > and > > several other fixes. > > > > Other fixes are also available for Broadcom's Android driver, radeonsi, > > r600, > > v3d, and so on. > > > > Meson also gets a couple of fixes, including fixes when compiling 32bit > > Intel > > drivers. > > > > > > Take a look at section "Mesa stable queue" for more information. > > > > > > Testing reports/general approval > > > > Any testing reports (or general approval of the state of the branch) will be > > greatly appreciated. > > > > The plan is to have 18.2.1 this Friday (21st September), around or shortly > > after 12:00 > > GMT. > > > > If you have any questions or suggestions - be that about the current patch > > queue > > or otherwise, please go ahead. > > > > > > Trivial merge conflicts > > --- > > commit 3f20c0a004e3e8ed4f56114af445ac9eed9e19e6 > > Author: Sergii Romantsov > > > > i965/tools: 32bit compilation with meson > > > > (cherry picked from commit 97fcccb25ed5f55139c03ebc1c71742f0f25f683) > > > > commit f1305c32c1cd4f7c59ef5dfb2eac9edabc70 > > Author: Jason Ekstrand > > > > nir: Add a small pass to rematerialize derefs per-block > > > > (cherry picked from commit 7d1d1208c2b38890fe065b6431ef2e3b7166bae4) > > > > > > Cheers, > > J.A. > > > > > > Mesa stable queue > > - > > > > Nominated (0) > > == > > > > Queued (57) > > === > > Andres Gomez (1): > > Revert "Revert "glsl: skip stringification in preprocessor if in > > unreachable branch"" > > > > Andrii Simiklit (4): > > mesa/util: add missing va_end() after va_copy() > > mesa/util: don't ignore NULL returned from 'malloc' > > mesa/util: don't use the same 'va_list' instance twice > > apple/glx/log: added missing va_end() after va_copy() > > > > Bas Nieuwenhuizen (4): > > radv: Use build ID if available for cache UUID. > > This patch regresses the cache. I just sent a fix forward to the ML > "radv: Fix driver UUID SHA1 init." Please either revert the change or > also include the fix. I'm going to try getting it reviewed and pushed > this evening on master. I'm including this patch in this release. Thanks for telling on time! J.A. > > > > radv: Only allow 16 user SGPRs for compute on GFX9+. > > radv: Set the user SGPR MSB for Vega. > > radv: Support v3 of VK_EXT_vertex_attribute_divisor. > > > > Christopher Egert (1): > > radeon: fix ColorMask > > > > Dave Airlie (1): > > virgl: don't send a shader create with no data. (v2) > > > > Dylan Baker (1): > > meson: Print a message about why a libdrm version was selected > > > > Eric Anholt (2): > > v3d: Fix setup of the VCM cache size. > > v3d: Fix SRC_ALPHA_SATURATE blending for RTs without alpha. > > > > Erik Faye-Lund (2): > > virgl: adjust strides when mapping temp-resources > > winsys/virgl: avoid unintended behavior > > > > Fritz Koenig (2): > > mesa: FramebufferParameteri parameter checking > > mesa: Additional FlipY applications > > > > Gert Wollny (2): > > mesa/texture: Also check for LA texture when querying intensity > > component size > > winsys/virgl: correct resource and handle allocation (v2) > > > > Ian Romanick (1): > > i965/fs: Don't propagate conditional modifiers from integer compares > > to adds > > > > Jason Ekstrand (11): > > nir/opt_if: Re-materialize derefs in use blocks before peeling loops > > nir/loop_unroll: Re-materialize derefs in use blocks before unrolling > > nir: Add a small pass to rematerialize derefs per-block > >Squashed with: > > nir: add initializer data to fix MSVC compile error > > anv/query: Write both dwords in emit_zero_queries > > anv: Support v3 of VK_EXT_vertex_attribute_divisor > > vulkan: Update the XML and headers to 1.1.84 > > anv: Clamp scissors to the framebuffer boundary > > anv: Disable the vertex cache when tessellating on SKL GT4 > > an
Re: [Mesa-dev] [PATCH 02/11] util: Add macro to get number of elements in dynarray
Am Sa., 15. Sep. 2018 um 07:45 Uhr schrieb Caio Marcelo de Oliveira Filho : > > --- > > I've ended up not using this macro in this series, but it is useful > for other cases, so kept it here. > I could make use of it. Reviewed-by: Christian Gmeiner > src/util/u_dynarray.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/util/u_dynarray.h b/src/util/u_dynarray.h > index f74bfc7080b..53dde9241bb 100644 > --- a/src/util/u_dynarray.h > +++ b/src/util/u_dynarray.h > @@ -149,6 +149,7 @@ util_dynarray_trim(struct util_dynarray *buf) > #define util_dynarray_element(buf, type, idx) ((type*)(buf)->data + (idx)) > #define util_dynarray_begin(buf) ((buf)->data) > #define util_dynarray_end(buf) ((void*)util_dynarray_element((buf), char, > (buf)->size)) > +#define util_dynarray_num_elements(buf, type) ((buf)->size / sizeof(type)) > > #define util_dynarray_foreach(buf, type, elem) \ > for (type *elem = (type *)(buf)->data; \ > -- > 2.19.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: Fix driver UUID SHA1 init.
On Thu, 2018-09-20 at 20:16 +0200, Bas Nieuwenhuizen wrote: > On Thu, Sep 20, 2018 at 7:33 PM Eric Engestrom > wrote: > > > > On Thursday, 2018-09-20 19:17:57 +0200, Bas Nieuwenhuizen wrote: > > > Was missing the init, found by Emil. > > > > > > Fixes: d17443a4593 "radv: Use build ID if available for cache UUID." > > > > Reviewed-by: Eric Engestrom > > > > > CC: > > > > Cc'ing mesa-stable has no effect when you're already adding the > > proper Fixes: tag :) > > Last time I asked about the difference between Fixes and CC, the > conclusion I got that Fixes is only best effort for the stable > branches and that if it does not apply it will be dropped silently, > while for the CC ones the release manager will notify you. > In previous releases that was the way it worked: we always our best effort to apply CC and Fixes patches. The difference was that if we couldn't apply the patch, then we were only notifying in the pre-announcement "Rejected" section about the CC, and silently ignoring the Fixes. But nowadays, we notify about all the candidates to stable, which are CC and Fixes. > Given that this is a high priority fix for a regression introduced by > a patch in the 18.2.1 release candidate, I think the extra CC is > justified here. > > > > > --- > > > src/amd/vulkan/radv_device.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c > > > index 7e46a57fb57..31d9bb59637 100644 > > > --- a/src/amd/vulkan/radv_device.c > > > +++ b/src/amd/vulkan/radv_device.c > > > @@ -77,7 +77,9 @@ radv_device_get_cache_uuid(enum radeon_family family, > > > void *uuid) > > > struct mesa_sha1 ctx; > > > unsigned char sha1[20]; > > > unsigned ptr_size = sizeof(void*); > > > + > > > memset(uuid, 0, VK_UUID_SIZE); > > > + _mesa_sha1_init(&ctx); > > > > > > if (!radv_get_build_id(radv_device_get_cache_uuid, &ctx) || > > > !radv_get_build_id(LLVMInitializeAMDGPUTargetInfo, &ctx)) > > > -- > > > 2.19.0 > > > > > > ___ > > > mesa-dev mailing list > > > mesa-dev@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ > mesa-stable mailing list > mesa-sta...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-stable ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106922] radv: corruption issues with Tangrams demo on Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=106922 Samuel Pitoiset changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #10 from Samuel Pitoiset --- So, this demo has several problems: - Not enough memory allocated in a pool which ends up by crashing with RADV. It does work with AMDVLK because they always allocate more space than needed. I pushed a change for that this week, but it was actually wrong and has been reverted. So, expect a crash anyway. - Use of 16-bit integers without checking if shaderInt16 is supported. - Possibly a missing barrier which might explain the rendering glitches on GFX8 (syncing GFX shaders and invalidating L2 seems to fix the problem). Tangrams is buggy in many ways and I don't think it's worth trying to investigate more. -- 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] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions
I agree with Timothy, it's a simple solution and it doesn't break anything. On 2018-09-21 01:42, Timothy Arceri wrote: On 20/9/18 11:09 pm, Ian Romanick wrote: On 09/19/2018 11:36 PM, Federico Dossena wrote: As most of you are probably aware of, id2 and id3 games store GL extensions in a buffer that's too small for modern systems. This usually leads to a crash when MESA_EXTENSION_MAX_YEAR is not set, but what the creator of this commit didn't know is that some id3 games (the more "recent" ones) don't crash, they just truncate the string. As a result of this commit, these games can't detect some extensions and therefore don't work properly. It sounds like the problem is still that MESA_EXTENSION_MAX_YEAR is not set, so why not just set it? Doesn't that fix the problem? There is no driconfig option for this currently. Personally I'd rather just sort the extensions (even if it was only for 32bit builds of Mesa) rather than adding a bunch of code and extra entry's into driconfig. Or are you saying you would prefer we do nothing and people should use MESA_EXTENSION_MAX_YEAR be required to use? I discovered this while trying to figure out why dynamic lights in Star Trek Voyager Elite Force (2000) suddenly broke with Mesa 18. I discussed this with Ronald Scheidegger, who's been very helpful and helped me figure out what was going on. Personally, I see nothing wrong with reverting this commit and keeping the extensions sorted by year, it doesn't impact performance and it doesn't break anything modern. What do you think about it? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 4/5] gitlab-ci: update base + llvm images with scheduled pipelines
On Thu, 2018-09-20 at 16:53 -0700, Eric Anholt wrote: > "Juan A. Suarez Romero" writes: > > > On Tue, 2018-09-04 at 08:19 -0700, Eric Anholt wrote: > > > "Juan A. Suarez Romero" writes: > > > > > > > Use scheduled pipelines to update both the base and the LLVM images. > > > > > > > > This way allows to have an updated version of the base images even when > > > > the respect Rockerfiles keep the same. > > > > > > I'm curious: does the scheduled build end up only updating the image > > > used by the normal CI path if the scheduled build passed tests? > > > > Yes, it only updates the base + llvm base images; it does not execute any > > other > > task. > > That sounds like you're actually saying "no" -- the scheduled build > would upload a new image, even if the new image with updated packages > can't build Mesa any more. Ah, yes, you're right. It only updates the base images, it doesn't try to check if Mesa builds or not. As it only updates the packages, and we are using an LTS distro in the base, hopefully it shouldn't break the build too many times. And if this happens, next push in Mesa will expose the problem. We have been using approach for several months in our side, and so far we never had this situation. But yes, could happen. J.A. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] pci_ids: add new polaris pci id
Reviewed-by: Marek Olšák Marek On Wed, Sep 19, 2018 at 11:14 PM, Alex Deucher wrote: > Signed-off-by: Alex Deucher > Cc: mesa-sta...@lists.freedesktop.org > --- > include/pci_ids/radeonsi_pci_ids.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/pci_ids/radeonsi_pci_ids.h > b/include/pci_ids/radeonsi_pci_ids.h > index c8d30597230..dd2fc3b8f25 100644 > --- a/include/pci_ids/radeonsi_pci_ids.h > +++ b/include/pci_ids/radeonsi_pci_ids.h > @@ -204,6 +204,7 @@ CHIPSET(0x67CC, POLARIS10) > CHIPSET(0x67CF, POLARIS10) > CHIPSET(0x67D0, POLARIS10) > CHIPSET(0x67DF, POLARIS10) > +CHIPSET(0x6FDF, POLARIS10) > > CHIPSET(0x98E4, STONEY) > > -- > 2.13.6 > > ___ > mesa-stable mailing list > mesa-sta...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-stable ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
