[Mesa-dev] [AppVeyor] mesa master #63 completed
Build mesa 63 completed Commit 848d5e444a by Vinson Lee on 8/28/2019 6:56 AM: swr: Fix build with llvm-9.0 again. Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] panfrost: Use ralloc() to allocate instructions to avoid leaking those objs
Instructions attached to blocks are never explicitly freed. Let's
use ralloc() to attach those objects to the compiler context so that
they are automatically freed when the ctx object is freed.
Signed-off-by: Boris Brezillon
---
src/panfrost/midgard/compiler.h| 13 +++--
src/panfrost/midgard/midgard_compile.c | 2 +-
src/panfrost/midgard/midgard_derivatives.c | 2 +-
src/panfrost/midgard/midgard_opt_invert.c | 2 +-
src/panfrost/midgard/midgard_opt_perspective.c | 2 +-
src/panfrost/midgard/midgard_ra.c | 4 ++--
src/panfrost/midgard/midgard_schedule.c| 6 +++---
src/panfrost/midgard/mir_promote_uniforms.c| 2 +-
8 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index f9ba31b5959d..68716f92b0b9 100644
--- a/src/panfrost/midgard/compiler.h
+++ b/src/panfrost/midgard/compiler.h
@@ -288,9 +288,9 @@ typedef struct compiler_context {
/* Append instruction to end of current block */
static inline midgard_instruction *
-mir_upload_ins(struct midgard_instruction ins)
+mir_upload_ins(struct compiler_context *ctx, struct midgard_instruction ins)
{
-midgard_instruction *heap = malloc(sizeof(ins));
+midgard_instruction *heap = ralloc(ctx, struct midgard_instruction);
memcpy(heap, &ins, sizeof(ins));
return heap;
}
@@ -298,15 +298,17 @@ mir_upload_ins(struct midgard_instruction ins)
static inline midgard_instruction *
emit_mir_instruction(struct compiler_context *ctx, struct midgard_instruction
ins)
{
-midgard_instruction *u = mir_upload_ins(ins);
+midgard_instruction *u = mir_upload_ins(ctx, ins);
list_addtail(&u->link, &ctx->current_block->instructions);
return u;
}
static inline struct midgard_instruction *
-mir_insert_instruction_before(struct midgard_instruction *tag, struct
midgard_instruction ins)
+mir_insert_instruction_before(struct compiler_context *ctx,
+ struct midgard_instruction *tag,
+ struct midgard_instruction ins)
{
-struct midgard_instruction *u = mir_upload_ins(ins);
+struct midgard_instruction *u = mir_upload_ins(ctx, ins);
list_addtail(&u->link, &tag->link);
return u;
}
@@ -315,7 +317,6 @@ static inline void
mir_remove_instruction(struct midgard_instruction *ins)
{
list_del(&ins->link);
-free(ins);
}
static inline midgard_instruction*
diff --git a/src/panfrost/midgard/midgard_compile.c
b/src/panfrost/midgard/midgard_compile.c
index 74511b278d16..74796b661df6 100644
--- a/src/panfrost/midgard/midgard_compile.c
+++ b/src/panfrost/midgard/midgard_compile.c
@@ -1962,7 +1962,7 @@ inline_alu_constants(compiler_context *ctx)
alu->src[1] = scratch;
/* Inject us -before- the last instruction
which set r31 */
-
mir_insert_instruction_before(mir_prev_op(alu), ins);
+mir_insert_instruction_before(ctx,
mir_prev_op(alu), ins);
}
}
}
diff --git a/src/panfrost/midgard/midgard_derivatives.c
b/src/panfrost/midgard/midgard_derivatives.c
index ce45b46ecb9c..bfeae5077fce 100644
--- a/src/panfrost/midgard/midgard_derivatives.c
+++ b/src/panfrost/midgard/midgard_derivatives.c
@@ -148,7 +148,7 @@ midgard_lower_derivatives(compiler_context *ctx,
midgard_block *block)
dup.texture.in_reg_swizzle = SWIZZLE_ZWWW;
/* Insert the new instruction */
-mir_insert_instruction_before(mir_next_op(ins), dup);
+mir_insert_instruction_before(ctx, mir_next_op(ins), dup);
/* TODO: Set .cont/.last automatically via dataflow analysis */
ctx->texture_op_count++;
diff --git a/src/panfrost/midgard/midgard_opt_invert.c
b/src/panfrost/midgard/midgard_opt_invert.c
index c3dc8142663e..729169f9a4a8 100644
--- a/src/panfrost/midgard/midgard_opt_invert.c
+++ b/src/panfrost/midgard/midgard_opt_invert.c
@@ -56,7 +56,7 @@ midgard_lower_invert(compiler_context *ctx, midgard_block
*block)
ins->dest = temp;
ins->invert = false;
-mir_insert_instruction_before(mir_next_op(ins), not);
+mir_insert_instruction_before(ctx, mir_next_op(ins), not);
}
}
diff --git a/src/panfrost/midgard/midgard_opt_perspective.c
b/src/panfrost/midgard/midgard_opt_perspective.c
index feec5a5be390..aa4c58c470c2 100644
--- a/src/panfrost/midgard/midgard_opt_perspective.c
+++ b/src/panfrost/midgard/midgard_opt_perspective.c
@@ -125,7 +125,7 @@ midgard_opt_combine_projection(compiler_context *ctx,
midgard_block *block)
}
};
-mir_insert_instruction_before(ins, accel);
+mir_insert_instruction_bef
Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration
I'm not following. I picked MR 1781 not because it was yours, but because it was running on my appveyor account -- https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/26989425 . See for yourself on https://ci.appveyor.com/project/mesa3d/mesa-re1yd/history -- there's plenty of MRs being run there. Here's another one from another person: https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/27006958 The odd thing is that there's no report of Appveyor on https://gitlab.freedesktop.org/cmarcelo/mesa/pipelines/59368 So it seems there are actually two problems: * appveyor is not running for some MRs * even when appveyor is running, it is not reporting back results for all MRs Jose From: Eric Engestrom Sent: Wednesday, August 28, 2019 02:08 To: Jose Fonseca Cc: mesa-dev@lists.freedesktop.org ; Brian Paul Subject: Re: Mesa GitLab <-> AppVeyor integration On Tuesday, 2019-08-27 13:31:22 +, Jose Fonseca wrote: > Appveyor seems to be building other MR 1781: > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.appveyor.com%2Fproject%2Fmesa3d%2Fmesa-re1yd%2Fbuilds%2F26989425&data=02%7C01%7Cjfonseca%40vmware.com%7C46b201504bcd45aca1f408d72b544469%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637025513249945766&sdata=1jROCgNnCM04pscw1K%2FoUWF5qlqWKxzfyW9jbld%2FPoY%3D&reserved=0 > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.appveyor.com%2Fproject%2Fmesa3d%2Fmesa-re1yd%2Fhistory&data=02%7C01%7Cjfonseca%40vmware.com%7C46b201504bcd45aca1f408d72b544469%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637025513249945766&sdata=6pqEuMnrInz7jF4ymROan8nfmPpxx%2BEuk4G9FrKd8ts%3D&reserved=0 > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Feric%2Fmesa%2Fpipelines%2F59190&data=02%7C01%7Cjfonseca%40vmware.com%7C46b201504bcd45aca1f408d72b544469%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637025513249955761&sdata=XICobt%2BBKAIcu8WCtN%2B%2B98w0Mnk5JlIehxjbBaikoOI%3D&reserved=0 You shouldn't take my MRs as an example for this, as I've set up the hook on my account, so my MRs always get picked up by appveyor :) > > I don't know what's special about MR 1779. Perhaps it's just the sheer > volume of merges and merge requests? > > Jose > > > From: Eric Engestrom > Sent: Tuesday, August 27, 2019 14:23 > To: Jose Fonseca > Cc: mesa-dev@lists.freedesktop.org ; Brian > Paul > Subject: Re: Mesa GitLab <-> AppVeyor integration > > On Tuesday, 2019-08-27 10:30:07 +, Jose Fonseca wrote: > > FYI, I've followed Eric Engestroms' instructions for better Mesa <-> > > AppVeyor integration. (Thanks Eric.) > > > > I haven't tested, but hopefully this new integration method should now > > trigger Appveyor builds on pull requests too, which should come handy. > > > > I'm still keeping the old webhook method integration around (with a > > different name.) So the list might receive duplicate notifications. I'll > > disable this when we're satisfied the new method works well. > > > > For the record, these Appveyor runs are running on a separate Appveyor > > account dedicated for Mesa and FDO projects like Piglit, and not my > > personal Appveyor account. > > > > Jose > > Thanks! > > Looks like it didn't quite work though... MR !1779 [1] was created after > your email, and doesn't have the [external/appveyor] job on its pipeline. > > I doubt there's much I could do that you can't to try to debug this, but > feel free to ask me :) > > [1] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F1779&data=02%7C01%7Cjfonseca%40vmware.com%7C46b201504bcd45aca1f408d72b544469%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637025513249955761&sdata=IbHZhB9FV3mATtyZk2WbJKHfxK4xFn9gFoz2BK3CN%2BQ%3D&reserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration
On 2019-08-28 3:08 a.m., Eric Engestrom wrote: > On Tuesday, 2019-08-27 13:31:22 +, Jose Fonseca wrote: >> Appveyor seems to be building other MR 1781: >> >> https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/26989425 >> https://ci.appveyor.com/project/mesa3d/mesa-re1yd/history >> https://gitlab.freedesktop.org/eric/mesa/pipelines/59190 > > You shouldn't take my MRs as an example for this, as I've set up the > hook on my account, so my MRs always get picked up by appveyor :) Yeah, the external integration settings are per GitLab project, and pre-merge CI pipelines for MRs run in the source project context, so the appveyor integration would need to be set up in each forked project used for MRs. This is a bit unfortunate, as it means the CI pipeline which runs (in the main project context) after an MR is merged could fail at the appveyor step, even if the pre-merge pipeline passed. Not sure what can be done about this though, other than requiring forked projects used for MRs to set up the appveyor integration as well. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration
On 28/08/2019 11:18, Michel Dänzer wrote: > On 2019-08-28 3:08 a.m., Eric Engestrom wrote: >> On Tuesday, 2019-08-27 13:31:22 +, Jose Fonseca wrote: >>> Appveyor seems to be building other MR 1781: >>> >>> >>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.appveyor.com%2Fproject%2Fmesa3d%2Fmesa-re1yd%2Fbuilds%2F26989425&data=02%7C01%7Cjfonseca%40vmware.com%7Cfe3cd31e967944da212808d72ba11193%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637025843105542606&sdata=1UouYWYgyMdOVBEvlQgjByq3Scl2yyy%2FEJKfrIM7vNk%3D&reserved=0 >>> >>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fci.appveyor.com%2Fproject%2Fmesa3d%2Fmesa-re1yd%2Fhistory&data=02%7C01%7Cjfonseca%40vmware.com%7Cfe3cd31e967944da212808d72ba11193%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637025843105542606&sdata=uefH8tE%2F0i8D8hn8W9i%2BsS61OuPYrKoAVxNoJkBfS3c%3D&reserved=0 >>> >>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Feric%2Fmesa%2Fpipelines%2F59190&data=02%7C01%7Cjfonseca%40vmware.com%7Cfe3cd31e967944da212808d72ba11193%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637025843105542606&sdata=wIlfbXS1USrnLRnLQJ5sMqDTtyQ2cDTYRolH6UezXco%3D&reserved=0 >> >> You shouldn't take my MRs as an example for this, as I've set up the >> hook on my account, so my MRs always get picked up by appveyor :) > > Yeah, the external integration settings are per GitLab project, and > pre-merge CI pipelines for MRs run in the source project context, so the > appveyor integration would need to be set up in each forked project used > for MRs. > > This is a bit unfortunate, as it means the CI pipeline which runs (in > the main project context) after an MR is merged could fail at the > appveyor step, even if the pre-merge pipeline passed. > > Not sure what can be done about this though, other than requiring forked > projects used for MRs to set up the appveyor integration as well. > > That's unfortunate. Though it looks like Appveyor is actually running MRs: https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/27008264 and notifying mesa-dev about failures: https://lists.freedesktop.org/archives/mesa-dev/2019-August/222329.html It's just unfortunate that there's no mention of it on the actual MR page https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1743 Caio, did you happen to receive any direct email from this? If we can't get these MRs notifcations right, then I think we're better off not running for MRs. To avoid spamming the list. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #71 failed
Build mesa 71 failed Commit 200859f45c by Lionel Landwerlin on 8/28/2019 10:32 AM: anv/wsi: signal the semaphore in the acquireNextImage Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #72 completed
Build mesa 72 completed Commit 200859f45c by Lionel Landwerlin on 8/28/2019 10:39 AM: anv/wsi: signal the semaphore in the acquireNextImage Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] scons: Make GCC builds stricter.
On 2019-08-27 12:57 p.m., Jose Fonseca wrote: > Uses some of the same -Werror options used by Meson, Cool stuff! Good to see you guys starting to take better advantage of the GitLab CI pipeline. > as suggested by Michel Daezer. With my last name spelled correctly Dänzer or Daenzer, Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #75 failed
Build mesa 75 failed Commit 200859f45c by Timothy Arceri on 8/28/2019 11:33 AM: radv: Use GCM Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] scons: Make GCC builds stricter.
Hi Michel, > Good to see you guys starting to take better advantage of the GitLab CI > pipeline. Gitlab CI integration is complicated (very configurable), but I can tell from my experience with my own personal Github projects that having tests run during PRs are a god send. > With my last name spelled correctly Dänzer or Daenzer, Oops. I worried about getting the "ae" right and forgot the "n".. m(_ _)m Jose From: Michel Dänzer Sent: Wednesday, August 28, 2019 11:59 To: Jose Fonseca ; Brian Paul ; Roland Scheidegger ; Charmaine Lee Cc: mesa-dev@lists.freedesktop.org ; e...@engestrom.ch Subject: Re: [Mesa-dev] [PATCH 4/4] scons: Make GCC builds stricter. On 2019-08-27 12:57 p.m., Jose Fonseca wrote: > Uses some of the same -Werror options used by Meson, Cool stuff! Good to see you guys starting to take better advantage of the GitLab CI pipeline. > as suggested by Michel Daezer. With my last name spelled correctly Dänzer or Daenzer, Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fredhat.com&data=02%7C01%7Cjfonseca%40vmware.com%7C00a1f6d6e4524f99fd1308d72ba6d5fe%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637025867896875073&sdata=FT3RG3hSCPhJe5Xdm3JIZ8gvSbjc6gbpsOIi0x3lMa4%3D&reserved=0 Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #76 completed
Build mesa 76 completed Commit 200859f45c by Tapani Pälli on 8/28/2019 11:39 AM: i965: initialize bo_reuse when creating brw_bufmgr Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #78 failed
Build mesa 78 failed Commit 200859f45c by Gert Wollny on 8/28/2019 11:43 AM: r600: Fix interpolateAtCentroid Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #81 failed
Build mesa 81 failed Commit 200859f45c by Gert Wollny on 8/28/2019 11:47 AM: r600: Fix interpolateAtCentroid Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #80 completed
Build mesa 80 completed Commit 200859f45c by Timothy Arceri on 8/28/2019 11:33 AM: anv/i965: Use GCM in nir_optimize Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #83 completed
Build mesa 83 completed Commit 200859f45c by Tapani Pälli on 8/28/2019 11:54 AM: iris: use driconf for 'bo_reuse' parameter Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Use ralloc() to allocate instructions to avoid leaking those objs
Looks good, r-b.
Is it tested?
On Wed, Aug 28, 2019 at 09:32:04AM +0200, Boris Brezillon wrote:
> Instructions attached to blocks are never explicitly freed. Let's
> use ralloc() to attach those objects to the compiler context so that
> they are automatically freed when the ctx object is freed.
>
> Signed-off-by: Boris Brezillon
> ---
> src/panfrost/midgard/compiler.h| 13 +++--
> src/panfrost/midgard/midgard_compile.c | 2 +-
> src/panfrost/midgard/midgard_derivatives.c | 2 +-
> src/panfrost/midgard/midgard_opt_invert.c | 2 +-
> src/panfrost/midgard/midgard_opt_perspective.c | 2 +-
> src/panfrost/midgard/midgard_ra.c | 4 ++--
> src/panfrost/midgard/midgard_schedule.c| 6 +++---
> src/panfrost/midgard/mir_promote_uniforms.c| 2 +-
> 8 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
> index f9ba31b5959d..68716f92b0b9 100644
> --- a/src/panfrost/midgard/compiler.h
> +++ b/src/panfrost/midgard/compiler.h
> @@ -288,9 +288,9 @@ typedef struct compiler_context {
> /* Append instruction to end of current block */
>
> static inline midgard_instruction *
> -mir_upload_ins(struct midgard_instruction ins)
> +mir_upload_ins(struct compiler_context *ctx, struct midgard_instruction ins)
> {
> -midgard_instruction *heap = malloc(sizeof(ins));
> +midgard_instruction *heap = ralloc(ctx, struct midgard_instruction);
> memcpy(heap, &ins, sizeof(ins));
> return heap;
> }
> @@ -298,15 +298,17 @@ mir_upload_ins(struct midgard_instruction ins)
> static inline midgard_instruction *
> emit_mir_instruction(struct compiler_context *ctx, struct
> midgard_instruction ins)
> {
> -midgard_instruction *u = mir_upload_ins(ins);
> +midgard_instruction *u = mir_upload_ins(ctx, ins);
> list_addtail(&u->link, &ctx->current_block->instructions);
> return u;
> }
>
> static inline struct midgard_instruction *
> -mir_insert_instruction_before(struct midgard_instruction *tag, struct
> midgard_instruction ins)
> +mir_insert_instruction_before(struct compiler_context *ctx,
> + struct midgard_instruction *tag,
> + struct midgard_instruction ins)
> {
> -struct midgard_instruction *u = mir_upload_ins(ins);
> +struct midgard_instruction *u = mir_upload_ins(ctx, ins);
> list_addtail(&u->link, &tag->link);
> return u;
> }
> @@ -315,7 +317,6 @@ static inline void
> mir_remove_instruction(struct midgard_instruction *ins)
> {
> list_del(&ins->link);
> -free(ins);
> }
>
> static inline midgard_instruction*
> diff --git a/src/panfrost/midgard/midgard_compile.c
> b/src/panfrost/midgard/midgard_compile.c
> index 74511b278d16..74796b661df6 100644
> --- a/src/panfrost/midgard/midgard_compile.c
> +++ b/src/panfrost/midgard/midgard_compile.c
> @@ -1962,7 +1962,7 @@ inline_alu_constants(compiler_context *ctx)
> alu->src[1] = scratch;
>
> /* Inject us -before- the last instruction
> which set r31 */
> -
> mir_insert_instruction_before(mir_prev_op(alu), ins);
> +mir_insert_instruction_before(ctx,
> mir_prev_op(alu), ins);
> }
> }
> }
> diff --git a/src/panfrost/midgard/midgard_derivatives.c
> b/src/panfrost/midgard/midgard_derivatives.c
> index ce45b46ecb9c..bfeae5077fce 100644
> --- a/src/panfrost/midgard/midgard_derivatives.c
> +++ b/src/panfrost/midgard/midgard_derivatives.c
> @@ -148,7 +148,7 @@ midgard_lower_derivatives(compiler_context *ctx,
> midgard_block *block)
> dup.texture.in_reg_swizzle = SWIZZLE_ZWWW;
>
> /* Insert the new instruction */
> -mir_insert_instruction_before(mir_next_op(ins), dup);
> +mir_insert_instruction_before(ctx, mir_next_op(ins), dup);
>
> /* TODO: Set .cont/.last automatically via dataflow analysis
> */
> ctx->texture_op_count++;
> diff --git a/src/panfrost/midgard/midgard_opt_invert.c
> b/src/panfrost/midgard/midgard_opt_invert.c
> index c3dc8142663e..729169f9a4a8 100644
> --- a/src/panfrost/midgard/midgard_opt_invert.c
> +++ b/src/panfrost/midgard/midgard_opt_invert.c
> @@ -56,7 +56,7 @@ midgard_lower_invert(compiler_context *ctx, midgard_block
> *block)
>
> ins->dest = temp;
> ins->invert = false;
> -mir_insert_instruction_before(mir_next_op(ins), not);
> +mir_insert_instruction_before(ctx, mir_next_op(ins), not);
> }
> }
>
> diff --git a/src/panfrost/midgard/midgard_opt_perspective.c
> b/src/panfrost/midgard/midgard_opt_perspective.c
> index feec5a5be390..aa4c58c470c2 100644
> --- a/src/panfrost/midgard
Re: [Mesa-dev] [PATCH] panfrost: Use ralloc() to allocate instructions to avoid leaking those objs
On Wed, 28 Aug 2019 07:08:18 -0700 Alyssa Rosenzweig wrote: > Looks good, r-b. > > Is it tested? Tested locally, and CI is green (this time I made sure the tests were actually run). Sorry again for introducing a regression with the other patch. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] panfrost: Reset the damage area on imported resources
Reset the damage area in the resource_from_handle() path (as done in
panfrost_resource_create()).
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_resource.c | 23 +++--
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index 1f5b23145cf3..57df61cb71cc 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -47,6 +47,17 @@
#include "pan_util.h"
#include "pan_tiling.h"
+static void
+panfrost_resource_reset_damage(struct panfrost_resource *pres)
+{
+/* We set the damage extent to the full resource size but keep the
+ * damage box empty so that the FB content is reloaded by default.
+ */
+memset(&pres->damage, 0, sizeof(pres->damage));
+pres->damage.extent.maxx = pres->base.width0;
+pres->damage.extent.maxy = pres->base.height0;
+}
+
static struct pipe_resource *
panfrost_resource_from_handle(struct pipe_screen *pscreen,
const struct pipe_resource *templat,
@@ -73,6 +84,7 @@ panfrost_resource_from_handle(struct pipe_screen *pscreen,
rsc->bo = panfrost_drm_import_bo(screen, whandle->handle);
rsc->slices[0].stride = whandle->stride;
rsc->slices[0].initialized = true;
+panfrost_resource_reset_damage(rsc);
if (screen->ro) {
rsc->scanout =
@@ -403,17 +415,6 @@ panfrost_resource_create_bo(struct panfrost_screen
*screen, struct panfrost_reso
pres->bo = panfrost_drm_create_bo(screen, bo_size,
PAN_ALLOCATE_DELAY_MMAP);
}
-static void
-panfrost_resource_reset_damage(struct panfrost_resource *pres)
-{
-/* We set the damage extent to the full resource size but keep the
- * damage box empty so that the FB content is reloaded by default.
- */
-memset(&pres->damage, 0, sizeof(pres->damage));
-pres->damage.extent.maxx = pres->base.width0;
-pres->damage.extent.maxy = pres->base.height0;
-}
-
void
panfrost_resource_set_damage_region(struct pipe_screen *screen,
struct pipe_resource *res,
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Use ralloc() to allocate instructions to avoid leaking those objs
:+1: On Wed, Aug 28, 2019 at 04:14:33PM +0200, Boris Brezillon wrote: > On Wed, 28 Aug 2019 07:08:18 -0700 > Alyssa Rosenzweig wrote: > > > Looks good, r-b. > > > > Is it tested? > > Tested locally, and CI is green (this time I made sure the tests were > actually run). Sorry again for introducing a regression with the other > patch. 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] panfrost: Reset the damage area on imported resources
R-b
On Wed, Aug 28, 2019 at 04:53:15PM +0200, Boris Brezillon wrote:
> Reset the damage area in the resource_from_handle() path (as done in
> panfrost_resource_create()).
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_resource.c | 23 +++--
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_resource.c
> b/src/gallium/drivers/panfrost/pan_resource.c
> index 1f5b23145cf3..57df61cb71cc 100644
> --- a/src/gallium/drivers/panfrost/pan_resource.c
> +++ b/src/gallium/drivers/panfrost/pan_resource.c
> @@ -47,6 +47,17 @@
> #include "pan_util.h"
> #include "pan_tiling.h"
>
> +static void
> +panfrost_resource_reset_damage(struct panfrost_resource *pres)
> +{
> +/* We set the damage extent to the full resource size but keep the
> + * damage box empty so that the FB content is reloaded by default.
> + */
> +memset(&pres->damage, 0, sizeof(pres->damage));
> +pres->damage.extent.maxx = pres->base.width0;
> +pres->damage.extent.maxy = pres->base.height0;
> +}
> +
> static struct pipe_resource *
> panfrost_resource_from_handle(struct pipe_screen *pscreen,
>const struct pipe_resource *templat,
> @@ -73,6 +84,7 @@ panfrost_resource_from_handle(struct pipe_screen *pscreen,
> rsc->bo = panfrost_drm_import_bo(screen, whandle->handle);
> rsc->slices[0].stride = whandle->stride;
> rsc->slices[0].initialized = true;
> +panfrost_resource_reset_damage(rsc);
>
> if (screen->ro) {
> rsc->scanout =
> @@ -403,17 +415,6 @@ panfrost_resource_create_bo(struct panfrost_screen
> *screen, struct panfrost_reso
> pres->bo = panfrost_drm_create_bo(screen, bo_size,
> PAN_ALLOCATE_DELAY_MMAP);
> }
>
> -static void
> -panfrost_resource_reset_damage(struct panfrost_resource *pres)
> -{
> -/* We set the damage extent to the full resource size but keep the
> - * damage box empty so that the FB content is reloaded by default.
> - */
> -memset(&pres->damage, 0, sizeof(pres->damage));
> -pres->damage.extent.maxx = pres->base.width0;
> -pres->damage.extent.maxy = pres->base.height0;
> -}
> -
> void
> panfrost_resource_set_damage_region(struct pipe_screen *screen,
> struct pipe_resource *res,
> --
> 2.21.0
>
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Reset the damage area on imported resources
On Wed, 28 Aug 2019 07:59:21 -0700
Alyssa Rosenzweig wrote:
> R-b
For the record, that was the reason for those damage_width/height = 0
situations you fixed in 0c5633036195 ("panfrost: Workaround bug in
partial update implementation").
>
> On Wed, Aug 28, 2019 at 04:53:15PM +0200, Boris Brezillon wrote:
> > Reset the damage area in the resource_from_handle() path (as done in
> > panfrost_resource_create()).
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > src/gallium/drivers/panfrost/pan_resource.c | 23 +++--
> > 1 file changed, 12 insertions(+), 11 deletions(-)
> >
> > diff --git a/src/gallium/drivers/panfrost/pan_resource.c
> > b/src/gallium/drivers/panfrost/pan_resource.c
> > index 1f5b23145cf3..57df61cb71cc 100644
> > --- a/src/gallium/drivers/panfrost/pan_resource.c
> > +++ b/src/gallium/drivers/panfrost/pan_resource.c
> > @@ -47,6 +47,17 @@
> > #include "pan_util.h"
> > #include "pan_tiling.h"
> >
> > +static void
> > +panfrost_resource_reset_damage(struct panfrost_resource *pres)
> > +{
> > +/* We set the damage extent to the full resource size but keep the
> > + * damage box empty so that the FB content is reloaded by default.
> > + */
> > +memset(&pres->damage, 0, sizeof(pres->damage));
> > +pres->damage.extent.maxx = pres->base.width0;
> > +pres->damage.extent.maxy = pres->base.height0;
> > +}
> > +
> > static struct pipe_resource *
> > panfrost_resource_from_handle(struct pipe_screen *pscreen,
> >const struct pipe_resource *templat,
> > @@ -73,6 +84,7 @@ panfrost_resource_from_handle(struct pipe_screen *pscreen,
> > rsc->bo = panfrost_drm_import_bo(screen, whandle->handle);
> > rsc->slices[0].stride = whandle->stride;
> > rsc->slices[0].initialized = true;
> > +panfrost_resource_reset_damage(rsc);
> >
> > if (screen->ro) {
> > rsc->scanout =
> > @@ -403,17 +415,6 @@ panfrost_resource_create_bo(struct panfrost_screen
> > *screen, struct panfrost_reso
> > pres->bo = panfrost_drm_create_bo(screen, bo_size,
> > PAN_ALLOCATE_DELAY_MMAP);
> > }
> >
> > -static void
> > -panfrost_resource_reset_damage(struct panfrost_resource *pres)
> > -{
> > -/* We set the damage extent to the full resource size but keep the
> > - * damage box empty so that the FB content is reloaded by default.
> > - */
> > -memset(&pres->damage, 0, sizeof(pres->damage));
> > -pres->damage.extent.maxx = pres->base.width0;
> > -pres->damage.extent.maxy = pres->base.height0;
> > -}
> > -
> > void
> > panfrost_resource_set_damage_region(struct pipe_screen *screen,
> > struct pipe_resource *res,
> > --
> > 2.21.0
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #89 failed
Build mesa 89 failed Commit 6e01575b68 by Jan Zielinski on 8/28/2019 3:06 PM: swr/rasterizer: Enable ARB_fragment_layer_viewport Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Reset the damage area on imported resources
Yeah, I gathered given the temporal proximity w/ IRC :)
On Wed, Aug 28, 2019 at 05:02:43PM +0200, Boris Brezillon wrote:
> On Wed, 28 Aug 2019 07:59:21 -0700
> Alyssa Rosenzweig wrote:
>
> > R-b
>
> For the record, that was the reason for those damage_width/height = 0
> situations you fixed in 0c5633036195 ("panfrost: Workaround bug in
> partial update implementation").
>
>
> >
> > On Wed, Aug 28, 2019 at 04:53:15PM +0200, Boris Brezillon wrote:
> > > Reset the damage area in the resource_from_handle() path (as done in
> > > panfrost_resource_create()).
> > >
> > > Signed-off-by: Boris Brezillon
> > > ---
> > > src/gallium/drivers/panfrost/pan_resource.c | 23 +++--
> > > 1 file changed, 12 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/src/gallium/drivers/panfrost/pan_resource.c
> > > b/src/gallium/drivers/panfrost/pan_resource.c
> > > index 1f5b23145cf3..57df61cb71cc 100644
> > > --- a/src/gallium/drivers/panfrost/pan_resource.c
> > > +++ b/src/gallium/drivers/panfrost/pan_resource.c
> > > @@ -47,6 +47,17 @@
> > > #include "pan_util.h"
> > > #include "pan_tiling.h"
> > >
> > > +static void
> > > +panfrost_resource_reset_damage(struct panfrost_resource *pres)
> > > +{
> > > +/* We set the damage extent to the full resource size but keep
> > > the
> > > + * damage box empty so that the FB content is reloaded by
> > > default.
> > > + */
> > > +memset(&pres->damage, 0, sizeof(pres->damage));
> > > +pres->damage.extent.maxx = pres->base.width0;
> > > +pres->damage.extent.maxy = pres->base.height0;
> > > +}
> > > +
> > > static struct pipe_resource *
> > > panfrost_resource_from_handle(struct pipe_screen *pscreen,
> > >const struct pipe_resource *templat,
> > > @@ -73,6 +84,7 @@ panfrost_resource_from_handle(struct pipe_screen
> > > *pscreen,
> > > rsc->bo = panfrost_drm_import_bo(screen, whandle->handle);
> > > rsc->slices[0].stride = whandle->stride;
> > > rsc->slices[0].initialized = true;
> > > +panfrost_resource_reset_damage(rsc);
> > >
> > > if (screen->ro) {
> > > rsc->scanout =
> > > @@ -403,17 +415,6 @@ panfrost_resource_create_bo(struct panfrost_screen
> > > *screen, struct panfrost_reso
> > > pres->bo = panfrost_drm_create_bo(screen, bo_size,
> > > PAN_ALLOCATE_DELAY_MMAP);
> > > }
> > >
> > > -static void
> > > -panfrost_resource_reset_damage(struct panfrost_resource *pres)
> > > -{
> > > -/* We set the damage extent to the full resource size but keep
> > > the
> > > - * damage box empty so that the FB content is reloaded by
> > > default.
> > > - */
> > > -memset(&pres->damage, 0, sizeof(pres->damage));
> > > -pres->damage.extent.maxx = pres->base.width0;
> > > -pres->damage.extent.maxy = pres->base.height0;
> > > -}
> > > -
> > > void
> > > panfrost_resource_set_damage_region(struct pipe_screen *screen,
> > > struct pipe_resource *res,
> > > --
> > > 2.21.0
> > >
>
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #90 completed
Build mesa 90 completed Commit 6e01575b68 by Jan Zielinski on 8/28/2019 3:09 PM: swr/rasterizer: Enable ARB_fragment_layer_viewport Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration
Hi, On Wed, 28 Aug 2019 at 11:18, Michel Dänzer wrote: > On 2019-08-28 3:08 a.m., Eric Engestrom wrote: > > On Tuesday, 2019-08-27 13:31:22 +, Jose Fonseca wrote: > >> Appveyor seems to be building other MR 1781: > >> > >> https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/26989425 > >> https://ci.appveyor.com/project/mesa3d/mesa-re1yd/history > >> https://gitlab.freedesktop.org/eric/mesa/pipelines/59190 > > > > You shouldn't take my MRs as an example for this, as I've set up the > > hook on my account, so my MRs always get picked up by appveyor :) > > Yeah, the external integration settings are per GitLab project, and > pre-merge CI pipelines for MRs run in the source project context, so the > appveyor integration would need to be set up in each forked project used > for MRs. > > This is a bit unfortunate, as it means the CI pipeline which runs (in > the main project context) after an MR is merged could fail at the > appveyor step, even if the pre-merge pipeline passed. > > Not sure what can be done about this though, other than requiring forked > projects used for MRs to set up the appveyor integration as well. To be honest, given the relative immaturity of external-job reporting, and some of the problems reported in #freedesktop for NetworkManager using it, I would probably suggest not using it. For Panfrost CI, which executes on an external system (LAVA), we create a new job in the GitLab CI pipeline with the 'idle-jobs' tag, which submits an HTTP request to LAVA to schedule the job, then sits waiting for it to report results and logs back. The 'idle-jobs' runner can do something like 64 concurrent jobs, as it's supposed to only be used for things like this. That might help with some of the flakiness, and bring the result reporting in line with the rest of execution. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Mark Janes changed: What|Removed |Added Depends on||111490 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=111490 [Bug 111490] [REGRESSION] [BISECTED] Shadow Tactics: Blades of the Shogun - problems rendering water -- 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 111496] dEQP-GLES31.functional.shaders.builtin_functions.integer.umulextended.uint_highp_vertex fails with bad intrinsic
https://bugs.freedesktop.org/show_bug.cgi?id=111496 --- Comment #1 from Roland Scheidegger --- It looks like llvm 7.0+ got rid of the umul intrinsic (the optimized umul code was once used by draw but nowadays it's only used for these 32x32->64bit muls). Need to update the code to follow the autoupgrade pattern of llvm instead. (For unsigned mul that would be bitcast/and/mul/shuffle, for signed it's bitcast/shl/ashr/mul/shuffle.) -- 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 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Clayton Craft changed: What|Removed |Added Depends on||111038 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=111038 [Bug 111038] [regression][bisected][ICL] piglit spec.arb_fragment_program.fp-indirections2 assertion -- 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] gallivm: use fallback code for mul_hi with llvm >= 7.0
From: Roland Scheidegger
LLVM 7.0 ditched the pmulu intrinsics.
This is only a trivial patch to use the fallback code instead.
It'll likely produce atrocious code since the pattern doesn't match what
llvm itself uses in its autoupgrade paths, hence the pattern won't be
recognized.
Should fix https://bugs.freedesktop.org/show_bug.cgi?id=111496
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index c4931c0b230..f1866c6625f 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -1169,8 +1169,13 @@ lp_build_mul_32_lohi_cpu(struct lp_build_context *bld,
* https://llvm.org/bugs/show_bug.cgi?id=30845
* So, whip up our own code, albeit only for length 4 and 8 (which
* should be good enough)...
+* FIXME: For llvm >= 7.0 we should match the autoupgrade pattern
+* (bitcast/and/mul/shuffle for unsigned, bitcast/shl/ashr/mul/shuffle
+* for signed), which the fallback code does not, without this llvm
+* will likely still produce atrocious code.
*/
- if ((bld->type.length == 4 || bld->type.length == 8) &&
+ if (HAVE_LLVM < 0x0700 &&
+ (bld->type.length == 4 || bld->type.length == 8) &&
((util_cpu_caps.has_sse2 && (bld->type.sign == 0)) ||
util_cpu_caps.has_sse4_1)) {
const char *intrinsic = NULL;
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Mark Janes changed: What|Removed |Added Depends on||111203 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=111203 [Bug 111203] [gen9 iris atom] Unigine Heaven gpu hang -- 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 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Clayton Craft changed: What|Removed |Added Depends on||111376 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=111376 [Bug 111376] [bisected] Steam crashes when newest Iris built with LTO -- 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 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Clayton Craft changed: What|Removed |Added Depends on||111339 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=111339 [Bug 111339] [Debug mesa]. Dirt 4 crashes after launching -- 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 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Clayton Craft changed: What|Removed |Added Depends on||111069 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=111069 [Bug 111069] Assertion fails in nir_opt_remove_phis.c during compilation of SPIR-V shader -- 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 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Clayton Craft changed: What|Removed |Added Depends on||111450 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=111450 [Bug 111450] SPIR-V shader causes assertion failure `!"Unsupported deref type"' in ir_build_deref_offset -- 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 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Clayton Craft changed: What|Removed |Added Depends on||111247 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=111247 [Bug 111247] [WebGL Conformance] clipping work incorrectly on y-axis -- 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] [AppVeyor] mesa master #102 failed
Build mesa 102 failed Commit b418269d7d by Vasily Khoruzhick on 8/28/2019 8:30 PM: lima/ppir: clone uniforms, load_coords to each successor Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #103 completed
Build mesa 103 completed Commit b418269d7d by Vasily Khoruzhick on 8/28/2019 8:31 PM: lima/ppir: clone uniforms and load_coords into each successor Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Clayton Craft changed: What|Removed |Added Depends on||110765 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110765 [Bug 110765] ANV regression: Assertion `pass->attachment_count == framebuffer->attachment_count' failed -- 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 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Clayton Craft changed: What|Removed |Added Depends on|111247 | Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=111247 [Bug 111247] [WebGL Conformance] clipping work incorrectly on y-axis -- 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] [AppVeyor] mesa master #107 failed
Build mesa 107 failed Commit 973b49386c by Anuj Phogat on 8/28/2019 8:42 PM: intel/isl/icl: Use halign 8 instead of 4 hw workaround Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #111 failed
Build mesa 111 failed Commit b418269d7d by Vasily Khoruzhick on 8/28/2019 9:05 PM: lima/ppir: clone uniforms and load_coords into each successor Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #114 completed
Build mesa 114 completed Commit cfbde3282d by Vasily Khoruzhick on 8/28/2019 9:08 PM: lima/ppir: clone uniforms and load_coords into each successor Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #117 failed
Build mesa 117 failed Commit cfbde3282d by Erico Nunes on 8/28/2019 9:28 PM: lima/ppir: improve regalloc spill cost calculation Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #119 completed
Build mesa 119 completed Commit cfbde3282d by Eric Anholt on 8/28/2019 9:52 PM: freedreno: Fix the type of single-component scaled vertex attrs. Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: use fallback code for mul_hi with llvm >= 7.0
Reviewed-by: Dave Airlie
On Thu, 29 Aug 2019 at 05:37, wrote:
>
> From: Roland Scheidegger
>
> LLVM 7.0 ditched the pmulu intrinsics.
> This is only a trivial patch to use the fallback code instead.
> It'll likely produce atrocious code since the pattern doesn't match what
> llvm itself uses in its autoupgrade paths, hence the pattern won't be
> recognized.
>
> Should fix https://bugs.freedesktop.org/show_bug.cgi?id=111496
> ---
> src/gallium/auxiliary/gallivm/lp_bld_arit.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> index c4931c0b230..f1866c6625f 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> @@ -1169,8 +1169,13 @@ lp_build_mul_32_lohi_cpu(struct lp_build_context *bld,
> * https://llvm.org/bugs/show_bug.cgi?id=30845
> * So, whip up our own code, albeit only for length 4 and 8 (which
> * should be good enough)...
> +* FIXME: For llvm >= 7.0 we should match the autoupgrade pattern
> +* (bitcast/and/mul/shuffle for unsigned, bitcast/shl/ashr/mul/shuffle
> +* for signed), which the fallback code does not, without this llvm
> +* will likely still produce atrocious code.
> */
> - if ((bld->type.length == 4 || bld->type.length == 8) &&
> + if (HAVE_LLVM < 0x0700 &&
> + (bld->type.length == 4 || bld->type.length == 8) &&
> ((util_cpu_caps.has_sse2 && (bld->type.sign == 0)) ||
> util_cpu_caps.has_sse4_1)) {
>const char *intrinsic = NULL;
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111510] [gallium-nine] [build failure] change in clang CompilerInvocation::CreateFromArgs breaks build
https://bugs.freedesktop.org/show_bug.cgi?id=111510 Bug ID: 111510 Summary: [gallium-nine] [build failure] change in clang CompilerInvocation::CreateFromArgs breaks build Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: Gallium/StateTracker/galliumnine Assignee: mesa-dev@lists.freedesktop.org Reporter: lonew...@xs4all.nl QA Contact: mesa-dev@lists.freedesktop.org building gallium-nine with mesa trunk rev cfbde3282d9 breaks with message /usr/include/clang/Frontend/CompilerInvocation.h:157:15: note: candidate expects 3 arguments, 4 provided checking llvm/clang commits indicates CompilerInvocation was changed recently . See https://github.com/llvm/llvm-project/commit/1fac68b0dc19b03fd2c5e9856f0f2c5a11691348 and https://reviews.llvm.org/D66797 . -- 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 111510] [gallium-nine] [build failure] change in clang CompilerInvocation::CreateFromArgs breaks build
https://bugs.freedesktop.org/show_bug.cgi?id=111510 LoneVVolf changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) -- 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] [AppVeyor] mesa master #128 failed
Build mesa 128 failed Commit 6167a63839 by Dave Airlie on 8/28/2019 11:13 PM: docs: add llvmpipe features for fb_no_attach and compute shaders Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #130 completed
Build mesa 130 completed Commit 6167a63839 by Timur Kristóf on 8/28/2019 11:25 PM: st/nine: Properly initialize GLSL types for NIR shaders. Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] egl/android: Enable HAL_PIXEL_FORMAT_RGBA_FP16 format
The patch adds support for 64 bit HAL_PIXEL_FORMAT_RGBA_FP16
for android platform.
Fixes android.graphics.cts.BitmapColorSpaceTest#test16bitHardware
which failed in egl due to "Unsupported native buffer format 0x16"
on chromebooks.
Change-Id: I44f886fce27fe5f738d2dc229eed8b59088cf6d6
Signed-off-by: Nataraj Deshpande
---
src/egl/drivers/dri2/platform_android.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
index 601b29e..97e7947 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -109,6 +109,9 @@ get_format_bpp(int native)
int bpp;
switch (native) {
+ case HAL_PIXEL_FORMAT_RGBA_FP16:
+ bpp = 8;
+ break;
case HAL_PIXEL_FORMAT_RGBA_:
case HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED:
/*
@@ -143,6 +146,7 @@ static int get_fourcc(int native)
* TODO: Remove this once https://issuetracker.google.com/32077885 is
fixed.
*/
case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FOURCC_XBGR;
+ case HAL_PIXEL_FORMAT_RGBA_FP16: return __DRI_IMAGE_FOURCC_ABGR16161616F;
default:
_eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", native);
}
@@ -161,6 +165,7 @@ static int get_format(int format)
* TODO: Revert this once https://issuetracker.google.com/32077885 is
fixed.
*/
case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FORMAT_XBGR;
+ case HAL_PIXEL_FORMAT_RGBA_FP16: return __DRI_IMAGE_FORMAT_ABGR16161616F;
default:
_eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", format);
}
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #133 failed
Build mesa 133 failed Commit 5f3eb6ef29 by Dave Airlie on 8/28/2019 11:45 PM: docs: add llvmpipe features for fb_no_attach and compute shaders Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration
On Tue, 27 Aug 2019 at 20:30, Jose Fonseca wrote: > > FYI, I've followed Eric Engestroms' instructions for better Mesa <-> AppVeyor > integration. (Thanks Eric.) > > I haven't tested, but hopefully this new integration method should now > trigger Appveyor builds on pull requests too, which should come handy. > > I'm still keeping the old webhook method integration around (with a different > name.) So the list might receive duplicate notifications. I'll disable this > when we're satisfied the new method works well. > > For the record, these Appveyor runs are running on a separate Appveyor > account dedicated for Mesa and FDO projects like Piglit, and not my personal > Appveyor account. It appears all the results are going to mesa-dev, is there a way to send them to the same ppl that would get them from gitlab? I push to some of my PRs quite a lot (esp when llvm version wrangling). Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH kmscube] kmscube: make fb/gl config format settable on cmdline
Instead of changing the code each time, allow the fourcc to be passed
in as an argument.
Signed-off-by: Ilia Mirkin
---
common.c | 4 ++--
common.h | 2 +-
kmscube.c| 20 +++-
texturator.c | 2 +-
4 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/common.c b/common.c
index b6f3e9b..b60b833 100644
--- a/common.c
+++ b/common.c
@@ -40,10 +40,10 @@ gbm_surface_create_with_modifiers(struct gbm_device *gbm,
const uint64_t *modifiers,
const unsigned int count);
-const struct gbm * init_gbm(int drm_fd, int w, int h, uint64_t modifier)
+const struct gbm * init_gbm(int drm_fd, int w, int h, uint32_t format,
uint64_t modifier)
{
gbm.dev = gbm_create_device(drm_fd);
- gbm.format = GBM_FORMAT_XRGB;
+ gbm.format = format;
gbm.surface = NULL;
if (gbm_surface_create_with_modifiers) {
diff --git a/common.h b/common.h
index d461262..6540763 100644
--- a/common.h
+++ b/common.h
@@ -99,7 +99,7 @@ struct gbm {
int width, height;
};
-const struct gbm * init_gbm(int drm_fd, int w, int h, uint64_t modifier);
+const struct gbm * init_gbm(int drm_fd, int w, int h, uint32_t format,
uint64_t modifier);
struct egl {
diff --git a/kmscube.c b/kmscube.c
index 90de638..6a1c2af 100644
--- a/kmscube.c
+++ b/kmscube.c
@@ -46,6 +46,7 @@ static const char *shortopts = "AD:M:m:V:v:";
static const struct option longopts[] = {
{"atomic", no_argument, 0, 'A'},
{"device", required_argument, 0, 'D'},
+ {"format", required_argument, 0, 'f'},
{"mode", required_argument, 0, 'M'},
{"modifier", required_argument, 0, 'm'},
{"samples", required_argument, 0, 's'},
@@ -66,6 +67,7 @@ static void usage(const char *name)
"rgba - rgba textured cube\n"
"nv12-2img - yuv textured (color conversion in
shader)\n"
"nv12-1img - yuv textured (single nv12
texture)\n"
+ "-f, --format=FOURCC framebuffer format\n"
"-m, --modifier=MODIFIER hardcode the selected
modifier\n"
"-s, --samples=N use MSAA\n"
"-V, --video=FILE video textured cube\n"
@@ -81,6 +83,7 @@ int main(int argc, char *argv[])
char mode_str[DRM_DISPLAY_MODE_LEN] = "";
char *p;
enum mode mode = SMOOTH;
+ uint32_t format = DRM_FORMAT_XRGB;
uint64_t modifier = DRM_FORMAT_MOD_LINEAR;
int samples = 0;
int atomic = 0;
@@ -101,6 +104,21 @@ int main(int argc, char *argv[])
case 'D':
device = optarg;
break;
+ case 'f': {
+ char fourcc[4] = "";
+ int length = strlen(optarg);
+ if (length > 0)
+ fourcc[0] = optarg[0];
+ if (length > 1)
+ fourcc[1] = optarg[1];
+ if (length > 2)
+ fourcc[2] = optarg[2];
+ if (length > 3)
+ fourcc[3] = optarg[3];
+ format = fourcc_code(fourcc[0], fourcc[1],
+fourcc[2], fourcc[3]);
+ break;
+ }
case 'M':
if (strcmp(optarg, "smooth") == 0) {
mode = SMOOTH;
@@ -155,7 +173,7 @@ int main(int argc, char *argv[])
}
gbm = init_gbm(drm->fd, drm->mode->hdisplay, drm->mode->vdisplay,
- modifier);
+ format, modifier);
if (!gbm) {
printf("failed to initialize GBM\n");
return -1;
diff --git a/texturator.c b/texturator.c
index ddd8014..555f81f 100644
--- a/texturator.c
+++ b/texturator.c
@@ -955,7 +955,7 @@ int main(int argc, char *argv[])
}
gbm = init_gbm(drm->fd, drm->mode->hdisplay, drm->mode->vdisplay,
- DRM_FORMAT_MOD_LINEAR);
+ DRM_FORMAT_XRGB, DRM_FORMAT_MOD_LINEAR);
if (!gbm) {
printf("failed to initialize GBM\n");
return -1;
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #140 completed
Build mesa 140 completed Commit 5f3eb6ef29 by Dave Airlie on 8/29/2019 1:38 AM: docs: add llvmpipe features for fb_no_attach and compute shaders Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111511] integer cube sampling fails to build shader
https://bugs.freedesktop.org/show_bug.cgi?id=111511 Bug ID: 111511 Summary: integer cube sampling fails to build shader Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: Drivers/Gallium/llvmpipe Assignee: mesa-dev@lists.freedesktop.org Reporter: airl...@freedesktop.org QA Contact: mesa-dev@lists.freedesktop.org dEQP-GLES31.functional.texture.gather.basic.cube.rgba8ui.size_pot.clamp_to_edge_repeat This fails to build due to lp_bld_bitarit.c:130:lp_build_andnot: Assertion `lp_check_value(type, a)' failed. I'm not sure how the averaging corner rules are supposed to work for integer textures (do you have to do integer divide by 3?) but this code has some coord_bld/texel_bld code if I had to guess. lp_build_sample_image_linear in the accurate_cube_corners case. -- 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
