[Mesa-dev] [Bug 37397] Expose more ES extensions that are identical to existing desktop GL functionality

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #1 from Timothy Arceri  ---
I think at this stage we have enabled most extensions people care about. I
doubt anyone has looked at this bug in years so closing.

-- 
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 102057] Enabling DSA in COMPATIBILITY PROFILE

[bugzilla-daemon]

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

--- Comment #1 from Timothy Arceri  ---
(In reply to Mika from comment #0)
> Created attachment 133265 [details] [review]
> DSA in compatibility profile
> 
> Hi,
> 
> My request is about GL_ARB_direct_state_access, I would like to know, if it
> could be enabled in compatibility profile. 
> 
> 
> I must admit, that I do not own a lot of application to test against, but
> ATM I did not spot anything fishy.
> 
> This allow Cemu ( http://cemu.info ) to work ontop of wine.
> 
> This could be linked to a driconf options or to the already existing "Allow
> a higher compat profile (version 3.1+) for apps that request it"
> 
>  GL_ARB_direct_state_access is supported by all drivers.
> 
> Thank you !

Thanks but patches should be created with git and sent to the mesa-dev mailing
list.

-- 
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 72572] no error on draw call without vbo set

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Timothy Arceri  ---
Is this still an issue can you provide a piglit test or example app?

-- 
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 44558] Consolidate / cleanup env variables

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #1 from Timothy Arceri  ---
Most of these are designed to be used by devs only. Also many are driver
specific putting them in a single file doesn't really make sense.

-- 
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 102992] Fedora see two monitors as one.

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #1 from Timothy Arceri  ---
Probably better to report this to Fedora or X devs.

-- 
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 99730] Metro Redux game(s) needs override for midshader extension declaration

[bugzilla-daemon]

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

--- Comment #4 from Timothy Arceri  ---
Is this still a problem? If so can you rebase the patch and send it to the
list?

-- 
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 54370] Autoconf mistakenly reports missing packages in Debian 64

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

-- 
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 79039] [TRACKER] Mesa 10.2 release tracker

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=79039
Bug 79039 depends on bug 77288, which changed state.

Bug 77288 Summary: [swrast] piglit glean glsl1 regression
https://bugs.freedesktop.org/show_bug.cgi?id=77288

   What|Removed |Added

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

-- 
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 77288] [swrast] piglit glean glsl1 regression

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #9 from Timothy Arceri  ---
All glean tests have been rewritten and removed from piglit, and since nobody
really cares enough to fix swrast anyway I'm closing this bug.

-- 
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 98281] 'message's in ctx->Debug.LogMessages[] seem to leak.

[bugzilla-daemon]

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

--- Comment #9 from Timothy Arceri  ---
Thanks for the bug report and sorry for delay in fixing.

Fix sent to list: https://patchwork.freedesktop.org/patch/216870/

-- 
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] getteximage: assume texture image is empty for non defined levels

[Iago Toral]

On Thu, 2018-04-12 at 17:59 +0200, Juan A. Suarez Romero wrote:
> Current code is returning an INVALID_OPERATION when trying to use
> getTextureImage() on a level that has not been explicitly defined.
> 
> That is, we define a mipmapped Texture2D with 3 levels, and try to
> use
> GetTextureImage() for the 4th levels, and INVALID_OPERATION is
> returned.
> 
> Nevertheless, such case is not listed as an error in OpenGL 4.6 spec,
> section 8.11.4 ("Texture Image Queries"), where all the case errors
> for
> this function are defined. So it seems this is a valid operation.
> 
> On the other hand, in section 8.22 ("Texture State and Proxy State")
> it
> states:
> 
>   "Each initial texture image is null. It has zero width, height, and
>depth, internal format RGBA, or R8 for buffer textures, component
>sizes set to zero and component types set to NONE, the compressed
>flag set to FALSE, a zero compressed size, and the bound buffer
>object name is zero."
> 
> We can assume that we are reading this initialized empty image when
> calling GetTextureImage() with a non defined level.
> 
> With this assumption, we will reach one of the other error cases
> defined
> for the functions. At the end, this means that we will return a
> different error to the caller.

I would chancge the last sentence to:

"In the end this means that we would end up returning INVALID_VALUE to
the caller"

> 
> This fixes arb_get_texture_sub_image piglit tests.
> 
> v2: just return INVALID_VALUE if there isno defined level (Iago)
   ^
  white space

Reviewed-by: Iago Toral Quiroga 

> 
> Signed-off-by: Juan A. Suarez Romero 
> ---
>  src/mesa/main/texgetimage.c | 27 +--
>  1 file changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/main/texgetimage.c
> b/src/mesa/main/texgetimage.c
> index 85d0ffd4770..69521c5dd05 100644
> --- a/src/mesa/main/texgetimage.c
> +++ b/src/mesa/main/texgetimage.c
> @@ -1004,8 +1004,31 @@ dimensions_error_check(struct gl_context *ctx,
>  
> texImage = select_tex_image(texObj, target, level, zoffset);
> if (!texImage) {
> -  /* missing texture image */
> -  _mesa_error(ctx, GL_INVALID_OPERATION, "%s(missing image)",
> caller);
> +  /* Trying to return a non-defined level is a valid operation
> per se, as
> +   * OpenGL 4.6 spec, section 8.11.4 ("Texture Image Queries")
> does not
> +   * handle this case as an error.
> +   *
> +   * Rather, we need to look at section 8.22 ("Texture State and
> Proxy
> +   * State"):
> +   *
> +   *   "Each initial texture image is null. It has zero width,
> height, and
> +   *depth, internal format RGBA, or R8 for buffer textures,
> component
> +   *sizes set to zero and component types set to NONE, the
> compressed
> +   *flag set to FALSE, a zero compressed size, and the bound
> buffer
> +   *object name is zero."
> +   *
> +   * This means we need to assume the image for the non-defined
> level is
> +   * an empty image. With this assumption, we can go back to
> section
> +   * 8.11.4 and checking again the errors:
> +   *
> +   *   "An INVALID_VALUE error is generated if xoffset + width
> is greater
> +   *than the texture’s width, yoffset + height is greater
> than the
> +   *texture’s height, or zoffset + depth is greater than the
> texture’s
> +   *depth."
> +   *
> +   * Thus why we return INVALID_VALUE.
> +   */
> +  _mesa_error(ctx, GL_INVALID_VALUE, "%s(missing image)",
> caller);
>return true;
> }
>  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] i965/fs: implement conversions from float16 to 64 bits data types

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/compiler/brw_fs_nir.cpp | 32 
 1 file changed, 32 insertions(+)

diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index 822a1ac4227..2c007a2a5a7 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -760,6 +760,38 @@ fs_visitor::nir_emit_alu(const fs_builder &bld, 
nir_alu_instr *instr)
case nir_op_f2f64:
case nir_op_f2i64:
case nir_op_f2u64:
+  /* BDW PRM, vol02, Command Reference Instructions, mov - MOVE:
+   *
+   *   "There is no direct conversion from HF to DF or DF to HF.
+   *Use two instructions and F (Float) as an intermediate type.
+   *
+   *There is no direct conversion from HF to Q/UQ or Q/UQ to HF.
+   *Use two instructions and F (Float) or a word integer type
+   *or a DWord integer type as an intermediate type."
+   */
+  if (nir_src_bit_size(instr->src[0].src) == 16) {
+ brw_reg_type type;
+ switch (instr->op) {
+ case nir_op_f2f64:
+type = BRW_REGISTER_TYPE_F;
+break;
+ case nir_op_f2i64:
+type = BRW_REGISTER_TYPE_D;
+break;
+ case nir_op_f2u64:
+type = BRW_REGISTER_TYPE_UD;
+break;
+ default:
+unreachable("Not supported");
+ }
+ fs_reg tmp = bld.vgrf(type, 1);
+ inst = bld.MOV(tmp, op[0]);
+ inst->saturate = instr->dest.saturate;
+ inst = bld.MOV(result, tmp);
+ inst->saturate = instr->dest.saturate;
+ break;
+  }
+  /* fallthrough */
case nir_op_i2f64:
case nir_op_i2i64:
case nir_op_u2f64:
-- 
2.14.1

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

[Mesa-dev] [PATCH] mesa: free debug messages when destroying the debug state

[Timothy Arceri]

Fixes: 04a8baad3721 "mesa: refactor _mesa_PopDebugGroup and 
_mesa_free_errors_data"

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98281
---
 src/mesa/main/debug_output.c | 45 ++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/src/mesa/main/debug_output.c b/src/mesa/main/debug_output.c
index 859e1f966d2..306ca98fe4f 100644
--- a/src/mesa/main/debug_output.c
+++ b/src/mesa/main/debug_output.c
@@ -501,6 +501,28 @@ debug_clear_group(struct gl_debug_state *debug)
debug->Groups[gstack] = NULL;
 }
 
+/**
+ * Delete the oldest debug messages out of the log.
+ */
+static void
+debug_delete_messages(struct gl_debug_state *debug, int count)
+{
+   struct gl_debug_log *log = &debug->Log;
+
+   if (count > log->NumMessages)
+  count = log->NumMessages;
+
+   while (count--) {
+  struct gl_debug_message *msg = &log->Messages[log->NextMessage];
+
+  debug_message_clear(msg);
+
+  log->NumMessages--;
+  log->NextMessage++;
+  log->NextMessage %= MAX_DEBUG_LOGGED_MESSAGES;
+   }
+}
+
 /**
  * Loop through debug group stack tearing down states for
  * filtering debug messages.  Then free debug output state.
@@ -514,6 +536,7 @@ debug_destroy(struct gl_debug_state *debug)
}
 
debug_clear_group(debug);
+   debug_delete_messages(debug, debug->Log.NumMessages);
free(debug);
 }
 
@@ -648,28 +671,6 @@ debug_fetch_message(const struct gl_debug_state *debug)
return (log->NumMessages) ? &log->Messages[log->NextMessage] : NULL;
 }
 
-/**
- * Delete the oldest debug messages out of the log.
- */
-static void
-debug_delete_messages(struct gl_debug_state *debug, int count)
-{
-   struct gl_debug_log *log = &debug->Log;
-
-   if (count > log->NumMessages)
-  count = log->NumMessages;
-
-   while (count--) {
-  struct gl_debug_message *msg = &log->Messages[log->NextMessage];
-
-  debug_message_clear(msg);
-
-  log->NumMessages--;
-  log->NextMessage++;
-  log->NextMessage %= MAX_DEBUG_LOGGED_MESSAGES;
-   }
-}
-
 static struct gl_debug_message *
 debug_get_group_message(struct gl_debug_state *debug)
 {
-- 
2.17.0

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

[Mesa-dev] [PATCH 2/2] i965/fs: Implement float64 to float16 conversion

[Samuel Iglesias Gonsálvez]

It is not supported directly in the HW, we need to convert to float32
first as intermediate step.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/compiler/brw_fs_nir.cpp | 17 +
 1 file changed, 17 insertions(+)

diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index 2c007a2a5a7..a392eaacdf9 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -753,6 +753,23 @@ fs_visitor::nir_emit_alu(const fs_builder &bld, 
nir_alu_instr *instr)
*/
 
case nir_op_f2f16_undef:
+  /* BDW PRM, vol02, Command Reference Instructions, mov - MOVE:
+   *
+   *   "There is no direct conversion from HF to DF or DF to HF.
+   *Use two instructions and F (Float) as an intermediate type.
+   *
+   *There is no direct conversion from HF to Q/UQ or Q/UQ to HF.
+   *Use two instructions and F (Float) or a word integer type
+   *or a DWord integer type as an intermediate type."
+   */
+  if (nir_src_bit_size(instr->src[0].src) == 64) {
+ fs_reg tmp = bld.vgrf(BRW_REGISTER_TYPE_F, 1);
+ inst = bld.MOV(tmp, op[0]);
+ inst->saturate = instr->dest.saturate;
+ inst = bld.MOV(result, tmp);
+ inst->saturate = instr->dest.saturate;
+ break;
+  }
   inst = bld.MOV(result, op[0]);
   inst->saturate = instr->dest.saturate;
   break;
-- 
2.14.1

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

[Mesa-dev] [PATCH 0/2] i965: Add support for fp16 <-> fp64 conversions

[Samuel Iglesias Gonsálvez]

Hello,

This series implements support for doing fp16 <-> fp64 conversions on
i965. The PRM says we need to do an intermediate conversion to a 32 bit
type.

This patch series applies on top of shaderInt16's patch series [0].
There is a branch for testing on Github:

$ git clone https://github.com/Igalia/mesa.git \
  -b siglesias/vulkan-fp16-fp64-conversions

There are tests for Vulkan CTS under review (CL#2246) for testing these
patches.

Best regards,

Sam

[0] https://lists.freedesktop.org/archives/mesa-dev/2018-April/191888.html

Samuel Iglesias Gonsálvez (2):
  i965/fs: implement conversions from float16 to 64 bits data types
  i965/fs: Implement float64 to float16 conversion

 src/intel/compiler/brw_fs_nir.cpp | 49 +++
 1 file changed, 49 insertions(+)

-- 
2.14.1

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

[Mesa-dev] [PATCH] radv: mark const structs as extern in header file to avoid lto damage

[Dave Airlie]

From: Dave Airlie 

The copr repo from che was using LTO and he reported radv broke
recently with it. When testing with lto builds here I noticed
that we weren't seeing any instance extensions reported.

It appears LTO was treating the const without extern as an empty
struct, this is possibly a gcc bug, but we can work around it
just by marking these with extern.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_extensions.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index db37d617f9..ae9396c43a 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -199,9 +199,9 @@ struct radv_device_extension_table {
};
 };
 
-const VkExtensionProperties 
radv_instance_extensions[RADV_INSTANCE_EXTENSION_COUNT];
-const VkExtensionProperties 
radv_device_extensions[RADV_DEVICE_EXTENSION_COUNT];
-const struct radv_instance_extension_table radv_supported_instance_extensions;
+extern const VkExtensionProperties 
radv_instance_extensions[RADV_INSTANCE_EXTENSION_COUNT];
+extern const VkExtensionProperties 
radv_device_extensions[RADV_DEVICE_EXTENSION_COUNT];
+extern const struct radv_instance_extension_table 
radv_supported_instance_extensions;
 
 
 struct radv_physical_device;
-- 
2.14.3

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

[Mesa-dev] [PATCH] swr: Remove unnecessary memset call

[Vlad Golovkin]

Zeroing memory after calloc is not necessary. This also allows to avoid
possible crash when allocation fails, because memset is called before
checking screen for NULL.
---
 src/gallium/drivers/swr/swr_screen.cpp | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/gallium/drivers/swr/swr_screen.cpp 
b/src/gallium/drivers/swr/swr_screen.cpp
index 880a177c39..4e43ac55fb 100644
--- a/src/gallium/drivers/swr/swr_screen.cpp
+++ b/src/gallium/drivers/swr/swr_screen.cpp
@@ -1130,7 +1130,6 @@ struct pipe_screen *
 swr_create_screen_internal(struct sw_winsys *winsys)
 {
struct swr_screen *screen = CALLOC_STRUCT(swr_screen);
-   memset(screen, 0, sizeof(struct swr_screen));
 
if (!screen)
   return NULL;
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH 07/17] radeonsi: skip DCC render feedback checking if color writes are disabled

[Timothy Arceri]

On 13/04/18 10:45, Timothy Arceri wrote:

This change cause around 20+ piglit crashes on my Polaris.

e.g tests/spec/arb_compute_shader/execution/atomic-counter.shader_test

Thread 1 "shader_runner" received signal SIGSEGV, Segmentation fault.
0x71009ccc in si_get_total_colormask (sctx=0x64b140) at 
si_pipe.h:945

945    if (sctx->queued.named.rasterizer->rasterizer_discard)


It also seems to cause hundreds of test failures e.g

./bin/copyteximage CUBE -auto


Unfortunately it doesn't revert cleanly either.


Actually ignore this second problem I'm seeing a lot of intermittent 
test failures. These are being caused by something else, however the

crash above is caused by this commit.




On 04/04/18 11:59, Marek Olšák wrote:

From: Marek Olšák 

The previous patch is required for this.
---
  src/gallium/drivers/radeonsi/si_blit.c  |  5 +
  src/gallium/drivers/radeonsi/si_pipe.h  | 17 +
  src/gallium/drivers/radeonsi/si_state_shaders.c |  6 +-
  3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_blit.c 
b/src/gallium/drivers/radeonsi/si_blit.c

index 45770b0d9bf..8dd8bc2a4dd 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers/radeonsi/si_blit.c
@@ -706,20 +706,25 @@ static void 
si_check_render_feedback_resident_images(struct si_context *sctx)

  si_check_render_feedback_texture(sctx, tex,
   view->u.tex.level,
   view->u.tex.level,
   view->u.tex.first_layer,
   view->u.tex.last_layer);
  }
  }
  static void si_check_render_feedback(struct si_context *sctx)
  {
+    /* There is no render feedback if color writes are disabled.
+ * (e.g. a pixel shader with image stores)
+ */
+    if (!si_get_total_colormask(sctx))
+    return;
  if (!sctx->need_check_render_feedback)
  return;
  for (int i = 0; i < SI_NUM_SHADERS; ++i) {
  si_check_render_feedback_images(sctx, &sctx->images[i]);
  si_check_render_feedback_textures(sctx, &sctx->samplers[i]);
  }
  si_check_render_feedback_resident_images(sctx);
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h

index e3d45ef6c3b..e65c946d186 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -933,11 +933,28 @@ vi_tc_compat_htile_enabled(struct r600_texture 
*tex, unsigned level)

  }
  static inline unsigned si_get_ps_iter_samples(struct si_context *sctx)
  {
  if (sctx->ps_uses_fbfetch)
  return sctx->framebuffer.nr_samples;
  return sctx->ps_iter_samples;
  }
+static inline unsigned si_get_total_colormask(struct si_context *sctx)
+{
+    if (sctx->queued.named.rasterizer->rasterizer_discard)
+    return 0;
+
+    struct si_shader_selector *ps = sctx->ps_shader.cso;
+    unsigned colormask = sctx->framebuffer.colorbuf_enabled_4bit &
+ sctx->queued.named.blend->cb_target_mask;
+
+    if (!ps->info.properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS])
+    colormask &= ps->colors_written_4bit;
+    else if (!ps->colors_written_4bit)
+    colormask = 0; /* color0 writes all cbufs, but it's not 
written */

+
+    return colormask;
+}
+
  #endif
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c

index d7742eafb04..f2d29e40744 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1208,25 +1208,21 @@ static void 
si_shader_selector_key_hw_vs(struct si_context *sctx,

  bool ps_disabled = true;
  if (ps) {
  const struct si_state_blend *blend = sctx->queued.named.blend;
  bool alpha_to_coverage = blend && blend->alpha_to_coverage;
  bool ps_modifies_zs = ps->info.uses_kill ||
    ps->info.writes_z ||
    ps->info.writes_stencil ||
    ps->info.writes_samplemask ||
    alpha_to_coverage ||
    si_get_alpha_test_func(sctx) != PIPE_FUNC_ALWAYS;
-
-    unsigned ps_colormask = 
sctx->framebuffer.colorbuf_enabled_4bit &

-    sctx->queued.named.blend->cb_target_mask;
-    if 
(!ps->info.properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS])

-    ps_colormask &= ps->colors_written_4bit;
+    unsigned ps_colormask = si_get_total_colormask(sctx);
  ps_disabled = 
sctx->queued.named.rasterizer->rasterizer_discard ||

    (!ps_colormask &&
 !ps_modifies_zs &&
 !ps->info.writes_memory);
  }
  /* Find out which VS outputs aren't used by the PS. */
  uint64_t outputs_written = vs->outputs_written;
  uint64_t inputs_read = 0;


___
mesa-dev mailing list
mesa-dev@lists.fr

[Mesa-dev] [PATCH] virgl: add shader offset alignment to to v2 caps struct

[gurchetansi...@chromium.org]

This is the SSBO analogue to fe0647. User supplied data must
be a multiple of GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT.

This fixes 44 GLES31 tests on airlied@'s GLES31 sketch branches with
Nvidia hardware, but this patch standalone can applied to master. The
alignment restriction on Nvidia is 32, hence the default value.

Example tests:
   dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.0
   dEQP-GLES31.functional.ssbo.layout.multi_basic_types.single_buffer.std430

v2: Move to a better place in case statement
---
 src/gallium/drivers/virgl/virgl_hw.h | 1 +
 src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
 src/gallium/drivers/virgl/virgl_winsys.h | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
b/src/gallium/drivers/virgl/virgl_hw.h
index 93849c03dd..624be3b271 100644
--- a/src/gallium/drivers/virgl/virgl_hw.h
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -286,6 +286,7 @@ struct virgl_caps_v2 {
 int32_t max_texture_gather_offset;
 uint32_t texture_buffer_offset_alignment;
 uint32_t uniform_buffer_offset_alignment;
+uint32_t shader_buffer_offset_alignment;
 };
 
 union virgl_caps {
diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
b/src/gallium/drivers/virgl/virgl_screen.c
index 02613f1866..f183752d63 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -198,6 +198,8 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
   return vscreen->caps.caps.v1.bset.has_sample_shading;
case PIPE_CAP_CULL_DISTANCE:
   return vscreen->caps.caps.v1.bset.has_cull;
+   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
+  return vscreen->caps.caps.v2.shader_buffer_offset_alignment;
case PIPE_CAP_TEXTURE_GATHER_SM5:
case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
case PIPE_CAP_FAKE_SW_MSAA:
@@ -227,7 +229,6 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL:
case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL:
-   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
case PIPE_CAP_INVALIDATE_BUFFER:
case PIPE_CAP_GENERATE_MIPMAP:
case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
diff --git a/src/gallium/drivers/virgl/virgl_winsys.h 
b/src/gallium/drivers/virgl/virgl_winsys.h
index 99e98ad9c9..c36b957aba 100644
--- a/src/gallium/drivers/virgl/virgl_winsys.h
+++ b/src/gallium/drivers/virgl/virgl_winsys.h
@@ -134,5 +134,6 @@ static inline void virgl_ws_fill_new_caps_defaults(struct 
virgl_drm_caps *caps)
caps->caps.v2.max_texture_gather_offset = 7;
caps->caps.v2.texture_buffer_offset_alignment = 32;
caps->caps.v2.uniform_buffer_offset_alignment = 256;
+   caps->caps.v2.shader_buffer_offset_alignment = 32;
 }
 #endif
-- 
2.13.5

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

Re: [Mesa-dev] [PATCH] virgl: add shader offset alignment to to v2 caps struct

[Ilia Mirkin]

On Thu, Apr 12, 2018 at 8:33 PM, Gurchetan Singh
 wrote:
> From: "gurchetansi...@chromium.org" 
>
> This is the SSBO analogue to fe0647. User supplied data must
> be a multiple of GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT.
>
> This fixes 44 GLES31 tests on airlied@'s GLES31 sketch branches with
> Nvidia hardware, but this patch standalone can applied to master. The
> alignment restriction on Nvidia is 32, hence the default value.
>
> Example tests:
>dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.0
>dEQP-GLES31.functional.ssbo.layout.multi_basic_types.single_buffer.std430
> ---
>  src/gallium/drivers/virgl/virgl_hw.h | 1 +
>  src/gallium/drivers/virgl/virgl_screen.c | 1 +
>  src/gallium/drivers/virgl/virgl_winsys.h | 1 +
>  3 files changed, 3 insertions(+)
>
> diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
> b/src/gallium/drivers/virgl/virgl_hw.h
> index 93849c03ddd..624be3b271d 100644
> --- a/src/gallium/drivers/virgl/virgl_hw.h
> +++ b/src/gallium/drivers/virgl/virgl_hw.h
> @@ -286,6 +286,7 @@ struct virgl_caps_v2 {
>  int32_t max_texture_gather_offset;
>  uint32_t texture_buffer_offset_alignment;
>  uint32_t uniform_buffer_offset_alignment;
> +uint32_t shader_buffer_offset_alignment;
>  };
>
>  union virgl_caps {
> diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
> b/src/gallium/drivers/virgl/virgl_screen.c
> index 02613f18663..886ea196bdd 100644
> --- a/src/gallium/drivers/virgl/virgl_screen.c
> +++ b/src/gallium/drivers/virgl/virgl_screen.c
> @@ -228,6 +228,7 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
> param)
> case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL:
> case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL:
> case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> +  return vscreen->caps.caps.v2.shader_buffer_offset_alignment;

You probably meant to move this out of the fallback logic...

> case PIPE_CAP_INVALIDATE_BUFFER:
> case PIPE_CAP_GENERATE_MIPMAP:
> case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
> diff --git a/src/gallium/drivers/virgl/virgl_winsys.h 
> b/src/gallium/drivers/virgl/virgl_winsys.h
> index 99e98ad9c9c..c36b957abad 100644
> --- a/src/gallium/drivers/virgl/virgl_winsys.h
> +++ b/src/gallium/drivers/virgl/virgl_winsys.h
> @@ -134,5 +134,6 @@ static inline void virgl_ws_fill_new_caps_defaults(struct 
> virgl_drm_caps *caps)
> caps->caps.v2.max_texture_gather_offset = 7;
> caps->caps.v2.texture_buffer_offset_alignment = 32;
> caps->caps.v2.uniform_buffer_offset_alignment = 256;
> +   caps->caps.v2.shader_buffer_offset_alignment = 32;
>  }
>  #endif
> --
> 2.13.5
>
> ___
> 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 07/17] radeonsi: skip DCC render feedback checking if color writes are disabled

[Timothy Arceri]

This change cause around 20+ piglit crashes on my Polaris.

e.g tests/spec/arb_compute_shader/execution/atomic-counter.shader_test

Thread 1 "shader_runner" received signal SIGSEGV, Segmentation fault.
0x71009ccc in si_get_total_colormask (sctx=0x64b140) at 
si_pipe.h:945

945 if (sctx->queued.named.rasterizer->rasterizer_discard)


It also seems to cause hundreds of test failures e.g

./bin/copyteximage CUBE -auto


Unfortunately it doesn't revert cleanly either.

On 04/04/18 11:59, Marek Olšák wrote:

From: Marek Olšák 

The previous patch is required for this.
---
  src/gallium/drivers/radeonsi/si_blit.c  |  5 +
  src/gallium/drivers/radeonsi/si_pipe.h  | 17 +
  src/gallium/drivers/radeonsi/si_state_shaders.c |  6 +-
  3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_blit.c 
b/src/gallium/drivers/radeonsi/si_blit.c
index 45770b0d9bf..8dd8bc2a4dd 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers/radeonsi/si_blit.c
@@ -706,20 +706,25 @@ static void 
si_check_render_feedback_resident_images(struct si_context *sctx)
si_check_render_feedback_texture(sctx, tex,
 view->u.tex.level,
 view->u.tex.level,
 view->u.tex.first_layer,
 view->u.tex.last_layer);
}
  }
  
  static void si_check_render_feedback(struct si_context *sctx)

  {
+   /* There is no render feedback if color writes are disabled.
+* (e.g. a pixel shader with image stores)
+*/
+   if (!si_get_total_colormask(sctx))
+   return;
  
  	if (!sctx->need_check_render_feedback)

return;
  
  	for (int i = 0; i < SI_NUM_SHADERS; ++i) {

si_check_render_feedback_images(sctx, &sctx->images[i]);
si_check_render_feedback_textures(sctx, &sctx->samplers[i]);
}
  
  	si_check_render_feedback_resident_images(sctx);

diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h
index e3d45ef6c3b..e65c946d186 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -933,11 +933,28 @@ vi_tc_compat_htile_enabled(struct r600_texture *tex, 
unsigned level)
  }
  
  static inline unsigned si_get_ps_iter_samples(struct si_context *sctx)

  {
if (sctx->ps_uses_fbfetch)
return sctx->framebuffer.nr_samples;
  
  	return sctx->ps_iter_samples;

  }
  
+static inline unsigned si_get_total_colormask(struct si_context *sctx)

+{
+   if (sctx->queued.named.rasterizer->rasterizer_discard)
+   return 0;
+
+   struct si_shader_selector *ps = sctx->ps_shader.cso;
+   unsigned colormask = sctx->framebuffer.colorbuf_enabled_4bit &
+sctx->queued.named.blend->cb_target_mask;
+
+   if (!ps->info.properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS])
+   colormask &= ps->colors_written_4bit;
+   else if (!ps->colors_written_4bit)
+   colormask = 0; /* color0 writes all cbufs, but it's not written 
*/
+
+   return colormask;
+}
+
  #endif
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index d7742eafb04..f2d29e40744 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1208,25 +1208,21 @@ static void si_shader_selector_key_hw_vs(struct 
si_context *sctx,
bool ps_disabled = true;
if (ps) {
const struct si_state_blend *blend = sctx->queued.named.blend;
bool alpha_to_coverage = blend && blend->alpha_to_coverage;
bool ps_modifies_zs = ps->info.uses_kill ||
  ps->info.writes_z ||
  ps->info.writes_stencil ||
  ps->info.writes_samplemask ||
  alpha_to_coverage ||
  si_get_alpha_test_func(sctx) != 
PIPE_FUNC_ALWAYS;
-
-   unsigned ps_colormask = sctx->framebuffer.colorbuf_enabled_4bit 
&
-   
sctx->queued.named.blend->cb_target_mask;
-   if 
(!ps->info.properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS])
-   ps_colormask &= ps->colors_written_4bit;
+   unsigned ps_colormask = si_get_total_colormask(sctx);
  
  		ps_disabled = sctx->queued.named.rasterizer->rasterizer_discard ||

  (!ps_colormask &&
   !ps_modifies_zs &&
   !ps->info.writes_memory);
}
  
  	/* Find out which VS outputs aren't used by the PS. */

uint64_t outp

[Mesa-dev] [PATCH] virgl: add shader offset alignment to to v2 caps struct

[Gurchetan Singh]

From: "gurchetansi...@chromium.org" 

This is the SSBO analogue to fe0647. User supplied data must
be a multiple of GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT.

This fixes 44 GLES31 tests on airlied@'s GLES31 sketch branches with
Nvidia hardware, but this patch standalone can applied to master. The
alignment restriction on Nvidia is 32, hence the default value.

Example tests:
   dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.0
   dEQP-GLES31.functional.ssbo.layout.multi_basic_types.single_buffer.std430
---
 src/gallium/drivers/virgl/virgl_hw.h | 1 +
 src/gallium/drivers/virgl/virgl_screen.c | 1 +
 src/gallium/drivers/virgl/virgl_winsys.h | 1 +
 3 files changed, 3 insertions(+)

diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
b/src/gallium/drivers/virgl/virgl_hw.h
index 93849c03ddd..624be3b271d 100644
--- a/src/gallium/drivers/virgl/virgl_hw.h
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -286,6 +286,7 @@ struct virgl_caps_v2 {
 int32_t max_texture_gather_offset;
 uint32_t texture_buffer_offset_alignment;
 uint32_t uniform_buffer_offset_alignment;
+uint32_t shader_buffer_offset_alignment;
 };
 
 union virgl_caps {
diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
b/src/gallium/drivers/virgl/virgl_screen.c
index 02613f18663..886ea196bdd 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -228,6 +228,7 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL:
case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL:
case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
+  return vscreen->caps.caps.v2.shader_buffer_offset_alignment;
case PIPE_CAP_INVALIDATE_BUFFER:
case PIPE_CAP_GENERATE_MIPMAP:
case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
diff --git a/src/gallium/drivers/virgl/virgl_winsys.h 
b/src/gallium/drivers/virgl/virgl_winsys.h
index 99e98ad9c9c..c36b957abad 100644
--- a/src/gallium/drivers/virgl/virgl_winsys.h
+++ b/src/gallium/drivers/virgl/virgl_winsys.h
@@ -134,5 +134,6 @@ static inline void virgl_ws_fill_new_caps_defaults(struct 
virgl_drm_caps *caps)
caps->caps.v2.max_texture_gather_offset = 7;
caps->caps.v2.texture_buffer_offset_alignment = 32;
caps->caps.v2.uniform_buffer_offset_alignment = 256;
+   caps->caps.v2.shader_buffer_offset_alignment = 32;
 }
 #endif
-- 
2.13.5

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

Re: [Mesa-dev] [PATCH v2] anv: fix number of planes for depth & stencil

[Nanley Chery]

On Thu, Apr 12, 2018 at 02:54:59PM -0700, Lionel Landwerlin wrote:
> We're not counting correctly with depth & stencil images.
> 
> Additionally we need to move an assert that is meant just for color
> attachments.
> 
> v2: Move an assert() (Reported by Craig)
> Change aspect mask checks (Francesco)
> 
> Signed-off-by: Lionel Landwerlin 
> Fixes: a62a97933578a ("anv: enable multiple planes per image/imageView")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105994
> ---
>  src/intel/vulkan/anv_private.h | 4 
>  src/intel/vulkan/genX_cmd_buffer.c | 2 +-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 

This patch is
Reviewed-by: Nanley Chery 

> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
> index 53115ae470f..52d4ba58dc9 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -2356,6 +2356,10 @@ anv_image_aspect_get_planes(VkImageAspectFlags 
> aspect_mask)
> if (aspect_mask & VK_IMAGE_ASPECT_PLANE_2_BIT)
>planes++;
>  
> +   if ((aspect_mask & VK_IMAGE_ASPECT_DEPTH_BIT) != 0 &&
> +   (aspect_mask & VK_IMAGE_ASPECT_STENCIL_BIT) != 0)
> +  planes++;
> +
> return planes;
>  }
>  
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 3c703f6be44..cbe623802e9 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -1248,13 +1248,13 @@ genX(cmd_buffer_setup_attachments)(struct 
> anv_cmd_buffer *cmd_buffer,
>  
>   struct anv_image_view *iview = framebuffer->attachments[i];
>   anv_assert(iview->vk_format == att->format);
> - anv_assert(iview->n_planes == 1);
>  
>   const uint32_t num_layers = iview->planes[0].isl.array_len;
>   state->attachments[i].pending_clear_views = (1 << num_layers) - 1;
>  
>   union isl_color_value clear_color = { .u32 = { 0, } };
>   if (att_aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV) {
> +anv_assert(iview->n_planes == 1);
>  assert(att_aspects == VK_IMAGE_ASPECT_COLOR_BIT);
>  color_attachment_compute_aux_usage(cmd_buffer->device,
> state, i, begin->renderArea,
> -- 
> 2.17.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [AppVeyor] mesa master #7445 failed

[Marek Olšák]

I'm working on it.

Marek

On Thu, Apr 12, 2018 at 7:36 PM, AppVeyor  wrote:

> Build mesa 7445 failed
> 
>
> Commit 43d66c8c2d by Marek Olšák  on 4/8/2018 5:13
> PM:
> mesa: include mtypes.h less\n\n- remove mtypes.h from most header files\n-
> add main/menums.h for often used definitions\n- remove main/core.h\n\nv2:
> fix radv build\n\nReviewed-by: Brian Paul 
>
> Configure your notification preferences
> 
>
> ___
> 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] [AppVeyor] mesa master #7445 failed

[AppVeyor]

Build mesa 7445 failed


Commit 43d66c8c2d by Marek Olšák on 4/8/2018 5:13 PM:

mesa: include mtypes.h less\n\n- remove mtypes.h from most header files\n- add main/menums.h for often used definitions\n- remove main/core.h\n\nv2: fix radv build\n\nReviewed-by: Brian Paul 


Configure your notification preferences

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

[Mesa-dev] [Bug 100629] No mans sky renders white screen under wine in linux

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #5 from Timothy Arceri  ---
(In reply to Giovanni ongaro from comment #4)
> i have noticed this on mesa git 
> 4.5 Mesa 17.2.0-devel (git-d5a9608) 
> it states compatibility profile 4.5
> Still no mans sky doest work under wine staging

Until recently the highest compat profile Mesa drivers supported was 3.0.
radeonsi now supports 3.1. 4.5 would be referring to the core profile. You can
run "glxinfo | grep OpenGL" to see what your driver supports.

Anyway Wine has now switched to using Core profile for Mesa drivers so it's
possible the game will now work better. Either way 4.5 compat profile is a
known missing feature rather than a bug so I'm going to close this bug for now.

-- 
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 v3 7/7] radv: enable subgroup capabilities

[Bas Nieuwenhuizen]

Okay, this series is

Reviewed-by: Bas Nieuwenhuizen 

Please split out the patch Jason commented on and give me a link to a
branch and I'll merge.

On Tue, Apr 10, 2018 at 4:37 PM, Daniel Schürmann
 wrote:
> ---
>  src/amd/vulkan/radv_device.c | 10 --
>  src/amd/vulkan/radv_shader.c |  7 ++-
>  2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 4fc7392e65..e50b661cac 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -939,8 +939,14 @@ void radv_GetPhysicalDeviceProperties2(
> (VkPhysicalDeviceSubgroupProperties*)ext;
> properties->subgroupSize = 64;
> properties->supportedStages = VK_SHADER_STAGE_ALL;
> -   properties->supportedOperations = 
> VK_SUBGROUP_FEATURE_BASIC_BIT;
> -   properties->quadOperationsInAllStages = false;
> +   properties->supportedOperations =
> +   
> VK_SUBGROUP_FEATURE_BASIC_BIT |
> +   
> VK_SUBGROUP_FEATURE_BALLOT_BIT |
> +   
> VK_SUBGROUP_FEATURE_QUAD_BIT |
> +   
> VK_SUBGROUP_FEATURE_SHUFFLE_BIT |
> +   
> VK_SUBGROUP_FEATURE_SHUFFLE_RELATIVE_BIT |
> +   
> VK_SUBGROUP_FEATURE_VOTE_BIT;
> +   properties->quadOperationsInAllStages = true;
> break;
> }
> case 
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_3_PROPERTIES: {
> diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
> index eaf24dcdee..9d49bc02a8 100644
> --- a/src/amd/vulkan/radv_shader.c
> +++ b/src/amd/vulkan/radv_shader.c
> @@ -213,7 +213,11 @@ radv_shader_compile_to_nir(struct radv_device *device,
> .tessellation = true,
> .int64 = true,
> .multiview = true,
> +   .subgroup_ballot = true,
> .subgroup_basic = true,
> +   .subgroup_quad = true,
> +   .subgroup_shuffle = true,
> +   .subgroup_vote = true,
> .variable_pointers = true,
> .gcn_shader = true,
> .trinary_minmax = true,
> @@ -283,7 +287,8 @@ radv_shader_compile_to_nir(struct radv_device *device,
> .lower_to_scalar = 1,
> .lower_subgroup_masks = 1,
> .lower_shuffle = 1,
> -   .lower_quad =  1,
> +   .lower_shuffle_to_32bit = 1,
> +   .lower_vote_eq_to_ballot = 1,
> });
>
> radv_optimize_nir(nir);
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] anv: fix number of planes for depth & stencil

[Lionel Landwerlin]

We're not counting correctly with depth & stencil images.

Additionally we need to move an assert that is meant just for color
attachments.

v2: Move an assert() (Reported by Craig)
Change aspect mask checks (Francesco)

Signed-off-by: Lionel Landwerlin 
Fixes: a62a97933578a ("anv: enable multiple planes per image/imageView")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105994
---
 src/intel/vulkan/anv_private.h | 4 
 src/intel/vulkan/genX_cmd_buffer.c | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 53115ae470f..52d4ba58dc9 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2356,6 +2356,10 @@ anv_image_aspect_get_planes(VkImageAspectFlags 
aspect_mask)
if (aspect_mask & VK_IMAGE_ASPECT_PLANE_2_BIT)
   planes++;
 
+   if ((aspect_mask & VK_IMAGE_ASPECT_DEPTH_BIT) != 0 &&
+   (aspect_mask & VK_IMAGE_ASPECT_STENCIL_BIT) != 0)
+  planes++;
+
return planes;
 }
 
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 3c703f6be44..cbe623802e9 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -1248,13 +1248,13 @@ genX(cmd_buffer_setup_attachments)(struct 
anv_cmd_buffer *cmd_buffer,
 
  struct anv_image_view *iview = framebuffer->attachments[i];
  anv_assert(iview->vk_format == att->format);
- anv_assert(iview->n_planes == 1);
 
  const uint32_t num_layers = iview->planes[0].isl.array_len;
  state->attachments[i].pending_clear_views = (1 << num_layers) - 1;
 
  union isl_color_value clear_color = { .u32 = { 0, } };
  if (att_aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV) {
+anv_assert(iview->n_planes == 1);
 assert(att_aspects == VK_IMAGE_ASPECT_COLOR_BIT);
 color_attachment_compute_aux_usage(cmd_buffer->device,
state, i, begin->renderArea,
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH] anv: fix number of planes for depth & stencil

[Jason Ekstrand]

Right.  It's just a very generically named function for a fairly specific
task. :-)  Maybe we should just inline in at it's one use.

On Thu, Apr 12, 2018 at 2:17 PM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> It's supposed to depend on how many aspects you've selected for creating
> the image view (not always correlate to the image).
>
>
> On 12/04/18 14:15, Jason Ekstrand wrote:
>
> I don't really get what this patch is doing.  Why not just use
> image->n_planes?
>
> On Thu, Apr 12, 2018 at 11:37 AM, Lionel Landwerlin <
> lionel.g.landwer...@intel.com> wrote:
>
>> We're not counting correctly with depth & stencil images.
>>
>> Signed-off-by: Lionel Landwerlin 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105994
>> ---
>>  src/intel/vulkan/anv_private.h | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/src/intel/vulkan/anv_private.h
>> b/src/intel/vulkan/anv_private.h
>> index 53115ae470f..a4297511bbb 100644
>> --- a/src/intel/vulkan/anv_private.h
>> +++ b/src/intel/vulkan/anv_private.h
>> @@ -2356,6 +2356,10 @@ anv_image_aspect_get_planes(VkImageAspectFlags
>> aspect_mask)
>> if (aspect_mask & VK_IMAGE_ASPECT_PLANE_2_BIT)
>>planes++;
>>
>> +   if (aspect_mask & VK_IMAGE_ASPECT_DEPTH_BIT &&
>> +   aspect_mask & VK_IMAGE_ASPECT_STENCIL_BIT)
>> +  planes++;
>> +
>> return planes;
>>  }
>>
>> --
>> 2.17.0
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] anv: fix number of planes for depth & stencil

[Lionel Landwerlin]

It's supposed to depend on how many aspects you've selected for creating 
the image view (not always correlate to the image).


On 12/04/18 14:15, Jason Ekstrand wrote:
I don't really get what this patch is doing.  Why not just use 
image->n_planes?


On Thu, Apr 12, 2018 at 11:37 AM, Lionel Landwerlin 
mailto:lionel.g.landwer...@intel.com>> 
wrote:


We're not counting correctly with depth & stencil images.

Signed-off-by: Lionel Landwerlin mailto:lionel.g.landwer...@intel.com>>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105994

---
 src/intel/vulkan/anv_private.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/intel/vulkan/anv_private.h
b/src/intel/vulkan/anv_private.h
index 53115ae470f..a4297511bbb 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2356,6 +2356,10 @@
anv_image_aspect_get_planes(VkImageAspectFlags aspect_mask)
    if (aspect_mask & VK_IMAGE_ASPECT_PLANE_2_BIT)
       planes++;

+   if (aspect_mask & VK_IMAGE_ASPECT_DEPTH_BIT &&
+       aspect_mask & VK_IMAGE_ASPECT_STENCIL_BIT)
+      planes++;
+
    return planes;
 }

--
2.17.0

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





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

Re: [Mesa-dev] [PATCH] anv: fix number of planes for depth & stencil

[Jason Ekstrand]

I don't really get what this patch is doing.  Why not just use
image->n_planes?

On Thu, Apr 12, 2018 at 11:37 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> We're not counting correctly with depth & stencil images.
>
> Signed-off-by: Lionel Landwerlin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105994
> ---
>  src/intel/vulkan/anv_private.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_
> private.h
> index 53115ae470f..a4297511bbb 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -2356,6 +2356,10 @@ anv_image_aspect_get_planes(VkImageAspectFlags
> aspect_mask)
> if (aspect_mask & VK_IMAGE_ASPECT_PLANE_2_BIT)
>planes++;
>
> +   if (aspect_mask & VK_IMAGE_ASPECT_DEPTH_BIT &&
> +   aspect_mask & VK_IMAGE_ASPECT_STENCIL_BIT)
> +  planes++;
> +
> return planes;
>  }
>
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: Implement VK_EXT_vertex_attribute_divisor.

[Bas Nieuwenhuizen]

Test test to the list.

On Thu, Apr 12, 2018 at 9:28 AM, Samuel Pitoiset
 wrote:
> Looks good to me, do you have tests?
>
> Reviewed-by: Samuel Pitoiset 
>
>
> On 04/12/2018 01:45 AM, Bas Nieuwenhuizen wrote:
>>
>> Pretty straight forward, just pass the divisors through the shader
>> key and then do a LLVM divide.
>> ---
>>   src/amd/vulkan/radv_device.c  |  6 ++
>>   src/amd/vulkan/radv_extensions.py |  1 +
>>   src/amd/vulkan/radv_nir_to_llvm.c | 26 +++---
>>   src/amd/vulkan/radv_pipeline.c| 26 ++
>>   src/amd/vulkan/radv_private.h |  1 +
>>   src/amd/vulkan/radv_shader.h  |  1 +
>>   6 files changed, 50 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
>> index 41f8242754c..4cd24eb2e96 100644
>> --- a/src/amd/vulkan/radv_device.c
>> +++ b/src/amd/vulkan/radv_device.c
>> @@ -961,6 +961,12 @@ void radv_GetPhysicalDeviceProperties2(
>> properties->filterMinmaxSingleComponentFormats =
>> true;
>> break;
>> }
>> +   case
>> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT: {
>> +
>> VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT *properties =
>> +
>> (VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT *)ext;
>> +   properties->maxVertexAttribDivisor = UINT32_MAX;
>> +   break;
>> +   }
>> default:
>> break;
>> }
>> diff --git a/src/amd/vulkan/radv_extensions.py
>> b/src/amd/vulkan/radv_extensions.py
>> index bc63a34896a..48cf3ccd992 100644
>> --- a/src/amd/vulkan/radv_extensions.py
>> +++ b/src/amd/vulkan/radv_extensions.py
>> @@ -93,6 +93,7 @@ EXTENSIONS = [
>>   Extension('VK_EXT_global_priority',   1,
>> 'device->rad_info.has_ctx_priority'),
>>   Extension('VK_EXT_sampler_filter_minmax', 1,
>> 'device->rad_info.chip_class >= CIK'),
>>   Extension('VK_EXT_shader_viewport_index_layer',   1, True),
>> +Extension('VK_EXT_vertex_attribute_divisor',  1, True),
>>   Extension('VK_AMD_draw_indirect_count',   1, True),
>>   Extension('VK_AMD_gcn_shader',1, True),
>>   Extension('VK_AMD_rasterization_order',   1,
>> 'device->has_out_of_order_rast'),
>> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
>> b/src/amd/vulkan/radv_nir_to_llvm.c
>> index 2f0864da462..a6b48e297da 100644
>> --- a/src/amd/vulkan/radv_nir_to_llvm.c
>> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
>> @@ -1794,14 +1794,26 @@ handle_vs_input_decl(struct radv_shader_context
>> *ctx,
>> for (unsigned i = 0; i < attrib_count; ++i, ++idx) {
>> if (ctx->options->key.vs.instance_rate_inputs & (1u <<
>> (index + i))) {
>> -   buffer_index = LLVMBuildAdd(ctx->ac.builder,
>> ctx->abi.instance_id,
>> -
>> ctx->abi.start_instance, "");
>> -   if (ctx->options->key.vs.as_ls) {
>> -   ctx->shader_info->vs.vgpr_comp_cnt =
>> -   MAX2(2,
>> ctx->shader_info->vs.vgpr_comp_cnt);
>> +   uint32_t divisor =
>> ctx->options->key.vs.instance_rate_divisors[index + i];
>> +
>> +   if (divisor) {
>> +   buffer_index =
>> LLVMBuildAdd(ctx->ac.builder, ctx->abi.instance_id,
>> +
>> ctx->abi.start_instance, "");
>> +
>> +   if (divisor != 1) {
>> +   buffer_index =
>> LLVMBuildUDiv(ctx->ac.builder, buffer_index,
>> +
>> LLVMConstInt(ctx->ac.i32, divisor, 0), "");
>> +   }
>> +
>> +   if (ctx->options->key.vs.as_ls) {
>> +   ctx->shader_info->vs.vgpr_comp_cnt
>> =
>> +   MAX2(2,
>> ctx->shader_info->vs.vgpr_comp_cnt);
>> +   } else {
>> +   ctx->shader_info->vs.vgpr_comp_cnt
>> =
>> +   MAX2(1,
>> ctx->shader_info->vs.vgpr_comp_cnt);
>> +   }
>> } else {
>> -   ctx->shader_info->vs.vgpr_comp_cnt =
>> -   MAX2(1,
>> ctx->shader_info->vs.vgpr_comp_cnt);
>> +   buffer_index = ctx->ac.i32_0;
>> }
>> } else
>> buffer_index = LLVMBuildAdd(ctx->ac.builder,
>> ctx->abi.vertex_id,
>> diff --git a/src/amd/vulkan/radv_pipeline.c
>> b/src/amd/vulkan/radv_pipeline.c
>> index 08abb9dbc47..91baac431b8 100644
>> --- a/src/amd/vulkan/radv_pipeline.c
>> +++ b/src/amd/vulkan/radv_pipeline.c
>> @@ -1743,22 +1743,38 @@ radv_generate_graphics_pipeline_key(st

[Mesa-dev] [PATCH crucible 2/2] Add VK_EXT_vertex_attribute_divisor test.

[Bas Nieuwenhuizen]

From: Bas Nieuwenhuizen 

---
 Makefile.am   |   2 +
 .../vertex_attribute_divisor.c| 216 ++
 2 files changed, 218 insertions(+)
 create mode 100644 
src/tests/func/vertex_attribute_divisor/vertex_attribute_divisor.c

diff --git a/Makefile.am b/Makefile.am
index 7c4a52b..128a7e9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -106,6 +106,7 @@ bin_crucible_SOURCES = \
src/tests/func/ssbo/interleave.c \
src/tests/func/sync/semaphore-fd.c \
src/tests/func/renderpass/clear.c \
+   src/tests/func/vertex_attribute_divisor/vertex_attribute_divisor.c \
src/tests/stress/lots-of-surface-state.c \
src/tests/stress/buffer_limit.c \
src/tests/self/concurrent-output.c \
@@ -151,6 +152,7 @@ BUILT_SOURCES = \
src/tests/func/shader_group_vote/ext_shader_subgroup_vote-spirv.h \
src/tests/func/ssbo/interleave-spirv.h \
src/tests/func/sync/semaphore-fd-spirv.h \
+   
src/tests/func/vertex_attribute_divisor/vertex_attribute_divisor-spirv.h \
src/tests/stress/lots-of-surface-state-spirv.h
 
 bin_crucible_LDADD = $(MESA_LDFLAGS) -lm -lvulkan -lpthread $(libpng_LIBS) \
diff --git a/src/tests/func/vertex_attribute_divisor/vertex_attribute_divisor.c 
b/src/tests/func/vertex_attribute_divisor/vertex_attribute_divisor.c
new file mode 100644
index 000..42ddfd6
--- /dev/null
+++ b/src/tests/func/vertex_attribute_divisor/vertex_attribute_divisor.c
@@ -0,0 +1,216 @@
+// Copyright 2018 Google LLC
+//
+// Permission is hereby granted, free of charge, to any person obtaining a
+// copy of this software and associated documentation files (the "Software"),
+// to deal in the Software without restriction, including without limitation
+// the rights to use, copy, modify, merge, publish, distribute, sublicense,
+// and/or sell copies of the Software, and to permit persons to whom the
+// Software is furnished to do so, subject to the following conditions:
+//
+// The above copyright notice and this permission notice (including the next
+// paragraph) shall be included in all copies or substantial portions of the
+// Software.
+//
+// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+// THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+// FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+// IN THE SOFTWARE.
+
+
+#include "util/simple_pipeline.h"
+#include "tapi/t.h"
+#include 
+
+#include "vertex_attribute_divisor-spirv.h"
+
+static void
+vertex_attribute_divisor()
+{
+t_require_ext("VK_EXT_vertex_attribute_divisor");
+
+VkRenderPass pass = qoCreateRenderPass(t_device,
+.attachmentCount = 1,
+.pAttachments = (VkAttachmentDescription[]) {
+{
+QO_ATTACHMENT_DESCRIPTION_DEFAULTS,
+.format = VK_FORMAT_R8G8B8A8_UNORM,
+.loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR,
+},
+},
+.subpassCount = 1,
+.pSubpasses = (VkSubpassDescription[]) {
+{
+QO_SUBPASS_DESCRIPTION_DEFAULTS,
+.colorAttachmentCount = 1,
+.pColorAttachments = (VkAttachmentReference[]) {
+{
+.attachment = 0,
+.layout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL,
+},
+},
+.preserveAttachmentCount = 1,
+.pPreserveAttachments = (uint32_t[]) { 0 },
+}
+});
+
+VkShaderModule vs = qoCreateShaderModuleGLSL(t_device, VERTEX,
+layout(location = 0) in vec4 a_position;
+layout(location = 1) in uint attributes[7];
+layout(location = 0) out vec4 v_color;
+void main()
+{
+gl_Position = vec4(a_position.x, -1.0 + float(gl_InstanceIndex) / 
8.0 + (1.0 + a_position.y) / 16.0,
+   a_position.z, a_position.w);
+bool correct = true;
+if (attributes[0] != 0)
+correct = false;
+for (int i = 1; i < 7; ++i)
+if (attributes[i] != gl_InstanceIndex / i)
+correct = false;
+v_color = correct ? vec4(0.0, 1.0, 0.0, 1.0) : vec4(1.0, 0.0, 0.0, 
1.0);
+}
+);
+
+VkShaderModule fs = qoCreateShaderModuleGLSL(t_device, FRAGMENT,
+layout(location = 0) in vec4 v_color;
+layout(location = 0) out vec4 color;
+void main()
+{
+color = v_color;
+}
+);
+
+const VkVertexInputBindingDescription bindings[8] = {
+{.binding = 0, .stride = 8, .inputRate = VK_VERTEX_INPUT_RATE_VERTEX},
+{.binding = 1

[Mesa-dev] [Bug 105901] Warn about mipmap-incomplete texture being used

[bugzilla-daemon]

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

--- Comment #4 from Ilia Mirkin  ---
There's also an unfortunate extra case that's not even picked up by
incomplete_tex here:

https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/texobj.h#n118

And this is actually the case being mentioned. The incomplete() stuff doesn't
take sampler state into account.

-- 
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 93278] Configure should not have hardcoded list of {dri, gallium} drivers

[bugzilla-daemon]

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

--- Comment #5 from Chris Arena  ---
The remarkable thing about this was that an unlikely target and dependent
library was picked by default.

Cross compiling on an cubieboard for an Intel part is unlikely in the extreme.
What is most likely is compiling for the cubieboard. Oftentimes, configure gets
it perfectly right for doing something in the native environment without
parameters.

If the configure can't figure out what the user wants from something in the
environment, defaulting to an unlikely case makes the user think that something
is broken, as I did. 

It would make sense that once the "checking for INTEL... no" was emitted, no
other diagnostics applicable to INTEL would be issued, such as "No package
'libdrm_intel' found". My reasoning is: intel isn't the platform, checking for
a package required to support intel doesn't mean anything, so saying that it's
missing doesn't add anything to the picture.

-- 
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] anv: fix number of planes for depth & stencil

[Nanley Chery]

On Thu, Apr 12, 2018 at 11:37:57AM -0700, Lionel Landwerlin wrote:
> We're not counting correctly with depth & stencil images.
> 
> Signed-off-by: Lionel Landwerlin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105994
> ---
>  src/intel/vulkan/anv_private.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
> index 53115ae470f..a4297511bbb 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -2356,6 +2356,10 @@ anv_image_aspect_get_planes(VkImageAspectFlags 
> aspect_mask)
> if (aspect_mask & VK_IMAGE_ASPECT_PLANE_2_BIT)
>planes++;
>  
> +   if (aspect_mask & VK_IMAGE_ASPECT_DEPTH_BIT &&
> +   aspect_mask & VK_IMAGE_ASPECT_STENCIL_BIT)
> +  planes++;
> +

I think we usually use curly braces for multi-line if-statements. I
can't find that written down anywhere though.

With or without that change, this patch is
Reviewed-by: Nanley Chery 

> return planes;
>  }
>  
> -- 
> 2.17.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105901] Warn about mipmap-incomplete texture being used

[bugzilla-daemon]

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

--- Comment #3 from Ruslan Kabatsayev  ---
(In reply to Brian Paul from comment #2)
> Want to take a stab at it?
I might try if no one other does, but I'm not sure how soon I'll be able to do
this.

-- 
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] anv: fix number of planes for depth & stencil

[Lionel Landwerlin]

We're not counting correctly with depth & stencil images.

Signed-off-by: Lionel Landwerlin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105994
---
 src/intel/vulkan/anv_private.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 53115ae470f..a4297511bbb 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2356,6 +2356,10 @@ anv_image_aspect_get_planes(VkImageAspectFlags 
aspect_mask)
if (aspect_mask & VK_IMAGE_ASPECT_PLANE_2_BIT)
   planes++;
 
+   if (aspect_mask & VK_IMAGE_ASPECT_DEPTH_BIT &&
+   aspect_mask & VK_IMAGE_ASPECT_STENCIL_BIT)
+  planes++;
+
return planes;
 }
 
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH 3/3] egl/x11: Handle both depth 30 formats for eglCreateImage().

[Ilia Mirkin]

On Thu, Apr 12, 2018 at 2:25 PM, Mario Kleiner
 wrote:
> On 04/12/2018 07:43 PM, Ilia Mirkin wrote:
>>
>> On Thu, Apr 12, 2018 at 1:18 PM, Mario Kleiner
>>  wrote:
>>>
>>> X11 Prime renderoffload is another unsolved problem with nouveau depth
>>> 30.
>>> Currently we get swapped red-blue with intel + nvidia. We could extend
>>> the
>>> buffer creation code to convert nouveau's rgba format into the bgra
>>> format
>>> wanted by intel or amd display gpu's during the blitImage call for
>>> converting the tiled renderbuffer to the linear buffer, like i try for
>>> the
>>> wayland+egl case. But we'd need to know what the display gpu wants.
>>> Haven't
>>> looked into that.
>>
>>
>> FWIW the NVIDIA hardware is perfectly happy to render into BGR10_A2.
>> Just can't display it.
>>
>>-ilia
>>
>
> Yes, but due to one of your earlier depth 30 commits we only expose formats
> with PIPE_BIND_DISPLAY_TARGET, so that ability is hidden from driver
> independent code like the EGL platform code, GLX etc. to prevent exposing
> formats that the hw can't display.

Yeah. The generic code would have to distinguish between "rendering"
and "displaying.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] egl/x11: Handle both depth 30 formats for eglCreateImage().

[Mario Kleiner]

On 04/12/2018 07:43 PM, Ilia Mirkin wrote:

On Thu, Apr 12, 2018 at 1:18 PM, Mario Kleiner
 wrote:

X11 Prime renderoffload is another unsolved problem with nouveau depth 30.
Currently we get swapped red-blue with intel + nvidia. We could extend the
buffer creation code to convert nouveau's rgba format into the bgra format
wanted by intel or amd display gpu's during the blitImage call for
converting the tiled renderbuffer to the linear buffer, like i try for the
wayland+egl case. But we'd need to know what the display gpu wants. Haven't
looked into that.


FWIW the NVIDIA hardware is perfectly happy to render into BGR10_A2.
Just can't display it.

   -ilia



Yes, but due to one of your earlier depth 30 commits we only expose 
formats with PIPE_BIND_DISPLAY_TARGET, so that ability is hidden from 
driver independent code like the EGL platform code, GLX etc. to prevent 
exposing formats that the hw can't display.


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

Re: [Mesa-dev] [PATCH 00/18] [RFC] Pointer specific data structures

[Eric Anholt]

Erik Faye-Lund  writes:

> On Wed, Apr 11, 2018 at 8:48 PM, Thomas Helland
>  wrote:
>> This series came about when I saw a talk online, while simultaneously
>> being annoyd about the needless waste of memory in our set as reported
>> by pahole. I have previously made some patches that changed our hash
>> table from a reprobing one to a quadratic probing one, in the name of
>> lower overhead and better cache locality, but I was not quite satisfied.
>>
>> I'm sending this series out now, as it seems like an ideal time since
>> Timothy is working at reducing our compile times. Further details about
>> the implementation and its advantages are described in the patches.
>> I've found this to give a reduction in shader-db runtime of about 2%,
>> but I have to do some more testing on my main computer, as my laptop
>> is showing its age with some terrible thermal issues.
>>
>> This special cases on pointers, as that is a very common usecase.
>> This allows us to drop some comparisons, and reduce the total size
>> of our hash table to 70% or our current and the set to 50%. It uses
>> linear probing and power-of-two table sizes to get good cache locality.
>> In the pointer_map caes it moves the stored hashes out into it's own
>> array for even better cache locality.
>>
>> I'm not sure if we want another set and map amongst our utils,
>> but the patch series is simple enough, and complete enough,
>> that I thought I could share it for some inital comments.
>
> This approach gives me a bad feeling. Using memory addresses for
> storage ordering in a compiler is not quite nice; it can easily mask
> spurious bugs, and have a compiler produce different result each run.
> Such compilers are not nice to work with. I've seen *exactly* this
> use-case go wrong in the past.

I've got bad news for you about what we're already doing in
_mesa_hash_pointer().

I'm generally interested in this series, though a completely new
implementation without unit tests is less interesting to me.  How much
do we get from just having a pointer map forked off of hash_table.c with
the ->hash removed?


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

Re: [Mesa-dev] [PATCH 3/3] egl/x11: Handle both depth 30 formats for eglCreateImage().

[Ilia Mirkin]

On Thu, Apr 12, 2018 at 1:18 PM, Mario Kleiner
 wrote:
> X11 Prime renderoffload is another unsolved problem with nouveau depth 30.
> Currently we get swapped red-blue with intel + nvidia. We could extend the
> buffer creation code to convert nouveau's rgba format into the bgra format
> wanted by intel or amd display gpu's during the blitImage call for
> converting the tiled renderbuffer to the linear buffer, like i try for the
> wayland+egl case. But we'd need to know what the display gpu wants. Haven't
> looked into that.

FWIW the NVIDIA hardware is perfectly happy to render into BGR10_A2.
Just can't display it.

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

Re: [Mesa-dev] [PATCH 3/3] egl/x11: Handle both depth 30 formats for eglCreateImage().

[Mario Kleiner]

On 04/10/2018 06:49 PM, Ilia Mirkin wrote:

On Tue, Apr 10, 2018 at 4:42 AM, Michel Dänzer  wrote:

On 2018-04-10 10:22 AM, Mario Kleiner wrote:

On 04/09/2018 12:12 PM, Michel Dänzer wrote:

On 2018-04-06 08:56 PM, Mario Kleiner wrote:

I'm interested in the full xdpyinfo *at screen depth 30*, in particular
whether it lists only one variant of depth 30 visuals. If so, one
possibility for a kludge would be to just look at any depth 30 visual.


Ok, the fresh v2 patch implements that kludge. This one retested to work
on nouveau, ati, intel.

On intel and nouveau we only get one channel mask for depth 30 visuals
in xdpyinfo. On amd we get both masks for xrgb2101010 and xbgr2101010,
as the amd gallium drivers expose both formats, but the ordering is
xrgb2101010 first, so that's fine when picking the first depth 30 visual
to get the channel mask for decisions.


Hmm, that sounds fragile though when there are both variants; is there
any guarantee they can't appear in the opposite order?


Afaics the rough order is determined by how the state tracker builds the 
list of __DRIconfig's in


mesa/src/gallium/state_trackers/dri/dri_screen.c:dri_fill_in_modes(),

ie. the ordering in the mesa_formats[] table at the top of that 
function. MESA_FORMAT_B10G10R10A2_UNORM and 
MESA_FORMAT_B10G10R10X2_UNORM are before MESA_FORMAT_R10G10B10A2_UNORM 
and MESA_FORMAT_R10G10B10X2_UNORM, and that is a requirement of the 
implementation that BGR[A/X] always comes before RGB[A/X].


The server processes those in the order they were generated when 
building visuals: xserver/glx/glxscreens.c:__glXScreenInit() converts 
pGlxScreen->fbconfigs retrieved from the Mesa driver into visuals. That 
fbconfigs list is always traversed in forward order.


So this should hopefully guarantee that for a given depth we always get 
the bgr10 formats we want before the rgb10 formats, and the order stays 
the way we want, with the desired bgr10 format as first depth 30 format.


That said, looking at line 388 of xserver/glx/glxscreens.c, i wonder if 
that check "if (depth == pScreen->visuals[i].nplanes)" is actually 
sufficient? Maybe we should check for compatible channel masks there and 
reject fbconfigs which don't find an existing X visual with matching 
channel mask? We do check the channel mask in pickFBConfig() when 
choosing FBConfigs for existing X Visuals in pass 1, but not when adding 
new X Visuals for FBConfigs that don't have existing X Visuals in pass 
2. That might get rid of the ambiguity and prevent exposing visuals that 
the ddx/kms driver won't be able display properly?




It seems like nouveau is stirring a bit of a hornet's nest here.
Unfortunately there's not a whole lot I can do about hw scanout format
support (rgb10x2 only, no bgr10x2 support until Kepler), but is there
something else that the DDX and/or mesa driver should be doing to
avoid some of this pain?

Should we get the *other* ddx's to avoid exposing both masks?


I think the ddx's only expose one mask per ddx, and seing both might be 
a X-Server problem (see above)? Maybe it could be beneficial if we 
stopped the amd gallium drivers from marking the R10G10B10[X/A]2 configs 
as PIPE_BIND_DISPLAY_TARGET if there isn't a use case for which they do 
that, apart from the hw/driver being capable of supporting it? Intel 
only supports bgrx ordering, nouveau only rgbx, amd both.


I have some half-finished wayland egl patches where it might help for 
the multi-gpu prime renderoffload case to feed wl_buffers in a format 
optimal for display on the server gpu instead of feeding them in a 
format that can be displayed by the server gpu but requires an extra 
copy. Not sure yet, half finished/half tested stuff, may not work out at 
all in the end.


X11 Prime renderoffload is another unsolved problem with nouveau depth 
30. Currently we get swapped red-blue with intel + nvidia. We could 
extend the buffer creation code to convert nouveau's rgba format into 
the bgra format wanted by intel or amd display gpu's during the 
blitImage call for converting the tiled renderbuffer to the linear 
buffer, like i try for the wayland+egl case. But we'd need to know what 
the display gpu wants. Haven't looked into that.


-mario



   -ilia


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

Re: [Mesa-dev] [PATCH v2 2/3] nir: add support for bindless_texture samplers

[Karol Herbst]

On Thu, Apr 12, 2018 at 6:33 PM, Jason Ekstrand  wrote:
> On Thu, Apr 12, 2018 at 7:36 AM, Karol Herbst  wrote:
>>
>> On Tue, Apr 10, 2018 at 5:10 PM, Jason Ekstrand 
>> wrote:
>> > On Tue, Apr 10, 2018 at 8:05 AM, Karol Herbst 
>> > wrote:
>> >>
>> >> v2: add both texture and sampler handles
>> >>
>> >> Signed-off-by: Karol Herbst 
>> >> ---
>> >>  src/compiler/glsl/glsl_to_nir.cpp | 17 +++--
>> >>  src/compiler/nir/nir.h|  2 ++
>> >>  src/compiler/nir/nir_print.c  |  6 ++
>> >>  3 files changed, 23 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/src/compiler/glsl/glsl_to_nir.cpp
>> >> b/src/compiler/glsl/glsl_to_nir.cpp
>> >> index dbb58d82e8f..9f233637306 100644
>> >> --- a/src/compiler/glsl/glsl_to_nir.cpp
>> >> +++ b/src/compiler/glsl/glsl_to_nir.cpp
>> >> @@ -1971,6 +1971,8 @@ nir_visitor::visit(ir_texture *ir)
>> >>  {
>> >> unsigned num_srcs;
>> >> nir_texop op;
>> >> +   bool bindless =
>> >> ir->sampler->variable_referenced()->contains_bindless();
>> >
>> >
>> > What happens if I have a uniform struct containing both a regular
>> > sampler
>> > and a bindless sampler?  I think this should be possible.
>> >
>>
>> well currently mesa just fails to compile, but even if it would I
>> don't see a way how we know with a ir_dereference if we reference a
>> bindless or bound sampler.
>>
>> The glsl_type doesn't tell us either and maybe it makes sense to add a
>> is_bindless method to glsl_type so that we can use it in places like
>> here? ir->sampler->type gives me the sampler type, but lacks the
>> information if it is bindless or not. Any thoughts?
>
>
> That seems like it's probably reasonable.  I'm not sure if we really want
> different types.  Another option would be to handle it as a layout qualifier
> on the structure type fields.  I'm not sure which is better.
>

I think we should add a field and add a is_opaque method to fix
glsl_type::contains_opaque, which is also broken, but we could do that
with a new type as well :(

>>
>> >>
>> >> +
>> >> switch (ir->op) {
>> >> case ir_tex:
>> >>op = nir_texop_tex;
>> >> @@ -2044,6 +2046,8 @@ nir_visitor::visit(ir_texture *ir)
>> >>num_srcs++;
>> >> if (ir->offset != NULL)
>> >>num_srcs++;
>> >> +   if (bindless)
>> >> +  num_srcs++;
>> >>
>> >> nir_tex_instr *instr = nir_tex_instr_create(this->shader,
>> >> num_srcs);
>> >>
>> >> @@ -2069,10 +2073,19 @@ nir_visitor::visit(ir_texture *ir)
>> >>unreachable("not reached");
>> >> }
>> >>
>> >> -   instr->texture = evaluate_deref(&instr->instr, ir->sampler);
>> >> -
>> >> unsigned src_number = 0;
>> >>
>> >> +   /* for bindless we use the texture handle src */
>> >> +   if (bindless) {
>> >> +  instr->texture = NULL;
>> >> +  instr->src[src_number].src =
>> >> + nir_src_for_ssa(evaluate_rvalue(ir->sampler));
>> >> +  instr->src[src_number].src_type = nir_tex_src_texture_handle;
>> >> +  src_number++;
>> >> +   } else {
>> >> +  instr->texture = evaluate_deref(&instr->instr, ir->sampler);
>> >> +   }
>> >> +
>> >> if (ir->coordinate != NULL) {
>> >>instr->coord_components = ir->coordinate->type->vector_elements;
>> >>instr->src[src_number].src =
>> >> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
>> >> index f33049d7134..e395352f89c 100644
>> >> --- a/src/compiler/nir/nir.h
>> >> +++ b/src/compiler/nir/nir.h
>> >> @@ -1218,6 +1218,8 @@ typedef enum {
>> >> nir_tex_src_texture_offset, /* < dynamically uniform indirect
>> >> offset
>> >> */
>> >> nir_tex_src_sampler_offset, /* < dynamically uniform indirect
>> >> offset
>> >> */
>> >> nir_tex_src_plane,  /* < selects plane for planar textures
>> >> */
>> >> +   nir_tex_src_texture_handle, /* < handle for bindless texture */
>> >> +   nir_tex_src_sampler_handle, /* < handle for bindless sampler */
>> >> nir_num_tex_src_types
>> >>  } nir_tex_src_type;
>> >>
>> >> diff --git a/src/compiler/nir/nir_print.c
>> >> b/src/compiler/nir/nir_print.c
>> >> index 21f13097651..52f20b1eb10 100644
>> >> --- a/src/compiler/nir/nir_print.c
>> >> +++ b/src/compiler/nir/nir_print.c
>> >> @@ -778,6 +778,12 @@ print_tex_instr(nir_tex_instr *instr, print_state
>> >> *state)
>> >>case nir_tex_src_plane:
>> >>   fprintf(fp, "(plane)");
>> >>   break;
>> >> +  case nir_tex_src_texture_handle:
>> >> + fprintf(fp, "(texture_handle)");
>> >> + break;
>> >> +  case nir_tex_src_sampler_handle:
>> >> + fprintf(fp, "(sampler_handle)");
>> >> + break;
>> >>
>> >>default:
>> >>   unreachable("Invalid texture source type");
>> >> --
>> >> 2.14.3
>> >>
>> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/3] nir: add support for bindless_texture samplers

[Jason Ekstrand]

On Thu, Apr 12, 2018 at 7:36 AM, Karol Herbst  wrote:

> On Tue, Apr 10, 2018 at 5:10 PM, Jason Ekstrand 
> wrote:
> > On Tue, Apr 10, 2018 at 8:05 AM, Karol Herbst 
> wrote:
> >>
> >> v2: add both texture and sampler handles
> >>
> >> Signed-off-by: Karol Herbst 
> >> ---
> >>  src/compiler/glsl/glsl_to_nir.cpp | 17 +++--
> >>  src/compiler/nir/nir.h|  2 ++
> >>  src/compiler/nir/nir_print.c  |  6 ++
> >>  3 files changed, 23 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/compiler/glsl/glsl_to_nir.cpp
> >> b/src/compiler/glsl/glsl_to_nir.cpp
> >> index dbb58d82e8f..9f233637306 100644
> >> --- a/src/compiler/glsl/glsl_to_nir.cpp
> >> +++ b/src/compiler/glsl/glsl_to_nir.cpp
> >> @@ -1971,6 +1971,8 @@ nir_visitor::visit(ir_texture *ir)
> >>  {
> >> unsigned num_srcs;
> >> nir_texop op;
> >> +   bool bindless =
> >> ir->sampler->variable_referenced()->contains_bindless();
> >
> >
> > What happens if I have a uniform struct containing both a regular sampler
> > and a bindless sampler?  I think this should be possible.
> >
>
> well currently mesa just fails to compile, but even if it would I
> don't see a way how we know with a ir_dereference if we reference a
> bindless or bound sampler.
>
> The glsl_type doesn't tell us either and maybe it makes sense to add a
> is_bindless method to glsl_type so that we can use it in places like
> here? ir->sampler->type gives me the sampler type, but lacks the
> information if it is bindless or not. Any thoughts?
>

That seems like it's probably reasonable.  I'm not sure if we really want
different types.  Another option would be to handle it as a layout
qualifier on the structure type fields.  I'm not sure which is better.


> >>
> >> +
> >> switch (ir->op) {
> >> case ir_tex:
> >>op = nir_texop_tex;
> >> @@ -2044,6 +2046,8 @@ nir_visitor::visit(ir_texture *ir)
> >>num_srcs++;
> >> if (ir->offset != NULL)
> >>num_srcs++;
> >> +   if (bindless)
> >> +  num_srcs++;
> >>
> >> nir_tex_instr *instr = nir_tex_instr_create(this->shader,
> num_srcs);
> >>
> >> @@ -2069,10 +2073,19 @@ nir_visitor::visit(ir_texture *ir)
> >>unreachable("not reached");
> >> }
> >>
> >> -   instr->texture = evaluate_deref(&instr->instr, ir->sampler);
> >> -
> >> unsigned src_number = 0;
> >>
> >> +   /* for bindless we use the texture handle src */
> >> +   if (bindless) {
> >> +  instr->texture = NULL;
> >> +  instr->src[src_number].src =
> >> + nir_src_for_ssa(evaluate_rvalue(ir->sampler));
> >> +  instr->src[src_number].src_type = nir_tex_src_texture_handle;
> >> +  src_number++;
> >> +   } else {
> >> +  instr->texture = evaluate_deref(&instr->instr, ir->sampler);
> >> +   }
> >> +
> >> if (ir->coordinate != NULL) {
> >>instr->coord_components = ir->coordinate->type->vector_elements;
> >>instr->src[src_number].src =
> >> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> >> index f33049d7134..e395352f89c 100644
> >> --- a/src/compiler/nir/nir.h
> >> +++ b/src/compiler/nir/nir.h
> >> @@ -1218,6 +1218,8 @@ typedef enum {
> >> nir_tex_src_texture_offset, /* < dynamically uniform indirect offset
> >> */
> >> nir_tex_src_sampler_offset, /* < dynamically uniform indirect offset
> >> */
> >> nir_tex_src_plane,  /* < selects plane for planar textures
> */
> >> +   nir_tex_src_texture_handle, /* < handle for bindless texture */
> >> +   nir_tex_src_sampler_handle, /* < handle for bindless sampler */
> >> nir_num_tex_src_types
> >>  } nir_tex_src_type;
> >>
> >> diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
> >> index 21f13097651..52f20b1eb10 100644
> >> --- a/src/compiler/nir/nir_print.c
> >> +++ b/src/compiler/nir/nir_print.c
> >> @@ -778,6 +778,12 @@ print_tex_instr(nir_tex_instr *instr, print_state
> >> *state)
> >>case nir_tex_src_plane:
> >>   fprintf(fp, "(plane)");
> >>   break;
> >> +  case nir_tex_src_texture_handle:
> >> + fprintf(fp, "(texture_handle)");
> >> + break;
> >> +  case nir_tex_src_sampler_handle:
> >> + fprintf(fp, "(sampler_handle)");
> >> + break;
> >>
> >>default:
> >>   unreachable("Invalid texture source type");
> >> --
> >> 2.14.3
> >>
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] getteximage: assume texture image is empty for non defined levels

[Juan A. Suarez Romero]

Current code is returning an INVALID_OPERATION when trying to use
getTextureImage() on a level that has not been explicitly defined.

That is, we define a mipmapped Texture2D with 3 levels, and try to use
GetTextureImage() for the 4th levels, and INVALID_OPERATION is returned.

Nevertheless, such case is not listed as an error in OpenGL 4.6 spec,
section 8.11.4 ("Texture Image Queries"), where all the case errors for
this function are defined. So it seems this is a valid operation.

On the other hand, in section 8.22 ("Texture State and Proxy State") it
states:

  "Each initial texture image is null. It has zero width, height, and
   depth, internal format RGBA, or R8 for buffer textures, component
   sizes set to zero and component types set to NONE, the compressed
   flag set to FALSE, a zero compressed size, and the bound buffer
   object name is zero."

We can assume that we are reading this initialized empty image when
calling GetTextureImage() with a non defined level.

With this assumption, we will reach one of the other error cases defined
for the functions. At the end, this means that we will return a
different error to the caller.

This fixes arb_get_texture_sub_image piglit tests.

v2: just return INVALID_VALUE if there isno defined level (Iago)

Signed-off-by: Juan A. Suarez Romero 
---
 src/mesa/main/texgetimage.c | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 85d0ffd4770..69521c5dd05 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -1004,8 +1004,31 @@ dimensions_error_check(struct gl_context *ctx,
 
texImage = select_tex_image(texObj, target, level, zoffset);
if (!texImage) {
-  /* missing texture image */
-  _mesa_error(ctx, GL_INVALID_OPERATION, "%s(missing image)", caller);
+  /* Trying to return a non-defined level is a valid operation per se, as
+   * OpenGL 4.6 spec, section 8.11.4 ("Texture Image Queries") does not
+   * handle this case as an error.
+   *
+   * Rather, we need to look at section 8.22 ("Texture State and Proxy
+   * State"):
+   *
+   *   "Each initial texture image is null. It has zero width, height, and
+   *depth, internal format RGBA, or R8 for buffer textures, component
+   *sizes set to zero and component types set to NONE, the compressed
+   *flag set to FALSE, a zero compressed size, and the bound buffer
+   *object name is zero."
+   *
+   * This means we need to assume the image for the non-defined level is
+   * an empty image. With this assumption, we can go back to section
+   * 8.11.4 and checking again the errors:
+   *
+   *   "An INVALID_VALUE error is generated if xoffset + width is greater
+   *than the texture’s width, yoffset + height is greater than the
+   *texture’s height, or zoffset + depth is greater than the texture’s
+   *depth."
+   *
+   * Thus why we return INVALID_VALUE.
+   */
+  _mesa_error(ctx, GL_INVALID_VALUE, "%s(missing image)", caller);
   return true;
}
 
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH 3/3] getteximage: assume texture image is empty for non defined levels

[Juan A. Suarez Romero]

On Thu, 2018-04-12 at 09:35 +0200, Iago Toral wrote:
> On Wed, 2018-04-11 at 19:51 +0200, Juan A. Suarez Romero wrote:
> > Current code is returning an INVALID_OPERATION when trying to use
> > getTextureImage() on a level that has not been explicitly defined.
> > 
> > That is, we define a mipmapped Texture2D with 3 levels, and try to
> > use
> > GetTextureImage() for the 4th levels, and INVALID_OPERATION is
> > returned.
> > 
> > Nevertheless, such case is not listed as an error in OpenGL 4.6 spec,
> > section 8.11.4 ("Texture Image Queries"), where all the case errors
> > for
> > this function are defined. So it seems this is a valid operation.
> 
> It says this:
> 
> An INVALID_VALUE error is generated if level is negative or larger than
> the maximum allowable level.
> 

The maximum allowable level is not the number of levels defined for the texture,
but rather a value that depends on the texture target. This maximum allowable
level is defined in section 8.11.3; specifically:

"level determines which level-of-detail’s state is returned. The maximum value
of level depends on the texture target:

- For targets TEXTURE_CUBE_MAP and TEXTURE_CUBE_MAP_ARRAY, the maximum value is
  log2 of the value of MAX_CUBE_MAP_TEXTURE_SIZE

- For target TEXTURE_3D , the maximum value is log2 of the value of
  MAX_3D_TEXTURE_SIZE

- For targets TEXTURE_BUFFER, TEXTURE_RECTANGLE, TEXTURE_2D_MULTISAMPLE, and
  TEXTURE_2D_MULTISAMPLE_ARRAY,  which do not support mipmaps, the maximum
  value is zero

- For  all  other  texture targets  supported  by GetTex*LevelParameter*, the
  maximum value is log2 of the value of MAX_TEXTURE_SIZE"

So this maximum allowable level defines how many levels the texture can have,
rather the number of levels it has.

> > On the other hand, in section 8.22 ("Texture State and Proxy State")
> > it
> > states:
> > 
> >   "Each initial texture image is null. It has zero width, height, and
> >depth, internal format RGBA, or R8 for buffer textures, component
> >sizes set to zero and component types set to NONE, the compressed
> >flag set to FALSE, a zero compressed size, and the bound buffer
> >object name is zero."
> > 
> > We can assume that we are reading this initialized empty image when
> > calling GetTextureImage() with a non defined level.
> 
> Based on the above, I think we should just change the error code to be
> INVALID_VALUE instead of INVALID_OPERATION.
> 

Yes, we could inmediately return with an INVALID_VALUE error. I choosed to not
do it to make it explicitly that the error is not because there is no image for
the level, but because it reaches the other error cases defined for the
function.

"An INVALID_VALUE error is generated if xoffset + width is greater than
the  texture’s  width, yoffset + height
is  greater  than  the  texture’s  height, or zoffset + depth is greater than
the texture’s depth."


As per private discussion, I'll send a new version of this patch to just return
inmediately the INVALID_VALUE error if the image is empty, adding a comment why
we return this error.


J.A.


> > With this assumption, we will reach one of the other error cases
> > defined
> > for the functions. At the end, this means that we will return a
> > different error to the caller.
> > 
> > This fixes arb_get_texture_sub_image piglit tests.
> > 
> > Signed-off-by: Juan A. Suarez Romero 
> > ---
> >  src/mesa/main/texgetimage.c | 23 +--
> >  1 file changed, 13 insertions(+), 10 deletions(-)
> > 
> > diff --git a/src/mesa/main/texgetimage.c
> > b/src/mesa/main/texgetimage.c
> > index 85d0ffd4770..0e4f030cb08 100644
> > --- a/src/mesa/main/texgetimage.c
> > +++ b/src/mesa/main/texgetimage.c
> > @@ -913,6 +913,7 @@ dimensions_error_check(struct gl_context *ctx,
> > const char *caller)
> >  {
> > const struct gl_texture_image *texImage;
> > +   GLuint image_width, image_height, image_depth;
> > int i;
> >  
> > if (xoffset < 0) {
> > @@ -1004,37 +1005,39 @@ dimensions_error_check(struct gl_context
> > *ctx,
> >  
> > texImage = select_tex_image(texObj, target, level, zoffset);
> > if (!texImage) {
> > -  /* missing texture image */
> > -  _mesa_error(ctx, GL_INVALID_OPERATION, "%s(missing image)",
> > caller);
> > -  return true;
> > +  /* missing texture image; continue as initialized as empty */
> > +  _mesa_warning(ctx, "%s(missing image)", caller);
> > }
> >  
> > -   if (xoffset + width > texImage->Width) {
> > +   image_width = texImage ? texImage->Width : 0;
> > +   if (xoffset + width > image_width) {
> >_mesa_error(ctx, GL_INVALID_VALUE,
> >"%s(xoffset %d + width %d > %u)",
> > -  caller, xoffset, width, texImage->Width);
> > +  caller, xoffset, width, image_width);
> >return true;
> > }
> >  
> > -   if (yoffset + height > texImage->Height) {
> > +   image_height = texImage ? texImage->Height : 0;
> > +   if (yoff

Re: [Mesa-dev] [RFC] Mesa release improvements - Release schedule

[Andres Gomez]

On Mon, 2018-03-12 at 16:00 +, Emil Velikov wrote:
> On 12 March 2018 at 14:35, Andres Gomez  wrote:
> > Hi,
> > 
> >  * Release schedule: move from pre-announce Wed, announcement Fri [0]
> >to pre-announce Mon, announcement Wed.
> > * Why would we want to do this?
> >* We have delays in the release every now and then. When this
> >  happens, we step already into the weekend which is bad for the
> >  release team but also for the developers of specific drivers
> >  who will have to test the patches in the queue before the
> >  actual release.
> >* Moving the dates to Mon and Wed gives a bigger margin to a
> >  delay without stepping into the weekend. It also gives a bit
> >  more of margin in case we found straight away that a release
> >  is problematic and needs immediate correction.
> > 
> > 
> 
> I believe that Ian/Carl had reasons for choosing Friday, although do
> not recall the details.
> I can see this proposal helping us, but it will be great if they can
> share their train of thought.
> 
> There could be something that we're missing ;-)
> 
> Obviously input from others is also appreciated.

No counter arguments so far. I'll send a patch to the doc for review
ASAP.

-- 
Br,

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

Re: [Mesa-dev] [PATCH 7/7] i965: Record mipmap resolver for unmapping

[Scott D Phillips]

Chris Wilson  writes:

> Quoting Scott D Phillips (2018-04-12 15:17:16)
>> Chris Wilson  writes:
>> 
>> > When mapping a region of the mipmap_tree, record which complementary
>> > method to use to unmap it afterwards. By doing so we can avoid
>> > duplicating the decision tree used when mapping and thereby eliminate
>> > trivial errors that can be introduced if the two if-chains become out of
>> > sync.
>> >
>> > Signed-off-by: Chris Wilson 
>> > Cc: Kenneth Graunke 
>> > Cc: Scott D Phillips 
>> 
>> for the series
>> 
>> Reviewed-by: Scott D Phillips 
>
> Does it fit into your work neatly, and if so do you want to submit them
> together? I was hoping having just one decision tree to update, should
> help the WC refactoring.

Yes, I do like this change for that series. I'll put my patches on top
of this and submit them together. Thanks for that,

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

Re: [Mesa-dev] [PATCH] miptree-map

[Scott D Phillips]

Chris Wilson  writes:

> Splitting intel_miptree_map() like so should help with the yuck factor.
> Though don't we also need to treat the stencil_mt to a similar treatment
> to avoid slow reads?

I didn't do that because stencil_mt is W tiled and our tiling functions
don't handle that. At the moment the best you can do is cross your
fingers and hope for a wb map. I guess we'll need to add W to the tiling
functions to really fix that slow part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/3] nir: add support for bindless_texture samplers

[Karol Herbst]

On Tue, Apr 10, 2018 at 5:10 PM, Jason Ekstrand  wrote:
> On Tue, Apr 10, 2018 at 8:05 AM, Karol Herbst  wrote:
>>
>> v2: add both texture and sampler handles
>>
>> Signed-off-by: Karol Herbst 
>> ---
>>  src/compiler/glsl/glsl_to_nir.cpp | 17 +++--
>>  src/compiler/nir/nir.h|  2 ++
>>  src/compiler/nir/nir_print.c  |  6 ++
>>  3 files changed, 23 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/compiler/glsl/glsl_to_nir.cpp
>> b/src/compiler/glsl/glsl_to_nir.cpp
>> index dbb58d82e8f..9f233637306 100644
>> --- a/src/compiler/glsl/glsl_to_nir.cpp
>> +++ b/src/compiler/glsl/glsl_to_nir.cpp
>> @@ -1971,6 +1971,8 @@ nir_visitor::visit(ir_texture *ir)
>>  {
>> unsigned num_srcs;
>> nir_texop op;
>> +   bool bindless =
>> ir->sampler->variable_referenced()->contains_bindless();
>
>
> What happens if I have a uniform struct containing both a regular sampler
> and a bindless sampler?  I think this should be possible.
>

well currently mesa just fails to compile, but even if it would I
don't see a way how we know with a ir_dereference if we reference a
bindless or bound sampler.

The glsl_type doesn't tell us either and maybe it makes sense to add a
is_bindless method to glsl_type so that we can use it in places like
here? ir->sampler->type gives me the sampler type, but lacks the
information if it is bindless or not. Any thoughts?

>>
>> +
>> switch (ir->op) {
>> case ir_tex:
>>op = nir_texop_tex;
>> @@ -2044,6 +2046,8 @@ nir_visitor::visit(ir_texture *ir)
>>num_srcs++;
>> if (ir->offset != NULL)
>>num_srcs++;
>> +   if (bindless)
>> +  num_srcs++;
>>
>> nir_tex_instr *instr = nir_tex_instr_create(this->shader, num_srcs);
>>
>> @@ -2069,10 +2073,19 @@ nir_visitor::visit(ir_texture *ir)
>>unreachable("not reached");
>> }
>>
>> -   instr->texture = evaluate_deref(&instr->instr, ir->sampler);
>> -
>> unsigned src_number = 0;
>>
>> +   /* for bindless we use the texture handle src */
>> +   if (bindless) {
>> +  instr->texture = NULL;
>> +  instr->src[src_number].src =
>> + nir_src_for_ssa(evaluate_rvalue(ir->sampler));
>> +  instr->src[src_number].src_type = nir_tex_src_texture_handle;
>> +  src_number++;
>> +   } else {
>> +  instr->texture = evaluate_deref(&instr->instr, ir->sampler);
>> +   }
>> +
>> if (ir->coordinate != NULL) {
>>instr->coord_components = ir->coordinate->type->vector_elements;
>>instr->src[src_number].src =
>> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
>> index f33049d7134..e395352f89c 100644
>> --- a/src/compiler/nir/nir.h
>> +++ b/src/compiler/nir/nir.h
>> @@ -1218,6 +1218,8 @@ typedef enum {
>> nir_tex_src_texture_offset, /* < dynamically uniform indirect offset
>> */
>> nir_tex_src_sampler_offset, /* < dynamically uniform indirect offset
>> */
>> nir_tex_src_plane,  /* < selects plane for planar textures */
>> +   nir_tex_src_texture_handle, /* < handle for bindless texture */
>> +   nir_tex_src_sampler_handle, /* < handle for bindless sampler */
>> nir_num_tex_src_types
>>  } nir_tex_src_type;
>>
>> diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
>> index 21f13097651..52f20b1eb10 100644
>> --- a/src/compiler/nir/nir_print.c
>> +++ b/src/compiler/nir/nir_print.c
>> @@ -778,6 +778,12 @@ print_tex_instr(nir_tex_instr *instr, print_state
>> *state)
>>case nir_tex_src_plane:
>>   fprintf(fp, "(plane)");
>>   break;
>> +  case nir_tex_src_texture_handle:
>> + fprintf(fp, "(texture_handle)");
>> + break;
>> +  case nir_tex_src_sampler_handle:
>> + fprintf(fp, "(sampler_handle)");
>> + break;
>>
>>default:
>>   unreachable("Invalid texture source type");
>> --
>> 2.14.3
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/7] i965: Record mipmap resolver for unmapping

[Chris Wilson]

Quoting Scott D Phillips (2018-04-12 15:17:16)
> Chris Wilson  writes:
> 
> > When mapping a region of the mipmap_tree, record which complementary
> > method to use to unmap it afterwards. By doing so we can avoid
> > duplicating the decision tree used when mapping and thereby eliminate
> > trivial errors that can be introduced if the two if-chains become out of
> > sync.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Kenneth Graunke 
> > Cc: Scott D Phillips 
> 
> for the series
> 
> Reviewed-by: Scott D Phillips 

Does it fit into your work neatly, and if so do you want to submit them
together? I was hoping having just one decision tree to update, should
help the WC refactoring.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/7] i965: Record mipmap resolver for unmapping

[Scott D Phillips]

Chris Wilson  writes:

> When mapping a region of the mipmap_tree, record which complementary
> method to use to unmap it afterwards. By doing so we can avoid
> duplicating the decision tree used when mapping and thereby eliminate
> trivial errors that can be introduced if the two if-chains become out of
> sync.
>
> Signed-off-by: Chris Wilson 
> Cc: Kenneth Graunke 
> Cc: Scott D Phillips 

for the series

Reviewed-by: Scott D Phillips 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/18] [RFC] Pointer specific data structures

[Erik Faye-Lund]

On Wed, Apr 11, 2018 at 8:48 PM, Thomas Helland
 wrote:
> This series came about when I saw a talk online, while simultaneously
> being annoyd about the needless waste of memory in our set as reported
> by pahole. I have previously made some patches that changed our hash
> table from a reprobing one to a quadratic probing one, in the name of
> lower overhead and better cache locality, but I was not quite satisfied.
>
> I'm sending this series out now, as it seems like an ideal time since
> Timothy is working at reducing our compile times. Further details about
> the implementation and its advantages are described in the patches.
> I've found this to give a reduction in shader-db runtime of about 2%,
> but I have to do some more testing on my main computer, as my laptop
> is showing its age with some terrible thermal issues.
>
> This special cases on pointers, as that is a very common usecase.
> This allows us to drop some comparisons, and reduce the total size
> of our hash table to 70% or our current and the set to 50%. It uses
> linear probing and power-of-two table sizes to get good cache locality.
> In the pointer_map caes it moves the stored hashes out into it's own
> array for even better cache locality.
>
> I'm not sure if we want another set and map amongst our utils,
> but the patch series is simple enough, and complete enough,
> that I thought I could share it for some inital comments.

This approach gives me a bad feeling. Using memory addresses for
storage ordering in a compiler is not quite nice; it can easily mask
spurious bugs, and have a compiler produce different result each run.
Such compilers are not nice to work with. I've seen *exactly* this
use-case go wrong in the past.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] mesa: include mtypes.h less

[Brian Paul]

On 04/11/2018 02:09 PM, Marek Olšák wrote:

From: Marek Olšák 

- remove mtypes.h from most header files
- add main/menums.h for often used definitions


FWIW, mtypes.h was originally types.h.  A long time ago, there was some 
obscure platform that had a /usr/include/types.h header and the compiler 
would errantly include it instead of Mesa's types.h.  So I renamed 
types.h to mtypes.h to work around that.


If you wanted to name the new file enums.h instead of menums.h that'd be 
OK.  No big deal though.


Otherwise, the series looks OK to me, though I see that Dylan found an 
issue.


Reviewed-by: Brian Paul 


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

[Mesa-dev] [Bug 48424] Fix warnings/errors reported by clang's scan-build tool

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #4 from Timothy Arceri  ---
Patches are always welcome and this is an on going issue I don't think we need
a bug to track this. Closing.

-- 
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 12365] Vegastrike not useable under Archlinux.

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Timothy Arceri  ---
Vegastrike works fine for me on i965. I suspect whatever the missing features
were, they were added long ago.

-- 
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 34495] Selecting objects in Blender 2.56 slow due the software gl_select mode

[bugzilla-daemon]

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

Eero Tamminen  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=62011

Timothy Arceri  changed:

   What|Removed |Added

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

-- 
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 85197] Fixes uclibc build as uclibc does not include backtrace functionality

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes
   |org |ktop.org
  Component|Other   |Drivers/DRI/i965

-- 
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 96543] N-Ball editor shows only a blackscreen

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from Timothy Arceri  ---
(In reply to Timothy Arceri from comment #4)
> The trace works for me even without the sb param on radeonsi. Assuming
> whatever it was has been fixed in the years since the report and closing.

Whoops thats was meant to say i965. Seems it doesn't work on radeonsi still.
Reopening.

-- 
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 96543] N-Ball editor shows only a blackscreen

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #4 from Timothy Arceri  ---
The trace works for me even without the sb param on radeonsi. Assuming whatever
it was has been fixed in the years since the report and 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] [Bug 93278] Configure should not have hardcoded list of {dri, gallium} drivers

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

-- 
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 95460] Please add more drivers (freedreno, virgl) to features.txt status document

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #7 from Timothy Arceri  ---
Please contact the etnaviv devs directly about this, ultimately its up to them
if they want to spend their time updating the features list. I don't think we
need to track this with a bug. 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

Re: [Mesa-dev] [PATCH] radv: always select the CS resolve path for integer formats

[Bas Nieuwenhuizen]

On Thu, Apr 12, 2018 at 1:20 PM, Samuel Pitoiset
 wrote:
> Both fixed resolve and FS resolve methods don't support integer
> formats, even if destination image is DCC compressed.
>
> No CTS changes on Vega, but this helps fixing some tests
> when DCC is enabled for MSAA textures.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_meta_resolve.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta_resolve.c 
> b/src/amd/vulkan/radv_meta_resolve.c
> index 1828eb37f46..deb75b9ff29 100644
> --- a/src/amd/vulkan/radv_meta_resolve.c
> +++ b/src/amd/vulkan/radv_meta_resolve.c
> @@ -354,12 +354,11 @@ static void radv_pick_resolve_method_images(struct 
> radv_image *src_image,
>
> cmd_buffer->queue_family_index);
>
> if (src_image->vk_format == VK_FORMAT_R16G16_UNORM ||
> -   src_image->vk_format == VK_FORMAT_R16G16_SNORM)
> +   src_image->vk_format == VK_FORMAT_R16G16_SNORM) {
> *method = RESOLVE_COMPUTE;
> -   else if (vk_format_is_int(src_image->vk_format))
> +   } else if (vk_format_is_int(src_image->vk_format)) {
> *method = RESOLVE_COMPUTE;

hmm, what happens if the destination image is DCC compressed and has
integer format? IIRC we did not modify compute resolves to handle that
yet?
> -
> -   if (radv_layout_dcc_compressed(dest_image, dest_image_layout, 
> queue_mask)) {
> +   } else if (radv_layout_dcc_compressed(dest_image, dest_image_layout, 
> queue_mask)) {
> *method = RESOLVE_FRAGMENT;
> } else if (dest_image->surface.micro_tile_mode != 
> src_image->surface.micro_tile_mode) {
> *method = RESOLVE_COMPUTE;
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 64791] swrast crashes with compiz

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #1 from Timothy Arceri  ---
Compiz and swrast are both dead projects. Closing as won't fix.

-- 
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 94383] build error on i386 when enabling swr

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

  Component|Other   |Drivers/Gallium/swr

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

[Mesa-dev] [Bug 99985] RFE: gbm needs a man page

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

-- 
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 98271] [radeonsi]Playing videos with vdpau or vaapi hardware acceleration crashes my pc

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
  Component|Other   |Drivers/Gallium/radeonsi

-- 
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 95338] build fails with python3 version of mako

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #2 from Timothy Arceri  ---
I'm pretty sure this is done now, either way its known and we don't need a bug
to track it. Closing.

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

[Mesa-dev] [Bug 91652] configure doesn't check for libedit

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

-- 
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 38172] Mesa build errors using build.sh script

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

-- 
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 29211] Recent Mesa breaks KDE with UMS too (previously only KMS was broken)

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

-- 
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 98595] glsl: ralloc assertion "info->canary == CANARY" failed

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|REOPENED|RESOLVED

-- 
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] [PATCH] radv: always select the CS resolve path for integer formats

[Samuel Pitoiset]

Both fixed resolve and FS resolve methods don't support integer
formats, even if destination image is DCC compressed.

No CTS changes on Vega, but this helps fixing some tests
when DCC is enabled for MSAA textures.

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

diff --git a/src/amd/vulkan/radv_meta_resolve.c 
b/src/amd/vulkan/radv_meta_resolve.c
index 1828eb37f46..deb75b9ff29 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -354,12 +354,11 @@ static void radv_pick_resolve_method_images(struct 
radv_image *src_image,
   
cmd_buffer->queue_family_index);
 
if (src_image->vk_format == VK_FORMAT_R16G16_UNORM ||
-   src_image->vk_format == VK_FORMAT_R16G16_SNORM)
+   src_image->vk_format == VK_FORMAT_R16G16_SNORM) {
*method = RESOLVE_COMPUTE;
-   else if (vk_format_is_int(src_image->vk_format))
+   } else if (vk_format_is_int(src_image->vk_format)) {
*method = RESOLVE_COMPUTE;
-   
-   if (radv_layout_dcc_compressed(dest_image, dest_image_layout, 
queue_mask)) {
+   } else if (radv_layout_dcc_compressed(dest_image, dest_image_layout, 
queue_mask)) {
*method = RESOLVE_FRAGMENT;
} else if (dest_image->surface.micro_tile_mode != 
src_image->surface.micro_tile_mode) {
*method = RESOLVE_COMPUTE;
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH 1/7] i965: Move unmap_gtt before map_gtt

[Samuel Iglesias Gonsálvez]

Patches 1-6 are,

Reviewed-by: Samuel Iglesias Gonsálvez 


On 12/04/18 02:10, Chris Wilson wrote:
> Reorder code to avoid a forward declaration in the next patch.
>
> Signed-off-by: Chris Wilson 
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 8d3ddd56544..f90d462b925 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -3080,6 +3080,12 @@ intel_miptree_unmap_raw(struct intel_mipmap_tree *mt)
> brw_bo_unmap(mt->bo);
>  }
>  
> +static void
> +intel_miptree_unmap_gtt(struct intel_mipmap_tree *mt)
> +{
> +   intel_miptree_unmap_raw(mt);
> +}
> +
>  static void
>  intel_miptree_map_gtt(struct brw_context *brw,
> struct intel_mipmap_tree *mt,
> @@ -3127,12 +3133,6 @@ intel_miptree_map_gtt(struct brw_context *brw,
> x, y, map->ptr, map->stride);
>  }
>  
> -static void
> -intel_miptree_unmap_gtt(struct intel_mipmap_tree *mt)
> -{
> -   intel_miptree_unmap_raw(mt);
> -}
> -
>  static void
>  intel_miptree_map_blit(struct brw_context *brw,
>  struct intel_mipmap_tree *mt,



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] [Mesa-announce] [ANNOUNCE] Mesa 17.3.9 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 17.3.9 is now available. Currently we have:
 - 23 queued
 - 0 nominated (outstanding)
 - and 0 rejected patches

NOTE: It is anticipated that 17.3.9 will be the final release in the
17.3 series. Users of 17.3 are encouraged to migrate to the 18.0 series
in order to obtain future fixes.

The current queue consists of:

Patches that clarify and fix issues regarding GL/GLES version overriding 
through environment variables.

AC get patches to use if/loop builder helpers, which increases the readability 
for LLVM IR dumps.
RadeonSI is beneficiated from this.

GLSL gets also some patches, including one to fix bugs related with loop 
unrolling.

RADV also gets a couple of fixes, one of them for a bug in Feral's game in VEGA.

Finally, there are other patches for NIR, st/dri, st/nine, spirv, and i965.

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


Testing reports/general approval

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

The plan is to have 17.3.9 this Monday (16th April), around or shortly after 
11:00
GMT.

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


Trivial merge conflicts
---

commit 0bb53b38aed1fc054e8514839db5c1fde2143d5f
Author: Timothy Arceri 

ac: make use of if/loop build helpers

(cherry picked from commit 99cdc019bf6fe11c135b7544ef6daf4ac964fa24)


commit 26aafd84b0913a2a83cc4b31dd36b8536d873691
Author: Timothy Arceri 

ac: add if/loop build helpers

(cherry picked from commit 42627dabb4db3011825a022325be7ae9b51103d6)


commit 9cd35f8aa6eccf634e9d8b34cde3bc72ea129a18
Author: Samuel Pitoiset 

radv: fix picking the method for resolve subpass

(cherry picked from commit 0babc8e5d665e54783c926b89183ab9a596aa04c)


Cheers,

J.A.



Mesa stable queue
-

Nominated (0)
==


Queued (23)
===

Andres Gomez (2):
  dri_util: when overriding, always reset the core version
  mesa: adds some comments regarding MESA_GLES_VERSION_OVERRIDE usage

Axel Davy (2):
  st/nine: Declare lighting consts for ff shaders
  st/nine: Do not use scratch for face register

Bas Nieuwenhuizen (1):
  ac/nir: Add workaround for GFX9 buffer views.

Daniel Stone (1):
  st/dri: Initialise modifier to INVALID for DRI2

Emil Velikov (1):
  glsl: remove unreachable assert()

Eric Engestrom (1):
  gbm: remove never-implemented function

Henri Verbeet (1):
  mesa: Inherit texture view multi-sample information from the original 
texture images.

Iago Toral Quiroga (1):
  compiler/spirv: set is_shadow for depth comparitor sampling opcodes

Jason Ekstrand (4):
  nir/vars_to_ssa: Remove copies from the correct set
  nir/lower_indirect_derefs: Support interp_var_at intrinsics
  intel/vec4: Set channel_sizes for MOV_INDIRECT sources
  nir/lower_vec_to_movs: Only coalesce if the vec had a SSA destination

Marek Olšák (1):
  mesa: simplify MESA_GL_VERSION_OVERRIDE behavior of API override

Samuel Pitoiset (1):
  radv: fix picking the method for resolve subpass

Sergii Romantsov (1):
  i965: Extend the negative 32-bit deltas to 64-bits

Timothy Arceri (5):
  gallium/pipebuffer: fix parenthesis location
  glsl: always call do_lower_jumps() after loop unrolling
  ac: add if/loop build helpers
  radeonsi: make use of if/loop build helpers in ac
  ac: make use of if/loop build helpers

Xiong, James (1):
  i965: return the fourcc saved in __DRIimage when possible


Rejected (0)
=


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

[Mesa-dev] [Bug 32211] [GLSL] lower_jumps with continue-statements in for-loops prevents loop unrolling

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

   Assignee|t_arc...@yahoo.com.au   |mesa-dev@lists.freedesktop.
   ||org

--- Comment #11 from Timothy Arceri  ---
With NIR we end up with :

loop {
block block_1:
/* preds: block_0 block_5 block_7 */
vec1 32 ssa_8 = phi block_0: ssa_3, block_5: ssa_4, block_7:
ssa_19
vec1 32 ssa_9 = phi block_0: ssa_2, block_5: ssa_17, block_7:
ssa_4
vec1 32 ssa_10 = phi block_0: ssa_1, block_5: ssa_4, block_7:
ssa_4
vec1 32 ssa_11 = phi block_0: ssa_0, block_5: ssa_4, block_7:
ssa_4
vec1 32 ssa_12 = phi block_0: ssa_4, block_5: ssa_16, block_7:
ssa_18
vec4 32 ssa_13 = vec4 ssa_8, ssa_9, ssa_10, ssa_11
vec1 32 ssa_14 = ige ssa_12, ssa_5
/* succs: block_2 block_3 */
if ssa_14 {
block block_2:
/* preds: block_1 */
break
/* succs: block_8 */
} else {
block block_3:
/* preds: block_1 */
/* succs: block_4 */
}
block block_4:
/* preds: block_3 */
vec1 32 ssa_15 = ilt ssa_6, ssa_12
/* succs: block_5 block_6 */
if ssa_15 {
block block_5:
/* preds: block_4 */
vec1 32 ssa_16 = iadd ssa_12, ssa_7
vec1 32 ssa_17 = load_const (0x3f80 /* 1.00 */)
continue
/* succs: block_1 */
} else {
block block_6:
/* preds: block_4 */
/* succs: block_7 */
}
block block_7:
/* preds: block_6 */
vec1 32 ssa_18 = iadd ssa_12, ssa_7
vec1 32 ssa_19 = load_const (0x3f80 /* 1.00 */)
/* succs: block_1 */
}

So all we need to do is move everything after the if into the else block and
remove the continue. Removing myself as assignee, this would probably be a good
beginners task.

-- 
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 105807] [Regression, bisected]: 3D Rendering not working correctly in Warhammer 40k: Dawn of War II

[bugzilla-daemon]

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

--- Comment #19 from Timothy Arceri  ---
(In reply to b...@besd.de from comment #18)
> Just confirmed that it works now.
> 
> Thanks!
> 
> Maybe this should be in stable too?

Fixes: a0c8b49284ef "mesa: enable OpenGL 3.1 with ARB_compatibility"

Means it will automatically get picked up by the stable scripts for inclusion
into any stable release that contains that commit.

-- 
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 3/3] getteximage: assume texture image is empty for non defined levels

[Iago Toral]

On Wed, 2018-04-11 at 19:51 +0200, Juan A. Suarez Romero wrote:
> Current code is returning an INVALID_OPERATION when trying to use
> getTextureImage() on a level that has not been explicitly defined.
> 
> That is, we define a mipmapped Texture2D with 3 levels, and try to
> use
> GetTextureImage() for the 4th levels, and INVALID_OPERATION is
> returned.
> 
> Nevertheless, such case is not listed as an error in OpenGL 4.6 spec,
> section 8.11.4 ("Texture Image Queries"), where all the case errors
> for
> this function are defined. So it seems this is a valid operation.

It says this:

An INVALID_VALUE error is generated if level is negative or larger than
the maximum allowable level.

> On the other hand, in section 8.22 ("Texture State and Proxy State")
> it
> states:
> 
>   "Each initial texture image is null. It has zero width, height, and
>depth, internal format RGBA, or R8 for buffer textures, component
>sizes set to zero and component types set to NONE, the compressed
>flag set to FALSE, a zero compressed size, and the bound buffer
>object name is zero."
> 
> We can assume that we are reading this initialized empty image when
> calling GetTextureImage() with a non defined level.

Based on the above, I think we should just change the error code to be
INVALID_VALUE instead of INVALID_OPERATION.

> With this assumption, we will reach one of the other error cases
> defined
> for the functions. At the end, this means that we will return a
> different error to the caller.
> 
> This fixes arb_get_texture_sub_image piglit tests.
> 
> Signed-off-by: Juan A. Suarez Romero 
> ---
>  src/mesa/main/texgetimage.c | 23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/src/mesa/main/texgetimage.c
> b/src/mesa/main/texgetimage.c
> index 85d0ffd4770..0e4f030cb08 100644
> --- a/src/mesa/main/texgetimage.c
> +++ b/src/mesa/main/texgetimage.c
> @@ -913,6 +913,7 @@ dimensions_error_check(struct gl_context *ctx,
> const char *caller)
>  {
> const struct gl_texture_image *texImage;
> +   GLuint image_width, image_height, image_depth;
> int i;
>  
> if (xoffset < 0) {
> @@ -1004,37 +1005,39 @@ dimensions_error_check(struct gl_context
> *ctx,
>  
> texImage = select_tex_image(texObj, target, level, zoffset);
> if (!texImage) {
> -  /* missing texture image */
> -  _mesa_error(ctx, GL_INVALID_OPERATION, "%s(missing image)",
> caller);
> -  return true;
> +  /* missing texture image; continue as initialized as empty */
> +  _mesa_warning(ctx, "%s(missing image)", caller);
> }
>  
> -   if (xoffset + width > texImage->Width) {
> +   image_width = texImage ? texImage->Width : 0;
> +   if (xoffset + width > image_width) {
>_mesa_error(ctx, GL_INVALID_VALUE,
>"%s(xoffset %d + width %d > %u)",
> -  caller, xoffset, width, texImage->Width);
> +  caller, xoffset, width, image_width);
>return true;
> }
>  
> -   if (yoffset + height > texImage->Height) {
> +   image_height = texImage ? texImage->Height : 0;
> +   if (yoffset + height > image_height) {
>_mesa_error(ctx, GL_INVALID_VALUE,
>"%s(yoffset %d + height %d > %u)",
> -  caller, yoffset, height, texImage->Height);
> +  caller, yoffset, height, image_height);
>return true;
> }
>  
> if (target != GL_TEXTURE_CUBE_MAP) {
>/* Cube map error checking was done above */
> -  if (zoffset + depth > texImage->Depth) {
> +  image_depth = texImage ? texImage->Depth : 0;
> +  if (zoffset + depth > image_depth) {
>   _mesa_error(ctx, GL_INVALID_VALUE,
>   "%s(zoffset %d + depth %d > %u)",
> - caller, zoffset, depth, texImage->Depth);
> + caller, zoffset, depth, image_depth);
>   return true;
>}
> }
>  
> /* Extra checks for compressed textures */
> -   {
> +   if (texImage) {
>GLuint bw, bh, bd;
>_mesa_get_format_block_size_3d(texImage->TexFormat, &bw, &bh,
> &bd);
>if (bw > 1 || bh > 1 || bd > 1) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105995] egl driver dri2 on wayland platform can't choose config with EGL_SURFACE_TYPE, EGL_PBUFFER_BIT

[bugzilla-daemon]

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

--- Comment #6 from Errong  ---
(In reply to Daniel Stone from comment #5)
> Pixmap surfaces can never be supported on Wayland, as there is no native
> pixmap type defined by Wayland.
> 
> FBOs are framebuffer objects, which allow the same thing (offscreen
> rendering) as pbuffers, but far more flexible, performant, and more widely
> supported.
> 
> Here are some resources explaining the basics of FBOs:
> https://www.khronos.org/opengl/wiki/Framebuffer_Object
> https://learnopengl.com/Advanced-OpenGL/Framebuffers

Ok. I got it.
Thank you very much.

-- 
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] [PATCH 1/3] gettextsubimage: verify zoffset and depth are correct

[Iago Toral]

Patches 1-2 are:
Reviewed-by: Iago Toral Quiroga 

On Wed, 2018-04-11 at 19:51 +0200, Juan A. Suarez Romero wrote:
> According to OpenGL 4.6 spec, section 8.11.4 ("Texture Image
> Queries"),
> relative to errors for GetTextureSubImage() function:
> 
>   "An INVALID_VALUE error is generated if the effective target is
>TEXTURE_1D and either yoffset is not zero, or height is not one.
> 
>An INVALID_VALUE error is generated if the effective target is
>TEXTURE_1D, TEXTURE_1D_ARRAY, TEXTURE_2D or TEXTURE_RECTANGLE, and
>either zoffset is not zero, or depth is not one."
> 
> The commit fixes the check for height and depth.
> 
> This fixes arb_get_texture_sub_image piglit tests.
> 
> Signed-off-by: Juan A. Suarez Romero 
> ---
>  src/mesa/main/texgetimage.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/main/texgetimage.c
> b/src/mesa/main/texgetimage.c
> index c61842e39ad..fbdbcd90a7d 100644
> --- a/src/mesa/main/texgetimage.c
> +++ b/src/mesa/main/texgetimage.c
> @@ -953,7 +953,7 @@ dimensions_error_check(struct gl_context *ctx,
>   "%s(1D, yoffset = %d)", caller, yoffset);
>   return true;
>}
> -  if (height > 1) {
> +  if (height != 1) {
>   _mesa_error(ctx, GL_INVALID_VALUE,
>   "%s(1D, height = %d)", caller, height);
>   return true;
> @@ -967,7 +967,7 @@ dimensions_error_check(struct gl_context *ctx,
>   "%s(zoffset = %d)", caller, zoffset);
>   return true;
>}
> -  if (depth > 1) {
> +  if (depth != 1) {
>   _mesa_error(ctx, GL_INVALID_VALUE,
>   "%s(depth = %d)", caller, depth);
>   return true;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/10] spirv: Update spirv.h to 12f8de9f04327336b699b1b80aa390ae7f9ddbf4

[Samuel Pitoiset]

Acked-by: Samuel Pitoiset 

On 04/12/2018 01:44 AM, Bas Nieuwenhuizen wrote:

---
  src/compiler/spirv/spirv.core.grammar.json | 169 -
  src/compiler/spirv/spirv.h |  18 +++
  2 files changed, 183 insertions(+), 4 deletions(-)

diff --git a/src/compiler/spirv/spirv.core.grammar.json 
b/src/compiler/spirv/spirv.core.grammar.json
index f3994a60358..a03c024335c 100644
--- a/src/compiler/spirv/spirv.core.grammar.json
+++ b/src/compiler/spirv/spirv.core.grammar.json
@@ -3144,6 +3144,7 @@
  { "kind" : "IdRef", "name" : "'Target'" },
  { "kind" : "Decoration" }
],
+  "extensions" : [ "SPV_GOOGLE_hlsl_functionality1" ],
"version" : "1.2"
  },
  {
@@ -3602,7 +3603,9 @@
  { "kind" : "IdResult" },
  { "kind" : "IdRef", "name" : "'Predicate'" }
],
-  "capabilities" : [ "SubgroupBallotKHR" ]
+  "capabilities" : [ "SubgroupBallotKHR" ],
+  "extensions" : [ "SPV_KHR_shader_ballot" ],
+  "version" : "None"
  },
  {
"opname" : "OpSubgroupFirstInvocationKHR",
@@ -3612,7 +3615,9 @@
  { "kind" : "IdResult" },
  { "kind" : "IdRef", "name" : "'Value'" }
],
-  "capabilities" : [ "SubgroupBallotKHR" ]
+  "capabilities" : [ "SubgroupBallotKHR" ],
+  "extensions" : [ "SPV_KHR_shader_ballot" ],
+  "version" : "None"
  },
  {
"opname" : "OpSubgroupAllKHR",
@@ -3666,6 +3671,7 @@
  { "kind" : "IdRef", "name" : "'Index'" }
],
"capabilities" : [ "SubgroupBallotKHR" ],
+  "extensions" : [ "SPV_KHR_shader_ballot" ],
"version" : "None"
  },
  {
@@ -3679,6 +3685,7 @@
  { "kind" : "IdRef",  "name" : "'X'" }
],
"capabilities" : [ "Groups" ],
+  "extensions" : [ "SPV_AMD_shader_ballot" ],
"version" : "None"
  },
  {
@@ -3692,6 +3699,7 @@
  { "kind" : "IdRef",  "name" : "'X'" }
],
"capabilities" : [ "Groups" ],
+  "extensions" : [ "SPV_AMD_shader_ballot" ],
"version" : "None"
  },
  {
@@ -3705,6 +3713,7 @@
  { "kind" : "IdRef",  "name" : "'X'" }
],
"capabilities" : [ "Groups" ],
+  "extensions" : [ "SPV_AMD_shader_ballot" ],
"version" : "None"
  },
  {
@@ -3718,6 +3727,7 @@
  { "kind" : "IdRef",  "name" : "'X'" }
],
"capabilities" : [ "Groups" ],
+  "extensions" : [ "SPV_AMD_shader_ballot" ],
"version" : "None"
  },
  {
@@ -3731,6 +3741,7 @@
  { "kind" : "IdRef",  "name" : "'X'" }
],
"capabilities" : [ "Groups" ],
+  "extensions" : [ "SPV_AMD_shader_ballot" ],
"version" : "None"
  },
  {
@@ -3744,6 +3755,7 @@
  { "kind" : "IdRef",  "name" : "'X'" }
],
"capabilities" : [ "Groups" ],
+  "extensions" : [ "SPV_AMD_shader_ballot" ],
"version" : "None"
  },
  {
@@ -3757,6 +3769,7 @@
  { "kind" : "IdRef",  "name" : "'X'" }
],
"capabilities" : [ "Groups" ],
+  "extensions" : [ "SPV_AMD_shader_ballot" ],
"version" : "None"
  },
  {
@@ -3770,6 +3783,7 @@
  { "kind" : "IdRef",  "name" : "'X'" }
],
"capabilities" : [ "Groups" ],
+  "extensions" : [ "SPV_AMD_shader_ballot" ],
"version" : "None"
  },
  {
@@ -3782,6 +3796,7 @@
  { "kind" : "IdRef", "name" : "'Coordinate'" }
],
"capabilities" : [ "FragmentMaskAMD" ],
+  "extensions" : [ "SPV_AMD_shader_fragment_mask" ],
"version" : "None"
  },
  {
@@ -3795,6 +3810,7 @@
  { "kind" : "IdRef", "name" : "'Fragment Index'" }
],
"capabilities" : [ "FragmentMaskAMD" ],
+  "extensions" : [ "SPV_AMD_shader_fragment_mask" ],
"version" : "None"
  },
  {
@@ -3911,6 +3927,18 @@
],
"extensions" : [ "SPV_GOOGLE_decorate_string" ],
"version" : "None"
+},
+{
+  "opname" : "OpGroupNonUniformPartitionNV",
+  "opcode" : 5296,
+  "operands" : [
+{ "kind" : "IdResultType" },
+{ "kind" : "IdResult" },
+{ "kind" : "IdRef", "name" : "'Value'" }
+  ],
+  "capabilities" : [ "GroupNonUniformPartitionedNV" ],
+  "extensions" : [ "SPV_NV_shader_subgroup_partitioned" ],
+  "version" : "None"
  }
],
"operand_kinds" : [
@@ -4541,12 +4569,14 @@
"enumerant" : "PostDepthCoverage",
"value" : 4446,
"capabilities" : [ "SampleMaskPostDepthCoverage" ],
+  "extensions" : [ "SPV_KHR_post_depth_coverage" ],
"version" : "None"
  },
  {
"enumerant" : "StencilRefReplacingEXT",
"value" : 5027,
"capabilities" : [ "StencilExportEXT" ],
+  "extensions" : [ "SPV_EXT_shader_stencil_export" ],
"version" : "None"
 

Re: [Mesa-dev] [PATCH] radv: Implement VK_EXT_vertex_attribute_divisor.

[Samuel Pitoiset]

Looks good to me, do you have tests?

Reviewed-by: Samuel Pitoiset 

On 04/12/2018 01:45 AM, Bas Nieuwenhuizen wrote:

Pretty straight forward, just pass the divisors through the shader
key and then do a LLVM divide.
---
  src/amd/vulkan/radv_device.c  |  6 ++
  src/amd/vulkan/radv_extensions.py |  1 +
  src/amd/vulkan/radv_nir_to_llvm.c | 26 +++---
  src/amd/vulkan/radv_pipeline.c| 26 ++
  src/amd/vulkan/radv_private.h |  1 +
  src/amd/vulkan/radv_shader.h  |  1 +
  6 files changed, 50 insertions(+), 11 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 41f8242754c..4cd24eb2e96 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -961,6 +961,12 @@ void radv_GetPhysicalDeviceProperties2(
properties->filterMinmaxSingleComponentFormats = true;
break;
}
+   case 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT: {
+   VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT 
*properties =
+   
(VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT *)ext;
+   properties->maxVertexAttribDivisor = UINT32_MAX;
+   break;
+   }
default:
break;
}
diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index bc63a34896a..48cf3ccd992 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -93,6 +93,7 @@ EXTENSIONS = [
  Extension('VK_EXT_global_priority',   1, 
'device->rad_info.has_ctx_priority'),
  Extension('VK_EXT_sampler_filter_minmax', 1, 
'device->rad_info.chip_class >= CIK'),
  Extension('VK_EXT_shader_viewport_index_layer',   1, True),
+Extension('VK_EXT_vertex_attribute_divisor',  1, True),
  Extension('VK_AMD_draw_indirect_count',   1, True),
  Extension('VK_AMD_gcn_shader',1, True),
  Extension('VK_AMD_rasterization_order',   1, 
'device->has_out_of_order_rast'),
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index 2f0864da462..a6b48e297da 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -1794,14 +1794,26 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
  
  	for (unsigned i = 0; i < attrib_count; ++i, ++idx) {

if (ctx->options->key.vs.instance_rate_inputs & (1u << (index + 
i))) {
-   buffer_index = LLVMBuildAdd(ctx->ac.builder, 
ctx->abi.instance_id,
-   ctx->abi.start_instance, 
"");
-   if (ctx->options->key.vs.as_ls) {
-   ctx->shader_info->vs.vgpr_comp_cnt =
-   MAX2(2, 
ctx->shader_info->vs.vgpr_comp_cnt);
+   uint32_t divisor = 
ctx->options->key.vs.instance_rate_divisors[index + i];
+
+   if (divisor) {
+   buffer_index = LLVMBuildAdd(ctx->ac.builder, 
ctx->abi.instance_id,
+   ctx->abi.start_instance, 
"");
+
+   if (divisor != 1) {
+   buffer_index = 
LLVMBuildUDiv(ctx->ac.builder, buffer_index,
+
LLVMConstInt(ctx->ac.i32, divisor, 0), "");
+   }
+
+   if (ctx->options->key.vs.as_ls) {
+   ctx->shader_info->vs.vgpr_comp_cnt =
+   MAX2(2, 
ctx->shader_info->vs.vgpr_comp_cnt);
+   } else {
+   ctx->shader_info->vs.vgpr_comp_cnt =
+   MAX2(1, 
ctx->shader_info->vs.vgpr_comp_cnt);
+   }
} else {
-   ctx->shader_info->vs.vgpr_comp_cnt =
-   MAX2(1, 
ctx->shader_info->vs.vgpr_comp_cnt);
+   buffer_index = ctx->ac.i32_0;
}
} else
buffer_index = LLVMBuildAdd(ctx->ac.builder, 
ctx->abi.vertex_id,
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 08abb9dbc47..91baac431b8 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1743,22 +1743,38 @@ radv_generate_graphics_pipeline_key(struct 
radv_pipeline *pipeline,
  {
const VkPipelineVertexInputStateCreateInfo *input_state =
 pCreateInfo->pVert

[Mesa-dev] [Bug 105995] egl driver dri2 on wayland platform can't choose config with EGL_SURFACE_TYPE, EGL_PBUFFER_BIT

[bugzilla-daemon]

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

--- Comment #5 from Daniel Stone  ---
Pixmap surfaces can never be supported on Wayland, as there is no native pixmap
type defined by Wayland.

FBOs are framebuffer objects, which allow the same thing (offscreen rendering)
as pbuffers, but far more flexible, performant, and more widely supported.

Here are some resources explaining the basics of FBOs:
https://www.khronos.org/opengl/wiki/Framebuffer_Object
https://learnopengl.com/Advanced-OpenGL/Framebuffers

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