[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

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

[Iago Toral]

On Tue, 2018-09-18 at 07:27 -0500, Jason Ekstrand wrote:
> On Tue, Sep 18, 2018 at 4:11 AM Iago Toral  wrote:
> > Hi Jason,
> > 
> > 
> > 
> > I left a few comments in patches 1 and 4, feel free to ignore them
> > if
> > 
> > you think they are not relevant. Either way the series is:
> 
> I would like to back-port this to 18.2 if you don't mind.  I think
> it's far more accurate than what we were doing before to try and
> avoid derefs in phis.

Sure, sounds good to me.
Iago
> --Jason
>  
> > Reviewed-by: Iago Toral Quiroga 
> > 
> > 
> > 
> > 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.
> > 
> > > ---
> > 
> > >  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 = &state->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(&parent->dest.ssa);
> > 
> > > +  } else {
> > 
> > > + nir_src_copy(&new_deref->parent, &deref->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(&new_deref->arr.index, &deref->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(&new_deref->instr, &

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

[Timothy Arceri]

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.


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

type = glsl_get_array_element(type);


+ }
+
   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, &state);
  
   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] shader cache backward compatibility

[Timothy Arceri]

On 3/9/18 6:53 pm, Alexander Larsson wrote:

On Mon, Sep 3, 2018 at 10:41 AM Alexander Larsson  wrote:


On Fri, Aug 31, 2018 at 4:05 PM Emil Velikov  wrote:


Valid point - I forgot about that.

A couple of ideas come to mind:
  - static link LLVM (Flatpak already does it)
No LLVM changes needed.

  - shared link LLVM
LLVM add -Wl,--build-id=sha1


As a very very simple workaround, can you add the file sizes (as well
as the mtimes) to the staleness check? I mean, its possible that a
rebuild generates the exact same size, but at least its better than
always being wrong.


Also, valentin david (of the freedesktop sdk project) started working
on a solution based on build-ids:
  https://gitlab.com/freedesktop-sdk/freedesktop-sdk/merge_requests/487/diffs

This currently relies on the freedesktop sdk having build-ids, but it
would be easy for it to fall back on the mtime if that was not found.
Also, this code is not really tested yet, but you still get the idea
from looking at it, and it should work.



I've sent a new series [1] to use build-id by default and fallback to 
timestamp. If timestamp is zero we will disable the cache. On RADV a 
zero timestamp  would mean the driver would fail to initialise, but it 
seem Intels ANV currently already does this if no build id is found so 
its still being pretty forgiving.


[1] https://patchwork.freedesktop.org/series/49882/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/6] util: rename timestamp param in disk_cache_create()

[Timothy Arceri]

Only some drivers use a timestamp here. Others use things such
as build-id, or even a combination of build-ids from Mesa and
LLVM.
---
 src/util/disk_cache.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index 87ddfb86b27..368ec417927 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -189,7 +189,7 @@ do {   \
 } while (0);
 
 struct disk_cache *
-disk_cache_create(const char *gpu_name, const char *timestamp,
+disk_cache_create(const char *gpu_name, const char *driver_id,
   uint64_t driver_flags)
 {
void *local;
@@ -387,9 +387,9 @@ disk_cache_create(const char *gpu_name, const char 
*timestamp,
cache->driver_keys_blob_size = cv_size;
 
/* Create driver id keys */
-   size_t ts_size = strlen(timestamp) + 1;
+   size_t id_size = strlen(driver_id) + 1;
size_t gpu_name_size = strlen(gpu_name) + 1;
-   cache->driver_keys_blob_size += ts_size;
+   cache->driver_keys_blob_size += id_size;
cache->driver_keys_blob_size += gpu_name_size;
 
/* We sometimes store entire structs that contains a pointers in the cache,
@@ -409,7 +409,7 @@ disk_cache_create(const char *gpu_name, const char 
*timestamp,
 
uint8_t *drv_key_blob = cache->driver_keys_blob;
DRV_KEY_CPY(drv_key_blob, &cache_version, cv_size)
-   DRV_KEY_CPY(drv_key_blob, timestamp, ts_size)
+   DRV_KEY_CPY(drv_key_blob, driver_id, id_size)
DRV_KEY_CPY(drv_key_blob, gpu_name, gpu_name_size)
DRV_KEY_CPY(drv_key_blob, &ptr_size, ptr_size_size)
DRV_KEY_CPY(drv_key_blob, &driver_flags, driver_flags_size)
-- 
2.17.1

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

[Mesa-dev] [PATCH 4/6] nouveau: use build-id when available for disk cache

[Timothy Arceri]

---
 src/gallium/drivers/nouveau/nouveau_screen.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
b/src/gallium/drivers/nouveau/nouveau_screen.c
index c97b707955c..eb184d3559b 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -148,18 +148,18 @@ nouveau_screen_bo_get_handle(struct pipe_screen *pscreen,
 static void
 nouveau_disk_cache_create(struct nouveau_screen *screen)
 {
-   uint32_t mesa_timestamp;
-   char *timestamp_str;
+   uint32_t mesa_id;
+   char *mesa_id_str;
int res;
 
-   if (disk_cache_get_function_timestamp(nouveau_disk_cache_create,
- &mesa_timestamp)) {
-  res = asprintf(×tamp_str, "%u", mesa_timestamp);
+   if (disk_cache_get_function_identifier(nouveau_disk_cache_create,
+  &mesa_id)) {
+  res = asprintf(&mesa_id_str, "%u", mesa_id);
   if (res != -1) {
  screen->disk_shader_cache =
 disk_cache_create(nouveau_screen_get_name(&screen->base),
-  timestamp_str, 0);
- free(timestamp_str);
+  mesa_id_str, 0);
+ free(mesa_id_str);
   }
}
 }
-- 
2.17.1

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

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

[Timothy Arceri]

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, ×tamp)) {
-   if (!timestamp) {
-   fprintf(stderr, "radv: The provided filesystem 
timestamp for the cache is bogus!\n");
-   }
-
_mesa_sha1_update(ctx, ×tamp, sizeof(timestamp));
} else
return false;
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");
+   }
+
return true;
 }
 
-- 
2.17.1

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

[Mesa-dev] [PATCH 5/6] r600: use build-id when available for disk cache

[Timothy Arceri]

---
 src/gallium/drivers/r600/r600_pipe_common.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_pipe_common.c 
b/src/gallium/drivers/r600/r600_pipe_common.c
index f7cfd0d46a6..6b581242a18 100644
--- a/src/gallium/drivers/r600/r600_pipe_common.c
+++ b/src/gallium/drivers/r600/r600_pipe_common.c
@@ -854,13 +854,13 @@ static void r600_disk_cache_create(struct 
r600_common_screen *rscreen)
if (rscreen->debug_flags & DBG_ALL_SHADERS)
return;
 
-   uint32_t mesa_timestamp;
-   if (disk_cache_get_function_timestamp(r600_disk_cache_create,
- &mesa_timestamp)) {
-   char *timestamp_str;
+   uint32_t mesa_id;
+   if (disk_cache_get_function_identifier(r600_disk_cache_create,
+  &mesa_id)) {
+   char *mesa_id_str;
int res = -1;
 
-   res = asprintf(×tamp_str, "%u",mesa_timestamp);
+   res = asprintf(&mesa_id_str, "%u", mesa_id);
if (res != -1) {
/* These flags affect shader compilation. */
uint64_t shader_debug_flags =
@@ -870,9 +870,9 @@ static void r600_disk_cache_create(struct 
r600_common_screen *rscreen)
 
rscreen->disk_shader_cache =
disk_cache_create(r600_get_family_name(rscreen),
- timestamp_str,
+ mesa_id_str,
  shader_debug_flags);
-   free(timestamp_str);
+   free(mesa_id_str);
}
}
 }
-- 
2.17.1

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

[Mesa-dev] [PATCH 3/6] radeonsi: use build-id when available for disk cache

[Timothy Arceri]

---
 src/gallium/drivers/radeonsi/si_pipe.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 82af9dd1de7..c38b754bf20 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -768,17 +768,14 @@ static void si_disk_cache_create(struct si_screen 
*sscreen)
if (sscreen->debug_flags & DBG_ALL_SHADERS)
return;
 
-   uint32_t mesa_timestamp;
-   if (disk_cache_get_function_timestamp(si_disk_cache_create,
- &mesa_timestamp)) {
-   char *timestamp_str;
+   uint32_t mesa_id;
+   if (disk_cache_get_function_identifier(si_disk_cache_create, &mesa_id)) 
{
+   char *driver_id_str;
int res = -1;
-   uint32_t llvm_timestamp;
-
-   if 
(disk_cache_get_function_timestamp(LLVMInitializeAMDGPUTargetInfo,
- &llvm_timestamp)) {
-   res = asprintf(×tamp_str, "%u_%u",
-  mesa_timestamp, llvm_timestamp);
+   uint32_t llvm_id;
+   if 
(disk_cache_get_function_identifier(LLVMInitializeAMDGPUTargetInfo,
+  &llvm_id)) {
+   res = asprintf(&driver_id_str, "%u_%u", mesa_id, 
llvm_id);
}
 
if (res != -1) {
@@ -799,9 +796,9 @@ static void si_disk_cache_create(struct si_screen *sscreen)
 
sscreen->disk_shader_cache =
disk_cache_create(sscreen->info.name,
- timestamp_str,
+ driver_id_str,
  shader_debug_flags);
-   free(timestamp_str);
+   free(driver_id_str);
}
}
 }
-- 
2.17.1

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

[Mesa-dev] [PATCH 2/6] util: add disk_cache_get_function_identifier()

[Timothy Arceri]

This can be used as a drop in replacement for
disk_cache_get_function_timestamp().

Here we use build-id to generate a driver-id rather than build
timestamp if available. This should resolve issues such as
distros using reproducable builds and flatpack not having
real build timestamps.
---
 src/util/disk_cache.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/util/disk_cache.h b/src/util/disk_cache.h
index 50bd9f41ac4..962a26ffc8c 100644
--- a/src/util/disk_cache.h
+++ b/src/util/disk_cache.h
@@ -26,6 +26,7 @@
 
 #ifdef HAVE_DLFCN_H
 #include 
+#include "util/build_id.h"
 #endif
 #include 
 #include 
@@ -103,6 +104,21 @@ disk_cache_get_function_timestamp(void *ptr, uint32_t* 
timestamp)
*timestamp = st.st_mtime;
return true;
 }
+
+static inline bool
+disk_cache_get_function_identifier(void *ptr, uint32_t *id)
+{
+#ifdef HAVE_DL_ITERATE_PHDR
+   const struct build_id_note *note = NULL;
+   if ((note = build_id_find_nhdr_for_addr(ptr))) {
+  const uint8_t *id_sha1 = build_id_data(note);
+  assert(id_sha1);
+  *id = *id_sha1;
+  return true;
+   } else
+#endif
+   return disk_cache_get_function_timestamp(ptr, id);
+}
 #endif
 
 /* Provide inlined stub functions if the shader cache is disabled. */
-- 
2.17.1

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

[Mesa-dev] [Bug 107986] Black window when HiZ enabled

[bugzilla-daemon]

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

--- Comment #3 from Bas Nieuwenhuizen  ---
Well, can reproduce here using the provided application. I'll look into this
later this week.

-- 
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 107986] Black window when HiZ enabled

[bugzilla-daemon]

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

--- Comment #2 from programmerj...@gmail.com ---
note that the trace plays just fine using AMDVLK

-- 
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] [Mesa-stable] [PATCH 1/2] radv: Set the user SGPR MSB for Vega.

[Bas Nieuwenhuizen]

On Wed, Sep 19, 2018 at 1:46 AM Dylan Baker  wrote:
>
> Quoting Bas Nieuwenhuizen (2018-09-16 03:30:55)
> > Otherwise using 32 user SGPRs would be broken.
> >
> > CC: 
> > ---
> >  src/amd/vulkan/radv_shader.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
> > index e05961339ca..51e0b7d65fc 100644
> > --- a/src/amd/vulkan/radv_shader.c
> > +++ b/src/amd/vulkan/radv_shader.c
> > @@ -408,6 +408,7 @@ radv_fill_shader_variant(struct radv_device *device,
> >
> > variant->code_size = radv_get_shader_binary_size(binary);
> > variant->rsrc2 = S_00B12C_USER_SGPR(variant->info.num_user_sgprs) |
> > +
> > S_00B12C_USER_SGPR_MSB(variant->info.num_user_sgprs >> 5) |
> >  S_00B12C_SCRATCH_EN(scratch_enabled);
> >
> > variant->rsrc1 = S_00B848_VGPRS((variant->config.num_vgprs - 1) / 
> > 4) |
> > --
> > 2.19.0
> >
>
> Hi Bas,
>
> both of these had minor merge conflicts going into the staging/18.1 branch.
> Would you mind double checking and making sure that everything looks good for
> me?
It does, thanks!

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] radv: Set the user SGPR MSB for Vega.

[Dylan Baker]

Quoting Bas Nieuwenhuizen (2018-09-16 03:30:55)
> Otherwise using 32 user SGPRs would be broken.
> 
> CC: 
> ---
>  src/amd/vulkan/radv_shader.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
> index e05961339ca..51e0b7d65fc 100644
> --- a/src/amd/vulkan/radv_shader.c
> +++ b/src/amd/vulkan/radv_shader.c
> @@ -408,6 +408,7 @@ radv_fill_shader_variant(struct radv_device *device,
>  
> variant->code_size = radv_get_shader_binary_size(binary);
> variant->rsrc2 = S_00B12C_USER_SGPR(variant->info.num_user_sgprs) |
> +S_00B12C_USER_SGPR_MSB(variant->info.num_user_sgprs 
> >> 5) |
>  S_00B12C_SCRATCH_EN(scratch_enabled);
>  
> variant->rsrc1 = S_00B848_VGPRS((variant->config.num_vgprs - 1) / 4) |
> -- 
> 2.19.0
> 

Hi Bas,

both of these had minor merge conflicts going into the staging/18.1 branch.
Would you mind double checking and making sure that everything looks good for
me?

Thanks,
Dylan


signature.asc
Description: signature
___
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

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Resolution|NOTOURBUG   |FIXED

--- Comment #16 from Bas Nieuwenhuizen  ---
You are right, a revert of 90819abb56f6b1a0cd4946b13b6caf24fb46e500 has been
pushed.

-- 
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 107986] Black window when HiZ enabled

[bugzilla-daemon]

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

--- Comment #1 from programmerj...@gmail.com ---
My code seems to be causing a crash in NVidia's Vulkan driver, see
https://github.com/programmerjake/hashlife3d/issues/1#issuecomment-421829804

-- 
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 107986] Black window when HiZ enabled

[bugzilla-daemon]

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

programmerj...@gmail.com changed:

   What|Removed |Added

 CC||programmerj...@gmail.com

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

[Mesa-dev] [Bug 107986] Black window when HiZ enabled

[bugzilla-daemon]

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

Bug ID: 107986
   Summary: Black window when HiZ enabled
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: programmerj...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 141649
  --> https://bugs.freedesktop.org/attachment.cgi?id=141649&action=edit
vktrace vulkan api trace

I'm building a Vulkan game, and I get a black window when I don't use
RADV_DEBUG=nohiz unless the window area is less than about 250k px^2. If I
resize the window to smaller than that, then it seems to work fine (except
maybe for some probably unrelated sRGB/gamma issues) even if it's really tall
and narrow or really wide and short.

It's possible I'm doing something wrong with the Vulkan API but I have not been
able to find where I'm messing up.

I'd guess that there is a memory allocation issue when allocating more than a
256k px depth buffer.

I have a RX 580 8GB.
I'm running on Ubuntu Linux 18.04 with kernel 4.15.0-34-generic
I'm using Mesa git from oibaf's ppa using version
18.3~git1809181930.c9dbe5~oibaf~b
I have Xorg version 1:7.7+19ubuntu7.1

I've attached a vktrace using LunarG's Vulkan SDK at version 1.1.77.0

I can reproduce the problem using just the vktrace, but for those who are
interested, my source code is available at
https://github.com/programmerjake/hashlife3d at commit
9d43f3ba82ba5d3d721a81e61da4dfed20a2926b

I am using SDL 2.0.8 built from source as until recently, SDL's vulkan bindings
were disabled in Debian's package.

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

[Dylan Baker]

Quoting Adam Jackson (2018-09-18 13:57:18)
> On Tue, 2018-09-18 at 13:50 -0700, Dylan Baker wrote:
> 
> > > 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). 
> > 
> > This is impossible by design. Meson is very specific that its internal 
> > directory
> > layout is an implementation detail. On top of that, there are two different
> > backends, a VS and ninja backend, which have slightly different layouts.
> 
> I'm not entirely sure that's true? mesa/build-lib/meson.build could
> have all the final link targets, and their results would show up in
> mesa/${builddir}/build-lib. It'd mean mirroring all the "do I build
> this target or not" logic in that meson.build, and you'd descend into
> that directory last from the top-level mesa/meson.build, but...

Unless you pass --layout=flat (I don't think any released versions have this 
yet).
Or upstream decides it wants to change something. It's playing with fire either
way, since upstream is very clear that you should not rely on it.

Dylan


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

[Mesa-dev] [PATCH 2/2] radv: Support VK_EXT_inline_uniform_block.

[Bas Nieuwenhuizen]

Basically just reserve the memory in the descriptor sets.

On the shader side we construct a buffer descriptor, since
AFAIU VGPR indexing on 32-bit pointers in LLVM is still broken.

This fully supports update after bind and variable descriptor set
sizes. However, the limits are somewhat arbitrary and are mostly
about finding a reasonable division of a 2 GiB max memory size over
the set.
---
 src/amd/vulkan/radv_descriptor_set.c | 83 
 src/amd/vulkan/radv_device.c | 22 +++-
 src/amd/vulkan/radv_extensions.py|  1 +
 src/amd/vulkan/radv_nir_to_llvm.c| 31 +--
 src/amd/vulkan/radv_private.h|  2 +
 5 files changed, 122 insertions(+), 17 deletions(-)

diff --git a/src/amd/vulkan/radv_descriptor_set.c 
b/src/amd/vulkan/radv_descriptor_set.c
index c4341f6ac52..bbdc866852a 100644
--- a/src/amd/vulkan/radv_descriptor_set.c
+++ b/src/amd/vulkan/radv_descriptor_set.c
@@ -125,6 +125,7 @@ VkResult radv_CreateDescriptorSetLayout(
uint32_t b = binding->binding;
uint32_t alignment;
unsigned binding_buffer_count = 0;
+   uint32_t descriptor_count = binding->descriptorCount;
 
switch (binding->descriptorType) {
case VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC:
@@ -162,6 +163,11 @@ VkResult radv_CreateDescriptorSetLayout(
set_layout->binding[b].size = 16;
alignment = 16;
break;
+   case VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT:
+   alignment = 16;
+   set_layout->binding[b].size = descriptor_count;
+   descriptor_count = 1;
+   break;
default:
unreachable("unknown descriptor type\n");
break;
@@ -169,7 +175,7 @@ VkResult radv_CreateDescriptorSetLayout(
 
set_layout->size = align(set_layout->size, alignment);
set_layout->binding[b].type = binding->descriptorType;
-   set_layout->binding[b].array_size = binding->descriptorCount;
+   set_layout->binding[b].array_size = descriptor_count;
set_layout->binding[b].offset = set_layout->size;
set_layout->binding[b].buffer_offset = buffer_count;
set_layout->binding[b].dynamic_offset_offset = 
dynamic_offset_count;
@@ -203,9 +209,9 @@ VkResult radv_CreateDescriptorSetLayout(
samplers_offset += 4 * sizeof(uint32_t) * 
binding->descriptorCount;
}
 
-   set_layout->size += binding->descriptorCount * 
set_layout->binding[b].size;
-   buffer_count += binding->descriptorCount * binding_buffer_count;
-   dynamic_offset_count += binding->descriptorCount *
+   set_layout->size += descriptor_count * 
set_layout->binding[b].size;
+   buffer_count += descriptor_count * binding_buffer_count;
+   dynamic_offset_count += descriptor_count *
set_layout->binding[b].dynamic_offset_count;
set_layout->shader_stages |= binding->stageFlags;
}
@@ -260,6 +266,7 @@ void radv_GetDescriptorSetLayoutSupport(VkDevice device,
 
uint64_t descriptor_size = 0;
uint64_t descriptor_alignment = 1;
+   uint32_t descriptor_count = binding->descriptorCount;
switch (binding->descriptorType) {
case VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC:
case VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC:
@@ -278,7 +285,7 @@ void radv_GetDescriptorSetLayoutSupport(VkDevice device,
descriptor_alignment = 32;
break;
case VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER:
-   if 
(!has_equal_immutable_samplers(binding->pImmutableSamplers, 
binding->descriptorCount)) {
+   if 
(!has_equal_immutable_samplers(binding->pImmutableSamplers, descriptor_count)) {
descriptor_size = 64;
} else {
descriptor_size = 96;
@@ -286,11 +293,16 @@ void radv_GetDescriptorSetLayoutSupport(VkDevice device,
descriptor_alignment = 32;
break;
case VK_DESCRIPTOR_TYPE_SAMPLER:
-   if 
(!has_equal_immutable_samplers(binding->pImmutableSamplers, 
binding->descriptorCount)) {
+   if 
(!has_equal_immutable_samplers(binding->pImmutableSamplers, descriptor_count)) {
descriptor_size = 16;
descriptor_alignment = 16;
}
break;
+   case VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT:
+   descriptor_alignment = 16;
+   de

[Mesa-dev] [PATCH 1/2] amd/common: Rework buffer resource loading for uniform blocks.

[Bas Nieuwenhuizen]

Pointer to descriptor becomes hard if the set does not contain a
descriptor. Furthermore we have no extra channel to pass whether
the given pointer points to a descriptor or not.
---
 src/amd/common/ac_nir_to_llvm.c   | 98 +--
 src/amd/common/ac_shader_abi.h| 34 +++
 src/amd/vulkan/radv_nir_to_llvm.c | 31 ++
 src/gallium/drivers/radeonsi/si_shader.c  |  4 +-
 .../drivers/radeonsi/si_shader_tgsi_mem.c |  4 +-
 5 files changed, 97 insertions(+), 74 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index b01309cc2a9..ddb47d42687 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1363,15 +1363,46 @@ static LLVMValueRef build_tex_intrinsic(struct 
ac_nir_context *ctx,
return ac_build_image_opcode(&ctx->ac, args);
 }
 
-static LLVMValueRef visit_vulkan_resource_reindex(struct ac_nir_context *ctx,
-  nir_intrinsic_instr *instr)
+
+static bool is_vulkan_buffer(nir_ssa_def *value)
 {
-   LLVMValueRef ptr = get_src(ctx, instr->src[0]);
-   LLVMValueRef index = get_src(ctx, instr->src[1]);
+   if (value->parent_instr->type != nir_instr_type_intrinsic)
+   return false;
 
-   LLVMValueRef result = LLVMBuildGEP(ctx->ac.builder, ptr, &index, 1, "");
-   LLVMSetMetadata(result, ctx->ac.uniform_md_kind, ctx->ac.empty_md);
-   return result;
+   nir_intrinsic_instr *instr = (nir_intrinsic_instr*)value->parent_instr;
+   return instr->intrinsic == nir_intrinsic_vulkan_resource_index ||
+  instr->intrinsic == nir_intrinsic_vulkan_resource_reindex;
+}
+
+static void get_buffer_resource(struct ac_nir_context *ctx,
+   nir_src value,
+   int *set,
+   int *binding,
+   LLVMValueRef *index)
+{
+   if (is_vulkan_buffer(value.ssa)) {
+   LLVMValueRef idx = ctx->ac.i32_0;
+   for(;;) {
+   assert(value.ssa->parent_instr->type == 
nir_instr_type_intrinsic);
+
+   nir_intrinsic_instr *instr = 
(nir_intrinsic_instr*)value.ssa->parent_instr;
+
+   if (instr->intrinsic == 
nir_intrinsic_vulkan_resource_index) {
+   *set = nir_intrinsic_desc_set(instr);
+   *binding = nir_intrinsic_binding(instr);
+   *index = LLVMBuildAdd(ctx->ac.builder, idx, 
get_src(ctx, instr->src[0]), "");
+   break;
+   }
+
+   idx = LLVMBuildAdd(ctx->ac.builder, idx, get_src(ctx, 
instr->src[1]), "");
+   value = instr->src[0];
+   }
+   } else {
+   /* For GL we get a plain index. */
+   *set = 0;
+   *binding = 0;
+   *index = get_src(ctx, value);
+   }
 }
 
 static LLVMValueRef visit_load_push_constant(struct ac_nir_context *ctx,
@@ -1412,9 +1443,13 @@ static LLVMValueRef visit_load_push_constant(struct 
ac_nir_context *ctx,
 static LLVMValueRef visit_get_buffer_size(struct ac_nir_context *ctx,
   const nir_intrinsic_instr *instr)
 {
-   LLVMValueRef index = get_src(ctx, instr->src[0]);
+   LLVMValueRef rsrc_index, rsrc;
+   int set, binding;
+
+   get_buffer_resource(ctx, instr->src[0], &set, &binding, &rsrc_index);
+   rsrc = ctx->abi->load_ssbo(ctx->abi, set, binding, rsrc_index, false);
 
-   return get_buffer_size(ctx, ctx->abi->load_ssbo(ctx->abi, index, 
false), false);
+   return get_buffer_size(ctx, rsrc, false);
 }
 
 static uint32_t widen_mask(uint32_t mask, unsigned multiplier)
@@ -1457,8 +1492,12 @@ static void visit_store_ssbo(struct ac_nir_context *ctx,
int elem_size_bytes = ac_get_elem_bits(&ctx->ac, LLVMTypeOf(src_data)) 
/ 8;
unsigned writemask = nir_intrinsic_write_mask(instr);
 
-   LLVMValueRef rsrc = ctx->abi->load_ssbo(ctx->abi,
-   get_src(ctx, instr->src[1]), true);
+   LLVMValueRef rsrc_index, rsrc;
+   int set, binding;
+
+   get_buffer_resource(ctx, instr->src[1], &set, &binding, &rsrc_index);
+   rsrc = ctx->abi->load_ssbo(ctx->abi, set, binding, rsrc_index, true);
+
LLVMValueRef base_data = ac_to_float(&ctx->ac, src_data);
base_data = ac_trim_vector(&ctx->ac, base_data, instr->num_components);
LLVMValueRef base_offset = get_src(ctx, instr->src[2]);
@@ -1555,14 +1594,16 @@ static LLVMValueRef visit_atomic_ssbo(struct 
ac_nir_context *ctx,
const char *name;
LLVMValueRef params[6];
int arg_count = 0;
+   LLVMValueRef rsrc_index;
+   int set, binding;
+
+   get_buffer_resource(ctx, instr->src[0], &set, &binding, &rsrc_index);
 
if (instr->in

Re: [Mesa-dev] Lets talk about autotools

[Adam Jackson]

On Tue, 2018-09-18 at 13:50 -0700, Dylan Baker wrote:

> > 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). 
> 
> This is impossible by design. Meson is very specific that its internal 
> directory
> layout is an implementation detail. On top of that, there are two different
> backends, a VS and ninja backend, which have slightly different layouts.

I'm not entirely sure that's true? mesa/build-lib/meson.build could
have all the final link targets, and their results would show up in
mesa/${builddir}/build-lib. It'd mean mirroring all the "do I build
this target or not" logic in that meson.build, and you'd descend into
that directory last from the top-level mesa/meson.build, but...

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: fix descriptor pool allocation size

[Bas Nieuwenhuizen]

+Dylan as 18.1 Release Manager

Hi Dylan,

Please be advised that the above patch has been reverted on master in
95bb7d82ca8abf514af2575e3b9f4babfbb034c4 and should not be included in
the 18.1.9 release.

Thanks,
Bas


On Tue, Sep 18, 2018 at 8:19 PM Samuel Pitoiset
 wrote:
>
>
>
> On 9/18/18 8:07 PM, Juan A. Suarez Romero wrote:
> > On Tue, 2018-09-18 at 17:20 +0200, Gustaw Smolarczyk wrote:
> >> pt., 14 wrz 2018 o 15:00 Bas Nieuwenhuizen  
> >> napisał(a):
> >>>
> >>> Reviewed-by: Bas Nieuwenhuizen 
> >>> On Fri, Sep 14, 2018 at 2:55 PM Samuel Pitoiset
> >>>  wrote:
> 
>  The size has to be multiplied by the number of sets.
> 
>  This gets rid of the OUT_OF_POOL_KHR error and fixes
>  the Tangrams demo.
> 
>  CC: 18.1 18.2 
>  Signed-off-by: Samuel Pitoiset 
>  ---
>    src/amd/vulkan/radv_descriptor_set.c | 3 ++-
>    1 file changed, 2 insertions(+), 1 deletion(-)
> 
>  diff --git a/src/amd/vulkan/radv_descriptor_set.c 
>  b/src/amd/vulkan/radv_descriptor_set.c
>  index c4341f6ac5..49d0811bb0 100644
>  --- a/src/amd/vulkan/radv_descriptor_set.c
>  +++ b/src/amd/vulkan/radv_descriptor_set.c
>  @@ -569,9 +569,10 @@ VkResult radv_CreateDescriptorPool(
>   }
> 
>   if (!(pCreateInfo->flags & 
>  VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT)) {
>  -   uint64_t host_size = pCreateInfo->maxSets * 
>  sizeof(struct radv_descriptor_set);
>  +   uint64_t host_size = sizeof(struct radv_descriptor_set);
>   host_size += sizeof(struct radeon_winsys_bo*) * 
>  bo_count;
>   host_size += sizeof(struct radv_descriptor_range) * 
>  range_count;
>  +   host_size *= pCreateInfo->maxSets;
>   size += host_size;
>   } else {
>   size += sizeof(struct radv_descriptor_pool_entry) * 
>  pCreateInfo->maxSets;
>  --
>  2.19.0
> 
>  ___
>  mesa-dev mailing list
>  mesa-dev@lists.freedesktop.org
>  https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >>>
> >>> ___
> >>> mesa-dev mailing list
> >>> mesa-dev@lists.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >>
> >> I don't think this change is correct.
> >>
> >
> > This patch was included for the next 18.2.1 release.
> >
> > I understand this must be removed from the queue before the release, right? 
> > Or
> > is there another  patch to apply over or replace this?
>
> You can remove it from the queue and I will revert it on master.
> Thanks.
>
> >
> >
> >
> >   J.A.
> >
> >>  From the vkAllocateDescriptorSets documentation [1]:
> >>
> >>
> >> If a call to vkAllocateDescriptorSets would cause the total number of
> >> descriptor sets allocated from the pool to exceed the value of
> >> VkDescriptorPoolCreateInfo::maxSets used to create
> >> pAllocateInfo→descriptorPool, then the allocation may fail due to lack
> >> of space in the descriptor pool. Similarly, the allocation may fail
> >> due to lack of space if the call to vkAllocateDescriptorSets would
> >> cause the number of any given descriptor type to exceed the sum of all
> >> the descriptorCount members of each element of
> >> VkDescriptorPoolCreateInfo::pPoolSizes with a member equal to that
> >> type.
> >>
> >>
> >> What it implies (I think), is that VkDescriptorPoolCreateInfo::maxSets
> >> and descriptorCount of each VkDescriptorPoolCreateInfo::pPoolSizes are
> >> treated separately. I don't think you should multiply one by another.
> >> Each pool should be able to allocate at least maxSets sets and
> >> descriptorCount descriptors.
> >>
> >> Please, correct me if I'm wrong.
> >>
> >> Regards,
> >>
> >> Gustaw Smolarczyk
> >>
> >> [1] 
> >> https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkAllocateDescriptorSets.html
> >> ___
> >> mesa-stable mailing list
> >> mesa-sta...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Dylan Baker]

Quoting Gert Wollny (2018-09-18 12:16:01)
> Am Montag, den 17.09.2018, 17:07 -0400 schrieb Marek Ol\u0161á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.

ninja installs are very fast and cheap, unlike autotools. Most of us using meson
already just do `meson builddir --prefix=$PWD/builddir; ninja -C builddir
install`, then you can point LD_LIBRARY_PATH and LIBGL_DRIVERS_DIR at
$PWD/builddir/lib and $PWD/builddir/lib/dri.

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

This is impossible by design. Meson is very specific that its internal directory
layout is an implementation detail. On top of that, there are two different
backends, a VS and ninja backend, which have slightly different layouts.

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 Kai Wasserbäch (2018-09-18 11:14:19)
> Dylan Baker wrote on 9/18/18 6:40 PM:
> > Quoting Kai Wasserbäch (2018-09-18 08:56:30)
> >> Dylan Baker wrote on 9/18/18 5:35 PM:
> >>> [...]
> >>>
> >>> This is something we've discussed upstream several times. I will freely 
> >>> admit
> >>> that llvm-config is a huge pain in the ass to deal with for a ton of 
> >>> reasons,
> >>> and since we don't use it at Intel
> >>
> >> Since there's now an „APU“ from Intel with an AMD GPU, I guess that is no 
> >> longer
> >> the case?
> > 
> > Our relationship with the KBL-G is complicated :)
> 
> Well, there's also SWR from Intel, which also relies on LLVM...
> 
> >>> it hasn't been on the top of my list of
> >>> things to do, and also because the solution upstream wants is very 
> >>> non-trival to
> >>> implement. This has come up already and I am working on it right now.
> >>
> >> If upstream support is unreasonable, I'd like to see a similar solution to
> >> LLVM_CONFIG as it's in autotools today. It must be possible to 
> >> mangle/override
> >> the meson variables right? (This might be totally ignorant, because I was 
> >> able
> >> to avoid Meson so far and all other build systems I've worked with, have 
> >> one or
> >> more options to set variables. Either by having an option in the build 
> >> files or
> >> by passing some option into the configure step.)
> > 
> > It really isn't, the only way we could really override this today is to 
> > allow
> > you to pass a version requirement. One of the guiding ideas of meson is that
> > complicated logic like "how the hell do you make a tool as
> > broken-by-design-and-implementation as llvm-config work" should be part of 
> > meson
> > itself and not in the local build-system. The downside of that is that 
> > upstream
> > really wants you to think about how you handle things like overriding a 
> > specific
> > binary like llvm-config because it has to live with that decision for a long
> > time.
> 
> I'm for the hiding, but why not do it in an easy to change way like the
> "Find${FOO}.cmake" scripts? As long as you get certain variables populated
> downstream is happy and an occasional change can be managed, if it should 
> become
> necessary. Having everything "in the core" sounds rather inflexible to me. Or
> I'm misunderstanding you. Anyway, this isn't really the topic here.
>
> >>> The other option you have it to set the $PATH variable, as long as the
> >>> llvm-config you want returns the highest version things will work as you 
> >>> expect.
> >>
> >> This might do as a workaround, though I'm not too keen on extending $PATH. 
> >> But
> >> as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain 
> >> that
> >> versions binaries, putting it first into the path could work.
> > 
> > meson will cache the llvm-config values, so you should be able to just do
> > something like:
> > 
> > PATH=/path/to/my/llvm meson build-with-my-llvm
> 
> Ok. Where's the cache? In the build directory or is this something, that's 
> kept
> globally and needs potential clearing? A quick search for this feature yielded
> . That makes it sound 
> like
> it is global, which I would almost consider broken design. Or is it local but
> kept between multiple invocations of meson? That also sounds like a recipe for
> disaster, though it would be easier to deal with: just nuke the build 
> directory.

It's per build directory, and is kept on subsequent rebuilds. The idea is that
if you need to reconfigure a build (say meson.build changes) when you do a `git
pull` that pkg-config, llvm-config, and fiends don't get reinvoked, it makes the
rebuild faster. I don't think there is a cache-invalidation method, though that
would be a nice feature to have.

Dylan


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

[Mesa-dev] [PATCH 2/6] radeonsi:optimizing SET_CONTEXT_REG for shaders GS

[Sonny Jiang]

Signed-off-by: Sonny Jiang 
---
 src/gallium/drivers/radeonsi/si_gfx_cs.c  |  15 ++-
 src/gallium/drivers/radeonsi/si_state.h   |  19 ++-
 .../drivers/radeonsi/si_state_shaders.c   | 112 --
 3 files changed, 109 insertions(+), 37 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_gfx_cs.c 
b/src/gallium/drivers/radeonsi/si_gfx_cs.c
index 99376c4847..39a97bf3da 100644
--- a/src/gallium/drivers/radeonsi/si_gfx_cs.c
+++ b/src/gallium/drivers/radeonsi/si_gfx_cs.c
@@ -352,9 +352,22 @@ void si_begin_new_gfx_cs(struct si_context *ctx)
ctx->tracked_regs.reg_value[SI_TRACKED_PA_CL_GB_HORZ_DISC_ADJ]  
= 0x3f80;
ctx->tracked_regs.reg_value[SI_TRACKED_PA_SC_CLIPRECT_RULE] 
= 0x;
ctx->tracked_regs.reg_value[SI_TRACKED_VGT_ESGS_RING_ITEMSIZE]  
= 0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GSVS_RING_OFFSET_1]  
= 0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GSVS_RING_OFFSET_2]  
= 0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GSVS_RING_OFFSET_3]  
= 0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GS_OUT_PRIM_TYPE]
= 0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GSVS_RING_ITEMSIZE]  
= 0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GS_MAX_VERT_OUT]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GS_VERT_ITEMSIZE]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GS_VERT_ITEMSIZE_1]  
= 0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GS_VERT_ITEMSIZE_2]  
= 0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GS_VERT_ITEMSIZE_3]  
= 0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GS_INSTANCE_CNT]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GS_ONCHIP_CNTL]  = 
0x;
+   
ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GS_MAX_PRIMS_PER_SUBGROUP]  = 
0x;
 
/* Set all saved registers state to saved. */
-   ctx->tracked_regs.reg_saved = 0x;
+   ctx->tracked_regs.reg_saved = 0x;
} else {
/* Set all saved registers state to unknown. */
ctx->tracked_regs.reg_saved = 0;
diff --git a/src/gallium/drivers/radeonsi/si_state.h 
b/src/gallium/drivers/radeonsi/si_state.h
index 7fb09ca953..9efb4be5a5 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -279,11 +279,28 @@ enum si_tracked_reg {
 
SI_TRACKED_VGT_ESGS_RING_ITEMSIZE,
 
+   SI_TRACKED_VGT_GSVS_RING_OFFSET_1, /* 4 consecutive registers */
+   SI_TRACKED_VGT_GSVS_RING_OFFSET_2,
+   SI_TRACKED_VGT_GSVS_RING_OFFSET_3,
+   SI_TRACKED_VGT_GS_OUT_PRIM_TYPE,
+
+   SI_TRACKED_VGT_GSVS_RING_ITEMSIZE,
+   SI_TRACKED_VGT_GS_MAX_VERT_OUT,
+
+   SI_TRACKED_VGT_GS_VERT_ITEMSIZE, /* 4 consecutive registers */
+   SI_TRACKED_VGT_GS_VERT_ITEMSIZE_1,
+   SI_TRACKED_VGT_GS_VERT_ITEMSIZE_2,
+   SI_TRACKED_VGT_GS_VERT_ITEMSIZE_3,
+
+   SI_TRACKED_VGT_GS_INSTANCE_CNT,
+   SI_TRACKED_VGT_GS_ONCHIP_CNTL,
+   SI_TRACKED_VGT_GS_MAX_PRIMS_PER_SUBGROUP,
+
SI_NUM_TRACKED_REGS,
 };
 
 struct si_tracked_regs {
-   uint32_treg_saved;
+   uint64_treg_saved;
uint32_treg_value[SI_NUM_TRACKED_REGS];
uint32_tspi_ps_input_cntl[32];
 };
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 0716021d85..87b58cd6e5 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -747,48 +747,99 @@ static void gfx9_get_gs_info(struct si_shader_selector 
*es,
assert(out->max_prims_per_subgroup <= max_out_prims);
 }
 
-static void si_shader_gs(struct si_screen *sscreen, struct si_shader *shader)
+static void si_emit_shader_gs(struct si_context *sctx)
 {
+   struct si_shader *shader = sctx->queued.named.gs->shader;
+   if (!shader)
+   return;
+
struct si_shader_selector *sel = shader->selector;
const ubyte *num_components = sel->info.num_stream_output_components;
unsigned gs_num_invocations = sel->gs_num_invocations;
-   struct si_pm4_state *pm4;
uint64_t va;
unsigned max_stream = sel->max_gs_stream;
-   unsigned offset;
+   unsigned offset_1, offset_2, offset_3, vgt_gsvs_ring_itemsize;
 
-   pm4 = si_get_shader_pm4_state(shader);
-   if (!pm4)
-   return;
-
-   offset = num_components[0] * sel->gs_max_out_vertices;
-   si_pm4_set_reg(pm4, R_028A60_VGT_GSVS_RING_OFFSET_1, offset);
+   offset_3 = offset_2 = offset_1 = num_components[0] * 
sel->gs_max_out_vertices;
if (max_stream

[Mesa-dev] [PATCH 5/6] radeonsi:optimizing SET_CONTEXT_REG for shaders Tessellation

[Sonny Jiang]

Signed-off-by: Sonny Jiang 
---
 src/gallium/drivers/radeonsi/si_gfx_cs.c  |  1 +
 src/gallium/drivers/radeonsi/si_state.h   |  1 +
 .../drivers/radeonsi/si_state_shaders.c   | 51 ++-
 3 files changed, 29 insertions(+), 24 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_gfx_cs.c 
b/src/gallium/drivers/radeonsi/si_gfx_cs.c
index 8c1bee8ed6..7cf1f6f4b7 100644
--- a/src/gallium/drivers/radeonsi/si_gfx_cs.c
+++ b/src/gallium/drivers/radeonsi/si_gfx_cs.c
@@ -378,6 +378,7 @@ void si_begin_new_gfx_cs(struct si_context *ctx)
ctx->tracked_regs.reg_value[SI_TRACKED_SPI_SHADER_Z_FORMAT]  = 
0x;
ctx->tracked_regs.reg_value[SI_TRACKED_SPI_SHADER_COL_FORMAT]  
= 0x;
ctx->tracked_regs.reg_value[SI_TRACKED_CB_SHADER_MASK]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_TF_PARAM]  = 
0x;
 
/* Set all saved registers state to saved. */
ctx->tracked_regs.reg_saved = 0x;
diff --git a/src/gallium/drivers/radeonsi/si_state.h 
b/src/gallium/drivers/radeonsi/si_state.h
index 878b67f0ed..54b03e0992 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -312,6 +312,7 @@ enum si_tracked_reg {
SI_TRACKED_SPI_SHADER_COL_FORMAT,
 
SI_TRACKED_CB_SHADER_MASK,
+   SI_TRACKED_VGT_TF_PARAM,
 
SI_NUM_TRACKED_REGS,
 };
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index e5732f7920..a8d2769475 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -336,9 +336,8 @@ void si_destroy_shader_cache(struct si_screen *sscreen)
 
 /* SHADER STATES */
 
-static void si_set_tesseval_regs(struct si_screen *sscreen,
-struct si_shader_selector *tes,
-struct si_pm4_state *pm4)
+static void si_set_tesseval_regs(struct si_context *sctx,
+struct si_shader_selector *tes)
 {
struct tgsi_shader_info *info = &tes->info;
unsigned tes_prim_mode = info->properties[TGSI_PROPERTY_TES_PRIM_MODE];
@@ -387,20 +386,21 @@ static void si_set_tesseval_regs(struct si_screen 
*sscreen,
else
topology = V_028B6C_OUTPUT_TRIANGLE_CW;
 
-   if (sscreen->has_distributed_tess) {
-   if (sscreen->info.family == CHIP_FIJI ||
-   sscreen->info.family >= CHIP_POLARIS10)
+   if (sctx->screen->has_distributed_tess) {
+   if (sctx->family == CHIP_FIJI ||
+   sctx->family >= CHIP_POLARIS10)
distribution_mode = 
V_028B6C_DISTRIBUTION_MODE_TRAPEZOIDS;
else
distribution_mode = V_028B6C_DISTRIBUTION_MODE_DONUTS;
} else
distribution_mode = V_028B6C_DISTRIBUTION_MODE_NO_DIST;
 
-   si_pm4_set_reg(pm4, R_028B6C_VGT_TF_PARAM,
-  S_028B6C_TYPE(type) |
-  S_028B6C_PARTITIONING(partitioning) |
-  S_028B6C_TOPOLOGY(topology) |
-  S_028B6C_DISTRIBUTION_MODE(distribution_mode));
+   radeon_opt_set_context_reg(sctx, R_028B6C_VGT_TF_PARAM,
+   SI_TRACKED_VGT_TF_PARAM,
+   S_028B6C_TYPE(type) |
+   S_028B6C_PARTITIONING(partitioning) |
+   S_028B6C_TOPOLOGY(topology) |
+   S_028B6C_DISTRIBUTION_MODE(distribution_mode));
 }
 
 /* Polaris needs different VTX_REUSE_DEPTH settings depending on
@@ -562,10 +562,16 @@ static void si_emit_shader_es(struct si_context *sctx)
 {
struct si_shader *shader = sctx->queued.named.es->shader;
 
-   if (shader)
-   radeon_opt_set_context_reg(sctx, 
R_028AAC_VGT_ESGS_RING_ITEMSIZE,
-  SI_TRACKED_VGT_ESGS_RING_ITEMSIZE,
-  shader->selector->esgs_itemsize / 4);
+   if (!shader)
+   return;
+
+   radeon_opt_set_context_reg(sctx, R_028AAC_VGT_ESGS_RING_ITEMSIZE,
+  SI_TRACKED_VGT_ESGS_RING_ITEMSIZE,
+  shader->selector->esgs_itemsize / 4);
+
+   if (shader->selector->type == PIPE_SHADER_TESS_EVAL)
+   si_set_tesseval_regs(sctx, shader->selector);
+
 }
 
 static void si_shader_es(struct si_screen *sscreen, struct si_shader *shader)
@@ -611,9 +617,6 @@ static void si_shader_es(struct si_screen *sscreen, struct 
si_shader *shader)
   S_00B32C_OC_LDS_EN(oc_lds_en) |
   
S_00B32C_SCRATCH_EN(shader->config.scratch_bytes_per_wave > 0));
 
-   if (shader->selector->type == PIPE_SHADER_TESS_EVAL)
-   si_set_tesseval_regs(sscreen, shader->selector, pm4);
-
polaris_set_vgt_vertex_re

[Mesa-dev] [PATCH 6/6] radeonsi:optimizing SET_CONTEXT_REG for shaders vgt_vertex_reuse

[Sonny Jiang]

Signed-off-by: Sonny Jiang 
---
 src/gallium/drivers/radeonsi/si_gfx_cs.c  |  1 +
 src/gallium/drivers/radeonsi/si_state.h   |  1 +
 .../drivers/radeonsi/si_state_shaders.c   | 25 +--
 3 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_gfx_cs.c 
b/src/gallium/drivers/radeonsi/si_gfx_cs.c
index 7cf1f6f4b7..77b7bf8f76 100644
--- a/src/gallium/drivers/radeonsi/si_gfx_cs.c
+++ b/src/gallium/drivers/radeonsi/si_gfx_cs.c
@@ -379,6 +379,7 @@ void si_begin_new_gfx_cs(struct si_context *ctx)
ctx->tracked_regs.reg_value[SI_TRACKED_SPI_SHADER_COL_FORMAT]  
= 0x;
ctx->tracked_regs.reg_value[SI_TRACKED_CB_SHADER_MASK]  = 
0x;
ctx->tracked_regs.reg_value[SI_TRACKED_VGT_TF_PARAM]  = 
0x;
+   
ctx->tracked_regs.reg_value[SI_TRACKED_VGT_VERTEX_REUSE_BLOCK_CNTL]  = 
0x001e; /* From VI */
 
/* Set all saved registers state to saved. */
ctx->tracked_regs.reg_saved = 0x;
diff --git a/src/gallium/drivers/radeonsi/si_state.h 
b/src/gallium/drivers/radeonsi/si_state.h
index 54b03e0992..fffc63680d 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -313,6 +313,7 @@ enum si_tracked_reg {
 
SI_TRACKED_CB_SHADER_MASK,
SI_TRACKED_VGT_TF_PARAM,
+   SI_TRACKED_VGT_VERTEX_REUSE_BLOCK_CNTL,
 
SI_NUM_TRACKED_REGS,
 };
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index a8d2769475..21564ff186 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -417,14 +417,13 @@ static void si_set_tesseval_regs(struct si_context *sctx,
  *
  * If "shader" is NULL, it's assumed it's not LS or GS copy shader.
  */
-static void polaris_set_vgt_vertex_reuse(struct si_screen *sscreen,
+static void polaris_set_vgt_vertex_reuse(struct si_context *sctx,
 struct si_shader_selector *sel,
-struct si_shader *shader,
-struct si_pm4_state *pm4)
+struct si_shader *shader)
 {
unsigned type = sel->type;
 
-   if (sscreen->info.family < CHIP_POLARIS10)
+   if (sctx->family < CHIP_POLARIS10)
return;
 
/* VS as VS, or VS as ES: */
@@ -440,8 +439,10 @@ static void polaris_set_vgt_vertex_reuse(struct si_screen 
*sscreen,
PIPE_TESS_SPACING_FRACTIONAL_ODD)
vtx_reuse_depth = 14;
 
-   si_pm4_set_reg(pm4, R_028C58_VGT_VERTEX_REUSE_BLOCK_CNTL,
-  vtx_reuse_depth);
+   radeon_opt_set_context_reg(sctx,
+   R_028C58_VGT_VERTEX_REUSE_BLOCK_CNTL,
+   SI_TRACKED_VGT_VERTEX_REUSE_BLOCK_CNTL,
+   vtx_reuse_depth);
}
 }
 
@@ -572,6 +573,7 @@ static void si_emit_shader_es(struct si_context *sctx)
if (shader->selector->type == PIPE_SHADER_TESS_EVAL)
si_set_tesseval_regs(sctx, shader->selector);
 
+   polaris_set_vgt_vertex_reuse(sctx, shader->selector, shader);
 }
 
 static void si_shader_es(struct si_screen *sscreen, struct si_shader *shader)
@@ -616,8 +618,6 @@ static void si_shader_es(struct si_screen *sscreen, struct 
si_shader *shader)
   S_00B32C_USER_SGPR(num_user_sgprs) |
   S_00B32C_OC_LDS_EN(oc_lds_en) |
   
S_00B32C_SCRATCH_EN(shader->config.scratch_bytes_per_wave > 0));
-
-   polaris_set_vgt_vertex_reuse(sscreen, shader->selector, shader, pm4);
 }
 
 static unsigned si_conv_prim_to_gs_out(unsigned mode)
@@ -832,6 +832,8 @@ static void si_emit_shader_gs(struct si_context *sctx)
 
if (shader->key.part.gs.es->type == PIPE_SHADER_TESS_EVAL)
si_set_tesseval_regs(sctx, shader->key.part.gs.es);
+
+   polaris_set_vgt_vertex_reuse(sctx, shader->key.part.gs.es, 
NULL);
}
 }
 
@@ -899,9 +901,6 @@ static void si_shader_gs(struct si_screen *sscreen, struct 
si_shader *shader)
   S_00B22C_OC_LDS_EN(es_type == 
PIPE_SHADER_TESS_EVAL) |
   S_00B22C_LDS_SIZE(gs_info.lds_size) |
   
S_00B22C_SCRATCH_EN(shader->config.scratch_bytes_per_wave > 0));
-
-   polaris_set_vgt_vertex_reuse(sscreen, shader->key.part.gs.es,
-NULL, pm4);
} else {
si_pm4_set_reg(pm4, R_00B220_SPI_SHADER_PGM_LO_GS, va >> 8);
si_pm4_set_reg(pm4, R_00B224_SPI_SHADER_PGM_HI_GS, 
S_00B224_MEM_BASE(va >> 40));
@@ -1004,6 +1003,8 @@ static void si_emit_shader_vs(struct si_context *sctx)
 
if (shader->selector->

[Mesa-dev] [PATCH 3/6] radeonsi:optimizing SET_CONTEXT_REG for shaders VS

[Sonny Jiang]

Signed-off-by: Sonny Jiang 
---
 src/gallium/drivers/radeonsi/si_gfx_cs.c  |   6 +
 src/gallium/drivers/radeonsi/si_state.h   |   6 +
 .../drivers/radeonsi/si_state_shaders.c   | 133 +++---
 3 files changed, 93 insertions(+), 52 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_gfx_cs.c 
b/src/gallium/drivers/radeonsi/si_gfx_cs.c
index 39a97bf3da..2e10d766a6 100644
--- a/src/gallium/drivers/radeonsi/si_gfx_cs.c
+++ b/src/gallium/drivers/radeonsi/si_gfx_cs.c
@@ -365,6 +365,12 @@ void si_begin_new_gfx_cs(struct si_context *ctx)
ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GS_INSTANCE_CNT]  = 
0x;
ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GS_ONCHIP_CNTL]  = 
0x;

ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GS_MAX_PRIMS_PER_SUBGROUP]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_GS_MODE]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_PRIMITIVEID_EN]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_REUSE_OFF]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_SPI_VS_OUT_CONFIG]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_SPI_SHADER_POS_FORMAT]  
= 0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_PA_CL_VTE_CNTL]  = 
0x;
 
/* Set all saved registers state to saved. */
ctx->tracked_regs.reg_saved = 0x;
diff --git a/src/gallium/drivers/radeonsi/si_state.h 
b/src/gallium/drivers/radeonsi/si_state.h
index 9efb4be5a5..bf1ae9f18f 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -295,6 +295,12 @@ enum si_tracked_reg {
SI_TRACKED_VGT_GS_INSTANCE_CNT,
SI_TRACKED_VGT_GS_ONCHIP_CNTL,
SI_TRACKED_VGT_GS_MAX_PRIMS_PER_SUBGROUP,
+   SI_TRACKED_VGT_GS_MODE,
+   SI_TRACKED_VGT_PRIMITIVEID_EN,
+   SI_TRACKED_VGT_REUSE_OFF,
+   SI_TRACKED_SPI_VS_OUT_CONFIG,
+   SI_TRACKED_SPI_SHADER_POS_FORMAT,
+   SI_TRACKED_PA_CL_VTE_CNTL,
 
SI_NUM_TRACKED_REGS,
 };
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 87b58cd6e5..332fdae3b3 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -914,29 +914,23 @@ static void si_shader_gs(struct si_screen *sscreen, 
struct si_shader *shader)
}
 }
 
-/**
- * Compute the state for \p shader, which will run as a vertex shader on the
- * hardware.
- *
- * If \p gs is non-NULL, it points to the geometry shader for which this shader
- * is the copy shader.
- */
-static void si_shader_vs(struct si_screen *sscreen, struct si_shader *shader,
- struct si_shader_selector *gs)
+static void si_emit_shader_vs(struct si_context *sctx)
 {
+   struct si_shader *shader = sctx->queued.named.vs->shader;
+   if (!shader)
+   return;
+
+   struct si_shader_selector *gs;
const struct tgsi_shader_info *info = &shader->selector->info;
-   struct si_pm4_state *pm4;
-   unsigned num_user_sgprs;
-   unsigned nparams, vgpr_comp_cnt;
-   uint64_t va;
-   unsigned oc_lds_en;
+   unsigned nparams;
unsigned window_space =
   info->properties[TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION];
bool enable_prim_id = shader->key.mono.u.vs_export_prim_id || 
info->uses_primid;
 
-   pm4 = si_get_shader_pm4_state(shader);
-   if (!pm4)
-   return;
+   if (shader->is_gs_copy_shader)
+   gs = shader->selector;
+   else
+   gs = NULL;
 
/* We always write VGT_GS_MODE in the VS state, because every switch
 * between different shader pipelines involving a different GS or no
@@ -952,21 +946,82 @@ static void si_shader_vs(struct si_screen *sscreen, 
struct si_shader *shader,
if (enable_prim_id)
mode = V_028A40_GS_SCENARIO_A;
 
-   si_pm4_set_reg(pm4, R_028A40_VGT_GS_MODE, S_028A40_MODE(mode));
-   si_pm4_set_reg(pm4, R_028A84_VGT_PRIMITIVEID_EN, 
enable_prim_id);
+   radeon_opt_set_context_reg(sctx, R_028A40_VGT_GS_MODE,
+  SI_TRACKED_VGT_GS_MODE,
+  S_028A40_MODE(mode));
+   radeon_opt_set_context_reg(sctx, R_028A84_VGT_PRIMITIVEID_EN,
+  SI_TRACKED_VGT_PRIMITIVEID_EN,
+  enable_prim_id);
} else {
-   si_pm4_set_reg(pm4, R_028A40_VGT_GS_MODE,
-  ac_vgt_gs_mode(gs->gs_max_out_vertices,
- sscreen->info.chip_class));
-   si_pm4_set_reg(pm4, R_028A84_VGT_PRIMITIVEID_EN, 0);
+   radeon_opt_set_con

[Mesa-dev] [PATCH 4/6] radeonsi:optimizing SET_CONTEXT_REG for shaders PS

[Sonny Jiang]

Signed-off-by: Sonny Jiang 
---
 src/gallium/drivers/radeonsi/si_gfx_cs.c  |   7 +
 src/gallium/drivers/radeonsi/si_state.h   |  11 ++
 .../drivers/radeonsi/si_state_shaders.c   | 144 ++
 3 files changed, 98 insertions(+), 64 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_gfx_cs.c 
b/src/gallium/drivers/radeonsi/si_gfx_cs.c
index 2e10d766a6..8c1bee8ed6 100644
--- a/src/gallium/drivers/radeonsi/si_gfx_cs.c
+++ b/src/gallium/drivers/radeonsi/si_gfx_cs.c
@@ -371,6 +371,13 @@ void si_begin_new_gfx_cs(struct si_context *ctx)
ctx->tracked_regs.reg_value[SI_TRACKED_SPI_VS_OUT_CONFIG]  = 
0x;
ctx->tracked_regs.reg_value[SI_TRACKED_SPI_SHADER_POS_FORMAT]  
= 0x;
ctx->tracked_regs.reg_value[SI_TRACKED_PA_CL_VTE_CNTL]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_SPI_PS_INPUT_ENA]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_SPI_PS_INPUT_ADDR]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_SPI_BARYC_CNTL]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_SPI_PS_IN_CONTROL]  = 
0x0002;
+   ctx->tracked_regs.reg_value[SI_TRACKED_SPI_SHADER_Z_FORMAT]  = 
0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_SPI_SHADER_COL_FORMAT]  
= 0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_CB_SHADER_MASK]  = 
0x;
 
/* Set all saved registers state to saved. */
ctx->tracked_regs.reg_saved = 0x;
diff --git a/src/gallium/drivers/radeonsi/si_state.h 
b/src/gallium/drivers/radeonsi/si_state.h
index bf1ae9f18f..878b67f0ed 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -302,6 +302,17 @@ enum si_tracked_reg {
SI_TRACKED_SPI_SHADER_POS_FORMAT,
SI_TRACKED_PA_CL_VTE_CNTL,
 
+   SI_TRACKED_SPI_PS_INPUT_ENA, /* 2 consecutive registers */
+   SI_TRACKED_SPI_PS_INPUT_ADDR,
+
+   SI_TRACKED_SPI_BARYC_CNTL,
+   SI_TRACKED_SPI_PS_IN_CONTROL,
+
+   SI_TRACKED_SPI_SHADER_Z_FORMAT, /* 2 consecutive registers */
+   SI_TRACKED_SPI_SHADER_COL_FORMAT,
+
+   SI_TRACKED_CB_SHADER_MASK,
+
SI_NUM_TRACKED_REGS,
 };
 
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 332fdae3b3..e5732f7920 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1100,12 +1100,88 @@ static unsigned si_get_spi_shader_col_format(struct 
si_shader *shader)
return value;
 }
 
-static void si_shader_ps(struct si_shader *shader)
+static void si_emit_shader_ps(struct si_context *sctx)
 {
+   struct si_shader *shader = sctx->queued.named.ps->shader;
+   if (!shader)
+   return;
+
struct tgsi_shader_info *info = &shader->selector->info;
-   struct si_pm4_state *pm4;
-   unsigned spi_ps_in_control, spi_shader_col_format, cb_shader_mask;
unsigned spi_baryc_cntl = S_0286E0_FRONT_FACE_ALL_BITS(1);
+   unsigned spi_ps_in_control, spi_shader_col_format, cb_shader_mask;
+
+   /* R_0286CC_SPI_PS_INPUT_ENA, R_0286D0_SPI_PS_INPUT_ADDR*/
+   radeon_opt_set_context_reg2(sctx, R_0286CC_SPI_PS_INPUT_ENA,
+   SI_TRACKED_SPI_PS_INPUT_ENA,
+   shader->config.spi_ps_input_ena,
+   shader->config.spi_ps_input_addr);
+
+   /* SPI_BARYC_CNTL.POS_FLOAT_LOCATION
+* Possible vaules:
+* 0 -> Position = pixel center
+* 1 -> Position = pixel centroid
+* 2 -> Position = at sample position
+*
+* From GLSL 4.5 specification, section 7.1:
+*   "The variable gl_FragCoord is available as an input variable from
+*within fragment shaders and it holds the window relative 
coordinates
+*(x, y, z, 1/w) values for the fragment. If multi-sampling, this
+*value can be for any location within the pixel, or one of the
+*fragment samples. The use of centroid does not further restrict
+*this value to be inside the current primitive."
+*
+* Meaning that centroid has no effect and we can return anything within
+* the pixel. Thus, return the value at sample position, because that's
+* the most accurate one shaders can get.
+*/
+   spi_baryc_cntl |= S_0286E0_POS_FLOAT_LOCATION(2);
+
+   if (info->properties[TGSI_PROPERTY_FS_COORD_PIXEL_CENTER] ==
+   TGSI_FS_COORD_PIXEL_CENTER_INTEGER)
+   spi_baryc_cntl |= S_0286E0_POS_FLOAT_ULC(1);
+
+   /* Set interpolation controls. */
+   spi_ps_in_control = S_0286D8_NUM_INTERP(si_get_ps_num_interp(shader));
+
+   radeon_opt_set_context_reg(sctx, R_0286E0_SPI_BARYC_CNTL,
+  SI_TR

[Mesa-dev] [PATCH 1/6] radeonsi: optimizing SET_CONTEXT_REG for shaders ES

[Sonny Jiang]

Signed-off-by: Sonny Jiang 
---
 src/gallium/drivers/radeonsi/si_gfx_cs.c  |  1 +
 src/gallium/drivers/radeonsi/si_pm4.c |  3 +++
 src/gallium/drivers/radeonsi/si_pm4.h | 11 ++
 src/gallium/drivers/radeonsi/si_state.h   |  9 ++--
 .../drivers/radeonsi/si_state_shaders.c   | 21 ---
 5 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_gfx_cs.c 
b/src/gallium/drivers/radeonsi/si_gfx_cs.c
index 38b85ce624..99376c4847 100644
--- a/src/gallium/drivers/radeonsi/si_gfx_cs.c
+++ b/src/gallium/drivers/radeonsi/si_gfx_cs.c
@@ -351,6 +351,7 @@ void si_begin_new_gfx_cs(struct si_context *ctx)
ctx->tracked_regs.reg_value[SI_TRACKED_PA_CL_GB_HORZ_CLIP_ADJ]  
= 0x3f80;
ctx->tracked_regs.reg_value[SI_TRACKED_PA_CL_GB_HORZ_DISC_ADJ]  
= 0x3f80;
ctx->tracked_regs.reg_value[SI_TRACKED_PA_SC_CLIPRECT_RULE] 
= 0x;
+   ctx->tracked_regs.reg_value[SI_TRACKED_VGT_ESGS_RING_ITEMSIZE]  
= 0x;
 
/* Set all saved registers state to saved. */
ctx->tracked_regs.reg_saved = 0x;
diff --git a/src/gallium/drivers/radeonsi/si_pm4.c 
b/src/gallium/drivers/radeonsi/si_pm4.c
index 446edea49a..1e686d8060 100644
--- a/src/gallium/drivers/radeonsi/si_pm4.c
+++ b/src/gallium/drivers/radeonsi/si_pm4.c
@@ -144,6 +144,9 @@ void si_pm4_emit(struct si_context *sctx, struct 
si_pm4_state *state)
radeon_emit(cs, ib->gpu_address >> 32);
radeon_emit(cs, (ib->b.b.width0 >> 2) & 0xf);
}
+
+   if (state->atom.emit)
+   state->atom.emit(sctx);
 }
 
 void si_pm4_reset_emitted(struct si_context *sctx)
diff --git a/src/gallium/drivers/radeonsi/si_pm4.h 
b/src/gallium/drivers/radeonsi/si_pm4.h
index 020da7a390..08e37714e4 100644
--- a/src/gallium/drivers/radeonsi/si_pm4.h
+++ b/src/gallium/drivers/radeonsi/si_pm4.h
@@ -33,8 +33,17 @@
 // forward defines
 struct si_context;
 
+/* State atoms are callbacks which write a sequence of packets into a GPU
+ * command buffer (AKA indirect buffer, AKA IB, AKA command stream, AKA CS).
+ */
+struct si_atom {
+   void (*emit)(struct si_context *ctx);
+};
+
 struct si_pm4_state
 {
+   struct si_shader *shader;
+
/* optional indirect buffer */
struct r600_resource*indirect_buffer;
 
@@ -52,6 +61,8 @@ struct si_pm4_state
struct r600_resource*bo[SI_PM4_MAX_BO];
enum radeon_bo_usagebo_usage[SI_PM4_MAX_BO];
enum radeon_bo_priority bo_priority[SI_PM4_MAX_BO];
+
+   struct si_atom atom;
 };
 
 void si_pm4_cmd_begin(struct si_pm4_state *state, unsigned opcode);
diff --git a/src/gallium/drivers/radeonsi/si_state.h 
b/src/gallium/drivers/radeonsi/si_state.h
index 89bb5b64a3..7fb09ca953 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -45,13 +45,6 @@ struct si_shader_selector;
 struct si_texture;
 struct si_qbo_state;
 
-/* State atoms are callbacks which write a sequence of packets into a GPU
- * command buffer (AKA indirect buffer, AKA IB, AKA command stream, AKA CS).
- */
-struct si_atom {
-   void (*emit)(struct si_context *ctx);
-};
-
 struct si_state_blend {
struct si_pm4_state pm4;
uint32_tcb_target_mask;
@@ -284,6 +277,8 @@ enum si_tracked_reg {
 
SI_TRACKED_PA_SC_CLIPRECT_RULE,
 
+   SI_TRACKED_VGT_ESGS_RING_ITEMSIZE,
+
SI_NUM_TRACKED_REGS,
 };
 
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 157a0e37eb..0716021d85 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -452,7 +452,13 @@ static struct si_pm4_state *si_get_shader_pm4_state(struct 
si_shader *shader)
else
shader->pm4 = CALLOC_STRUCT(si_pm4_state);
 
-   return shader->pm4;
+   if (shader->pm4) {
+   shader->pm4->shader = shader;
+   return shader->pm4;
+   } else {
+   fprintf(stderr, "radeonsi: Failed to create pm4 state.\n");
+   return NULL;
+   }
 }
 
 static unsigned si_get_num_vs_user_sgprs(unsigned num_always_on_user_sgprs)
@@ -552,6 +558,16 @@ static void si_shader_hs(struct si_screen *sscreen, struct 
si_shader *shader)
}
 }
 
+static void si_emit_shader_es(struct si_context *sctx)
+{
+   struct si_shader *shader = sctx->queued.named.es->shader;
+
+   if (shader)
+   radeon_opt_set_context_reg(sctx, 
R_028AAC_VGT_ESGS_RING_ITEMSIZE,
+  SI_TRACKED_VGT_ESGS_RING_ITEMSIZE,
+  shader->selector->esgs_itemsize / 4);
+}
+
 static void si_shader_es(struct si_screen *sscreen, struct si_shader *shader)
 {
struct si_pm4_state *pm4;
@@ -566,6 +582,7 @@ static void si_shader_es(struct 

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

[Roland Scheidegger]

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
 nice if someone has time to look into it (but I won't have, while I try
 to look into llvmpipe bugs that doesn't really extend to things which
 are likely app issues).

 Roland


> On 2018-09-18 16:55, Roland Scheidegger wrote:
>> I don't see any shadows at all with the 17.3.7 video?
>> Whereas the 18.0.0 one look quite bogus to me, but I think shadows are
>> known to be glitchy with id tech 3?
>> It should be possible to tweak shadows via cg_shadow (0-3),
>> r_stencilbits 8 might be necessary for some modes, r_dynamiclights 0
>> might also switch them off, if it works the same as with quake 3...
>>
>> Roland
>>
>>
>> Am 17.09.2018 um 18:55 schrieb Federico Dossena:
>>> Hi,
>>>
>>> I'm using Mesa (specifically Gallium on LLVMPipe) to run an old game
>>> called Star Trek Voyager Elite Force.
>>>
>>> I'd like to report a bug introduced with version 18.0.0 and still
>>> present in Mesa master that completely breaks the shadows in this
>>> game.
>>>
>>> I don't know how Mesa works i

[Mesa-dev] [Bug 107777] No 3D in "Vampire: The Masquerade - Bloodlines" when d3d-nine enabled

[bugzilla-daemon]

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

--- Comment #15 from Axel Davy  ---
"HKEY_CURRENT_USER/Software/Wine/DirectDrawRenderer="gdi"" did actually change
something to the behaviour with nine ? It looks bad, because it only affects
wined3d, and it could indicate that both are used, maybe because directdraw is
used or something, and nine doesn't support mixing these.

Could you produce a trace that pictures the "HUD misaligned" and "Game menu
after pressed ESC in game" ? Hopefully some of the issues with these can be
caught in a trace.

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

[Gert Wollny]

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.

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

Re: [Mesa-dev] [PATCH 5/5] docs/meson: Add note about llvm-config$version and llvm-config-$version

[Dylan Baker]

Quoting Eric Engestrom (2018-09-18 11:16:25)
> On Tuesday, 2018-09-18 09:13:04 -0700, Dylan Baker wrote:
> > These are how FreeBSD and Debian handle multiple versions of LLVM
> > installed at the same time, respectively.
> > ---
> >  docs/meson.html | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/docs/meson.html b/docs/meson.html
> > index 1640e577d16..d9148e44671 100644
> > --- a/docs/meson.html
> > +++ b/docs/meson.html
> > @@ -129,7 +129,8 @@ the popular compilers, a complete list is available
> >  LLVM
> >  Meson includes upstream logic to wrap llvm-config using it's 
> > standard
> 
> s/it's/its/
> 
> >  dependency interface. It will search $PATH (or 
> > %PATH% on windows) for
> > -llvm-config, so using an LLVM from a non-standard path is as easy as
> > +llvm-config (and llvm-config$version and llvm-config-$version), so using an
> > +LLVM from a non-standard path is as easy as
> >  PATH=/path/with/llvm-config:$PATH meson build.
> 
> Maybe follow up with a note explaining under what conditions meson will
> remember this?
> I have a feeling it might be forgotten by the next `reconfigure`.

Yeah. I really need to finish getting my config file stuff working so we have a
credible story for this. After lunch project I guess :)

> Reviewed-by: Eric Engestrom 
> 
> >  
> >  
> > -- 
> > 2.19.0
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 4/5] docs/meson: Update notes on using CFLAGS and -Dc_args

[Dylan Baker]

Quoting Eric Engestrom (2018-09-18 11:12:49)
> On Tuesday, 2018-09-18 09:13:03 -0700, Dylan Baker wrote:
> > bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107313
> > ---
> >  docs/meson.html | 28 ++--
> >  1 file changed, 14 insertions(+), 14 deletions(-)
> > 
> > diff --git a/docs/meson.html b/docs/meson.html
> > index e419d13e76d..1640e577d16 100644
> > --- a/docs/meson.html
> > +++ b/docs/meson.html
> > @@ -99,29 +99,29 @@ recommended in the documentation
> >  Environment Variables
> >  Meson supports the standard CC and CXX environment variables for
> >  changing the default compiler, and CFLAGS, CXXFLAGS, and LDFLAGS for 
> > setting
> > -options to the compiler and linker.
> > +options to the compiler and linker durring the initial configuration.
> 
> s/durring/during/
> 
> >  
> > -The default compilers depends on your operating system. Meson supports 
> > most of
> > -the popular compilers, a complete list is available
> > - > href="http://mesonbuild.com/Reference-tables.html#compiler-ids";>here.
> > -
> > -These arguments are consumed and stored by meson when it is initialized or
> > -re-initialized. Therefore passing them to meson configure will not do 
> > anything,
> > -and passing them to ninja will only do something if ninja decides to
> > -re-initialize meson, for example, if a meson.build file has been changed.
> > -Changing these variables will not cause all targets to be rebuilt, so 
> > running
> > -ninja clean is recommended when changing CFLAGS or CXXFLAGS. Meson will 
> > never
> > -change compiler in a configured build directory.
> > +These arguments are consumed and stored by meson when it is initialized. To
> > +change these flags after the build is initialized (or when doing a first
> > +initialization), consider using -D$lang_args and
> 
> How about {} around `lang` so that it's clear what is variable here?
> -D${lang}_args

Yes, that's much better. Normally I use , but html doesn't really like
that :)

> Reviewed-by: Eric Engestrom 
> 
> > +-D$lang_link_args instead. Meson will never change compiler 
> > in a
> > +configured build directory.
> >  
> >  
> >  
> >  CC=clang CXX=clang++ meson build-clang
> >  ninja -C build-clang
> >  ninja -C build-clang clean
> > -touch meson.build
> > -CFLAGS=-Wno-typedef-redefinition ninja -C build-clang
> > +meson configure build -Dc_args="-Wno-typedef-redefinition"
> > +ninja -C build-clang
> >  
> >  
> > +
> > +The default compilers depends on your operating system. Meson supports 
> > most of
> > +the popular compilers, a complete list is available
> > + > href="http://mesonbuild.com/Reference-tables.html#compiler-ids";>here.
> > +
> > +
> >  Meson also honors DESTDIR for installs
> >  
> >  
> > -- 
> > 2.19.0
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 1/5] meson: Don't compile pipe loader with dri support when not using dri

[Dylan Baker]

Quoting Eric Engestrom (2018-09-18 11:07:57)
> On Tuesday, 2018-09-18 19:02:55 +0100, Eric Engestrom wrote:
> > On Tuesday, 2018-09-18 09:13:00 -0700, Dylan Baker wrote:
> > > Corrects building glx as gallium-xlib without any dri targets.
> > > 
> > > Fixes: 66c94b9313a697ce8f2b222f4ba353035e4b8726
> > >("meson: build gallium winsys for dri, null, and wrapper")
> > 
> > Reviewed-by: Eric Engestrom 
> > 
> > > ---
> > >  src/gallium/auxiliary/pipe-loader/meson.build | 7 +--
> > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/src/gallium/auxiliary/pipe-loader/meson.build 
> > > b/src/gallium/auxiliary/pipe-loader/meson.build
> > > index 32e8188c68b..277a68057b9 100644
> > > --- a/src/gallium/auxiliary/pipe-loader/meson.build
> > > +++ b/src/gallium/auxiliary/pipe-loader/meson.build
> > > @@ -31,6 +31,9 @@ libpipe_loader_defines = []
> > >  if dep_libdrm.found()
> > >files_pipe_loader += files('pipe_loader_drm.c')
> > >  endif
> > > +if with_dri
> > > +  libpipe_loader_defines += '-DHAVE_PIPE_LOADER_DRI'
> > > +endif
> > >  if with_gallium_drisw_kms
> > >libpipe_loader_defines += '-DHAVE_PIPE_LOADER_KMS'
> > >  endif
> > > @@ -43,7 +46,7 @@ libpipe_loader_static = static_library(
> > >  inc_gallium_winsys,
> > >],
> > >c_args : [
> > > -c_vis_args, '-DHAVE_PIPE_LOADER_DRI', '-DGALLIUM_STATIC_TARGETS=1',
> > > +c_vis_args,'-DGALLIUM_STATIC_TARGETS=1',
> 
> Actually, missing space here ^

That whole block is badly formatted, there's a weird newline and a there's a
string wedged between two variables. Looks kinda like I committed before I
finished the formatting :/

> 
> > >  libpipe_loader_defines,
> > >],
> > >link_with : [libloader, libxmlconfig],
> > > @@ -59,7 +62,7 @@ libpipe_loader_dynamic = static_library(
> > >  inc_gallium_winsys,
> > >],
> > >c_args : [
> > > -c_vis_args, libpipe_loader_defines, '-DHAVE_PIPE_LOADER_DRI',
> > > +c_vis_args, libpipe_loader_defines,
> > >  '-DPIPE_SEARCH_DIR="@0@"'.format(
> > >join_paths(get_option('prefix'), get_option('libdir'), 
> > > 'gallium-pipe')
> > >  )
> > > -- 
> > > 2.19.0
> > > 
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [Bug 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 #15 from Gustaw Smolarczyk  ---
It turns out it really was a problem on mesa side. I think we should change the
resolution of the bug.

-- 
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] meson: add option to statically link llvm

[Christoph Haag]

On 9/18/18 6:56 PM, Dylan Baker wrote:
> I can't say I'm entirely thrilled, but:
> Reviewed-by: Dylan Baker 
> 
> Do you need me to push this for you?
> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Not thrilled about the special case of static llvm linking?

Unfortunately I do need it. My setup is a custom llvm installation in
/usr/lib/llvm-mesa/ and mesa linked to this installation.
Even with system and custom llvm using symbol versioning I get crashes
in applications that use both mesa and llvm.
For example kdevelep upses qt -> mesa -> llvm and it also uses
clang-complete -> llvm, which causes a crash.


The patch follows the example of the shared-glapi option, so I went for
consistency there.

Yes, I do not have push permissions so please push it.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: fix descriptor pool allocation size

[Samuel Pitoiset]

On 9/18/18 8:07 PM, Juan A. Suarez Romero wrote:

On Tue, 2018-09-18 at 17:20 +0200, Gustaw Smolarczyk wrote:

pt., 14 wrz 2018 o 15:00 Bas Nieuwenhuizen  
napisał(a):


Reviewed-by: Bas Nieuwenhuizen 
On Fri, Sep 14, 2018 at 2:55 PM Samuel Pitoiset
 wrote:


The size has to be multiplied by the number of sets.

This gets rid of the OUT_OF_POOL_KHR error and fixes
the Tangrams demo.

CC: 18.1 18.2 
Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_descriptor_set.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_descriptor_set.c 
b/src/amd/vulkan/radv_descriptor_set.c
index c4341f6ac5..49d0811bb0 100644
--- a/src/amd/vulkan/radv_descriptor_set.c
+++ b/src/amd/vulkan/radv_descriptor_set.c
@@ -569,9 +569,10 @@ VkResult radv_CreateDescriptorPool(
 }

 if (!(pCreateInfo->flags & 
VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT)) {
-   uint64_t host_size = pCreateInfo->maxSets * sizeof(struct 
radv_descriptor_set);
+   uint64_t host_size = sizeof(struct radv_descriptor_set);
 host_size += sizeof(struct radeon_winsys_bo*) * bo_count;
 host_size += sizeof(struct radv_descriptor_range) * 
range_count;
+   host_size *= pCreateInfo->maxSets;
 size += host_size;
 } else {
 size += sizeof(struct radv_descriptor_pool_entry) * 
pCreateInfo->maxSets;
--
2.19.0

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


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


I don't think this change is correct.



This patch was included for the next 18.2.1 release.

I understand this must be removed from the queue before the release, right? Or
is there another  patch to apply over or replace this?


You can remove it from the queue and I will revert it on master.
Thanks.





J.A.


 From the vkAllocateDescriptorSets documentation [1]:


If a call to vkAllocateDescriptorSets would cause the total number of
descriptor sets allocated from the pool to exceed the value of
VkDescriptorPoolCreateInfo::maxSets used to create
pAllocateInfo→descriptorPool, then the allocation may fail due to lack
of space in the descriptor pool. Similarly, the allocation may fail
due to lack of space if the call to vkAllocateDescriptorSets would
cause the number of any given descriptor type to exceed the sum of all
the descriptorCount members of each element of
VkDescriptorPoolCreateInfo::pPoolSizes with a member equal to that
type.


What it implies (I think), is that VkDescriptorPoolCreateInfo::maxSets
and descriptorCount of each VkDescriptorPoolCreateInfo::pPoolSizes are
treated separately. I don't think you should multiply one by another.
Each pool should be able to allocate at least maxSets sets and
descriptorCount descriptors.

Please, correct me if I'm wrong.

Regards,

Gustaw Smolarczyk

[1] 
https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkAllocateDescriptorSets.html
___
mesa-stable mailing list
mesa-sta...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-stable



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

Re: [Mesa-dev] [PATCH 5/5] docs/meson: Add note about llvm-config$version and llvm-config-$version

[Eric Engestrom]

On Tuesday, 2018-09-18 09:13:04 -0700, Dylan Baker wrote:
> These are how FreeBSD and Debian handle multiple versions of LLVM
> installed at the same time, respectively.
> ---
>  docs/meson.html | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/meson.html b/docs/meson.html
> index 1640e577d16..d9148e44671 100644
> --- a/docs/meson.html
> +++ b/docs/meson.html
> @@ -129,7 +129,8 @@ the popular compilers, a complete list is available
>  LLVM
>  Meson includes upstream logic to wrap llvm-config using it's standard

s/it's/its/

>  dependency interface. It will search $PATH (or 
> %PATH% on windows) for
> -llvm-config, so using an LLVM from a non-standard path is as easy as
> +llvm-config (and llvm-config$version and llvm-config-$version), so using an
> +LLVM from a non-standard path is as easy as
>  PATH=/path/with/llvm-config:$PATH meson build.

Maybe follow up with a note explaining under what conditions meson will
remember this?
I have a feeling it might be forgotten by the next `reconfigure`.

Reviewed-by: Eric Engestrom 

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

Re: [Mesa-dev] Lets talk about autotools

[Kai Wasserbäch]

Dylan Baker wrote on 9/18/18 6:40 PM:
> Quoting Kai Wasserbäch (2018-09-18 08:56:30)
>> Dylan Baker wrote on 9/18/18 5:35 PM:
>>> [...]
>>>
>>> This is something we've discussed upstream several times. I will freely 
>>> admit
>>> that llvm-config is a huge pain in the ass to deal with for a ton of 
>>> reasons,
>>> and since we don't use it at Intel
>>
>> Since there's now an „APU“ from Intel with an AMD GPU, I guess that is no 
>> longer
>> the case?
> 
> Our relationship with the KBL-G is complicated :)

Well, there's also SWR from Intel, which also relies on LLVM...

>>> it hasn't been on the top of my list of
>>> things to do, and also because the solution upstream wants is very 
>>> non-trival to
>>> implement. This has come up already and I am working on it right now.
>>
>> If upstream support is unreasonable, I'd like to see a similar solution to
>> LLVM_CONFIG as it's in autotools today. It must be possible to 
>> mangle/override
>> the meson variables right? (This might be totally ignorant, because I was 
>> able
>> to avoid Meson so far and all other build systems I've worked with, have one 
>> or
>> more options to set variables. Either by having an option in the build files 
>> or
>> by passing some option into the configure step.)
> 
> It really isn't, the only way we could really override this today is to allow
> you to pass a version requirement. One of the guiding ideas of meson is that
> complicated logic like "how the hell do you make a tool as
> broken-by-design-and-implementation as llvm-config work" should be part of 
> meson
> itself and not in the local build-system. The downside of that is that 
> upstream
> really wants you to think about how you handle things like overriding a 
> specific
> binary like llvm-config because it has to live with that decision for a long
> time.

I'm for the hiding, but why not do it in an easy to change way like the
"Find${FOO}.cmake" scripts? As long as you get certain variables populated
downstream is happy and an occasional change can be managed, if it should become
necessary. Having everything "in the core" sounds rather inflexible to me. Or
I'm misunderstanding you. Anyway, this isn't really the topic here.

>>> The other option you have it to set the $PATH variable, as long as the
>>> llvm-config you want returns the highest version things will work as you 
>>> expect.
>>
>> This might do as a workaround, though I'm not too keen on extending $PATH. 
>> But
>> as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain that
>> versions binaries, putting it first into the path could work.
> 
> meson will cache the llvm-config values, so you should be able to just do
> something like:
> 
> PATH=/path/to/my/llvm meson build-with-my-llvm

Ok. Where's the cache? In the build directory or is this something, that's kept
globally and needs potential clearing? A quick search for this feature yielded
. That makes it sound like
it is global, which I would almost consider broken design. Or is it local but
kept between multiple invocations of meson? That also sounds like a recipe for
disaster, though it would be easier to deal with: just nuke the build directory.

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 4/5] docs/meson: Update notes on using CFLAGS and -Dc_args

[Eric Engestrom]

On Tuesday, 2018-09-18 09:13:03 -0700, Dylan Baker wrote:
> bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107313
> ---
>  docs/meson.html | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/docs/meson.html b/docs/meson.html
> index e419d13e76d..1640e577d16 100644
> --- a/docs/meson.html
> +++ b/docs/meson.html
> @@ -99,29 +99,29 @@ recommended in the documentation
>  Environment Variables
>  Meson supports the standard CC and CXX environment variables for
>  changing the default compiler, and CFLAGS, CXXFLAGS, and LDFLAGS for setting
> -options to the compiler and linker.
> +options to the compiler and linker durring the initial configuration.

s/durring/during/

>  
> -The default compilers depends on your operating system. Meson supports most 
> of
> -the popular compilers, a complete list is available
> -http://mesonbuild.com/Reference-tables.html#compiler-ids";>here.
> -
> -These arguments are consumed and stored by meson when it is initialized or
> -re-initialized. Therefore passing them to meson configure will not do 
> anything,
> -and passing them to ninja will only do something if ninja decides to
> -re-initialize meson, for example, if a meson.build file has been changed.
> -Changing these variables will not cause all targets to be rebuilt, so running
> -ninja clean is recommended when changing CFLAGS or CXXFLAGS. Meson will never
> -change compiler in a configured build directory.
> +These arguments are consumed and stored by meson when it is initialized. To
> +change these flags after the build is initialized (or when doing a first
> +initialization), consider using -D$lang_args and

How about {} around `lang` so that it's clear what is variable here?
-D${lang}_args

Reviewed-by: Eric Engestrom 

> +-D$lang_link_args instead. Meson will never change compiler in a
> +configured build directory.
>  
>  
>  
>  CC=clang CXX=clang++ meson build-clang
>  ninja -C build-clang
>  ninja -C build-clang clean
> -touch meson.build
> -CFLAGS=-Wno-typedef-redefinition ninja -C build-clang
> +meson configure build -Dc_args="-Wno-typedef-redefinition"
> +ninja -C build-clang
>  
>  
> +
> +The default compilers depends on your operating system. Meson supports most 
> of
> +the popular compilers, a complete list is available
> +http://mesonbuild.com/Reference-tables.html#compiler-ids";>here.
> +
> +
>  Meson also honors DESTDIR for installs
>  
>  
> -- 
> 2.19.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] docs: update meson docs to reflect the current status

[Eric Engestrom]

On Tuesday, 2018-09-18 09:13:02 -0700, Dylan Baker wrote:
> ---
>  docs/meson.html | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/meson.html b/docs/meson.html
> index 29907a60a9c..e419d13e76d 100644
> --- a/docs/meson.html
> +++ b/docs/meson.html
> @@ -21,10 +21,10 @@
>  The Meson build system is generally considered stable and ready
>  for production
>  
> -The meson build is tested on on Linux, macOS, Cygwin and Haiku, it should
> -work on FreeBSD, DragonflyBSD, NetBSD, and OpenBSD.
> +The meson build is tested on on Linux, macOS, Cygwin and Haiku, FreeBSD,

s/ and/,/; s/on on/only on/

Reviewed-by: Eric Engestrom 

> +DragonflyBSD, and NetBSD; and should work on OpenBSD.
>  
> -Mesa requires Meson >= 0.44.1 to build.
> +Mesa requires Meson >= 0.45.0 to build.
>  
>  Some older versions of meson do not check that they are too old and will 
> error
>  out in odd ways.
> -- 
> 2.19.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: fix descriptor pool allocation size

[Juan A. Suarez Romero]

On Tue, 2018-09-18 at 17:20 +0200, Gustaw Smolarczyk wrote:
> pt., 14 wrz 2018 o 15:00 Bas Nieuwenhuizen  
> napisał(a):
> > 
> > Reviewed-by: Bas Nieuwenhuizen 
> > On Fri, Sep 14, 2018 at 2:55 PM Samuel Pitoiset
> >  wrote:
> > > 
> > > The size has to be multiplied by the number of sets.
> > > 
> > > This gets rid of the OUT_OF_POOL_KHR error and fixes
> > > the Tangrams demo.
> > > 
> > > CC: 18.1 18.2 
> > > Signed-off-by: Samuel Pitoiset 
> > > ---
> > >  src/amd/vulkan/radv_descriptor_set.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/src/amd/vulkan/radv_descriptor_set.c 
> > > b/src/amd/vulkan/radv_descriptor_set.c
> > > index c4341f6ac5..49d0811bb0 100644
> > > --- a/src/amd/vulkan/radv_descriptor_set.c
> > > +++ b/src/amd/vulkan/radv_descriptor_set.c
> > > @@ -569,9 +569,10 @@ VkResult radv_CreateDescriptorPool(
> > > }
> > > 
> > > if (!(pCreateInfo->flags & 
> > > VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT)) {
> > > -   uint64_t host_size = pCreateInfo->maxSets * sizeof(struct 
> > > radv_descriptor_set);
> > > +   uint64_t host_size = sizeof(struct radv_descriptor_set);
> > > host_size += sizeof(struct radeon_winsys_bo*) * bo_count;
> > > host_size += sizeof(struct radv_descriptor_range) * 
> > > range_count;
> > > +   host_size *= pCreateInfo->maxSets;
> > > size += host_size;
> > > } else {
> > > size += sizeof(struct radv_descriptor_pool_entry) * 
> > > pCreateInfo->maxSets;
> > > --
> > > 2.19.0
> > > 
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> I don't think this change is correct.
> 

This patch was included for the next 18.2.1 release.

I understand this must be removed from the queue before the release, right? Or
is there another  patch to apply over or replace this?



J.A.

> From the vkAllocateDescriptorSets documentation [1]:
> 
> 
> If a call to vkAllocateDescriptorSets would cause the total number of
> descriptor sets allocated from the pool to exceed the value of
> VkDescriptorPoolCreateInfo::maxSets used to create
> pAllocateInfo→descriptorPool, then the allocation may fail due to lack
> of space in the descriptor pool. Similarly, the allocation may fail
> due to lack of space if the call to vkAllocateDescriptorSets would
> cause the number of any given descriptor type to exceed the sum of all
> the descriptorCount members of each element of
> VkDescriptorPoolCreateInfo::pPoolSizes with a member equal to that
> type.
> 
> 
> What it implies (I think), is that VkDescriptorPoolCreateInfo::maxSets
> and descriptorCount of each VkDescriptorPoolCreateInfo::pPoolSizes are
> treated separately. I don't think you should multiply one by another.
> Each pool should be able to allocate at least maxSets sets and
> descriptorCount descriptors.
> 
> Please, correct me if I'm wrong.
> 
> Regards,
> 
> Gustaw Smolarczyk
> 
> [1] 
> https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkAllocateDescriptorSets.html
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable

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

Re: [Mesa-dev] [PATCH 1/5] meson: Don't compile pipe loader with dri support when not using dri

[Eric Engestrom]

On Tuesday, 2018-09-18 19:02:55 +0100, Eric Engestrom wrote:
> On Tuesday, 2018-09-18 09:13:00 -0700, Dylan Baker wrote:
> > Corrects building glx as gallium-xlib without any dri targets.
> > 
> > Fixes: 66c94b9313a697ce8f2b222f4ba353035e4b8726
> >("meson: build gallium winsys for dri, null, and wrapper")
> 
> Reviewed-by: Eric Engestrom 
> 
> > ---
> >  src/gallium/auxiliary/pipe-loader/meson.build | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/gallium/auxiliary/pipe-loader/meson.build 
> > b/src/gallium/auxiliary/pipe-loader/meson.build
> > index 32e8188c68b..277a68057b9 100644
> > --- a/src/gallium/auxiliary/pipe-loader/meson.build
> > +++ b/src/gallium/auxiliary/pipe-loader/meson.build
> > @@ -31,6 +31,9 @@ libpipe_loader_defines = []
> >  if dep_libdrm.found()
> >files_pipe_loader += files('pipe_loader_drm.c')
> >  endif
> > +if with_dri
> > +  libpipe_loader_defines += '-DHAVE_PIPE_LOADER_DRI'
> > +endif
> >  if with_gallium_drisw_kms
> >libpipe_loader_defines += '-DHAVE_PIPE_LOADER_KMS'
> >  endif
> > @@ -43,7 +46,7 @@ libpipe_loader_static = static_library(
> >  inc_gallium_winsys,
> >],
> >c_args : [
> > -c_vis_args, '-DHAVE_PIPE_LOADER_DRI', '-DGALLIUM_STATIC_TARGETS=1',
> > +c_vis_args,'-DGALLIUM_STATIC_TARGETS=1',

Actually, missing space here ^

> >  libpipe_loader_defines,
> >],
> >link_with : [libloader, libxmlconfig],
> > @@ -59,7 +62,7 @@ libpipe_loader_dynamic = static_library(
> >  inc_gallium_winsys,
> >],
> >c_args : [
> > -c_vis_args, libpipe_loader_defines, '-DHAVE_PIPE_LOADER_DRI',
> > +c_vis_args, libpipe_loader_defines,
> >  '-DPIPE_SEARCH_DIR="@0@"'.format(
> >join_paths(get_option('prefix'), get_option('libdir'), 
> > 'gallium-pipe')
> >  )
> > -- 
> > 2.19.0
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/5] meson: Don't force libva to required from auto

[Eric Engestrom]

On Tuesday, 2018-09-18 09:13:01 -0700, Dylan Baker wrote:
> We already correctly handle va being auto, but we force it to being
> true, which is bad.
> 
> Fixes 94cf3970925ec87d913a1549a42cdb03713fc4bb
>   ("meson: Fix auto option for va")

Reviewed-by: Eric Engestrom 

> ---
>  meson.build | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 0588ebf8e7a..97098abdfa3 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -569,8 +569,6 @@ elif not (with_gallium_r600 or with_gallium_radeonsi or 
> with_gallium_nouveau)
>else
>  _va = 'false'
>endif
> -elif _va == 'auto'
> -  _va = 'true'
>  endif
>  with_gallium_va = false
>  dep_va = null_dep
> -- 
> 2.19.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] meson: Don't compile pipe loader with dri support when not using dri

[Eric Engestrom]

On Tuesday, 2018-09-18 09:13:00 -0700, Dylan Baker wrote:
> Corrects building glx as gallium-xlib without any dri targets.
> 
> Fixes: 66c94b9313a697ce8f2b222f4ba353035e4b8726
>("meson: build gallium winsys for dri, null, and wrapper")

Reviewed-by: Eric Engestrom 

> ---
>  src/gallium/auxiliary/pipe-loader/meson.build | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/pipe-loader/meson.build 
> b/src/gallium/auxiliary/pipe-loader/meson.build
> index 32e8188c68b..277a68057b9 100644
> --- a/src/gallium/auxiliary/pipe-loader/meson.build
> +++ b/src/gallium/auxiliary/pipe-loader/meson.build
> @@ -31,6 +31,9 @@ libpipe_loader_defines = []
>  if dep_libdrm.found()
>files_pipe_loader += files('pipe_loader_drm.c')
>  endif
> +if with_dri
> +  libpipe_loader_defines += '-DHAVE_PIPE_LOADER_DRI'
> +endif
>  if with_gallium_drisw_kms
>libpipe_loader_defines += '-DHAVE_PIPE_LOADER_KMS'
>  endif
> @@ -43,7 +46,7 @@ libpipe_loader_static = static_library(
>  inc_gallium_winsys,
>],
>c_args : [
> -c_vis_args, '-DHAVE_PIPE_LOADER_DRI', '-DGALLIUM_STATIC_TARGETS=1',
> +c_vis_args,'-DGALLIUM_STATIC_TARGETS=1',
>  libpipe_loader_defines,
>],
>link_with : [libloader, libxmlconfig],
> @@ -59,7 +62,7 @@ libpipe_loader_dynamic = static_library(
>  inc_gallium_winsys,
>],
>c_args : [
> -c_vis_args, libpipe_loader_defines, '-DHAVE_PIPE_LOADER_DRI',
> +c_vis_args, libpipe_loader_defines,
>  '-DPIPE_SEARCH_DIR="@0@"'.format(
>join_paths(get_option('prefix'), get_option('libdir'), 'gallium-pipe')
>  )
> -- 
> 2.19.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Dylan Baker]

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.


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] radv: fix descriptor pool allocation size

[Samuel Pitoiset]

On 9/18/18 5:20 PM, Gustaw Smolarczyk wrote:

pt., 14 wrz 2018 o 15:00 Bas Nieuwenhuizen  
napisał(a):


Reviewed-by: Bas Nieuwenhuizen 
On Fri, Sep 14, 2018 at 2:55 PM Samuel Pitoiset
 wrote:


The size has to be multiplied by the number of sets.

This gets rid of the OUT_OF_POOL_KHR error and fixes
the Tangrams demo.

CC: 18.1 18.2 
Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_descriptor_set.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_descriptor_set.c 
b/src/amd/vulkan/radv_descriptor_set.c
index c4341f6ac5..49d0811bb0 100644
--- a/src/amd/vulkan/radv_descriptor_set.c
+++ b/src/amd/vulkan/radv_descriptor_set.c
@@ -569,9 +569,10 @@ VkResult radv_CreateDescriptorPool(
 }

 if (!(pCreateInfo->flags & 
VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT)) {
-   uint64_t host_size = pCreateInfo->maxSets * sizeof(struct 
radv_descriptor_set);
+   uint64_t host_size = sizeof(struct radv_descriptor_set);
 host_size += sizeof(struct radeon_winsys_bo*) * bo_count;
 host_size += sizeof(struct radv_descriptor_range) * 
range_count;
+   host_size *= pCreateInfo->maxSets;
 size += host_size;
 } else {
 size += sizeof(struct radv_descriptor_pool_entry) * 
pCreateInfo->maxSets;
--
2.19.0

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

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


I don't think this change is correct.

 From the vkAllocateDescriptorSets documentation [1]:


If a call to vkAllocateDescriptorSets would cause the total number of
descriptor sets allocated from the pool to exceed the value of
VkDescriptorPoolCreateInfo::maxSets used to create
pAllocateInfo→descriptorPool, then the allocation may fail due to lack
of space in the descriptor pool. Similarly, the allocation may fail
due to lack of space if the call to vkAllocateDescriptorSets would
cause the number of any given descriptor type to exceed the sum of all
the descriptorCount members of each element of
VkDescriptorPoolCreateInfo::pPoolSizes with a member equal to that
type.


Yes. As I said to Bas over IRC that app is actually buggy and I have 
been confused. This patch should be reverted and the bug reported.


FWIW, it works with AMDVLK because they seem to always allocate more 
space than needed.





What it implies (I think), is that VkDescriptorPoolCreateInfo::maxSets
and descriptorCount of each VkDescriptorPoolCreateInfo::pPoolSizes are
treated separately. I don't think you should multiply one by another.
Each pool should be able to allocate at least maxSets sets and
descriptorCount descriptors.

Please, correct me if I'm wrong.

Regards,

Gustaw Smolarczyk

[1] 
https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkAllocateDescriptorSets.html


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

Re: [Mesa-dev] [PATCH] radv: fix descriptor pool allocation size

[Bas Nieuwenhuizen]

On Tue, 18 Sep 2018, 17:21 Gustaw Smolarczyk,  wrote:

> pt., 14 wrz 2018 o 15:00 Bas Nieuwenhuizen 
> napisał(a):
> >
> > Reviewed-by: Bas Nieuwenhuizen 
> > On Fri, Sep 14, 2018 at 2:55 PM Samuel Pitoiset
> >  wrote:
> > >
> > > The size has to be multiplied by the number of sets.
> > >
> > > This gets rid of the OUT_OF_POOL_KHR error and fixes
> > > the Tangrams demo.
> > >
> > > CC: 18.1 18.2 
> > > Signed-off-by: Samuel Pitoiset 
> > > ---
> > >  src/amd/vulkan/radv_descriptor_set.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/amd/vulkan/radv_descriptor_set.c
> b/src/amd/vulkan/radv_descriptor_set.c
> > > index c4341f6ac5..49d0811bb0 100644
> > > --- a/src/amd/vulkan/radv_descriptor_set.c
> > > +++ b/src/amd/vulkan/radv_descriptor_set.c
> > > @@ -569,9 +569,10 @@ VkResult radv_CreateDescriptorPool(
> > > }
> > >
> > > if (!(pCreateInfo->flags &
> VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT)) {
> > > -   uint64_t host_size = pCreateInfo->maxSets *
> sizeof(struct radv_descriptor_set);
> > > +   uint64_t host_size = sizeof(struct
> radv_descriptor_set);
> > > host_size += sizeof(struct radeon_winsys_bo*) *
> bo_count;
> > > host_size += sizeof(struct radv_descriptor_range) *
> range_count;
> > > +   host_size *= pCreateInfo->maxSets;
> > > size += host_size;
> > > } else {
> > > size += sizeof(struct radv_descriptor_pool_entry) *
> pCreateInfo->maxSets;
> > > --
> > > 2.19.0
> > >
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> I don't think this change is correct.
>
> From the vkAllocateDescriptorSets documentation [1]:
>
>
> If a call to vkAllocateDescriptorSets would cause the total number of
> descriptor sets allocated from the pool to exceed the value of
> VkDescriptorPoolCreateInfo::maxSets used to create
> pAllocateInfo→descriptorPool, then the allocation may fail due to lack
> of space in the descriptor pool. Similarly, the allocation may fail
> due to lack of space if the call to vkAllocateDescriptorSets would
> cause the number of any given descriptor type to exceed the sum of all
> the descriptorCount members of each element of
> VkDescriptorPoolCreateInfo::pPoolSizes with a member equal to that
> type.
>
>
> What it implies (I think), is that VkDescriptorPoolCreateInfo::maxSets
> and descriptorCount of each VkDescriptorPoolCreateInfo::pPoolSizes are
> treated separately. I don't think you should multiply one by another.
> Each pool should be able to allocate at least maxSets sets and
> descriptorCount descriptors.
>

Totally agree. Was thinking about the descriptors set allocation logic
instead of the pool logic when reviewing this ... Apologies.

>
> Please, correct me if I'm wrong.
>
> Regards,
>
> Gustaw Smolarczyk
>
> [1]
> https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkAllocateDescriptorSets.html
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Eric Engestrom]

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.

You're about 30 years too late to try to change this ¯\_(ツ)_/¯

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

Re: [Mesa-dev] [PATCH] meson: add option to statically link llvm

[Dylan Baker]

Quoting Christoph Haag (2018-09-17 16:08:07)
> From: Christoph Haag 
> 
> ---
>  meson.build   | 4 
>  meson_options.txt | 6 ++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/meson.build b/meson.build
> index 0588ebf8e7a..5e250470ed1 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1188,6 +1188,8 @@ else
>_llvm_version = '>= 3.3.0'
>  endif
>  
> +_shared_llvm = get_option('shared-llvm')
> +
>  _llvm = get_option('llvm')
>  if _llvm == 'auto'
>dep_llvm = dependency(
> @@ -1196,6 +1198,7 @@ if _llvm == 'auto'
>  modules : llvm_modules,
>  optional_modules : llvm_optional_modules,
>  required : with_amd_vk or with_gallium_radeonsi or with_gallium_swr or 
> with_gallium_opencl,
> +static : not _shared_llvm
>)
>with_llvm = dep_llvm.found()
>  elif _llvm == 'true'
> @@ -1204,6 +1207,7 @@ elif _llvm == 'true'
>  version : _llvm_version,
>  modules : llvm_modules,
>  optional_modules : llvm_optional_modules,
> +static : not _shared_llvm,
>)
>with_llvm = true
>  else
> diff --git a/meson_options.txt b/meson_options.txt
> index 5676ef5e45d..18c03921db2 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -237,6 +237,12 @@ option(
>choices : ['auto', 'true', 'false'],
>description : 'Build with LLVM support.'
>  )
> +option(
> +  'shared-llvm',
> +  type : 'boolean',
> +  value : true,
> +  description : 'Whether to link llvm shared or statically.'
> +)
>  option(
>'valgrind',
>type : 'combo',
> -- 
> 2.19.0
> 

I can't say I'm entirely thrilled, but:
Reviewed-by: Dylan Baker 

Do you need me to push this for you?


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

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 Kai Wasserbäch (2018-09-18 08:56:30)
> Dylan Baker wrote on 9/18/18 5:35 PM:
> > Quoting Kai Wasserbäch (2018-09-18 07:43:08)
> >> Hey,
> >> Dylan Baker wrote on 9/17/18 6:44 PM:
> >>> 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.
> >>
> >> How do I set a specific llvm-config name to look for? I have build 
> >> environments
> >> with multiple LLVM versions (eg. 6, 7 and 8) installed in parallel. So far 
> >> I
> >> could convince each build system with LLVM_CONFIG or similar means to 
> >> choose a
> >> particular llvm-config-${LLVM_VERSION], meson can't do that AFAICT.
> >>
> >> Eric pointed me to an ugly hack on IRC, which involves symlinking the 
> >> particular
> >> llvm-config-${VERSION} to llvm-config in $PATH
> >> ().
> >> But I think this should be fixed properly before making meson mandatory. 
> >> Other
> >> modern build systems like CMake react to something like -DLLVM_DIR during
> >> configure (see
> >> ) and 
> >> Mesa's
> >> stable build systems use LLVM_CONFIG, if set.
> >>
> >> Cheers,
> >> Kai
> > 
> > This is something we've discussed upstream several times. I will freely 
> > admit
> > that llvm-config is a huge pain in the ass to deal with for a ton of 
> > reasons,
> > and since we don't use it at Intel
> 
> Since there's now an „APU“ from Intel with an AMD GPU, I guess that is no 
> longer
> the case?

Our relationship with the KBL-G is complicated :)

> > it hasn't been on the top of my list of
> > things to do, and also because the solution upstream wants is very 
> > non-trival to
> > implement. This has come up already and I am working on it right now.
> 
> If upstream support is unreasonable, I'd like to see a similar solution to
> LLVM_CONFIG as it's in autotools today. It must be possible to mangle/override
> the meson variables right? (This might be totally ignorant, because I was able
> to avoid Meson so far and all other build systems I've worked with, have one 
> or
> more options to set variables. Either by having an option in the build files 
> or
> by passing some option into the configure step.)

It really isn't, the only way we could really override this today is to allow
you to pass a version requirement. One of the guiding ideas of meson is that
complicated logic like "how the hell do you make a tool as
broken-by-design-and-implementation as llvm-config work" should be part of meson
itself and not in the local build-system. The downside of that is that upstream
really wants you to think about how you handle things like overriding a specific
binary like llvm-config because it has to live with that decision for a long
time.

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

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 Chuck Atkins (2018-09-18 08:00:44)
> First, I'm fully in support of killing off autotools woo-hoo to that.  And
> given the substantial investment already put into the meson build that
> certainly seems like a good direction to go.
> 
> That being said, the way "auto" is currently implemented leaves quite a bit to
> be desired.  One of the nice features of the Autotools build was how
> auto-enabled options were treated in that the dependencies were searched for
> and if they were all found and met then the option would be enabled.  My
> experience so far with the meson build has shown this not to be the case and a
> "configure" with no options has yet to be successful for me.  Many of the
> 'auto' options are treated as 'set to true if your platform supports it'
> regardless of whether your system has the requisite dependencies available. 
> For example"
> 
>   • The 'gallium-va' option defaults to 'auto' but the implementation ends up
> setting the '_va' option to true if the other option conditions are met,
> long before libva is searched for.  So then when libva isn't found one 
> gets
> an error.
>   □ if set to auto then missing the libva dependencies should be a 
> failure,
> it should just disable the gallium va state tracker

This is a bug I noticed earlier, I think I have a patch for it I just never sent
out apparently. I've send that out now.

>   • The platform options set to 'auto'  has a set of checks to determine which
> platforms are enabled as required.  If the system_has_kms_drm check is 
> true
> then Wayland is enabled as required.  Later if the check for wayland
> dependencies fails, an error occurs.
>   □ If platforms are set to auto then a failure to locate dependencies for
> a given platform should disable the platform.
> 
> I realize these are just two specific examples, each of which can be readily
> dealt with in their own specific way so I'm not asking "how to I address #1 
> and
> #2?" because I can certainly do that.  These are just two instances of many
> though in the way "auto" is dealt with.  My point is really a broader one that
> before meson becomes the primary build then the behavior of "auto" should
> create a successful configure out of the box without additional options. 

This is a much harder thing to fix, I'll look into it, but it'll take at least a
few days to get this done.

> 
> --
> Chuck Atkins
> Staff R&D Engineer, Scientific Computing
> Kitware, Inc.
> 
> 
> On Tue, Sep 18, 2018 at 9:04 AM Eric Engestrom 
> wrote:
> 
> On Monday, 2018-09-17 17:25:36 -0400, Marek Olšák wrote:
> > Where do I find default values for meson configure options?
> 
> If you mean the project's options, they're in meson_options.txt;
> currently not printed in the output of `meson configure` though.
> 
> If you mean Meson's own options (like `buildtype`), I don't think that
> information exists anywhere outside of Meson's source code (and it's
> affected by meson.build too).
> 
> It might be worth opening an issue upstream to ask for and track the
> progress of this feature if you want it :)
> 
> >
> > 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
> 


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

[Mesa-dev] [PATCH 4/5] docs/meson: Update notes on using CFLAGS and -Dc_args

[Dylan Baker]

bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107313
---
 docs/meson.html | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/docs/meson.html b/docs/meson.html
index e419d13e76d..1640e577d16 100644
--- a/docs/meson.html
+++ b/docs/meson.html
@@ -99,29 +99,29 @@ recommended in the documentation
 Environment Variables
 Meson supports the standard CC and CXX environment variables for
 changing the default compiler, and CFLAGS, CXXFLAGS, and LDFLAGS for setting
-options to the compiler and linker.
+options to the compiler and linker durring the initial configuration.
 
-The default compilers depends on your operating system. Meson supports most of
-the popular compilers, a complete list is available
-http://mesonbuild.com/Reference-tables.html#compiler-ids";>here.
-
-These arguments are consumed and stored by meson when it is initialized or
-re-initialized. Therefore passing them to meson configure will not do anything,
-and passing them to ninja will only do something if ninja decides to
-re-initialize meson, for example, if a meson.build file has been changed.
-Changing these variables will not cause all targets to be rebuilt, so running
-ninja clean is recommended when changing CFLAGS or CXXFLAGS. Meson will never
-change compiler in a configured build directory.
+These arguments are consumed and stored by meson when it is initialized. To
+change these flags after the build is initialized (or when doing a first
+initialization), consider using -D$lang_args and
+-D$lang_link_args instead. Meson will never change compiler in a
+configured build directory.
 
 
 
 CC=clang CXX=clang++ meson build-clang
 ninja -C build-clang
 ninja -C build-clang clean
-touch meson.build
-CFLAGS=-Wno-typedef-redefinition ninja -C build-clang
+meson configure build -Dc_args="-Wno-typedef-redefinition"
+ninja -C build-clang
 
 
+
+The default compilers depends on your operating system. Meson supports most of
+the popular compilers, a complete list is available
+http://mesonbuild.com/Reference-tables.html#compiler-ids";>here.
+
+
 Meson also honors DESTDIR for installs
 
 
-- 
2.19.0

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

[Mesa-dev] [PATCH 3/5] docs: update meson docs to reflect the current status

[Dylan Baker]

---
 docs/meson.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/meson.html b/docs/meson.html
index 29907a60a9c..e419d13e76d 100644
--- a/docs/meson.html
+++ b/docs/meson.html
@@ -21,10 +21,10 @@
 The Meson build system is generally considered stable and ready
 for production
 
-The meson build is tested on on Linux, macOS, Cygwin and Haiku, it should
-work on FreeBSD, DragonflyBSD, NetBSD, and OpenBSD.
+The meson build is tested on on Linux, macOS, Cygwin and Haiku, FreeBSD,
+DragonflyBSD, and NetBSD; and should work on OpenBSD.
 
-Mesa requires Meson >= 0.44.1 to build.
+Mesa requires Meson >= 0.45.0 to build.
 
 Some older versions of meson do not check that they are too old and will error
 out in odd ways.
-- 
2.19.0

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

[Mesa-dev] [PATCH 1/5] meson: Don't compile pipe loader with dri support when not using dri

[Dylan Baker]

Corrects building glx as gallium-xlib without any dri targets.

Fixes: 66c94b9313a697ce8f2b222f4ba353035e4b8726
   ("meson: build gallium winsys for dri, null, and wrapper")
---
 src/gallium/auxiliary/pipe-loader/meson.build | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/pipe-loader/meson.build 
b/src/gallium/auxiliary/pipe-loader/meson.build
index 32e8188c68b..277a68057b9 100644
--- a/src/gallium/auxiliary/pipe-loader/meson.build
+++ b/src/gallium/auxiliary/pipe-loader/meson.build
@@ -31,6 +31,9 @@ libpipe_loader_defines = []
 if dep_libdrm.found()
   files_pipe_loader += files('pipe_loader_drm.c')
 endif
+if with_dri
+  libpipe_loader_defines += '-DHAVE_PIPE_LOADER_DRI'
+endif
 if with_gallium_drisw_kms
   libpipe_loader_defines += '-DHAVE_PIPE_LOADER_KMS'
 endif
@@ -43,7 +46,7 @@ libpipe_loader_static = static_library(
 inc_gallium_winsys,
   ],
   c_args : [
-c_vis_args, '-DHAVE_PIPE_LOADER_DRI', '-DGALLIUM_STATIC_TARGETS=1',
+c_vis_args,'-DGALLIUM_STATIC_TARGETS=1',
 libpipe_loader_defines,
   ],
   link_with : [libloader, libxmlconfig],
@@ -59,7 +62,7 @@ libpipe_loader_dynamic = static_library(
 inc_gallium_winsys,
   ],
   c_args : [
-c_vis_args, libpipe_loader_defines, '-DHAVE_PIPE_LOADER_DRI',
+c_vis_args, libpipe_loader_defines,
 '-DPIPE_SEARCH_DIR="@0@"'.format(
   join_paths(get_option('prefix'), get_option('libdir'), 'gallium-pipe')
 )
-- 
2.19.0

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

[Mesa-dev] [PATCH 5/5] docs/meson: Add note about llvm-config$version and llvm-config-$version

[Dylan Baker]

These are how FreeBSD and Debian handle multiple versions of LLVM
installed at the same time, respectively.
---
 docs/meson.html | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/docs/meson.html b/docs/meson.html
index 1640e577d16..d9148e44671 100644
--- a/docs/meson.html
+++ b/docs/meson.html
@@ -129,7 +129,8 @@ the popular compilers, a complete list is available
 LLVM
 Meson includes upstream logic to wrap llvm-config using it's standard
 dependency interface. It will search $PATH (or 
%PATH% on windows) for
-llvm-config, so using an LLVM from a non-standard path is as easy as
+llvm-config (and llvm-config$version and llvm-config-$version), so using an
+LLVM from a non-standard path is as easy as
 PATH=/path/with/llvm-config:$PATH meson build.
 
 
-- 
2.19.0

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

[Mesa-dev] [PATCH 2/5] meson: Don't force libva to required from auto

[Dylan Baker]

We already correctly handle va being auto, but we force it to being
true, which is bad.

Fixes 94cf3970925ec87d913a1549a42cdb03713fc4bb
  ("meson: Fix auto option for va")
---
 meson.build | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meson.build b/meson.build
index 0588ebf8e7a..97098abdfa3 100644
--- a/meson.build
+++ b/meson.build
@@ -569,8 +569,6 @@ elif not (with_gallium_r600 or with_gallium_radeonsi or 
with_gallium_nouveau)
   else
 _va = 'false'
   endif
-elif _va == 'auto'
-  _va = 'true'
 endif
 with_gallium_va = false
 dep_va = null_dep
-- 
2.19.0

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

[Mesa-dev] [Bug 104843] Mesa version not updated for rebuild

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEEDINFO|RESOLVED

--- Comment #2 from Dylan Baker  ---
Since I can't reproduce this and Mark hasn't commented I'm closing this. Reopen
if needed.

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

Re: [Mesa-dev] Lets talk about autotools

[Eric Engestrom]

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šá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.

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

Re: [Mesa-dev] Lets talk about autotools

[Kai Wasserbäch]

Dylan Baker wrote on 9/18/18 5:35 PM:
> Quoting Kai Wasserbäch (2018-09-18 07:43:08)
>> Hey,
>> Dylan Baker wrote on 9/17/18 6:44 PM:
>>> 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.
>>
>> How do I set a specific llvm-config name to look for? I have build 
>> environments
>> with multiple LLVM versions (eg. 6, 7 and 8) installed in parallel. So far I
>> could convince each build system with LLVM_CONFIG or similar means to choose 
>> a
>> particular llvm-config-${LLVM_VERSION], meson can't do that AFAICT.
>>
>> Eric pointed me to an ugly hack on IRC, which involves symlinking the 
>> particular
>> llvm-config-${VERSION} to llvm-config in $PATH
>> ().
>> But I think this should be fixed properly before making meson mandatory. 
>> Other
>> modern build systems like CMake react to something like -DLLVM_DIR during
>> configure (see
>> ) and Mesa's
>> stable build systems use LLVM_CONFIG, if set.
>>
>> Cheers,
>> Kai
> 
> This is something we've discussed upstream several times. I will freely admit
> that llvm-config is a huge pain in the ass to deal with for a ton of reasons,
> and since we don't use it at Intel

Since there's now an „APU“ from Intel with an AMD GPU, I guess that is no longer
the case?

> it hasn't been on the top of my list of
> things to do, and also because the solution upstream wants is very non-trival 
> to
> implement. This has come up already and I am working on it right now.

If upstream support is unreasonable, I'd like to see a similar solution to
LLVM_CONFIG as it's in autotools today. It must be possible to mangle/override
the meson variables right? (This might be totally ignorant, because I was able
to avoid Meson so far and all other build systems I've worked with, have one or
more options to set variables. Either by having an option in the build files or
by passing some option into the configure step.)

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

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

[Mesa-dev] [Bug 101405] x.org/wiki/GalliumStatus/: Add description for DEPRECATED

[bugzilla-daemon]

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

--- Comment #3 from Adam Jackson  ---
(In reply to David Hedlund from comment #2)

> Thank you. Can you please add a disclaimer on
> https://www.x.org/wiki/GalliumStatus/ to make this clear?

Done:

https://cgit.freedesktop.org/wiki/xorg/commit/GalliumStatus.mdwn?id=bcddcce1e2e1e9325bdf7ac689ac8fe5d3000ab1

-- 
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] Bug introduced with Mesa 18.0.0: Star Trek Voyager Elite Force shadow glitches

[Roland Scheidegger]

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
nice if someone has time to look into it (but I won't have, while I try
to look into llvmpipe bugs that doesn't really extend to things which
are likely app issues).

Roland


> 
> 
> On 2018-09-18 16:55, Roland Scheidegger wrote:
>> I don't see any shadows at all with the 17.3.7 video?
>> Whereas the 18.0.0 one look quite bogus to me, but I think shadows are
>> known to be glitchy with id tech 3?
>> It should be possible to tweak shadows via cg_shadow (0-3),
>> r_stencilbits 8 might be necessary for some modes, r_dynamiclights 0
>> might also switch them off, if it works the same as with quake 3...
>>
>> Roland
>>
>>
>> Am 17.09.2018 um 18:55 schrieb Federico Dossena:
>>> Hi,
>>>
>>> I'm using Mesa (specifically Gallium on LLVMPipe) to run an old game
>>> called Star Trek Voyager Elite Force.
>>>
>>> I'd like to report a bug introduced with version 18.0.0 and still
>>> present in Mesa master that completely breaks the shadows in this game.
>>>
>>> I don't know how Mesa works internally so I'll just attach 2 videos:
>>>
>>>    * Mesa 17.3.7: shadows work normally:
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrive.google.com%2Fopen%3Fid%3D1UOD4NqEuL12FrZfvukkP5r83dyjTd3E2&data=02%7C01%7Csroland%40vmware.com%7Cd563fe86e19d4f85b39e08d61d78cd05%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636728802018203011&sdata=yx1Mp4lq25L3q8XEsTj6uV%2FtmIN6htN3p2t5%2Fk6HY1g%3D&reserved=0
>>>
>>> 
>>> 
>>>
>>>    * Mesa 18.0.0 and newer: shadows are broken:
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrive.google.com%2Fopen%3Fid%3D10cYYciVfLD3fCHpoOrp4cRTGj_GTuh2j&data=02%7C01%7Csroland%40vmware.com%7Cd563fe86e19d4f85b39e08d61d78cd05%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636728802018203011&sdata=huKMBD1eSk0qEHGyaDIdFWNIyuMUMTb097HhFKg4%2FWY%3D&reserved=0
>>>
>>> 
>>> 
>>>
>>>
>>> The game uses the id3 engine so I assume other games are also affected,
>>> although I haven't tested it.
>>>
>>> For what it's worth, the proprietary AMD drivers have the same bug.
>>>
>>> If you need the game for testing, please let me know.
>>> A demo is also available here:
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fileplanet.com%2F46986%2F4%2Ffileinfo%2FStar-Trek%3A-Voyager---Elite-Force-Demo&data=02%7C01%7Csroland%40vmware.com%7Cd563fe86e19d4f85b39e08d61d78cd05%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636728802018203011&sdata=uxya7NzNzuNCmQaz3g%2BY798FPON9H4nkmG9G7NvTm0w%3D&reserved=0
>>>
>>> 
>>>
>>>
>>>
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Csrol

Re: [Mesa-dev] Lets talk about autotools

[Dylan Baker]

Quoting Brian Paul (2018-09-17 20:02:21)
> Hi Dylan,
> 
> I have my 32-bit cross-compile working, but "ninja -C builddir install" 
> isn't putting the 32-bit libs and drivers in the right place.
> 
> I've been playing with the meson --prefix option and the 
> -Ddri-drivers-path=foo option but haven't found the right incantation.
> 
> On Ubuntu, I want the libs and drivers to wind up in 
> /usr/lib/i386-linux-gnu/
> 
> Any tips?
> 
> -Brian

As Marek said, you probably want to set -Dlibdir=i386-linux-gnu, if any of these
paths are relative they're assumed to be relative to your prefix.

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 Kai Wasserbäch (2018-09-18 07:43:08)
> Hey,
> Dylan Baker wrote on 9/17/18 6:44 PM:
> > 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.
> 
> How do I set a specific llvm-config name to look for? I have build 
> environments
> with multiple LLVM versions (eg. 6, 7 and 8) installed in parallel. So far I
> could convince each build system with LLVM_CONFIG or similar means to choose a
> particular llvm-config-${LLVM_VERSION], meson can't do that AFAICT.
> 
> Eric pointed me to an ugly hack on IRC, which involves symlinking the 
> particular
> llvm-config-${VERSION} to llvm-config in $PATH
> ().
> But I think this should be fixed properly before making meson mandatory. Other
> modern build systems like CMake react to something like -DLLVM_DIR during
> configure (see
> ) and Mesa's
> stable build systems use LLVM_CONFIG, if set.
> 
> Cheers,
> Kai

This is something we've discussed upstream several times. I will freely admit
that llvm-config is a huge pain in the ass to deal with for a ton of reasons,
and since we don't use it at Intel it hasn't been on the top of my list of
things to do, and also because the solution upstream wants is very non-trival to
implement. This has come up already and I am working on it right now.

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.

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? I'd also encourage writing a new "configure" script which
> echo's instructions on how to operate meson -- it's really not
> obvious, with alternating --prefix=bla -Dfoo=bla argument styles.
> People know how to use autotools, but meson is a fairly new thing.
> 
> Cheers,
> 
>   -ilia

I got a patch into (I think) 0.46 that allows the use -D for all options, all
the time. Now you can say `meson build -Dprefix=blah -Dfoo=blah` and it will
work. I think there's some work to refactor the way that argument processing is
handled so that that -- and -D are interchangeable.

Dylan


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

[Mesa-dev] [PATCH] gallium/util: Clarify comment in util_init_thread_pinning

[Michel Dänzer]

From: Michel Dänzer 

As discussed in the review of the patch which added the comment:

Nothing happens when a thread is created, because pthread_atfork doesn't
affect creating threads. However, spawning a child process will likely
crash.

Signed-off-by: Michel Dänzer 
---
 src/gallium/auxiliary/util/u_helpers.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/util/u_helpers.c 
b/src/gallium/auxiliary/util/u_helpers.c
index b6cebf96329..4c70c004178 100644
--- a/src/gallium/auxiliary/util/u_helpers.c
+++ b/src/gallium/auxiliary/util/u_helpers.c
@@ -148,7 +148,10 @@ util_init_thread_pinning(void)
/* Reset thread affinity for all child processes to prevent them from
 * inheriting the current thread's affinity.
 *
-* What happens if a driver is unloaded and the app creates a thread?
+* XXX: If the driver is unloaded after this, and the app later calls
+* fork(), the child process will likely crash before fork() returns,
+* because the address where util_set_full_cpu_affinity was located
+* will either be unmapped or point to random other contents.
 */
pthread_atfork(NULL, NULL, util_set_full_cpu_affinity);
 }
-- 
2.19.0

___
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 Kenneth Graunke (2018-09-18 01:40:48)
> On Monday, September 17, 2018 3:24:56 PM PDT Dylan Baker wrote:
> > Quoting Marek Olšá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.

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] radv: fix descriptor pool allocation size

[Gustaw Smolarczyk]

pt., 14 wrz 2018 o 15:00 Bas Nieuwenhuizen  
napisał(a):
>
> Reviewed-by: Bas Nieuwenhuizen 
> On Fri, Sep 14, 2018 at 2:55 PM Samuel Pitoiset
>  wrote:
> >
> > The size has to be multiplied by the number of sets.
> >
> > This gets rid of the OUT_OF_POOL_KHR error and fixes
> > the Tangrams demo.
> >
> > CC: 18.1 18.2 
> > Signed-off-by: Samuel Pitoiset 
> > ---
> >  src/amd/vulkan/radv_descriptor_set.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/amd/vulkan/radv_descriptor_set.c 
> > b/src/amd/vulkan/radv_descriptor_set.c
> > index c4341f6ac5..49d0811bb0 100644
> > --- a/src/amd/vulkan/radv_descriptor_set.c
> > +++ b/src/amd/vulkan/radv_descriptor_set.c
> > @@ -569,9 +569,10 @@ VkResult radv_CreateDescriptorPool(
> > }
> >
> > if (!(pCreateInfo->flags & 
> > VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT)) {
> > -   uint64_t host_size = pCreateInfo->maxSets * sizeof(struct 
> > radv_descriptor_set);
> > +   uint64_t host_size = sizeof(struct radv_descriptor_set);
> > host_size += sizeof(struct radeon_winsys_bo*) * bo_count;
> > host_size += sizeof(struct radv_descriptor_range) * 
> > range_count;
> > +   host_size *= pCreateInfo->maxSets;
> > size += host_size;
> > } else {
> > size += sizeof(struct radv_descriptor_pool_entry) * 
> > pCreateInfo->maxSets;
> > --
> > 2.19.0
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

I don't think this change is correct.

From the vkAllocateDescriptorSets documentation [1]:


If a call to vkAllocateDescriptorSets would cause the total number of
descriptor sets allocated from the pool to exceed the value of
VkDescriptorPoolCreateInfo::maxSets used to create
pAllocateInfo→descriptorPool, then the allocation may fail due to lack
of space in the descriptor pool. Similarly, the allocation may fail
due to lack of space if the call to vkAllocateDescriptorSets would
cause the number of any given descriptor type to exceed the sum of all
the descriptorCount members of each element of
VkDescriptorPoolCreateInfo::pPoolSizes with a member equal to that
type.


What it implies (I think), is that VkDescriptorPoolCreateInfo::maxSets
and descriptorCount of each VkDescriptorPoolCreateInfo::pPoolSizes are
treated separately. I don't think you should multiply one by another.
Each pool should be able to allocate at least maxSets sets and
descriptorCount descriptors.

Please, correct me if I'm wrong.

Regards,

Gustaw Smolarczyk

[1] 
https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkAllocateDescriptorSets.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] mesa: rotation of 0-vector

[Sergii Romantsov]

>
> Isn't x guaranteed to be 0.0F here?

Yes, it will 0.0f but its not used in any computation anywhere. So new
'else'-block should be treated as (1,0,0) on input - its optimized
computation of rotation only by x.

On Tue, Sep 18, 2018 at 5:56 PM, Gustaw Smolarczyk 
wrote:

> wt., 18 wrz 2018 o 15:59 Sergii Romantsov 
> napisał(a):
> >
> > Specification doesn't define behaviour for rotation of 0-vector.
> > Windows and Nvidia drivers have a workaround for that.
> > For compatibility proposed that for 0-vector a rotation will be
> > done around x-axis.
> >
> > -v2: logic moved to _math_matrix_rotate
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100960
> > Signed-off-by: Sergii Romantsov 
> > ---
> >  src/mesa/math/m_matrix.c | 19 +++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
> > index 57a4953..2b3adb3 100644
> > --- a/src/mesa/math/m_matrix.c
> > +++ b/src/mesa/math/m_matrix.c
> > @@ -824,6 +824,25 @@ _math_matrix_rotate( GLmatrix *mat,
> > M(1,0) = s;
> >  }
> >   }
> > + else {
> > +/* https://bugs.freedesktop.org/show_bug.cgi?id=100960
> > + * https://github.com/KhronosGroup/OpenGL-API/issues/41
> > + * So that is kind of workaround for empty-vectors to have
> > + * compatibility with Windows and Nvidia drivers.
> > + */
> > +optimized = GL_TRUE;
> > +/* rotate only around x-axis */
> > +M(1,1) = c;
> > +M(2,2) = c;
> > +if (x < 0.0F) {
>
> Isn't x guaranteed to be 0.0F here? And I think you wanted to treat it
> as 1.0F in that case, so that (0, 0, 0) becomes (1, 0, 0).
>
> Regards,
> Gustaw Smolarczyk
>
> > +   M(1,2) = s;
> > +   M(2,1) = -s;
> > +}
> > +else {
> > +   M(1,2) = -s;
> > +   M(2,1) = s;
> > +}
> > + }
> >}
> >else if (z == 0.0F) {
> >   optimized = GL_TRUE;
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev 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

Re: [Mesa-dev] Lets talk about autotools

[Chuck Atkins]

First, I'm fully in support of killing off autotools woo-hoo to that.  And
given the substantial investment already put into the meson build that
certainly seems like a good direction to go.

That being said, the way "auto" is currently implemented leaves quite a bit
to be desired.  One of the nice features of the Autotools build was how
auto-enabled options were treated in that the dependencies were searched
for and if they were all found and met then the option would be enabled.
My experience so far with the meson build has shown this not to be the case
and a "configure" with no options has yet to be successful for me.  Many of
the 'auto' options are treated as 'set to true if your platform supports
it' regardless of whether your system has the requisite dependencies
available.  For example"

   - The 'gallium-va' option defaults to 'auto' but the implementation ends
   up setting the '_va' option to true if the other option conditions are met,
   long before libva is searched for.  So then when libva isn't found one gets
   an error.
  - if set to auto then missing the libva dependencies should be a
  failure, it should just disable the gallium va state tracker
  - The platform options set to 'auto'  has a set of checks to
   determine which platforms are enabled as required.  If the
   system_has_kms_drm check is true then Wayland is enabled as required.
   Later if the check for wayland dependencies fails, an error occurs.
  - If platforms are set to auto then a failure to locate dependencies
  for a given platform should disable the platform.

I realize these are just two specific examples, each of which can be
readily dealt with in their own specific way so I'm not asking "how to I
address #1 and #2?" because I can certainly do that.  These are just two
instances of many though in the way "auto" is dealt with.  My point is
really a broader one that before meson becomes the primary build then the
behavior of "auto" should create a successful configure out of the box
without additional options.

--
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.


On Tue, Sep 18, 2018 at 9:04 AM Eric Engestrom 
wrote:

> On Monday, 2018-09-17 17:25:36 -0400, Marek Olšák wrote:
> > Where do I find default values for meson configure options?
>
> If you mean the project's options, they're in meson_options.txt;
> currently not printed in the output of `meson configure` though.
>
> If you mean Meson's own options (like `buildtype`), I don't think that
> information exists anywhere outside of Meson's source code (and it's
> affected by meson.build too).
>
> It might be worth opening an issue upstream to ask for and track the
> progress of this feature if you want it :)
>
> >
> > 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 v2] mesa: rotation of 0-vector

[Gustaw Smolarczyk]

wt., 18 wrz 2018 o 15:59 Sergii Romantsov 
napisał(a):
>
> Specification doesn't define behaviour for rotation of 0-vector.
> Windows and Nvidia drivers have a workaround for that.
> For compatibility proposed that for 0-vector a rotation will be
> done around x-axis.
>
> -v2: logic moved to _math_matrix_rotate
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100960
> Signed-off-by: Sergii Romantsov 
> ---
>  src/mesa/math/m_matrix.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
> index 57a4953..2b3adb3 100644
> --- a/src/mesa/math/m_matrix.c
> +++ b/src/mesa/math/m_matrix.c
> @@ -824,6 +824,25 @@ _math_matrix_rotate( GLmatrix *mat,
> M(1,0) = s;
>  }
>   }
> + else {
> +/* https://bugs.freedesktop.org/show_bug.cgi?id=100960
> + * https://github.com/KhronosGroup/OpenGL-API/issues/41
> + * So that is kind of workaround for empty-vectors to have
> + * compatibility with Windows and Nvidia drivers.
> + */
> +optimized = GL_TRUE;
> +/* rotate only around x-axis */
> +M(1,1) = c;
> +M(2,2) = c;
> +if (x < 0.0F) {

Isn't x guaranteed to be 0.0F here? And I think you wanted to treat it
as 1.0F in that case, so that (0, 0, 0) becomes (1, 0, 0).

Regards,
Gustaw Smolarczyk

> +   M(1,2) = s;
> +   M(2,1) = -s;
> +}
> +else {
> +   M(1,2) = -s;
> +   M(2,1) = s;
> +}
> + }
>}
>else if (z == 0.0F) {
>   optimized = GL_TRUE;
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev 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]

I don't see any shadows at all with the 17.3.7 video?
Whereas the 18.0.0 one look quite bogus to me, but I think shadows are
known to be glitchy with id tech 3?
It should be possible to tweak shadows via cg_shadow (0-3),
r_stencilbits 8 might be necessary for some modes, r_dynamiclights 0
might also switch them off, if it works the same as with quake 3...

Roland


Am 17.09.2018 um 18:55 schrieb Federico Dossena:
> Hi,
> 
> I'm using Mesa (specifically Gallium on LLVMPipe) to run an old game
> called Star Trek Voyager Elite Force.
> 
> I'd like to report a bug introduced with version 18.0.0 and still
> present in Mesa master that completely breaks the shadows in this game.
> 
> I don't know how Mesa works internally so I'll just attach 2 videos:
> 
>   * Mesa 17.3.7: shadows work normally:
> https://drive.google.com/open?id=1UOD4NqEuL12FrZfvukkP5r83dyjTd3E2
> 
> 
>   * Mesa 18.0.0 and newer: shadows are broken:
> https://drive.google.com/open?id=10cYYciVfLD3fCHpoOrp4cRTGj_GTuh2j
> 
> 
> 
> The game uses the id3 engine so I assume other games are also affected,
> although I haven't tested it.
> 
> For what it's worth, the proprietary AMD drivers have the same bug.
> 
> If you need the game for testing, please let me know.
> A demo is also available here:
> https://www.fileplanet.com/46986/4/fileinfo/Star-Trek:-Voyager---Elite-Force-Demo
> 
> 
> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Csroland%40vmware.com%7C626d7d56b64147bd7efb08d61d4d7367%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636728615875582416&sdata=EG%2F9jjkx%2BSP%2B3duzpdTyPqQ%2BNABlOb5qBPDCJHaa520%3D&reserved=0
> 

___
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 Baker wrote on 9/17/18 6:44 PM:
> 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.

How do I set a specific llvm-config name to look for? I have build environments
with multiple LLVM versions (eg. 6, 7 and 8) installed in parallel. So far I
could convince each build system with LLVM_CONFIG or similar means to choose a
particular llvm-config-${LLVM_VERSION], meson can't do that AFAICT.

Eric pointed me to an ugly hack on IRC, which involves symlinking the particular
llvm-config-${VERSION} to llvm-config in $PATH
().
But I think this should be fixed properly before making meson mandatory. Other
modern build systems like CMake react to something like -DLLVM_DIR during
configure (see
) and Mesa's
stable build systems use LLVM_CONFIG, if set.

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

[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

Samuel Pitoiset  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #14 from Samuel Pitoiset  ---
Yeah, dolphin allocates too much memory. Anyway we should use a 64-bit unsigned
integer. Closing.

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

[Mesa-dev] [PATCH] radv: use a 64-bit unsigned integer when allocating a descriptor pool

[Samuel Pitoiset]

pool->size is a 64-bit unsigned integer too.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_descriptor_set.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_descriptor_set.c 
b/src/amd/vulkan/radv_descriptor_set.c
index 49d0811bb0..143881fb6e 100644
--- a/src/amd/vulkan/radv_descriptor_set.c
+++ b/src/amd/vulkan/radv_descriptor_set.c
@@ -533,7 +533,7 @@ VkResult radv_CreateDescriptorPool(
 {
RADV_FROM_HANDLE(radv_device, device, _device);
struct radv_descriptor_pool *pool;
-   int size = sizeof(struct radv_descriptor_pool);
+   uint64_t size = sizeof(struct radv_descriptor_pool);
uint64_t bo_size = 0, bo_count = 0, range_count = 0;
 
 
-- 
2.19.0

___
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 #13 from kyle.de...@mykolab.com ---
Your patch doesn't help, unfortunately.

Probably best if I report this bug to dolphin-emu, then.

-- 
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 v2] mesa: rotation of 0-vector

[Sergii Romantsov]

Uploaded new version.
Seems that waiting for any response on
https://github.com/KhronosGroup/OpenGL-API/issues/41 may take much more
time

On Tue, Sep 18, 2018 at 4:57 PM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:

> Specification doesn't define behaviour for rotation of 0-vector.
> Windows and Nvidia drivers have a workaround for that.
> For compatibility proposed that for 0-vector a rotation will be
> done around x-axis.
>
> -v2: logic moved to _math_matrix_rotate
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100960
> Signed-off-by: Sergii Romantsov 
> ---
>  src/mesa/math/m_matrix.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
> index 57a4953..2b3adb3 100644
> --- a/src/mesa/math/m_matrix.c
> +++ b/src/mesa/math/m_matrix.c
> @@ -824,6 +824,25 @@ _math_matrix_rotate( GLmatrix *mat,
> M(1,0) = s;
>  }
>   }
> + else {
> +/* https://bugs.freedesktop.org/show_bug.cgi?id=100960
> + * https://github.com/KhronosGroup/OpenGL-API/issues/41
> + * So that is kind of workaround for empty-vectors to have
> + * compatibility with Windows and Nvidia drivers.
> + */
> +optimized = GL_TRUE;
> +/* rotate only around x-axis */
> +M(1,1) = c;
> +M(2,2) = c;
> +if (x < 0.0F) {
> +   M(1,2) = s;
> +   M(2,1) = -s;
> +}
> +else {
> +   M(1,2) = -s;
> +   M(2,1) = s;
> +}
> + }
>}
>else if (z == 0.0F) {
>   optimized = GL_TRUE;
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



-- 
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 v2] mesa: rotation of 0-vector

[Sergii Romantsov]

Specification doesn't define behaviour for rotation of 0-vector.
Windows and Nvidia drivers have a workaround for that.
For compatibility proposed that for 0-vector a rotation will be
done around x-axis.

-v2: logic moved to _math_matrix_rotate

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100960
Signed-off-by: Sergii Romantsov 
---
 src/mesa/math/m_matrix.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
index 57a4953..2b3adb3 100644
--- a/src/mesa/math/m_matrix.c
+++ b/src/mesa/math/m_matrix.c
@@ -824,6 +824,25 @@ _math_matrix_rotate( GLmatrix *mat,
M(1,0) = s;
 }
  }
+ else {
+/* https://bugs.freedesktop.org/show_bug.cgi?id=100960
+ * https://github.com/KhronosGroup/OpenGL-API/issues/41
+ * So that is kind of workaround for empty-vectors to have
+ * compatibility with Windows and Nvidia drivers.
+ */
+optimized = GL_TRUE;
+/* rotate only around x-axis */
+M(1,1) = c;
+M(2,2) = c;
+if (x < 0.0F) {
+   M(1,2) = s;
+   M(2,1) = -s;
+}
+else {
+   M(1,2) = -s;
+   M(2,1) = s;
+}
+ }
   }
   else if (z == 0.0F) {
  optimized = GL_TRUE;
-- 
2.7.4

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

[Mesa-dev] [Bug 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 #12 from Samuel Pitoiset  ---
Created attachment 141640
  --> https://bugs.freedesktop.org/attachment.cgi?id=141640&action=edit
possible fix

Well, dolphin tries to allocate a TON of memory for one descriptor pool. It
allocates 16262320 bytes for one set... And they are 10. That explains the
OOM error.

The attached patch might help but this should be reported to the Dolphin guys
because it's definitely too bad.

Let me know if that helps.

-- 
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 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 #11 from kyle.de...@mykolab.com ---
I ran dolphin-emu, and decided to log any errors (why didn't I think of this
previously...):

43:00:797 VideoBackends/Vulkan/VulkanLoader.cpp:314 E[Video]:
(CreateCommandBuffers) vkCreateDescriptorPool failed:  (-1:
VK_ERROR_OUT_OF_HOST_MEMORY)
43:00:797 Common/MsgHandler.cpp:92 E[MASTER]: Warning: Failed to create Vulkan
command buffers

-- 
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 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 #10 from kyle.de...@mykolab.com ---
Is this potentially a dolphin-emu bug, then?

-- 
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 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 #9 from kyle.de...@mykolab.com ---
No change... :/

-- 
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 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 #8 from Gustaw Smolarczyk  ---
Hi, I am just passing by.

I have found the following piece of code in Dolphin source code [1]:

VkDescriptorPoolCreateInfo pool_create_info =
{VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_CREATE_INFO,
   nullptr,
   0,
   10,  // tweak this
  
static_cast(ArraySize(pool_sizes)),
   pool_sizes};


maxSets is being set to 10, which might be the source of this problem. I
like the comment next to it :)

[1]
https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoBackends/Vulkan/CommandBufferManager.cpp#L97

-- 
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 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 #7 from Samuel Pitoiset  ---
Created attachment 141639
  --> https://bugs.freedesktop.org/attachment.cgi?id=141639&action=edit
test

Please try this patch. Does it abort?

-- 
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 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 #6 from kyle.de...@mykolab.com ---
Backtrace: https://paste.kde.org/pnt3dlvpx

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

[Brian Paul]

On 09/17/2018 10:32 PM, Mathias Fröhlich wrote:
> Good Morning,
> 
> On Tuesday, 18 September 2018 05:10:04 CEST Brian Paul wrote:
>> The function pointer declarations in dd.h for the BufferData() and
>> BufferSubData() use the ARB-suffixed datatypes.  This patch changes
>> the buffer_data_fallback() and buffer_sub_data_fallback() functions
>> to use those datatypes too.
>>
>> This fixes a build warning when building 32-bit libraries.  Evidently,
>> GLsizeiptrARB and GLsizeiptr are defined differently in that situation.
>>
>> All all implementations of these driver hooks use the ARB-suffixed
>> types.
> 
> Hmm, all of GL{int,sizei}ptr{,ARB} are typedefs to ptrdiff_t by gl.xml.

gl.xml doesn't seem relevant to this.  In GL/glext.h we have:

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.


> That makes me think that you may be running into some other problem
> for your build that you may want to know the reason for?
> 
> Anyhow, for mesa itself, it seems reasonable to assign functions with
> exactly the same argument signature to the appropriate driver function 
> pointers.
> 
> This one as well as the other two warning fixes:
> Reviewed-by: Mathias Fröhlich 

Thanks.

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

[Mesa-dev] [PATCH] radv: enable VK_SUBGROUP_FEATURE_ARITHMETIC_BIT

[Samuel Pitoiset]

All CTS pass on Polaris/Vega with LLVM 6, 7 and master, so
I think it's safe to enable the feature.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_device.c | 1 +
 src/amd/vulkan/radv_shader.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index f9169d9d01..7e46a57fb5 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1061,6 +1061,7 @@ void radv_GetPhysicalDeviceProperties2(
properties->subgroupSize = 64;
properties->supportedStages = VK_SHADER_STAGE_ALL;
properties->supportedOperations =
+   
VK_SUBGROUP_FEATURE_ARITHMETIC_BIT |

VK_SUBGROUP_FEATURE_BASIC_BIT |

VK_SUBGROUP_FEATURE_BALLOT_BIT |

VK_SUBGROUP_FEATURE_QUAD_BIT |
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index c59b783f4a..9c038a5570 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -212,6 +212,7 @@ radv_shader_compile_to_nir(struct radv_device *device,
.int64 = true,
.int16 = true,
.multiview = true,
+   .subgroup_arithmetic = true,
.subgroup_ballot = true,
.subgroup_basic = true,
.subgroup_quad = true,
-- 
2.19.0

___
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 #5 from Samuel Pitoiset  ---
I meant what commit. Are you sure it's 90819abb56f6b1a0cd4946b13b6caf24fb46e500
? That seems quite weird.

Yes, please attach a backtrace.

-- 
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 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 #4 from kyle.de...@mykolab.com ---
As soon as I click play for any of the games in dolphin-emu's game list, which
is when it starts the renderer.

I can provide a backtrace from dolphin-emu, if it helps any.

-- 
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 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 #3 from Samuel Pitoiset  ---
So, when does the problem start exactly?

-- 
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 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 #2 from kyle.de...@mykolab.com ---
> It is 6521d4a659b911bb86d979564de03665616a671e that cause problems with 
> dolphin-emu initializing Vulkan in the first place.

Actually, no, ignore this...

-- 
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 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 #1 from kyle.de...@mykolab.com ---
Actually, 90819abb56f6b1a0cd4946b13b6caf24fb46e500 ~ `radv: fix descriptor pool
allocation size` is where the fun starts.

It crashes dolphin-emu with "Failed to create Vulkan command buffers"

It is 6521d4a659b911bb86d979564de03665616a671e that cause problems with
dolphin-emu initializing Vulkan in the first place.

-- 
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 107977] Commit 90819abb56f6b1a0cd4946b13b6caf24fb46e500 crashes dolphin-emu with "Failed to create Vulkan command buffers"

[bugzilla-daemon]

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

kyle.de...@mykolab.com changed:

   What|Removed |Added

Summary|Commit  |Commit
   |6521d4a659b911bb86d979564de |90819abb56f6b1a0cd4946b13b6
   |03665616a671e breaks|caf24fb46e500 crashes
   |dolphin-emu Vulkan  |dolphin-emu with "Failed to
   |initialization on at least  |create Vulkan command
   |RX580   |buffers"

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

[Mesa-dev] [PATCH] radv: do not support blitting surfaces with depth and stencil

[Samuel Pitoiset]

Fixes:
dEQP-VK.api.copy_and_blit.core.blit_image.all_formats.depth_stencil.d32_sfloat_s8_uint_d32_sfloat_s8_uint.optimal_optimal_nearest

And all friends that try to blit a surface with different
depth and stencil formats.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_formats.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
index e1b4b5e830..ad06c9e996 100644
--- a/src/amd/vulkan/radv_formats.c
+++ b/src/amd/vulkan/radv_formats.c
@@ -645,6 +645,10 @@ radv_physical_device_get_format_properties(struct 
radv_physical_device *physical
if (radv_is_filter_minmax_format_supported(format))
 tiled |= 
VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT;
 
+   /* Don't support blitting surfaces with depth/stencil. 
*/
+   if (vk_format_is_depth(format) && 
vk_format_is_stencil(format))
+   tiled &= ~VK_FORMAT_FEATURE_BLIT_DST_BIT;
+
/* Don't support linear depth surfaces */
linear = 0;
}
-- 
2.19.0

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

Re: [Mesa-dev] Lets talk about autotools

[Eric Engestrom]

On Monday, 2018-09-17 17:25:36 -0400, Marek Olšák wrote:
> Where do I find default values for meson configure options?

If you mean the project's options, they're in meson_options.txt;
currently not printed in the output of `meson configure` though.

If you mean Meson's own options (like `buildtype`), I don't think that
information exists anywhere outside of Meson's source code (and it's
affected by meson.build too).

It might be worth opening an issue upstream to ask for and track the
progress of this feature if you want it :)

> 
> 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] [Bug 107977] Commit 6521d4a659b911bb86d979564de03665616a671e breaks dolphin-emu Vulkan initialization on at least RX580

[bugzilla-daemon]

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

kyle.de...@mykolab.com changed:

   What|Removed |Added

Summary|Commit `Revert "radv:   |Commit
   |Optimize rebinding the same |6521d4a659b911bb86d979564de
   |descriptor set."` breaks|03665616a671e breaks
   |dolphin-emu Vulkan  |dolphin-emu Vulkan
   |initialization on at least  |initialization on at least
   |RX580   |RX580

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