[Mesa-dev] [Bug 107994] driinfo_gallium.h:32:72: error: expected '; ' after top level declarator

[bugzilla-daemon]

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

Bug ID: 107994
   Summary: driinfo_gallium.h:32:72: error: expected ';' after top
level declarator
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Mac OS X (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org

meson build error on macOS

$ meson builddir -Degl=false
$ ninja -C builddir
[...]
In file included from ../src/gallium/auxiliary/pipe-loader/pipe_loader.c:55:
../src/gallium/auxiliary/pipe-loader/driinfo_gallium.h:32:72: error: expected
';' after top level declarator
   DRI_CONF_ALLOW_GLSL_LAYOUT_QUALIFIER_ON_FUNCTION_PARAMETERS("false")
   ^
   ;

-- 
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 107870] Undefined symbols for architecture x86_64: "_util_cpu_caps"

[bugzilla-daemon]

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

Vinson Lee  changed:

   What|Removed |Added

   Keywords||bisected

--- Comment #2 from Vinson Lee  ---
commit 80825abb5d1a7491035880253ffd531c55acae6b
Author: Dylan Baker 
Date:   Thu Aug 16 17:20:38 2018 -0700

move u_math to src/util

Currently we have two sets of functions for bit counts, one in gallium
and one in core mesa. The ones in core mesa are header only in many
cases, since they reduce to "#define _mesa_bitcount popcount", but they
provide a fallback implementation. This is important because 32bit msvc
doesn't have popcountll, just popcount; so when nir (for example)
includes the core mesa header it doesn't (and shouldn't) link with core
mesa. To fix this we'll promote the version out of gallium util, then
replace the core mesa uses with the util version, since nir (and other
non-core mesa users) can and do link with mesautils.

Acked-by: Eric Engestrom 
Reviewed-by: Ian Romanick 

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

[Mesa-dev] [PATCH 2/4] freedreno: don't do flush unless needed.

[Hyunjun Ko]

The commit 4b847b38 introduced some crashes of deqp gles31 cts,
since it always tries to flush if the flag flushed is false, which
is the initial state.

This sometimes makes it trying unnecessary drawing when context is
being destroyed for example.

Fixes: 
dEQP-GLES31.functional.fbo.no_attachments.interaction.17x512ms4_default_16x16ms2
and other 5 relevant cts.
---
 src/gallium/drivers/freedreno/freedreno_batch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/freedreno/freedreno_batch.c 
b/src/gallium/drivers/freedreno/freedreno_batch.c
index ff8298e82a..8c9439bb9a 100644
--- a/src/gallium/drivers/freedreno/freedreno_batch.c
+++ b/src/gallium/drivers/freedreno/freedreno_batch.c
@@ -286,7 +286,7 @@ batch_flush(struct fd_batch *batch, bool force)
 {
DBG("%p: needs_flush=%d", batch, batch->needs_flush);
 
-   if (batch->flushed)
+   if (!batch->needs_flush || batch->flushed)
return;
 
batch->needs_flush = false;
-- 
2.17.1

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

[Mesa-dev] [PATCH 2/4] freedreno: don't do flush unless needed.

[Hyunjun Ko]

The commit 4b847b38 introduced some crashes of deqp gles31 cts,
since it always tries to flush if the flag flushed is false, which
is the initial state.

This sometimes makes it trying unnecessary drawing when context is
being destroyed for example.

Fixes: 
dEQP-GLES31.functional.fbo.no_attachments.interaction.17x512ms4_default_16x16ms2
and other 5 relevant cts.
---
 src/gallium/drivers/freedreno/freedreno_batch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/freedreno/freedreno_batch.c 
b/src/gallium/drivers/freedreno/freedreno_batch.c
index ff8298e82a..8c9439bb9a 100644
--- a/src/gallium/drivers/freedreno/freedreno_batch.c
+++ b/src/gallium/drivers/freedreno/freedreno_batch.c
@@ -286,7 +286,7 @@ batch_flush(struct fd_batch *batch, bool force)
 {
DBG("%p: needs_flush=%d", batch, batch->needs_flush);
 
-   if (batch->flushed)
+   if (!batch->needs_flush || batch->flushed)
return;
 
batch->needs_flush = false;
-- 
2.17.1

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

[Mesa-dev] [PATCH] pci_ids: add new polaris pci id

[Alex Deucher]

Signed-off-by: Alex Deucher 
Cc: mesa-sta...@lists.freedesktop.org
---
 include/pci_ids/radeonsi_pci_ids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/pci_ids/radeonsi_pci_ids.h 
b/include/pci_ids/radeonsi_pci_ids.h
index c8d30597230..dd2fc3b8f25 100644
--- a/include/pci_ids/radeonsi_pci_ids.h
+++ b/include/pci_ids/radeonsi_pci_ids.h
@@ -204,6 +204,7 @@ CHIPSET(0x67CC, POLARIS10)
 CHIPSET(0x67CF, POLARIS10)
 CHIPSET(0x67D0, POLARIS10)
 CHIPSET(0x67DF, POLARIS10)
+CHIPSET(0x6FDF, POLARIS10)
 
 CHIPSET(0x98E4, STONEY)
 
-- 
2.13.6

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

[Mesa-dev] [PATCH 4/4] freedreno: fix a typo in launch_grid

[Hyunjun Ko]

---
 src/gallium/drivers/freedreno/freedreno_draw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/freedreno/freedreno_draw.c 
b/src/gallium/drivers/freedreno/freedreno_draw.c
index 0a472c78b1..0b7f9ffe5e 100644
--- a/src/gallium/drivers/freedreno/freedreno_draw.c
+++ b/src/gallium/drivers/freedreno/freedreno_draw.c
@@ -467,7 +467,7 @@ fd_launch_grid(struct pipe_context *pctx, const struct 
pipe_grid_info *info)
 * read vs written, so just assume the worst
 */
foreach_bit(i, ctx->shaderbuf[PIPE_SHADER_COMPUTE].enabled_mask)
-   resource_read(batch, 
ctx->shaderbuf[PIPE_SHADER_COMPUTE].sb[i].buffer);
+   resource_written(batch, 
ctx->shaderbuf[PIPE_SHADER_COMPUTE].sb[i].buffer);
 
foreach_bit(i, ctx->shaderimg[PIPE_SHADER_COMPUTE].enabled_mask) {
struct pipe_image_view *img =
-- 
2.17.1

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

[Mesa-dev] [PATCH 3/4] freedreno: synchronize when flushing batches in launch_grid

[Hyunjun Ko]

Since the commit 4b847b38 landed, there has been a race condition in
launch_grid, which is between fdX_launch_grid and rendering in batch flush.

This leads many cts to unstable results, especially for those using
compute shader.

Fixes: many cts for compute shader including dEQP-GLES31.functional.compute.*
---
 src/gallium/drivers/freedreno/freedreno_draw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/freedreno/freedreno_draw.c 
b/src/gallium/drivers/freedreno/freedreno_draw.c
index f55905e7bf..0a472c78b1 100644
--- a/src/gallium/drivers/freedreno/freedreno_draw.c
+++ b/src/gallium/drivers/freedreno/freedreno_draw.c
@@ -500,7 +500,8 @@ fd_launch_grid(struct pipe_context *pctx, const struct 
pipe_grid_info *info)
batch->needs_flush = true;
ctx->launch_grid(ctx, info);
 
-   fd_batch_flush(batch, false, false);
+   /* TODO: flush with sync might affect performance, need to get improved 
*/
+   fd_batch_flush(batch, true, false);
 
fd_batch_reference(>batch, save_batch);
fd_batch_reference(_batch, NULL);
-- 
2.17.1

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

[Mesa-dev] [PATCH 1/4] freedreno/ir3: fix the param order of cmpxchg

[Hyunjun Ko]

According to the following definition,
int AtomicCompSwap(inout int mem, uint compare, uint data);

the preceding one in atomic_comp_swap of NIR is compare and data is
followed, while src0 for cmpxchg needs vec2(data, compare)
So for ssbo/image deref comp_swap, that should be reversed.

Fixes: dEQP-GLES31.functional.image_load_store.*.atomic.comp_swap*
---
 src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c 
b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
index 79314140d8..8f749f4110 100644
--- a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
+++ b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
@@ -1626,8 +1626,8 @@ emit_intrinsic_atomic_ssbo(struct ir3_context *ctx, 
nir_intrinsic_instr *intr)
case nir_intrinsic_ssbo_atomic_comp_swap:
/* for cmpxchg, src0 is [ui]vec2(data, compare): */
src0 = create_collect(ctx, (struct ir3_instruction*[]){
-   src0,
get_src(ctx, >src[3])[0],
+   src0,
}, 2);
atomic = ir3_ATOMIC_CMPXCHG_G(b, ssbo, 0, src0, 0, src1, 0, 
src2, 0);
break;
@@ -2095,8 +2095,8 @@ emit_intrinsic_atomic_image(struct ir3_context *ctx, 
nir_intrinsic_instr *intr)
case nir_intrinsic_image_deref_atomic_comp_swap:
/* for cmpxchg, src0 is [ui]vec2(data, compare): */
src0 = create_collect(ctx, (struct ir3_instruction*[]){
-   src0,
get_src(ctx, >src[4])[0],
+   src0,
}, 2);
atomic = ir3_ATOMIC_CMPXCHG_G(b, image, 0, src0, 0, src1, 0, 
src2, 0);
break;
-- 
2.17.1

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

[Mesa-dev] [PATCH 2/4] freedreno: don't do flush unless needed.

[Hyunjun Ko]

The commit 4b847b38 introduced some crashes of deqp gles31 cts,
since it always tries to flush if the flag flushed is false, which
is the initial state.

This sometimes makes it trying unnecessary drawing when context is
being destroyed for example.

Fixes: 
dEQP-GLES31.functional.fbo.no_attachments.interaction.17x512ms4_default_16x16ms2
and other 5 relevant cts.
---
 src/gallium/drivers/freedreno/freedreno_batch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/freedreno/freedreno_batch.c 
b/src/gallium/drivers/freedreno/freedreno_batch.c
index ff8298e82a..987348a09f 100644
--- a/src/gallium/drivers/freedreno/freedreno_batch.c
+++ b/src/gallium/drivers/freedreno/freedreno_batch.c
@@ -286,7 +286,7 @@ batch_flush(struct fd_batch *batch, bool force)
 {
DBG("%p: needs_flush=%d", batch, batch->needs_flush);
 
-   if (batch->flushed)
+   if (!batch->needs_flush || bathc->flushed)
return;
 
batch->needs_flush = false;
-- 
2.17.1

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

[Mesa-dev] [PATCH 0/4] fix crashes and failures of deqp gles31

[Hyunjun Ko]

This series fixes crashes/failures of tests from deqp gles31 on freedreno.
Thanks for review.

Hyunjun Ko (4):
  freedreno/ir3: fix the param order of cmpxchg
  freedreno: don't do flush unless needed.
  freedreno: synchronize when flushing batches in launch_grid
  freedreno: fix a typo in launch_grid

 src/gallium/drivers/freedreno/freedreno_batch.c  | 2 +-
 src/gallium/drivers/freedreno/freedreno_draw.c   | 5 +++--
 src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c | 4 ++--
 3 files changed, 6 insertions(+), 5 deletions(-)

-- 
2.17.1

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

[Mesa-dev] [Bug 106996] Compiler diagnostic for sampler declared as "out" parameter of function is terrible

[bugzilla-daemon]

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

--- Comment #3 from Ilia Mirkin  ---
(In reply to Ian Romanick from comment #2)
> sampler variables cannot be assigned, so it's impossible for it to be an out
> parameter.

FWIW they can be with bindless. But then the expectation would be that the
function does something like "dst = src" or something.

-- 
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 V2 6/6] util: disable cache if we have no build-id and timestamp is zero

[Bas Nieuwenhuizen]

R-b

On Thu, 20 Sep 2018, 00:54 Timothy Arceri,  wrote:

> Timestamp can be zero for example when Flatpak is used. In this
> case just disable the cache rather then segfaulting when
> incompatible cache items are loaded.
>
> V2: actually return false when mtime is 0.
> ---
>  src/amd/vulkan/radv_device.c | 4 
>  src/util/disk_cache.h| 8 
>  2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index f9169d9d012..7d915c68aaa 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -61,10 +61,6 @@ radv_get_build_id(void *ptr, struct mesa_sha1 *ctx)
> } else
>  #endif
> if (disk_cache_get_function_timestamp(ptr, )) {
> -   if (!timestamp) {
> -   fprintf(stderr, "radv: The provided filesystem
> timestamp for the cache is bogus!\n");
> -   }
> -
> _mesa_sha1_update(ctx, , sizeof(timestamp));
> } else
> return false;
> diff --git a/src/util/disk_cache.h b/src/util/disk_cache.h
> index 962a26ffc8c..185e05f200e 100644
> --- a/src/util/disk_cache.h
> +++ b/src/util/disk_cache.h
> @@ -101,7 +101,15 @@ disk_cache_get_function_timestamp(void *ptr,
> uint32_t* timestamp)
> if (stat(info.dli_fname, )) {
>return false;
> }
> +
> +   if (!st.st_mtime) {
> +  fprintf(stderr, "Mesa: The provided filesystem timestamp for the
> cache "
> +  "is bogus! Disabling On-disk cache.\n");
> +  return false;
> +   }
> +
> *timestamp = st.st_mtime;
> +
> return true;
>  }
>
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH V2 6/6] util: disable cache if we have no build-id and timestamp is zero

[Timothy Arceri]

Timestamp can be zero for example when Flatpak is used. In this
case just disable the cache rather then segfaulting when
incompatible cache items are loaded.

V2: actually return false when mtime is 0.
---
 src/amd/vulkan/radv_device.c | 4 
 src/util/disk_cache.h| 8 
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index f9169d9d012..7d915c68aaa 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -61,10 +61,6 @@ radv_get_build_id(void *ptr, struct mesa_sha1 *ctx)
} else
 #endif
if (disk_cache_get_function_timestamp(ptr, )) {
-   if (!timestamp) {
-   fprintf(stderr, "radv: The provided filesystem 
timestamp for the cache is bogus!\n");
-   }
-
_mesa_sha1_update(ctx, , sizeof(timestamp));
} else
return false;
diff --git a/src/util/disk_cache.h b/src/util/disk_cache.h
index 962a26ffc8c..185e05f200e 100644
--- a/src/util/disk_cache.h
+++ b/src/util/disk_cache.h
@@ -101,7 +101,15 @@ disk_cache_get_function_timestamp(void *ptr, uint32_t* 
timestamp)
if (stat(info.dli_fname, )) {
   return false;
}
+
+   if (!st.st_mtime) {
+  fprintf(stderr, "Mesa: The provided filesystem timestamp for the cache "
+  "is bogus! Disabling On-disk cache.\n");
+  return false;
+   }
+
*timestamp = st.st_mtime;
+
return true;
 }
 
-- 
2.17.1

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

[Mesa-dev] [Bug 107547] shader crashing glsl_compiler (uniform block assigned to vec2, then component substraced by 1)

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #5 from Timothy Arceri  ---
Should be fixed by:

commit 6f3c7374b11299c21d829db794fad3b756af60fb
Author: Danylo Piliaiev 
Date:   Wed Aug 15 15:46:22 2018 +0300

Date:   Wed Aug 15 15:46:22 2018 +0300

glsl: Avoid propagating incompatible type of initializer

do_assignment validated assigment but when rhs type was not compatible
it proceeded without issues and returned error_emitted = false.
On the other hand process_initializer expected do_assignment to always
return compatible type and never fail.

As a result when variable was initialized with incompatible type
the type of variable changed to the incompatible one.
This manifested in unnecessary error messages and in one case in crash.

Example GLSL:
 vec4 tmp = vec2(0.0);
 tmp.z -= 1.0;

Past error messages:
 initializer of type vec2 cannot be assigned to variable of type vec4
 invalid swizzle / mask `z'
 type mismatch
 operands to arithmetic operators must be numeric

After this patch:
 initializer of type vec2 cannot be assigned to variable of type vec4

In the other case when we initialize variable with incompatible struct,
accessing variable's field leaded to a crash. Example:
 uniform struct {float field;} data;
 ...
 vec4 tmp = data;
 tmp.x -= 1.0;

After the patch there is only error line without a crash:
 initializer of type #anon_struct cannot be assigned to variable of
  type vec4

Signed-off-by: Danylo Piliaiev 
Reviewed-by: Timothy Arceri 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107547

-- 
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 19/26] nir/linker: use only the array element type for array of ssbo/ubo

[Timothy Arceri]

On 19/9/18 11:10 pm, Alejandro Piñeiro wrote:


On 19/09/18 14:09, Timothy Arceri wrote:

On 19/9/18 7:59 pm, Alejandro Piñeiro wrote:

On 19/09/18 07:20, Timothy Arceri wrote:

On 16/9/18 2:18 am, Alejandro Piñeiro wrote:

For this interfaces, the inner members are added only once as uniforms
or resources, in opposite to other cases, like a uniform array of
structs.
---
    src/compiler/glsl/gl_nir_link_uniforms.c | 26
--
    1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/gl_nir_link_uniforms.c
b/src/compiler/glsl/gl_nir_link_uniforms.c
index 00995fb3f76..c692cd0171f 100644
--- a/src/compiler/glsl/gl_nir_link_uniforms.c
+++ b/src/compiler/glsl/gl_nir_link_uniforms.c
@@ -498,11 +498,33 @@ gl_nir_link_uniforms(struct gl_context *ctx,
       state.current_var = var;
    + /*
+  * From OpenGL 4.6 spec, section 7.3.1.1, "Naming Active
Resources":
+  *
+  *   "* For an active shader storage block member declared
as an
+  *  array of an aggregate type, an entry will be
generated only
+  *  for the first array element, regardless of its
type. Such
+  *  block members are referred to as top-level arrays.
If the
+  *  block member is an aggregate type, the enumeration
rules are
+  *  then applied recursively.
+  *    * For an active interface block not declared as an
array of
+  *  block instances, a single entry will be generated,
using the
+  *  block name from the shader source."
+  *
+  * So for the UBO and SSBO case, we expand only the array
element
+  * type.
+  */
+ const struct glsl_type *type = var->type;
+ if (nir_variable_is_in_block(var) &&
+ glsl_type_is_array(type)) {
+    type = glsl_get_array_element(type);


This also strips away vector and matrix type information while leaving
arrays for anything but a single dimension array.


Well, but the idea behind this patch is getting a single dimension
array.


I think you mean getting a single element of an array?


Perhaps.




We are using the type to populate the uniforms, and as mentioned
on the spec quote, for ubo/ssbo and recursively for his entries, it is
done just once, no matter the dimension of the ubo/ssbo array.

Also not sure why do you mean that we would lose matrix and vector type
information. Could you give an example.


The code for glsl_get_array_element() is:

const glsl_type *
glsl_get_array_element(const glsl_type* type)
{
    if (type->is_matrix())
   return type->column_type();
    else if (type->is_vector())
   return type->get_scalar_type();
    return type->fields.array;
}

I was thinking you might end up stripping away the vec and matrix type
but as you have glsl_type_is_array(type) in the if condition it is fine.


Ok.





FWIW, this patch is needed to get this test working:
https://github.com/Igalia/piglit/blob/arb_gl_spirv-series5-ubo-ssbo-v1/tests/spec/arb_gl_spirv/execution/ubo/array-complex.shader_test


and just in case, I have just writing a similar test, slightly more
complex, but with array members and array of matrices members:

https://github.com/Igalia/piglit/blob/arb_gl_spirv-series5-ubo-ssbo-v1/tests/spec/arb_gl_spirv/execution/ubo/array-complex-2.shader_test


And the uniform and variable count is the same on both GLSL and SPIR-V.



Are you sure you don't want the following instead?

type = glsl_get_array_element(type);


Sorry, but isn't that what we are already doing? Or do you mean that we
should made the call always, without the is_in_block and is_array
checks?


Apologizes I pasted the wrong thing I meant:

   type = glsl_without_array(type);


Ok, later today, or tomorrow, I will try with this one.


As I said below on closer look I don't actually think this is what you 
want.






However looking more closely at the code and the spec I see that's not
what you want.

However I'm starting to think the quote from the spec and this code
have nothing to do with each other.


Yes, probably the spec quote is not the best one. We know what the
behaviour should be (based on comments at the GLSL linker, how
uniformstorage is populated on GLSL, and the program interface queries),
so I thought that was the spec quote justifying it. Now that you mention
it, and re-reading, it is true that's not perhaps the best quote
justifying it.



The spec is taking about top level block member arrays. For example:

layout (std140, binding = 5, row_major) uniform ComponentsBlock
  {
     float c1[3];
} components;

However neither of the examples you gave have top level arrays:

layout (std140, binding = 5, row_major) uniform ComponentsBlock
  {
     float c1;
     vec2 c2;
     S s;
} components[2];

My guess is you are using this to remove the array from the block
itself which is applied when the block is split into separate vars.
However the logic in this patch 

Re: [Mesa-dev] [PATCH 1/4] nir: Add a small pass to rematerialize derefs per-block

[Jason Ekstrand]

Looks good

On September 19, 2018 22:18:56 "Juan A. Suarez Romero" 
 wrote:



On Mon, 2018-09-17 at 09:43 -0500, Jason Ekstrand wrote:

This pass re-materializes deref instructions on a per-block basis to
ensure that every use of a deref occurs in the same block as the
instruction which uses it.


Hello!

This patch was commited CCing to 18.2 stable branch.

This patch didn't apply cleanly on 18.2 branch, so I've fixed the conflicts.

Besides this, I've initialized struct variable explicitly to "{ 0 }", 
instead of

"{ }", as this was causing an error when building with MSVC.

You can find the patch commited at


https://gitlab.freedesktop.org/mesa/mesa/commit/f1305c32c1cd4f7c59ef5dfb2eac9edabc70


The change I did is in line 375.

Feel free to check if there are any error.

Thanks in advance!

J.A.


---
 src/compiler/nir/nir.h   |   1 +
 src/compiler/nir/nir_deref.c | 132 +++
 2 files changed, 133 insertions(+)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 599f469a714..e0df95c391c 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -3012,6 +3012,7 @@ bool nir_convert_from_ssa(nir_shader *shader, bool 
phi_webs_only);


 bool nir_lower_phis_to_regs_block(nir_block *block);
 bool nir_lower_ssa_defs_to_regs_block(nir_block *block);
+bool nir_rematerialize_derefs_in_use_blocks_impl(nir_function_impl *impl);

 bool nir_opt_algebraic(nir_shader *shader);
 bool nir_opt_algebraic_before_ffma(nir_shader *shader);
diff --git a/src/compiler/nir/nir_deref.c b/src/compiler/nir/nir_deref.c
index 097ea8f1046..87a54790c95 100644
--- a/src/compiler/nir/nir_deref.c
+++ b/src/compiler/nir/nir_deref.c
@@ -24,6 +24,7 @@
 #include "nir.h"
 #include "nir_builder.h"
 #include "nir_deref.h"
+#include "util/hash_table.h"

 void
 nir_deref_path_init(nir_deref_path *path,
@@ -379,3 +380,134 @@ nir_compare_derefs(nir_deref_instr *a, 
nir_deref_instr *b)


return result;
 }
+
+struct rematerialize_deref_state {
+   bool progress;
+   nir_builder builder;
+   nir_block *block;
+   struct hash_table *cache;
+};
+
+static nir_deref_instr *
+rematerialize_deref_in_block(nir_deref_instr *deref,
+ struct rematerialize_deref_state *state)
+{
+   if (deref->instr.block == state->block)
+  return deref;
+
+   if (!state->cache) {
+  state->cache= _mesa_hash_table_create(NULL, _mesa_hash_pointer,
+_mesa_key_pointer_equal);
+   }
+
+   struct hash_entry *cached = _mesa_hash_table_search(state->cache, deref);
+   if (cached)
+  return cached->data;
+
+   nir_builder *b = >builder;
+   nir_deref_instr *new_deref =
+  nir_deref_instr_create(b->shader, deref->deref_type);
+   new_deref->mode = deref->mode;
+   new_deref->type = deref->type;
+
+   if (deref->deref_type == nir_deref_type_var) {
+  new_deref->var = deref->var;
+   } else {
+  nir_deref_instr *parent = nir_src_as_deref(deref->parent);
+  if (parent) {
+ parent = rematerialize_deref_in_block(parent, state);
+ new_deref->parent = nir_src_for_ssa(>dest.ssa);
+  } else {
+ nir_src_copy(_deref->parent, >parent, new_deref);
+  }
+   }
+
+   switch (deref->deref_type) {
+   case nir_deref_type_var:
+   case nir_deref_type_array_wildcard:
+   case nir_deref_type_cast:
+  /* Nothing more to do */
+  break;
+
+   case nir_deref_type_array:
+  assert(!nir_src_as_deref(deref->arr.index));
+  nir_src_copy(_deref->arr.index, >arr.index, new_deref);
+  break;
+
+   case nir_deref_type_struct:
+  new_deref->strct.index = deref->strct.index;
+  break;
+
+   default:
+  unreachable("Invalid deref instruction type");
+   }
+
+   nir_ssa_dest_init(_deref->instr, _deref->dest,
+ deref->dest.ssa.num_components,
+ deref->dest.ssa.bit_size,
+ deref->dest.ssa.name);
+   nir_builder_instr_insert(b, _deref->instr);
+
+   return new_deref;
+}
+
+static bool
+rematerialize_deref_src(nir_src *src, void *_state)
+{
+   struct rematerialize_deref_state *state = _state;
+
+   nir_deref_instr *deref = nir_src_as_deref(*src);
+   if (!deref)
+  return true;
+
+   nir_deref_instr *block_deref = rematerialize_deref_in_block(deref, state);
+
+   nir_instr_rewrite_src(src->parent_instr, src,
+ nir_src_for_ssa(_deref->dest.ssa));
+   nir_deref_instr_remove_if_unused(deref);
+   state->progress = true;
+
+   return true;
+}
+
+/** Re-materialize derefs in every block
+ *
+ * This pass re-materializes deref instructions in every block in which it is
+ * used.  After this pass has been run, every use of a deref will be of a
+ * deref in the same block as the use.  Also, all unused derefs will be
+ * deleted as a side-effect.
+ */
+bool
+nir_rematerialize_derefs_in_use_blocks_impl(nir_function_impl *impl)
+{
+   struct rematerialize_deref_state state = { };
+   nir_builder_init(, impl);
+
+ 

Re: [Mesa-dev] [PATCH] docs: Update FAQ with respect to s3tc support

[Adam Jackson]

On Wed, 2018-09-19 at 18:28 +1000, Stuart Young wrote:

> -4.3 Why isn't GL_EXT_texture_compression_s3tc implemented in Mesa?
> +4.3 The GL_EXT_texture_compression_s3tc feature and Mesa?

This isn't really a question, so probably shouldn't end with a question
mark. I would leave the original question in place and...

>  
> -The  href="http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt;>specification
>  for the extension
> -indicates that there are intellectual property (IP) and/or patent issues
> -to be dealt with.
> +Prior to 2nd October 2017, the Mesa project did not include s3tc support due
> +to intellectual property (IP) and/or patent issues around the s3tc algorithm.
>  

... phrase it positively here, as in: "Oh, but it is! Prior to..."

With that:

Reviewed-by: Adam Jackson 

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

[Mesa-dev] [ANNOUNCE] Mesa 18.2.1 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 18.2.1 is now available. Currently we have:
 - 57 queued (+1 squashed)
 - 0 nominated (outstanding)
 - and 2 rejected patches

The current queue consists of:

Vulkan headers are now updated to 1.1.84.

Lot of fixes for Vulkan drivers.

In RADV driver there are fixes for crashes in the CTS testsuite, GPU hangs when
using indirect descriptors, fixes for VK_EXT_conditional_rendering extension,
and some other fixes.

On the other hand, ANV driver also contains several fixes related with vertex
attributes, disabling cache in SKL GT4 tessellation shader, clamping scissors in
framebuffer, support for v3 in VK_EXT_vertex_attribute_divisor extension, and
several other fixes.

Other fixes are also available for Broadcom's Android driver, radeonsi, r600,
v3d, and so on.

Meson also gets a couple of fixes, including fixes when compiling 32bit Intel
drivers.


Take a look at section "Mesa stable queue" for more information.


Testing reports/general approval

Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.

The plan is to have 18.2.1 this Friday (21st September), around or shortly 
after 12:00
GMT.

If you have any questions or suggestions - be that about the current patch queue
or otherwise, please go ahead.


Trivial merge conflicts
---
commit 3f20c0a004e3e8ed4f56114af445ac9eed9e19e6
Author: Sergii Romantsov 

i965/tools: 32bit compilation with meson

(cherry picked from commit 97fcccb25ed5f55139c03ebc1c71742f0f25f683)

commit f1305c32c1cd4f7c59ef5dfb2eac9edabc70
Author: Jason Ekstrand 

nir: Add a small pass to rematerialize derefs per-block

(cherry picked from commit 7d1d1208c2b38890fe065b6431ef2e3b7166bae4)


Cheers,
J.A.


Mesa stable queue
-

Nominated (0)
==

Queued (57)
===
Andres Gomez (1):
  Revert "Revert "glsl: skip stringification in preprocessor if in 
unreachable branch""

Andrii Simiklit (4):
  mesa/util: add missing va_end() after va_copy()
  mesa/util: don't ignore NULL returned from 'malloc'
  mesa/util: don't use the same 'va_list' instance twice
  apple/glx/log: added missing va_end() after va_copy()

Bas Nieuwenhuizen (4):
  radv: Use build ID if available for cache UUID.
  radv: Only allow 16 user SGPRs for compute on GFX9+.
  radv: Set the user SGPR MSB for Vega.
  radv: Support v3 of VK_EXT_vertex_attribute_divisor.

Christopher Egert (1):
  radeon: fix ColorMask

Dave Airlie (1):
  virgl: don't send a shader create with no data. (v2)

Dylan Baker (1):
  meson: Print a message about why a libdrm version was selected

Eric Anholt (2):
  v3d: Fix setup of the VCM cache size.
  v3d: Fix SRC_ALPHA_SATURATE blending for RTs without alpha.

Erik Faye-Lund (2):
  virgl: adjust strides when mapping temp-resources
  winsys/virgl: avoid unintended behavior

Fritz Koenig (2):
  mesa: FramebufferParameteri parameter checking
  mesa: Additional FlipY applications

Gert Wollny (2):
  mesa/texture: Also check for LA texture when querying intensity component 
size
  winsys/virgl: correct resource and handle allocation (v2)

Ian Romanick (1):
  i965/fs: Don't propagate conditional modifiers from integer compares to 
adds

Jason Ekstrand (11):
  nir/opt_if: Re-materialize derefs in use blocks before peeling loops
  nir/loop_unroll: Re-materialize derefs in use blocks before unrolling
  nir: Add a small pass to rematerialize derefs per-block
   Squashed with:
  nir: add initializer data to fix MSVC compile error
  anv/query: Write both dwords in emit_zero_queries
  anv: Support v3 of VK_EXT_vertex_attribute_divisor
  vulkan: Update the XML and headers to 1.1.84
  anv: Clamp scissors to the framebuffer boundary
  anv: Disable the vertex cache when tessellating on SKL GT4
  anv: Re-emit vertex buffers when the pipeline changes
  i965: Workaround the gen9 hw astc5x5 sampler bug
  anv/pipeline: Only consider double elements which actually exist

Josh Pieper (1):
  st/mesa: Validate the result of pipe_transfer_map in make_texture (v2)

Kenneth Feng (1):
  amd: Add Picasso device id

Marek Olšák (5):
  ac: revert new LLVM 7.0 behavior for fdiv
  radeonsi: fix printing a BO list into ddebug reports
  r600: fix HTILE for NPOT textures with mipmapping
  winsys/radeon: fix CMASK fast clear for NPOT textures with mipmapping on 
SI/CI
  radeonsi: fix HTILE for NPOT textures with mipmapping on SI/CI

Mathias Fröhlich (1):
  tnl: Fix green gun regression in xonotic.

Mauro Rossi (3):
  android: broadcom/cle: export the broadcom top level path headers
  android: broadcom/cle: add gallium include path
  android: broadcom/genxml: fix collision with intel/genxml header-gen macro

Michel Dänzer (1):
  loader/dri3: Only wait for back buffer fences in 

[Mesa-dev] [PATCH 2/2] gallium/ttn: Convert inputs and outputs to derefs of variables.

[Eric Anholt]

This means that TTN shaders more closely resemble GTN shaders: they have
inputs and outputs as variable derefs, with the variables having their
.driver_location already set up for you.

This will be useful for v3d to do input variable DCE in NIR, which we
can't do when the TTN shaders never have a pre-nir_lower_io stage.

Cc: Rob Clark 
---
 src/gallium/auxiliary/nir/tgsi_to_nir.c   | 114 +-
 .../drivers/freedreno/ir3/ir3_shader.c|   5 +-
 src/gallium/drivers/v3d/v3d_program.c |   7 +-
 src/gallium/drivers/vc4/vc4_program.c |   7 +-
 4 files changed, 64 insertions(+), 69 deletions(-)

diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c 
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 4f7f900c2433..0ad274b535af 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -65,6 +65,9 @@ struct ttn_compile {
 
nir_register *addr_reg;
 
+   nir_variable **inputs;
+   nir_variable **outputs;
+
/**
 * Stack of nir_cursors where instructions should be pushed as we pop
 * back out of the control flow stack.
@@ -301,6 +304,7 @@ ttn_emit_declaration(struct ttn_compile *c)
 }
 
 exec_list_push_tail(>shader->inputs, >node);
+c->inputs[idx] = var;
 
 for (int i = 0; i < array_size; i++)
b->shader->info.inputs_read |= 1 << (var->data.location + i);
@@ -368,6 +372,7 @@ ttn_emit_declaration(struct ttn_compile *c)
 }
 
 exec_list_push_tail(>shader->outputs, >node);
+c->outputs[idx] = var;
 
 for (int i = 0; i < array_size; i++)
b->shader->info.outputs_written |= 1 << (var->data.location + 
i);
@@ -504,45 +509,41 @@ ttn_src_for_file_and_index(struct ttn_compile *c, 
unsigned file, unsigned index,
}
 
case TGSI_FILE_INPUT:
+  /* Special case: Turn the frontface varying into a load of the
+   * frontface intrinsic plus math, and appending the silly floats.
+   */
+  if (c->scan->processor == PIPE_SHADER_FRAGMENT &&
+  c->scan->input_semantic_name[index] == TGSI_SEMANTIC_FACE) {
+ nir_ssa_def *tgsi_frontface[4] = {
+nir_bcsel(>build,
+  nir_load_system_value(>build,
+nir_intrinsic_load_front_face, 0),
+  nir_imm_float(>build, 1.0),
+  nir_imm_float(>build, -1.0)),
+nir_imm_float(>build, 0.0),
+nir_imm_float(>build, 0.0),
+nir_imm_float(>build, 1.0),
+ };
+
+ return nir_src_for_ssa(nir_vec(>build, tgsi_frontface, 4));
+  } else {
+ /* Indirection on input arrays isn't supported by TTN. */
+ assert(!dim);
+ nir_deref_instr *deref = nir_build_deref_var(>build,
+  c->inputs[index]);
+ return nir_src_for_ssa(nir_load_deref(>build, deref));
+  }
+  break;
+
case TGSI_FILE_CONSTANT: {
   nir_intrinsic_instr *load;
   nir_intrinsic_op op;
   unsigned srcn = 0;
 
-  switch (file) {
-  case TGSI_FILE_INPUT:
- /* Special case: Turn the frontface varying into a load of the
-  * frontface intrinsic plus math, and appending the silly floats.
-  */
- if (c->scan->processor == PIPE_SHADER_FRAGMENT &&
- c->scan->input_semantic_name[index] == TGSI_SEMANTIC_FACE) {
-nir_ssa_def *tgsi_frontface[4] = {
-   nir_bcsel(>build,
- nir_load_system_value(>build,
-   nir_intrinsic_load_front_face, 
0),
- nir_imm_float(>build, 1.0),
- nir_imm_float(>build, -1.0)),
-   nir_imm_float(>build, 0.0),
-   nir_imm_float(>build, 0.0),
-   nir_imm_float(>build, 1.0),
-};
-
-return nir_src_for_ssa(nir_vec(>build, tgsi_frontface, 4));
- }
-
- op = nir_intrinsic_load_input;
- assert(!dim);
- break;
-  case TGSI_FILE_CONSTANT:
- if (dim && (dim->Index > 0 || dim->Indirect)) {
-op = nir_intrinsic_load_ubo;
- } else {
-op = nir_intrinsic_load_uniform;
- }
- break;
-  default:
- unreachable("No other load files supported");
- break;
+  if (dim && (dim->Index > 0 || dim->Indirect)) {
+ op = nir_intrinsic_load_ubo;
+  } else {
+ op = nir_intrinsic_load_uniform;
   }
 
   load = nir_intrinsic_instr_create(b->shader, op);
@@ -1758,35 +1759,25 @@ ttn_add_output_stores(struct ttn_compile *c)
 {
nir_builder *b = >build;
 
-   foreach_list_typed(nir_variable, var, node, >shader->outputs) {
-  unsigned array_len = MAX2(glsl_get_length(var->type), 1);
-  unsigned i;
-
-  for (i = 0; i < array_len; i++) {
- nir_intrinsic_instr 

[Mesa-dev] [PATCH 1/2] gallium/ttn: Fix the type of gl_FragDepth.

[Eric Anholt]

In TGSI we have a vec4 of which only .z is used, but for NIR we should be
using a float the same as other NIR IR.  We were already moving TGSI's .z
to the .x channel.
---
 src/gallium/auxiliary/nir/tgsi_to_nir.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c 
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 12114dc2030a..4f7f900c2433 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -344,6 +344,7 @@ ttn_emit_declaration(struct ttn_compile *c)
}
case TGSI_SEMANTIC_POSITION:
   var->data.location = FRAG_RESULT_DEPTH;
+  var->type = glsl_float_type();
   break;
default:
   fprintf(stderr, "Bad TGSI semantic: %d/%d\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 1/4] nir: Add a small pass to rematerialize derefs per-block

[Juan A. Suarez Romero]

On Mon, 2018-09-17 at 09:43 -0500, Jason Ekstrand wrote:
> This pass re-materializes deref instructions on a per-block basis to
> ensure that every use of a deref occurs in the same block as the
> instruction which uses it.

Hello!

This patch was commited CCing to 18.2 stable branch.

This patch didn't apply cleanly on 18.2 branch, so I've fixed the conflicts.

Besides this, I've initialized struct variable explicitly to "{ 0 }", instead of
"{ }", as this was causing an error when building with MSVC.

You can find the patch commited at


https://gitlab.freedesktop.org/mesa/mesa/commit/f1305c32c1cd4f7c59ef5dfb2eac9edabc70


The change I did is in line 375.

Feel free to check if there are any error.

Thanks in advance!

J.A.

> ---
>  src/compiler/nir/nir.h   |   1 +
>  src/compiler/nir/nir_deref.c | 132 +++
>  2 files changed, 133 insertions(+)
> 
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 599f469a714..e0df95c391c 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -3012,6 +3012,7 @@ bool nir_convert_from_ssa(nir_shader *shader, bool 
> phi_webs_only);
>  
>  bool nir_lower_phis_to_regs_block(nir_block *block);
>  bool nir_lower_ssa_defs_to_regs_block(nir_block *block);
> +bool nir_rematerialize_derefs_in_use_blocks_impl(nir_function_impl *impl);
>  
>  bool nir_opt_algebraic(nir_shader *shader);
>  bool nir_opt_algebraic_before_ffma(nir_shader *shader);
> diff --git a/src/compiler/nir/nir_deref.c b/src/compiler/nir/nir_deref.c
> index 097ea8f1046..87a54790c95 100644
> --- a/src/compiler/nir/nir_deref.c
> +++ b/src/compiler/nir/nir_deref.c
> @@ -24,6 +24,7 @@
>  #include "nir.h"
>  #include "nir_builder.h"
>  #include "nir_deref.h"
> +#include "util/hash_table.h"
>  
>  void
>  nir_deref_path_init(nir_deref_path *path,
> @@ -379,3 +380,134 @@ nir_compare_derefs(nir_deref_instr *a, nir_deref_instr 
> *b)
>  
> return result;
>  }
> +
> +struct rematerialize_deref_state {
> +   bool progress;
> +   nir_builder builder;
> +   nir_block *block;
> +   struct hash_table *cache;
> +};
> +
> +static nir_deref_instr *
> +rematerialize_deref_in_block(nir_deref_instr *deref,
> + struct rematerialize_deref_state *state)
> +{
> +   if (deref->instr.block == state->block)
> +  return deref;
> +
> +   if (!state->cache) {
> +  state->cache= _mesa_hash_table_create(NULL, _mesa_hash_pointer,
> +_mesa_key_pointer_equal);
> +   }
> +
> +   struct hash_entry *cached = _mesa_hash_table_search(state->cache, deref);
> +   if (cached)
> +  return cached->data;
> +
> +   nir_builder *b = >builder;
> +   nir_deref_instr *new_deref =
> +  nir_deref_instr_create(b->shader, deref->deref_type);
> +   new_deref->mode = deref->mode;
> +   new_deref->type = deref->type;
> +
> +   if (deref->deref_type == nir_deref_type_var) {
> +  new_deref->var = deref->var;
> +   } else {
> +  nir_deref_instr *parent = nir_src_as_deref(deref->parent);
> +  if (parent) {
> + parent = rematerialize_deref_in_block(parent, state);
> + new_deref->parent = nir_src_for_ssa(>dest.ssa);
> +  } else {
> + nir_src_copy(_deref->parent, >parent, new_deref);
> +  }
> +   }
> +
> +   switch (deref->deref_type) {
> +   case nir_deref_type_var:
> +   case nir_deref_type_array_wildcard:
> +   case nir_deref_type_cast:
> +  /* Nothing more to do */
> +  break;
> +
> +   case nir_deref_type_array:
> +  assert(!nir_src_as_deref(deref->arr.index));
> +  nir_src_copy(_deref->arr.index, >arr.index, new_deref);
> +  break;
> +
> +   case nir_deref_type_struct:
> +  new_deref->strct.index = deref->strct.index;
> +  break;
> +
> +   default:
> +  unreachable("Invalid deref instruction type");
> +   }
> +
> +   nir_ssa_dest_init(_deref->instr, _deref->dest,
> + deref->dest.ssa.num_components,
> + deref->dest.ssa.bit_size,
> + deref->dest.ssa.name);
> +   nir_builder_instr_insert(b, _deref->instr);
> +
> +   return new_deref;
> +}
> +
> +static bool
> +rematerialize_deref_src(nir_src *src, void *_state)
> +{
> +   struct rematerialize_deref_state *state = _state;
> +
> +   nir_deref_instr *deref = nir_src_as_deref(*src);
> +   if (!deref)
> +  return true;
> +
> +   nir_deref_instr *block_deref = rematerialize_deref_in_block(deref, state);
> +
> +   nir_instr_rewrite_src(src->parent_instr, src,
> + nir_src_for_ssa(_deref->dest.ssa));
> +   nir_deref_instr_remove_if_unused(deref);
> +   state->progress = true;
> +
> +   return true;
> +}
> +
> +/** Re-materialize derefs in every block
> + *
> + * This pass re-materializes deref instructions in every block in which it is
> + * used.  After this pass has been run, every use of a deref will be of a
> + * deref in the same block as the use.  Also, all unused derefs will be
> + * deleted 

[Mesa-dev] [Bug 104926] swrast: Mesa 17.3.3 produces: HW cursor for format 875713089 not supported

[bugzilla-daemon]

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

Adam Jackson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Adam Jackson  ---
commit 194bf0a2e01769f4b29df06febf27ce340c1cd68 (HEAD -> master, origin/master,
origin/HEAD)
Author: Michal Srb 
Date:   Thu Mar 15 17:27:57 2018 +0100

st/dri: don't set queryDmaBufFormats/queryDmaBufModifiers if the driver
does not implement it

This is equivalent to commit a65db0ad1c3, but for dri_kms_init_screen.
Without
this gbm_dri_is_format_supported always returns false.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104926
Fixes: e14fe41e0bf ("st/dri: implement createImageFromRenderbuffer(2)")
Reviewed-by: Emil Velikov 
Reviewed-by: Adam Jackson 
Tested-by: Adam Williamson 

-- 
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 104926] swrast: Mesa 17.3.3 produces: HW cursor for format 875713089 not supported

[bugzilla-daemon]

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

--- Comment #8 from Adam Williamson  ---
Confirmed the patch fixes the error message flood, makes my VM cursor move much
more smoothly, and somehow seems to fix paste from the host system into the VM
too. Maybe I should see if it can pick my lotto numbers for me as well...

-- 
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 104926] swrast: Mesa 17.3.3 produces: HW cursor for format 875713089 not supported

[bugzilla-daemon]

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

--- Comment #7 from Adam Williamson  ---
I'm seeing exactly these same message floods running Fedora 29 images in VMs,
and indeed the fix seems to have got lost - there was one reply to the message,
then crickets after that, and it's still broken in git master. :(

-- 
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 107989] GLES 3.x context: GL_INVALID_OPERATION in glGenerateMipmap(invalid internal format GL_RED)

[bugzilla-daemon]

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

Andrei Alexeyev <0x416b617...@gmail.com> changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #2 from Andrei Alexeyev <0x416b617...@gmail.com> ---
@Tapani Pälli: yes, you seem to be right. I somehow missed this bit. Sorry for
the false alarm. I guess it's ANGLE exhibiting non-conformant behavior, then
(unless it's covered by some extension that I'm not aware of).

-- 
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] Lets talk about autotools

[Dylan Baker]

Quoting Kai Wasserbäch (2018-09-19 08:04:35)
> Hey Dylan,
> Dylan Baker wrote on 9/18/18 10:43 PM:
> > Quoting Kai Wasserbäch (2018-09-18 11:14:19)
> >> Dylan Baker wrote on 9/18/18 6:40 PM:
> >>> Quoting Kai Wasserbäch (2018-09-18 08:56:30)
>  Dylan Baker wrote on 9/18/18 5:35 PM:
> > [...]
> >
> > The other option you have it to set the $PATH variable, as long as the
> > llvm-config you want returns the highest version things will work as 
> > you expect.
> 
>  This might do as a workaround, though I'm not too keen on extending 
>  $PATH. But
>  as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain 
>  that
>  versions binaries, putting it first into the path could work.
> >>>
> >>> meson will cache the llvm-config values, so you should be able to just do
> >>> something like:
> >>>
> >>> PATH=/path/to/my/llvm meson build-with-my-llvm
> >>
> >> Ok. Where's the cache? In the build directory or is this something, that's 
> >> kept
> >> globally and needs potential clearing? A quick search for this feature 
> >> yielded
> >> . That makes it 
> >> sound like
> >> it is global, which I would almost consider broken design. Or is it local 
> >> but
> >> kept between multiple invocations of meson? That also sounds like a recipe 
> >> for
> >> disaster, though it would be easier to deal with: just nuke the build 
> >> directory.
> > 
> > It's per build directory, and is kept on subsequent rebuilds. The idea is 
> > that
> > if you need to reconfigure a build (say meson.build changes) when you do a 
> > `git
> > pull` that pkg-config, llvm-config, and fiends don't get reinvoked, it 
> > makes the
> > rebuild faster. I don't think there is a cache-invalidation method, though 
> > that
> > would be a nice feature to have.
> 
> I think I can work with that: one build-directory per build and nuke it 
> afterwards.
> 
> As a side note: to me this sounds like a mis-feature or at least something 
> that
> you should have to turn on explicitly. I'd rather pay a little time penalty
> (which isn't too much these days, given how fast SSDs and systems in general
> have become), than using some stale value. Especially since it sounds like 
> meson
> is caching the values of environment variables as well? Which would make usage
> of MESA_GIT_SHA1_OVERRIDE after some changes awkward (which value is used and 
> why).

meson only caches environment variables it cares about, CFLAGS, CC,
PKG_CONFIG_PATH.

> In any case, thanks for your replies. I'll see if I can scare up some time 
> over
> the weekend and check if I can get Mesa building with meson. Nevertheless I'd
> like to ask for not making meson mandatory until something like today's
> LLVM_CONFIG or something equivalent within a released version of meson is 
> available.

In case you (or anyone else following this is interested) here's my work in
progress for getting llvm-config overrides into meson:
https://github.com/mesonbuild/meson/pull/4216

Dylan


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

Re: [Mesa-dev] Lets talk about autotools

[Dylan Baker]

Quoting Ilia Mirkin (2018-09-17 17:56:15)
> On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker  wrote:
> > I feel like for !windows meson is in good enough shape at this point that we
> > can start having the discussion about deleting the autotools build. So, is 
> > there
> > anything left that autotools can do that meson cannot (that we actually 
> > want to
> > implement)? And, what is a reasonable time-table to remove the autotools 
> > build?
> > I think we could reasonably remove it as soon as 18.3 if others felt 
> > confident
> > that it would work for them.
> 
> I remember there was a particularly egregious failure mode for meson
> where running "meson configure help" would fail if any of the
> dependencies were missing for whatever the default was. Has that been
> resolved?

Do you mean `meson configure --help`? That doesn't run any of the options from
the local build, it just shows the meson global options.

`meson configure $builddir` does run the config script, at least with 0.47.2
this works fine even with a missing dependency (I set gallium-omx to tizonia and
it works).

Dylan


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

Re: [Mesa-dev] [PATCH] mesa: only update framebuffer-state for clears

[Mark Janes]

This patch broke all the intel systems also.

Ilia Mirkin  writes:

> On Wed, Sep 19, 2018 at 7:04 AM, Jakob Bornecrantz  
> wrote:
>> This patch regresses about 3000 dEQP [2,3,3.1] tests on virgl. Full
>> setup is dEQP running on virgl with vtest that is running RadeonSI. So
>> QEMU is not in the picture. All instances of the Mesa driver is from
>> the same tree and have the patch applied.
>
> Does this happen with dEQP on just radeonsi? If not, that definitely
> points in the virglrenderer direction for bugs...
>
>   -ilia
> ___
> 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 v2] anv/skylake: disable ForceThreadDispatchEnable

[Sergii Romantsov]

On Skylake enabling of ForceThreadDispatchEnable causes gpu-hang.

-v2: enabling of  ForceThreadDispatchEnable is only for gen8, for
 gen9 and higher reverted enabling of PixelShaderHasUAV.

CC: Jason Ekstrand 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107941
Fixes: 79270d2140ec (anv: Stop setting 3DSTATE_PS_EXTRA::PixelShaderHasUAV)
Signed-off-by: Sergii Romantsov 
---
 src/intel/vulkan/genX_pipeline.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 9595a71..b469270 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -1445,7 +1445,7 @@ emit_3dstate_wm(struct anv_pipeline *pipeline, struct 
anv_subpass *subpass,
 wm.EarlyDepthStencilControl = EDSC_NORMAL;
  }
 
-#if GEN_GEN >= 8
+#if GEN_GEN == 8
  /* Gen8 hardware tries to compute ThreadDispatchEnable for us but
   * doesn't take into account KillPixels when no depth or stencil
   * writes are enabled.  In order for occlusion queries to work
@@ -1663,6 +1663,37 @@ emit_3dstate_ps_extra(struct anv_pipeline *pipeline,
  wm_prog_data->uses_kill;
 
 #if GEN_GEN >= 9
+  /* The stricter cross-primitive coherency guarantees that the hardware
+   * gives us with the "Accesses UAV" bit set for at least one shader stage
+   * and the "UAV coherency required" bit set on the 3DPRIMITIVE command 
are
+   * redundant within the current image, atomic counter and SSBO GL APIs,
+   * which all have very loose ordering and coherency requirements and
+   * generally rely on the application to insert explicit barriers when a
+   * shader invocation is expected to see the memory writes performed by 
the
+   * invocations of some previous primitive.  Regardless of the value of
+   * "UAV coherency required", the "Accesses UAV" bits will implicitly 
cause
+   * an in most cases useless DC flush when the lowermost stage with the 
bit
+   * set finishes execution.
+   *
+   * It would be nice to disable it, but in some cases we can't because on
+   * Gen8+ it also has an influence on rasterization via the PS UAV-only
+   * signal (which could be set independently from the coherency mechanism
+   * in the 3DSTATE_WM command on Gen7), and because in some cases it will
+   * determine whether the hardware skips execution of the fragment shader
+   * or not via the ThreadDispatchEnable signal.  However if we know that
+   * GEN8_PS_BLEND_HAS_WRITEABLE_RT is going to be set and
+   * GEN8_PSX_PIXEL_SHADER_NO_RT_WRITE is not set it shouldn't make any
+   * difference so we may just disable it here.
+   *
+   * Gen8 hardware tries to compute ThreadDispatchEnable for us but doesn't
+   * take into account KillPixels when no depth or stencil writes are
+   * enabled. In order for occlusion queries to work correctly with no
+   * attachments, we need to force-enable here.
+   */
+  if ((wm_prog_data->has_side_effects || wm_prog_data->uses_kill) &&
+  !has_color_buffer_write_enabled(pipeline, blend))
+ ps.PixelShaderHasUAV = true;
+
   ps.PixelShaderComputesStencil = wm_prog_data->computed_stencil;
   ps.PixelShaderPullsBary= wm_prog_data->pulls_bary;
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH v1] anv/skylake: disable ForceThreadDispatchEnable

[Sergii Romantsov]

Probably there should be some much more complex conditions for doing that,
but as initial solution...

On Wed, Sep 19, 2018 at 6:55 PM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:

> On Skylake enabling of ForceThreadDispatchEnable causes gpu-hang.
>
> CC: Jason Ekstrand 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107941
> Fixes: 79270d2140ec (anv: Stop setting 3DSTATE_PS_EXTRA::
> PixelShaderHasUAV)
> Signed-off-by: Sergii Romantsov 
> ---
>  src/intel/vulkan/genX_pipeline.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_
> pipeline.c
> index 9595a71..bf5150d 100644
> --- a/src/intel/vulkan/genX_pipeline.c
> +++ b/src/intel/vulkan/genX_pipeline.c
> @@ -1462,7 +1462,8 @@ emit_3dstate_wm(struct anv_pipeline *pipeline,
> struct anv_subpass *subpass,
>* is 3DSTATE_PS_EXTRA::PixelShaderHasUAV which causes hangs on
> BDW.
>* Given two bad options, we choose the one which works.
>*/
> - if ((wm_prog_data->has_side_effects || wm_prog_data->uses_kill)
> &&
> + if (!pipeline->device->info.is_skylake &&
> + (wm_prog_data->has_side_effects || wm_prog_data->uses_kill)
> &&
>   !has_color_buffer_write_enabled(pipeline, blend))
>  wm.ForceThreadDispatchEnable = ForceON;
>  #endif
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



-- 
Sergii Romantsov
GlobalLogic Inc.
www.globallogic.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v1] anv/skylake: disable ForceThreadDispatchEnable

[Sergii Romantsov]

On Skylake enabling of ForceThreadDispatchEnable causes gpu-hang.

CC: Jason Ekstrand 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107941
Fixes: 79270d2140ec (anv: Stop setting 3DSTATE_PS_EXTRA::PixelShaderHasUAV)
Signed-off-by: Sergii Romantsov 
---
 src/intel/vulkan/genX_pipeline.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 9595a71..bf5150d 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -1462,7 +1462,8 @@ emit_3dstate_wm(struct anv_pipeline *pipeline, struct 
anv_subpass *subpass,
   * is 3DSTATE_PS_EXTRA::PixelShaderHasUAV which causes hangs on BDW.
   * Given two bad options, we choose the one which works.
   */
- if ((wm_prog_data->has_side_effects || wm_prog_data->uses_kill) &&
+ if (!pipeline->device->info.is_skylake &&
+ (wm_prog_data->has_side_effects || wm_prog_data->uses_kill) &&
  !has_color_buffer_write_enabled(pipeline, blend))
 wm.ForceThreadDispatchEnable = ForceON;
 #endif
-- 
2.7.4

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

Re: [Mesa-dev] Lets talk about autotools

[Ian Romanick]

On 09/18/2018 10:38 AM, Dylan Baker wrote:
> Quoting Eric Engestrom (2018-09-18 09:59:22)
>> On Tuesday, 2018-09-18 09:35:20 -0700, Dylan Baker wrote:
>>> Quoting Eric Engestrom (2018-09-18 09:00:49)
 On Tuesday, 2018-09-18 08:24:52 -0700, Dylan Baker wrote:
> Quoting Kenneth Graunke (2018-09-18 01:40:48)
>> On Monday, September 17, 2018 3:24:56 PM PDT Dylan Baker wrote:
>>> Quoting Marek Ol\u0161ák (2018-09-17 15:14:11)
 How do I build 32-bit Mesa with meson?

 Thanks,
 Marek

>>>
>>> Some people get away with just adding CFLAGs=-m32, but using a cross 
>>> file and
>>> doing a cross build is a better way, and is basically required if you 
>>> want llvm.
>>> Here's mine: https://gitlab.freedesktop.org/snippets/504
>>>
>>> Dylan
>>
>> I've attached mine, I then do:
>>
>> meson --cross-file=/home/kwg/.local/meson-32-cross --buildtype=release 
>> --prefix=/home/kwg/Projects/mesa/build/32/install -Ddri-drivers=i965 
>> -Dvulkan-drivers=intel -Dgallium-drivers= -Db_ndebug=true -Dglvnd=true 
>> build/32
>>
>> Other than the addition of --cross-file, it's just like any other build.
>
> If you put your cross file in ~/.local/share/meson/cross then you could 
> just do
>
> meson --cross-file=meson-32-cross --buildtype=release 
> --prefix=$PWD/build/32/install -Ddri-drivers=i965 -Dvulkan-drivers=intel 
> -Dgallium-drivers= -Db_ndebug=true -Dglvnd=true build/32
>
> I think Eric Engstrom also landed is if-debug patches, so ndebug is by 
> default
> only enabled for debug and debugoptimized builds now. I think.

 Other way around: b_ndebug is false by default and can be manually set
 to true, or to if-release in which case it is true if buildtype=release,
 but still false for debugoptimised, debug, minsize and plain unless
 specified.
>>>
>>> ndebug makes my head hurt. I really wish that meson would have called the 
>>> option
>>> "b_assert" so it could be true for asserts on and false for asserts off. You
>>> know what, I'm going to go propose that right now.
>>
>> I know, and I kind of agree, but it's not gonna fly, because what meson
>> controls with this option is NDEBUG which is a (de facto?) standard, and
>> that flag can control more than just asserts.
> 
> In C/C++ that's true. What about in Rust and D (for example)? It really feels
> like carrying legacy cruft around.

You're working on this project and complaining about cruft?  Lol



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] Lets talk about autotools

[Ian Romanick]

On 09/18/2018 12:16 PM, Gert Wollny wrote:
> Am Montag, den 17.09.2018, 17:07 -0400 schrieb Marek Olšák:
>> I don't see radeonsi_dri.so. How/where is radeonsi_dri.so created?
> +1 
> 
> With autotools I can use an uninstalled but compiled version of meson
> (e.g. for testing) by pointing LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
> to the $BUILDDIR/lib and $BUILDDIR/lib/gallium respectively.  With
> meson it seems one always needs to run "ninja install" to get the
> actual drivers and libraries somewhere.

I do the same thing.  The way I worked around this was to set the
install dir to the build dir.  My build script has something like:

DESTDIR=$PWD/$DIR ninja-build -C $DIR install

> It would be nice if meson would act like autotools in that regard by
> creating the drivers and libraries in specific directories (also as a
> configure option if there is concern about compilation speed). 
> 
> Thanks,
> Gert 
> 
>>
>> Thanks,
>> Marek
>>
>> On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker 
>> wrote:
>>> I feel like for !windows meson is in good enough shape at this
>>> point that we
>>> can start having the discussion about deleting the autotools build.
>>> So, is there
>>> anything left that autotools can do that meson cannot (that we
>>> actually want to
>>> implement)? And, what is a reasonable time-table to remove the
>>> autotools build?
>>> I think we could reasonably remove it as soon as 18.3 if others
>>> felt confident
>>> that it would work for them.
>>>
>>> Dylan
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> ___
> mesa-dev 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 2/2] .travis: Drop note about Clover builds being slow

[Jan Vesely]

On Wed, 2018-09-12 at 18:20 -0400, Jan Vesely wrote:
> SWR takes 17+ minutes to build. Clover builds take ~6-7 minutes.
> 
> Signed-off-by: Jan Vesely 
> ---
>  .travis.yml | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 4035a729ff..78e6d251ae 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -186,7 +186,6 @@ matrix:
>  - libelf-dev
>  - libunwind8-dev
>  - env:
> -# NOTE: Analogous to SWR above, building Clover is quite slow.
>  - LABEL="make Gallium ST Clover LLVM-3.9"
>  - BUILD=make
>  - MAKEFLAGS="-j4"
> @@ -225,7 +224,6 @@ matrix:
>  - libelf-dev
>  - libunwind8-dev
>  - env:
> -# NOTE: Analogous to SWR above, building Clover is quite slow.
>  - LABEL="make Gallium ST Clover LLVM-4.0"
>  - BUILD=make
>  - MAKEFLAGS="-j4"
> @@ -261,7 +259,6 @@ matrix:
>  - libelf-dev
>  - libunwind8-dev
>  - env:
> -# NOTE: Analogous to SWR above, building Clover is quite slow.
>  - LABEL="make Gallium ST Clover LLVM-5.0"
>  - BUILD=make
>  - MAKEFLAGS="-j4"
> @@ -297,7 +294,6 @@ matrix:
>  - libelf-dev
>  - libunwind8-dev
>  - env:
> -# NOTE: Analogous to SWR above, building Clover is quite slow.
>  - LABEL="make Gallium ST Clover LLVM-6.0"
>  - BUILD=make
>  - MAKEFLAGS="-j4"


ping for the series.
LLVM-7 was released today.

Jan


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106996] Compiler diagnostic for sampler declared as "out" parameter of function is terrible

[bugzilla-daemon]

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

Ian Romanick  changed:

   What|Removed |Added

Summary|Compute shader compiling|Compiler diagnostic for
   |fails for invalid input |sampler declared as "out"
   |layout qualifier used   |parameter of function is
   ||terrible

--- Comment #2 from Ian Romanick  ---
The problem is dst is marked as an "out" parameter of the function.  sampler
variables cannot be assigned, so it's impossible for it to be an out parameter.
 Deleting "out" allows the shader to compile.

Sadly, the compiler error message is useless for debugging that problem.

-- 
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 1/3] mesa: use GLsizeiptrARB, GLintptrARB in bufferobj.c

[Mathias Fröhlich]

Hi Brian,

> gl.xml doesn't seem relevant to this.  In GL/glext.h we have:
I thought that somewere at khronos the headers are
generated from the xml. And the new headers are usually
imported then together with the matching xml into mesa?

> typedef khronos_ssize_t GLsizeiptr;
> [...]
> typedef ptrdiff_t GLsizeiptrARB;
> 
> and in KHR/khrplatform.h:
> 
> typedef unsigned long  int khronos_uintptr_t;
> 
> and in stdef.h:
> 
> typedef __PTRDIFF_TYPE__ ptrdiff_t;
> 
> And it looks like __PTRDIFF_TYPE__ is a compiler built-in.
> 
> So, gcc is warning that __PTRDIFF_TYPE__ is not the same as unsigned 
> long int.  Seems reasonable.

Uh, ok.
Thanks for the explanation!

Ok, yes I see now that khronos' version of the xml file changed the
data type already to khronos_uintptr_t. So, xml and headers are obviously
not always imported at the same time ...

Anyhow, thanks!

best
Mathias


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

Re: [Mesa-dev] Lets talk about autotools

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 9/18/18 10:43 PM:
> Quoting Kai Wasserbäch (2018-09-18 11:14:19)
>> Dylan Baker wrote on 9/18/18 6:40 PM:
>>> Quoting Kai Wasserbäch (2018-09-18 08:56:30)
 Dylan Baker wrote on 9/18/18 5:35 PM:
> [...]
>
> The other option you have it to set the $PATH variable, as long as the
> llvm-config you want returns the highest version things will work as you 
> expect.

 This might do as a workaround, though I'm not too keen on extending $PATH. 
 But
 as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain 
 that
 versions binaries, putting it first into the path could work.
>>>
>>> meson will cache the llvm-config values, so you should be able to just do
>>> something like:
>>>
>>> PATH=/path/to/my/llvm meson build-with-my-llvm
>>
>> Ok. Where's the cache? In the build directory or is this something, that's 
>> kept
>> globally and needs potential clearing? A quick search for this feature 
>> yielded
>> . That makes it sound 
>> like
>> it is global, which I would almost consider broken design. Or is it local but
>> kept between multiple invocations of meson? That also sounds like a recipe 
>> for
>> disaster, though it would be easier to deal with: just nuke the build 
>> directory.
> 
> It's per build directory, and is kept on subsequent rebuilds. The idea is that
> if you need to reconfigure a build (say meson.build changes) when you do a 
> `git
> pull` that pkg-config, llvm-config, and fiends don't get reinvoked, it makes 
> the
> rebuild faster. I don't think there is a cache-invalidation method, though 
> that
> would be a nice feature to have.

I think I can work with that: one build-directory per build and nuke it 
afterwards.

As a side note: to me this sounds like a mis-feature or at least something that
you should have to turn on explicitly. I'd rather pay a little time penalty
(which isn't too much these days, given how fast SSDs and systems in general
have become), than using some stale value. Especially since it sounds like meson
is caching the values of environment variables as well? Which would make usage
of MESA_GIT_SHA1_OVERRIDE after some changes awkward (which value is used and 
why).

In any case, thanks for your replies. I'll see if I can scare up some time over
the weekend and check if I can get Mesa building with meson. Nevertheless I'd
like to ask for not making meson mandatory until something like today's
LLVM_CONFIG or something equivalent within a released version of meson is 
available.

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] [PATCH] mesa: only update framebuffer-state for clears

[Michel Dänzer]

On 2018-09-19 1:10 p.m., Erik Faye-Lund wrote:
> On on., sep. 19, 2018 at 1:04 PM, Jakob Bornecrantz
>  wrote:
>> This patch regresses about 3000 dEQP [2,3,3.1] tests on virgl. Full
>> setup is dEQP running on virgl with vtest that is running RadeonSI. So
>> QEMU is not in the picture. All instances of the Mesa driver is from
>> the same tree and have the patch applied.
>>
>> Cheers, Jakob.
> 
> Hmm, that's a bit odd IMO. Perhaps a full flush is needed when clears
> are implemented using the graphics-pipeline or something? But I don't
> think virgl does this, so hmmm...
> 
> I guess I should revert, and try to respin with some more testing...

Please do. :) It also broke hundreds of piglits with radeonsi and
llvmpipe, presumably all Gallium drivers.


Maybe it's time to look into hooking up some CI testing with LLVM in
Gitlab. Any volunteers?


-- 
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 1/4] anv/so_memcpy: Don't consider src/dst_offset when computing block size

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 12/09/2018 06:06, Jason Ekstrand wrote:

The only thing that matters is the size since we never specify any
offsets in terms of blocks.
---
  src/intel/vulkan/genX_gpu_memcpy.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/intel/vulkan/genX_gpu_memcpy.c 
b/src/intel/vulkan/genX_gpu_memcpy.c
index eaafcfa3b22..57abd8cd5c1 100644
--- a/src/intel/vulkan/genX_gpu_memcpy.c
+++ b/src/intel/vulkan/genX_gpu_memcpy.c
@@ -126,10 +126,8 @@ genX(cmd_buffer_so_memcpy)(struct anv_cmd_buffer 
*cmd_buffer,
 assert(src_offset + size <= src->size);
  
 /* The maximum copy block size is 4 32-bit components at a time. */

-   unsigned bs = 16;
-   bs = gcd_pow2_u64(bs, src_offset);
-   bs = gcd_pow2_u64(bs, dst_offset);
-   bs = gcd_pow2_u64(bs, size);
+   assert(size % 4 == 0);
+   unsigned bs = gcd_pow2_u64(16, size);
  
 enum isl_format format;

 switch (bs) {



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

Re: [Mesa-dev] [PATCH] mesa: only update framebuffer-state for clears

[Jakob Bornecrantz]

On Wed, Sep 19, 2018 at 1:48 PM Ilia Mirkin  wrote:
>
> On Wed, Sep 19, 2018 at 7:04 AM, Jakob Bornecrantz  
> wrote:
> > This patch regresses about 3000 dEQP [2,3,3.1] tests on virgl. Full
> > setup is dEQP running on virgl with vtest that is running RadeonSI. So
> > QEMU is not in the picture. All instances of the Mesa driver is from
> > the same tree and have the patch applied.
>
> Does this happen with dEQP on just radeonsi? If not, that definitely
> points in the virglrenderer direction for bugs...

Yeah, just tested and I get about the same amount of failures on just
RadeonSI. So I'll revert the patch soon so Erik can respin it.

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

[Mesa-dev] [PATCH] radeon/uvd: use bitstream coded number for symbols of Huffman tables

[Leo Liu]

Signed-off-by: Leo Liu 
Fixes: 130d1f456(radeon/uvd: reconstruct MJPEG bitstream)
Cc: "18.2" 
---
 src/gallium/drivers/radeon/radeon_uvd.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_uvd.c 
b/src/gallium/drivers/radeon/radeon_uvd.c
index 923216d77f1..a7ef4252ee0 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -1003,25 +1003,35 @@ static void get_mjpeg_slice_header(struct ruvd_decoder 
*dec, struct pipe_mjpeg_p
size++;
 
for (i = 0; i < 2; ++i) {
+   int num = 0, j;
+
if (pic->huffman_table.load_huffman_table[i] == 0)
continue;
 
buf[size++] = 0x00 | i;
memcpy((buf + size), >huffman_table.table[i].num_dc_codes, 
16);
size += 16;
-   memcpy((buf + size), >huffman_table.table[i].dc_values, 
12);
-   size += 12;
+   for (j = 0; j < 16; ++j)
+   num += pic->huffman_table.table[i].num_dc_codes[j];
+   assert(num <= 12);
+   memcpy((buf + size), >huffman_table.table[i].dc_values, 
num);
+   size += num;
}
 
for (i = 0; i < 2; ++i) {
+   int num = 0, j;
+
if (pic->huffman_table.load_huffman_table[i] == 0)
continue;
 
buf[size++] = 0x10 | i;
memcpy((buf + size), >huffman_table.table[i].num_ac_codes, 
16);
size += 16;
-   memcpy((buf + size), >huffman_table.table[i].ac_values, 
162);
-   size += 162;
+   for (j = 0; j < 16; ++j)
+   num += pic->huffman_table.table[i].num_ac_codes[j];
+   assert(num <= 162);
+   memcpy((buf + size), >huffman_table.table[i].ac_values, 
num);
+   size += num;
}
 
bs = (uint16_t*)[len_pos];
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH 19/26] nir/linker: use only the array element type for array of ssbo/ubo

[Alejandro Piñeiro]

On 19/09/18 14:09, Timothy Arceri wrote:
> On 19/9/18 7:59 pm, Alejandro Piñeiro wrote:
>> On 19/09/18 07:20, Timothy Arceri wrote:
>>> On 16/9/18 2:18 am, Alejandro Piñeiro wrote:
 For this interfaces, the inner members are added only once as uniforms
 or resources, in opposite to other cases, like a uniform array of
 structs.
 ---
    src/compiler/glsl/gl_nir_link_uniforms.c | 26
 --
    1 file changed, 24 insertions(+), 2 deletions(-)

 diff --git a/src/compiler/glsl/gl_nir_link_uniforms.c
 b/src/compiler/glsl/gl_nir_link_uniforms.c
 index 00995fb3f76..c692cd0171f 100644
 --- a/src/compiler/glsl/gl_nir_link_uniforms.c
 +++ b/src/compiler/glsl/gl_nir_link_uniforms.c
 @@ -498,11 +498,33 @@ gl_nir_link_uniforms(struct gl_context *ctx,
       state.current_var = var;
    + /*
 +  * From OpenGL 4.6 spec, section 7.3.1.1, "Naming Active
 Resources":
 +  *
 +  *   "* For an active shader storage block member declared
 as an
 +  *  array of an aggregate type, an entry will be
 generated only
 +  *  for the first array element, regardless of its
 type. Such
 +  *  block members are referred to as top-level arrays.
 If the
 +  *  block member is an aggregate type, the enumeration
 rules are
 +  *  then applied recursively.
 +  *    * For an active interface block not declared as an
 array of
 +  *  block instances, a single entry will be generated,
 using the
 +  *  block name from the shader source."
 +  *
 +  * So for the UBO and SSBO case, we expand only the array
 element
 +  * type.
 +  */
 + const struct glsl_type *type = var->type;
 + if (nir_variable_is_in_block(var) &&
 + glsl_type_is_array(type)) {
 +    type = glsl_get_array_element(type);
>>>
>>> This also strips away vector and matrix type information while leaving
>>> arrays for anything but a single dimension array.
>>
>> Well, but the idea behind this patch is getting a single dimension
>> array.
>
> I think you mean getting a single element of an array?

Perhaps.

>
>> We are using the type to populate the uniforms, and as mentioned
>> on the spec quote, for ubo/ssbo and recursively for his entries, it is
>> done just once, no matter the dimension of the ubo/ssbo array.
>>
>> Also not sure why do you mean that we would lose matrix and vector type
>> information. Could you give an example.
>
> The code for glsl_get_array_element() is:
>
> const glsl_type *
> glsl_get_array_element(const glsl_type* type)
> {
>    if (type->is_matrix())
>   return type->column_type();
>    else if (type->is_vector())
>   return type->get_scalar_type();
>    return type->fields.array;
> }
>
> I was thinking you might end up stripping away the vec and matrix type
> but as you have glsl_type_is_array(type) in the if condition it is fine.

Ok.

>
>>
>> FWIW, this patch is needed to get this test working:
>> https://github.com/Igalia/piglit/blob/arb_gl_spirv-series5-ubo-ssbo-v1/tests/spec/arb_gl_spirv/execution/ubo/array-complex.shader_test
>>
>>
>> and just in case, I have just writing a similar test, slightly more
>> complex, but with array members and array of matrices members:
>>
>> https://github.com/Igalia/piglit/blob/arb_gl_spirv-series5-ubo-ssbo-v1/tests/spec/arb_gl_spirv/execution/ubo/array-complex-2.shader_test
>>
>>
>> And the uniform and variable count is the same on both GLSL and SPIR-V.
>>
>>>
>>> Are you sure you don't want the following instead?
>>>
>>> type = glsl_get_array_element(type);
>>
>> Sorry, but isn't that what we are already doing? Or do you mean that we
>> should made the call always, without the is_in_block and is_array
>> checks?
>
> Apologizes I pasted the wrong thing I meant:
>
>   type = glsl_without_array(type);

Ok, later today, or tomorrow, I will try with this one.

>
> However looking more closely at the code and the spec I see that's not
> what you want.
>
> However I'm starting to think the quote from the spec and this code
> have nothing to do with each other.

Yes, probably the spec quote is not the best one. We know what the
behaviour should be (based on comments at the GLSL linker, how
uniformstorage is populated on GLSL, and the program interface queries),
so I thought that was the spec quote justifying it. Now that you mention
it, and re-reading, it is true that's not perhaps the best quote
justifying it.

>
> The spec is taking about top level block member arrays. For example:
>
> layout (std140, binding = 5, row_major) uniform ComponentsBlock
>  {
>     float c1[3];
> } components;
>
> However neither of the examples you gave have top level arrays:
>
> layout (std140, binding = 5, row_major) uniform ComponentsBlock
>  {

Re: [Mesa-dev] [PATCH 6/6] util: disable cache if we have no build-id and timestamp is zero

[Timothy Arceri]

On 19/9/18 9:32 pm, Bas Nieuwenhuizen wrote:

On Wed, Sep 19, 2018 at 4:14 AM Timothy Arceri  wrote:


Timestamp can be zero for example when Flatpack is used. In this
case just disable the cache rather then segfaulting when
incompatible cache items are loaded.
---
  src/amd/vulkan/radv_device.c | 4 
  src/util/disk_cache.h| 6 ++
  2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index f9169d9d012..7d915c68aaa 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -61,10 +61,6 @@ radv_get_build_id(void *ptr, struct mesa_sha1 *ctx)
 } else
  #endif
 if (disk_cache_get_function_timestamp(ptr, )) {
-   if (!timestamp) {
-   fprintf(stderr, "radv: The provided filesystem timestamp for 
the cache is bogus!\n");
-   }
-
 _mesa_sha1_update(ctx, , sizeof(timestamp));
 } else
 return false;
diff --git a/src/util/disk_cache.h b/src/util/disk_cache.h
index 962a26ffc8c..c37acd75830 100644
--- a/src/util/disk_cache.h
+++ b/src/util/disk_cache.h
@@ -102,6 +102,12 @@ disk_cache_get_function_timestamp(void *ptr, uint32_t* 
timestamp)
return false;
 }
 *timestamp = st.st_mtime;
+
+   if (!timestamp) {
+  fprintf(stderr, "Mesa: The provided filesystem timestamp for the cache "
+  "is bogus! Disabling On-disk cache.\n");


Wouldn't this need a "return false;" ?


Yeah and it also should be if (!st.st_mtime) rather than null checking 
the timestamp pointer.


Sorry I made a mess of this patch.


+   }
+
 return true;
  }

--
2.17.1

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

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

Re: [Mesa-dev] [PATCH] mesa: only update framebuffer-state for clears

[Ilia Mirkin]

On Wed, Sep 19, 2018 at 7:04 AM, Jakob Bornecrantz  wrote:
> This patch regresses about 3000 dEQP [2,3,3.1] tests on virgl. Full
> setup is dEQP running on virgl with vtest that is running RadeonSI. So
> QEMU is not in the picture. All instances of the Mesa driver is from
> the same tree and have the patch applied.

Does this happen with dEQP on just radeonsi? If not, that definitely
points in the virglrenderer direction for bugs...

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

Re: [Mesa-dev] Bug introduced with Mesa 18.0.0: Star Trek Voyager Elite Force shadow glitches

[Roland Scheidegger]

Am 19.09.2018 um 07:55 schrieb Federico Dossena:
> I tried setting MESA_EXTENSION_YEAR=2002 but the glitch still occurs.
> Same with 2000 and 2001.
What about 1999?
Can you provide the complete console output so we can see what extension
it's looking for (if it prints that out like q3 does)?


> 
> I'm familiar with the bug in id2 and id3 games with the length of the
> extension string, I didn't expect this to be the problem because it
> usually just makes the game crash.
> 
> Would it be possible to revert this commit? Or at least add hacks for
> id3 games that might suffer from this?
The sorting was removed because it was deemed not to really be the right
solution and not helping, so if that isn't true I suppose technically it
could be reverted. I don't work in that area though...

Roland


> 
> 
> On 2018-09-18 22:13, Roland Scheidegger wrote:
>> Am 18.09.2018 um 20:04 schrieb Federico Dossena:
>>> The problem is caused by this commit:
>>> [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove unnecessary
>>> 'sort by year' for the GL extensions
>>> 
>>>
>>>
>>> I guess the game can't find some extension because of this change.
>> Ahh yes I suppose that would make sense. id tech 3 is famous for bugs
>> with long extension strings, albeit usually it was a crash. But maybe
>> this version there doesn't actually overflow but only considers the
>> first few kB of the string or something along these lines.
>> In this case setting MESA_EXTENSION_MAX_YEAR=2002 or so should help (I'm
>> not sure what extension it would be missing, EXT_stencil_wrap would come
>> to mind, which is listed as 2002 albeit the extension is actually 1999
>> so might have been just available for this game - quake 3 however
>> doesn't use it (it really only uses very few extensions), but not sure
>> about the engine differences for this game, although at least quake3
>> should have printed out if an extension is available or not for all it
>> could potentially use).
>> There's no automatic detection of any of the affected apps by mesa by
>> the looks of it.
>>
>> Roland
>>
>>
>>>
>>> On 2018-09-18 18:37, Roland Scheidegger wrote:
 Am 18.09.2018 um 18:14 schrieb Federico Dossena:
> Upon further investigation, renaming the game to quake3.exe somehow
> forces it to load the system opengl32.dll instead of gallium, so
> that's
> why it worked. I should have checked that.
>
> As I said in my previous email, I have tested every single version of
> Mesa (since 13.0.5 to be exact), and the problem is only present after
> version 18.0.0, all subsequent versions are affected, including the
> current master.
 Ah sorry I missed that I thought you didn't test versions later than
 18.0.


> The glitch must have been introduced when version 18 was in
> development
> and it doesn't affect 17.3.x, that narrows it down to a few hundred
> commits I guess. I will try to do a bisect to find the exact commit
> that
> caused the issue but that's going to take a while since I have to test
> manually. I'll keep you informed.
 Thanks for doing the testing!

 Roland

> On 2018-09-18 17:40, Roland Scheidegger wrote:
>> Am 18.09.2018 um 17:09 schrieb Federico Dossena:
>>> Weapon fire doesn't generate shadows in this game, just a light.
>>>
>>> cg_shadow is set to 3.  Other values don't seem to change anything
>>> except for 2 making the game sluggish.
>>> r_stencilbits is already set to 8.
>>> r_dynamiclights is set to 1; setting it to 0 obviously fixes the
>>> issue
>>> but it's not a solution, you're just disabling dynamic lights.
>>>
>>>   From what I can tell, the glitch affects only the surfaces that
>>> are
>>> affected by dynamic lighting, and it looks like the lighting is
>>> "multiplied" by the dynamic light that's supposed to be added to
>>> that
>>> surface? Does that make any sense? This affects all dynamic
>>> lights in
>>> the game, not just weapons.
>>>
>>> It also looks like Mesa already has some workaround for this,
>>> because if
>>> i rename the game to quake3.exe, it looks correct. Maybe you
>>> could add
>>> stvoy.exe and stvoyHM.exe to that list.
>> I don't see quake3.exe in the list of workarounds, so this seems very
>> very odd.
>>
>>
>>> Is there some way I can help you figure out the problem? Do you
>>> want a
>>> trace?
>> Could you try with a newer version?
>> Otherwise if you could do a git bisect that would help, a trace
>> would be

Re: [Mesa-dev] [PATCH 19/26] nir/linker: use only the array element type for array of ssbo/ubo

[Timothy Arceri]

On 19/9/18 7:59 pm, Alejandro Piñeiro wrote:

On 19/09/18 07:20, Timothy Arceri wrote:

On 16/9/18 2:18 am, Alejandro Piñeiro wrote:

For this interfaces, the inner members are added only once as uniforms
or resources, in opposite to other cases, like a uniform array of
structs.
---
   src/compiler/glsl/gl_nir_link_uniforms.c | 26
--
   1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/gl_nir_link_uniforms.c
b/src/compiler/glsl/gl_nir_link_uniforms.c
index 00995fb3f76..c692cd0171f 100644
--- a/src/compiler/glsl/gl_nir_link_uniforms.c
+++ b/src/compiler/glsl/gl_nir_link_uniforms.c
@@ -498,11 +498,33 @@ gl_nir_link_uniforms(struct gl_context *ctx,
      state.current_var = var;
   + /*
+  * From OpenGL 4.6 spec, section 7.3.1.1, "Naming Active
Resources":
+  *
+  *   "* For an active shader storage block member declared
as an
+  *  array of an aggregate type, an entry will be
generated only
+  *  for the first array element, regardless of its
type. Such
+  *  block members are referred to as top-level arrays.
If the
+  *  block member is an aggregate type, the enumeration
rules are
+  *  then applied recursively.
+  *    * For an active interface block not declared as an
array of
+  *  block instances, a single entry will be generated,
using the
+  *  block name from the shader source."
+  *
+  * So for the UBO and SSBO case, we expand only the array
element
+  * type.
+  */
+ const struct glsl_type *type = var->type;
+ if (nir_variable_is_in_block(var) &&
+ glsl_type_is_array(type)) {
+    type = glsl_get_array_element(type);


This also strips away vector and matrix type information while leaving
arrays for anything but a single dimension array.


Well, but the idea behind this patch is getting a single dimension
array.


I think you mean getting a single element of an array?


We are using the type to populate the uniforms, and as mentioned
on the spec quote, for ubo/ssbo and recursively for his entries, it is
done just once, no matter the dimension of the ubo/ssbo array.

Also not sure why do you mean that we would lose matrix and vector type
information. Could you give an example.


The code for glsl_get_array_element() is:

const glsl_type *
glsl_get_array_element(const glsl_type* type)
{
   if (type->is_matrix())
  return type->column_type();
   else if (type->is_vector())
  return type->get_scalar_type();
   return type->fields.array;
}

I was thinking you might end up stripping away the vec and matrix type 
but as you have glsl_type_is_array(type) in the if condition it is fine.




FWIW, this patch is needed to get this test working:
https://github.com/Igalia/piglit/blob/arb_gl_spirv-series5-ubo-ssbo-v1/tests/spec/arb_gl_spirv/execution/ubo/array-complex.shader_test

and just in case, I have just writing a similar test, slightly more
complex, but with array members and array of matrices members:

https://github.com/Igalia/piglit/blob/arb_gl_spirv-series5-ubo-ssbo-v1/tests/spec/arb_gl_spirv/execution/ubo/array-complex-2.shader_test

And the uniform and variable count is the same on both GLSL and SPIR-V.



Are you sure you don't want the following instead?

type = glsl_get_array_element(type);


Sorry, but isn't that what we are already doing? Or do you mean that we
should made the call always, without the is_in_block and is_array checks?


Apologizes I pasted the wrong thing I meant:

  type = glsl_without_array(type);

However looking more closely at the code and the spec I see that's not 
what you want.


However I'm starting to think the quote from the spec and this code have 
nothing to do with each other.


The spec is taking about top level block member arrays. For example:

layout (std140, binding = 5, row_major) uniform ComponentsBlock
 {
float c1[3];
} components;

However neither of the examples you gave have top level arrays:

layout (std140, binding = 5, row_major) uniform ComponentsBlock
 {
float c1;
vec2 c2;
S s;
} components[2];

My guess is you are using this to remove the array from the block itself 
which is applied when the block is split into separate vars. However the 
logic in this patch will fail when you have arrays of arrays for example:


layout (std140, binding = 5, row_major) uniform ComponentsBlock
 {
float c1;
vec2 c2;
S s;
} components[2][2];

Or even something like:

layout (std140, binding = 5, row_major) uniform ComponentsBlock
 {
float c1[3];
vec2 c2[3];
S s[3];
} components[2];

It's late here and I've only skimmed over other patches in the series so 
if I'm missing something please correct me.







+ }
+
    struct type_tree_entry *type_tree =
-    build_type_tree_for_type(var->type);
+    build_type_tree_for_type(type);
 

[Mesa-dev] [Bug 107939] Commit 888b7fc causes performance regression

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #2 from Samuel Pitoiset  ---
Hi David,

Thanks for reporting this.

Unfortunately the original performance tweak doesn't really work on GFX8, as TC
compatible HTILE for 16-bit depth surfaces is only natively supported on GFX9.

I know that this decreases performance for the shadowmapping demo but the
impact is really tiny for real apps and we can't restore it without introducing
rendering problems in some situations (as explained in the commit message).

It's nice to see that your CI system Vulkan is working. :)

Closing.

-- 
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 6/6] util: disable cache if we have no build-id and timestamp is zero

[Timothy Arceri]

On 19/9/18 9:32 pm, Bas Nieuwenhuizen wrote:

On Wed, Sep 19, 2018 at 4:14 AM Timothy Arceri  wrote:


Timestamp can be zero for example when Flatpack is used. In this
case just disable the cache rather then segfaulting when
incompatible cache items are loaded.
---
  src/amd/vulkan/radv_device.c | 4 
  src/util/disk_cache.h| 6 ++
  2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index f9169d9d012..7d915c68aaa 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -61,10 +61,6 @@ radv_get_build_id(void *ptr, struct mesa_sha1 *ctx)
 } else
  #endif
 if (disk_cache_get_function_timestamp(ptr, )) {
-   if (!timestamp) {
-   fprintf(stderr, "radv: The provided filesystem timestamp for 
the cache is bogus!\n");
-   }
-
 _mesa_sha1_update(ctx, , sizeof(timestamp));
 } else
 return false;
diff --git a/src/util/disk_cache.h b/src/util/disk_cache.h
index 962a26ffc8c..c37acd75830 100644
--- a/src/util/disk_cache.h
+++ b/src/util/disk_cache.h
@@ -102,6 +102,12 @@ disk_cache_get_function_timestamp(void *ptr, uint32_t* 
timestamp)
return false;
 }
 *timestamp = st.st_mtime;
+
+   if (!timestamp) {
+  fprintf(stderr, "Mesa: The provided filesystem timestamp for the cache "
+  "is bogus! Disabling On-disk cache.\n");


Wouldn't this need a "return false;" ?


Whoops. That was the intention here yes.


+   }
+
 return true;
  }

--
2.17.1

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

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


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

Re: [Mesa-dev] [PATCH 6/6] util: disable cache if we have no build-id and timestamp is zero

[Bas Nieuwenhuizen]

On Wed, Sep 19, 2018 at 4:14 AM Timothy Arceri  wrote:
>
> Timestamp can be zero for example when Flatpack is used. In this
> case just disable the cache rather then segfaulting when
> incompatible cache items are loaded.
> ---
>  src/amd/vulkan/radv_device.c | 4 
>  src/util/disk_cache.h| 6 ++
>  2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index f9169d9d012..7d915c68aaa 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -61,10 +61,6 @@ radv_get_build_id(void *ptr, struct mesa_sha1 *ctx)
> } else
>  #endif
> if (disk_cache_get_function_timestamp(ptr, )) {
> -   if (!timestamp) {
> -   fprintf(stderr, "radv: The provided filesystem 
> timestamp for the cache is bogus!\n");
> -   }
> -
> _mesa_sha1_update(ctx, , sizeof(timestamp));
> } else
> return false;
> diff --git a/src/util/disk_cache.h b/src/util/disk_cache.h
> index 962a26ffc8c..c37acd75830 100644
> --- a/src/util/disk_cache.h
> +++ b/src/util/disk_cache.h
> @@ -102,6 +102,12 @@ disk_cache_get_function_timestamp(void *ptr, uint32_t* 
> timestamp)
>return false;
> }
> *timestamp = st.st_mtime;
> +
> +   if (!timestamp) {
> +  fprintf(stderr, "Mesa: The provided filesystem timestamp for the cache 
> "
> +  "is bogus! Disabling On-disk cache.\n");

Wouldn't this need a "return false;" ?
> +   }
> +
> return true;
>  }
>
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: only update framebuffer-state for clears

[Erik Faye-Lund]

On on., sep. 19, 2018 at 1:04 PM, Jakob Bornecrantz 
 wrote:

This patch regresses about 3000 dEQP [2,3,3.1] tests on virgl. Full
setup is dEQP running on virgl with vtest that is running RadeonSI. So
QEMU is not in the picture. All instances of the Mesa driver is from
the same tree and have the patch applied.

Cheers, Jakob.


Hmm, that's a bit odd IMO. Perhaps a full flush is needed when clears 
are implemented using the graphics-pipeline or something? But I don't 
think virgl does this, so hmmm...


I guess I should revert, and try to respin with some more testing...


On Wed, Sep 12, 2018 at 12:05 PM Erik Faye-Lund
 wrote:


 If we update the program-state etc, we risk compiling needless 
shaders,

 which can cost quite a bit of performance.

 Signed-off-by: Erik Faye-Lund 
 ---
 This was motivated by seeing an unexpected shader-compile with
 nonsensical state on start-up in glxgears.

  src/mesa/main/clear.c | 34 --
  1 file changed, 20 insertions(+), 14 deletions(-)

 diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
 index 6beff9ed84..3d2ca490c9 100644
 --- a/src/mesa/main/clear.c
 +++ b/src/mesa/main/clear.c
 @@ -35,6 +35,7 @@
  #include "context.h"
  #include "enums.h"
  #include "fbobject.h"
 +#include "framebuffer.h"
  #include "get.h"
  #include "macros.h"
  #include "mtypes.h"
 @@ -135,10 +136,10 @@ color_buffer_writes_enabled(const struct 
gl_context *ctx, unsigned idx)

   * \param mask bit-mask indicating the buffers to be cleared.
   *
   * Flushes the vertices and verifies the parameter.
 - * If __struct gl_contextRec::NewState is set then calls 
_mesa_update_state()
 - * to update gl_frame_buffer::_Xmin, etc.  If the rasterization 
mode is set to

 - * GL_RENDER then requests the driver to clear the buffers, via the
 - * dd_function_table::Clear callback.
 + * If __struct gl_contextRec::NewState contains _NEW_BUFFERS then 
calls
 + * _mesa_update_framebuffer() to update gl_frame_buffer::_Xmin, 
etc. If the
 + * rasterization mode is set to GL_RENDER then requests the driver 
to clear

 + * the buffers, via the dd_function_table::Clear callback.
   */
  static ALWAYS_INLINE void
  clear(struct gl_context *ctx, GLbitfield mask, bool no_error)
 @@ -165,8 +166,9 @@ clear(struct gl_context *ctx, GLbitfield mask, 
bool no_error)

}
 }

 -   if (ctx->NewState) {
 -  _mesa_update_state( ctx );   /* update _Xmin, etc */
 +   if (ctx->NewState & _NEW_BUFFERS) {
 +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, 
ctx->DrawBuffer); /* update _Xmin, etc */

 +  ctx->NewState &= ~_NEW_BUFFERS;
 }

 if (!no_error && ctx->DrawBuffer->_Status != 
GL_FRAMEBUFFER_COMPLETE_EXT) {
 @@ -346,8 +348,9 @@ clear_bufferiv(struct gl_context *ctx, GLenum 
buffer, GLint drawbuffer,

 FLUSH_VERTICES(ctx, 0);
 FLUSH_CURRENT(ctx, 0);

 -   if (ctx->NewState) {
 -  _mesa_update_state( ctx );
 +   if (ctx->NewState & _NEW_BUFFERS) {
 +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, 
ctx->DrawBuffer);

 +  ctx->NewState &= ~_NEW_BUFFERS;
 }

 switch (buffer) {
 @@ -460,8 +463,9 @@ clear_bufferuiv(struct gl_context *ctx, GLenum 
buffer, GLint drawbuffer,

 FLUSH_VERTICES(ctx, 0);
 FLUSH_CURRENT(ctx, 0);

 -   if (ctx->NewState) {
 -  _mesa_update_state( ctx );
 +   if (ctx->NewState & _NEW_BUFFERS) {
 +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, 
ctx->DrawBuffer);

 +  ctx->NewState &= ~_NEW_BUFFERS;
 }

 switch (buffer) {
 @@ -549,8 +553,9 @@ clear_bufferfv(struct gl_context *ctx, GLenum 
buffer, GLint drawbuffer,

 FLUSH_VERTICES(ctx, 0);
 FLUSH_CURRENT(ctx, 0);

 -   if (ctx->NewState) {
 -  _mesa_update_state( ctx );
 +   if (ctx->NewState & _NEW_BUFFERS) {
 +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, 
ctx->DrawBuffer);

 +  ctx->NewState &= ~_NEW_BUFFERS;
 }

 switch (buffer) {
 @@ -691,8 +696,9 @@ clear_bufferfi(struct gl_context *ctx, GLenum 
buffer, GLint drawbuffer,

 if (ctx->RasterDiscard)
return;

 -   if (ctx->NewState) {
 -  _mesa_update_state( ctx );
 +   if (ctx->NewState & _NEW_BUFFERS) {
 +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, 
ctx->DrawBuffer);

 +  ctx->NewState &= ~_NEW_BUFFERS;
 }

 if (ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer)
 --
 2.17.1

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

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


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

Re: [Mesa-dev] [PATCH] mesa: only update framebuffer-state for clears

[Jakob Bornecrantz]

This patch regresses about 3000 dEQP [2,3,3.1] tests on virgl. Full
setup is dEQP running on virgl with vtest that is running RadeonSI. So
QEMU is not in the picture. All instances of the Mesa driver is from
the same tree and have the patch applied.

Cheers, Jakob.
On Wed, Sep 12, 2018 at 12:05 PM Erik Faye-Lund
 wrote:
>
> If we update the program-state etc, we risk compiling needless shaders,
> which can cost quite a bit of performance.
>
> Signed-off-by: Erik Faye-Lund 
> ---
> This was motivated by seeing an unexpected shader-compile with
> nonsensical state on start-up in glxgears.
>
>  src/mesa/main/clear.c | 34 --
>  1 file changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
> index 6beff9ed84..3d2ca490c9 100644
> --- a/src/mesa/main/clear.c
> +++ b/src/mesa/main/clear.c
> @@ -35,6 +35,7 @@
>  #include "context.h"
>  #include "enums.h"
>  #include "fbobject.h"
> +#include "framebuffer.h"
>  #include "get.h"
>  #include "macros.h"
>  #include "mtypes.h"
> @@ -135,10 +136,10 @@ color_buffer_writes_enabled(const struct gl_context 
> *ctx, unsigned idx)
>   * \param mask bit-mask indicating the buffers to be cleared.
>   *
>   * Flushes the vertices and verifies the parameter.
> - * If __struct gl_contextRec::NewState is set then calls _mesa_update_state()
> - * to update gl_frame_buffer::_Xmin, etc.  If the rasterization mode is set 
> to
> - * GL_RENDER then requests the driver to clear the buffers, via the
> - * dd_function_table::Clear callback.
> + * If __struct gl_contextRec::NewState contains _NEW_BUFFERS then calls
> + * _mesa_update_framebuffer() to update gl_frame_buffer::_Xmin, etc. If the
> + * rasterization mode is set to GL_RENDER then requests the driver to clear
> + * the buffers, via the dd_function_table::Clear callback.
>   */
>  static ALWAYS_INLINE void
>  clear(struct gl_context *ctx, GLbitfield mask, bool no_error)
> @@ -165,8 +166,9 @@ clear(struct gl_context *ctx, GLbitfield mask, bool 
> no_error)
>}
> }
>
> -   if (ctx->NewState) {
> -  _mesa_update_state( ctx );   /* update _Xmin, etc */
> +   if (ctx->NewState & _NEW_BUFFERS) {
> +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer); /* 
> update _Xmin, etc */
> +  ctx->NewState &= ~_NEW_BUFFERS;
> }
>
> if (!no_error && ctx->DrawBuffer->_Status != GL_FRAMEBUFFER_COMPLETE_EXT) 
> {
> @@ -346,8 +348,9 @@ clear_bufferiv(struct gl_context *ctx, GLenum buffer, 
> GLint drawbuffer,
> FLUSH_VERTICES(ctx, 0);
> FLUSH_CURRENT(ctx, 0);
>
> -   if (ctx->NewState) {
> -  _mesa_update_state( ctx );
> +   if (ctx->NewState & _NEW_BUFFERS) {
> +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer);
> +  ctx->NewState &= ~_NEW_BUFFERS;
> }
>
> switch (buffer) {
> @@ -460,8 +463,9 @@ clear_bufferuiv(struct gl_context *ctx, GLenum buffer, 
> GLint drawbuffer,
> FLUSH_VERTICES(ctx, 0);
> FLUSH_CURRENT(ctx, 0);
>
> -   if (ctx->NewState) {
> -  _mesa_update_state( ctx );
> +   if (ctx->NewState & _NEW_BUFFERS) {
> +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer);
> +  ctx->NewState &= ~_NEW_BUFFERS;
> }
>
> switch (buffer) {
> @@ -549,8 +553,9 @@ clear_bufferfv(struct gl_context *ctx, GLenum buffer, 
> GLint drawbuffer,
> FLUSH_VERTICES(ctx, 0);
> FLUSH_CURRENT(ctx, 0);
>
> -   if (ctx->NewState) {
> -  _mesa_update_state( ctx );
> +   if (ctx->NewState & _NEW_BUFFERS) {
> +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer);
> +  ctx->NewState &= ~_NEW_BUFFERS;
> }
>
> switch (buffer) {
> @@ -691,8 +696,9 @@ clear_bufferfi(struct gl_context *ctx, GLenum buffer, 
> GLint drawbuffer,
> if (ctx->RasterDiscard)
>return;
>
> -   if (ctx->NewState) {
> -  _mesa_update_state( ctx );
> +   if (ctx->NewState & _NEW_BUFFERS) {
> +  _mesa_update_framebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer);
> +  ctx->NewState &= ~_NEW_BUFFERS;
> }
>
> if (ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer)
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107989] GLES 3.x context: GL_INVALID_OPERATION in glGenerateMipmap(invalid internal format GL_RED)

[bugzilla-daemon]

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

--- Comment #1 from Tapani Pälli  ---
For me it seems this behavior is according to the OpenGL ES spec:

"An INVALID_OPERATION error is generated if the level base array was not
specified with an unsized internal format from table 8.3 or a sized internal
for-
mat that is both color-renderable and texture-filterable according to table
8.10."

Table 8.3 does not list GL_RED.

-- 
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 19/26] nir/linker: use only the array element type for array of ssbo/ubo

[Alejandro Piñeiro]

On 19/09/18 07:20, Timothy Arceri wrote:
> On 16/9/18 2:18 am, Alejandro Piñeiro wrote:
>> For this interfaces, the inner members are added only once as uniforms
>> or resources, in opposite to other cases, like a uniform array of
>> structs.
>> ---
>>   src/compiler/glsl/gl_nir_link_uniforms.c | 26
>> --
>>   1 file changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/compiler/glsl/gl_nir_link_uniforms.c
>> b/src/compiler/glsl/gl_nir_link_uniforms.c
>> index 00995fb3f76..c692cd0171f 100644
>> --- a/src/compiler/glsl/gl_nir_link_uniforms.c
>> +++ b/src/compiler/glsl/gl_nir_link_uniforms.c
>> @@ -498,11 +498,33 @@ gl_nir_link_uniforms(struct gl_context *ctx,
>>      state.current_var = var;
>>   + /*
>> +  * From OpenGL 4.6 spec, section 7.3.1.1, "Naming Active
>> Resources":
>> +  *
>> +  *   "* For an active shader storage block member declared
>> as an
>> +  *  array of an aggregate type, an entry will be
>> generated only
>> +  *  for the first array element, regardless of its
>> type. Such
>> +  *  block members are referred to as top-level arrays.
>> If the
>> +  *  block member is an aggregate type, the enumeration
>> rules are
>> +  *  then applied recursively.
>> +  *    * For an active interface block not declared as an
>> array of
>> +  *  block instances, a single entry will be generated,
>> using the
>> +  *  block name from the shader source."
>> +  *
>> +  * So for the UBO and SSBO case, we expand only the array
>> element
>> +  * type.
>> +  */
>> + const struct glsl_type *type = var->type;
>> + if (nir_variable_is_in_block(var) &&
>> + glsl_type_is_array(type)) {
>> +    type = glsl_get_array_element(type);
>
> This also strips away vector and matrix type information while leaving
> arrays for anything but a single dimension array.

Well, but the idea behind this patch is getting a single dimension
array. We are using the type to populate the uniforms, and as mentioned
on the spec quote, for ubo/ssbo and recursively for his entries, it is
done just once, no matter the dimension of the ubo/ssbo array.

Also not sure why do you mean that we would lose matrix and vector type
information. Could you give an example.

FWIW, this patch is needed to get this test working:
https://github.com/Igalia/piglit/blob/arb_gl_spirv-series5-ubo-ssbo-v1/tests/spec/arb_gl_spirv/execution/ubo/array-complex.shader_test

and just in case, I have just writing a similar test, slightly more
complex, but with array members and array of matrices members:

https://github.com/Igalia/piglit/blob/arb_gl_spirv-series5-ubo-ssbo-v1/tests/spec/arb_gl_spirv/execution/ubo/array-complex-2.shader_test

And the uniform and variable count is the same on both GLSL and SPIR-V.

>
> Are you sure you don't want the following instead?
>
> type = glsl_get_array_element(type);

Sorry, but isn't that what we are already doing? Or do you mean that we
should made the call always, without the is_in_block and is_array checks?

>
>> + }
>> +
>>    struct type_tree_entry *type_tree =
>> -    build_type_tree_for_type(var->type);
>> +    build_type_tree_for_type(type);
>>    state.current_type = type_tree;
>>   - int res = nir_link_uniform(ctx, prog, sh->Program,
>> shader_type, var->type,
>> + int res = nir_link_uniform(ctx, prog, sh->Program,
>> shader_type, type,
>>   location, );
>>      free_type_tree(type_tree);
>>
>

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

Re: [Mesa-dev] [PATCH] nir: add initializer data to fix MSVC compile error

[Juan A. Suarez Romero]

On Wed, 2018-09-19 at 11:40 +0200, Juan A. Suarez Romero wrote:
> CC: Jason Ekstrand 
> Fixes: 82799a5d1b8 ("nir: Add a small pass to rematerialize derefs

 ^^^
 7d1d1208c2b

I've committed a mistake when referring the commit it fixes.


> per-block")
> ---
>  src/compiler/nir/nir_deref.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/compiler/nir/nir_deref.c b/src/compiler/nir/nir_deref.c
> index 1a3bf4ad206..4a87ee84d8a 100644
> --- a/src/compiler/nir/nir_deref.c
> +++ b/src/compiler/nir/nir_deref.c
> @@ -481,7 +481,7 @@ rematerialize_deref_src(nir_src *src, void *_state)
>  bool
>  nir_rematerialize_derefs_in_use_blocks_impl(nir_function_impl *impl)
>  {
> -   struct rematerialize_deref_state state = { };
> +   struct rematerialize_deref_state state = { 0 };
> nir_builder_init(, impl);
>  
> nir_foreach_block(block, impl) {

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

[Mesa-dev] [AppVeyor] mesa master #8903 completed

[AppVeyor]

Build mesa 8903 completed



Commit 0c82e3603e by Juan A. Suarez Romero on 9/19/2018 9:27 AM:

nir: add initializer data to fix MSVC compile error\n\nCC: Jason Ekstrand \nFixes: 82799a5d1b8 ("nir: Add a small pass to rematerialize derefs\nper-block")\nReviewed-by: Samuel Iglesias Gonsálvez 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH] nir: add initializer data to fix MSVC compile error

[Samuel Iglesias Gonsálvez]

Reviewed-by: Samuel Iglesias Gonsálvez 



On 19/09/18 11:40, Juan A. Suarez Romero wrote:
> CC: Jason Ekstrand 
> Fixes: 82799a5d1b8 ("nir: Add a small pass to rematerialize derefs
> per-block")
> ---
>  src/compiler/nir/nir_deref.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/nir/nir_deref.c b/src/compiler/nir/nir_deref.c
> index 1a3bf4ad206..4a87ee84d8a 100644
> --- a/src/compiler/nir/nir_deref.c
> +++ b/src/compiler/nir/nir_deref.c
> @@ -481,7 +481,7 @@ rematerialize_deref_src(nir_src *src, void *_state)
>  bool
>  nir_rematerialize_derefs_in_use_blocks_impl(nir_function_impl *impl)
>  {
> -   struct rematerialize_deref_state state = { };
> +   struct rematerialize_deref_state state = { 0 };
> nir_builder_init(, impl);
>  
> nir_foreach_block(block, impl) {



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

[Mesa-dev] [PATCH] nir: add initializer data to fix MSVC compile error

[Juan A. Suarez Romero]

CC: Jason Ekstrand 
Fixes: 82799a5d1b8 ("nir: Add a small pass to rematerialize derefs
per-block")
---
 src/compiler/nir/nir_deref.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_deref.c b/src/compiler/nir/nir_deref.c
index 1a3bf4ad206..4a87ee84d8a 100644
--- a/src/compiler/nir/nir_deref.c
+++ b/src/compiler/nir/nir_deref.c
@@ -481,7 +481,7 @@ rematerialize_deref_src(nir_src *src, void *_state)
 bool
 nir_rematerialize_derefs_in_use_blocks_impl(nir_function_impl *impl)
 {
-   struct rematerialize_deref_state state = { };
+   struct rematerialize_deref_state state = { 0 };
nir_builder_init(, impl);
 
nir_foreach_block(block, impl) {
-- 
2.17.1

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

[Mesa-dev] [Bug 107989] GLES 3.x context: GL_INVALID_OPERATION in glGenerateMipmap(invalid internal format GL_RED)

[bugzilla-daemon]

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

Bug ID: 107989
   Summary: GLES 3.x context: GL_INVALID_OPERATION in
glGenerateMipmap(invalid internal format GL_RED)
   Product: Mesa
   Version: 18.2
  Hardware: All
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: 0x416b617...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Trying to call glGenerateMipmap on a texture with the internal format of GL_RED
in an OpenGL ES 3.x context produces a GL_INVALID_OPERATION error. Explicitly
sized formats such as GL_R8 work, and so do other formats with no size
specified, such as GL_RGBA. Core context is not affected. Tested with the
radeonsi and llvmpipe drivers.

-- 
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] docs: Update FAQ with respect to s3tc support

[Stuart Young]

It's just over 10 months since 17.3.0 was released with s3tc support enabled.
Probably a good idea to update the FAQ page.

CC: 

---
 docs/faq.html | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/docs/faq.html b/docs/faq.html
index 1f2fd66034..3d0010885a 100644
--- a/docs/faq.html
+++ b/docs/faq.html
@@ -16,7 +16,7 @@
 
 
 Mesa Frequently Asked Questions
-Last updated: 9 October 2012
+Last updated: 19 September 2018
 
 
 
@@ -371,20 +371,17 @@ the archives) is a good way to get information.
 
 
 
-4.3 Why isn't GL_EXT_texture_compression_s3tc implemented in Mesa?
+4.3 The GL_EXT_texture_compression_s3tc feature and Mesa?
 
-The http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt;>specification
 for the extension
-indicates that there are intellectual property (IP) and/or patent issues
-to be dealt with.
+Prior to 2nd October 2017, the Mesa project did not include s3tc support due
+to intellectual property (IP) and/or patent issues around the s3tc algorithm.
 
-We've been unsuccessful in getting a response from S3 (or whoever owns
-the IP nowadays) to indicate whether or not an open source project can
-implement the extension (specifically the compression/decompression
-algorithms).
+
+As of Mesa 17.3.0, Mesa now officially supports s3tc, as the patent has 
expired.
 
 
-In the mean time, a 3rd party https://dri.freedesktop.org/wiki/S3TC;>
-plug-in library is available.
+In versions prior to this, a 3rd party https://dri.freedesktop.org/wiki/S3TC;>
+plug-in library was required.
 
 
 
-- 
2.11.0

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

[Mesa-dev] [AppVeyor] mesa master #8902 failed

[AppVeyor]

Build mesa 8902 failed


Commit 976046a8d8 by Jason Ekstrand on 9/11/2018 6:06 PM:

nir: Add some asserts that we don't put derefs in phis\n\nThe lcssa and phis_to_regs passes are used by various NIR optimizations\nthat modify the CFG.  Putting a couple of asserts will help ensure that\nwe don't accidentally put derefs in phis as part of an optimization\npass.\n\nReviewed-by: Iago Toral Quiroga 


Configure your notification preferences

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

[Mesa-dev] [Bug 107977] Commit 90819abb56f6b1a0cd4946b13b6caf24fb46e500 crashes dolphin-emu with "Failed to create Vulkan command buffers"

[bugzilla-daemon]

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

--- Comment #17 from kyle.de...@mykolab.com ---
Can you explain why it was a bug in Mesa? Just trying to understand why the
change broke things.

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