[Mesa-dev] [PATCH] nir/print: Print texture and sampler indices
Commit 5fb69daa6076e56b deleted support from nir_print for printing the
texture and sampler indices on texture instructions. This commit just
brings it back as best as we can.
---
src/compiler/nir/nir_print.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
index 32839fa4dc9..18860db0058 100644
--- a/src/compiler/nir/nir_print.c
+++ b/src/compiler/nir/nir_print.c
@@ -795,6 +795,7 @@ print_tex_instr(nir_tex_instr *instr, print_state *state)
break;
}
+ bool has_texture_deref = false, has_sampler_deref = false;
for (unsigned i = 0; i < instr->num_srcs; i++) {
print_src(>src[i].src, state);
@@ -832,9 +833,11 @@ print_tex_instr(nir_tex_instr *instr, print_state *state)
fprintf(fp, "(ddy)");
break;
case nir_tex_src_texture_deref:
+ has_texture_deref = true;
fprintf(fp, "(texture_deref)");
break;
case nir_tex_src_sampler_deref:
+ has_sampler_deref = true;
fprintf(fp, "(sampler_deref)");
break;
case nir_tex_src_texture_offset:
@@ -858,6 +861,14 @@ print_tex_instr(nir_tex_instr *instr, print_state *state)
if (instr->op == nir_texop_tg4) {
fprintf(fp, "%u (gather_component), ", instr->component);
}
+
+ if (!has_texture_deref) {
+ fprintf(fp, "%u (texture), ", instr->texture_index);
+ }
+
+ if (!has_sampler_deref) {
+ fprintf(fp, "%u (sampler), ", instr->sampler_index);
+ }
}
static void
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nvc0/ir: use the combined tid special register
anyway, I think it might make sense to take a look at the shaders hurt most as I suspect there might be a way to improve the situation a little On Sat, Jul 7, 2018 at 3:38 AM, Karol Herbst wrote: > okay right, if loading those special regs is indeed more expensive > than doing the read + a few extbf then I see the point of this > optimization > > On Sat, Jul 7, 2018 at 2:46 AM, Ilia Mirkin wrote: >> Are they? Fewer special reg loads = better... >> >> On Fri, Jul 6, 2018 at 8:31 PM, Karol Herbst wrote: >>> somehow it doesn't really look like that it is worth the effort as the >>> generated shaders are worse in avg? >>> >>> On Fri, Jul 6, 2018 at 10:32 PM, Rhys Perry >>> wrote: This patch doesn't touch NTID since it seems very difficult (or impossible) to generate. Seemingly because the state tracker or glsl compiler is turning gl_WorkGroupSize into a immediate. Such a transformation is not possible with GL_ARB_compute_variable_group_size but gl_WorkGroupSize is not available when that extension is enabled. On Kepler+, it seems to end up being lowered into constant buffer loads anyway. On Fri, Jul 6, 2018 at 9:21 PM, Rhys Perry wrote: > total instructions in shared programs : 5804448 -> 5804690 (0.00%) > total gprs used in shared programs: 670065 -> 670065 (0.00%) > total shared used in shared programs : 548832 -> 548832 (0.00%) > total local used in shared programs : 21068 -> 21068 (0.00%) > > local sharedgpr inst bytes > helped 0 0 0 5 5 > hurt 0 0 0 191 191 > > Signed-off-by: Rhys Perry > --- > Instead of combining SV_TID reads into a SV_COMBINED_TID read, this has > SV_TID reads lowered into a SV_COMBINED_TID read which can them be > combined by CSE and then turned into a SV_TID read by AlgebraicOpt if it > doesn't create another RDSV. > > src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 + > .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 1 + > .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 1 + > .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 1 + > .../nouveau/codegen/nv50_ir_lowering_nv50.cpp | 3 ++ > .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 12 +++ > .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 40 > ++ > .../drivers/nouveau/codegen/nv50_ir_print.cpp | 1 + > .../nouveau/codegen/nv50_ir_target_nv50.cpp| 1 + > 9 files changed, 61 insertions(+) > > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h > b/src/gallium/drivers/nouveau/codegen/nv50_ir.h > index f4f3c70888..0b220cc48d 100644 > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h > @@ -453,6 +453,7 @@ enum SVSemantic > SV_TESS_INNER, > SV_TESS_COORD, > SV_TID, > + SV_COMBINED_TID, > SV_CTAID, > SV_NTID, > SV_GRIDID, > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp > b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp > index 647d1a5d0e..2118c3153f 100644 > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp > @@ -2297,6 +2297,7 @@ CodeEmitterGK110::getSRegEncoding(const ValueRef& > ref) > case SV_INVOCATION_ID: return 0x11; > case SV_YDIR: return 0x12; > case SV_THREAD_KILL: return 0x13; > + case SV_COMBINED_TID: return 0x20; > case SV_TID: return 0x21 + SDATA(ref).sv.index; > case SV_CTAID: return 0x25 + SDATA(ref).sv.index; > case SV_NTID: return 0x29 + SDATA(ref).sv.index; > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > index 26826d6360..694d1b10a3 100644 > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > @@ -267,6 +267,7 @@ CodeEmitterGM107::emitSYS(int pos, const Value *val) > case SV_INVOCATION_ID : id = 0x11; break; > case SV_THREAD_KILL: id = 0x13; break; > case SV_INVOCATION_INFO: id = 0x1d; break; > + case SV_COMBINED_TID : id = 0x20; break; > case SV_TID: id = 0x21 + val->reg.data.sv.index; break; > case SV_CTAID : id = 0x25 + val->reg.data.sv.index; break; > case SV_LANEMASK_EQ: id = 0x38; break; > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp > b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp > index
Re: [Mesa-dev] [PATCH] nvc0/ir: use the combined tid special register
okay right, if loading those special regs is indeed more expensive than doing the read + a few extbf then I see the point of this optimization On Sat, Jul 7, 2018 at 2:46 AM, Ilia Mirkin wrote: > Are they? Fewer special reg loads = better... > > On Fri, Jul 6, 2018 at 8:31 PM, Karol Herbst wrote: >> somehow it doesn't really look like that it is worth the effort as the >> generated shaders are worse in avg? >> >> On Fri, Jul 6, 2018 at 10:32 PM, Rhys Perry wrote: >>> This patch doesn't touch NTID since it seems very difficult (or >>> impossible) to generate. Seemingly because the state tracker or glsl >>> compiler is turning gl_WorkGroupSize into a immediate. Such a >>> transformation is not possible with GL_ARB_compute_variable_group_size >>> but gl_WorkGroupSize is not available when that extension is enabled. >>> >>> On Kepler+, it seems to end up being lowered into constant buffer loads >>> anyway. >>> >>> On Fri, Jul 6, 2018 at 9:21 PM, Rhys Perry wrote: total instructions in shared programs : 5804448 -> 5804690 (0.00%) total gprs used in shared programs: 670065 -> 670065 (0.00%) total shared used in shared programs : 548832 -> 548832 (0.00%) total local used in shared programs : 21068 -> 21068 (0.00%) local sharedgpr inst bytes helped 0 0 0 5 5 hurt 0 0 0 191 191 Signed-off-by: Rhys Perry --- Instead of combining SV_TID reads into a SV_COMBINED_TID read, this has SV_TID reads lowered into a SV_COMBINED_TID read which can them be combined by CSE and then turned into a SV_TID read by AlgebraicOpt if it doesn't create another RDSV. src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 + .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 1 + .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 1 + .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 1 + .../nouveau/codegen/nv50_ir_lowering_nv50.cpp | 3 ++ .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 12 +++ .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 40 ++ .../drivers/nouveau/codegen/nv50_ir_print.cpp | 1 + .../nouveau/codegen/nv50_ir_target_nv50.cpp| 1 + 9 files changed, 61 insertions(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h b/src/gallium/drivers/nouveau/codegen/nv50_ir.h index f4f3c70888..0b220cc48d 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h @@ -453,6 +453,7 @@ enum SVSemantic SV_TESS_INNER, SV_TESS_COORD, SV_TID, + SV_COMBINED_TID, SV_CTAID, SV_NTID, SV_GRIDID, diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp index 647d1a5d0e..2118c3153f 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp @@ -2297,6 +2297,7 @@ CodeEmitterGK110::getSRegEncoding(const ValueRef& ref) case SV_INVOCATION_ID: return 0x11; case SV_YDIR: return 0x12; case SV_THREAD_KILL: return 0x13; + case SV_COMBINED_TID: return 0x20; case SV_TID: return 0x21 + SDATA(ref).sv.index; case SV_CTAID: return 0x25 + SDATA(ref).sv.index; case SV_NTID: return 0x29 + SDATA(ref).sv.index; diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp index 26826d6360..694d1b10a3 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp @@ -267,6 +267,7 @@ CodeEmitterGM107::emitSYS(int pos, const Value *val) case SV_INVOCATION_ID : id = 0x11; break; case SV_THREAD_KILL: id = 0x13; break; case SV_INVOCATION_INFO: id = 0x1d; break; + case SV_COMBINED_TID : id = 0x20; break; case SV_TID: id = 0x21 + val->reg.data.sv.index; break; case SV_CTAID : id = 0x25 + val->reg.data.sv.index; break; case SV_LANEMASK_EQ: id = 0x38; break; diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp index d85fdda56f..b6e35dd0ee 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp @@ -1990,6 +1990,7 @@ CodeEmitterNVC0::getSRegEncoding(const ValueRef& ref) case SV_INVOCATION_ID: return 0x11; case SV_YDIR:
Re: [Mesa-dev] [PATCH] nvc0/ir: use the combined tid special register
Are they? Fewer special reg loads = better... On Fri, Jul 6, 2018 at 8:31 PM, Karol Herbst wrote: > somehow it doesn't really look like that it is worth the effort as the > generated shaders are worse in avg? > > On Fri, Jul 6, 2018 at 10:32 PM, Rhys Perry wrote: >> This patch doesn't touch NTID since it seems very difficult (or >> impossible) to generate. Seemingly because the state tracker or glsl >> compiler is turning gl_WorkGroupSize into a immediate. Such a >> transformation is not possible with GL_ARB_compute_variable_group_size >> but gl_WorkGroupSize is not available when that extension is enabled. >> >> On Kepler+, it seems to end up being lowered into constant buffer loads >> anyway. >> >> On Fri, Jul 6, 2018 at 9:21 PM, Rhys Perry wrote: >>> total instructions in shared programs : 5804448 -> 5804690 (0.00%) >>> total gprs used in shared programs: 670065 -> 670065 (0.00%) >>> total shared used in shared programs : 548832 -> 548832 (0.00%) >>> total local used in shared programs : 21068 -> 21068 (0.00%) >>> >>> local sharedgpr inst bytes >>> helped 0 0 0 5 5 >>> hurt 0 0 0 191 191 >>> >>> Signed-off-by: Rhys Perry >>> --- >>> Instead of combining SV_TID reads into a SV_COMBINED_TID read, this has >>> SV_TID reads lowered into a SV_COMBINED_TID read which can them be >>> combined by CSE and then turned into a SV_TID read by AlgebraicOpt if it >>> doesn't create another RDSV. >>> >>> src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 + >>> .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 1 + >>> .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 1 + >>> .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 1 + >>> .../nouveau/codegen/nv50_ir_lowering_nv50.cpp | 3 ++ >>> .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 12 +++ >>> .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 40 >>> ++ >>> .../drivers/nouveau/codegen/nv50_ir_print.cpp | 1 + >>> .../nouveau/codegen/nv50_ir_target_nv50.cpp| 1 + >>> 9 files changed, 61 insertions(+) >>> >>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h >>> b/src/gallium/drivers/nouveau/codegen/nv50_ir.h >>> index f4f3c70888..0b220cc48d 100644 >>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h >>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h >>> @@ -453,6 +453,7 @@ enum SVSemantic >>> SV_TESS_INNER, >>> SV_TESS_COORD, >>> SV_TID, >>> + SV_COMBINED_TID, >>> SV_CTAID, >>> SV_NTID, >>> SV_GRIDID, >>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp >>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp >>> index 647d1a5d0e..2118c3153f 100644 >>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp >>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp >>> @@ -2297,6 +2297,7 @@ CodeEmitterGK110::getSRegEncoding(const ValueRef& ref) >>> case SV_INVOCATION_ID: return 0x11; >>> case SV_YDIR: return 0x12; >>> case SV_THREAD_KILL: return 0x13; >>> + case SV_COMBINED_TID: return 0x20; >>> case SV_TID: return 0x21 + SDATA(ref).sv.index; >>> case SV_CTAID: return 0x25 + SDATA(ref).sv.index; >>> case SV_NTID: return 0x29 + SDATA(ref).sv.index; >>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp >>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp >>> index 26826d6360..694d1b10a3 100644 >>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp >>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp >>> @@ -267,6 +267,7 @@ CodeEmitterGM107::emitSYS(int pos, const Value *val) >>> case SV_INVOCATION_ID : id = 0x11; break; >>> case SV_THREAD_KILL: id = 0x13; break; >>> case SV_INVOCATION_INFO: id = 0x1d; break; >>> + case SV_COMBINED_TID : id = 0x20; break; >>> case SV_TID: id = 0x21 + val->reg.data.sv.index; break; >>> case SV_CTAID : id = 0x25 + val->reg.data.sv.index; break; >>> case SV_LANEMASK_EQ: id = 0x38; break; >>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp >>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp >>> index d85fdda56f..b6e35dd0ee 100644 >>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp >>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp >>> @@ -1990,6 +1990,7 @@ CodeEmitterNVC0::getSRegEncoding(const ValueRef& ref) >>> case SV_INVOCATION_ID: return 0x11; >>> case SV_YDIR: return 0x12; >>> case SV_THREAD_KILL: return 0x13; >>> + case SV_COMBINED_TID: return 0x20; >>> case SV_TID: return 0x21 + SDATA(ref).sv.index; >>> case SV_CTAID: return 0x25 + SDATA(ref).sv.index; >>> case SV_NTID: return 0x29 +
Re: [Mesa-dev] [PATCH] nvc0/ir: use the combined tid special register
somehow it doesn't really look like that it is worth the effort as the generated shaders are worse in avg? On Fri, Jul 6, 2018 at 10:32 PM, Rhys Perry wrote: > This patch doesn't touch NTID since it seems very difficult (or > impossible) to generate. Seemingly because the state tracker or glsl > compiler is turning gl_WorkGroupSize into a immediate. Such a > transformation is not possible with GL_ARB_compute_variable_group_size > but gl_WorkGroupSize is not available when that extension is enabled. > > On Kepler+, it seems to end up being lowered into constant buffer loads > anyway. > > On Fri, Jul 6, 2018 at 9:21 PM, Rhys Perry wrote: >> total instructions in shared programs : 5804448 -> 5804690 (0.00%) >> total gprs used in shared programs: 670065 -> 670065 (0.00%) >> total shared used in shared programs : 548832 -> 548832 (0.00%) >> total local used in shared programs : 21068 -> 21068 (0.00%) >> >> local sharedgpr inst bytes >> helped 0 0 0 5 5 >> hurt 0 0 0 191 191 >> >> Signed-off-by: Rhys Perry >> --- >> Instead of combining SV_TID reads into a SV_COMBINED_TID read, this has >> SV_TID reads lowered into a SV_COMBINED_TID read which can them be >> combined by CSE and then turned into a SV_TID read by AlgebraicOpt if it >> doesn't create another RDSV. >> >> src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 + >> .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 1 + >> .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 1 + >> .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 1 + >> .../nouveau/codegen/nv50_ir_lowering_nv50.cpp | 3 ++ >> .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 12 +++ >> .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 40 >> ++ >> .../drivers/nouveau/codegen/nv50_ir_print.cpp | 1 + >> .../nouveau/codegen/nv50_ir_target_nv50.cpp| 1 + >> 9 files changed, 61 insertions(+) >> >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h >> b/src/gallium/drivers/nouveau/codegen/nv50_ir.h >> index f4f3c70888..0b220cc48d 100644 >> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h >> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h >> @@ -453,6 +453,7 @@ enum SVSemantic >> SV_TESS_INNER, >> SV_TESS_COORD, >> SV_TID, >> + SV_COMBINED_TID, >> SV_CTAID, >> SV_NTID, >> SV_GRIDID, >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp >> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp >> index 647d1a5d0e..2118c3153f 100644 >> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp >> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp >> @@ -2297,6 +2297,7 @@ CodeEmitterGK110::getSRegEncoding(const ValueRef& ref) >> case SV_INVOCATION_ID: return 0x11; >> case SV_YDIR: return 0x12; >> case SV_THREAD_KILL: return 0x13; >> + case SV_COMBINED_TID: return 0x20; >> case SV_TID: return 0x21 + SDATA(ref).sv.index; >> case SV_CTAID: return 0x25 + SDATA(ref).sv.index; >> case SV_NTID: return 0x29 + SDATA(ref).sv.index; >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp >> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp >> index 26826d6360..694d1b10a3 100644 >> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp >> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp >> @@ -267,6 +267,7 @@ CodeEmitterGM107::emitSYS(int pos, const Value *val) >> case SV_INVOCATION_ID : id = 0x11; break; >> case SV_THREAD_KILL: id = 0x13; break; >> case SV_INVOCATION_INFO: id = 0x1d; break; >> + case SV_COMBINED_TID : id = 0x20; break; >> case SV_TID: id = 0x21 + val->reg.data.sv.index; break; >> case SV_CTAID : id = 0x25 + val->reg.data.sv.index; break; >> case SV_LANEMASK_EQ: id = 0x38; break; >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp >> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp >> index d85fdda56f..b6e35dd0ee 100644 >> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp >> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp >> @@ -1990,6 +1990,7 @@ CodeEmitterNVC0::getSRegEncoding(const ValueRef& ref) >> case SV_INVOCATION_ID: return 0x11; >> case SV_YDIR: return 0x12; >> case SV_THREAD_KILL: return 0x13; >> + case SV_COMBINED_TID: return 0x20; >> case SV_TID: return 0x21 + SDATA(ref).sv.index; >> case SV_CTAID: return 0x25 + SDATA(ref).sv.index; >> case SV_NTID: return 0x29 + SDATA(ref).sv.index; >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp >> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp >> index 36ab837f6e..1f0fd466a9 100644
Re: [Mesa-dev] [PATCH] st/wgl: check for NULL piAttribList in wglCreatePbufferARB()
Looks good to me.
Reviewed-by: Neha Bhende
Regards,
Neha
From: Charmaine Lee
Sent: Friday, July 6, 2018 4:09:02 PM
To: mesa-dev@lists.freedesktop.org
Cc: Brian Paul; Neha Bhende; Charmaine Lee
Subject: [PATCH] st/wgl: check for NULL piAttribList in wglCreatePbufferARB()
Java2d opengl pipeline passes NULL piAttribList to
wglCreatePbufferARB(). So skip parsing the attribute list
if it is NULL.
---
src/gallium/state_trackers/wgl/stw_ext_pbuffer.c | 80
1 file changed, 41 insertions(+), 39 deletions(-)
diff --git a/src/gallium/state_trackers/wgl/stw_ext_pbuffer.c
b/src/gallium/state_trackers/wgl/stw_ext_pbuffer.c
index d709faa..02ccb76 100644
--- a/src/gallium/state_trackers/wgl/stw_ext_pbuffer.c
+++ b/src/gallium/state_trackers/wgl/stw_ext_pbuffer.c
@@ -101,45 +101,47 @@ wglCreatePbufferARB(HDC hCurrentDC,
return 0;
}
- for (piAttrib = piAttribList; *piAttrib; piAttrib++) {
- switch (*piAttrib) {
- case WGL_PBUFFER_LARGEST_ARB:
- piAttrib++;
- useLargest = *piAttrib;
- break;
- case WGL_TEXTURE_FORMAT_ARB:
- /* WGL_ARB_render_texture */
- piAttrib++;
- textureFormat = *piAttrib;
- if (textureFormat != WGL_TEXTURE_RGB_ARB &&
- textureFormat != WGL_TEXTURE_RGBA_ARB &&
- textureFormat != WGL_NO_TEXTURE_ARB) {
- SetLastError(ERROR_INVALID_DATA);
- return 0;
- }
- break;
- case WGL_TEXTURE_TARGET_ARB:
- /* WGL_ARB_render_texture */
- piAttrib++;
- textureTarget = *piAttrib;
- if (textureTarget != WGL_TEXTURE_CUBE_MAP_ARB &&
- textureTarget != WGL_TEXTURE_1D_ARB &&
- textureTarget != WGL_TEXTURE_2D_ARB &&
- textureTarget != WGL_NO_TEXTURE_ARB) {
- SetLastError(ERROR_INVALID_DATA);
- return 0;
- }
- break;
- case WGL_MIPMAP_TEXTURE_ARB:
- /* WGL_ARB_render_texture */
- piAttrib++;
- textureMipmap = !!*piAttrib;
- break;
- default:
- SetLastError(ERROR_INVALID_DATA);
- debug_printf("wgl: Unsupported attribute 0x%x in %s\n",
- *piAttrib, __func__);
- return 0;
+ if (piAttribList) {
+ for (piAttrib = piAttribList; *piAttrib; piAttrib++) {
+ switch (*piAttrib) {
+ case WGL_PBUFFER_LARGEST_ARB:
+piAttrib++;
+useLargest = *piAttrib;
+break;
+ case WGL_TEXTURE_FORMAT_ARB:
+ /* WGL_ARB_render_texture */
+ piAttrib++;
+ textureFormat = *piAttrib;
+ if (textureFormat != WGL_TEXTURE_RGB_ARB &&
+textureFormat != WGL_TEXTURE_RGBA_ARB &&
+textureFormat != WGL_NO_TEXTURE_ARB) {
+SetLastError(ERROR_INVALID_DATA);
+return 0;
+ }
+ break;
+ case WGL_TEXTURE_TARGET_ARB:
+ /* WGL_ARB_render_texture */
+ piAttrib++;
+ textureTarget = *piAttrib;
+ if (textureTarget != WGL_TEXTURE_CUBE_MAP_ARB &&
+ textureTarget != WGL_TEXTURE_1D_ARB &&
+ textureTarget != WGL_TEXTURE_2D_ARB &&
+ textureTarget != WGL_NO_TEXTURE_ARB) {
+SetLastError(ERROR_INVALID_DATA);
+return 0;
+ }
+ break;
+ case WGL_MIPMAP_TEXTURE_ARB:
+/* WGL_ARB_render_texture */
+piAttrib++;
+textureMipmap = !!*piAttrib;
+break;
+ default:
+SetLastError(ERROR_INVALID_DATA);
+debug_printf("wgl: Unsupported attribute 0x%x in %s\n",
+ *piAttrib, __func__);
+return 0;
+ }
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] i965/fs: Properly handle sign(-abs(x))
On 07/05/2018 06:22 PM, Caio Marcelo de Oliveira Filho wrote:
> Reviewed-by: Caio Marcelo de Oliveira Filho
>
> Tested the patch with the shaders mentioned.
>
> Do you think would be worth to have a pass at NIR level to perform
> these transformations?
Possibly. In many cases, it is better to keep a negation or an abs on
the inside of an expression instead of the outside (e.g., sign(-x) vs
-sign(x)). We can almost always propagate an outer negation to the
user, but there are some cases, such as when the user is in a different
basic block, where it cannot be done. In those cases, the outer unary
op results in an extra move. It is difficult to move unary ops inside
because it can interfere with other optimizations. When I have tried
this in the past, it has generally been an even split between helps / hurts.
> Thanks,
> Caio
>
>
> On Wed, Jun 27, 2018 at 07:37:57AM -0700, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Fixes new piglit tests:
>>
>> - glsl-1.10/execution/fs-sign-neg-abs.shader_test
>> - glsl-1.10/execution/fs-sign-sat-neg-abs.shader_test
>> - glsl-1.10/execution/vs-sign-neg-abs.shader_test
>> - glsl-1.10/execution/vs-sign-sat-neg-abs.shader_test
>>
>> Signed-off-by: Ian Romanick
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>> src/intel/compiler/brw_fs_nir.cpp | 15 ---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/intel/compiler/brw_fs_nir.cpp
>> b/src/intel/compiler/brw_fs_nir.cpp
>> index 0abb4798e70..2ad7a2d0dfc 100644
>> --- a/src/intel/compiler/brw_fs_nir.cpp
>> +++ b/src/intel/compiler/brw_fs_nir.cpp
>> @@ -807,11 +807,20 @@ fs_visitor::nir_emit_alu(const fs_builder ,
>> nir_alu_instr *instr)
>>
>> case nir_op_fsign: {
>>if (op[0].abs) {
>> - /* Straightforward since the source can be assumed to be
>> - * non-negative.
>> + /* Straightforward since the source can be assumed to be either
>> + * strictly >= 0 or strictly <= 0 depending on the setting of the
>> + * negate flag.
>>*/
>> set_condmod(BRW_CONDITIONAL_NZ, bld.MOV(result, op[0]));
>> - set_predicate(BRW_PREDICATE_NORMAL, bld.MOV(result,
>> brw_imm_f(1.0f)));
>> +
>> + inst = (op[0].negate)
>> +? bld.MOV(result, brw_imm_f(-1.0f))
>> +: bld.MOV(result, brw_imm_f(1.0f));
>> +
>> + set_predicate(BRW_PREDICATE_NORMAL, inst);
>> +
>> + if (instr->dest.saturate)
>> +inst->saturate = true;
>>
>>} else if (type_sz(op[0].type) < 8) {
>> /* AND(val, 0x8000) gives the sign bit.
>> --
>> 2.14.4
>>
>> ___
>> 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 0/3] verify max vertex attrib stride
On 07/06/2018 09:43 AM, Roland Scheidegger wrote: > Am 06.07.2018 um 12:03 schrieb Erik Faye-Lund: >> OpenGL 4.4 and OpenGL ES 3.1 both require the maximum >> vertex attrib stride to be at least 2048. If this isn't >> the case, we shouldn't expose these API versions. >> >> Unfortunately, the r600 driver only supports 2047. To >> avoid regressions in the supported GL version, the >> first patch modifies the returned value. >> >> I'm not sure if that last one is a good idea or not, as >> it's strictly speaking non-conformant. But applications >> won't expect GL errors generated when using strides of >> 2048 either, which is what currently happens. >> >> The initial motivation for this patch-series is to avoid >> exposing a too high spec version in virgl and then get >> dEQP failures when running on old hardware. The virgl >> specific bits are being sent separately, because they >> depend on some other not-yet-upstream things ATM. >> >> Thoughts? >> >> Erik Faye-Lund (3): >> r600: report incorrect max-vertex-attrib for GL 4.4 >> mesa: verify MaxVertexAttribStride for GL 4.4 >> mesa: verify MaxVertexAttribStride for GLES 3.1 >> >> src/gallium/drivers/r600/r600_pipe.c | 3 ++- >> src/mesa/main/version.c | 2 ++ >> 2 files changed, 4 insertions(+), 1 deletion(-) >> > > Personally I think it's _much_ better to lie about the supported GL > version rather than the maximum vertex attrib stride (I don't know if > dEQP would actually have a test which tests for the max stride also > working than just being advertized, which would be way more relevant and > fail in any case). > (Because if you're going to use stride 2048, it is hugely unlikely you'd > just rely on GL 4.4 for that, hence it wouldn't work with older versions > of GL anyway neither, where ALL strides are just supposed to work.) I believe the query was added in the same GL version that added 2048 as the minimum maximum. My guess is that any application that cares will just assume 2048. In this particular case, I believe lying about the GL version and lying about the limit are equivalent. > Roland > > FWIW, I think it should be possible to work around that limitation on > r600. Since vertex fetch just uses a fetch shader, you could have a > shader key bit indicating strides of 2048, program a stride of 1024 > instead and multiply the index to fetch by 2 in the shader. Of course > that could cause shader recompiles (never in practice...) and there's > some overhead associated with it, so might not be worth it... > > Roland > ___ > 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 0/3] verify max vertex attrib stride
Assuming the concerns about patch 1 are resolved, patches 2 and 3 are Reviewed-by: Ian Romanick On 07/06/2018 03:03 AM, Erik Faye-Lund wrote: > OpenGL 4.4 and OpenGL ES 3.1 both require the maximum > vertex attrib stride to be at least 2048. If this isn't > the case, we shouldn't expose these API versions. > > Unfortunately, the r600 driver only supports 2047. To > avoid regressions in the supported GL version, the > first patch modifies the returned value. > > I'm not sure if that last one is a good idea or not, as > it's strictly speaking non-conformant. But applications > won't expect GL errors generated when using strides of > 2048 either, which is what currently happens. > > The initial motivation for this patch-series is to avoid > exposing a too high spec version in virgl and then get > dEQP failures when running on old hardware. The virgl > specific bits are being sent separately, because they > depend on some other not-yet-upstream things ATM. > > Thoughts? > > Erik Faye-Lund (3): > r600: report incorrect max-vertex-attrib for GL 4.4 > mesa: verify MaxVertexAttribStride for GL 4.4 > mesa: verify MaxVertexAttribStride for GLES 3.1 > > src/gallium/drivers/r600/r600_pipe.c | 3 ++- > src/mesa/main/version.c | 2 ++ > 2 files changed, 4 insertions(+), 1 deletion(-) > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107146] swr doesn't compile with current LLVM 7.0 snapshots
https://bugs.freedesktop.org/show_bug.cgi?id=107146 Bug ID: 107146 Summary: swr doesn't compile with current LLVM 7.0 snapshots Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/swr Assignee: mesa-dev@lists.freedesktop.org Reporter: b...@lindev.ch QA Contact: mesa-dev@lists.freedesktop.org createInstructionSimplifierPass() has been removed in LLVM. This is used in a few places in SWR; looks like this can safely be removed because it is always preceded by createInstructionCombiningPass() which seems to be a superset of what createInstructionSimplifierPass() used to do. Fixing this just unmasks another problem though - Intrinsic::x86_fma_vfmadd_ps_256 is gone. Not sure how to replace that properly. -- 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] st/wgl: check for NULL piAttribList in wglCreatePbufferARB()
Java2d opengl pipeline passes NULL piAttribList to
wglCreatePbufferARB(). So skip parsing the attribute list
if it is NULL.
---
src/gallium/state_trackers/wgl/stw_ext_pbuffer.c | 80
1 file changed, 41 insertions(+), 39 deletions(-)
diff --git a/src/gallium/state_trackers/wgl/stw_ext_pbuffer.c
b/src/gallium/state_trackers/wgl/stw_ext_pbuffer.c
index d709faa..02ccb76 100644
--- a/src/gallium/state_trackers/wgl/stw_ext_pbuffer.c
+++ b/src/gallium/state_trackers/wgl/stw_ext_pbuffer.c
@@ -101,45 +101,47 @@ wglCreatePbufferARB(HDC hCurrentDC,
return 0;
}
- for (piAttrib = piAttribList; *piAttrib; piAttrib++) {
- switch (*piAttrib) {
- case WGL_PBUFFER_LARGEST_ARB:
- piAttrib++;
- useLargest = *piAttrib;
- break;
- case WGL_TEXTURE_FORMAT_ARB:
- /* WGL_ARB_render_texture */
- piAttrib++;
- textureFormat = *piAttrib;
- if (textureFormat != WGL_TEXTURE_RGB_ARB &&
- textureFormat != WGL_TEXTURE_RGBA_ARB &&
- textureFormat != WGL_NO_TEXTURE_ARB) {
- SetLastError(ERROR_INVALID_DATA);
- return 0;
- }
- break;
- case WGL_TEXTURE_TARGET_ARB:
- /* WGL_ARB_render_texture */
- piAttrib++;
- textureTarget = *piAttrib;
- if (textureTarget != WGL_TEXTURE_CUBE_MAP_ARB &&
- textureTarget != WGL_TEXTURE_1D_ARB &&
- textureTarget != WGL_TEXTURE_2D_ARB &&
- textureTarget != WGL_NO_TEXTURE_ARB) {
- SetLastError(ERROR_INVALID_DATA);
- return 0;
- }
- break;
- case WGL_MIPMAP_TEXTURE_ARB:
- /* WGL_ARB_render_texture */
- piAttrib++;
- textureMipmap = !!*piAttrib;
- break;
- default:
- SetLastError(ERROR_INVALID_DATA);
- debug_printf("wgl: Unsupported attribute 0x%x in %s\n",
- *piAttrib, __func__);
- return 0;
+ if (piAttribList) {
+ for (piAttrib = piAttribList; *piAttrib; piAttrib++) {
+ switch (*piAttrib) {
+ case WGL_PBUFFER_LARGEST_ARB:
+piAttrib++;
+useLargest = *piAttrib;
+break;
+ case WGL_TEXTURE_FORMAT_ARB:
+ /* WGL_ARB_render_texture */
+ piAttrib++;
+ textureFormat = *piAttrib;
+ if (textureFormat != WGL_TEXTURE_RGB_ARB &&
+textureFormat != WGL_TEXTURE_RGBA_ARB &&
+textureFormat != WGL_NO_TEXTURE_ARB) {
+SetLastError(ERROR_INVALID_DATA);
+return 0;
+ }
+ break;
+ case WGL_TEXTURE_TARGET_ARB:
+ /* WGL_ARB_render_texture */
+ piAttrib++;
+ textureTarget = *piAttrib;
+ if (textureTarget != WGL_TEXTURE_CUBE_MAP_ARB &&
+ textureTarget != WGL_TEXTURE_1D_ARB &&
+ textureTarget != WGL_TEXTURE_2D_ARB &&
+ textureTarget != WGL_NO_TEXTURE_ARB) {
+SetLastError(ERROR_INVALID_DATA);
+return 0;
+ }
+ break;
+ case WGL_MIPMAP_TEXTURE_ARB:
+/* WGL_ARB_render_texture */
+piAttrib++;
+textureMipmap = !!*piAttrib;
+break;
+ default:
+SetLastError(ERROR_INVALID_DATA);
+debug_printf("wgl: Unsupported attribute 0x%x in %s\n",
+ *piAttrib, __func__);
+return 0;
+ }
}
}
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965/miptree: Allocate MS texture BOs as BUSY
These buffer objects are never accessed with the CPU.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index eee83a7a963..3a1d064ef4b 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -694,8 +694,8 @@ miptree_create(struct brw_context *brw,
enum intel_miptree_create_flags flags)
{
const struct gen_device_info *devinfo = >screen->devinfo;
- const uint32_t alloc_flags = (flags & MIPTREE_CREATE_BUSY) ?
-BO_ALLOC_BUSY : 0;
+ const uint32_t alloc_flags =
+ (flags & MIPTREE_CREATE_BUSY || num_samples > 1) ? BO_ALLOC_BUSY : 0;
isl_tiling_flags_t tiling_flags = ISL_TILING_ANY_MASK;
/* TODO: This used to be because there wasn't BLORP to handle Y-tiling. */
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] mesa: verify MaxVertexAttribStride for GLES 3.1
For the series:
Reviewed-by: Marek Olšák
Marek
On Fri, Jul 6, 2018 at 6:03 AM, Erik Faye-Lund
wrote:
> The OpenGL 3.1 specification, table Table 20.41 ("Implementation
> Dependent Values"), defines the minimum-maximum value for
> MAX_VERTEX_ATTRIB_STRIDE to be 2048.
>
> So we shouldn't enable OpenGL ES 3.1 on implementations where this
> isn't the case. Let's add a check for this
>
> Signed-off-by: Erik Faye-Lund
> ---
> src/mesa/main/version.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
> index 0b0d5b79d6..58e68b4772 100644
> --- a/src/mesa/main/version.c
> +++ b/src/mesa/main/version.c
> @@ -530,6 +530,7 @@ compute_version_es2(const struct gl_extensions
> *extensions,
> const bool es31_compute_shader =
>consts->MaxComputeWorkGroupInvocations >= 128;
> const bool ver_3_1 = (ver_3_0 &&
> + consts->MaxVertexAttribStride >= 2048 &&
> extensions->ARB_arrays_of_arrays &&
> es31_compute_shader &&
> extensions->ARB_draw_indirect &&
> --
> 2.18.0.rc2
>
> ___
> 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 1/3] r600: report incorrect max-vertex-attrib for GL 4.4
Reviewed-by: Marek Olšák Marek On Fri, Jul 6, 2018 at 6:03 AM, Erik Faye-Lund wrote: > OpenGL 4.4 requires a max vertex attrib of 2048 or higher, but > r600 only supports 2047. Technically, this makes it an GL4.3 GPU, > but it's currently exposing GL4.4. > > To avoid regressing the GL version supported in the following > patches, let's just lie and pretend like we support 2048. Any > applications using 2048 are already broken anyway. > > Signed-off-by: Erik Faye-Lund > --- > src/gallium/drivers/r600/r600_pipe.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/r600/r600_pipe.c > b/src/gallium/drivers/r600/r600_pipe.c > index bc5660d6d1..2518032145 100644 > --- a/src/gallium/drivers/r600/r600_pipe.c > +++ b/src/gallium/drivers/r600/r600_pipe.c > @@ -470,7 +470,8 @@ static int r600_get_param(struct pipe_screen* pscreen, > enum pipe_cap param) > return family >= CHIP_CEDAR ? 4 : 1; > > case PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE: > - return 2047; > + /* Should be 2047, but 2048 is a requirement for GL 4.4 */ > + return 2048; > > /* Texturing. */ > case PIPE_CAP_MAX_TEXTURE_2D_LEVELS: > -- > 2.18.0.rc2 > > ___ > 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] vulkan: utils: handle hexadecimal values in registry
Reviewed-by: Jason Ekstrand On Fri, Jul 6, 2018 at 2:06 PM Lionel Landwerlin < lionel.g.landwer...@intel.com> wrote: > Signed-off-by: Lionel Landwerlin > --- > src/vulkan/util/gen_enum_to_str.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/vulkan/util/gen_enum_to_str.py > b/src/vulkan/util/gen_enum_to_str.py > index bf883d5cb8f..fb9ecd65c6d 100644 > --- a/src/vulkan/util/gen_enum_to_str.py > +++ b/src/vulkan/util/gen_enum_to_str.py > @@ -172,7 +172,7 @@ class VkEnum(object): > def add_value_from_xml(self, elem, extension=None): > if 'value' in elem.attrib: > self.add_value(elem.attrib['name'], > - value=int(elem.attrib['value'])) > + value=int(elem.attrib['value'], base=0)) > elif 'alias' in elem.attrib: > self.add_value(elem.attrib['name'], > value=self.name_to_value[elem.attrib['alias']]) > -- > 2.18.0 > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vulkan: utils: handle hexadecimal values in registry
Signed-off-by: Lionel Landwerlin --- src/vulkan/util/gen_enum_to_str.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/vulkan/util/gen_enum_to_str.py b/src/vulkan/util/gen_enum_to_str.py index bf883d5cb8f..fb9ecd65c6d 100644 --- a/src/vulkan/util/gen_enum_to_str.py +++ b/src/vulkan/util/gen_enum_to_str.py @@ -172,7 +172,7 @@ class VkEnum(object): def add_value_from_xml(self, elem, extension=None): if 'value' in elem.attrib: self.add_value(elem.attrib['name'], - value=int(elem.attrib['value'])) + value=int(elem.attrib['value'], base=0)) elif 'alias' in elem.attrib: self.add_value(elem.attrib['name'], value=self.name_to_value[elem.attrib['alias']]) -- 2.18.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vulkan: Allow for hex values in XML enum definitions
These have come up from time to time in some enums. They've never been
a problem in the past because we just haven't cared about enum_to_str on
those.
---
src/vulkan/util/gen_enum_to_str.py | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/vulkan/util/gen_enum_to_str.py
b/src/vulkan/util/gen_enum_to_str.py
index bf883d5cb8f..a01e4a66604 100644
--- a/src/vulkan/util/gen_enum_to_str.py
+++ b/src/vulkan/util/gen_enum_to_str.py
@@ -118,6 +118,11 @@ FOREIGN_ENUM_VALUES = [
"VK_STRUCTURE_TYPE_NATIVE_BUFFER_ANDROID",
]
+def num_from_str(num_str):
+if num_str.lower().startswith('0x'):
+return int(num_str, base=16)
+else:
+return int(num_str)
class NamedFactory(object):
"""Factory for creating enums."""
@@ -172,7 +177,7 @@ class VkEnum(object):
def add_value_from_xml(self, elem, extension=None):
if 'value' in elem.attrib:
self.add_value(elem.attrib['name'],
- value=int(elem.attrib['value']))
+ value=num_from_str(elem.attrib['value']))
elif 'alias' in elem.attrib:
self.add_value(elem.attrib['name'],
value=self.name_to_value[elem.attrib['alias']])
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nvc0/ir: use the combined tid special register
This patch doesn't touch NTID since it seems very difficult (or impossible) to generate. Seemingly because the state tracker or glsl compiler is turning gl_WorkGroupSize into a immediate. Such a transformation is not possible with GL_ARB_compute_variable_group_size but gl_WorkGroupSize is not available when that extension is enabled. On Kepler+, it seems to end up being lowered into constant buffer loads anyway. On Fri, Jul 6, 2018 at 9:21 PM, Rhys Perry wrote: > total instructions in shared programs : 5804448 -> 5804690 (0.00%) > total gprs used in shared programs: 670065 -> 670065 (0.00%) > total shared used in shared programs : 548832 -> 548832 (0.00%) > total local used in shared programs : 21068 -> 21068 (0.00%) > > local sharedgpr inst bytes > helped 0 0 0 5 5 > hurt 0 0 0 191 191 > > Signed-off-by: Rhys Perry > --- > Instead of combining SV_TID reads into a SV_COMBINED_TID read, this has > SV_TID reads lowered into a SV_COMBINED_TID read which can them be > combined by CSE and then turned into a SV_TID read by AlgebraicOpt if it > doesn't create another RDSV. > > src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 + > .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 1 + > .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 1 + > .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 1 + > .../nouveau/codegen/nv50_ir_lowering_nv50.cpp | 3 ++ > .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 12 +++ > .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 40 > ++ > .../drivers/nouveau/codegen/nv50_ir_print.cpp | 1 + > .../nouveau/codegen/nv50_ir_target_nv50.cpp| 1 + > 9 files changed, 61 insertions(+) > > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h > b/src/gallium/drivers/nouveau/codegen/nv50_ir.h > index f4f3c70888..0b220cc48d 100644 > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h > @@ -453,6 +453,7 @@ enum SVSemantic > SV_TESS_INNER, > SV_TESS_COORD, > SV_TID, > + SV_COMBINED_TID, > SV_CTAID, > SV_NTID, > SV_GRIDID, > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp > b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp > index 647d1a5d0e..2118c3153f 100644 > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp > @@ -2297,6 +2297,7 @@ CodeEmitterGK110::getSRegEncoding(const ValueRef& ref) > case SV_INVOCATION_ID: return 0x11; > case SV_YDIR: return 0x12; > case SV_THREAD_KILL: return 0x13; > + case SV_COMBINED_TID: return 0x20; > case SV_TID: return 0x21 + SDATA(ref).sv.index; > case SV_CTAID: return 0x25 + SDATA(ref).sv.index; > case SV_NTID: return 0x29 + SDATA(ref).sv.index; > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > index 26826d6360..694d1b10a3 100644 > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp > @@ -267,6 +267,7 @@ CodeEmitterGM107::emitSYS(int pos, const Value *val) > case SV_INVOCATION_ID : id = 0x11; break; > case SV_THREAD_KILL: id = 0x13; break; > case SV_INVOCATION_INFO: id = 0x1d; break; > + case SV_COMBINED_TID : id = 0x20; break; > case SV_TID: id = 0x21 + val->reg.data.sv.index; break; > case SV_CTAID : id = 0x25 + val->reg.data.sv.index; break; > case SV_LANEMASK_EQ: id = 0x38; break; > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp > b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp > index d85fdda56f..b6e35dd0ee 100644 > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp > @@ -1990,6 +1990,7 @@ CodeEmitterNVC0::getSRegEncoding(const ValueRef& ref) > case SV_INVOCATION_ID: return 0x11; > case SV_YDIR: return 0x12; > case SV_THREAD_KILL: return 0x13; > + case SV_COMBINED_TID: return 0x20; > case SV_TID: return 0x21 + SDATA(ref).sv.index; > case SV_CTAID: return 0x25 + SDATA(ref).sv.index; > case SV_NTID: return 0x29 + SDATA(ref).sv.index; > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp > b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp > index 36ab837f6e..1f0fd466a9 100644 > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp > @@ -1201,6 +1201,9 @@ NV50LoweringPreSSA::handleRDSV(Instruction *i) > bld.mkMov(def, bld.mkImm(0)); >
Re: [Mesa-dev] [PATCH 00/13] Fix stencil texturing and BO caching bugs
On Fri, Jul 06, 2018 at 01:29:29PM -0700, Nanley Chery wrote: > On Fri, Jul 06, 2018 at 03:36:01PM +0300, Pohjolainen, Topi wrote: > > On Tue, Jun 12, 2018 at 12:21:52PM -0700, Nanley Chery wrote: > > > This series fixes a couple stencil texturing bugs on HSW and > > > cache-tracking for certain stencil BOs on all platforms. > > > > > > Nanley Chery (13): > > > i965: Set the r8stencil flag in miptree_finish_write > > > i965/miptree: Set the r8stencil flag in map_depthstencil > > > i965/draw: Set the r8stencil flag after drawing > > > i965/draw: Fix adding the stencil bo to the depth cache > > > i965/miptree: Use make_surface in map_blit > > > i965/miptree: Delete MIPTREE_CREATE_LINEAR > > > i965/miptree: Share tiling_flags in miptree_create > > > i965/miptree: Share the miptree format in miptree_create > > > i965/miptree: Share alloc_flags in miptree_create > > > > I'm not sure if this maintains the BO_ALLOC_BUSY. > > > > > i965/miptree: Add and use mt_surf_usage > > > i965/miptree: Refactor miptree_create > > > i965/miptree: Create the r8stencil_mt immediately > > > i965/miptree: Inline make_separate_stencil > > > > Same here. > I should mention that I attempted to answer your questions on those patches here. Please let me know if I didn't. -Nanley > Yes, those two patches don't maintain BO_ALLOC_BUSY for the cases where > the user creates a depth, depth-stencil, or stencil texture. It seems > better this way though since, like a color texture, those are liable to > be accessed with the CPU immediately. > > I think we can maintain BO_ALLOC_BUSY for multisampled textures, since > they will never be accessed on the CPU. I'll send a follow-up patch. > Thoughts? > > AFAICT, BO_ALLOC_BUSY wasn't used for those textures until commit > a73d56dce37ae13f422215de1bf1fdfb8e2f6ed7, which allocated renderbuffers > for depth stencil textures and implicitly (and perhaps accidentally) > asked for a BUSY BO. I haven't thoroughly checked though. > > > Otherwise the series is: > > > > Reviewed-by: Topi Pohjolainen > > > > Thanks for the review! > > -Nanley > > > > > > > src/mesa/drivers/dri/i965/brw_blorp.c | 6 +- > > > src/mesa/drivers/dri/i965/brw_clear.c | 8 - > > > src/mesa/drivers/dri/i965/brw_draw.c | 14 +- > > > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 211 -- > > > src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 5 +- > > > src/mesa/drivers/dri/i965/intel_tex_image.c | 3 - > > > 6 files changed, 103 insertions(+), 144 deletions(-) > > > > > > -- > > > 2.17.0 > > > > > > ___ > > > 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 00/13] Fix stencil texturing and BO caching bugs
On Fri, Jul 06, 2018 at 03:36:01PM +0300, Pohjolainen, Topi wrote: > On Tue, Jun 12, 2018 at 12:21:52PM -0700, Nanley Chery wrote: > > This series fixes a couple stencil texturing bugs on HSW and > > cache-tracking for certain stencil BOs on all platforms. > > > > Nanley Chery (13): > > i965: Set the r8stencil flag in miptree_finish_write > > i965/miptree: Set the r8stencil flag in map_depthstencil > > i965/draw: Set the r8stencil flag after drawing > > i965/draw: Fix adding the stencil bo to the depth cache > > i965/miptree: Use make_surface in map_blit > > i965/miptree: Delete MIPTREE_CREATE_LINEAR > > i965/miptree: Share tiling_flags in miptree_create > > i965/miptree: Share the miptree format in miptree_create > > i965/miptree: Share alloc_flags in miptree_create > > I'm not sure if this maintains the BO_ALLOC_BUSY. > > > i965/miptree: Add and use mt_surf_usage > > i965/miptree: Refactor miptree_create > > i965/miptree: Create the r8stencil_mt immediately > > i965/miptree: Inline make_separate_stencil > > Same here. Yes, those two patches don't maintain BO_ALLOC_BUSY for the cases where the user creates a depth, depth-stencil, or stencil texture. It seems better this way though since, like a color texture, those are liable to be accessed with the CPU immediately. I think we can maintain BO_ALLOC_BUSY for multisampled textures, since they will never be accessed on the CPU. I'll send a follow-up patch. Thoughts? AFAICT, BO_ALLOC_BUSY wasn't used for those textures until commit a73d56dce37ae13f422215de1bf1fdfb8e2f6ed7, which allocated renderbuffers for depth stencil textures and implicitly (and perhaps accidentally) asked for a BUSY BO. I haven't thoroughly checked though. > Otherwise the series is: > > Reviewed-by: Topi Pohjolainen > Thanks for the review! -Nanley > > > > src/mesa/drivers/dri/i965/brw_blorp.c | 6 +- > > src/mesa/drivers/dri/i965/brw_clear.c | 8 - > > src/mesa/drivers/dri/i965/brw_draw.c | 14 +- > > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 211 -- > > src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 5 +- > > src/mesa/drivers/dri/i965/intel_tex_image.c | 3 - > > 6 files changed, 103 insertions(+), 144 deletions(-) > > > > -- > > 2.17.0 > > > > ___ > > 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] nvc0/ir: use the combined tid special register
total instructions in shared programs : 5804448 -> 5804690 (0.00%)
total gprs used in shared programs: 670065 -> 670065 (0.00%)
total shared used in shared programs : 548832 -> 548832 (0.00%)
total local used in shared programs : 21068 -> 21068 (0.00%)
local sharedgpr inst bytes
helped 0 0 0 5 5
hurt 0 0 0 191 191
Signed-off-by: Rhys Perry
---
Instead of combining SV_TID reads into a SV_COMBINED_TID read, this has
SV_TID reads lowered into a SV_COMBINED_TID read which can them be
combined by CSE and then turned into a SV_TID read by AlgebraicOpt if it
doesn't create another RDSV.
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 +
.../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 1 +
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 1 +
.../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 1 +
.../nouveau/codegen/nv50_ir_lowering_nv50.cpp | 3 ++
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 12 +++
.../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 40 ++
.../drivers/nouveau/codegen/nv50_ir_print.cpp | 1 +
.../nouveau/codegen/nv50_ir_target_nv50.cpp| 1 +
9 files changed, 61 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index f4f3c70888..0b220cc48d 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -453,6 +453,7 @@ enum SVSemantic
SV_TESS_INNER,
SV_TESS_COORD,
SV_TID,
+ SV_COMBINED_TID,
SV_CTAID,
SV_NTID,
SV_GRIDID,
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index 647d1a5d0e..2118c3153f 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -2297,6 +2297,7 @@ CodeEmitterGK110::getSRegEncoding(const ValueRef& ref)
case SV_INVOCATION_ID: return 0x11;
case SV_YDIR: return 0x12;
case SV_THREAD_KILL: return 0x13;
+ case SV_COMBINED_TID: return 0x20;
case SV_TID: return 0x21 + SDATA(ref).sv.index;
case SV_CTAID: return 0x25 + SDATA(ref).sv.index;
case SV_NTID: return 0x29 + SDATA(ref).sv.index;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 26826d6360..694d1b10a3 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -267,6 +267,7 @@ CodeEmitterGM107::emitSYS(int pos, const Value *val)
case SV_INVOCATION_ID : id = 0x11; break;
case SV_THREAD_KILL: id = 0x13; break;
case SV_INVOCATION_INFO: id = 0x1d; break;
+ case SV_COMBINED_TID : id = 0x20; break;
case SV_TID: id = 0x21 + val->reg.data.sv.index; break;
case SV_CTAID : id = 0x25 + val->reg.data.sv.index; break;
case SV_LANEMASK_EQ: id = 0x38; break;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index d85fdda56f..b6e35dd0ee 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -1990,6 +1990,7 @@ CodeEmitterNVC0::getSRegEncoding(const ValueRef& ref)
case SV_INVOCATION_ID: return 0x11;
case SV_YDIR: return 0x12;
case SV_THREAD_KILL: return 0x13;
+ case SV_COMBINED_TID: return 0x20;
case SV_TID: return 0x21 + SDATA(ref).sv.index;
case SV_CTAID: return 0x25 + SDATA(ref).sv.index;
case SV_NTID: return 0x29 + SDATA(ref).sv.index;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
index 36ab837f6e..1f0fd466a9 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
@@ -1201,6 +1201,9 @@ NV50LoweringPreSSA::handleRDSV(Instruction *i)
bld.mkMov(def, bld.mkImm(0));
}
break;
+ case SV_COMBINED_TID:
+ bld.mkMov(def, tid);
+ break;
case SV_SAMPLE_POS: {
Value *off = new_LValue(func, FILE_ADDRESS);
bld.mkOp1(OP_RDSV, TYPE_U32, def, bld.mkSysVal(SV_SAMPLE_INDEX, 0));
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 597dcdffbe..1410cf26c8 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -2576,6 +2576,18 @@ NVC0LoweringPass::handleRDSV(Instruction *i)
// TGSI
[Mesa-dev] [PATCH 1/2] drm-uapi: Update drm_fourcc.h for new format modifiers.
This brings in the Broadcom VC4 SAND and V3D 3.x+ UIF modifiers, from
drm-next commit 4da1d4c751c9b1b713c13043bad7c4d27cd1418c.
---
In sending this series, I'm just looking for an ack from someone for
updating the drm_fourcc.h from drm-next.
include/drm-uapi/drm_fourcc.h | 80 +++
1 file changed, 80 insertions(+)
diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
index e04613d30a13..d5e52350a3aa 100644
--- a/include/drm-uapi/drm_fourcc.h
+++ b/include/drm-uapi/drm_fourcc.h
@@ -384,6 +384,23 @@ extern "C" {
#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
fourcc_mod_code(NVIDIA, 0x15)
+/*
+ * Some Broadcom modifiers take parameters, for example the number of
+ * vertical lines in the image. Reserve the lower 32 bits for modifier
+ * type, and the next 24 bits for parameters. Top 8 bits are the
+ * vendor code.
+ */
+#define __fourcc_mod_broadcom_param_shift 8
+#define __fourcc_mod_broadcom_param_bits 48
+#define fourcc_mod_broadcom_code(val, params) \
+ fourcc_mod_code(BROADCOM, __u64)params) <<
__fourcc_mod_broadcom_param_shift) | val))
+#define fourcc_mod_broadcom_param(m) \
+ ((int)(((m) >> __fourcc_mod_broadcom_param_shift) & \
+ ((1ULL << __fourcc_mod_broadcom_param_bits) - 1)))
+#define fourcc_mod_broadcom_mod(m) \
+ ((m) & ~(((1ULL << __fourcc_mod_broadcom_param_bits) - 1) <<\
+__fourcc_mod_broadcom_param_shift))
+
/*
* Broadcom VC4 "T" format
*
@@ -405,6 +422,69 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED fourcc_mod_code(BROADCOM, 1)
+/*
+ * Broadcom SAND format
+ *
+ * This is the native format that the H.264 codec block uses. For VC4
+ * HVS, it is only valid for H.264 (NV12/21) and RGBA modes.
+ *
+ * The image can be considered to be split into columns, and the
+ * columns are placed consecutively into memory. The width of those
+ * columns can be either 32, 64, 128, or 256 pixels, but in practice
+ * only 128 pixel columns are used.
+ *
+ * The pitch between the start of each column is set to optimally
+ * switch between SDRAM banks. This is passed as the number of lines
+ * of column width in the modifier (we can't use the stride value due
+ * to various core checks that look at it , so you should set the
+ * stride to width*cpp).
+ *
+ * Note that the column height for this format modifier is the same
+ * for all of the planes, assuming that each column contains both Y
+ * and UV. Some SAND-using hardware stores UV in a separate tiled
+ * image from Y to reduce the column height, which is not supported
+ * with these modifiers.
+ */
+
+#define DRM_FORMAT_MOD_BROADCOM_SAND32_COL_HEIGHT(v) \
+ fourcc_mod_broadcom_code(2, v)
+#define DRM_FORMAT_MOD_BROADCOM_SAND64_COL_HEIGHT(v) \
+ fourcc_mod_broadcom_code(3, v)
+#define DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT(v) \
+ fourcc_mod_broadcom_code(4, v)
+#define DRM_FORMAT_MOD_BROADCOM_SAND256_COL_HEIGHT(v) \
+ fourcc_mod_broadcom_code(5, v)
+
+#define DRM_FORMAT_MOD_BROADCOM_SAND32 \
+ DRM_FORMAT_MOD_BROADCOM_SAND32_COL_HEIGHT(0)
+#define DRM_FORMAT_MOD_BROADCOM_SAND64 \
+ DRM_FORMAT_MOD_BROADCOM_SAND64_COL_HEIGHT(0)
+#define DRM_FORMAT_MOD_BROADCOM_SAND128 \
+ DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT(0)
+#define DRM_FORMAT_MOD_BROADCOM_SAND256 \
+ DRM_FORMAT_MOD_BROADCOM_SAND256_COL_HEIGHT(0)
+
+/* Broadcom UIF format
+ *
+ * This is the common format for the current Broadcom multimedia
+ * blocks, including V3D 3.x and newer, newer video codecs, and
+ * displays.
+ *
+ * The image consists of utiles (64b blocks), UIF blocks (2x2 utiles),
+ * and macroblocks (4x4 UIF blocks). Those 4x4 UIF block groups are
+ * stored in columns, with padding between the columns to ensure that
+ * moving from one column to the next doesn't hit the same SDRAM page
+ * bank.
+ *
+ * To calculate the padding, it is assumed that each hardware block
+ * and the software driving it knows the platform's SDRAM page size,
+ * number of banks, and XOR address, and that it's identical between
+ * all blocks using the format. This tiling modifier will use XOR as
+ * necessary to reduce the padding. If a hardware block can't do XOR,
+ * the assumption is that a no-XOR tiling modifier will be created.
+ */
+#define DRM_FORMAT_MOD_BROADCOM_UIF fourcc_mod_code(BROADCOM, 6)
+
#if defined(__cplusplus)
}
#endif
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] v3d: Fix tiling modifier support to use the new UIF define.
You can't use T tiled buffers on V3D 3.x and newer, it's been replaced
with a newer layout shared with other hardware blocks.
---
src/gallium/drivers/v3d/v3d_resource.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/v3d/v3d_resource.c
b/src/gallium/drivers/v3d/v3d_resource.c
index cd49c1af52bc..a9c337b69c03 100644
--- a/src/gallium/drivers/v3d/v3d_resource.c
+++ b/src/gallium/drivers/v3d/v3d_resource.c
@@ -324,6 +324,17 @@ v3d_resource_get_handle(struct pipe_screen *pscreen,
*/
bo->private = false;
+if (rsc->tiled) {
+/* A shared tiled buffer should always be allocated as UIF,
+ * not UBLINEAR or LT.
+ */
+assert(rsc->slices[0].tiling == VC5_TILING_UIF_XOR ||
+ rsc->slices[0].tiling == VC5_TILING_UIF_NO_XOR);
+whandle->modifier = DRM_FORMAT_MOD_BROADCOM_UIF;
+} else {
+whandle->modifier = DRM_FORMAT_MOD_LINEAR;
+}
+
switch (whandle->type) {
case WINSYS_HANDLE_TYPE_SHARED:
return v3d_bo_flink(bo, >handle);
@@ -651,7 +662,7 @@ v3d_resource_create_with_modifiers(struct pipe_screen
*pscreen,
linear_ok = true;
rsc->tiled = should_tile;
} else if (should_tile &&
- find_modifier(DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED,
+ find_modifier(DRM_FORMAT_MOD_BROADCOM_UIF,
modifiers, count)) {
rsc->tiled = true;
} else if (linear_ok) {
@@ -697,10 +708,12 @@ v3d_resource_from_handle(struct pipe_screen *pscreen,
switch (whandle->modifier) {
case DRM_FORMAT_MOD_LINEAR:
-case DRM_FORMAT_MOD_INVALID:
rsc->tiled = false;
break;
-/* XXX: UIF */
+case DRM_FORMAT_MOD_BROADCOM_UIF:
+case DRM_FORMAT_MOD_INVALID:
+rsc->tiled = true;
+break;
default:
fprintf(stderr,
"Attempt to import unsupported modifier 0x%llx\n",
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx: Don't allow glXMakeContextCurrent() with only one valid drawable
Adam Jackson writes: > Drawable and readable need to either both be None or both be non-None. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Check for xcb-randr version and xrandr to enable leasing
Hi Danylo, I just run into the same issue, thanks for fixing this with autotools. I think the same issue remains with meson though. Thanks, - Lionel On 20/06/18 14:25, Danylo Piliaiev wrote: VK_USE_PLATFORM_XLIB_XRANDR_EXT requires xlib leasing which requires xcb-randr >= 1.13. Also xrandr header is required for this extension. The extension should not be automatically enabled if these dependencies aren't satisfied. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106976 Signed-off-by: Danylo Piliaiev --- configure.ac | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/configure.ac b/configure.ac index 0652410..ab59e06 100644 --- a/configure.ac +++ b/configure.ac @@ -97,6 +97,7 @@ XCBDRI2_REQUIRED=1.8 XCBDRI3_MODIFIERS_REQUIRED=1.13 XCBGLX_REQUIRED=1.8.1 XCBPRESENT_MODIFIERS_REQUIRED=1.13 +XCBRANDR_XLEASE_REQUIRED=1.13 XDAMAGE_REQUIRED=1.1 XSHMFENCE_REQUIRED=1.1 XVMC_REQUIRED=1.0.6 @@ -1867,18 +1868,6 @@ if test x"$enable_dri3" = xyes; then fi fi - -if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 'drm'; then -have_xlease=yes -else -have_xlease=no -fi - -if test x"$have_xlease" = xyes; then -randr_modules="x11-xcb xcb-randr" -PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules]) -fi - AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11') AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland') AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm') @@ -1896,12 +1885,20 @@ xno) ;; *) if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 'drm'; then -enable_xlib_lease=yes +xlease_modules="x11-xcb xcb-randr >= $XCBRANDR_XLEASE_REQUIRED xrandr" +PKG_CHECK_EXISTS([$xlease_modules], [enable_xlib_lease=yes], [enable_xlib_lease=no]) else enable_xlib_lease=no fi esac +if test x"$enable_xlib_lease" = xyes; then +randr_modules="x11-xcb xcb-randr >= $XCBRANDR_XLEASE_REQUIRED" +PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules]) +xlib_randr_modules="xrandr" +PKG_CHECK_MODULES([XLIB_RANDR], [$xlib_randr_modules]) +fi + AM_CONDITIONAL(HAVE_XLIB_LEASE, test "x$enable_xlib_lease" = xyes) dnl ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: don't check ccs_e support if isl_format is ISL_FORMAT_UNSUPPORTED
Hi Lionel, The original problem we saw happened when dri format is __DRI_IMAGE_FORMAT_XBGR2101010, which doesn't have any corresponding ISL format available. And yes, I verified the problem we saw doesn't happen anymore with the latest code base possibly with your fix. So I could turn down this patch. However, in general, doesn't it make sense to stop when there's no matched ISL format instead of passing it down, which leads to assertion error? Thanks, DW On Fri, Jul 06, 2018 at 02:14:42PM +0100, Lionel Landwerlin wrote: > Hi Dongwon, > > Jason & I merged some patches to fix similar issues a few weeks ago. > I think we didn't change this function because a crash or hitting an assert > is a good indication that something's gone wrong before we run into this > function. > > If you patch fixes an issue, could you give some detail about it? > Maybe a gdb backtrace? > > Thanks, > > - > Lionel > > On 05/07/18 19:27, Dongwon Kim wrote: > >'ISL_FORMAT_UNSUPPORTED' shouldn't be passed down for evaluation as it is > >strictly prohibited in isl code (e.g. format_info_exists). > > > >Signed-off-by: Dongwon Kim > >--- > > src/mesa/drivers/dri/i965/intel_screen.c | 12 ++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > >diff --git a/src/mesa/drivers/dri/i965/intel_screen.c > >b/src/mesa/drivers/dri/i965/intel_screen.c > >index cb357419a7..a65042da72 100644 > >--- a/src/mesa/drivers/dri/i965/intel_screen.c > >+++ b/src/mesa/drivers/dri/i965/intel_screen.c > >@@ -346,8 +346,16 @@ modifier_is_supported(const struct gen_device_info > >*devinfo, > > */ > >format = _mesa_format_fallback_rgbx_to_rgba(format); > >format = _mesa_get_srgb_format_linear(format); > >- if (!isl_format_supports_ccs_e(devinfo, > >- > >brw_isl_format_for_mesa_format(format))) > >+ > >+ enum isl_format isl_format; > >+ isl_format = brw_isl_format_for_mesa_format(format); > >+ > >+ /* whether there is supported ISL format for given mesa format */ > >+ if (isl_format == ISL_FORMAT_UNSUPPORTED) > >+ return false; > >+ > >+ /* check if isl_fomat supports ccs_e */ > >+ if (!isl_format_supports_ccs_e(devinfo, isl_format)) > > return false; > > } > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx: Don't allow glXMakeContextCurrent() with only one valid drawable
Drawable and readable need to either both be None or both be non-None.
Cc:
Signed-off-by: Adam Jackson
---
src/glx/glxcurrent.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/glx/glxcurrent.c b/src/glx/glxcurrent.c
index fd04929b89f..2b9c708c3ee 100644
--- a/src/glx/glxcurrent.c
+++ b/src/glx/glxcurrent.c
@@ -194,6 +194,13 @@ MakeContextCurrent(Display * dpy, GLXDrawable draw,
return True;
}
+ /* can't have only one be 0 */
+ if (!!draw != !!read) {
+ __glXUnlock();
+ __glXSendError(dpy, BadMatch, None, X_GLXMakeContextCurrent, True);
+ return False;
+ }
+
if (oldGC != ) {
if (--oldGC->thread_refcount == 0) {
oldGC->vtable->unbind(oldGC, gc);
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/26] python: Use the Python 3 exception syntax
I've gone ahead and tested (through our CI) and pushed patches 1-3 with the
relevant *-bys added from Me, Eric, and Ian. I wanted to get patch 1 merged
quickly due to the high chance of conflicts.
Dylan
Quoting Mathieu Bridon (2018-07-05 06:17:34)
> This is compatible with Python versions >= 2.6.
>
> Signed-off-by: Mathieu Bridon
> ---
> src/mapi/glapi/gen/glX_XML.py | 2 +-
> src/mapi/glapi/gen/gl_XML.py| 6 +++---
> src/mapi/glapi/gen/gl_marshal.py| 2 +-
> src/mapi/glapi/gen/gl_marshal_h.py | 2 +-
> src/mesa/main/get_hash_generator.py | 2 +-
> 5 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/src/mapi/glapi/gen/glX_XML.py b/src/mapi/glapi/gen/glX_XML.py
> index b6d305c879..e1aa1b3e61 100644
> --- a/src/mapi/glapi/gen/glX_XML.py
> +++ b/src/mapi/glapi/gen/glX_XML.py
> @@ -470,7 +470,7 @@ class glx_function(gl_XML.gl_function):
> def needs_reply(self):
> try:
> x = self._needs_reply
> -except Exception, e:
> +except Exception as e:
> x = 0
> if self.return_type != 'void':
> x = 1
> diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
> index 3a191abe0d..330ca0e5a6 100644
> --- a/src/mapi/glapi/gen/gl_XML.py
> +++ b/src/mapi/glapi/gen/gl_XML.py
> @@ -284,7 +284,7 @@ def classify_category(name, number):
>
> try:
> core_version = float(name)
> -except Exception,e:
> +except Exception as e:
> core_version = 0.0
>
> if core_version > 0.0:
> @@ -365,7 +365,7 @@ class gl_enum( gl_item ):
> else:
> try:
> c = int(temp)
> -except Exception,e:
> +except Exception as e:
> raise RuntimeError('Invalid count value "%s" for enum "%s"
> in function "%s" when an integer was expected.' % (temp, self.name, n))
>
> self.default_count = c
> @@ -426,7 +426,7 @@ class gl_parameter(object):
> count = int(c)
> self.count = count
> self.counter = None
> -except Exception,e:
> +except Exception as e:
> count = 1
> self.count = 0
> self.counter = c
> diff --git a/src/mapi/glapi/gen/gl_marshal.py
> b/src/mapi/glapi/gen/gl_marshal.py
> index e9dd2c4f78..18d7a7012b 100644
> --- a/src/mapi/glapi/gen/gl_marshal.py
> +++ b/src/mapi/glapi/gen/gl_marshal.py
> @@ -353,7 +353,7 @@ if __name__ == '__main__':
>
> try:
> (args, trail) = getopt.getopt(sys.argv[1:], 'm:f:')
> -except Exception,e:
> +except Exception as e:
> show_usage()
>
> for (arg,val) in args:
> diff --git a/src/mapi/glapi/gen/gl_marshal_h.py
> b/src/mapi/glapi/gen/gl_marshal_h.py
> index 6490595a00..a7a9eda573 100644
> --- a/src/mapi/glapi/gen/gl_marshal_h.py
> +++ b/src/mapi/glapi/gen/gl_marshal_h.py
> @@ -74,7 +74,7 @@ if __name__ == '__main__':
>
> try:
> (args, trail) = getopt.getopt(sys.argv[1:], 'm:f:')
> -except Exception,e:
> +except Exception:
> show_usage()
>
> for (arg,val) in args:
> diff --git a/src/mesa/main/get_hash_generator.py
> b/src/mesa/main/get_hash_generator.py
> index 86c6771066..facdccd8a5 100644
> --- a/src/mesa/main/get_hash_generator.py
> +++ b/src/mesa/main/get_hash_generator.py
> @@ -201,7 +201,7 @@ def show_usage():
> if __name__ == '__main__':
> try:
>(opts, args) = getopt.getopt(sys.argv[1:], "f:")
> - except Exception,e:
> + except Exception:
>show_usage()
>
> if len(args) != 0:
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106151] [amdgpu][vulkan] GPU hang (Vega 56) while running game (Rise of the Tomb Raider)
https://bugs.freedesktop.org/show_bug.cgi?id=106151 --- Comment #25 from pritzl3...@gmail.com --- (In reply to Samuel Pitoiset from comment #20) > Created attachment 140246 [details] [review] > possible fix > > Does this patch help? The game still hangs with this patch using Mesa 18.1.3. -- 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 106151] [amdgpu][vulkan] GPU hang (Vega 56) while running game (Rise of the Tomb Raider)
https://bugs.freedesktop.org/show_bug.cgi?id=106151 --- Comment #24 from pritzl3...@gmail.com --- (In reply to Samuel Pitoiset from comment #19) > Thanks, what preset do you use? I'm using the high preset and I have disabled AA. Resolution is 3840x2160. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/26] python: Use range() instead of xrange()
This patch is
Reviewed-by: Ian Romanick
On 07/06/2018 03:22 AM, Mathieu Bridon wrote:
> Python 2 has a range() function which returns a list, and an xrange()
> one which returns an iterator.
>
> Python 3 lost the function returning a list, and renamed the function
> returning an iterator as range().
>
> As a result, using range() makes the scripts compatible with both Python
> versions 2 and 3.
>
> Signed-off-by: Mathieu Bridon
> ---
> src/amd/vulkan/radv_entrypoints_gen.py | 2 +-
> src/broadcom/cle/gen_pack_header.py | 2 +-
> src/compiler/glsl/ir_expression_operation.py | 2 +-
> src/compiler/nir/nir_opcodes.py | 4 ++--
> src/intel/vulkan/anv_entrypoints_gen.py | 2 +-
> src/mapi/glapi/gen/glX_proto_send.py | 2 +-
> src/mapi/glapi/gen/gl_gentable.py| 4 ++--
> src/mapi/mapi_abi.py | 2 +-
> src/mesa/main/format_parser.py | 4 ++--
> 9 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_entrypoints_gen.py
> b/src/amd/vulkan/radv_entrypoints_gen.py
> index 9c4dfd02a0..ca022bcbb0 100644
> --- a/src/amd/vulkan/radv_entrypoints_gen.py
> +++ b/src/amd/vulkan/radv_entrypoints_gen.py
> @@ -136,7 +136,7 @@ static const struct string_map_entry string_map_entries[]
> = {
> /* Hash table stats:
> * size ${len(strmap.sorted_strings)} entries
> * collisions entries:
> -% for i in xrange(10):
> +% for i in range(10):
> * ${i}${'+' if i == 9 else ' '} ${strmap.collisions[i]}
> % endfor
> */
> diff --git a/src/broadcom/cle/gen_pack_header.py
> b/src/broadcom/cle/gen_pack_header.py
> index c6e1c564e6..8ad54464cb 100644
> --- a/src/broadcom/cle/gen_pack_header.py
> +++ b/src/broadcom/cle/gen_pack_header.py
> @@ -216,7 +216,7 @@ class Group(object):
> first_byte = field.start // 8
> last_byte = field.end // 8
>
> -for b in xrange(first_byte, last_byte + 1):
> +for b in range(first_byte, last_byte + 1):
> if not b in bytes:
> bytes[b] = self.Byte()
>
> diff --git a/src/compiler/glsl/ir_expression_operation.py
> b/src/compiler/glsl/ir_expression_operation.py
> index b3dac3da3f..16b98690a6 100644
> --- a/src/compiler/glsl/ir_expression_operation.py
> +++ b/src/compiler/glsl/ir_expression_operation.py
> @@ -116,7 +116,7 @@ constant_template_common = mako.template.Template("""\
> constant_template_vector_scalar = mako.template.Template("""\
> case ${op.get_enum_name()}:
> % if "mixed" in op.flags:
> -% for i in xrange(op.num_operands):
> +% for i in range(op.num_operands):
>assert(op[${i}]->type->base_type == ${op.source_types[0].glsl_type} ||
> % for src_type in op.source_types[1:-1]:
> op[${i}]->type->base_type == ${src_type.glsl_type} ||
> diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
> index 3c3316dcaa..b03c5da2ea 100644
> --- a/src/compiler/nir/nir_opcodes.py
> +++ b/src/compiler/nir/nir_opcodes.py
> @@ -367,8 +367,8 @@ for (unsigned bit = 0; bit < bit_size; bit++) {
> """)
>
>
> -for i in xrange(1, 5):
> - for j in xrange(1, 5):
> +for i in range(1, 5):
> + for j in range(1, 5):
>unop_horiz("fnoise{0}_{1}".format(i, j), i, tfloat, j, tfloat, "0.0f")
>
>
> diff --git a/src/intel/vulkan/anv_entrypoints_gen.py
> b/src/intel/vulkan/anv_entrypoints_gen.py
> index 8a37336496..5e2cd0740a 100644
> --- a/src/intel/vulkan/anv_entrypoints_gen.py
> +++ b/src/intel/vulkan/anv_entrypoints_gen.py
> @@ -145,7 +145,7 @@ static const struct string_map_entry string_map_entries[]
> = {
> /* Hash table stats:
> * size ${len(strmap.sorted_strings)} entries
> * collisions entries:
> -% for i in xrange(10):
> +% for i in range(10):
> * ${i}${'+' if i == 9 else ' '} ${strmap.collisions[i]}
> % endfor
> */
> diff --git a/src/mapi/glapi/gen/glX_proto_send.py
> b/src/mapi/glapi/gen/glX_proto_send.py
> index fba2f0cc1e..a920ecc012 100644
> --- a/src/mapi/glapi/gen/glX_proto_send.py
> +++ b/src/mapi/glapi/gen/glX_proto_send.py
> @@ -392,7 +392,7 @@ static const struct proc_pair
> _glapi_proc proc;
> } proc_pairs[%d] = {""" % len(procs))
> names = sorted(procs.keys())
> -for i in xrange(len(names)):
> +for i in range(len(names)):
> comma = ',' if i < len(names) - 1 else ''
> print(' { "%s", (_glapi_proc) gl%s }%s' % (names[i],
> procs[names[i]], comma))
> print("""};
> diff --git a/src/mapi/glapi/gen/gl_gentable.py
> b/src/mapi/glapi/gen/gl_gentable.py
> index 49206b1167..9d8923cf8d 100644
> --- a/src/mapi/glapi/gen/gl_gentable.py
> +++ b/src/mapi/glapi/gen/gl_gentable.py
> @@ -216,13 +216,13 @@ class PrintCode(gl_XML.gl_print_base):
>
> # Check that the table has no gaps. We expect a function at every
> offset,
> # and the code which generates the table relies on this.
> -
Re: [Mesa-dev] [PATCH 07/26] python: Better sort dictionary keys/values
This patch is
Reviewed-by: Ian Romanick
On 07/06/2018 03:17 AM, Mathieu Bridon wrote:
> In Python 2, dict.keys() and dict.values() both return a list, which can
> be sorted in two ways:
>
> * l.sort() modifies the list in-place;
> * sorted(l) returns a new, sorted list;
>
> In Python 3, dict.keys() and dict.values() do not return lists any more,
> but iterators. Iterators do not have a .sort() method.
>
> This commit moves the build scripts to using sorted() on dict keys and
> values, which makes them compatible with both Python 2 and Python 3.
>
> Signed-off-by: Mathieu Bridon
> ---
> src/mapi/glapi/gen/glX_proto_send.py | 3 +--
> src/mapi/glapi/gen/glX_proto_size.py | 6 ++
> src/mapi/glapi/gen/gl_XML.py | 12
> src/mapi/glapi/gen/gl_procs.py | 3 +--
> src/mapi/mapi_abi.py | 6 ++
> 5 files changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/src/mapi/glapi/gen/glX_proto_send.py
> b/src/mapi/glapi/gen/glX_proto_send.py
> index c389872044..fba2f0cc1e 100644
> --- a/src/mapi/glapi/gen/glX_proto_send.py
> +++ b/src/mapi/glapi/gen/glX_proto_send.py
> @@ -391,8 +391,7 @@ static const struct proc_pair
> const char *name;
> _glapi_proc proc;
> } proc_pairs[%d] = {""" % len(procs))
> -names = procs.keys()
> -names.sort()
> +names = sorted(procs.keys())
> for i in xrange(len(names)):
> comma = ',' if i < len(names) - 1 else ''
> print(' { "%s", (_glapi_proc) gl%s }%s' % (names[i],
> procs[names[i]], comma))
> diff --git a/src/mapi/glapi/gen/glX_proto_size.py
> b/src/mapi/glapi/gen/glX_proto_size.py
> index 18a6f2e502..2a843c3e24 100644
> --- a/src/mapi/glapi/gen/glX_proto_size.py
> +++ b/src/mapi/glapi/gen/glX_proto_size.py
> @@ -208,8 +208,7 @@ class glx_enum_function(object):
> for enum_obj in self.enums[e]:
> list[ enum_obj.priority() ] = enum_obj.name
>
> -keys = list.keys()
> -keys.sort()
> +keys = sorted(list.keys())
> for k in keys:
> j = list[k]
> if first:
> @@ -275,8 +274,7 @@ class glx_server_enum_function(glx_enum_function):
> o = f.offset_of( param_name )
> foo[o] = param_name
>
> -keys = foo.keys()
> -keys.sort()
> +keys = sorted(foo.keys())
> for o in keys:
> p = f.parameters_by_name[ foo[o] ]
>
> diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
> index 20057cf9c4..7bd5a1f4e4 100644
> --- a/src/mapi/glapi/gen/gl_XML.py
> +++ b/src/mapi/glapi/gen/gl_XML.py
> @@ -988,12 +988,10 @@ class gl_api(object):
>
> functions = []
> for func_cat_type in range(0,4):
> -keys = lists[func_cat_type].keys()
> -keys.sort()
> +keys = sorted(lists[func_cat_type].keys())
>
> for key in keys:
> -names = lists[func_cat_type][key].keys()
> -names.sort()
> +names = sorted(lists[func_cat_type][key].keys())
>
> for name in names:
> functions.append(lists[func_cat_type][key][name])
> @@ -1027,8 +1025,7 @@ class gl_api(object):
>
>
> def enumIterateByName(self):
> -keys = self.enums_by_name.keys()
> -keys.sort()
> +keys = sorted(self.enums_by_name.keys())
>
> list = []
> for enum in keys:
> @@ -1047,8 +1044,7 @@ class gl_api(object):
>
> list = []
> for cat_type in range(0,4):
> -keys = self.categories[cat_type].keys()
> -keys.sort()
> +keys = sorted(self.categories[cat_type].keys())
>
> for key in keys:
> list.append(self.categories[cat_type][key])
> diff --git a/src/mapi/glapi/gen/gl_procs.py b/src/mapi/glapi/gen/gl_procs.py
> index 5718f42ab6..4bd3321610 100644
> --- a/src/mapi/glapi/gen/gl_procs.py
> +++ b/src/mapi/glapi/gen/gl_procs.py
> @@ -144,8 +144,7 @@ typedef struct {
> print('')
> print('/* OpenGL ES specific prototypes */')
> print('')
> -keys = categories.keys()
> -keys.sort()
> +keys = sorted(categories.keys())
> for key in keys:
> print('/* category %s */' % key)
> print("\n".join(categories[key]))
> diff --git a/src/mapi/mapi_abi.py b/src/mapi/mapi_abi.py
> index e3f65547bf..826721479d 100644
> --- a/src/mapi/mapi_abi.py
> +++ b/src/mapi/mapi_abi.py
> @@ -180,8 +180,7 @@ def abi_parse_xml(xml):
> ent = ABIEntry(cols, attrs, func)
> entry_dict[ent.name] = ent
>
> -entries = entry_dict.values()
> -entries.sort()
> +entries = sorted(entry_dict.values())
>
> return entries
>
> @@ -250,8 +249,7 @@ def abi_parse(filename):
>
Re: [Mesa-dev] [PATCH 04/26] python: Better check for keys in dicts
I don't think I knew about the "in" operator when I wrote that code... a lot of it is pretty old, so it may not have even existed in 2005. :) This patch is Reviewed-by: Ian Romanick On 07/06/2018 03:15 AM, Mathieu Bridon wrote: > Python 3 lost the dict.has_key() method. Instead it requires using the > "in" operator. > > This is also compatible with Python 2. > > Signed-off-by: Mathieu Bridon > --- > src/mapi/glapi/gen/glX_XML.py| 2 +- > src/mapi/glapi/gen/glX_proto_send.py | 2 +- > src/mapi/glapi/gen/glX_proto_size.py | 18 +- > src/mapi/glapi/gen/gl_XML.py | 6 +++--- > src/mapi/glapi/gen/gl_procs.py | 2 +- > src/mapi/mapi_abi.py | 4 ++-- > src/util/xmlpool/gen_xmlpool.py | 4 ++-- > 7 files changed, 19 insertions(+), 19 deletions(-) > > diff --git a/src/mapi/glapi/gen/glX_XML.py b/src/mapi/glapi/gen/glX_XML.py > index d09370a508..e10c8b0a09 100644 > --- a/src/mapi/glapi/gen/glX_XML.py > +++ b/src/mapi/glapi/gen/glX_XML.py > @@ -64,7 +64,7 @@ class glx_enum(gl_XML.gl_enum): > else: > mode = 1 > > -if not self.functions.has_key(n): > +if n not in self.functions: > self.functions[ n ] = [c, mode] > > return > diff --git a/src/mapi/glapi/gen/glX_proto_send.py > b/src/mapi/glapi/gen/glX_proto_send.py > index f199e9a0a1..7ab1eb4a70 100644 > --- a/src/mapi/glapi/gen/glX_proto_send.py > +++ b/src/mapi/glapi/gen/glX_proto_send.py > @@ -842,7 +842,7 @@ generic_%u_byte( GLint rop, const void * ptr ) > > > def printPixelFunction(self, f): > -if self.pixel_stubs.has_key( f.name ): > +if f.name in self.pixel_stubs: > # Normally gl_function::get_parameter_string could be > # used. However, this call needs to have the missing > # dimensions (e.g., a fake height value for > diff --git a/src/mapi/glapi/gen/glX_proto_size.py > b/src/mapi/glapi/gen/glX_proto_size.py > index 284ee70e61..18a6f2e502 100644 > --- a/src/mapi/glapi/gen/glX_proto_size.py > +++ b/src/mapi/glapi/gen/glX_proto_size.py > @@ -71,7 +71,7 @@ class glx_enum_function(object): > for enum_name in enum_dict: > e = enum_dict[ enum_name ] > > -if e.functions.has_key( match_name ): > +if match_name in e.functions: > [count, mode] = e.functions[ match_name ] > > if mode_set and mode != self.mode: > @@ -79,11 +79,11 @@ class glx_enum_function(object): > > self.mode = mode > > -if self.enums.has_key( e.value ): > +if e.value in self.enums: > if e.name not in self.enums[ e.value ]: > self.enums[ e.value ].append( e ) > else: > -if not self.count.has_key( count ): > +if count not in self.count: > self.count[ count ] = [] > > self.enums[ e.value ] = [ e ] > @@ -131,7 +131,7 @@ class glx_enum_function(object): > for a in self.enums: > count += 1 > > -if self.count.has_key(-1): > +if -1 in self.count: > return 0 > > # Determine if there is some mask M, such that M = (2^N) - 1, > @@ -356,7 +356,7 @@ class PrintGlxSizeStubs_c(PrintGlxSizeStubs_common): > > if (ef.is_set() and self.emit_set) or (not ef.is_set() and > self.emit_get): > sig = ef.signature() > -if enum_sigs.has_key( sig ): > +if sig in enum_sigs: > aliases.append( [func.name, enum_sigs[ sig ]] ) > else: > enum_sigs[ sig ] = func.name > @@ -477,10 +477,10 @@ class PrintGlxReqSize_c(PrintGlxReqSize_common): > > sig = ef.signature() > > -if not enum_functions.has_key(func.name): > +if func.name not in enum_functions: > enum_functions[ func.name ] = sig > > -if not enum_sigs.has_key( sig ): > +if sig not in enum_sigs: > enum_sigs[ sig ] = ef > > > @@ -496,7 +496,7 @@ class PrintGlxReqSize_c(PrintGlxReqSize_common): > if func.server_handcode: continue > if not func.has_variable_size_request(): continue > > -if enum_functions.has_key(func.name): > +if func.name in enum_functions: > sig = enum_functions[func.name] > ef = enum_sigs[ sig ] > > @@ -621,7 +621,7 @@ class PrintGlxReqSize_c(PrintGlxReqSize_common): > # already be emitted, don't emit this function. Instead, add > # it to the list of function aliases. > > -if self.counter_sigs.has_key(sig): > +if sig in self.counter_sigs: > n = self.counter_sigs[sig]; > alias = [f.name, n] > else: >
Re: [Mesa-dev] [PATCH 03/26] python: Stop using the Python 2 exception syntax
This patch is
Reviewed-by: Ian Romanick
On 07/06/2018 03:13 AM, Mathieu Bridon wrote:
> We could have made this compatible with Python 3 by using:
>
> except Exception as e:
>
> But since none of this code actually uses the exception objects, let's
> just drop them entirely.
>
> Signed-off-by: Mathieu Bridon
> ---
> src/mapi/glapi/gen/glX_XML.py | 2 +-
> src/mapi/glapi/gen/gl_XML.py| 6 +++---
> src/mapi/glapi/gen/gl_marshal.py| 2 +-
> src/mapi/glapi/gen/gl_marshal_h.py | 2 +-
> src/mesa/main/get_hash_generator.py | 2 +-
> 5 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/src/mapi/glapi/gen/glX_XML.py b/src/mapi/glapi/gen/glX_XML.py
> index b6d305c879..d09370a508 100644
> --- a/src/mapi/glapi/gen/glX_XML.py
> +++ b/src/mapi/glapi/gen/glX_XML.py
> @@ -470,7 +470,7 @@ class glx_function(gl_XML.gl_function):
> def needs_reply(self):
> try:
> x = self._needs_reply
> -except Exception, e:
> +except Exception:
> x = 0
> if self.return_type != 'void':
> x = 1
> diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
> index 3a191abe0d..bfeacf1386 100644
> --- a/src/mapi/glapi/gen/gl_XML.py
> +++ b/src/mapi/glapi/gen/gl_XML.py
> @@ -284,7 +284,7 @@ def classify_category(name, number):
>
> try:
> core_version = float(name)
> -except Exception,e:
> +except Exception:
> core_version = 0.0
>
> if core_version > 0.0:
> @@ -365,7 +365,7 @@ class gl_enum( gl_item ):
> else:
> try:
> c = int(temp)
> -except Exception,e:
> +except Exception:
> raise RuntimeError('Invalid count value "%s" for enum "%s"
> in function "%s" when an integer was expected.' % (temp, self.name, n))
>
> self.default_count = c
> @@ -426,7 +426,7 @@ class gl_parameter(object):
> count = int(c)
> self.count = count
> self.counter = None
> -except Exception,e:
> +except Exception:
> count = 1
> self.count = 0
> self.counter = c
> diff --git a/src/mapi/glapi/gen/gl_marshal.py
> b/src/mapi/glapi/gen/gl_marshal.py
> index e9dd2c4f78..5b35357ac5 100644
> --- a/src/mapi/glapi/gen/gl_marshal.py
> +++ b/src/mapi/glapi/gen/gl_marshal.py
> @@ -353,7 +353,7 @@ if __name__ == '__main__':
>
> try:
> (args, trail) = getopt.getopt(sys.argv[1:], 'm:f:')
> -except Exception,e:
> +except Exception:
> show_usage()
>
> for (arg,val) in args:
> diff --git a/src/mapi/glapi/gen/gl_marshal_h.py
> b/src/mapi/glapi/gen/gl_marshal_h.py
> index 6490595a00..a7a9eda573 100644
> --- a/src/mapi/glapi/gen/gl_marshal_h.py
> +++ b/src/mapi/glapi/gen/gl_marshal_h.py
> @@ -74,7 +74,7 @@ if __name__ == '__main__':
>
> try:
> (args, trail) = getopt.getopt(sys.argv[1:], 'm:f:')
> -except Exception,e:
> +except Exception:
> show_usage()
>
> for (arg,val) in args:
> diff --git a/src/mesa/main/get_hash_generator.py
> b/src/mesa/main/get_hash_generator.py
> index 86c6771066..facdccd8a5 100644
> --- a/src/mesa/main/get_hash_generator.py
> +++ b/src/mesa/main/get_hash_generator.py
> @@ -201,7 +201,7 @@ def show_usage():
> if __name__ == '__main__':
> try:
>(opts, args) = getopt.getopt(sys.argv[1:], "f:")
> - except Exception,e:
> + except Exception:
>show_usage()
>
> if len(args) != 0:
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/13] i965/miptree: Add and use mt_surf_usage
On Fri, Jul 06, 2018 at 03:21:31PM +0300, Pohjolainen, Topi wrote:
> On Fri, Jul 06, 2018 at 03:17:14PM +0300, Pohjolainen, Topi wrote:
> > On Tue, Jun 12, 2018 at 12:22:02PM -0700, Nanley Chery wrote:
> > > ---
> > > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 40 ---
> > > 1 file changed, 26 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > index cfb83d15ecc..5e00da86d32 100644
> > > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > @@ -677,6 +677,23 @@ make_separate_stencil_surface(struct brw_context
> > > *brw,
> > > return true;
> > > }
> > >
> > > +/* Return the usual surface usage flags for the given format. */
> > > +static isl_surf_usage_flags_t
> > > +mt_surf_usage(mesa_format format)
> > > +{
> > > + switch(_mesa_get_format_base_format(format)) {
> > > + case GL_DEPTH_COMPONENT:
> > > + return ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT;
> > > + case GL_DEPTH_STENCIL:
> > > + return ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_STENCIL_BIT |
> > > + ISL_SURF_USAGE_TEXTURE_BIT;
> > > + case GL_STENCIL_INDEX:
> > > + return ISL_SURF_USAGE_STENCIL_BIT | ISL_SURF_USAGE_TEXTURE_BIT;
> > > + default:
> > > + return ISL_SURF_USAGE_RENDER_TARGET_BIT |
> > > ISL_SURF_USAGE_TEXTURE_BIT;
> > > + }
> > > +}
> > > +
> > > static struct intel_mipmap_tree *
> > > miptree_create(struct brw_context *brw,
> > > GLenum target,
> > > @@ -713,8 +730,7 @@ miptree_create(struct brw_context *brw,
> > >return make_surface(brw, target, mt_fmt, first_level, last_level,
> > >width0, height0, depth0, num_samples,
> > >tiling_flags,
> > > - ISL_SURF_USAGE_STENCIL_BIT |
> > > - ISL_SURF_USAGE_TEXTURE_BIT,
> > > + mt_surf_usage(mt_fmt),
> > >alloc_flags,
> > >0,
> > >NULL);
> > > @@ -726,7 +742,7 @@ miptree_create(struct brw_context *brw,
> > > brw, target, mt_fmt,
> > > first_level, last_level,
> > > width0, height0, depth0, num_samples, tiling_flags,
> > > - ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT,
> > > + mt_surf_usage(mt_fmt),
> > > alloc_flags, 0, NULL);
> > >
> > >if (needs_separate_stencil(brw, mt, format) &&
> > > @@ -746,8 +762,7 @@ miptree_create(struct brw_context *brw,
> > > first_level, last_level,
> > > width0, height0, depth0,
> > > num_samples, tiling_flags,
> > > - ISL_SURF_USAGE_RENDER_TARGET_BIT |
> > > - ISL_SURF_USAGE_TEXTURE_BIT,
> > > + mt_surf_usage(mt_fmt),
> > > alloc_flags, 0, NULL);
> > > if (!mt)
> > >return NULL;
> > > @@ -816,12 +831,11 @@ intel_miptree_create_for_bo(struct brw_context *brw,
> > >
> > > if ((base_format == GL_DEPTH_COMPONENT ||
> > > base_format == GL_DEPTH_STENCIL)) {
> > > - const mesa_format depth_only_format =
> > > - intel_depth_format_for_depthstencil_format(format);
> > > - mt = make_surface(brw, target,
> > > -devinfo->gen >= 6 ? depth_only_format : format,
> > > + mesa_format mt_fmt = (devinfo->gen < 6) ? format :
> > > +
> > > intel_depth_format_for_depthstencil_format(format);
> >
> > This introduction of helper variable isn't really related. But if you decide
> > to keep it, you could make it const.
>
> And I keep on mis-reading, it is really needed, sorry for the noise.
>
No problem. I'll make the variable const.
v2: Make mt_fmt const (Topi).
-Nanley
> >
> > > + mt = make_surface(brw, target, mt_fmt,
> > > 0, 0, width, height, depth, 1, ISL_TILING_Y0_BIT,
> > > -ISL_SURF_USAGE_DEPTH_BIT |
> > > ISL_SURF_USAGE_TEXTURE_BIT,
> > > +mt_surf_usage(mt_fmt),
> > > 0, pitch, bo);
> > >if (!mt)
> > > return NULL;
> > > @@ -836,8 +850,7 @@ intel_miptree_create_for_bo(struct brw_context *brw,
> > >mt = make_surface(brw, target, MESA_FORMAT_S_UINT8,
> > > 0, 0, width, height, depth, 1,
> > > ISL_TILING_W_BIT,
> > > -ISL_SURF_USAGE_STENCIL_BIT |
> > > -ISL_SURF_USAGE_TEXTURE_BIT,
> > > +mt_surf_usage(MESA_FORMAT_S_UINT8),
> > > 0, pitch, bo);
> > >if (!mt)
> > >
Re: [Mesa-dev] [PATCH] swrast: Fix eglMakeCurrent(dpy, NULL, NULL, ctx)
On 07/06/2018 08:45 AM, Adam Jackson wrote: > On Fri, 2018-07-06 at 10:29 +0100, Emil Velikov wrote: > >> Skimming through the egl_khr_create_context text, this relaxes some >> parts which are meant to be an error. >> For example >> >> * If either of or is a valid surface and the other >> is EGL_NO_SURFACE, an EGL_BAD_MATCH error is generated. > > That seems like an invariant EGL promises for the driver, not something > the driver validates. eglMakeCurrent already says: > > if ((!draw_surf && draw != EGL_NO_SURFACE) || > (!read_surf && read != EGL_NO_SURFACE)) > RETURN_EGL_ERROR(disp, EGL_BAD_SURFACE, EGL_FALSE); > > glXMakeCurrent doesn't seem to have code to generate an error in that > case, anymore. The server would throw an error for the GLXMakeCurrent > request, but we don't always emit those for... bad reasons. Regardless > I'd say that check belongs in MakeContextCurrent, not the driver. That is how we have typically divided up work. The libEGL / libGLX layer handles the API validation, and the driver tries not to crash. :) > - ajax > ___ > 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 0/3] verify max vertex attrib stride
Am 06.07.2018 um 12:03 schrieb Erik Faye-Lund: > OpenGL 4.4 and OpenGL ES 3.1 both require the maximum > vertex attrib stride to be at least 2048. If this isn't > the case, we shouldn't expose these API versions. > > Unfortunately, the r600 driver only supports 2047. To > avoid regressions in the supported GL version, the > first patch modifies the returned value. > > I'm not sure if that last one is a good idea or not, as > it's strictly speaking non-conformant. But applications > won't expect GL errors generated when using strides of > 2048 either, which is what currently happens. > > The initial motivation for this patch-series is to avoid > exposing a too high spec version in virgl and then get > dEQP failures when running on old hardware. The virgl > specific bits are being sent separately, because they > depend on some other not-yet-upstream things ATM. > > Thoughts? > > Erik Faye-Lund (3): > r600: report incorrect max-vertex-attrib for GL 4.4 > mesa: verify MaxVertexAttribStride for GL 4.4 > mesa: verify MaxVertexAttribStride for GLES 3.1 > > src/gallium/drivers/r600/r600_pipe.c | 3 ++- > src/mesa/main/version.c | 2 ++ > 2 files changed, 4 insertions(+), 1 deletion(-) > Personally I think it's _much_ better to lie about the supported GL version rather than the maximum vertex attrib stride (I don't know if dEQP would actually have a test which tests for the max stride also working than just being advertized, which would be way more relevant and fail in any case). (Because if you're going to use stride 2048, it is hugely unlikely you'd just rely on GL 4.4 for that, hence it wouldn't work with older versions of GL anyway neither, where ALL strides are just supposed to work.) Roland FWIW, I think it should be possible to work around that limitation on r600. Since vertex fetch just uses a fetch shader, you could have a shader key bit indicating strides of 2048, program a stride of 1024 instead and multiply the index to fetch by 2 in the shader. Of course that could cause shader recompiles (never in practice...) and there's some overhead associated with it, so might not be worth it... Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] swrast: Fix eglMakeCurrent(dpy, NULL, NULL, ctx)
On Fri, 2018-07-06 at 10:29 +0100, Emil Velikov wrote: > Skimming through the egl_khr_create_context text, this relaxes some > parts which are meant to be an error. > For example > > * If either of or is a valid surface and the other > is EGL_NO_SURFACE, an EGL_BAD_MATCH error is generated. That seems like an invariant EGL promises for the driver, not something the driver validates. eglMakeCurrent already says: if ((!draw_surf && draw != EGL_NO_SURFACE) || (!read_surf && read != EGL_NO_SURFACE)) RETURN_EGL_ERROR(disp, EGL_BAD_SURFACE, EGL_FALSE); glXMakeCurrent doesn't seem to have code to generate an error in that case, anymore. The server would throw an error for the GLXMakeCurrent request, but we don't always emit those for... bad reasons. Regardless I'd say that check belongs in MakeContextCurrent, not the driver. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv/pipeline: honor the pipeline_cache_enabled run-time flag
On 04/07/18 09:44, Iago Toral Quiroga wrote:
---
src/intel/vulkan/anv_pipeline_cache.c | 37 +++
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/src/intel/vulkan/anv_pipeline_cache.c
b/src/intel/vulkan/anv_pipeline_cache.c
index d4c7262dc0..5825bf9f01 100644
--- a/src/intel/vulkan/anv_pipeline_cache.c
+++ b/src/intel/vulkan/anv_pipeline_cache.c
@@ -570,23 +570,26 @@ anv_device_search_for_kernel(struct anv_device *device,
}
I guess you could do :
if (disk_cache && device->instance->pipeline_cache_enabled) {
...
to minimize the diff.
Do we still want to save stuff in the cache (anv_device_upload_kernel)
when cache is disabled?
Regardless :
Reviewed-by: Lionel Landwerlin
Thanks!
#ifdef ENABLE_SHADER_CACHE
- struct disk_cache *disk_cache = device->instance->physicalDevice.disk_cache;
- if (disk_cache) {
- cache_key cache_key;
- disk_cache_compute_key(disk_cache, key_data, key_size, cache_key);
-
- size_t buffer_size;
- uint8_t *buffer = disk_cache_get(disk_cache, cache_key, _size);
- if (buffer) {
- struct blob_reader blob;
- blob_reader_init(, buffer, buffer_size);
- bin = anv_shader_bin_create_from_blob(device, );
- free(buffer);
-
- if (bin) {
-if (cache)
- anv_pipeline_cache_add_shader_bin(cache, bin);
-return bin;
+ if (device->instance->pipeline_cache_enabled) {
+ struct disk_cache *disk_cache =
+ device->instance->physicalDevice.disk_cache;
+ if (disk_cache) {
+ cache_key cache_key;
+ disk_cache_compute_key(disk_cache, key_data, key_size, cache_key);
+
+ size_t buffer_size;
+ uint8_t *buffer = disk_cache_get(disk_cache, cache_key, _size);
+ if (buffer) {
+struct blob_reader blob;
+blob_reader_init(, buffer, buffer_size);
+bin = anv_shader_bin_create_from_blob(device, );
+free(buffer);
+
+if (bin) {
+ if (cache)
+ anv_pipeline_cache_add_shader_bin(cache, bin);
+ return bin;
+}
}
}
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: don't check ccs_e support if isl_format is ISL_FORMAT_UNSUPPORTED
Hi Dongwon, Jason & I merged some patches to fix similar issues a few weeks ago. I think we didn't change this function because a crash or hitting an assert is a good indication that something's gone wrong before we run into this function. If you patch fixes an issue, could you give some detail about it? Maybe a gdb backtrace? Thanks, - Lionel On 05/07/18 19:27, Dongwon Kim wrote: 'ISL_FORMAT_UNSUPPORTED' shouldn't be passed down for evaluation as it is strictly prohibited in isl code (e.g. format_info_exists). Signed-off-by: Dongwon Kim --- src/mesa/drivers/dri/i965/intel_screen.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/i965/intel_screen.c b/src/mesa/drivers/dri/i965/intel_screen.c index cb357419a7..a65042da72 100644 --- a/src/mesa/drivers/dri/i965/intel_screen.c +++ b/src/mesa/drivers/dri/i965/intel_screen.c @@ -346,8 +346,16 @@ modifier_is_supported(const struct gen_device_info *devinfo, */ format = _mesa_format_fallback_rgbx_to_rgba(format); format = _mesa_get_srgb_format_linear(format); - if (!isl_format_supports_ccs_e(devinfo, - brw_isl_format_for_mesa_format(format))) + + enum isl_format isl_format; + isl_format = brw_isl_format_for_mesa_format(format); + + /* whether there is supported ISL format for given mesa format */ + if (isl_format == ISL_FORMAT_UNSUPPORTED) + return false; + + /* check if isl_fomat supports ccs_e */ + if (!isl_format_supports_ccs_e(devinfo, isl_format)) return false; } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/13] Fix stencil texturing and BO caching bugs
On Tue, Jun 12, 2018 at 12:21:52PM -0700, Nanley Chery wrote: > This series fixes a couple stencil texturing bugs on HSW and > cache-tracking for certain stencil BOs on all platforms. > > Nanley Chery (13): > i965: Set the r8stencil flag in miptree_finish_write > i965/miptree: Set the r8stencil flag in map_depthstencil > i965/draw: Set the r8stencil flag after drawing > i965/draw: Fix adding the stencil bo to the depth cache > i965/miptree: Use make_surface in map_blit > i965/miptree: Delete MIPTREE_CREATE_LINEAR > i965/miptree: Share tiling_flags in miptree_create > i965/miptree: Share the miptree format in miptree_create > i965/miptree: Share alloc_flags in miptree_create I'm not sure if this maintains the BO_ALLOC_BUSY. > i965/miptree: Add and use mt_surf_usage > i965/miptree: Refactor miptree_create > i965/miptree: Create the r8stencil_mt immediately > i965/miptree: Inline make_separate_stencil Same here. Otherwise the series is: Reviewed-by: Topi Pohjolainen > > src/mesa/drivers/dri/i965/brw_blorp.c | 6 +- > src/mesa/drivers/dri/i965/brw_clear.c | 8 - > src/mesa/drivers/dri/i965/brw_draw.c | 14 +- > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 211 -- > src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 5 +- > src/mesa/drivers/dri/i965/intel_tex_image.c | 3 - > 6 files changed, 103 insertions(+), 144 deletions(-) > > -- > 2.17.0 > > ___ > 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 13/13] i965/miptree: Inline make_separate_stencil
On Tue, Jun 12, 2018 at 12:22:05PM -0700, Nanley Chery wrote:
> Note that the separate stencil miptree now has the same alloc_flag as
> the depth component.
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 29 ---
> 1 file changed, 6 insertions(+), 23 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 6311b2257db..d9251967876 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -664,28 +664,6 @@ fail:
> return NULL;
> }
>
> -static bool
> -make_separate_stencil_surface(struct brw_context *brw,
> - struct intel_mipmap_tree *mt)
> -{
> - mt->stencil_mt = make_surface(brw, mt->target, MESA_FORMAT_S_UINT8,
> - 0, mt->surf.levels - 1,
> - mt->surf.logical_level0_px.width,
> - mt->surf.logical_level0_px.height,
> - mt->surf.dim == ISL_SURF_DIM_3D ?
> -mt->surf.logical_level0_px.depth :
> -mt->surf.logical_level0_px.array_len,
> - mt->surf.samples, ISL_TILING_W_BIT,
> - ISL_SURF_USAGE_STENCIL_BIT |
> - ISL_SURF_USAGE_TEXTURE_BIT,
> - BO_ALLOC_BUSY, 0, NULL);
> -
> - if (!mt->stencil_mt)
> - return false;
> -
> - return true;
> -}
> -
> /* Return the usual surface usage flags for the given format. */
> static isl_surf_usage_flags_t
> mt_surf_usage(mesa_format format)
> @@ -745,7 +723,12 @@ miptree_create(struct brw_context *brw,
>return NULL;
>
> if (needs_separate_stencil(brw, mt, format)) {
> - if (!make_separate_stencil_surface(brw, mt)) {
> + mt->stencil_mt =
> + make_surface(brw, target, MESA_FORMAT_S_UINT8, first_level,
> last_level,
> + width0, height0, depth0, num_samples,
> + ISL_TILING_W_BIT, mt_surf_usage(MESA_FORMAT_S_UINT8),
> + alloc_flags, 0, NULL);
Should we use BO_ALLOC_BUSY instead of alloc_flags?
> + if (mt->stencil_mt == NULL) {
> intel_miptree_release();
> return NULL;
>}
> --
> 2.17.0
>
> ___
> 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 10/13] i965/miptree: Add and use mt_surf_usage
On Fri, Jul 06, 2018 at 03:17:14PM +0300, Pohjolainen, Topi wrote:
> On Tue, Jun 12, 2018 at 12:22:02PM -0700, Nanley Chery wrote:
> > ---
> > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 40 ---
> > 1 file changed, 26 insertions(+), 14 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > index cfb83d15ecc..5e00da86d32 100644
> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > @@ -677,6 +677,23 @@ make_separate_stencil_surface(struct brw_context *brw,
> > return true;
> > }
> >
> > +/* Return the usual surface usage flags for the given format. */
> > +static isl_surf_usage_flags_t
> > +mt_surf_usage(mesa_format format)
> > +{
> > + switch(_mesa_get_format_base_format(format)) {
> > + case GL_DEPTH_COMPONENT:
> > + return ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT;
> > + case GL_DEPTH_STENCIL:
> > + return ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_STENCIL_BIT |
> > + ISL_SURF_USAGE_TEXTURE_BIT;
> > + case GL_STENCIL_INDEX:
> > + return ISL_SURF_USAGE_STENCIL_BIT | ISL_SURF_USAGE_TEXTURE_BIT;
> > + default:
> > + return ISL_SURF_USAGE_RENDER_TARGET_BIT | ISL_SURF_USAGE_TEXTURE_BIT;
> > + }
> > +}
> > +
> > static struct intel_mipmap_tree *
> > miptree_create(struct brw_context *brw,
> > GLenum target,
> > @@ -713,8 +730,7 @@ miptree_create(struct brw_context *brw,
> >return make_surface(brw, target, mt_fmt, first_level, last_level,
> >width0, height0, depth0, num_samples,
> >tiling_flags,
> > - ISL_SURF_USAGE_STENCIL_BIT |
> > - ISL_SURF_USAGE_TEXTURE_BIT,
> > + mt_surf_usage(mt_fmt),
> >alloc_flags,
> >0,
> >NULL);
> > @@ -726,7 +742,7 @@ miptree_create(struct brw_context *brw,
> > brw, target, mt_fmt,
> > first_level, last_level,
> > width0, height0, depth0, num_samples, tiling_flags,
> > - ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT,
> > + mt_surf_usage(mt_fmt),
> > alloc_flags, 0, NULL);
> >
> >if (needs_separate_stencil(brw, mt, format) &&
> > @@ -746,8 +762,7 @@ miptree_create(struct brw_context *brw,
> > first_level, last_level,
> > width0, height0, depth0,
> > num_samples, tiling_flags,
> > - ISL_SURF_USAGE_RENDER_TARGET_BIT |
> > - ISL_SURF_USAGE_TEXTURE_BIT,
> > + mt_surf_usage(mt_fmt),
> > alloc_flags, 0, NULL);
> > if (!mt)
> >return NULL;
> > @@ -816,12 +831,11 @@ intel_miptree_create_for_bo(struct brw_context *brw,
> >
> > if ((base_format == GL_DEPTH_COMPONENT ||
> > base_format == GL_DEPTH_STENCIL)) {
> > - const mesa_format depth_only_format =
> > - intel_depth_format_for_depthstencil_format(format);
> > - mt = make_surface(brw, target,
> > -devinfo->gen >= 6 ? depth_only_format : format,
> > + mesa_format mt_fmt = (devinfo->gen < 6) ? format :
> > +
> > intel_depth_format_for_depthstencil_format(format);
>
> This introduction of helper variable isn't really related. But if you decide
> to keep it, you could make it const.
And I keep on mis-reading, it is really needed, sorry for the noise.
>
> > + mt = make_surface(brw, target, mt_fmt,
> > 0, 0, width, height, depth, 1, ISL_TILING_Y0_BIT,
> > -ISL_SURF_USAGE_DEPTH_BIT |
> > ISL_SURF_USAGE_TEXTURE_BIT,
> > +mt_surf_usage(mt_fmt),
> > 0, pitch, bo);
> >if (!mt)
> > return NULL;
> > @@ -836,8 +850,7 @@ intel_miptree_create_for_bo(struct brw_context *brw,
> >mt = make_surface(brw, target, MESA_FORMAT_S_UINT8,
> > 0, 0, width, height, depth, 1,
> > ISL_TILING_W_BIT,
> > -ISL_SURF_USAGE_STENCIL_BIT |
> > -ISL_SURF_USAGE_TEXTURE_BIT,
> > +mt_surf_usage(MESA_FORMAT_S_UINT8),
> > 0, pitch, bo);
> >if (!mt)
> > return NULL;
> > @@ -862,8 +875,7 @@ intel_miptree_create_for_bo(struct brw_context *brw,
> > mt = make_surface(brw, target, format,
> > 0, 0, width, height, depth, 1,
> > 1lu << tiling,
> > - ISL_SURF_USAGE_RENDER_TARGET_BIT |
> > - ISL_SURF_USAGE_TEXTURE_BIT,
> > +
Re: [Mesa-dev] [PATCH 10/13] i965/miptree: Add and use mt_surf_usage
On Tue, Jun 12, 2018 at 12:22:02PM -0700, Nanley Chery wrote:
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 40 ---
> 1 file changed, 26 insertions(+), 14 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index cfb83d15ecc..5e00da86d32 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -677,6 +677,23 @@ make_separate_stencil_surface(struct brw_context *brw,
> return true;
> }
>
> +/* Return the usual surface usage flags for the given format. */
> +static isl_surf_usage_flags_t
> +mt_surf_usage(mesa_format format)
> +{
> + switch(_mesa_get_format_base_format(format)) {
> + case GL_DEPTH_COMPONENT:
> + return ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT;
> + case GL_DEPTH_STENCIL:
> + return ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_STENCIL_BIT |
> + ISL_SURF_USAGE_TEXTURE_BIT;
> + case GL_STENCIL_INDEX:
> + return ISL_SURF_USAGE_STENCIL_BIT | ISL_SURF_USAGE_TEXTURE_BIT;
> + default:
> + return ISL_SURF_USAGE_RENDER_TARGET_BIT | ISL_SURF_USAGE_TEXTURE_BIT;
> + }
> +}
> +
> static struct intel_mipmap_tree *
> miptree_create(struct brw_context *brw,
> GLenum target,
> @@ -713,8 +730,7 @@ miptree_create(struct brw_context *brw,
>return make_surface(brw, target, mt_fmt, first_level, last_level,
>width0, height0, depth0, num_samples,
>tiling_flags,
> - ISL_SURF_USAGE_STENCIL_BIT |
> - ISL_SURF_USAGE_TEXTURE_BIT,
> + mt_surf_usage(mt_fmt),
>alloc_flags,
>0,
>NULL);
> @@ -726,7 +742,7 @@ miptree_create(struct brw_context *brw,
> brw, target, mt_fmt,
> first_level, last_level,
> width0, height0, depth0, num_samples, tiling_flags,
> - ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT,
> + mt_surf_usage(mt_fmt),
> alloc_flags, 0, NULL);
>
>if (needs_separate_stencil(brw, mt, format) &&
> @@ -746,8 +762,7 @@ miptree_create(struct brw_context *brw,
> first_level, last_level,
> width0, height0, depth0,
> num_samples, tiling_flags,
> - ISL_SURF_USAGE_RENDER_TARGET_BIT |
> - ISL_SURF_USAGE_TEXTURE_BIT,
> + mt_surf_usage(mt_fmt),
> alloc_flags, 0, NULL);
> if (!mt)
>return NULL;
> @@ -816,12 +831,11 @@ intel_miptree_create_for_bo(struct brw_context *brw,
>
> if ((base_format == GL_DEPTH_COMPONENT ||
> base_format == GL_DEPTH_STENCIL)) {
> - const mesa_format depth_only_format =
> - intel_depth_format_for_depthstencil_format(format);
> - mt = make_surface(brw, target,
> -devinfo->gen >= 6 ? depth_only_format : format,
> + mesa_format mt_fmt = (devinfo->gen < 6) ? format :
> +
> intel_depth_format_for_depthstencil_format(format);
This introduction of helper variable isn't really related. But if you decide
to keep it, you could make it const.
> + mt = make_surface(brw, target, mt_fmt,
> 0, 0, width, height, depth, 1, ISL_TILING_Y0_BIT,
> -ISL_SURF_USAGE_DEPTH_BIT |
> ISL_SURF_USAGE_TEXTURE_BIT,
> +mt_surf_usage(mt_fmt),
> 0, pitch, bo);
>if (!mt)
> return NULL;
> @@ -836,8 +850,7 @@ intel_miptree_create_for_bo(struct brw_context *brw,
>mt = make_surface(brw, target, MESA_FORMAT_S_UINT8,
> 0, 0, width, height, depth, 1,
> ISL_TILING_W_BIT,
> -ISL_SURF_USAGE_STENCIL_BIT |
> -ISL_SURF_USAGE_TEXTURE_BIT,
> +mt_surf_usage(MESA_FORMAT_S_UINT8),
> 0, pitch, bo);
>if (!mt)
> return NULL;
> @@ -862,8 +875,7 @@ intel_miptree_create_for_bo(struct brw_context *brw,
> mt = make_surface(brw, target, format,
> 0, 0, width, height, depth, 1,
> 1lu << tiling,
> - ISL_SURF_USAGE_RENDER_TARGET_BIT |
> - ISL_SURF_USAGE_TEXTURE_BIT,
> + mt_surf_usage(format),
> 0, pitch, bo);
> if (!mt)
>return NULL;
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/13] i965/miptree: Share alloc_flags in miptree_create
On Tue, Jun 12, 2018 at 12:22:01PM -0700, Nanley Chery wrote:
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 97de30076e0..cfb83d15ecc 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -690,6 +690,8 @@ miptree_create(struct brw_context *brw,
> enum intel_miptree_create_flags flags)
> {
> const struct gen_device_info *devinfo = >screen->devinfo;
> + const uint32_t alloc_flags = (flags & MIPTREE_CREATE_BUSY) ?
> +BO_ALLOC_BUSY : 0;
> isl_tiling_flags_t tiling_flags = ISL_TILING_ANY_MASK;
>
> /* TODO: This used to be because there wasn't BLORP to handle Y-tiling. */
> @@ -713,7 +715,7 @@ miptree_create(struct brw_context *brw,
>tiling_flags,
>ISL_SURF_USAGE_STENCIL_BIT |
>ISL_SURF_USAGE_TEXTURE_BIT,
> - BO_ALLOC_BUSY,
> + alloc_flags,
Only intel_finalize_mipmap_tree(), intel_renderbuffer_move_to_temp() and
intel_miptree_create_for_renderbuffer() use MIPTREE_CREATE_BUSY. Can we end
up here for somewhere else?
>0,
>NULL);
>
> @@ -725,7 +727,7 @@ miptree_create(struct brw_context *brw,
> first_level, last_level,
> width0, height0, depth0, num_samples, tiling_flags,
> ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT,
> - BO_ALLOC_BUSY, 0, NULL);
> + alloc_flags, 0, NULL);
Same question here?
>
>if (needs_separate_stencil(brw, mt, format) &&
>!make_separate_stencil_surface(brw, mt)) {
> @@ -739,11 +741,6 @@ miptree_create(struct brw_context *brw,
>return mt;
> }
>
> - uint32_t alloc_flags = 0;
> -
> - if (flags & MIPTREE_CREATE_BUSY)
> - alloc_flags |= BO_ALLOC_BUSY;
> -
> struct intel_mipmap_tree *mt = make_surface(
> brw, target, mt_fmt,
> first_level, last_level,
> --
> 2.17.0
>
> ___
> 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] meson: Build with Python 3
AFAICS, we use python 2 in two places: (1) SCons* I suspect using Python 3 will be far from straightforward, as it will require newer SCons versions, and all that's implied. So I rather not embark on this yet. (2) C code generation scripts Python 3.5 seems to be included on our build environment for all supported OSes. So I think it should be possible to start using Python 3 for the scripts. We just need to ensure the Scons* files use python 3 interpreter. That said, it's better if we can keep using Python 2 and 3 at the same time, for a transitory period, so we have time to iron out any wrinkles transitioning, which is not possible if we do a "all or nothing" approach. Jose On 05/07/18 16:51, Dylan Baker wrote: Dave, Brian, and Jose, IIRC when we discussed migrating piglit to python 3 (and went with a hybrid approach instead), y'all had requirements to run on python 2, and couldn't support python 3. Is that still the case, or would moving to python 3 be acceptable? Quoting Mathieu Bridon (2018-07-05 06:17:31) This patch series allows building Mesa with Python 3. The build scripts are kept compatible with Python 2 as well, for those platforms which don't have Python 3 yet. In fact, only the Meson build system is moved to Python 3, since it is the only one I'm 100% sure has Python 3 available. (Meson itself requires it) I briefly thought about adding an option to the Meson build system to control which version of Python to build with, but decided against. I'm happy to add it if you think it's necessary. I checked (with the `diff` command) that all the scripts output the exact same things when built with Meson on: * master (as of f9b6dfd919 which includes my patches to make the build output reproducible) * the second to last patch in this series (that is, all the scripts changed but still building with Python 2) * the last patch in this series (that is, with Python 3) Each patch fixes a single type of problem in multiple scripts/subsystems. As a result, it should be possible to review and merge each patch independently (but probably not in order), without breaking the build. It's a lot of changes: 86 files changed, 1965 insertions(+), 1833 deletions(-) The end goal is to be able to eventually remove Python 2 from future versions of the Flatpak Freedesktop SDK, Mesa being one of the last few things still requiring it. For those who prefer reviewing a git repo, I have pushed the changes to a fork on the FDO Gitlab: * a branch compatible with both Python 2 and 3, but still building with Python 2: https://gitlab.freedesktop.org/bochecha/mesa/tree/python-2-and-3 * a branch building with Python 3: https://gitlab.freedesktop.org/bochecha/mesa/tree/python3 ___ 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 09/26] python: Use range() instead of xrange()
Python 2 has a range() function which returns a list, and an xrange()
one which returns an iterator.
Python 3 lost the function returning a list, and renamed the function
returning an iterator as range().
As a result, using range() makes the scripts compatible with both Python
versions 2 and 3.
Signed-off-by: Mathieu Bridon
---
src/amd/vulkan/radv_entrypoints_gen.py | 2 +-
src/broadcom/cle/gen_pack_header.py | 2 +-
src/compiler/glsl/ir_expression_operation.py | 2 +-
src/compiler/nir/nir_opcodes.py | 4 ++--
src/intel/vulkan/anv_entrypoints_gen.py | 2 +-
src/mapi/glapi/gen/glX_proto_send.py | 2 +-
src/mapi/glapi/gen/gl_gentable.py| 4 ++--
src/mapi/mapi_abi.py | 2 +-
src/mesa/main/format_parser.py | 4 ++--
9 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/amd/vulkan/radv_entrypoints_gen.py
b/src/amd/vulkan/radv_entrypoints_gen.py
index 9c4dfd02a0..ca022bcbb0 100644
--- a/src/amd/vulkan/radv_entrypoints_gen.py
+++ b/src/amd/vulkan/radv_entrypoints_gen.py
@@ -136,7 +136,7 @@ static const struct string_map_entry string_map_entries[] =
{
/* Hash table stats:
* size ${len(strmap.sorted_strings)} entries
* collisions entries:
-% for i in xrange(10):
+% for i in range(10):
* ${i}${'+' if i == 9 else ' '} ${strmap.collisions[i]}
% endfor
*/
diff --git a/src/broadcom/cle/gen_pack_header.py
b/src/broadcom/cle/gen_pack_header.py
index c6e1c564e6..8ad54464cb 100644
--- a/src/broadcom/cle/gen_pack_header.py
+++ b/src/broadcom/cle/gen_pack_header.py
@@ -216,7 +216,7 @@ class Group(object):
first_byte = field.start // 8
last_byte = field.end // 8
-for b in xrange(first_byte, last_byte + 1):
+for b in range(first_byte, last_byte + 1):
if not b in bytes:
bytes[b] = self.Byte()
diff --git a/src/compiler/glsl/ir_expression_operation.py
b/src/compiler/glsl/ir_expression_operation.py
index b3dac3da3f..16b98690a6 100644
--- a/src/compiler/glsl/ir_expression_operation.py
+++ b/src/compiler/glsl/ir_expression_operation.py
@@ -116,7 +116,7 @@ constant_template_common = mako.template.Template("""\
constant_template_vector_scalar = mako.template.Template("""\
case ${op.get_enum_name()}:
% if "mixed" in op.flags:
-% for i in xrange(op.num_operands):
+% for i in range(op.num_operands):
assert(op[${i}]->type->base_type == ${op.source_types[0].glsl_type} ||
% for src_type in op.source_types[1:-1]:
op[${i}]->type->base_type == ${src_type.glsl_type} ||
diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index 3c3316dcaa..b03c5da2ea 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -367,8 +367,8 @@ for (unsigned bit = 0; bit < bit_size; bit++) {
""")
-for i in xrange(1, 5):
- for j in xrange(1, 5):
+for i in range(1, 5):
+ for j in range(1, 5):
unop_horiz("fnoise{0}_{1}".format(i, j), i, tfloat, j, tfloat, "0.0f")
diff --git a/src/intel/vulkan/anv_entrypoints_gen.py
b/src/intel/vulkan/anv_entrypoints_gen.py
index 8a37336496..5e2cd0740a 100644
--- a/src/intel/vulkan/anv_entrypoints_gen.py
+++ b/src/intel/vulkan/anv_entrypoints_gen.py
@@ -145,7 +145,7 @@ static const struct string_map_entry string_map_entries[] =
{
/* Hash table stats:
* size ${len(strmap.sorted_strings)} entries
* collisions entries:
-% for i in xrange(10):
+% for i in range(10):
* ${i}${'+' if i == 9 else ' '} ${strmap.collisions[i]}
% endfor
*/
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index fba2f0cc1e..a920ecc012 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -392,7 +392,7 @@ static const struct proc_pair
_glapi_proc proc;
} proc_pairs[%d] = {""" % len(procs))
names = sorted(procs.keys())
-for i in xrange(len(names)):
+for i in range(len(names)):
comma = ',' if i < len(names) - 1 else ''
print(' { "%s", (_glapi_proc) gl%s }%s' % (names[i],
procs[names[i]], comma))
print("""};
diff --git a/src/mapi/glapi/gen/gl_gentable.py
b/src/mapi/glapi/gen/gl_gentable.py
index 49206b1167..9d8923cf8d 100644
--- a/src/mapi/glapi/gen/gl_gentable.py
+++ b/src/mapi/glapi/gen/gl_gentable.py
@@ -216,13 +216,13 @@ class PrintCode(gl_XML.gl_print_base):
# Check that the table has no gaps. We expect a function at every
offset,
# and the code which generates the table relies on this.
-for i in xrange(0, func_count):
+for i in range(0, func_count):
if funcnames[i] is None:
raise Exception("Function table has no function at offset %d"
% (i))
print("#define GLAPI_TABLE_COUNT %d" % func_count)
print("static const char * const
[Mesa-dev] [PATCH 06/26] python: Better iterate over dictionaries
In Python 2, dictionaries have 2 sets of methods to iterate over their
keys and values: keys()/values()/items() and
iterkeys()/itervalues()/iteritems().
The former return lists while the latter return iterators.
Python 3 dropped the method which return lists, and renamed the methods
returning iterators to keys()/values()/items().
Using those names makes the scripts compatible with both Python 2 and 3.
Signed-off-by: Mathieu Bridon
---
src/amd/vulkan/radv_entrypoints_gen.py | 2 +-
src/compiler/nir/nir_algebraic.py| 2 +-
src/compiler/nir/nir_builder_opcodes_h.py| 4 ++--
src/compiler/nir/nir_constant_expressions.py | 4 ++--
src/compiler/nir/nir_intrinsics_c.py | 2 +-
src/compiler/nir/nir_opcodes_c.py| 2 +-
src/compiler/nir/nir_opcodes_h.py| 2 +-
src/intel/genxml/gen_bits_header.py | 10 +-
src/intel/vulkan/anv_entrypoints_gen.py | 2 +-
src/mapi/glapi/gen/gl_XML.py | 14 +++---
src/mapi/glapi/gen/gl_gentable.py| 4 ++--
src/mesa/drivers/dri/i965/brw_oa.py | 4 ++--
12 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/src/amd/vulkan/radv_entrypoints_gen.py
b/src/amd/vulkan/radv_entrypoints_gen.py
index bef0c447f6..9c4dfd02a0 100644
--- a/src/amd/vulkan/radv_entrypoints_gen.py
+++ b/src/amd/vulkan/radv_entrypoints_gen.py
@@ -433,7 +433,7 @@ def get_entrypoints(doc, entrypoints_to_defines,
start_index):
e_clone.name = e.name
entrypoints[e.name] = e_clone
-return [e for e in entrypoints.itervalues() if e.enabled]
+return [e for e in entrypoints.values() if e.enabled]
def get_entrypoints_defines(doc):
diff --git a/src/compiler/nir/nir_algebraic.py
b/src/compiler/nir/nir_algebraic.py
index 847c59dbd8..8c0b530f69 100644
--- a/src/compiler/nir/nir_algebraic.py
+++ b/src/compiler/nir/nir_algebraic.py
@@ -512,7 +512,7 @@ struct transform {
#endif
-% for (opcode, xform_list) in xform_dict.iteritems():
+% for (opcode, xform_list) in xform_dict.items():
% for xform in xform_list:
${xform.search.render()}
${xform.replace.render()}
diff --git a/src/compiler/nir/nir_builder_opcodes_h.py
b/src/compiler/nir/nir_builder_opcodes_h.py
index 72cf5b4549..e600093e9f 100644
--- a/src/compiler/nir/nir_builder_opcodes_h.py
+++ b/src/compiler/nir/nir_builder_opcodes_h.py
@@ -34,7 +34,7 @@ def src_list(num_srcs):
return ', '.join('src' + str(i) if i < num_srcs else 'NULL' for i in
range(4))
%>
-% for name, opcode in sorted(opcodes.iteritems()):
+% for name, opcode in sorted(opcodes.items()):
static inline nir_ssa_def *
nir_${name}(nir_builder *build, ${src_decl_list(opcode.num_inputs)})
{
@@ -55,7 +55,7 @@ nir_load_system_value(nir_builder *build, nir_intrinsic_op
op, int index)
return >dest.ssa;
}
-% for name, opcode in filter(lambda v: v[1].sysval,
sorted(INTR_OPCODES.iteritems())):
+% for name, opcode in filter(lambda v: v[1].sysval,
sorted(INTR_OPCODES.items())):
static inline nir_ssa_def *
nir_${name}(nir_builder *build)
{
diff --git a/src/compiler/nir/nir_constant_expressions.py
b/src/compiler/nir/nir_constant_expressions.py
index 35dffe70ce..118af9f781 100644
--- a/src/compiler/nir/nir_constant_expressions.py
+++ b/src/compiler/nir/nir_constant_expressions.py
@@ -387,7 +387,7 @@ struct bool32_vec {
% endif
-% for name, op in sorted(opcodes.iteritems()):
+% for name, op in sorted(opcodes.items()):
static nir_const_value
evaluate_${name}(MAYBE_UNUSED unsigned num_components,
${"UNUSED" if op_bit_sizes(op) is None else ""} unsigned
bit_size,
@@ -420,7 +420,7 @@ nir_eval_const_opcode(nir_op op, unsigned num_components,
unsigned bit_width, nir_const_value *src)
{
switch (op) {
-% for name in sorted(opcodes.iterkeys()):
+% for name in sorted(opcodes.keys()):
case nir_op_${name}:
return evaluate_${name}(num_components, bit_width, src);
% endfor
diff --git a/src/compiler/nir/nir_intrinsics_c.py
b/src/compiler/nir/nir_intrinsics_c.py
index 9604fcdf62..98af67c38a 100644
--- a/src/compiler/nir/nir_intrinsics_c.py
+++ b/src/compiler/nir/nir_intrinsics_c.py
@@ -25,7 +25,7 @@ template = """\
#include "nir.h"
const nir_intrinsic_info nir_intrinsic_infos[nir_num_intrinsics] = {
-% for name, opcode in sorted(INTR_OPCODES.iteritems()):
+% for name, opcode in sorted(INTR_OPCODES.items()):
{
.name = "${name}",
.num_srcs = ${opcode.num_srcs},
diff --git a/src/compiler/nir/nir_opcodes_c.py
b/src/compiler/nir/nir_opcodes_c.py
index 108e144b5f..4603cd3d74 100644
--- a/src/compiler/nir/nir_opcodes_c.py
+++ b/src/compiler/nir/nir_opcodes_c.py
@@ -116,7 +116,7 @@ nir_type_conversion_op(nir_alu_type src, nir_alu_type dst,
nir_rounding_mode rnd
}
const nir_op_info nir_op_infos[nir_num_opcodes] = {
-% for name, opcode in sorted(opcodes.iteritems()):
+% for name, opcode in sorted(opcodes.items()):
{
.name = "${name}",
[Mesa-dev] [PATCH 07/26] python: Better sort dictionary keys/values
In Python 2, dict.keys() and dict.values() both return a list, which can
be sorted in two ways:
* l.sort() modifies the list in-place;
* sorted(l) returns a new, sorted list;
In Python 3, dict.keys() and dict.values() do not return lists any more,
but iterators. Iterators do not have a .sort() method.
This commit moves the build scripts to using sorted() on dict keys and
values, which makes them compatible with both Python 2 and Python 3.
Signed-off-by: Mathieu Bridon
---
src/mapi/glapi/gen/glX_proto_send.py | 3 +--
src/mapi/glapi/gen/glX_proto_size.py | 6 ++
src/mapi/glapi/gen/gl_XML.py | 12
src/mapi/glapi/gen/gl_procs.py | 3 +--
src/mapi/mapi_abi.py | 6 ++
5 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index c389872044..fba2f0cc1e 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -391,8 +391,7 @@ static const struct proc_pair
const char *name;
_glapi_proc proc;
} proc_pairs[%d] = {""" % len(procs))
-names = procs.keys()
-names.sort()
+names = sorted(procs.keys())
for i in xrange(len(names)):
comma = ',' if i < len(names) - 1 else ''
print(' { "%s", (_glapi_proc) gl%s }%s' % (names[i],
procs[names[i]], comma))
diff --git a/src/mapi/glapi/gen/glX_proto_size.py
b/src/mapi/glapi/gen/glX_proto_size.py
index 18a6f2e502..2a843c3e24 100644
--- a/src/mapi/glapi/gen/glX_proto_size.py
+++ b/src/mapi/glapi/gen/glX_proto_size.py
@@ -208,8 +208,7 @@ class glx_enum_function(object):
for enum_obj in self.enums[e]:
list[ enum_obj.priority() ] = enum_obj.name
-keys = list.keys()
-keys.sort()
+keys = sorted(list.keys())
for k in keys:
j = list[k]
if first:
@@ -275,8 +274,7 @@ class glx_server_enum_function(glx_enum_function):
o = f.offset_of( param_name )
foo[o] = param_name
-keys = foo.keys()
-keys.sort()
+keys = sorted(foo.keys())
for o in keys:
p = f.parameters_by_name[ foo[o] ]
diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
index 20057cf9c4..7bd5a1f4e4 100644
--- a/src/mapi/glapi/gen/gl_XML.py
+++ b/src/mapi/glapi/gen/gl_XML.py
@@ -988,12 +988,10 @@ class gl_api(object):
functions = []
for func_cat_type in range(0,4):
-keys = lists[func_cat_type].keys()
-keys.sort()
+keys = sorted(lists[func_cat_type].keys())
for key in keys:
-names = lists[func_cat_type][key].keys()
-names.sort()
+names = sorted(lists[func_cat_type][key].keys())
for name in names:
functions.append(lists[func_cat_type][key][name])
@@ -1027,8 +1025,7 @@ class gl_api(object):
def enumIterateByName(self):
-keys = self.enums_by_name.keys()
-keys.sort()
+keys = sorted(self.enums_by_name.keys())
list = []
for enum in keys:
@@ -1047,8 +1044,7 @@ class gl_api(object):
list = []
for cat_type in range(0,4):
-keys = self.categories[cat_type].keys()
-keys.sort()
+keys = sorted(self.categories[cat_type].keys())
for key in keys:
list.append(self.categories[cat_type][key])
diff --git a/src/mapi/glapi/gen/gl_procs.py b/src/mapi/glapi/gen/gl_procs.py
index 5718f42ab6..4bd3321610 100644
--- a/src/mapi/glapi/gen/gl_procs.py
+++ b/src/mapi/glapi/gen/gl_procs.py
@@ -144,8 +144,7 @@ typedef struct {
print('')
print('/* OpenGL ES specific prototypes */')
print('')
-keys = categories.keys()
-keys.sort()
+keys = sorted(categories.keys())
for key in keys:
print('/* category %s */' % key)
print("\n".join(categories[key]))
diff --git a/src/mapi/mapi_abi.py b/src/mapi/mapi_abi.py
index e3f65547bf..826721479d 100644
--- a/src/mapi/mapi_abi.py
+++ b/src/mapi/mapi_abi.py
@@ -180,8 +180,7 @@ def abi_parse_xml(xml):
ent = ABIEntry(cols, attrs, func)
entry_dict[ent.name] = ent
-entries = entry_dict.values()
-entries.sort()
+entries = sorted(entry_dict.values())
return entries
@@ -250,8 +249,7 @@ def abi_parse(filename):
raise Exception('%s is duplicated' % (ent.name))
entry_dict[ent.name] = ent
-entries = entry_dict.values()
-entries.sort()
+entries = sorted(entry_dict.values())
return entries
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
[Mesa-dev] [PATCH 04/26] python: Better check for keys in dicts
Python 3 lost the dict.has_key() method. Instead it requires using the "in" operator. This is also compatible with Python 2. Signed-off-by: Mathieu Bridon --- src/mapi/glapi/gen/glX_XML.py| 2 +- src/mapi/glapi/gen/glX_proto_send.py | 2 +- src/mapi/glapi/gen/glX_proto_size.py | 18 +- src/mapi/glapi/gen/gl_XML.py | 6 +++--- src/mapi/glapi/gen/gl_procs.py | 2 +- src/mapi/mapi_abi.py | 4 ++-- src/util/xmlpool/gen_xmlpool.py | 4 ++-- 7 files changed, 19 insertions(+), 19 deletions(-) diff --git a/src/mapi/glapi/gen/glX_XML.py b/src/mapi/glapi/gen/glX_XML.py index d09370a508..e10c8b0a09 100644 --- a/src/mapi/glapi/gen/glX_XML.py +++ b/src/mapi/glapi/gen/glX_XML.py @@ -64,7 +64,7 @@ class glx_enum(gl_XML.gl_enum): else: mode = 1 -if not self.functions.has_key(n): +if n not in self.functions: self.functions[ n ] = [c, mode] return diff --git a/src/mapi/glapi/gen/glX_proto_send.py b/src/mapi/glapi/gen/glX_proto_send.py index f199e9a0a1..7ab1eb4a70 100644 --- a/src/mapi/glapi/gen/glX_proto_send.py +++ b/src/mapi/glapi/gen/glX_proto_send.py @@ -842,7 +842,7 @@ generic_%u_byte( GLint rop, const void * ptr ) def printPixelFunction(self, f): -if self.pixel_stubs.has_key( f.name ): +if f.name in self.pixel_stubs: # Normally gl_function::get_parameter_string could be # used. However, this call needs to have the missing # dimensions (e.g., a fake height value for diff --git a/src/mapi/glapi/gen/glX_proto_size.py b/src/mapi/glapi/gen/glX_proto_size.py index 284ee70e61..18a6f2e502 100644 --- a/src/mapi/glapi/gen/glX_proto_size.py +++ b/src/mapi/glapi/gen/glX_proto_size.py @@ -71,7 +71,7 @@ class glx_enum_function(object): for enum_name in enum_dict: e = enum_dict[ enum_name ] -if e.functions.has_key( match_name ): +if match_name in e.functions: [count, mode] = e.functions[ match_name ] if mode_set and mode != self.mode: @@ -79,11 +79,11 @@ class glx_enum_function(object): self.mode = mode -if self.enums.has_key( e.value ): +if e.value in self.enums: if e.name not in self.enums[ e.value ]: self.enums[ e.value ].append( e ) else: -if not self.count.has_key( count ): +if count not in self.count: self.count[ count ] = [] self.enums[ e.value ] = [ e ] @@ -131,7 +131,7 @@ class glx_enum_function(object): for a in self.enums: count += 1 -if self.count.has_key(-1): +if -1 in self.count: return 0 # Determine if there is some mask M, such that M = (2^N) - 1, @@ -356,7 +356,7 @@ class PrintGlxSizeStubs_c(PrintGlxSizeStubs_common): if (ef.is_set() and self.emit_set) or (not ef.is_set() and self.emit_get): sig = ef.signature() -if enum_sigs.has_key( sig ): +if sig in enum_sigs: aliases.append( [func.name, enum_sigs[ sig ]] ) else: enum_sigs[ sig ] = func.name @@ -477,10 +477,10 @@ class PrintGlxReqSize_c(PrintGlxReqSize_common): sig = ef.signature() -if not enum_functions.has_key(func.name): +if func.name not in enum_functions: enum_functions[ func.name ] = sig -if not enum_sigs.has_key( sig ): +if sig not in enum_sigs: enum_sigs[ sig ] = ef @@ -496,7 +496,7 @@ class PrintGlxReqSize_c(PrintGlxReqSize_common): if func.server_handcode: continue if not func.has_variable_size_request(): continue -if enum_functions.has_key(func.name): +if func.name in enum_functions: sig = enum_functions[func.name] ef = enum_sigs[ sig ] @@ -621,7 +621,7 @@ class PrintGlxReqSize_c(PrintGlxReqSize_common): # already be emitted, don't emit this function. Instead, add # it to the list of function aliases. -if self.counter_sigs.has_key(sig): +if sig in self.counter_sigs: n = self.counter_sigs[sig]; alias = [f.name, n] else: diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py index bfeacf1386..bea6801db3 100644 --- a/src/mapi/glapi/gen/gl_XML.py +++ b/src/mapi/glapi/gen/gl_XML.py @@ -943,7 +943,7 @@ class gl_api(object): temp_name = child.get( "name" ) self.category_dict[ temp_name ] = [cat_name, cat_number] -if self.functions_by_name.has_key( func_name ): +if func_name in self.functions_by_name:
[Mesa-dev] [PATCH 03/26] python: Stop using the Python 2 exception syntax
We could have made this compatible with Python 3 by using:
except Exception as e:
But since none of this code actually uses the exception objects, let's
just drop them entirely.
Signed-off-by: Mathieu Bridon
---
src/mapi/glapi/gen/glX_XML.py | 2 +-
src/mapi/glapi/gen/gl_XML.py| 6 +++---
src/mapi/glapi/gen/gl_marshal.py| 2 +-
src/mapi/glapi/gen/gl_marshal_h.py | 2 +-
src/mesa/main/get_hash_generator.py | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/mapi/glapi/gen/glX_XML.py b/src/mapi/glapi/gen/glX_XML.py
index b6d305c879..d09370a508 100644
--- a/src/mapi/glapi/gen/glX_XML.py
+++ b/src/mapi/glapi/gen/glX_XML.py
@@ -470,7 +470,7 @@ class glx_function(gl_XML.gl_function):
def needs_reply(self):
try:
x = self._needs_reply
-except Exception, e:
+except Exception:
x = 0
if self.return_type != 'void':
x = 1
diff --git a/src/mapi/glapi/gen/gl_XML.py b/src/mapi/glapi/gen/gl_XML.py
index 3a191abe0d..bfeacf1386 100644
--- a/src/mapi/glapi/gen/gl_XML.py
+++ b/src/mapi/glapi/gen/gl_XML.py
@@ -284,7 +284,7 @@ def classify_category(name, number):
try:
core_version = float(name)
-except Exception,e:
+except Exception:
core_version = 0.0
if core_version > 0.0:
@@ -365,7 +365,7 @@ class gl_enum( gl_item ):
else:
try:
c = int(temp)
-except Exception,e:
+except Exception:
raise RuntimeError('Invalid count value "%s" for enum "%s" in
function "%s" when an integer was expected.' % (temp, self.name, n))
self.default_count = c
@@ -426,7 +426,7 @@ class gl_parameter(object):
count = int(c)
self.count = count
self.counter = None
-except Exception,e:
+except Exception:
count = 1
self.count = 0
self.counter = c
diff --git a/src/mapi/glapi/gen/gl_marshal.py b/src/mapi/glapi/gen/gl_marshal.py
index e9dd2c4f78..5b35357ac5 100644
--- a/src/mapi/glapi/gen/gl_marshal.py
+++ b/src/mapi/glapi/gen/gl_marshal.py
@@ -353,7 +353,7 @@ if __name__ == '__main__':
try:
(args, trail) = getopt.getopt(sys.argv[1:], 'm:f:')
-except Exception,e:
+except Exception:
show_usage()
for (arg,val) in args:
diff --git a/src/mapi/glapi/gen/gl_marshal_h.py
b/src/mapi/glapi/gen/gl_marshal_h.py
index 6490595a00..a7a9eda573 100644
--- a/src/mapi/glapi/gen/gl_marshal_h.py
+++ b/src/mapi/glapi/gen/gl_marshal_h.py
@@ -74,7 +74,7 @@ if __name__ == '__main__':
try:
(args, trail) = getopt.getopt(sys.argv[1:], 'm:f:')
-except Exception,e:
+except Exception:
show_usage()
for (arg,val) in args:
diff --git a/src/mesa/main/get_hash_generator.py
b/src/mesa/main/get_hash_generator.py
index 86c6771066..facdccd8a5 100644
--- a/src/mesa/main/get_hash_generator.py
+++ b/src/mesa/main/get_hash_generator.py
@@ -201,7 +201,7 @@ def show_usage():
if __name__ == '__main__':
try:
(opts, args) = getopt.getopt(sys.argv[1:], "f:")
- except Exception,e:
+ except Exception:
show_usage()
if len(args) != 0:
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/3] verify max vertex attrib stride
OpenGL 4.4 and OpenGL ES 3.1 both require the maximum vertex attrib stride to be at least 2048. If this isn't the case, we shouldn't expose these API versions. Unfortunately, the r600 driver only supports 2047. To avoid regressions in the supported GL version, the first patch modifies the returned value. I'm not sure if that last one is a good idea or not, as it's strictly speaking non-conformant. But applications won't expect GL errors generated when using strides of 2048 either, which is what currently happens. The initial motivation for this patch-series is to avoid exposing a too high spec version in virgl and then get dEQP failures when running on old hardware. The virgl specific bits are being sent separately, because they depend on some other not-yet-upstream things ATM. Thoughts? Erik Faye-Lund (3): r600: report incorrect max-vertex-attrib for GL 4.4 mesa: verify MaxVertexAttribStride for GL 4.4 mesa: verify MaxVertexAttribStride for GLES 3.1 src/gallium/drivers/r600/r600_pipe.c | 3 ++- src/mesa/main/version.c | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) -- 2.18.0.rc2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] mesa: verify MaxVertexAttribStride for GLES 3.1
The OpenGL 3.1 specification, table Table 20.41 ("Implementation
Dependent Values"), defines the minimum-maximum value for
MAX_VERTEX_ATTRIB_STRIDE to be 2048.
So we shouldn't enable OpenGL ES 3.1 on implementations where this
isn't the case. Let's add a check for this
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/version.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 0b0d5b79d6..58e68b4772 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -530,6 +530,7 @@ compute_version_es2(const struct gl_extensions *extensions,
const bool es31_compute_shader =
consts->MaxComputeWorkGroupInvocations >= 128;
const bool ver_3_1 = (ver_3_0 &&
+ consts->MaxVertexAttribStride >= 2048 &&
extensions->ARB_arrays_of_arrays &&
es31_compute_shader &&
extensions->ARB_draw_indirect &&
--
2.18.0.rc2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] r600: report incorrect max-vertex-attrib for GL 4.4
OpenGL 4.4 requires a max vertex attrib of 2048 or higher, but r600 only supports 2047. Technically, this makes it an GL4.3 GPU, but it's currently exposing GL4.4. To avoid regressing the GL version supported in the following patches, let's just lie and pretend like we support 2048. Any applications using 2048 are already broken anyway. Signed-off-by: Erik Faye-Lund --- src/gallium/drivers/r600/r600_pipe.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index bc5660d6d1..2518032145 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b/src/gallium/drivers/r600/r600_pipe.c @@ -470,7 +470,8 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) return family >= CHIP_CEDAR ? 4 : 1; case PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE: - return 2047; + /* Should be 2047, but 2048 is a requirement for GL 4.4 */ + return 2048; /* Texturing. */ case PIPE_CAP_MAX_TEXTURE_2D_LEVELS: -- 2.18.0.rc2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] mesa: verify MaxVertexAttribStride for GL 4.4
The OpenGL 4.4 specification, table Table 23.55 ("Implementation
Dependent Values"), defines the minimum-maximum value for
MAX_VERTEX_ATTRIB_STRIDE to be 2048.
So we shouldn't enable OpenGL 4.4 on implementations where this isn't
the case. Let's add a check for this.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/version.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 2ba4c0b57f..0b0d5b79d6 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -369,6 +369,7 @@ compute_version(const struct gl_extensions *extensions,
extensions->ARB_texture_view);
const bool ver_4_4 = (ver_4_3 &&
consts->GLSLVersion >= 440 &&
+ consts->MaxVertexAttribStride >= 2048 &&
extensions->ARB_buffer_storage &&
extensions->ARB_clear_texture &&
extensions->ARB_enhanced_layouts &&
--
2.18.0.rc2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel: tools: dump_gpu: fix ppgtt mapping
We were not properly writing page tables when the virtual address
range spans multiple subtrees of the tables.
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/intel_dump_gpu.c | 46
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/src/intel/tools/intel_dump_gpu.c b/src/intel/tools/intel_dump_gpu.c
index 8a7dd52e746..c909d63d88f 100644
--- a/src/intel/tools/intel_dump_gpu.c
+++ b/src/intel/tools/intel_dump_gpu.c
@@ -423,13 +423,7 @@ static void
map_ppgtt(uint64_t start, uint64_t size)
{
uint64_t l4_start = start & 0xff80;
- uint64_t l3_start = start & 0xc000;
- uint64_t l2_start = start & 0xffe0;
- uint64_t l1_start = start & 0xf000;
uint64_t l4_end = ((start + size - 1) | 0x007f) & 0x;
- uint64_t l3_end = ((start + size - 1) | 0x3fff) & 0x;
- uint64_t l2_end = ((start + size - 1) | 0x001f) & 0x;
- uint64_t l1_end = ((start + size - 1) | 0x0fff) & 0x;
#define L4_index(addr) (((addr) >> 39) & 0x1ff)
#define L3_index(addr) (((addr) >> 30) & 0x1ff)
@@ -442,28 +436,34 @@ map_ppgtt(uint64_t start, uint64_t size)
populate_ppgtt_table(, L4_index(l4_start), L4_index(l4_end), 4);
- for (uint64_t a = l4_start; a < l4_end; a += (1ULL << 39)) {
- uint64_t _start = max(a, l3_start);
- uint64_t _end = min(a + (1ULL << 39), l3_end);
+ for (uint64_t l4 = l4_start; l4 < l4_end; l4 += (1ULL << 39)) {
+ uint64_t l3_start = max(l4, start & 0xc000);
+ uint64_t l3_end = min(l4 + (1ULL << 39),
+((start + size - 1) | 0x3fff) &
0x);
+ uint64_t l3_start_idx = L3_index(l3_start);
+ uint64_t l3_end_idx = L3_index(l3_start) >= l3_start_idx ?
L3_index(l3_end) : 0x1ff;
- populate_ppgtt_table(L3_table(a), L3_index(_start),
- L3_index(_end), 3);
- }
+ populate_ppgtt_table(L3_table(l4), l3_start_idx, l3_end_idx, 3);
- for (uint64_t a = l3_start; a < l3_end; a += (1ULL << 30)) {
- uint64_t _start = max(a, l2_start);
- uint64_t _end = min(a + (1ULL << 30), l2_end);
+ for (uint64_t l3 = l3_start; l3 < l3_end; l3 += (1ULL << 30)) {
+ uint64_t l2_start = max(l3, start & 0xffe0);
+ uint64_t l2_end = min(l3 + (1ULL << 30),
+ ((start + size - 1) | 0x001f) &
0x);
+ uint64_t l2_start_idx = L2_index(l2_start);
+ uint64_t l2_end_idx = L2_index(l2_end) >= l2_start_idx ?
L2_index(l2_end) : 0x1ff;
- populate_ppgtt_table(L2_table(a), L2_index(_start),
- L2_index(_end), 2);
- }
+ populate_ppgtt_table(L2_table(l3), l2_start_idx, l2_end_idx, 2);
- for (uint64_t a = l2_start; a < l2_end; a += (1ULL << 21)) {
- uint64_t _start = max(a, l1_start);
- uint64_t _end = min(a + (1ULL << 21), l1_end);
+ for (uint64_t l2 = l2_start; l2 < l2_end; l2 += (1ULL << 21)) {
+uint64_t l1_start = max(l2, start & 0xf000);
+uint64_t l1_end = min(l2 + (1ULL << 21),
+ ((start + size - 1) | 0x0fff) &
0x);
+uint64_t l1_start_idx = L1_index(l1_start);
+uint64_t l1_end_idx = L1_index(l1_end) >= l1_start_idx ?
L1_index(l1_end) : 0x1ff;
- populate_ppgtt_table(L1_table(a), L1_index(_start),
- L1_index(_end), 1);
+populate_ppgtt_table(L1_table(l2), l1_start_idx, l1_end_idx, 1);
+ }
+ }
}
}
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] intel: tools: fix build on old systems
Older system might not have support for memfd_create at the kernel
level. There we won't be able to use aubinator.
We also initially tried to workaround some libc having the
memfd_create syscall number defined, but not the memfd_create()
function.
This change makes dealing with the 2 problems above simpler by
creating our own syscall wrapper regardless. Aubinator won't be
compiled if the syscall number isn't defined.
v2: Simplify dealing with memfd_create (Matt)
Print error message if memfd_create syscall number not found (Eric)
Signed-off-by: Lionel Landwerlin
---
configure.ac | 13 +++--
meson.build | 2 +-
src/intel/Makefile.tools.am | 6 +-
src/intel/tools/aubinator.c | 9 +++--
src/intel/tools/meson.build | 30 --
src/intel/vulkan/anv_allocator.c | 6 ++
6 files changed, 42 insertions(+), 24 deletions(-)
diff --git a/configure.ac b/configure.ac
index f135d057365..f2c1bd1cd8e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -875,7 +875,16 @@ AC_CHECK_HEADERS([endian.h])
AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
AC_CHECK_FUNC([timespec_get], [DEFINES="$DEFINES -DHAVE_TIMESPEC_GET"])
-AC_CHECK_FUNC([memfd_create], [DEFINES="$DEFINES -DHAVE_MEMFD_CREATE"])
+AC_CHECK_FUNC([memfd_create], [MEMFD_CREATE=yes], [MEMFD_CREATE=no])
+
+AC_COMPILE_IFELSE(
+[AC_LANG_PROGRAM([], [[
+#include
+int main() { return SYS_memfd_create; }
+]])],
+have_memfd_nr=yes; AC_MSG_RESULT(yes),
+AC_MSG_RESULT(no))
+AM_CONDITIONAL(HAVE_MEMFD_CREATE, test "x$have_memfd_nr" = xyes)
AC_MSG_CHECKING([whether strtod has locale support])
AC_LINK_IFELSE([AC_LANG_SOURCE([[
@@ -2900,7 +2909,7 @@ if test "x$enable_llvm" = xyes; then
fi
dnl The gallium-xlib GLX and gallium OSMesa targets directly embed the
-dnl swr/llvmpipe driver into the final binary. Adding LLVM_LIBS results
in
+dnl swr/llvmpipe driver into the final binary. Adding LLVM_LIBS results in
dnl the LLVM library propagated in the Libs.private of the respective .pc
dnl file which ensures complete dependency information when statically
dnl linking.
diff --git a/meson.build b/meson.build
index 7d12af3d510..73a004b77a1 100644
--- a/meson.build
+++ b/meson.build
@@ -960,7 +960,7 @@ elif cc.has_header_symbol('sys/mkdev.h', 'major')
pre_args += '-DMAJOR_IN_MKDEV'
endif
-foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h', 'endian.h']
+foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h', 'endian.h',
'sys/memfd.h']
if cc.compiles('#include <@0@>'.format(h), name : '@0@'.format(h))
pre_args += '-DHAVE_@0@'.format(h.to_upper().underscorify())
endif
diff --git a/src/intel/Makefile.tools.am b/src/intel/Makefile.tools.am
index b00cc8cc2cb..16cc1095f62 100644
--- a/src/intel/Makefile.tools.am
+++ b/src/intel/Makefile.tools.am
@@ -19,8 +19,12 @@
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
# IN THE SOFTWARE.
+if HAVE_MEMFD_CREATE
+noinst_PROGRAMS += \
+ tools/aubinator
+endif
+
noinst_PROGRAMS += \
- tools/aubinator \
tools/aubinator_error_decode
tools_aubinator_SOURCES = \
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 8989d558b66..a7b8697960a 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include "util/list.h"
#include "util/macros.h"
@@ -46,15 +47,11 @@
#include "common/gen_gem.h"
#include "intel_aub.h"
-#ifndef HAVE_MEMFD_CREATE
-#include
-
static inline int
-memfd_create(const char *name, unsigned int flags)
+local_memfd_create(const char *name, unsigned int flags)
{
return syscall(SYS_memfd_create, name, flags);
}
-#endif
/* Below is the only command missing from intel_aub.h in libdrm
* So, reuse intel_aub.h from libdrm and #define the
@@ -907,7 +904,7 @@ int main(int argc, char *argv[])
if (isatty(1) && pager)
setup_pager();
- mem_fd = memfd_create("phys memory", 0);
+ mem_fd = local_memfd_create("phys memory", 0);
list_inithead();
diff --git a/src/intel/tools/meson.build b/src/intel/tools/meson.build
index 705a353f26a..bf1db7c4542 100644
--- a/src/intel/tools/meson.build
+++ b/src/intel/tools/meson.build
@@ -18,16 +18,26 @@
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
-aubinator = executable(
- 'aubinator',
- files('aubinator.c', 'intel_aub.h'),
- dependencies : [dep_expat, dep_zlib, dep_dl, dep_thread, dep_m],
- include_directories : [inc_common, inc_intel],
- link_with : [libintel_common, libintel_compiler, libintel_dev, libmesa_util],
- c_args : [c_vis_args, no_override_init_args],
- build_by_default : with_tools.contains('intel'),
- install : with_tools.contains('intel'),
-)
+has_memfd_create = cc.compiles('''#include
+
[Mesa-dev] [PATCH] swrast: remove unneeded _glapi_check_multithread() call
From: Emil Velikov With commit c6c0f947142, back in 2006 Brian removed the _glapi_check_multithread() call from core mesa - _mesa_make_current. He moved it to a DRI loader (type of) decision - with equivalents in the monolithic OSMesa and libGL-Xlib. Some time afterwords, swrast (a DRI driver) was introduced as a copy paste of the latter two. Remove the call since the DRI loader handles that for us. Signed-off-by: Emil Velikov --- src/mesa/drivers/dri/swrast/swrast.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/mesa/drivers/dri/swrast/swrast.c b/src/mesa/drivers/dri/swrast/swrast.c index ae5874f5927..1f90a853941 100644 --- a/src/mesa/drivers/dri/swrast/swrast.c +++ b/src/mesa/drivers/dri/swrast/swrast.c @@ -882,8 +882,6 @@ dri_make_current(__DRIcontext * cPriv, return GL_TRUE; } - _glapi_check_multithread(); - swrast_check_and_update_window_size(mesaCtx, mesaDraw); if (mesaRead != mesaDraw) swrast_check_and_update_window_size(mesaCtx, mesaRead); -- 2.18.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/26] python: Explicitly use lists
On Thu, 2018-07-05 at 09:31 -0700, Dylan Baker wrote:
> Quoting Mathieu Bridon (2018-07-05 06:17:47)
> > On Python 2, the builtin functions filter() and zip() would return
> > lists.
> >
> > On Python 3, they return iterators.
> >
> > Since we want to use those objects in contexts where we need lists,
> > we
> > need to explicitly turn them into lists.
> >
> > This makes the code compatible with both Python 2 and Python 3.
> >
> > Signed-off-by: Mathieu Bridon
> > ---
> > src/compiler/nir/nir_opt_algebraic.py | 2 +-
> > src/mesa/main/get_hash_generator.py | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/compiler/nir/nir_opt_algebraic.py
> > b/src/compiler/nir/nir_opt_algebraic.py
> > index 5e07d662b0..7b2ba56990 100644
> > --- a/src/compiler/nir/nir_opt_algebraic.py
> > +++ b/src/compiler/nir/nir_opt_algebraic.py
> > @@ -633,7 +633,7 @@ optimizations = [
> >
> > invert = OrderedDict([('feq', 'fne'), ('fne', 'feq'), ('fge',
> > 'flt'), ('flt', 'fge')])
> >
> > -for left, right in list(itertools.combinations(invert.keys(), 2))
> > + zip(invert.keys(), invert.keys()):
> > +for left, right in list(itertools.combinations(invert.keys(), 2))
> > + list(zip(invert.keys(), invert.keys())):
>
> Isn't this just a really expenisve re-implementation of:
> itertools.combinations_with_replacement(invert.keys(), 2)
It seems to be, yes. (I was so focused on fixing the "can't concatenate
list with zip" error that I completely missed it)
However, since dict.keys() isn't guaranteed to always be in the same
order, it is theoretically possible that:
>>> zip(invert.keys(), invert.keys())
doesn't always return the same thing.
That is, the following could happen:
>>> d = {'A': …, 'B': …}
>>> zip(d.keys(), d.keys())
['AB', 'BA']
Which would make the whole line not equivalent to
`itertools.combinations_with_replacement()` any more.
In practice it probably doesn't happen though, but that means if the
intention behind the code was what you suspect, then by using
`itertools.combinations_with_replacement()` we'd be fixing an actual
bug, not just making the script compatible with Python 3. :)
--
Mathieu
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 3/5] platform/android: Enable kms_swrast fallback
Hi Rob, On 6 July 2018 at 09:58, Robert Foss wrote: >> >> You can trivially eliminate the goto statement here. >> > > As Tomasz noted this fallback is already implemented in egldriver.c, > so it can be removed entirely. > Right forgot about that one. Currently we have the fallback in egldriver.c and another one in the platforms themselves - wayland, x11... Gut suggests that we want to have only one, although we can do that as follow-up. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/26] python: Specify the template output encoding
On Thu, 2018-07-05 at 09:14 -0700, Dylan Baker wrote: > Does it make more sense to encode, or to use io.open and open the > file in text mode? I've gone back and forth on this myself several > times. Same here, both seem equally valid and I can't really make my mind up on which one to pick. The general recommendation with Python 3 is to use unicode strings everywhere, and only encode/decode at the boundaries. I guess the boundary is actually writing to the file, so opening it in text mode and handling unicode strings (not encode them ourselves) fits that a bit better? It seems like a very weak argument though in this specific case, since we're not really doing anything with the byte-string other than just writing it directly to the file. Do you want me to do a v2 with that change? -- Mathieu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] swrast: Fix eglMakeCurrent(dpy, NULL, NULL, ctx)
On 5 July 2018 at 20:35, Adam Jackson wrote:
> Fixes 14 piglits, mostly in egl_khr_create_context.
>
> Fixes: https://github.com/anholt/libepoxy/issues/177
> Signed-off-by: Adam Jackson
> ---
> src/mesa/drivers/dri/swrast/swrast.c | 34 +++-
> 1 file changed, 18 insertions(+), 16 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/swrast/swrast.c
> b/src/mesa/drivers/dri/swrast/swrast.c
> index ae5874f5927..7f08107c24f 100644
> --- a/src/mesa/drivers/dri/swrast/swrast.c
> +++ b/src/mesa/drivers/dri/swrast/swrast.c
> @@ -675,6 +675,9 @@ swrast_check_and_update_window_size( struct gl_context
> *ctx, struct gl_framebuff
> {
> GLsizei width, height;
>
> +if (!fb)
> +return;
> +
> get_window_size(fb, , );
> if (fb->Width != width || fb->Height != height) {
> _mesa_resize_framebuffer(ctx, fb, width, height);
> @@ -857,30 +860,29 @@ dri_make_current(__DRIcontext * cPriv,
> __DRIdrawable * driReadPriv)
> {
> struct gl_context *mesaCtx;
> -struct gl_framebuffer *mesaDraw;
> -struct gl_framebuffer *mesaRead;
> +struct gl_framebuffer *mesaDraw = NULL;
> +struct gl_framebuffer *mesaRead = NULL;
> TRACE;
>
> if (cPriv) {
> - struct dri_context *ctx = dri_context(cPriv);
> struct dri_drawable *draw;
> struct dri_drawable *read;
>
> - if (!driDrawPriv || !driReadPriv)
> - return GL_FALSE;
> +mesaCtx = _context(cPriv)->Base;
>
> - draw = dri_drawable(driDrawPriv);
> - read = dri_drawable(driReadPriv);
> - mesaCtx = >Base;
> - mesaDraw = >Base;
> - mesaRead = >Base;
> + if (driDrawPriv && driReadPriv) {
> + draw = dri_drawable(driDrawPriv);
> + read = dri_drawable(driReadPriv);
> + mesaDraw = >Base;
> + mesaRead = >Base;
>
> - /* check for same context and buffer */
> - if (mesaCtx == _mesa_get_current_context()
> - && mesaCtx->DrawBuffer == mesaDraw
> - && mesaCtx->ReadBuffer == mesaRead) {
> - return GL_TRUE;
> - }
> + /* check for same context and buffer */
> + if (mesaCtx == _mesa_get_current_context()
> + && mesaCtx->DrawBuffer == mesaDraw
> + && mesaCtx->ReadBuffer == mesaRead) {
> + return GL_TRUE;
> + }
> +}
>
Skimming through the egl_khr_create_context text, this relaxes some
parts which are meant to be an error.
For example
* If either of or is a valid surface and the other
is EGL_NO_SURFACE, an EGL_BAD_MATCH error is generated.
Something like the below should handle the case you're thinking of, right?
HTH
Emil
diff --git a/src/mesa/drivers/dri/swrast/swrast.c
b/src/mesa/drivers/dri/swrast/swrast.c
index ae5874f5927..3fa2dd83f27 100644
--- a/src/mesa/drivers/dri/swrast/swrast.c
+++ b/src/mesa/drivers/dri/swrast/swrast.c
@@ -866,6 +866,12 @@ dri_make_current(__DRIcontext * cPriv,
struct dri_drawable *draw;
struct dri_drawable *read;
+/* GL 3.0 allows *MakeCurrent(dpy, NULL, NULL, ctx) */
+if (!driDrawPriv && !driReadPriv) {
+_mesa_make_current(ctx, NULL, NULL);
+return GL_TRUE;
+}
+
if (!driDrawPriv || !driReadPriv)
return GL_FALSE;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 12/26] python: Fix unequality comparisons
On Thu, 2018-07-05 at 09:10 -0700, Dylan Baker wrote: > Quoting Mathieu Bridon (2018-07-05 06:17:43) > > +def __ne__(self, other): > > +return not self.__eq__(other) > > This can be written as "not (self == other)", right? It can, yes. The `==` operator is going to end up calling the `__eq__` method defined just above anyway, and we're already in the implementation details of `__ne__`. So it felt more natural to me to have `__ne__` be the opposite of `__eq__` rather than the opposite of `==`. Also, `not (… == …)` feels weird, it screams "replace me by `… != …`". Which I'm worried someone not paying attention might do in the future. I don't feel very strongly about it though, so I'll change it if you do. -- Mathieu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 3/5] platform/android: Enable kms_swrast fallback
Hey Emil,
On 05/07/18 15:04, Emil Velikov wrote:
Hi Rob,
On 5 July 2018 at 11:07, Robert Foss wrote:
Add support for the ForceSoftware option, which is togglable
on the Android platform through setting the "drm.gpu.force_software"
property to a non-zero value.
kms_swrast is also enabled as a fallback for when a driver is not
able to be loaded for for a drm node that was opened.
Signed-off-by: Robert Foss
---
src/egl/drivers/dri2/platform_android.c | 26 +
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
index 92b2d2b343e..bc644c25bf9 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1193,17 +1193,21 @@ static const __DRIextension
*droid_image_loader_extensions[] = {
};
EGLBoolean
-droid_load_driver(_EGLDisplay *disp)
+droid_load_driver(_EGLDisplay *disp, EGLBoolean force_software)
{
struct dri2_egl_display *dri2_dpy = disp->DriverData;
const char *err;
- dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
+ if (force_software) {
+ dri2_dpy->driver_name = strdup("kms_swrast");
+ } else {
+ dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
+ }
+
Nit: no brackets are needed here.
Ack.
if (dri2_dpy->driver_name == NULL)
return false;
dri2_dpy->is_render_node = drmGetNodeTypeFromFd(dri2_dpy->fd) ==
DRM_NODE_RENDER;
-
if (!dri2_dpy->is_render_node) {
#ifdef HAVE_DRM_GRALLOC
/* Handle control nodes using __DRI_DRI2_LOADER extension and GEM names
@@ -1359,6 +1363,7 @@ EGLBoolean
dri2_initialize_android(_EGLDriver *drv, _EGLDisplay *disp)
{
struct dri2_egl_display *dri2_dpy;
+ int force_software = disp->Options.ForceSoftware;
ForceSoftware is EGLBoolean and droid_load_driver() uses the same.
Yet "int" is used here and "= true" below.
Ack.
const char *err;
int ret;
@@ -1384,13 +1389,18 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay
*disp)
dri2_dpy->fd = droid_open_device(disp);
if (dri2_dpy->fd < 0) {
- err = "DRI2: failed to open device";
- goto cleanup;
+ err = "DRI2: failed to open device, trying software device";
Ignoring the first patch for a second - the goto cleanup should stay.
Ack.
}
- if (!droid_load_driver(disp)) {
- err = "DRI2: failed to load driver";
- goto cleanup;
+load_driver:
+ if (!droid_load_driver(disp, force_software)) {
+ if (force_software) {
+ err = "DRI2: failed to load driver";
+ goto cleanup;
+ } else {
+ force_software = true;
+ goto load_driver;
+ }
You can trivially eliminate the goto statement here.
As Tomasz noted this fallback is already implemented in egldriver.c,
so it can be removed entirely.
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 5/5] DEBUG
On 05/07/18 17:50, Robert Foss wrote:
Hey Emil,
On 05/07/18 15:13, Emil Velikov wrote:
Hi Rob,
On 5 July 2018 at 11:07, Robert Foss wrote:
@@ -511,7 +515,7 @@ dri2_open_driver(_EGLDisplay *disp)
char path[PATH_MAX], *search_paths, *next, *end;
char *get_extensions_name;
const __DRIextension **(*get_extensions)(void);
-
+ ALOGE("%s() 1 driver_name=%s", __func__, dri2_dpy->driver_name);
Aside:
Personally, I try to use "before/after X". Otherwise I find myself
always bouncing back and forth, relate the 1, 1.1... with the actual
call chain.
Hmmph, yeah. Maybe that is a more pleasant way of going about it.
I'll have to feel it out :)
@@ -1367,10 +1379,6 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay
*disp)
const char *err;
int ret;
- /* Not supported yet */
- if (disp->Options.ForceSoftware)
- return EGL_FALSE;
-
Even with the issues you mentioned in the cover letter, this could be
fleshed out or even squashed with 3/5. Up-to you really.
This chunk shouldn't really be in this patch. I had some issues setting the
Android property and while figuring out that the property wasn't propagated
properly this chunk was removed.
The debug patch will be dropped in v1, so this will be removed.
Actueally, when re-reading this comment I realize I misunderstood it.
I'll fold this into 3/5 as you're suggesting.
-Emil
___
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] [RFC 3/5] platform/android: Enable kms_swrast fallback
Hey Tomasz,
On 05/07/18 16:26, Tomasz Figa wrote:
Hi Rob,
On Thu, Jul 5, 2018 at 7:07 PM Robert Foss wrote:
Add support for the ForceSoftware option, which is togglable
on the Android platform through setting the "drm.gpu.force_software"
property to a non-zero value.
kms_swrast is also enabled as a fallback for when a driver is not
able to be loaded for for a drm node that was opened.
Signed-off-by: Robert Foss
---
src/egl/drivers/dri2/platform_android.c | 26 +
1 file changed, 18 insertions(+), 8 deletions(-)
Thanks for the patch. Please see my comments inline.
diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
index 92b2d2b343e..bc644c25bf9 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1193,17 +1193,21 @@ static const __DRIextension
*droid_image_loader_extensions[] = {
};
EGLBoolean
-droid_load_driver(_EGLDisplay *disp)
+droid_load_driver(_EGLDisplay *disp, EGLBoolean force_software)
{
struct dri2_egl_display *dri2_dpy = disp->DriverData;
const char *err;
- dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
+ if (force_software) {
+ dri2_dpy->driver_name = strdup("kms_swrast");
+ } else {
+ dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
+ }
+
if (dri2_dpy->driver_name == NULL)
return false;
dri2_dpy->is_render_node = drmGetNodeTypeFromFd(dri2_dpy->fd) ==
DRM_NODE_RENDER;
-
Unrelated whitespace change.
Ack.
if (!dri2_dpy->is_render_node) {
#ifdef HAVE_DRM_GRALLOC
/* Handle control nodes using __DRI_DRI2_LOADER extension and GEM names
@@ -1359,6 +1363,7 @@ EGLBoolean
dri2_initialize_android(_EGLDriver *drv, _EGLDisplay *disp)
{
struct dri2_egl_display *dri2_dpy;
+ int force_software = disp->Options.ForceSoftware;
EGLBoolean
Ack.
const char *err;
int ret;
@@ -1384,13 +1389,18 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay
*disp)
dri2_dpy->fd = droid_open_device(disp);
if (dri2_dpy->fd < 0) {
- err = "DRI2: failed to open device";
- goto cleanup;
+ err = "DRI2: failed to open device, trying software device";
}
- if (!droid_load_driver(disp)) {
- err = "DRI2: failed to load driver";
- goto cleanup;
+load_driver:
+ if (!droid_load_driver(disp, force_software)) {
+ if (force_software) {
+ err = "DRI2: failed to load driver";
+ goto cleanup;
+ } else {
+ force_software = true;
+ goto load_driver;
+ }
I believe we don't need this retry here, because if we fail here once,
_eglMatchDriver() would retry us with ForceSoftware = EGL_TRUE [1].
[1] https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/main/egldriver.c#n80
Oh nice. I didn't realize that the fallback was implemented somewhere else
already.
Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/26] python: Better iterate over dictionaries
On Thu, 2018-07-05 at 08:48 -0700, Dylan Baker wrote: > I've asked a couple of people who have (in the past at least) had a > hard requirement on python 2.x if moving to 3.x will be okay for > them. If it's not then we may need to do something else here. I've > used six in the past (although I know a lot of other pythonistas > don't like six), so that would be an option I think. > > While this works fine, it's going to create a lot of overhead for > anyone using python 2, since some of these data structures are huge, > and returning a copy (or copy of a copy) is going to be fairly > expensive. If we can drop python 2 support that of course isn't a > problem. I tested the scripts with Python 2 as well, and they didn't seem to take significantly more time to complete. (I didn't look at memory consumption though, which is a bit hard for scripts running so fast) Are some of those platforms that require Python 2 very low-performance ones, where it would have an actual impact? I have a very slow ARM machine handy, I can try and see whether the patches make a big difference there if it helps? > Assuming that those people are okay with python 3, If everyone is ok moving fully to Python 3, then the patch series could be quite different and simpler. ^_^ -- Mathieu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/dri: fix a crash in server_wait_Sync
On 2018-07-06 12:15 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> Ported from i965 including the comment.
>
> This fixes:
> dEQP-EGL.functional.reusable_sync.valid.wait_server
>
> Cc: 18.1
> ---
> src/gallium/state_trackers/dri/dri_helpers.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/gallium/state_trackers/dri/dri_helpers.c
> b/src/gallium/state_trackers/dri/dri_helpers.c
> index f1501bfb815..5d42873a208 100644
> --- a/src/gallium/state_trackers/dri/dri_helpers.c
> +++ b/src/gallium/state_trackers/dri/dri_helpers.c
> @@ -207,20 +207,26 @@ dri2_client_wait_sync(__DRIcontext *_ctx, void *_fence,
> unsigned flags,
>return false;
> }
> }
>
> static void
> dri2_server_wait_sync(__DRIcontext *_ctx, void *_fence, unsigned flags)
> {
> struct pipe_context *ctx = dri_context(_ctx)->st->pipe;
> struct dri2_fence *fence = (struct dri2_fence*)_fence;
>
> + /* We might be called here with a NULL fence as a result of WaitSyncKHR
> +* on a EGL_KHR_reusable_sync fence. Nothing to do here in such case.
> +*/
> + if (!fence)
> + return;
> +
> if (ctx->fence_server_sync)
>ctx->fence_server_sync(ctx, fence->pipe_fence);
> }
>
> const __DRI2fenceExtension dri2FenceExtension = {
> .base = { __DRI2_FENCE, 2 },
>
> .create_fence = dri2_create_fence,
> .get_fence_from_cl_event = dri2_get_fence_from_cl_event,
> .destroy_fence = dri2_destroy_fence,
>
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.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] [PATCH] vma/tests: Fix compilation if limits.h defines PAGE_SIZE (v2)
Jon Turney writes: > per POSIX, limits.h may define PAGE_SIZE when the value is not indeterminate > > v2: just change the variable name, since there's no intended correlation > here between this value and the machine's actual page size. > > Cc: Scott D Phillips > Signed-off-by: Jon Turney Reviewed-by: Scott D Phillips ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] intel/compiler: add an optimization pass for booleans
On Thu, 2018-07-05 at 15:47 -0700, Caio Marcelo de Oliveira Filho
wrote:
> (I had to stop reading to go home last Tuesday, so here are the
> remaining comments.)
>
>
> On Tue, May 15, 2018 at 01:05:21PM +0200, Iago Toral Quiroga wrote:
> > NIR assumes that all booleans are 32-bit but Intel hardware
> > produces
> > booleans of the same size as the operands to the CMP instruction,
> > so we
> > can actually have 8-bit and 16-bit booleans. To work around this
> > mismatch between NIR and the hardware, we emit boolean conversions
> > to
> > 32-bit right after emitting the CMP instruction during the NIR->FS
> > pass, which makes interfacing with NIR a lot easier, but can leave
> > unnecessary boolean conversions in the shader code.
>
> Question: have you explored handling this at the NIR->FS conversion?
> I.e. instead of generate the cmp + mov and then look for the cmp +
> mov
> to fix up; when generating a cmp, perform those checks (at nir level)
> and then pick the right bitsize.
It is not that easy. The problem is that NIR will continue to come at
us with 32-bit boolean instructions after the CMP+MOV, so instead of
prpagating forward for every conversion, now, for every bool we find in
IR we'd need to go back in the FS program to check if it is a real 32-
bit boolean or not to decide what to emit. I don't see any benefit,
plus we would be coupling all this with the translation implementation,
which I think is less nice than having it being a completely separate
thing.
Anyway, there is a major issue with the current patch that I have found
this week thanks to some new CTS tests: when we propagate the bitsize
of a logical instruction to its destination, that affects all its
consumers even outside the current block, so we need to handle
propagation across blocks, which adds a few more problems, so I still
need to figure out how to deal with that properly and whether that is
something we want to do (there is a reason why no other opt/lowering
passes do cross-block changes...).
Iago
>
> > +/**
> > + * Propagates the bit-size of the destination of a boolean
> > instruction to
> > + * all its consumers. If propagate_from_source is True, then the
> > producer
> > + * is a conversion MOV from a low bit-size boolean to 32-bit, and
> > in that
> > + * case the propagation happens from the source of the instruction
> > instead
> > + * of its destination.
> > + */
> > +static bool
> > +propagate_bool_bit_size(fs_inst *inst, bool propagate_from_source)
> > +{
> > + assert(!propagate_from_source || inst->opcode ==
> > BRW_OPCODE_MOV);
> > +
> > + bool progress = false;
> > +
> > + const unsigned bit_size = 8 * (propagate_from_source ?
> > + type_sz(inst->src[0].type) : type_sz(inst->dst.type));
> > +
> > + /* Look for any follow-up instructions that sources from the
> > boolean
> > +* result of the producer instruction and rewrite them to use
> > the correct
> > +* bit-size.
> > +*/
> > + foreach_inst_in_block_starting_from(fs_inst, fixup_inst, inst)
> > {
> > + if (!inst_supports_boolean(fixup_inst))
> > + continue;
>
> Should we care about other instruction clobbering the contents of
> inst->dst, or at this point of the optimization we can count on it
> not
> being?
>
>
> > + /* If it is a plain boolean conversion to 32-bit, then
> > look for any
> > + * follow-up instructions that source from the 32-bit
> > boolean and
> > + * rewrite them to source from the output of the CMP
> > (which is the
> > + * source of the conversion instruction) directly if
> > possible.
> > + */
> > + progress = propagate_bool_bit_size(conv_inst, true) ||
> > progress;
> > + }
> > +#if 0
> > + else if (inst_supports_boolean(inst) && inst->sources > 1)
> > {
>
> If you end up enabling this section, I suggest move the
> inst_supports_boolean() check to the beginning of the for-loop, as an
> early return. Makes the condition for the cases we are handling
> cleaner.
>
>
>
> > + /* For all logical instructions that can take more than
> > one operand
> > + * we need to ensure that all of them have matching bit-
> > sizes. If they
> > + * don't, it means that the original shader code is
> > operating boolean
> > + * expressions with different native bit-sizes and we
> > need to choose
> > + * a canonical boolean form for all the operands, which
> > requires to
> > + * inject conversions to temporaries. We choose the bit-
> > size of the
> > + * destination as the canonical form (which must be a 32-
> > bit boolean
> > + * since we only propagate smaller bit-sizes to the
> > destination if we
> > + * managed to convert all the operands to the same bit-
> > size) because
> > + * that way we don't need to worry about propagating the
> > destination
> > + * bit-size down the line.
> > + */
>
> To make this comment less heavy, I'd
