Re: [Mesa-dev] [PATCH v2] nv50/ir: optimize shl(a, 0) to a

[Ilia Mirkin]

Maybe in a separate change. I'd want to double check on all gens. I think
the thing I suggested is sufficient.

On Apr 29, 2017 8:09 PM, "Karol Herbst"  wrote:

2017-04-30 0:28 GMT+02:00 Ilia Mirkin :
> On Sat, Apr 29, 2017 at 6:09 PM, Karol Herbst 
wrote:
>> helps two alien isolation shaders
>>
>> shader-db:
>> total instructions in shared programs : 4251497 -> 4251494 (-0.00%)
>> total gprs used in shared programs: 513962 -> 513962 (0.00%)
>> total local used in shared programs   : 29797 -> 29797 (0.00%)
>> total bytes used in shared programs   : 38960264 -> 38960232 (-0.00%)
>>
>> localgpr   inst  bytes
>> helped   0   0   2   2
>>   hurt   0   0   0   0
>>
>> v2: handle potential mods on src0
>>
>> Signed-off-by: Karol Herbst 
>> Reviewed-by: Samuel Pitoiset 
>> Reviewed-by: Ilia Mirkin 
>> ---
>>  src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>> index 015def0391..82da0d3e48 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>> @@ -1284,6 +1284,13 @@ ConstantFolding::opnd(Instruction *i,
ImmediateValue , int s)
>>
>> case OP_SHL:
>> {
>> +  if (s == 1 && imm0.isInteger(0)) {
>> + i->op = i->src(0).mod.getOp();
>> + if (i->op != OP_CVT)
>> +i->src(0).mod = 0;
>
> Is this necessary? Presumably if the op != 0, then op == OP_CVT...
>

yeah, no idea. I just thought I do it right when I actually depend on
the getOp magic. But we can't emit any mods to begin with, so maybe we
should just drop the mod handling and be done with it?

>> + i->setSrc(1, NULL);
>> + break;
>> +  }
>>if (s != 1 || i->src(0).mod != Modifier(0))
>>   break;
>>// try to concatenate shifts
>> --
>> 2.12.2
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: Add NIR loop unrolling.

[Timothy Arceri]

On 29/04/17 07:11, Bas Nieuwenhuizen wrote:

Not much effect on dota2/talos, but positive on deferred.


Yeah I had a similar patch but didn't send it because I didn't see any 
difference. Feral tend to have loop heavy shader maybe mad max will show 
something? Anyway.


Reviewed-by: Timothy Arceri 



Signed-off-by: Bas Nieuwenhuizen 
---
  src/amd/vulkan/radv_pipeline.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index d6989137a55..7340675915f 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -61,6 +61,7 @@ static const struct nir_shader_compiler_options nir_options = 
{
.lower_unpack_unorm_4x8 = true,
.lower_extract_byte = true,
.lower_extract_word = true,
+   .max_unroll_iterations = 32
  };
  
  VkResult radv_CreateShaderModule(

@@ -152,6 +153,12 @@ radv_optimize_nir(struct nir_shader *shader)
  NIR_PASS(progress, shader, nir_copy_prop);
  NIR_PASS(progress, shader, nir_opt_remove_phis);
  NIR_PASS(progress, shader, nir_opt_dce);
+if (nir_opt_trivial_continues(shader)) {
+progress = true;
+NIR_PASS(progress, shader, nir_copy_prop);
+NIR_PASS(progress, shader, nir_opt_dce);
+}
+NIR_PASS(progress, shader, nir_opt_if);
  NIR_PASS(progress, shader, nir_opt_dead_cf);
  NIR_PASS(progress, shader, nir_opt_cse);
  NIR_PASS(progress, shader, nir_opt_peephole_select, 8);
@@ -159,6 +166,9 @@ radv_optimize_nir(struct nir_shader *shader)
  NIR_PASS(progress, shader, nir_opt_constant_folding);
  NIR_PASS(progress, shader, nir_opt_undef);
  NIR_PASS(progress, shader, nir_opt_conditional_discard);
+if (shader->options->max_unroll_iterations) {
+NIR_PASS(progress, shader, nir_opt_loop_unroll, 0);
+}
  } while (progress);
  }
  


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

Re: [Mesa-dev] [PATCH v2] nv50/ir: optimize shl(a, 0) to a

[Karol Herbst]

2017-04-30 0:28 GMT+02:00 Ilia Mirkin :
> On Sat, Apr 29, 2017 at 6:09 PM, Karol Herbst  wrote:
>> helps two alien isolation shaders
>>
>> shader-db:
>> total instructions in shared programs : 4251497 -> 4251494 (-0.00%)
>> total gprs used in shared programs: 513962 -> 513962 (0.00%)
>> total local used in shared programs   : 29797 -> 29797 (0.00%)
>> total bytes used in shared programs   : 38960264 -> 38960232 (-0.00%)
>>
>> localgpr   inst  bytes
>> helped   0   0   2   2
>>   hurt   0   0   0   0
>>
>> v2: handle potential mods on src0
>>
>> Signed-off-by: Karol Herbst 
>> Reviewed-by: Samuel Pitoiset 
>> Reviewed-by: Ilia Mirkin 
>> ---
>>  src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>> index 015def0391..82da0d3e48 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>> @@ -1284,6 +1284,13 @@ ConstantFolding::opnd(Instruction *i, ImmediateValue 
>> , int s)
>>
>> case OP_SHL:
>> {
>> +  if (s == 1 && imm0.isInteger(0)) {
>> + i->op = i->src(0).mod.getOp();
>> + if (i->op != OP_CVT)
>> +i->src(0).mod = 0;
>
> Is this necessary? Presumably if the op != 0, then op == OP_CVT...
>

yeah, no idea. I just thought I do it right when I actually depend on
the getOp magic. But we can't emit any mods to begin with, so maybe we
should just drop the mod handling and be done with it?

>> + i->setSrc(1, NULL);
>> + break;
>> +  }
>>if (s != 1 || i->src(0).mod != Modifier(0))
>>   break;
>>// try to concatenate shifts
>> --
>> 2.12.2
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/4] Call for testing: Gallium set_index_buffer removal etc.

[Ilia Mirkin]

On Fri, Apr 28, 2017 at 7:12 PM, Marek Olšák  wrote:
> These drivers need testing:
> - nv30
> - nv50
> - nvc0

I'm going to try to test these by Wednesday May 3. If you don't hear
from me (or anyone else regarding these drivers), don't wait.

Cheers,

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

Re: [Mesa-dev] [PATCH v2] nv50/ir: optimize shl(a, 0) to a

[Ilia Mirkin]

On Sat, Apr 29, 2017 at 6:09 PM, Karol Herbst  wrote:
> helps two alien isolation shaders
>
> shader-db:
> total instructions in shared programs : 4251497 -> 4251494 (-0.00%)
> total gprs used in shared programs: 513962 -> 513962 (0.00%)
> total local used in shared programs   : 29797 -> 29797 (0.00%)
> total bytes used in shared programs   : 38960264 -> 38960232 (-0.00%)
>
> localgpr   inst  bytes
> helped   0   0   2   2
>   hurt   0   0   0   0
>
> v2: handle potential mods on src0
>
> Signed-off-by: Karol Herbst 
> Reviewed-by: Samuel Pitoiset 
> Reviewed-by: Ilia Mirkin 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> index 015def0391..82da0d3e48 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> @@ -1284,6 +1284,13 @@ ConstantFolding::opnd(Instruction *i, ImmediateValue 
> , int s)
>
> case OP_SHL:
> {
> +  if (s == 1 && imm0.isInteger(0)) {
> + i->op = i->src(0).mod.getOp();
> + if (i->op != OP_CVT)
> +i->src(0).mod = 0;

Is this necessary? Presumably if the op != 0, then op == OP_CVT...

> + i->setSrc(1, NULL);
> + break;
> +  }
>if (s != 1 || i->src(0).mod != Modifier(0))
>   break;
>// try to concatenate shifts
> --
> 2.12.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] nv50/ir: optimize shl(a, 0) to a

[Karol Herbst]

helps two alien isolation shaders

shader-db:
total instructions in shared programs : 4251497 -> 4251494 (-0.00%)
total gprs used in shared programs: 513962 -> 513962 (0.00%)
total local used in shared programs   : 29797 -> 29797 (0.00%)
total bytes used in shared programs   : 38960264 -> 38960232 (-0.00%)

localgpr   inst  bytes
helped   0   0   2   2
  hurt   0   0   0   0

v2: handle potential mods on src0

Signed-off-by: Karol Herbst 
Reviewed-by: Samuel Pitoiset 
Reviewed-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 015def0391..82da0d3e48 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -1284,6 +1284,13 @@ ConstantFolding::opnd(Instruction *i, ImmediateValue 
, int s)
 
case OP_SHL:
{
+  if (s == 1 && imm0.isInteger(0)) {
+ i->op = i->src(0).mod.getOp();
+ if (i->op != OP_CVT)
+i->src(0).mod = 0;
+ i->setSrc(1, NULL);
+ break;
+  }
   if (s != 1 || i->src(0).mod != Modifier(0))
  break;
   // try to concatenate shifts
-- 
2.12.2

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

Re: [Mesa-dev] [PATCH 0/4] Call for testing: Gallium set_index_buffer removal etc.

[Edmondo Tommasina]

Hi Marek

I've also tested this series with nine and STALKER: CoC. Sadly it segfaults.

Bisected to this patch: "gallium: remove pipe_index_buffer and set_index_buffer"

edmondo


On Sat, Apr 29, 2017 at 1:12 AM, Marek Olšák  wrote:
> Hi,
>
> This series shrinks various gallium structures and removes
> set_index_buffer in order to decrease CPU overhead.
>
>
> PART 1: Performance results
>
> All testing below was done with radeonsi, and I used the drawoverhead
> microbenchmark from mesa/demos ported to piglit and using GL 3.0
> Compat and GL 3.2 Core (same GL states in both contexts).
>
> 1) Performance difference for the removal of set_index_buffer only:
>
>   Compat: DrawElements: 5.1 -> 5.3 million draws/second
>   Core:   DrawElements: 5.1 -> 5.5 million draws/second
>
> The result is better for the core profile where u_vbuf is disabled.
>
>
> 2) Performance difference with all 4 patches (Core profile only)
>
>DrawArrays: 8.3 -> 8.5 million draws/second
>DrawElements: 5.2 -> 5.8 million draws/second
>
>
> 3) Performance difference with threaded Gallium (Core profile only):
>
>DrawElements: 5.9 -> 7.1 million draws/second
>
> Threaded Gallium is still work in progress and might require
> a non-trivial amount of driver work.
>
>
> PART 2: Call for testing
>
> These drivers have been tested:
> - ddebug
> - llvmpipe
> - r300 (also with SWTCL)
> - r600
> - radeonsi
> - softpipe
> - trace
>
> These drivers need testing:
> - etnaviv
> - freedreno
> - nv30
> - nv50
> - nvc0
> - svga
> - swr
> - vc4
> - virgl
>
> The following state trackers might need testing:
> - nine
>
> You can get the patches by fetching:
>   git://people.freedesktop.org/~mareko/mesa gallium-cleanup
>
> I'd like to ask to you for testing drivers that I couldn't test.
> Please let me know when you're done testing and if things are good.
> After that, I'll push everything assuming the code review goes well.
> You can also ignore this if you don't mind fixing your driver in
> the master branch later.
>
> Thanks,
>
> Marek
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 100876] Variable GALLIUM_HUD_DUMP_DIR is not working with Wine LFS

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100876

Edmondo Tommasina  changed:

   What|Removed |Added

 CC||edmondo.tommas...@gmail.com

--- Comment #4 from Edmondo Tommasina  ---
The original code in 17.0 should just flush the I/O buffer to the file when the
buffer size reaches the default BUFSIZ value (8 KB on my machine) or when
fclose is called. You usually have to wait longer to see something in the
files. I'm not sure why with some applications the fclose doesn't get called on
exit.

With the new patch the I/O buffer gets flushed after every printf with newline.
This is probably the expected behavior and it doesn't seem to negatively impact
the performance.

Release 17.1 is expected for end next week and the patch is included.

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

[Mesa-dev] [Bug 100690] [Regression, bisected] TotalWar: Warhammer corrupted graphics

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100690

talonz  changed:

   What|Removed |Added

 CC||talonz...@gmail.com

--- Comment #11 from talonz  ---
Created attachment 131153
  --> https://bugs.freedesktop.org/attachment.cgi?id=131153=edit
Minor glitches

while no weird colouring you can still that there is a problem.  the game is
perfectly playable now at least

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

Re: [Mesa-dev] [PATCH] nv50/ir: optimmize shl(a, 0) to a

[Karol Herbst]

2017-04-29 21:03 GMT+02:00 Ilia Mirkin :
> On Sat, Apr 29, 2017 at 12:46 PM, Karol Herbst  wrote:
>> helps two alien isolation shaders
>>
>> shader-db:
>> total instructions in shared programs : 4251497 -> 4251494 (-0.00%)
>> total gprs used in shared programs: 513962 -> 513962 (0.00%)
>> total local used in shared programs   : 29797 -> 29797 (0.00%)
>> total bytes used in shared programs   : 38960264 -> 38960232 (-0.00%)
>>
>> localgpr   inst  bytes
>> helped   0   0   2   2
>>   hurt   0   0   0   0
>>
>> Signed-off-by: Karol Herbst 
>> ---
>>  src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>> index 015def0391..a2446e4df8 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
>> @@ -1284,6 +1284,11 @@ ConstantFolding::opnd(Instruction *i, ImmediateValue 
>> , int s)
>>
>> case OP_SHL:
>> {
>> +  if (s == 1 && imm0.isInteger(0)) {
>> + i->op = OP_MOV;
>> + i->setSrc(1, NULL);
>> + break;
>> +  }
>>if (s != 1 || i->src(0).mod != Modifier(0))
>>   break;
>
> Interesting. This suggests that src(0) may have modifiers, although I
> can't imagine what that'd be. Perhaps it can take a neg? In that case,
> you need to fix the OP_MOV above -- should probably do it anyways,
> i.e. i->op = i->src(0).mod.getOp() or something. With that, this is
>

I looked through the emitter and there seem to be no flags. Envydis
and nvdisasm seem to think the same.
Will fix it up nethertheless.

> Reviewed-by: Ilia Mirkin 
>
> Separately, I just noticed that we don't appear to have any 0 << x or
> 0 >> y or EXTBF or anything like that. I doubt it comes up too often
> though.
>
>>// try to concatenate shifts
>> --
>> 2.12.2
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gm107/ir: add a missing assertion in emitISCADD()

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 

On Sat, Apr 29, 2017 at 11:40 AM, Samuel Pitoiset
 wrote:
> For consistency, similar to the other emitters.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 2 ++
>  1 file changed, 2 insertions(+)
>
> 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 8b58df49c2..b1e9f941fe 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
> @@ -1858,6 +1858,8 @@ CodeEmitterGM107::emitIMAD()
>  void
>  CodeEmitterGM107::emitISCADD()
>  {
> +   assert(insn->src(1).get()->asImm());
> +
> switch (insn->src(2).getFile()) {
> case FILE_GPR:
>emitInsn(0x5c18);
> --
> 2.12.2
>
> ___
> 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] nv50/ir: optimmize shl(a, 0) to a

[Ilia Mirkin]

On Sat, Apr 29, 2017 at 12:46 PM, Karol Herbst  wrote:
> helps two alien isolation shaders
>
> shader-db:
> total instructions in shared programs : 4251497 -> 4251494 (-0.00%)
> total gprs used in shared programs: 513962 -> 513962 (0.00%)
> total local used in shared programs   : 29797 -> 29797 (0.00%)
> total bytes used in shared programs   : 38960264 -> 38960232 (-0.00%)
>
> localgpr   inst  bytes
> helped   0   0   2   2
>   hurt   0   0   0   0
>
> Signed-off-by: Karol Herbst 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> index 015def0391..a2446e4df8 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> @@ -1284,6 +1284,11 @@ ConstantFolding::opnd(Instruction *i, ImmediateValue 
> , int s)
>
> case OP_SHL:
> {
> +  if (s == 1 && imm0.isInteger(0)) {
> + i->op = OP_MOV;
> + i->setSrc(1, NULL);
> + break;
> +  }
>if (s != 1 || i->src(0).mod != Modifier(0))
>   break;

Interesting. This suggests that src(0) may have modifiers, although I
can't imagine what that'd be. Perhaps it can take a neg? In that case,
you need to fix the OP_MOV above -- should probably do it anyways,
i.e. i->op = i->src(0).mod.getOp() or something. With that, this is

Reviewed-by: Ilia Mirkin 

Separately, I just noticed that we don't appear to have any 0 << x or
0 >> y or EXTBF or anything like that. I doubt it comes up too often
though.

>// try to concatenate shifts
> --
> 2.12.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 06/37] genxml: Add alias for MOCS.

[Jason Ekstrand]

On April 29, 2017 01:02:28 Kenneth Graunke  wrote:


On Tuesday, April 25, 2017 1:59:15 PM PDT Rafael Antognolli wrote:

Use an alias, so we can set the same value as the #define's.

v3:
   - Call it "SO Buffer MOCS" to follow the most common naming scheme.
   - Add alias for gen7 and gen75 too (Ken).

Signed-off-by: Rafael Antognolli 
---
 src/intel/genxml/gen7.xml  | 1 +
 src/intel/genxml/gen75.xml | 1 +
 src/intel/genxml/gen8.xml  | 1 +
 src/intel/genxml/gen9.xml  | 1 +
 4 files changed, 4 insertions(+)

diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index 440258a..b63add0 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -1642,6 +1642,7 @@
 
 
  type="MEMORY_OBJECT_CONTROL_STATE"/>

+
 
 
 
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index 9f0486c..e63979c 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -1957,6 +1957,7 @@
 
 
  type="MEMORY_OBJECT_CONTROL_STATE"/>

+
 
 
 
diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 408d241..3b44406 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -2064,6 +2064,7 @@
 
 
  type="MEMORY_OBJECT_CONTROL_STATE"/>

+
 
  end="52" type="bool"/>

 
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index 59daa31..d78a321 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -2246,6 +2246,7 @@
 
 
  type="MEMORY_OBJECT_CONTROL_STATE"/>

+
 
  end="52" type="bool"/>

 



Can we just get rid of "SO Buffer Object Control State" then?
I don't think anything uses it, and your new field is easier to use.


We haven't on any of the others but I'm not necessarily opposed


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

[Mesa-dev] [Bug 92877] Add support for libglvnd

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92877

Vasyl Demin  changed:

   What|Removed |Added

 CC||vasyl.de...@gmail.com

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

Re: [Mesa-dev] [Nouveau] [PATCH] nv50/ir: optimmize shl(a, 0) to a

[Samuel Pitoiset]

"optimmize" ? No need to resend just for that though.

Reviewed-by: Samuel Pitoiset 

On 04/29/2017 06:46 PM, Karol Herbst wrote:

helps two alien isolation shaders

shader-db:
total instructions in shared programs : 4251497 -> 4251494 (-0.00%)
total gprs used in shared programs: 513962 -> 513962 (0.00%)
total local used in shared programs   : 29797 -> 29797 (0.00%)
total bytes used in shared programs   : 38960264 -> 38960232 (-0.00%)

 localgpr   inst  bytes
 helped   0   0   2   2
   hurt   0   0   0   0

Signed-off-by: Karol Herbst 
---
  src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 5 +
  1 file changed, 5 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 015def0391..a2446e4df8 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -1284,6 +1284,11 @@ ConstantFolding::opnd(Instruction *i, ImmediateValue 
, int s)
  
 case OP_SHL:

 {
+  if (s == 1 && imm0.isInteger(0)) {
+ i->op = OP_MOV;
+ i->setSrc(1, NULL);
+ break;
+  }
if (s != 1 || i->src(0).mod != Modifier(0))
   break;
// try to concatenate shifts


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

[Mesa-dev] [PATCH] nv50/ir: optimmize shl(a, 0) to a

[Karol Herbst]

helps two alien isolation shaders

shader-db:
total instructions in shared programs : 4251497 -> 4251494 (-0.00%)
total gprs used in shared programs: 513962 -> 513962 (0.00%)
total local used in shared programs   : 29797 -> 29797 (0.00%)
total bytes used in shared programs   : 38960264 -> 38960232 (-0.00%)

localgpr   inst  bytes
helped   0   0   2   2
  hurt   0   0   0   0

Signed-off-by: Karol Herbst 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 015def0391..a2446e4df8 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -1284,6 +1284,11 @@ ConstantFolding::opnd(Instruction *i, ImmediateValue 
, int s)
 
case OP_SHL:
{
+  if (s == 1 && imm0.isInteger(0)) {
+ i->op = OP_MOV;
+ i->setSrc(1, NULL);
+ break;
+  }
   if (s != 1 || i->src(0).mod != Modifier(0))
  break;
   // try to concatenate shifts
-- 
2.12.2

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] nv50/ir: skip optimizing ADD+SHL to SHLADD when src(1) is 0

[Karol Herbst]

yes. I will follow up with a patch, which will optimize that stuff again

2017-04-29 18:20 GMT+02:00 Samuel Pitoiset :
>
>
> On 04/29/2017 06:14 PM, Emil Velikov wrote:
>>
>> Hi Samuel,
>>
>> On 29 April 2017 at 17:01, Samuel Pitoiset 
>> wrote:
>>>
>>> Doing '(a << b) + c' when b is 0 is dumb, ADD should be used
>>> instead.
>>>
>>> This fixes a compilation error with Alien Isolation because
>>> src(1) is expected to be an immediate value, and the
>>> replaceZero logic will transform 0 to $r63 (or $r255).
>>>
>> Just checking: does this replace or complement the patch by Karol?
>
>
> It replaces.
>
>>
>> FWIW this seems like the better solution, although I could be confused
>> due to the longer commit message ;-)
>>
>> Thanks,
>> 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] [Mesa-stable] [PATCH] nv50/ir: skip optimizing ADD+SHL to SHLADD when src(1) is 0

[Samuel Pitoiset]

On 04/29/2017 06:14 PM, Emil Velikov wrote:

Hi Samuel,

On 29 April 2017 at 17:01, Samuel Pitoiset  wrote:

Doing '(a << b) + c' when b is 0 is dumb, ADD should be used
instead.

This fixes a compilation error with Alien Isolation because
src(1) is expected to be an immediate value, and the
replaceZero logic will transform 0 to $r63 (or $r255).


Just checking: does this replace or complement the patch by Karol?


It replaces.



FWIW this seems like the better solution, although I could be confused
due to the longer commit message ;-)

Thanks,
Emil


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

Re: [Mesa-dev] [Mesa-stable] [PATCH] nv50/ir: skip optimizing ADD+SHL to SHLADD when src(1) is 0

[Emil Velikov]

Hi Samuel,

On 29 April 2017 at 17:01, Samuel Pitoiset  wrote:
> Doing '(a << b) + c' when b is 0 is dumb, ADD should be used
> instead.
>
> This fixes a compilation error with Alien Isolation because
> src(1) is expected to be an immediate value, and the
> replaceZero logic will transform 0 to $r63 (or $r255).
>
Just checking: does this replace or complement the patch by Karol?

FWIW this seems like the better solution, although I could be confused
due to the longer commit message ;-)

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

[Mesa-dev] [PATCH] nv50/ir: skip optimizing ADD+SHL to SHLADD when src(1) is 0

[Samuel Pitoiset]

Doing '(a << b) + c' when b is 0 is dumb, ADD should be used
instead.

This fixes a compilation error with Alien Isolation because
src(1) is expected to be an immediate value, and the
replaceZero logic will transform 0 to $r63 (or $r255).

Signed-off-by: Samuel Pitoiset 
Cc: "13.0 17.0 17.1" 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 4c92a1efb5..015def0391 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -2224,6 +2224,9 @@ LateAlgebraicOpt::tryADDToSHLADD(Instruction *add)
if (!shl->src(1).getImmediate(imm))
   return false;
 
+   if (imm.isInteger(0))
+  return false;
+
add->op = OP_SHLADD;
add->setSrc(2, add->src(!s));
// SHL can't have any modifiers, but the ADD source may have had
-- 
2.12.2

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

Re: [Mesa-dev] [PATCH] nv50/ir: we can't replace 0x0 with zero reg for SHLADD

[Karol Herbst]

2017-04-29 17:18 GMT+02:00 Ilia Mirkin :
> On Sat, Apr 29, 2017 at 10:41 AM, Karol Herbst  wrote:
>> fixes a crash in Alien Isolation
>
> What crash?

assertion, because shladd requires an immediate, there can't be a reg at src1

"shladd u32 $r0 $r0 $r63 $r36" is invalid for the emiter so we have to
use 0x0 here

> How did the zero get there?

by replaceZero

> Does this only happen if you do your optimization loop thing?

no, it happens on master and the stable branches without any modifications

>
> In either case, we still want the replaceZero() logic. However that
> logic should be aware that the middle argument of a SHLADD is not to
> be touched. Otherwise we could end up with an un-emittable
> instruction.

ohh right, you mean for the other args... true.

>
>>
>> Signed-off-by: Karol Herbst 
>> ---
>>  src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> 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 732e1a93b4..4815d6df07 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
>> @@ -740,7 +740,7 @@ NVC0LegalizePostRA::visit(BasicBlock *bb)
>> next = hi;
>>   }
>>
>> - if (i->op != OP_MOV && i->op != OP_PFETCH)
>> + if (i->op != OP_MOV && i->op != OP_PFETCH && i->op != OP_SHLADD)
>>  replaceZero(i);
>>}
>> }
>> --
>> 2.12.2
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gm107/ir: add a missing assertion in emitISCADD()

[Samuel Pitoiset]

For consistency, similar to the other emitters.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 2 ++
 1 file changed, 2 insertions(+)

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 8b58df49c2..b1e9f941fe 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -1858,6 +1858,8 @@ CodeEmitterGM107::emitIMAD()
 void
 CodeEmitterGM107::emitISCADD()
 {
+   assert(insn->src(1).get()->asImm());
+
switch (insn->src(2).getFile()) {
case FILE_GPR:
   emitInsn(0x5c18);
-- 
2.12.2

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

Re: [Mesa-dev] [PATCH] nv50/ir: we can't replace 0x0 with zero reg for SHLADD

[Ilia Mirkin]

On Sat, Apr 29, 2017 at 10:41 AM, Karol Herbst  wrote:
> fixes a crash in Alien Isolation

What crash? How did the zero get there? Does this only happen if you
do your optimization loop thing?

In either case, we still want the replaceZero() logic. However that
logic should be aware that the middle argument of a SHLADD is not to
be touched. Otherwise we could end up with an un-emittable
instruction.

>
> Signed-off-by: Karol Herbst 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> 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 732e1a93b4..4815d6df07 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> @@ -740,7 +740,7 @@ NVC0LegalizePostRA::visit(BasicBlock *bb)
> next = hi;
>   }
>
> - if (i->op != OP_MOV && i->op != OP_PFETCH)
> + if (i->op != OP_MOV && i->op != OP_PFETCH && i->op != OP_SHLADD)
>  replaceZero(i);
>}
> }
> --
> 2.12.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nv50/ir: we can't replace 0x0 with the zero reg for SHLADD

[Karol Herbst]

fixes a crash in Alien Isolation

Signed-off-by: Karol Herbst 
Cc: 13.0 17.0 17.1 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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 732e1a93b4..4815d6df07 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -740,7 +740,7 @@ NVC0LegalizePostRA::visit(BasicBlock *bb)
next = hi;
  }
 
- if (i->op != OP_MOV && i->op != OP_PFETCH)
+ if (i->op != OP_MOV && i->op != OP_PFETCH && i->op != OP_SHLADD)
 replaceZero(i);
   }
}
-- 
2.12.2

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

[Mesa-dev] [Bug 100690] [Regression, bisected] TotalWar: Warhammer corrupted graphics

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100690

--- Comment #10 from Gregor Münch  ---
I just tested it too, for me the world map is fixed. But Im waiting for your
screenshots to see what you see. ;)

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

[Mesa-dev] [PATCH] nv50/ir: we can't replace 0x0 with zero reg for SHLADD

[Karol Herbst]

fixes a crash in Alien Isolation

Signed-off-by: Karol Herbst 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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 732e1a93b4..4815d6df07 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -740,7 +740,7 @@ NVC0LegalizePostRA::visit(BasicBlock *bb)
next = hi;
  }
 
- if (i->op != OP_MOV && i->op != OP_PFETCH)
+ if (i->op != OP_MOV && i->op != OP_PFETCH && i->op != OP_SHLADD)
 replaceZero(i);
   }
}
-- 
2.12.2

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

[Mesa-dev] [PATCH v2] mesa: Avoid leaking surface in st_renderbuffer_delete

[Bartosz Tomczyk]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100741
Fixes: a5e733c6b52 mesa: drop current draw/read buffer when ctx is released
CC: Rob Clark 
v2: add comment in code
---
 src/mesa/main/context.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 3570f94f5a..9aa6fb64b2 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1664,17 +1664,23 @@ _mesa_make_current( struct gl_context *newCtx,
   _mesa_flush(curCtx);
 
/* We used to call _glapi_check_multithread() here.  Now do it in drivers */
-   _glapi_set_context((void *) newCtx);
-   assert(_mesa_get_current_context() == newCtx);
 
if (!newCtx) {
   _glapi_set_dispatch(NULL);  /* none current */
+  /* We need old ctx to correctly release Draw/ReadBuffer
+   * and avoid a surface leak in st_renderbuffer_delete.
+   * Therefore, first drop buffers then set new ctx to NULL.
+   */
   if (curCtx) {
  _mesa_reference_framebuffer(>WinSysDrawBuffer, NULL);
  _mesa_reference_framebuffer(>WinSysReadBuffer, NULL);
   }
+  _glapi_set_context(NULL);
+  assert(_mesa_get_current_context() == NULL);
}
else {
+  _glapi_set_context((void *) newCtx);
+  assert(_mesa_get_current_context() == newCtx);
   _glapi_set_dispatch(newCtx->CurrentClientDispatch);
 
   if (drawBuffer && readBuffer) {
-- 
2.12.2

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

Re: [Mesa-dev] [PATCH kmscube 1/2] common: use %llx to print modifier

[Rob Clark]

On Sat, Apr 29, 2017 at 5:00 AM, Lucas Stach  wrote:
> Am Freitag, den 28.04.2017, 14:17 -0400 schrieb Rob Clark:
>> I guess this applies on top of one of Ben's in-flight patches?
>> Perhaps it can be squashed into that?  (Otherwise remind me about
>> this
>> when the modifiers patchset is merged)
>
> It applies on top of what is currently in FDO mesa/kmscube. It seems
> the modifier patchset has been merged there.

my bad.. seems I should rename my remotes, since "origin" is still my
old github tree.. I was looking in the wrong place ;-)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 100854] YUV to RGB Color Space Conversion result is not precise

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100854

--- Comment #2 from johnson@intel.com ---
@Matt Turner
Yes I have.
Also piglit test has YUV2RGB test
https://cgit.freedesktop.org/piglit/tree/tests/spec/ext_image_dma_buf_import/sample_yuv.c

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

Re: [Mesa-dev] [PATCH 12/16] travis: split the make target to three separate ones

[Emil Velikov]

On 29 April 2017 at 00:02, Andres Gomez  wrote:

> With those 2 changes, this is:
>
Seems like I've squashed them in the wrong patch :-\
Fixed up and pushed the series.

Thanks again for the comments and reviews!
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: initialise dummy_thread via _eglInitThreadInfo

[Ilia Mirkin]

On Sat, Apr 29, 2017 at 10:04 AM, Emil Velikov  wrote:
> On 29 April 2017 at 14:51, Ilia Mirkin  wrote:
>> On Tue, Apr 25, 2017 at 12:07 PM, Emil Velikov  
>> wrote:
>>> From: Emil Velikov 
>>>
>>> Considering we cannot make dummy_thread a constant we might as well,
>>> initialise by the same function that handles the actual thread info.
>>>
>>> This way we don't need to worry about mismatch between the initialiser
>>> and initialising function.
>>>
>>> Signed-off-by: Emil Velikov 
>>> ---
>>>  src/egl/main/eglcurrent.c | 13 -
>>>  1 file changed, 4 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/src/egl/main/eglcurrent.c b/src/egl/main/eglcurrent.c
>>> index eae7bdcea15..26f42761e26 100644
>>> --- a/src/egl/main/eglcurrent.c
>>> +++ b/src/egl/main/eglcurrent.c
>>> @@ -37,12 +37,8 @@
>>>  #include "eglcurrent.h"
>>>  #include "eglglobals.h"
>>>
>>> -/* This should be kept in sync with _eglInitThreadInfo() */
>>> -#define _EGL_THREAD_INFO_INITIALIZER \
>>> -   { EGL_SUCCESS, NULL, EGL_OPENGL_ES_API, NULL, NULL, NULL }
>>> -
>>>  /* a fallback thread info to guarantee that every thread always has one */
>>> -static _EGLThreadInfo dummy_thread = _EGL_THREAD_INFO_INITIALIZER;
>>> +static _EGLThreadInfo dummy_thread;
>>
>> Are statics initialized to 0? I didn't think they were... I think you
>> need a "= {};" here. Did you test this by forcing allocation failures?
>>
> Static variables are implicitly initialized with zero/NULL [1]. The
> .bss size is increased while the actual [complete] binary size remains
> small.
>
> Consider the following:
>
>  static int foo[2000] = {};
>  static int foo[2000];
>
> The former will/should produce a very large binary, while the
> following will not. In both case the array will be filled with zeros
> ;-)

OK, I thought there was some subtlety in that situation, but I guess
not. Excellent.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: polish dri2_to_egl_attribute_map[]

[Emil Velikov]

On 28 April 2017 at 19:38, Matt Turner  wrote:
> Nice change.
>
Indeed - less code + smaller binary size.

> Reviewed-by: Matt Turner 

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

Re: [Mesa-dev] [PATCH] egl: initialise dummy_thread via _eglInitThreadInfo

[Emil Velikov]

On 29 April 2017 at 14:51, Ilia Mirkin  wrote:
> On Tue, Apr 25, 2017 at 12:07 PM, Emil Velikov  
> wrote:
>> From: Emil Velikov 
>>
>> Considering we cannot make dummy_thread a constant we might as well,
>> initialise by the same function that handles the actual thread info.
>>
>> This way we don't need to worry about mismatch between the initialiser
>> and initialising function.
>>
>> Signed-off-by: Emil Velikov 
>> ---
>>  src/egl/main/eglcurrent.c | 13 -
>>  1 file changed, 4 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/egl/main/eglcurrent.c b/src/egl/main/eglcurrent.c
>> index eae7bdcea15..26f42761e26 100644
>> --- a/src/egl/main/eglcurrent.c
>> +++ b/src/egl/main/eglcurrent.c
>> @@ -37,12 +37,8 @@
>>  #include "eglcurrent.h"
>>  #include "eglglobals.h"
>>
>> -/* This should be kept in sync with _eglInitThreadInfo() */
>> -#define _EGL_THREAD_INFO_INITIALIZER \
>> -   { EGL_SUCCESS, NULL, EGL_OPENGL_ES_API, NULL, NULL, NULL }
>> -
>>  /* a fallback thread info to guarantee that every thread always has one */
>> -static _EGLThreadInfo dummy_thread = _EGL_THREAD_INFO_INITIALIZER;
>> +static _EGLThreadInfo dummy_thread;
>
> Are statics initialized to 0? I didn't think they were... I think you
> need a "= {};" here. Did you test this by forcing allocation failures?
>
Static variables are implicitly initialized with zero/NULL [1]. The
.bss size is increased while the actual [complete] binary size remains
small.

Consider the following:

 static int foo[2000] = {};
 static int foo[2000];

The former will/should produce a very large binary, while the
following will not. In both case the array will be filled with zeros
;-)

-Emil

[1] http://c-faq.com/decl/initval.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] c11/threads: rework Windows thrd_current() comment

[Emil Velikov]

From: Emil Velikov 

Drop the misleading "will not match the one returned by thread_create"
hunk and provide more clarity as to what/why GetCurrentThread() isn't
the solution we're looking for.

Cc: José Fonseca 
Signed-off-by: Emil Velikov 
---
 include/c11/threads_win32.h | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/c11/threads_win32.h b/include/c11/threads_win32.h
index d017c31c34e..7ffd3ae3a23 100644
--- a/include/c11/threads_win32.h
+++ b/include/c11/threads_win32.h
@@ -502,9 +502,13 @@ thrd_current(void)
 HANDLE hCurrentThread;
 BOOL bRet;
 
-/* GetCurrentThread() returns a pseudo-handle, which is useless.  We need
- * to call DuplicateHandle to get a real handle.  However the handle value
- * will not match the one returned by thread_create.
+/* GetCurrentThread() returns a pseudo-handle, which we need
+ * to pass to DuplicateHandle. Only the resulting handle can be used
+ * from other threads.
+ *
+ * Note that neither handle can be compared to the one by thread_create.
+ * Only the thread IDs - as returned by GetThreadId and GetCurrentThreadId
+ * can be compared directly.
  *
  * Other potential solutions would be:
  * - define thrd_t as a thread Ids, but this would mean we'd need to 
OpenThread for many operations
-- 
2.12.2

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

Re: [Mesa-dev] [PATCH] egl: initialise dummy_thread via _eglInitThreadInfo

[Ilia Mirkin]

On Tue, Apr 25, 2017 at 12:07 PM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> Considering we cannot make dummy_thread a constant we might as well,
> initialise by the same function that handles the actual thread info.
>
> This way we don't need to worry about mismatch between the initialiser
> and initialising function.
>
> Signed-off-by: Emil Velikov 
> ---
>  src/egl/main/eglcurrent.c | 13 -
>  1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/src/egl/main/eglcurrent.c b/src/egl/main/eglcurrent.c
> index eae7bdcea15..26f42761e26 100644
> --- a/src/egl/main/eglcurrent.c
> +++ b/src/egl/main/eglcurrent.c
> @@ -37,12 +37,8 @@
>  #include "eglcurrent.h"
>  #include "eglglobals.h"
>
> -/* This should be kept in sync with _eglInitThreadInfo() */
> -#define _EGL_THREAD_INFO_INITIALIZER \
> -   { EGL_SUCCESS, NULL, EGL_OPENGL_ES_API, NULL, NULL, NULL }
> -
>  /* a fallback thread info to guarantee that every thread always has one */
> -static _EGLThreadInfo dummy_thread = _EGL_THREAD_INFO_INITIALIZER;
> +static _EGLThreadInfo dummy_thread;

Are statics initialized to 0? I didn't think they were... I think you
need a "= {};" here. Did you test this by forcing allocation failures?

>  static mtx_t _egl_TSDMutex = _MTX_INITIALIZER_NP;
>  static EGLBoolean _egl_TSDInitialized;
>  static tss_t _egl_TSD;
> @@ -109,7 +105,6 @@ static inline EGLBoolean _eglInitTSD(void 
> (*dtor)(_EGLThreadInfo *))
>  static void
>  _eglInitThreadInfo(_EGLThreadInfo *t)
>  {
> -   memset(t, 0, sizeof(*t));
> t->LastError = EGL_SUCCESS;
> /* default, per EGL spec */
> t->CurrentAPI = EGL_OPENGL_ES_API;
> @@ -123,10 +118,10 @@ static _EGLThreadInfo *
>  _eglCreateThreadInfo(void)
>  {
> _EGLThreadInfo *t = calloc(1, sizeof(_EGLThreadInfo));
> -   if (t)
> -  _eglInitThreadInfo(t);
> -   else
> +   if (!t)
>t = _thread;
> +
> +   _eglInitThreadInfo(t);
> return t;
>  }
>
> --
> 2.12.2
>
> ___
> 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] gallium/targets: fix bool setting on BE architectures

[Emil Velikov]

On 29 April 2017 at 14:24, Ilia Mirkin  wrote:
> On Sat, Apr 29, 2017 at 9:18 AM, Emil Velikov  
> wrote:
>> On 18 April 2017 at 05:00, Ilia Mirkin  wrote:
>>> val_bool and val_int are in a union. val_bool gets the first byte, which
>>> happens to work on LE when setting via the int, but breaks on BE. By
>>> setting the value properly, we are able to use DRI3 on BE architectures.
>>> Tested by running glxgears with a NV34 in a G5 PPC.
>>>
>>> Signed-off-by: Ilia Mirkin 
>>> Cc: mesa-sta...@lists.freedesktop.org
>>> ---
>>>  src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 8 
>>>  src/gallium/targets/pipe-loader/pipe_i915.c | 2 +-
>>>  src/gallium/targets/pipe-loader/pipe_msm.c  | 2 +-
>>>  src/gallium/targets/pipe-loader/pipe_nouveau.c  | 2 +-
>>>  src/gallium/targets/pipe-loader/pipe_r300.c | 2 +-
>>>  src/gallium/targets/pipe-loader/pipe_r600.c | 2 +-
>>>  src/gallium/targets/pipe-loader/pipe_radeonsi.c | 2 +-
>>>  7 files changed, 10 insertions(+), 10 deletions(-)
>>>
>> A while ago I've managed to half the duplication, but we still have some ;-)
>>
>> With the vmwgfx hunk squashed:
>> Reviewed-by: Emil Velikov 
>
> Thanks. I totally forgot about this... will try to push it out today.
> Feel free to do it for me if you like.
>
Done + fixed up the patchwork bits.
Feel free to parse through the latter - you might notice a few other
patches that have fallen through the cracks

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

Re: [Mesa-dev] [PATCH] i965: Solve Android native fence fd double close issue

[Xu, Randy]

> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Saturday, April 29, 2017 8:36 PM
> To: Chad Versace ; Emil Velikov
> ; Xu, Randy ; mesa-
> d...@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] i965: Solve Android native fence fd double
> close issue
> 
> On 28 April 2017 at 17:18, Chad Versace 
> wrote:
> > On Thu 27 Apr 2017, Emil Velikov wrote:
> >> On 27 April 2017 at 12:14, Xu, Randy  wrote:
> >> > Hi, Chad
> >> >
> >> > Please review this patch, we need it to solve some instability
> >> > issues
> >
> > Randy and Tapani, could you provide a few dEQP test names that this
> > patch fixes? I'd like to mention at least one EGL and one Vulkan test
> > in the commit message.
> >
> >> The patch is correct, although the commit message can be improved upon.
> >> Read through the following example and consider the alternative
> >> solution mentioned within.
> >
> > Yes, this patch is correct. It makes brw_dri_create_fence_fd() behave
> > like all the other drivers' create_fence_fd funcs, which call dup().
> > Since this is an easy one-liner that can backport to stable, let's
> > take it.
> >
> > However, I believe the fully correct solution is Emil's plan B:
> > __DRI2fenceExtensionRec::create_fence_fd should transfer fd ownership
> > to the driver, and therefore no dup is needed. But that's a slightly
> > more invasive change that's not as easily backported to stable.
> >
> > Reviewed-by: Chad Versace 
> > Cc: mesa-sta...@lists.freedesktop.org
> >
> > Emil, how about one of us appends your extended commit message to
> > Randy's, and then pushes?
> >
> Feel free to polish and push Chad.
> 
> Randy please don't forget to send a patch for dri_interface.h.

Thanks, Emil,  if create_fence_fd just transfer fd ownership to the driver, 
not dup, we also need change dri2_dup_native_fence_fd, which should not
keep the fd after calls get_fence_fd. It should be workable, but I need do
more test.

Chad, please help to polish my comments, or give me some suggestions.

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

Re: [Mesa-dev] [PATCH] gallium/targets: fix bool setting on BE architectures

[Ilia Mirkin]

On Sat, Apr 29, 2017 at 9:18 AM, Emil Velikov  wrote:
> On 18 April 2017 at 05:00, Ilia Mirkin  wrote:
>> val_bool and val_int are in a union. val_bool gets the first byte, which
>> happens to work on LE when setting via the int, but breaks on BE. By
>> setting the value properly, we are able to use DRI3 on BE architectures.
>> Tested by running glxgears with a NV34 in a G5 PPC.
>>
>> Signed-off-by: Ilia Mirkin 
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>>  src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 8 
>>  src/gallium/targets/pipe-loader/pipe_i915.c | 2 +-
>>  src/gallium/targets/pipe-loader/pipe_msm.c  | 2 +-
>>  src/gallium/targets/pipe-loader/pipe_nouveau.c  | 2 +-
>>  src/gallium/targets/pipe-loader/pipe_r300.c | 2 +-
>>  src/gallium/targets/pipe-loader/pipe_r600.c | 2 +-
>>  src/gallium/targets/pipe-loader/pipe_radeonsi.c | 2 +-
>>  7 files changed, 10 insertions(+), 10 deletions(-)
>>
> A while ago I've managed to half the duplication, but we still have some ;-)
>
> With the vmwgfx hunk squashed:
> Reviewed-by: Emil Velikov 

Thanks. I totally forgot about this... will try to push it out today.
Feel free to do it for me if you like.

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

Re: [Mesa-dev] [PATCH v2] scons: update for LLVM 4.0

[Emil Velikov]

Hi Ben,

On 27 April 2017 at 21:31, Ben Boeckel  wrote:
> LLVMDemangle, LLVMGlobalISel, and LLVMDebugInfoMSF are new.
>
> Also update the comment to add irreader to the list of components.
>
> CC: 
> Reviewed-by: Chuck Atkins 
> Signed-off-by: Ben Boeckel 
Haven't tested this but is seems reasonable.

Acked-by: Emil Velikov 

Barring any objections from Jose I'll push this in a couple of days.

-Emil
P.S. For future patches please add a brief changelog. Before or after
the --- line.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/targets: fix bool setting on BE architectures

[Emil Velikov]

On 18 April 2017 at 05:00, Ilia Mirkin  wrote:
> val_bool and val_int are in a union. val_bool gets the first byte, which
> happens to work on LE when setting via the int, but breaks on BE. By
> setting the value properly, we are able to use DRI3 on BE architectures.
> Tested by running glxgears with a NV34 in a G5 PPC.
>
> Signed-off-by: Ilia Mirkin 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 8 
>  src/gallium/targets/pipe-loader/pipe_i915.c | 2 +-
>  src/gallium/targets/pipe-loader/pipe_msm.c  | 2 +-
>  src/gallium/targets/pipe-loader/pipe_nouveau.c  | 2 +-
>  src/gallium/targets/pipe-loader/pipe_r300.c | 2 +-
>  src/gallium/targets/pipe-loader/pipe_r600.c | 2 +-
>  src/gallium/targets/pipe-loader/pipe_radeonsi.c | 2 +-
>  7 files changed, 10 insertions(+), 10 deletions(-)
>
A while ago I've managed to half the duplication, but we still have some ;-)

With the vmwgfx hunk squashed:
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] i965: Select pipeline and emit state base address in Gen8+ HiZ ops.

[Emil Velikov]

On 30 March 2017 at 23:32, Nanley Chery  wrote:
> On Mon, Mar 20, 2017 at 08:05:22PM -0700, Nanley Chery wrote:
>
> Okay, I've re-read the email.
>
>> On Mon, Mar 20, 2017 at 08:01:25PM -0700, Nanley Chery wrote:
>> > On Thu, Mar 16, 2017 at 05:34:13PM -0700, Kenneth Graunke wrote:
>> > > On Wednesday, March 8, 2017 10:27:20 AM PDT Nanley Chery wrote:
>> > > > On Wed, Mar 08, 2017 at 10:07:12AM -0800, Nanley Chery wrote:
>> > > > > On Wed, Mar 08, 2017 at 02:17:59AM -0800, Kenneth Graunke wrote:
>> > > > > > On Thursday, March 2, 2017 4:36:08 PM PST Nanley Chery wrote:
>> > > > > > > On Mon, Feb 06, 2017 at 03:55:49PM -0800, Kenneth Graunke wrote:
>> > > > > > > > If a HiZ op is the first thing in the batch, we should make 
>> > > > > > > > sure
>> > > > > > > > to select the render pipeline and emit state base address 
>> > > > > > > > before
>> > > > > > > > proceeding.
>> > > > > > > >
>> > > > > > > > I believe 3DSTATE_WM_HZ_OP creates 3DPRIMITIVEs internally, and
>> > > > > > > > dispatching those on the GPGPU pipeline seems a bit sketchy.  
>> > > > > > > > I'm
>> > > > > > >
>> > > > > > > Yes, it does seem like we currently allow HZ_OPs within a GPGPU
>> > > > > > > pipeline. This patch should fix that problem.
>> > > > > > >
>> > > > > > > > not actually sure that STATE_BASE_ADDRESS is necessary, as the
>> > > > > > > > depth related commands use graphics addresses, not ones 
>> > > > > > > > relative
>> > > > > > > > to the base address...but we're likely to set it as part of the
>> > > > > > > > next operation anyway, so we should just do it right away.
>> > > > > > > >
>> >
>> > Why should we do it right away if it will happen later on? I don't see
>> > why this part of the patch is necessary.
>> >
>> > > > > > >
>> > > > > > > I agree, re-emitting STATE_BASE_ADDRESS doesn't seem necessary. 
>> > > > > > > I think
>> > > > > > > we should drop this part of the patch and add it back in later 
>> > > > > > > if we get
>> > > > > > > some data that it's necessary. Leaving it there may be 
>> > > > > > > distracting to
>> > > > > > > some readers and the BDW PRM warns that it's an expensive 
>> > > > > > > command:
>> > > > > > >
>> > > > > > >   Execution of this command causes a full pipeline flush, thus 
>> > > > > > > its
>> > > > > > >   use should be minimized for higher performance.
>> > > > > >
>> > > > > > I think it should be basically free, actually.  We track a boolean,
>> > > > > > brw->batch.state_base_address_emitted, to avoid emitting it 
>> > > > > > multiple
>> > > > > > times per batch.
>> > > > > >
>> > > > > > Let's say the first thing in a fresh batch is a HiZ op, followed by
>> > > > > > normal drawing.  Previously, we'd do:
>> > > > > >
>> > > > > > 1. HiZ op commands
>> > > > > > 2. STATE_BASE_ADDRESS (triggered by normal rendering upload)
>> > > > > > 3. rest of normal drawing commands
>> > > > > >
>> > > > > > Now we'd do:
>> > > > > >
>> > > > > > 1. STATE_BASE_ADDRESS (triggered by HiZ op)
>> > > > > > 2. HiZ op commands
>> > > > > > 3. normal drawing commands (second SBA is skipped)
>> > > > > >
>> > > > > > In other words...we're just moving it a bit earlier.  I suppose 
>> > > > > > there
>> > > > > > could be a batch containing only HiZ ops, at which point we'd pay 
>> > > > > > for
>> > > > > > a single STATE_BASE_ADDRESS...but that seems really unlikely.
>> > > > > >
>> > > > >
>> > > > > Sorry for not stating it up front, but the special case you've 
>> > > > > mentioned
>> > > > > is exactly what I'd like not to hurt unnecessarily.
>> > > > >
>> > >
>> > > Why?  We really think there are going to be batches with only
>> > > 3DSTATE_WM_HZ_OP and no normal rendering or BLORP?  It sounds
>> > > really hypothetical to me.
>> > >
>> >
>> > I've commented on the performance implications of that snippet because
>> > it is the only functional change I can see from emitting SBA. That
>> > unfortunately seems to have distracted us from the more important
>> > question found above. Sorry about that.
>> >
>
> I've commented on the performance implications of that snippet because
> it is the only functional change I can see from emitting SBA.
> Unfortunately, discussing the impact of this change is seems to have
> distracted us from the more important question of why we're making this
> change. Sorry about that.
>
>> > > > Correct me if I'm wrong, but after thinking about it some more, it 
>> > > > seems
>> > > > that performance wouldn't suffer by emitting the SBA since the pipeline
>> > > > was already flushed at the end of the preceding batch. It may also
>> > > > improve since the pipelined HiZ op will likely be followed by other
>> > > > pipelined commands. I'm not totally confident in my understanding on
>> > > > pipeline flushes by the way. Is this why you'd like to emit the SBA 
>> > > > here?
>> > > > I think it's fine to leave it if we expound on the rationale.
>> > >
>> > > Performance is not a motivation for this 

Re: [Mesa-dev] [PATCH 0/4] Call for testing: Gallium set_index_buffer removal etc.

[Mike Lothian]

Hi

I've just tested this with Nine. It causes a weird white strobing effect -
I think there are other graphical glitches too but it's hard to tell

I was testing the blizzard app http://eu.battle.net/en/app/ the same also
happens when World of Warcraft is launched

This doesn't happen if I use CSMT rather than Nine

Cheers

Mike

On Sat, 29 Apr 2017 at 00:12 Marek Olšák  wrote:

> Hi,
>
> This series shrinks various gallium structures and removes
> set_index_buffer in order to decrease CPU overhead.
>
>
> PART 1: Performance results
>
> All testing below was done with radeonsi, and I used the drawoverhead
> microbenchmark from mesa/demos ported to piglit and using GL 3.0
> Compat and GL 3.2 Core (same GL states in both contexts).
>
> 1) Performance difference for the removal of set_index_buffer only:
>
>   Compat: DrawElements: 5.1 -> 5.3 million draws/second
>   Core:   DrawElements: 5.1 -> 5.5 million draws/second
>
> The result is better for the core profile where u_vbuf is disabled.
>
>
> 2) Performance difference with all 4 patches (Core profile only)
>
>DrawArrays: 8.3 -> 8.5 million draws/second
>DrawElements: 5.2 -> 5.8 million draws/second
>
>
> 3) Performance difference with threaded Gallium (Core profile only):
>
>DrawElements: 5.9 -> 7.1 million draws/second
>
> Threaded Gallium is still work in progress and might require
> a non-trivial amount of driver work.
>
>
> PART 2: Call for testing
>
> These drivers have been tested:
> - ddebug
> - llvmpipe
> - r300 (also with SWTCL)
> - r600
> - radeonsi
> - softpipe
> - trace
>
> These drivers need testing:
> - etnaviv
> - freedreno
> - nv30
> - nv50
> - nvc0
> - svga
> - swr
> - vc4
> - virgl
>
> The following state trackers might need testing:
> - nine
>
> You can get the patches by fetching:
>   git://people.freedesktop.org/~mareko/mesa gallium-cleanup
>
> I'd like to ask to you for testing drivers that I couldn't test.
> Please let me know when you're done testing and if things are good.
> After that, I'll push everything assuming the code review goes well.
> You can also ignore this if you don't mind fixing your driver in
> the master branch later.
>
> Thanks,
>
> Marek
> ___
> 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] glsl: set vector_elements to 1 for samplers

[Samuel Pitoiset]

On 04/28/2017 08:40 PM, Mark Janes wrote:

Samuel Pitoiset  writes:


On 04/28/2017 06:58 PM, Mark Janes wrote:

With this commit, a wide range of intel hardware began hanging during
the GLES CTS, with dmesg errors like:

[25488.739167] traps: glcts[15106] general protection ip:7fdac6484ba5 
sp:7ffdcda85a20 error:0

Machines that did complete the cts, reported hundreds of errors like:

*** Error in `/tmp/build_root/m64/bin/es/cts/glcts': malloc(): memory
  corruption: 0x562c7503b270 ***


That's unfortunate. I don't have any Intel hw.


I can set up a CI build that will test your patches on Intel hardware.
Many non-Intel developers find that the exhaustive testing in our CI
alerts them to bugs in their patches.  It takes about 30 minutes to run.

Please give me a branch that you want to use for testing.  When you
force-push to that branch, a build will trigger.


Thanks. That will be very helpful to prevent such a thing to happen.




Kenneth is going to revert the patch for now.

Would be very nice if someone with the hardware could have a look.

Which tests are failing? Can you list some?


I put a list of failing piglit tests in
https://bugs.freedesktop.org/show_bug.cgi?id=100871





Samuel Pitoiset  writes:


I don't see any reasons why vector_elements is 1 for images and
0 for samplers. This increases consistency and allows to clean
up some code a bit.

This will also help for ARB_bindless_texture.

No piglit regressions with RadeonSI.

Signed-off-by: Samuel Pitoiset 
---
   src/compiler/glsl_types.cpp |  7 +--
   src/mesa/main/uniform_query.cpp | 15 +--
   2 files changed, 6 insertions(+), 16 deletions(-)

diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index 0480bef80e..bf078ad614 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -95,12 +95,7 @@ glsl_type::glsl_type(GLenum gl_type, glsl_base_type 
base_type,
   
  memset(& fields, 0, sizeof(fields));
   
-   if (is_sampler()) {

-  /* Samplers take no storage whatsoever. */
-  matrix_columns = vector_elements = 0;
-   } else {
-  matrix_columns = vector_elements = 1;
-   }
+   matrix_columns = vector_elements = 1;
   }
   
   glsl_type::glsl_type(const glsl_struct_field *fields, unsigned num_fields,

diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index e400d0eb00..114f6fb5be 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -321,8 +321,7 @@ _mesa_get_uniform(struct gl_context *ctx, GLuint program, 
GLint location,
  }
   
  {

-  unsigned elements = (uni->type->is_sampler())
-? 1 : uni->type->components();
+  unsigned elements = uni->type->components();
 const int dmul = uni->type->is_64bit() ? 2 : 1;
 const int rmul = glsl_base_type_is_64bit(returnType) ? 2 : 1;
   
@@ -648,10 +647,8 @@ _mesa_propagate_uniforms_to_driver_storage(struct gl_uniform_storage *uni,

   {
  unsigned i;
   
-   /* vector_elements and matrix_columns can be 0 for samplers.

-*/
-   const unsigned components = MAX2(1, uni->type->vector_elements);
-   const unsigned vectors = MAX2(1, uni->type->matrix_columns);
+   const unsigned components = uni->type->vector_elements;
+   const unsigned vectors = uni->type->matrix_columns;
  const int dmul = uni->type->is_64bit() ? 2 : 1;
   
  /* Store the data in the driver's requested type in the driver's storage

@@ -803,8 +800,7 @@ validate_uniform(GLint location, GLsizei count, const 
GLvoid *values,
  }
   
  /* Verify that the types are compatible. */

-   const unsigned components = uni->type->is_sampler()
-  ? 1 : uni->type->vector_elements;
+   const unsigned components = uni->type->vector_elements;
   
  if (components != src_components) {

 /* glUniformN() must match float/vecN type */
@@ -925,8 +921,7 @@ _mesa_uniform(GLint location, GLsizei count, const GLvoid 
*values,
return;
  }
   
-   const unsigned components = uni->type->is_sampler()

-  ? 1 : uni->type->vector_elements;
+   const unsigned components = uni->type->vector_elements;
   
  /* Page 82 (page 96 of the PDF) of the OpenGL 2.1 spec says:

   *
--
2.12.2

___
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] i965: Solve Android native fence fd double close issue

[Emil Velikov]

On 28 April 2017 at 17:18, Chad Versace  wrote:
> On Thu 27 Apr 2017, Emil Velikov wrote:
>> On 27 April 2017 at 12:14, Xu, Randy  wrote:
>> > Hi, Chad
>> >
>> > Please review this patch, we need it to solve some instability issues
>
> Randy and Tapani, could you provide a few dEQP test names that this
> patch fixes? I'd like to mention at least one EGL and one Vulkan test in
> the commit message.
>
>> The patch is correct, although the commit message can be improved upon.
>> Read through the following example and consider the alternative
>> solution mentioned within.
>
> Yes, this patch is correct. It makes brw_dri_create_fence_fd() behave
> like all the other drivers' create_fence_fd funcs, which call dup().
> Since this is an easy one-liner that can backport to stable, let's take
> it.
>
> However, I believe the fully correct solution is Emil's plan B:
> __DRI2fenceExtensionRec::create_fence_fd should transfer fd ownership to
> the driver, and therefore no dup is needed. But that's a slightly more
> invasive change that's not as easily backported to stable.
>
> Reviewed-by: Chad Versace 
> Cc: mesa-sta...@lists.freedesktop.org
>
> Emil, how about one of us appends your extended commit message to
> Randy's, and then pushes?
>
Feel free to polish and push Chad.

Randy please don't forget to send a patch for dri_interface.h.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] disk_cache: reduce default cache size to 5% of filesystem

[Kai Wasserbäch]

Hey,
Marek Olšák wrote on 29.04.2017 12:49:
> On Apr 29, 2017 11:27 AM, "Timothy Arceri"  wrote:
> On 29/04/17 18:44, Marek Olšák wrote:
>> [...]
>>
>> That's a good point. I didn't think of that. Still, if one game evicts all
>> entries, the cache may be almost as good as disabled.
>>
> 
> I'm happy for the default limit to be raised from 1GB. However as I replied
> in the other thread using a percentage is not a good idea at this stage IMO.
> 
> For the majority of use cases 1GB should be more than enough. Deus Ex is
> very shader heavy and when compressed it was only taking up ~30MB, so I
> wouldn't be to worried about entries getting evicted unless there is
> something on the system generating a boat load of unique shaders.
> 
> 
> 30MB is actually useful information that puts everything into perspective.
> Thanks.

just to give a bit more input here: I've been using the cache for a while now
and never cleared it manually after the unified directory structure came to be.
With several games, Wine (without nine) and various Superpositions runs
(different quality settings) – btw big thanks to the whole AMD team: I'm seeing
4043 points at 2560×1440 with medium quality settings and 2805 points with high
settings in that benchmark! – I just hit 133 MB as displayed by "du -hs" as of
today. Granted, there are a couple more MB for the user running the desktop
environment and the display manager, but last time I checked that was about 12 
MB.
And I should probably add that there are certainly stale cache files in there,
since I've rebuilt Mesa and LLVM several times.

Anyway a limit of 1 GB sounds fine by me.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] disk_cache: reduce default cache size to 5% of filesystem

[Marek Olšák]

On Apr 29, 2017 11:27 AM, "Timothy Arceri"  wrote:



On 29/04/17 18:44, Marek Olšák wrote:

>
>
> On Apr 29, 2017 4:20 AM, "Michel Dänzer" > wrote:
>
> On 28/04/17 09:11 PM, Marek Olšák wrote:
>  > On Thu, Apr 27, 2017 at 8:47 AM, Michel Dänzer
> > wrote:
>  >> On 27/04/17 10:15 AM, Timothy Arceri wrote:
>  >>> Modern disks are extremely large and are only going to get bigger.
>  >>> Usage has shown frequent Mesa upgrades can result in the cache
>  >>> growing very fast i.e. wasting a lot of disk space unnecessarily.
>  >>>
>  >>> 5% seems like a more reasonable default.
>  >>>
>  >>> Cc: "17.1"  >
>
>  >>> ---
>  >>>  src/util/disk_cache.c | 4 ++--
>  >>>  1 file changed, 2 insertions(+), 2 deletions(-)
>  >>>
>  >>> diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
>  >>> index d9de8ef..9fd7b96 100644
>  >>> --- a/src/util/disk_cache.c
>  >>> +++ b/src/util/disk_cache.c
>  >>> @@ -324,24 +324,24 @@ disk_cache_create(const char *gpu_name,
> const char *timestamp)
>  >>>   case '\0':
>  >>>   case 'G':
>  >>>   case 'g':
>  >>>   default:
>  >>>  max_size *= 1024*1024*1024;
>  >>>  break;
>  >>>   }
>  >>>}
>  >>> }
>  >>>
>  >>> -   /* Default to 1GB or 10% of filesystem for maximum cache
> size. */
>  >>> +   /* Default to 1GB or 5% of filesystem for maximum cache
> size. */
>  >>> if (max_size == 0) {
>  >>>statvfs(path, );
>  >>> -  max_size = MAX2(1024*1024*1024, vfs.f_blocks *
> vfs.f_bsize / 10);
>  >>> +  max_size = MAX2(1024*1024*1024, vfs.f_blocks *
> vfs.f_bsize / 20);
>  >>> }
>  >>
>  >> 5% can still be quite a lot (what if every library on the system
> tried
>  >> using that much for itself?). How about 1%?
>  >
>  > The argument is flawed. My ccache uses 12% (26.8 GB) of my disk, and
>  > I'm not saying "what if every small app used that much...". There
> is a
>  > very good reason for that size with my use case.
>
> ccache defaults to a maximum cache size of 5G. You had to explicitly
> allow it to use more; you can do the same with the Mesa shader cache.
>
>
>  > It certainly makes sense to use 5% of the filesystem for Mesa.
>
> I don't agree for the default, especially as long as the Mesa shader
> cache only actually makes use of about 10-20% of the disk space
> allocated for it, due to having a huge number of tiny files. (ccache in
> contrast actually makes good use of the disk space allocated for it,
> because its cache entries are normally larger than a single disk block)
>
>
> That's a good point. I didn't think of that. Still, if one game evicts all
> entries, the cache may be almost as good as disabled.
>

I'm happy for the default limit to be raised from 1GB. However as I replied
in the other thread using a percentage is not a good idea at this stage IMO.

For the majority of use cases 1GB should be more than enough. Deus Ex is
very shader heavy and when compressed it was only taking up ~30MB, so I
wouldn't be to worried about entries getting evicted unless there is
something on the system generating a boat load of unique shaders.


30MB is actually useful information that puts everything into perspective.
Thanks.

Marek





> Marek
>
>
>
> --
> 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

[Mesa-dev] [Bug 100882] dri2_lookup_egl_image crash dure to __DRIimageLookupExtension *loader is NULL

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100882

Bug ID: 100882
   Summary: dri2_lookup_egl_image crash dure to
__DRIimageLookupExtension *loader  is NULL
   Product: Mesa
   Version: 17.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: comicfan...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

when calling eglImageTargetTexture2DOES, mesa crash in dri2_lookup_egl_image

dri2.c:774

   const __DRIimageLookupExtension *loader = screen->sPriv->dri2.image;
   __DRIimage *img;

   if (!loader->lookupEGLImage)   >   loader is NULL
  return NULL;


backtrace shows as following:



#0  0x7f49673239f8 in dri2_lookup_egl_image (screen=,
handle=0x5) at dri2.c:774
#1  0x7f4967321ccb in dri_get_egl_image (smapi=,
egl_image=, stimg=0x7f49258108a0) at dri_screen.c:329
#2  0x7f49671e0a91 in st_manager_get_egl_image_surface (st=0x7f48f84b7a20,
eglimg=) at state_tracker/st_manager.c:850
#3  0x7f4967190336 in st_egl_image_target_texture_2d (ctx=0x7f48f8482f00,
target=, texObj=0x7f48f84c9900, 
texImage=0x7f48f84d3e00, image_handle=) at
state_tracker/st_cb_eglimage.c:165
#4  0x7f4967114ea6 in _mesa_EGLImageTargetTexture2DOES (target=3553,
image=0x5) at main/teximage.c:3194
#5  0x005629d2 in ColorBuffer::bindToTexture (this=0x7f4904400a30)
at
/home/comicfans/.cache/pacaur/anbox-git/src/anbox/src/anbox/graphics/emugl/ColorBuffer.cpp:319
#6  0x00510d9d in Renderer::bindColorBufferToTexture (this=0x1365c90,
p_colorbuffer=6)
at
/home/comicfans/.cache/pacaur/anbox-git/src/anbox/src/anbox/graphics/emugl/Renderer.cpp:592
#7  0x00580021 in renderControl_decoder_context_t::decode(void*,
unsigned long, IOStream*) ()
#8  0x004aa375 in RenderThread::main (this=0x7f4908001470)
at
/home/comicfans/.cache/pacaur/anbox-git/src/anbox/src/anbox/graphics/emugl/RenderThread.cpp:80
#9  0x00584291 in emugl::Thread::thread_main(void*) ()
#10 0x7f4973b9c2e7 in start_thread () from /usr/lib/libpthread.so.0
#11 0x7f4972ac654f in clone () from /usr/lib/libc.so.6


mesa version 17.0.4
with archlinux's patches (
https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/mesa)

while running application anbox

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] disk_cache: reduce default cache size to 5% of filesystem

[Timothy Arceri]

On 29/04/17 18:44, Marek Olšák wrote:



On Apr 29, 2017 4:20 AM, "Michel Dänzer" > wrote:


On 28/04/17 09:11 PM, Marek Olšák wrote:
 > On Thu, Apr 27, 2017 at 8:47 AM, Michel Dänzer
> wrote:
 >> On 27/04/17 10:15 AM, Timothy Arceri wrote:
 >>> Modern disks are extremely large and are only going to get bigger.
 >>> Usage has shown frequent Mesa upgrades can result in the cache
 >>> growing very fast i.e. wasting a lot of disk space unnecessarily.
 >>>
 >>> 5% seems like a more reasonable default.
 >>>
 >>> Cc: "17.1" >
 >>> ---
 >>>  src/util/disk_cache.c | 4 ++--
 >>>  1 file changed, 2 insertions(+), 2 deletions(-)
 >>>
 >>> diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
 >>> index d9de8ef..9fd7b96 100644
 >>> --- a/src/util/disk_cache.c
 >>> +++ b/src/util/disk_cache.c
 >>> @@ -324,24 +324,24 @@ disk_cache_create(const char *gpu_name,
const char *timestamp)
 >>>   case '\0':
 >>>   case 'G':
 >>>   case 'g':
 >>>   default:
 >>>  max_size *= 1024*1024*1024;
 >>>  break;
 >>>   }
 >>>}
 >>> }
 >>>
 >>> -   /* Default to 1GB or 10% of filesystem for maximum cache
size. */
 >>> +   /* Default to 1GB or 5% of filesystem for maximum cache
size. */
 >>> if (max_size == 0) {
 >>>statvfs(path, );
 >>> -  max_size = MAX2(1024*1024*1024, vfs.f_blocks *
vfs.f_bsize / 10);
 >>> +  max_size = MAX2(1024*1024*1024, vfs.f_blocks *
vfs.f_bsize / 20);
 >>> }
 >>
 >> 5% can still be quite a lot (what if every library on the system
tried
 >> using that much for itself?). How about 1%?
 >
 > The argument is flawed. My ccache uses 12% (26.8 GB) of my disk, and
 > I'm not saying "what if every small app used that much...". There
is a
 > very good reason for that size with my use case.

ccache defaults to a maximum cache size of 5G. You had to explicitly
allow it to use more; you can do the same with the Mesa shader cache.


 > It certainly makes sense to use 5% of the filesystem for Mesa.

I don't agree for the default, especially as long as the Mesa shader
cache only actually makes use of about 10-20% of the disk space
allocated for it, due to having a huge number of tiny files. (ccache in
contrast actually makes good use of the disk space allocated for it,
because its cache entries are normally larger than a single disk block)


That's a good point. I didn't think of that. Still, if one game evicts 
all entries, the cache may be almost as good as disabled.


I'm happy for the default limit to be raised from 1GB. However as I 
replied in the other thread using a percentage is not a good idea at 
this stage IMO.


For the majority of use cases 1GB should be more than enough. Deus Ex is 
very shader heavy and when compressed it was only taking up ~30MB, so I 
wouldn't be to worried about entries getting evicted unless there is 
something on the system generating a boat load of unique shaders.





Marek



--
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] util/disk_cache: remove percentage based max cache limit

[Timothy Arceri]

On 28/04/17 22:29, Marek Olšák wrote:

On Fri, Apr 28, 2017 at 5:05 AM, Timothy Arceri  wrote:

The more I think about it the more this seems like a bad idea.
When we were deleting old cache dirs this wasn't so bad as it
was unlikely we would ever hit the actual limit before things
were cleaned up. Now that we only start cleaning up old cache
items once the limit is reached the a percentage based max
cache limit is more risky.

For the inital release of shader cache I think its better to
stick to a more conservative cache limit, at least until we
have some way of cleaning up the cache more aggressively.


See my comment in the other thread. Also, what's wrong with hitting
the limit? Isn't hitting the limit actually the main point of the
cache?


Right, hitting a limit is fine. The problem is using percentage is
arbitrary, one system it may be 10GB on another 200GB which is a 
ridiculous size.


The point I was trying to make was that I was ok with the effectively 
unreachable cache limit when we were cleaning things up. Now that we 
will actually approach the limit I can only see bad things happening, 
bug reports, distros disabling the cache, etc.


More comments on the other thread.



Marek


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

Re: [Mesa-dev] [PATCH kmscube 1/2] common: use %llx to print modifier

[Lucas Stach]

Am Freitag, den 28.04.2017, 14:17 -0400 schrieb Rob Clark:
> I guess this applies on top of one of Ben's in-flight patches?
> Perhaps it can be squashed into that?  (Otherwise remind me about
> this
> when the modifiers patchset is merged)

It applies on top of what is currently in FDO mesa/kmscube. It seems
the modifier patchset has been merged there.

Regards,
Lucas

> BR,
> -R
> 
> On Fri, Apr 28, 2017 at 12:18 PM, Lucas Stach  > wrote:
> > Use long long format when printing the format modifier, as a simple
> > long is only 4 bytes on 32bit systems.
> > 
> > Signed-off-by: Lucas Stach 
> > ---
> >  drm-common.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drm-common.c b/drm-common.c
> > index 2f2c918596a4..fb4ec7f4389e 100644
> > --- a/drm-common.c
> > +++ b/drm-common.c
> > @@ -73,7 +73,7 @@ struct drm_fb * drm_fb_get_from_bo(struct gbm_bo
> > *bo)
> > 
> > if (modifiers[0]) {
> > flags = DRM_MODE_FB_MODIFIERS;
> > -   printf("Using modifier %lx\n", modifiers[0]);
> > +   printf("Using modifier %llx\n", modifiers[0]);
> > }
> > 
> > ret = drmModeAddFB2WithModifiers(drm_fd, width, height,
> > --
> > 2.11.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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] disk_cache: reduce default cache size to 5% of filesystem

[Marek Olšák]

On Apr 29, 2017 4:20 AM, "Michel Dänzer"  wrote:

On 28/04/17 09:11 PM, Marek Olšák wrote:
> On Thu, Apr 27, 2017 at 8:47 AM, Michel Dänzer  wrote:
>> On 27/04/17 10:15 AM, Timothy Arceri wrote:
>>> Modern disks are extremely large and are only going to get bigger.
>>> Usage has shown frequent Mesa upgrades can result in the cache
>>> growing very fast i.e. wasting a lot of disk space unnecessarily.
>>>
>>> 5% seems like a more reasonable default.
>>>
>>> Cc: "17.1" 
>>> ---
>>>  src/util/disk_cache.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
>>> index d9de8ef..9fd7b96 100644
>>> --- a/src/util/disk_cache.c
>>> +++ b/src/util/disk_cache.c
>>> @@ -324,24 +324,24 @@ disk_cache_create(const char *gpu_name, const
char *timestamp)
>>>   case '\0':
>>>   case 'G':
>>>   case 'g':
>>>   default:
>>>  max_size *= 1024*1024*1024;
>>>  break;
>>>   }
>>>}
>>> }
>>>
>>> -   /* Default to 1GB or 10% of filesystem for maximum cache size. */
>>> +   /* Default to 1GB or 5% of filesystem for maximum cache size. */
>>> if (max_size == 0) {
>>>statvfs(path, );
>>> -  max_size = MAX2(1024*1024*1024, vfs.f_blocks * vfs.f_bsize / 10);
>>> +  max_size = MAX2(1024*1024*1024, vfs.f_blocks * vfs.f_bsize / 20);
>>> }
>>
>> 5% can still be quite a lot (what if every library on the system tried
>> using that much for itself?). How about 1%?
>
> The argument is flawed. My ccache uses 12% (26.8 GB) of my disk, and
> I'm not saying "what if every small app used that much...". There is a
> very good reason for that size with my use case.

ccache defaults to a maximum cache size of 5G. You had to explicitly
allow it to use more; you can do the same with the Mesa shader cache.


> It certainly makes sense to use 5% of the filesystem for Mesa.

I don't agree for the default, especially as long as the Mesa shader
cache only actually makes use of about 10-20% of the disk space
allocated for it, due to having a huge number of tiny files. (ccache in
contrast actually makes good use of the disk space allocated for it,
because its cache entries are normally larger than a single disk block)


That's a good point. I didn't think of that. Still, if one game evicts all
entries, the cache may be almost as good as disabled.

Marek



--
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

[Mesa-dev] [Bug 100690] [Regression, bisected] TotalWar: Warhammer corrupted graphics

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100690

--- Comment #9 from talonz  ---
Just tested the patch ... while not fixing the problem completely it has fixed
the graphic glitches replacing the red and green squares with minor graphic
glitches on the campaign map and on the battle map it has completely resolved
my issue of large red blocks on the grass, i will post screenshots soon to
better explain what i mean

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

[Mesa-dev] [Bug 100876] Variable GALLIUM_HUD_DUMP_DIR is not working with Wine LFS

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100876

--- Comment #3 from Balázs Vinarz  ---
The current patch is sending the data line-by-line instead of sending the whole
output at the exit. Right?
Maybe the exit status won't affect the data generation.

-- 
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