[Mesa-dev] [Bug 105412] [OpenGL] [HD 7790] - VSYNC always ON in all videogames

[bugzilla-daemon]

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

--- Comment #5 from Vasya  ---
(In reply to Matias N. Goldberg from comment #2)
> Thus I should write:
> xrandr --output HDMI-A-0 --set TearFree off
I also HDMI-0 output, but this command doesn't give any effect
> This could be caused by the Ubuntu's Unity Compositor (Compiz).
> You could try forcing VSync off in one of Compiz config/tweak tools.
VSync is disabled in Compiz.

In kernel <=4.09 VSync is correctly disabled in every video-game if appropriate
checkbox is unset. But for kernels above 4.09 appropriate checkbox in the game
has no effect. VSync ALWAYS ON!

-- 
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 105412] [OpenGL] [HD 7790] - VSYNC always ON in all videogames

[bugzilla-daemon]

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

--- Comment #4 from Vasya  ---
Created attachment 137955
  --> https://bugs.freedesktop.org/attachment.cgi?id=137955=edit
glxinfo results

-- 
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 105412] [OpenGL] [HD 7790] - VSYNC always ON in all videogames

[bugzilla-daemon]

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

--- Comment #3 from Vasya  ---
Created attachment 137954
  --> https://bugs.freedesktop.org/attachment.cgi?id=137954=edit
X.ORG log

-- 
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 105171] performance regression (3x slower) running glamor with PutImage workload (radeonsi)

[bugzilla-daemon]

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

--- Comment #9 from Clemens Eisserer  ---
So, shmput10 is now equally fast with Mesa-17.3.6 and Mesa-27.2.4 - however the
real-world workload still suffers.

Please have a look at http://93.83.133.214/downloads/JXRenderMark-1.0.1.zip -
it is a stand-alone benchmark which emulates the XRender sequences generated by
the Java XRender backend.

CentOS-7 + updates (Mesa 17.0.1):
./render 3 32 3 32 3 32 3 32 3 32 3 32 3 32
18621.335408 Ops/s; put composition (!); 32x32
18901.781304 Ops/s; put composition (!); 32x32
18903.572785 Ops/s; put composition (!); 32x32

Fedora 27 + updates (Mesa 17.3.6):
./render 3 32 3 32 3 32 3 32 3 32 3 32 3 32
[ce@localhost temp]$ ./JXRenderMark-1.0.1 3 32 3 32 3 32 3 32 3 32 3 32
6938.738245 Ops/s; put composition (!); 32x32
6825.050537 Ops/s; put composition (!); 32x32
6955.692404 Ops/s; put composition (!); 32x32

So there it is ... the slowdown of factor 2,5 :/

-- 
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] i965: Emit texture cache invalidates around blorp_copy

[Jason Ekstrand]

This is a terrible hack but it fixes CTS regressions.  It's still
incredibly unclear exactly what is going wrong in the hardware to cause
this to be an issue so this isn't a good fix by any means.  However, it
does fix tests so there is that.

Fixes: fb0e9b5197 "i965: Track the depth and render caches separately"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103746
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 1d586e5..72c5d19 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -428,6 +428,18 @@ brw_blorp_copy_miptrees(struct brw_context *brw,
blorp_surf_for_miptree(brw, _surf, dst_mt, dst_aux_usage, true,
   _level, dst_layer, 1, _surfs[1]);
 
+   /* The hardware seems to have issues with having a two different format
+* views of the same texture in the sampler cache at the same time.  It's
+* unclear exactly what the issue is but it hurts glCopyImageSubData
+* particularly badly because it does a lot of format reinterprets.  We
+* badly need better understanding of the issue and a better fix but this
+* works for now and fixes CTS tests.
+*
+* TODO: Remove this hack!
+*/
+   brw_emit_pipe_control_flush(brw, PIPE_CONTROL_CS_STALL |
+PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE);
+
struct blorp_batch batch;
blorp_batch_init(>blorp, , brw, 0);
blorp_copy(, _surf, src_level, src_layer,
@@ -435,6 +447,9 @@ brw_blorp_copy_miptrees(struct brw_context *brw,
   src_x, src_y, dst_x, dst_y, src_width, src_height);
blorp_batch_finish();
 
+   brw_emit_pipe_control_flush(brw, PIPE_CONTROL_CS_STALL |
+PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE);
+
intel_miptree_finish_write(brw, dst_mt, dst_level, dst_layer, 1,
   dst_aux_usage);
 }
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH] r600: implement callstack workaround for evergreen.

[Roland Scheidegger]

Looks great to me. (I think I even mentioned it looked odd to me that
stack workarounds looked different on non-sb when I extended the sb
workaround logic to exclude hemlock...)

Reviewed-by: Roland Scheidegger 

Am 09.03.2018 um 07:09 schrieb Dave Airlie:
> From: Dave Airlie 
> 
> This is ported from the sb backend, there are some issues with
> evergreen stacks on the boundary between entries and ALU_PUSH_BEFORE
> instructions.
> 
> Whenever we are going to use a push before, we check the stack
> usage and if we have to use the workaround, then we switch to
> a separate push.
> 
> I noticed this problem dealing with some of the soft fp64 shaders,
> in nosb mode, they are quite stack happy.
> 
> This fixes all the glitches and inconsistencies I've seen with them
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/drivers/r600/r600_shader.c | 39 
> +++---
>  1 file changed, 31 insertions(+), 8 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/r600_shader.c 
> b/src/gallium/drivers/r600/r600_shader.c
> index 48750fb..3ca7890 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -377,7 +377,7 @@ struct r600_shader_tgsi_instruction {
>  static int emit_gs_ring_writes(struct r600_shader_ctx *ctx, const struct 
> pipe_stream_output_info *so, int stream, bool ind);
>  static const struct r600_shader_tgsi_instruction 
> r600_shader_tgsi_instruction[], eg_shader_tgsi_instruction[], 
> cm_shader_tgsi_instruction[];
>  static int tgsi_helper_tempx_replicate(struct r600_shader_ctx *ctx);
> -static inline void callstack_push(struct r600_shader_ctx *ctx, unsigned 
> reason);
> +static inline int callstack_push(struct r600_shader_ctx *ctx, unsigned 
> reason);
>  static void fc_pushlevel(struct r600_shader_ctx *ctx, int type);
>  static int tgsi_else(struct r600_shader_ctx *ctx);
>  static int tgsi_endif(struct r600_shader_ctx *ctx);
> @@ -393,6 +393,15 @@ static void r600_bytecode_src(struct 
> r600_bytecode_alu_src *bc_src,
>  static int do_lds_fetch_values(struct r600_shader_ctx *ctx, unsigned 
> temp_reg,
>  unsigned dst_reg, unsigned mask);
>  
> +static bool ctx_needs_stack_workaround_8xx(struct r600_shader_ctx *ctx)
> +{
> + if (ctx->bc->family == CHIP_HEMLOCK ||
> + ctx->bc->family == CHIP_CYPRESS ||
> + ctx->bc->family == CHIP_JUNIPER)
> + return false;
> + return true;
> +}
> +
>  static bool ctx_has_doubles(struct r600_shader_ctx *ctx)
>  {
>   if (ctx->bc->family == CHIP_ARUBA ||
> @@ -10182,7 +10191,7 @@ static int pops(struct r600_shader_ctx *ctx, int pops)
>   return 0;
>  }
>  
> -static inline void callstack_update_max_depth(struct r600_shader_ctx *ctx,
> +static inline int callstack_update_max_depth(struct r600_shader_ctx *ctx,
>unsigned reason)
>  {
>   struct r600_stack_info *stack = >bc->stack;
> @@ -10200,7 +10209,7 @@ static inline void callstack_update_max_depth(struct 
> r600_shader_ctx *ctx,
>   /* pre-r8xx: if any non-WQM PUSH instruction is invoked, 2 
> elements on
>* the stack must be reserved to hold the current 
> active/continue
>* masks */
> - if (reason == FC_PUSH_VPM) {
> + if (reason == FC_PUSH_VPM || stack->push > 0) {
>   elements += 2;
>   }
>   break;
> @@ -10226,7 +10235,7 @@ static inline void callstack_update_max_depth(struct 
> r600_shader_ctx *ctx,
>*NOTE: it seems we also need to reserve additional element 
> in some
>*other cases, e.g. when we have 4 levels of PUSH_VPM in 
> the shader,
>*then STACK_SIZE should be 2 instead of 1 */
> - if (reason == FC_PUSH_VPM) {
> + if (reason == FC_PUSH_VPM || stack->push > 0) {
>   elements += 1;
>   }
>   break;
> @@ -10245,6 +10254,7 @@ static inline void callstack_update_max_depth(struct 
> r600_shader_ctx *ctx,
>  
>   if (entries > stack->max_entries)
>   stack->max_entries = entries;
> + return elements;
>  }
>  
>  static inline void callstack_pop(struct r600_shader_ctx *ctx, unsigned 
> reason)
> @@ -10268,7 +10278,7 @@ static inline void callstack_pop(struct 
> r600_shader_ctx *ctx, unsigned reason)
>   }
>  }
>  
> -static inline void callstack_push(struct r600_shader_ctx *ctx, unsigned 
> reason)
> +static inline int callstack_push(struct r600_shader_ctx *ctx, unsigned 
> reason)
>  {
>   switch (reason) {
>   case FC_PUSH_VPM:
> @@ -10276,6 +10286,7 @@ static inline void callstack_push(struct 
> r600_shader_ctx *ctx, unsigned reason)
>   break;
>   case FC_PUSH_WQM:
>   ++ctx->bc->stack.push_wqm;
> + break;
>   case FC_LOOP:
>   

[Mesa-dev] [PATCH] u_blit: (trivial) u_blit.h needs to include p_defines.h

[sroland]

From: Roland Scheidegger 

(For the pipe_tex_filter enum)
---
 src/gallium/auxiliary/util/u_blit.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/auxiliary/util/u_blit.h 
b/src/gallium/auxiliary/util/u_blit.h
index 085ea63..004ceae 100644
--- a/src/gallium/auxiliary/util/u_blit.h
+++ b/src/gallium/auxiliary/util/u_blit.h
@@ -31,6 +31,7 @@
 
 
 #include "pipe/p_compiler.h"
+#include "pipe/p_defines.h"
 
 
 #ifdef __cplusplus
-- 
2.7.4

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

[Mesa-dev] [PATCH] intel/tools: aubinator: Catch gen11 "enhanced execlist" submission

[Scott D Phillips]

Different registers are used for execlist submission in gen11, so
also watch those. This code only watches element zero of the
submit queue, which is all aubdump currently writes.
---
 src/intel/tools/aubinator.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 77bad29051e..8029dc12155 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -248,6 +248,9 @@ handle_memtrace_reg_write(uint32_t *p)
int engine;
static int render_elsp_writes = 0;
static int blitter_elsp_writes = 0;
+   static int render_elsq0 = 0;
+   static int blitter_elsq0 = 0;
+   uint8_t *pphwsp;
 
if (offset == 0x2230) {
   render_elsp_writes++;
@@ -255,18 +258,29 @@ handle_memtrace_reg_write(uint32_t *p)
} else if (offset == 0x22230) {
   blitter_elsp_writes++;
   engine = GEN_ENGINE_BLITTER;
+   } else if (offset == 0x2510) {
+  render_elsq0 = value;
+   } else if (offset == 0x22510) {
+  blitter_elsq0 = value;
+   } else if (offset == 0x2550 || offset == 0x22550) {
+  /* nothing */;
} else {
   return;
}
 
-   if (render_elsp_writes > 3)
-  render_elsp_writes = 0;
-   else if (blitter_elsp_writes > 3)
-  blitter_elsp_writes = 0;
-   else
+   if (render_elsp_writes > 3 || blitter_elsp_writes > 3) {
+  render_elsp_writes = blitter_elsp_writes = 0;
+  pphwsp = (uint8_t*)gtt + (value & 0xf000);
+   } else if (offset == 0x2550) {
+  engine = GEN_ENGINE_RENDER;
+  pphwsp = (uint8_t*)gtt + (render_elsq0 & 0xf000);
+   } else if (offset == 0x22550) {
+  engine = GEN_ENGINE_BLITTER;
+  pphwsp = (uint8_t*)gtt + (blitter_elsq0 & 0xf000);
+   } else {
   return;
+   }
 
-   uint8_t *pphwsp = (uint8_t*)gtt + (value & 0xf000);
const uint32_t pphwsp_size = 4096;
uint32_t *context = (uint32_t*)(pphwsp + pphwsp_size);
uint32_t ring_buffer_head = context[5];
-- 
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/5] intel/dev: Add devinfo cs_scratch_ids_per_subslice field

[Kenneth Graunke]

On Wednesday, March 7, 2018 12:36:02 PM PST Jordan Justen wrote:
> On 2018-03-07 00:47:12, Kenneth Graunke wrote:
> > On Wednesday, March 7, 2018 12:16:28 AM PST Jordan Justen wrote:
> > > Suggested-by: Kenneth Graunke 
> > > Signed-off-by: Jordan Justen 
> > > ---
> > >  src/intel/dev/gen_device_info.c | 13 -
> > >  src/intel/dev/gen_device_info.h |  8 
> > >  2 files changed, 16 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/src/intel/dev/gen_device_info.c 
> > > b/src/intel/dev/gen_device_info.c
> > > index 1773009d33c..de018c6a692 100644
> > > --- a/src/intel/dev/gen_device_info.c
> > > +++ b/src/intel/dev/gen_device_info.c
> > > @@ -284,11 +284,13 @@ static const struct gen_device_info 
> > > gen_device_info_byt = {
> > > },
> > >  };
> > >  
> > > -#define HSW_FEATURES \
> > > -   GEN7_FEATURES,\
> > > -   .is_haswell = true,   \
> > > -   .supports_simd16_3src = true, \
> > > -   .has_resource_streamer = true
> > > +#define HSW_FEATURES \
> > > +   GEN7_FEATURES,\
> > > +   .is_haswell = true,   \
> > > +   .supports_simd16_3src = true, \
> > > +   .has_resource_streamer = true,\
> > > +   /* WaCSScratchSize:hsw */ \
> > > +   .cs_scratch_ids_per_subslice = 16 * 8
> > >  
> > >  static const struct gen_device_info gen_device_info_hsw_gt1 = {
> > > HSW_FEATURES, .gt = 1,
> > > @@ -476,6 +478,7 @@ static const struct gen_device_info 
> > > gen_device_info_chv = {
> > > .max_gs_threads = 80,
> > > .max_wm_threads = 128,
> > > .max_cs_threads = 6 * 7,
> > > +   .cs_scratch_ids_per_subslice = 8 * 7,
> > > .urb = {
> > >.size = 192,
> > >.min_entries = {
> > > diff --git a/src/intel/dev/gen_device_info.h 
> > > b/src/intel/dev/gen_device_info.h
> > > index b8044d00032..fa6b38f19ec 100644
> > > --- a/src/intel/dev/gen_device_info.h
> > > +++ b/src/intel/dev/gen_device_info.h
> > > @@ -148,6 +148,14 @@ struct gen_device_info
> > >  */
> > > unsigned max_cs_threads;
> > >  
> > > +   /**
> > > +* The range of scratch addresses may differ from the number of EUs
> > > +* available for compute programs. This requires allocating a larger
> > > +* scratch buffer. For affected hardware, this will be set. If this 
> > > is not
> > > +* set, then max_cs_threads should be used instead.
> > > +*/
> > > +   unsigned cs_scratch_ids_per_subslice;
> > > +
> > > struct {
> > >/**
> > > * Hardware default URB size.
> > > 
> > 
> > This works, but it's not quite what I had in mind.  I was thinking you
> > would add the new field, then add this hunk to gen_get_device_info():
> > 
> >if (devinfo->is_haswell) {
> >   /* WaCSScratchSize:hsw
> >*
> >* Haswell's scratch space address calculation appears to be sparse
> >* rather than tightly packed. The Thread ID has bits indicating
> >* which subslice, EU within a subslice, and thread within an EU it
> >* is. There's a maximum of two slices and two subslices, so these
> >* can be stored with a single bit. Even though there are only 10 EUs
> >* per subslice, this is stored in 4 bits, so there's an effective
> >* maximum value of 16 EUs. Similarly, although there are only 7
> >* threads per EU, this is stored in a 3 bit number, giving an
> >* effective maximum value of 8 threads per EU.
> >*
> >* This means that we need to use 16 * 8 instead of 10 * 7 for the
> >* number of threads per subslice.
> >*/
> >   devinfo->cs_scratch_ids_per_subslice = 16 * 8;
> >} else if (devinfo->is_cherryview) {
> >   /* For Cherryview, it appears that the scratch addresses for the 6 EU
> >* devices may still generate compute scratch addresses covering the
> >* same range as 8 EU.
> >*/
> >   devinfo->cs_scratch_ids_per_subslice = 8 * 7;
> >} else {
> >   devinfo->cs_scratch_ids_per_subslice = devinfo->max_cs_threads;
> >}
> 
> Originally, I had initialized them in the structures, and then had:
> 
>if (devinfo->cs_scratch_ids_per_subslice == 0)
>   devinfo->cs_scratch_ids_per_subslice = devinfo->max_cs_threads;
> 
> I used it directly, like you mentioned below.
> 
> Then I got concerned about how the kernel params might update
> max_cs_threads, and should that cause cs_scratch_ids_per_subslice to
> be updated? So, I changed it to be treated as an override.
> 
> But, I could change the code that updates max_cs_threads to also
> update cs_scratch_ids_per_subslice.

Ugh...thanks for paying more attention than I did.  I forgot we update
max_cs_threads on Cherryview (and might elsewhere someday - though I
kinda hope not).  What you did is probably safer.

Series is
Reviewed-by: Kenneth Graunke 

[Mesa-dev] [PATCH shader-db 4/4] run: handling binding of attribute variable name

[Dongwon Kim]

Optional binding of variables can be processed before linking shader
objects for creating shader program. It is activated by adding lines
with a keyword "BindAttribLoc" followed by name and index as,

"BindAttribLoc name_str1 "

For example,

[require]
..
BindAttrbLoc vertex 1
BindAttrbLoc coord 2
BindAttrbLoc col 3

This makes the shader-db run

glBindAttribLocation(p, 1, "vertex");
glBindAttribLocation(p, 2, "coord");
glBindAttribLocation(p, 3, "col");

before glLinkProgram() to include these binding info in binary shader
program.

Signed-off-by: Dongwon Kim 
---
 run.c | 79 +++
 1 file changed, 79 insertions(+)

diff --git a/run.c b/run.c
index bbab5d9..fe2a97a 100644
--- a/run.c
+++ b/run.c
@@ -76,6 +76,12 @@ struct shader {
 int type;
 };
 
+struct binding_var {
+char *name;
+GLint index;
+struct binding_var *next;
+};
+
 static bool
 extension_in_string(const char *haystack, const char *needle)
 {
@@ -105,6 +111,10 @@ extension_in_string(const char *haystack, const char 
*needle)
 return false;
 }
 
+#define SKIP_SPACES(str) while (*(str) == ' ') str++
+
+struct binding_var binding_head = {"NULL", -1, NULL};
+
 static struct shader *
 get_shaders(const struct context_info *core, const struct context_info *compat,
 const struct context_info *es,
@@ -120,6 +130,7 @@ get_shaders(const struct context_info *core, const struct 
context_info *compat,
 static const char *fp_req = "\nGL_ARB_fragment_program";
 static const char *vp_req = "\nGL_ARB_vertex_program";
 static const char *sso_req = "\nSSO ENABLED";
+static const char *binding = "\nBindAttribLoc";
 static const char *gs = "geometry shader]\n";
 static const char *fs = "fragment ";
 static const char *vs = "vertex ";
@@ -186,11 +197,13 @@ get_shaders(const struct context_info *core, const struct 
context_info *compat,
 const struct context_info *info = *type == TYPE_CORE ? core : compat;
 
 const char *extension_text = text;
+
 while ((extension_text = memmem(extension_text, end_text - extension_text,
 "\nGL_", strlen("\nGL_"))) != NULL) {
 extension_text += 1;
 const char *newline = memchr(extension_text, '\n',
  end_text - extension_text);
+
 if (memmem(info->extension_string, info->extension_string_len,
extension_text, newline - extension_text) == NULL) {
 fprintf(stderr, "SKIP: %s requires unavailable extension %.*s\n",
@@ -202,6 +215,62 @@ get_shaders(const struct context_info *core, const struct 
context_info *compat,
 }
 }
 
+/* process binding */
+struct binding_var *binding_prev = _head;
+const char *pre_binding_text = text;
+
+while ((pre_binding_text = memmem(pre_binding_text, end_text - 
pre_binding_text,
+  binding, strlen(binding))) != NULL) {
+pre_binding_text += strlen(binding);
+
+const char *newline = memchr(pre_binding_text, '\n', end_text - 
pre_binding_text);
+
+SKIP_SPACES(pre_binding_text);
+
+char *endword = memchr(pre_binding_text, ' ', newline - 
pre_binding_text);
+
+/* if there's no more space in the same line */
+if (!endword) {
+fprintf(stderr, "SKIP: can't find attr index for this binding\n");
+continue;
+}
+
+char *binding_name = (char *)calloc(1, endword - pre_binding_text + 1);
+
+strncpy(binding_name, pre_binding_text, endword - pre_binding_text);
+
+pre_binding_text = endword;
+
+SKIP_SPACES(pre_binding_text);
+if (*pre_binding_text == '\n') {
+fprintf(stderr, "SKIP: can't find attr variable name for this 
binding\n");
+continue;
+}
+
+endword = memchr(pre_binding_text, ' ', newline - pre_binding_text);
+
+if (!endword)
+endword = (char *)newline;
+
+char *index_string = calloc(1, endword - pre_binding_text + 1);
+strncpy(index_string, pre_binding_text, endword - pre_binding_text);
+
+struct binding_var *binding_new = malloc(sizeof(struct binding_var));
+
+binding_new->index = strtol(index_string, NULL, 10);
+binding_new->name = binding_name;
+binding_new->next = NULL;
+
+free(index_string);
+
+fprintf(stdout,
+"LOG: glBindAttribLocation(prog, %d, \"%s\") will be executed 
before linking\n",
+binding_new->index, binding_new->name);
+
+binding_prev->next = binding_new;
+binding_prev = binding_new;
+}
+
 /* Find the shaders. */
 unsigned shader_size = 3;
 struct shader *shader = malloc(shader_size * sizeof(struct shader));
@@ -887,6 +956,16 @@ main(int argc, char **argv)
 glDeleteShader(s);
 }
 
+/* takes care of 

[Mesa-dev] [Bug 105426] [regression] Mesa-18.0rc4 - black screen in some Valve games when run under Wine

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

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

-- 
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 105426] [regression] Mesa-18.0rc4 - black screen in some Valve games when run under Wine

[bugzilla-daemon]

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

Bug ID: 105426
   Summary: [regression] Mesa-18.0rc4 - black screen in some Valve
games when run under Wine
   Product: Mesa
   Version: unspecified
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: i...@yahoo.com
QA Contact: mesa-dev@lists.freedesktop.org
Blocks: 77449

Running Portal, HL2, HL2_LC, L4D2 using wined3d results in black screen. Other
than that the games seem to run fine - I can hear the menu sounds. The Steam
Overlay also works and displays fps counter and notifications.

In the terminal the following message could be seen:
"00c1:err:d3d:wined3d_debug_callback 0xf399120: "GL_INVALID_OPERATION in
glUseProgram(program 7 not linked)"

The problem happens only with the Mesa3D-18.0 branch. I've tried rc4 and rc1.

Everything works properly with Mesa-17.3 and git master from Feb 23 (
8df11f3fad52507266ca1e97149fd4175ad05471 )

Gallium Nine and native Linux OpenGL versions of the same titles works fine.
I'm with AMD HD5670 - Evergreen Redwood card (R600 driver).


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=77449
[Bug 77449] Tracker bug for all bugs related to Steam titles
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

i...@yahoo.com changed:

   What|Removed |Added

 Depends on||105426


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=105426
[Bug 105426] [regression] Mesa-18.0rc4 - black screen in some Valve games when
run under Wine
-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #6 from MirceaKitsune  ---
An important note: The exact same freeze happens with both the "radeon" and
"amdgpu" driver: Using either module makes absolutely no difference.

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

MirceaKitsune  changed:

   What|Removed |Added

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

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

MirceaKitsune  changed:

   What|Removed |Added

   Priority|medium  |high

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #5 from MirceaKitsune  ---
Created attachment 137952
  --> https://bugs.freedesktop.org/attachment.cgi?id=137952=edit
xsession-errors-:0

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #4 from MirceaKitsune  ---
Created attachment 137951
  --> https://bugs.freedesktop.org/attachment.cgi?id=137951=edit
Xorg.0.log

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #3 from MirceaKitsune  ---
Created attachment 137950
  --> https://bugs.freedesktop.org/attachment.cgi?id=137950=edit
lspci

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #2 from MirceaKitsune  ---
Created attachment 137949
  --> https://bugs.freedesktop.org/attachment.cgi?id=137949=edit
journalctl

journalctl --since "1 day ago"

This encompasses multiple crashes caused today by Blender 2.79.

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

MirceaKitsune  changed:

   What|Removed |Added

 Attachment #137948|dmesg.txt   |dmesg
description||

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #1 from MirceaKitsune  ---
Created attachment 137948
  --> https://bugs.freedesktop.org/attachment.cgi?id=137948=edit
dmesg.txt

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

MirceaKitsune  changed:

   What|Removed |Added

 CC||sonichedgehog_hyperblast00@
   ||yahoo.com

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

[Mesa-dev] [Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

Bug ID: 105425
   Summary: 3D & games produce periodic GPU crashes (Radeon R7
370)
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: sonichedgehog_hyperblas...@yahoo.com
QA Contact: mesa-dev@lists.freedesktop.org

I am experiencing periodical system freezes which to my knowledge are caused by
a GPU lockup. Those freezes are always triggered by 3D rendering, and are
seemingly produced by a multitude of game engines. The crash is highly
probabilistic, with various programs having a chance of triggering it anywhere
between one minute and one hour. The image instantly freezes in place while
audio stops working and every form of input dies (including the NumLock /
CapsLock keyboard leds), the machine is entirely bricked until powered off and
back on.

The problem is oddly similar to an issue I experienced an year ago, which had
the exact same behavior and was also caused by 3D. That issue was fixed as
every system component has received major updates since, however it seems to
have come back sometime during the last few months. I will link its report here
as it may still contain useful information:

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

My OS is Linux openSUSE Tumbleweed x64: Kernel 4.15.7, Xorg X11 Server 1.19.6,
Mesa 18.0.0, xf86-video-ati 17.10.0, xf86-video-amdgpu 18.0.0. My motherboard
is a Gigabyte GA-X58A-UD7 (rev 1.0). My video card is a Radeon R7 370
(Gigabyte) (rev 1.0), Pitcairn Islands GPU, GCN 1.0, RadeonSI.

https://www.gigabyte.com/Motherboard/GA-X58A-UD7-rev-10
https://www.gigabyte.com/Graphics-Card/GV-R737WF2OC-2GD-rev-10

-- 
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 105412] [OpenGL] [HD 7790] - VSYNC always ON in all videogames

[bugzilla-daemon]

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

--- Comment #2 from Matias N. Goldberg  ---
This could be caused by the Ubuntu's Unity Compositor (Compiz).
You could try forcing VSync off in one of Compiz config/tweak tools.

It could also be caused by the tear free parameter. To test that try:
xrandr --output VIDEO --set TearFree off

where "VIDEO" is the name of your monitor output; you can find out by just
running "xrandr" and it will list all of your monitor outputs. For example mine
reads:
HDMI-A-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y
axis) 510mm x 290mm
   1920x1080 60.00*+  50.0059.94  
   1920x1080i60.0050.0059.94  
   1680x1050 59.88  
   1400x1050 59.95  
   1600x900  60.00  
   1280x1024 60.02  
   1440x900  59.90  
   1280x800  59.91  
   1152x864  75.00  
   1280x720  60.0050.0059.94  
   1024x768  60.00  
   800x600   60.32  
   720x576   50.00  
   720x480   60.0059.94  
   640x480   60.0059.94

Thus I should write:
xrandr --output HDMI-A-0 --set TearFree off

-- 
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] [RFC] Mesa 17.3.x release problems and process improvements

[Mark Janes]

Ilia Mirkin  writes:

> On Tue, Mar 6, 2018 at 2:34 PM, Emil Velikov  wrote:
>> So while others explore ways of improving the testing, let me propose
>> a few ideas for improving the actual releasing process.
>>
>>
>>  - Making the current state always visible - have a web page, git
>>branch and other ways for people to see which patches are picked,
>>require backports, etc.
>
> Yes please! A git branch that's available (and force-pushed freely)
> before the "you're screwed" announcement is going to help clear a lot
> of things up.

I agree that early information is good.  I don't agree that anyone
should force push.  Release branches need to be protected.  Proposed
release branches should only accept patches that have already been
vetted by the process on mesa master.

I would propose:

 - Patches are applied to proposed stable branch by automation when the
   associated commit is pushed to master.  The existing commit message
   annotations drive this process.  There must be zero ambiguity in the
   annotations (eg which stable branches need the patch).

 - Committer is responsible for ensuring that the automation executed.

 - Failure-to-apply generates mail to release managers and committer.
   The committer *should* have been able to test that the commit would
   not apply before pushing the patch to master, and should get dinged
   for this.

 - Failures to apply are resolved by committer, who must backport.  Each
   backported commit references associated patch(es) on master in commit
   message.  Backport is submitted by committer to release managers in
   PR or email.

 - CI Automation immediately builds/tests the proposed stable branch
   whenever it changes.  Release managers verify the results.

 - Any CI failures are resolved by force-pushing the series off of the
   proposed branch.  Release manager communicates status to committer.

I think automation could be implemented to generate proposed stable
branches on an arbitrary branch point in a local git repo.  Including
this policy mechanism in our git tree would make the process
transparent, verifiable, debuggable, and extensible.

Separately, I think we want to limit the ability of release manager to
unilaterally change the stable build.  Release managers should not
author any new commit in the stable branch that is not reviewed by
another release manager, from a different company.

>>  - Per team maintainer - each team has person (a few people) to check,
>>coordinate and remind people for high priority bugs and backports.

I've been doing this for Intel.  Developers are on the hook to fix their
bugs, but you can't make them do it.  They have many pressures on them,
and a maintainer can't make the call as to whether a rendering bug is
more important than day-1 vulkan conformance, for example.

We could heighten the transparency of what is blocking the build by
publicizing the authors of bisected blocking bugs to Phoronix, which
might get things moving.

> Yes! I think this role is highly necessary, but not for the reasons
> you outline here. My main issue thus far with the stable release
> process has been that I don't appear to have any control over what
> patches are included in a particular release. Reasons for rejection
> have varied from "well, there will be another release in 2+ weeks" to
> "this patch doesn't fit some arbitrary criterion".

If the patches are immediately merged to proposed stable branches, then
they should be included by default.  It makes sense to have a standard
window by which patches must be applied before a release.

> What I'd like to propose is a system where the team maintainer is able
> to request any particular patch to be included in a stable release (as
> long as it's done by a certain pre-announced deadline, which happens
> *after* the initial release nominations email). If a release manager
> disagrees, they can make that disagreement known, but it's ultimately
> up to the team maintainer for driver code. If it's in shared code
> (i.e. not driver-specific - winsys, core mesa, state trackers used by
> multiple drivers), the override would be 1 additional team maintainer
> acking, and conversely any team maintainer would be able to nak it (so
> the condition in case of disagreement would be at least 2 team
> maintainers in favor, and 0 against).
>
> As you may know, I've stopped tagging things for stable since a while
> back since it seems completely pointless - nothing I can do to
> actually cause a patch to be included in a release. Telling people to
> just use HEAD seems way more reliable. I'm not particularly happy with
> this arrangement, but it's at least supportable.
>
> Hopefully others here agree with me. Otherwise I'll just go back to
> doing what I'm doing (and perhaps my contribution level has dropped
> sufficiently to not worry about it).
>
> Cheers,
>
>   -ilia
> ___
> mesa-dev mailing 

Re: [Mesa-dev] [PATCH 04/56] anv/entrypoints: Generalize the string map a bit

[Jason Ekstrand]

On Fri, Mar 9, 2018 at 11:59 AM, Dave Airlie  wrote:

> Working under embargoes does suck and quite a lot of people had seen
> this code but I think the process falls down a bit when Jason wrote
> (even tongue-in-cheek)
> "You're 4.5 hours too late, I'm afraid.  I'd be happy to take some
> patches though. :-)"
>
> I know in this case Dylan writing patches is probably the most
> expedient thing, but the response is off putting for post-push review.
>
> Review after something has landed is just as valid as review before.
> If someone spends the time
> reviewing something and it's already in the tree, you should still try
> and respond to the review in a timely fashion.
>
> If you want to push stuff quickly that has gotten lots of internal
> review, but you also need to realise you are have obligations to take
> post-review feedback more seriously :-)
>

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

Re: [Mesa-dev] [PATCH 04/56] anv/entrypoints: Generalize the string map a bit

[Dave Airlie]

Working under embargoes does suck and quite a lot of people had seen
this code but I think the process falls down a bit when Jason wrote
(even tongue-in-cheek)
"You're 4.5 hours too late, I'm afraid.  I'd be happy to take some
patches though. :-)"

I know in this case Dylan writing patches is probably the most
expedient thing, but the response is off putting for post-push review.

Review after something has landed is just as valid as review before.
If someone spends the time
reviewing something and it's already in the tree, you should still try
and respond to the review in a timely fashion.

If you want to push stuff quickly that has gotten lots of internal
review, but you also need to realise you are have obligations to take
post-review feedback more seriously :-)

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

Re: [Mesa-dev] [PATCH 1/3] meson: Use system_has_kms_drm in default driver selection

[Eric Anholt]

Greg V  writes:

> ---

I've pushed this patch with Dylan's and my review on it.


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 1/2] egl/wayland: Add 10bpc BGR configs

[Eric Engestrom]

On Thursday, 2018-03-08 17:36:39 +, Daniel Stone wrote:
> Add support for XBGR2101010 and ABGR2101010.
> 
> Signed-off-by: Daniel Stone 
> Cc: Ilia Mirkin 

Reviewed-by: Eric Engestrom 

> ---
>  src/egl/drivers/dri2/platform_wayland.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/src/egl/drivers/dri2/platform_wayland.c 
> b/src/egl/drivers/dri2/platform_wayland.c
> index 877f7933b9a..7a32491974e 100644
> --- a/src/egl/drivers/dri2/platform_wayland.c
> +++ b/src/egl/drivers/dri2/platform_wayland.c
> @@ -81,6 +81,18 @@ static const struct dri2_wl_visual {
>   __DRI_IMAGE_FORMAT_ARGB2101010, 32,
>   { 0x3ff0, 0x000ffc00, 0x03ff, 0xc000 }
> },
> +   {
> + "XBGR2101010",
> + WL_DRM_FORMAT_XBGR2101010, WL_SHM_FORMAT_XBGR2101010,
> + __DRI_IMAGE_FORMAT_XBGR2101010, 32,
> + { 0x03ff, 0x000ffc00, 0x3ff0, 0x }
> +   },
> +   {
> + "ABGR2101010",
> + WL_DRM_FORMAT_ABGR2101010, WL_SHM_FORMAT_ABGR2101010,
> + __DRI_IMAGE_FORMAT_ABGR2101010, 32,
> + { 0x03ff, 0x000ffc00, 0x3ff0, 0xc000 }
> +   },
> {
>   "XRGB",
>   WL_DRM_FORMAT_XRGB, WL_SHM_FORMAT_XRGB,
> -- 
> 2.14.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] i965: Hard code scratch_ids_per_subslice for Cherryview

[Mark Janes]

Could this be the reason that BSW systems never reliably passed all unit
tests?  Up to now, we re-execute each failing test, and mark it as a
pass if it succeeds a second time.

I'd like to remove that crutch if possible.

Jordan Justen  writes:

> Ken suggested that we might be underallocating scratch space on HD
> 400. Allocating scratch space as though there was actually 8 EUs
> seems to help with a GPU hang seen on synmark CSDof.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104636
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105290
> Cc: Kenneth Graunke 
> Cc: Eero Tamminen 
> Cc: 
> Signed-off-by: Jordan Justen 
> ---
>  src/mesa/drivers/dri/i965/brw_program.c | 44 
> -
>  1 file changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
> b/src/mesa/drivers/dri/i965/brw_program.c
> index 527f003977b..c121136c439 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.c
> +++ b/src/mesa/drivers/dri/i965/brw_program.c
> @@ -402,23 +402,33 @@ brw_alloc_stage_scratch(struct brw_context *brw,
>if (devinfo->gen >= 9)
>   subslices = 4 * brw->screen->devinfo.num_slices;
>  
> -  /* WaCSScratchSize:hsw
> -   *
> -   * Haswell's scratch space address calculation appears to be sparse
> -   * rather than tightly packed.  The Thread ID has bits indicating
> -   * which subslice, EU within a subslice, and thread within an EU
> -   * it is.  There's a maximum of two slices and two subslices, so these
> -   * can be stored with a single bit.  Even though there are only 10 EUs
> -   * per subslice, this is stored in 4 bits, so there's an effective
> -   * maximum value of 16 EUs.  Similarly, although there are only 7
> -   * threads per EU, this is stored in a 3 bit number, giving an 
> effective
> -   * maximum value of 8 threads per EU.
> -   *
> -   * This means that we need to use 16 * 8 instead of 10 * 7 for the
> -   * number of threads per subslice.
> -   */
> -  const unsigned scratch_ids_per_subslice =
> - devinfo->is_haswell ? 16 * 8 : devinfo->max_cs_threads;
> +  unsigned scratch_ids_per_subslice;
> +  if (devinfo->is_haswell) {
> + /* WaCSScratchSize:hsw
> +  *
> +  * Haswell's scratch space address calculation appears to be sparse
> +  * rather than tightly packed. The Thread ID has bits indicating
> +  * which subslice, EU within a subslice, and thread within an EU it
> +  * is. There's a maximum of two slices and two subslices, so these
> +  * can be stored with a single bit. Even though there are only 10 
> EUs
> +  * per subslice, this is stored in 4 bits, so there's an effective
> +  * maximum value of 16 EUs. Similarly, although there are only 7
> +  * threads per EU, this is stored in a 3 bit number, giving an
> +  * effective maximum value of 8 threads per EU.
> +  *
> +  * This means that we need to use 16 * 8 instead of 10 * 7 for the
> +  * number of threads per subslice.
> +  */
> + scratch_ids_per_subslice = 16 * 8;
> +  } else if (devinfo->is_cherryview) {
> + /* For Cherryview, it appears that the scratch addresses for the 6 
> EU
> +  * devices may still generate compute scratch addresses covering the
> +  * same range as 8 EU.
> +  */
> + scratch_ids_per_subslice = 8 * 7;
> +  } else {
> + scratch_ids_per_subslice = devinfo->max_cs_threads;
> +  }
>  
>thread_count = scratch_ids_per_subslice * subslices;
>break;
> -- 
> 2.16.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 04/56] anv/entrypoints: Generalize the string map a bit

[Jason Ekstrand]

On Fri, Mar 9, 2018 at 8:57 AM, Alex Deucher  wrote:

> On Fri, Mar 9, 2018 at 11:04 AM, Jason Ekstrand 
> wrote:
> > On March 9, 2018 00:35:06 Michel Dänzer  wrote:
> >
> >> On 2018-03-08 07:53 PM, Jason Ekstrand wrote:
> >>>
> >>> On Thu, Mar 8, 2018 at 8:45 AM, Dylan Baker  >>> > wrote:
> >>>
> >>> > I know we've always given a lot of flexibility to vendor specific
> >>> code
> >>> > (i965 or nouveau), but you hope everyone can understand my
> >>> frustration
> >>> > with a 56 patch series that I sent review for 8 hours after it
> was
> >>> > posted to the list and I got told "Oh, I merged that hours ago,
> >>> > patches welcome."
> >>>
> >>> I can. I guess Jason got a bit carried away by the Vulkan 1.1
> >>> excitement.
> >>>
> >>>
> >>> Perhaps.  :-)  I do think that being there day-1 is important.
> >>
> >>
> >> The code was there on day 1 anyway. If being available in Git ASAP is
> >> that important (not sure why though), it can be made available in a
> >> repository other than the main shared one.
> >
> >
> > Thanks to things such as the oibaf ppa, landing in master means also
> landing
> > in the hands of users.  There's a little extra delay but there are piles
> of
> > people who now have a Vulkan 1.1 driver who wouldn't build from source.
> > Maybe not a huge deal but landing in master does matter over having a
> > branch.
> >
> >>> If nothing else, it shows the rest of the graphics community (who
> already
> >>> fears the concept of open-source) that working in the open isn't going
> >>> to cramp their style.
> >>
> >>
> >> It wasn't following the normal Mesa development process, so I'm not sure
> >> it's really useful for showing anything about that to anyone.
> >
> >
> > I'm not sure I follow.
> >
>
> One could argue it shows people that are leery of open source to go
> ahead and push out whatever you have ASAP to meet a schedule and fix
> it up later which seems to contradict the whole idea of group review
> and making sure your code is the best it can be.  In my experience,
> one of the biggest concerns people that are not familiar with open
> source tend to have is that it takes too long to get upstream because
> of all the code review.  I'm not really trying to argue, I realize it
> is a fine line...
>

Yeah.  It is a fine line.  I also recognize that anything short of "at
least 24 hours on the public list" is a bit of a slippery slope.  If you
can push without giving everyone in the world (timezone wise) a chance for
review, what's the threshold?  12 hours? 8 hours? 4?  Can you just push
without sending it to the list at all?  There's no real good threshold
below 24.  And, if needs be, we can always get in contact with the guy who
does the oibaf PPA and have him apply the patches or pick up a branch so
that users get it.  Or we can just count on the fact that no one will have
any games that require Vulkan 1.1 on the first day and hope that developers
who want to write Vulkan 1.1 code know how to apply patches build mesa from
source.

That said, I think it is good, when working with embargoes, for people who
do have early access to do early review.  That way the later review process
goes much more smoothly if there are any comments at all.  What
closed-source developers (and companies) are afraid of is not the 24 hour
window, it's the 5-10 respins/rebases of 100+ patches over the course of 2
weeks - 6 months.  Now, mesa is a fairly reasonable community and you're
more likely looking at 2-3 respins and 1-2 weeks for a series like this.
However, it's still going to be a lot more than 24 hours if there is
significant late-breaking feedback.

I'm sorry if I'm venting a bit here.  I sucks to be the guy working under
an embargo.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 04/56] anv/entrypoints: Generalize the string map a bit

[Alex Deucher]

On Fri, Mar 9, 2018 at 11:04 AM, Jason Ekstrand  wrote:
> On March 9, 2018 00:35:06 Michel Dänzer  wrote:
>
>> On 2018-03-08 07:53 PM, Jason Ekstrand wrote:
>>>
>>> On Thu, Mar 8, 2018 at 8:45 AM, Dylan Baker >> > wrote:
>>>
>>> > I know we've always given a lot of flexibility to vendor specific
>>> code
>>> > (i965 or nouveau), but you hope everyone can understand my
>>> frustration
>>> > with a 56 patch series that I sent review for 8 hours after it was
>>> > posted to the list and I got told "Oh, I merged that hours ago,
>>> > patches welcome."
>>>
>>> I can. I guess Jason got a bit carried away by the Vulkan 1.1
>>> excitement.
>>>
>>>
>>> Perhaps.  :-)  I do think that being there day-1 is important.
>>
>>
>> The code was there on day 1 anyway. If being available in Git ASAP is
>> that important (not sure why though), it can be made available in a
>> repository other than the main shared one.
>
>
> Thanks to things such as the oibaf ppa, landing in master means also landing
> in the hands of users.  There's a little extra delay but there are piles of
> people who now have a Vulkan 1.1 driver who wouldn't build from source.
> Maybe not a huge deal but landing in master does matter over having a
> branch.
>
>>> If nothing else, it shows the rest of the graphics community (who already
>>> fears the concept of open-source) that working in the open isn't going
>>> to cramp their style.
>>
>>
>> It wasn't following the normal Mesa development process, so I'm not sure
>> it's really useful for showing anything about that to anyone.
>
>
> I'm not sure I follow.
>

One could argue it shows people that are leery of open source to go
ahead and push out whatever you have ASAP to meet a schedule and fix
it up later which seems to contradict the whole idea of group review
and making sure your code is the best it can be.  In my experience,
one of the biggest concerns people that are not familiar with open
source tend to have is that it takes too long to get upstream because
of all the code review.  I'm not really trying to argue, I realize it
is a fine line...

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

Re: [Mesa-dev] [PATCH] vulkan: simplify VK_USE_PLATFORM_*_KHR handling

[Eric Engestrom]

On Friday, 2018-03-09 15:24:18 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Instead of having multiple guards littered through the code, simply
> introduce static inline no-op functions when the respective macros are
> not set.
> 
> Inspired by the same convention from the kernel.

Oh right, I didn't get what you meant at first, but this makes sense. As
the number of supported platform increases, this will be much cleaner.

> 
> Cc: Eric Engestrom 
> Signed-off-by: Emil Velikov 
> ---
> Here is an example of my earlier suggestion.
> NOTE: not even compile tested!
> ---
>  src/vulkan/wsi/wsi_common.c |  8 
>  src/vulkan/wsi/wsi_common_private.h | 27 +++
>  2 files changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
> index fe262b4968d..c91075325b9 100644
> --- a/src/vulkan/wsi/wsi_common.c
> +++ b/src/vulkan/wsi/wsi_common.c
> @@ -79,17 +79,13 @@ wsi_device_init(struct wsi_device *wsi,
> WSI_GET_CB(WaitForFences);
>  #undef WSI_GET_CB
>  
> -#ifdef VK_USE_PLATFORM_XCB_KHR
> result = wsi_x11_init_wsi(wsi, alloc);
> if (result != VK_SUCCESS)
>goto fail;
> -#endif
>  
> -#ifdef VK_USE_PLATFORM_WAYLAND_KHR
> result = wsi_wl_init_wsi(wsi, alloc, pdevice);
> if (result != VK_SUCCESS)
>goto fail;
> -#endif
>  
> return VK_SUCCESS;
>  
> @@ -102,12 +98,8 @@ void
>  wsi_device_finish(struct wsi_device *wsi,
>const VkAllocationCallbacks *alloc)
>  {
> -#ifdef VK_USE_PLATFORM_WAYLAND_KHR
> wsi_wl_finish_wsi(wsi, alloc);
> -#endif
> -#ifdef VK_USE_PLATFORM_XCB_KHR
> wsi_x11_finish_wsi(wsi, alloc);
> -#endif
>  }
>  
>  VkResult
> diff --git a/src/vulkan/wsi/wsi_common_private.h 
> b/src/vulkan/wsi/wsi_common_private.h
> index b608119b969..501bbf0498e 100644
> --- a/src/vulkan/wsi/wsi_common_private.h
> +++ b/src/vulkan/wsi/wsi_common_private.h
> @@ -129,16 +129,43 @@ struct wsi_interface {
>  struct wsi_swapchain **swapchain);
>  };
>  
> +#ifdef VK_USE_PLATFORM_XCB_KHR
>  VkResult wsi_x11_init_wsi(struct wsi_device *wsi_device,
>const VkAllocationCallbacks *alloc);
>  void wsi_x11_finish_wsi(struct wsi_device *wsi_device,
>  const VkAllocationCallbacks *alloc);
> +#else
> +static inline
> +VkResult wsi_x11_init_wsi(struct wsi_device *wsi_device,
> +  const VkAllocationCallbacks *alloc)
> +{
> +   return VK_SUCCESS;
> +}
> +
> +static inline
> +void wsi_x11_finish_wsi(struct wsi_device *wsi_device,
> +const VkAllocationCallbacks *alloc) { }

Nit: can we have all the `{` and `}` on their own lines, just like the
`init` stub above?

Provided you compile-test :P
Reviewed-by: Eric Engestrom 

> +#endif
> +
> +#ifdef VK_USE_PLATFORM_WAYLAND_KHR
>  VkResult wsi_wl_init_wsi(struct wsi_device *wsi_device,
>   const VkAllocationCallbacks *alloc,
>   VkPhysicalDevice physical_device);
>  void wsi_wl_finish_wsi(struct wsi_device *wsi_device,
> const VkAllocationCallbacks *alloc);
> +#else
> +static inline
> +VkResult wsi_wl_init_wsi(struct wsi_device *wsi_device,
> + const VkAllocationCallbacks *alloc,
> + VkPhysicalDevice physical_device);
> +{
> +   return VK_SUCCESS;
> +}
>  
> +static inline
> +void wsi_wl_finish_wsi(struct wsi_device *wsi_device,
> +   const VkAllocationCallbacks *alloc) {}
> +#endif
>  
>  #define WSI_DEFINE_NONDISP_HANDLE_CASTS(__wsi_type, __VkType)  \
> \
> -- 
> 2.16.0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Add moduledir to d3d.pc

[Eric Engestrom]

On Friday, 2018-03-09 08:32:29 -0800, Dylan Baker wrote:
> This is required to build wine with the nine patchset
> 
> Fixes: 6b4c7047d57178d3362a710ad503057c6a582ca3
>("meson: build gallium nine state_tracker")
> Reported-by: Mike Lothian 
> Signed-off-by: Dylan Baker 

Reviewed-by: Eric Engestrom 

> ---
>  src/gallium/targets/d3dadapter9/meson.build | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/gallium/targets/d3dadapter9/meson.build 
> b/src/gallium/targets/d3dadapter9/meson.build
> index fd608be9bf6..e3f4ae58f53 100644
> --- a/src/gallium/targets/d3dadapter9/meson.build
> +++ b/src/gallium/targets/d3dadapter9/meson.build
> @@ -72,4 +72,5 @@ pkg.generate(
>description : 'Native D3D driver modules',
>version : '.'.join(nine_version),
>requires_private : 'libdrm >= 2.4.75',
> +  variables : ['moduledir=${prefix}/@0@'.format(d3d_drivers_path)],
>  )
> -- 
> 2.16.2
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: Increase the number of dynamic uniform buffers.

[Alex Smith]

Tested-by: Alex Smith 

Thanks!

On 9 March 2018 at 16:21, Bas Nieuwenhuizen  wrote:

> The vulkan API is not ideal as it does not allow us have a
> shared limit.
>
> Feral needs 15+6 for one of their games, and I'm not a fan
> of overcommitting the limits, so increase the number of
> dynamic uniform buffers to 16.
>
> CC: 
> CC: Alex Smith 
> ---
>  src/amd/vulkan/radv_device.c  | 4 ++--
>  src/amd/vulkan/radv_private.h | 4 +++-
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 7a11e08f97..0ed3e27c7b 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -775,9 +775,9 @@ void radv_GetPhysicalDeviceProperties(
> .maxPerStageResources =
> max_descriptor_set_size,
> .maxDescriptorSetSamplers =
> max_descriptor_set_size,
> .maxDescriptorSetUniformBuffers   =
> max_descriptor_set_size,
> -   .maxDescriptorSetUniformBuffersDynamic=
> MAX_DYNAMIC_BUFFERS / 2,
> +   .maxDescriptorSetUniformBuffersDynamic=
> MAX_DYNAMIC_UNIFORM_BUFFERS,
> .maxDescriptorSetStorageBuffers   =
> max_descriptor_set_size,
> -   .maxDescriptorSetStorageBuffersDynamic=
> MAX_DYNAMIC_BUFFERS / 2,
> +   .maxDescriptorSetStorageBuffersDynamic=
> MAX_DYNAMIC_STORAGE_BUFFERS,
> .maxDescriptorSetSampledImages=
> max_descriptor_set_size,
> .maxDescriptorSetStorageImages=
> max_descriptor_set_size,
> .maxDescriptorSetInputAttachments =
> max_descriptor_set_size,
> diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
> index 0f8ddb2e10..439522585a 100644
> --- a/src/amd/vulkan/radv_private.h
> +++ b/src/amd/vulkan/radv_private.h
> @@ -87,7 +87,9 @@ typedef uint32_t xcb_window_t;
>  #define MAX_DISCARD_RECTANGLES 4
>  #define MAX_PUSH_CONSTANTS_SIZE 128
>  #define MAX_PUSH_DESCRIPTORS 32
> -#define MAX_DYNAMIC_BUFFERS 16
> +#define MAX_DYNAMIC_UNIFORM_BUFFERS 16
> +#define MAX_DYNAMIC_STORAGE_BUFFERS 8
> +#define MAX_DYNAMIC_BUFFERS (MAX_DYNAMIC_UNIFORM_BUFFERS +
> MAX_DYNAMIC_STORAGE_BUFFERS)
>  #define MAX_SAMPLES_LOG2 4
>  #define NUM_META_FS_KEYS 13
>  #define RADV_MAX_DRM_DEVICES 8
> --
> 2.16.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Few issues with Meson

[Dylan Baker]

Quoting Mike Lothian (2018-03-06 05:07:34)
> Hi
> 
> When compiling wine I also noticed that the d3d.pc files didn't have moduledir
> set, so wine couldn't find it
> 
> configure: error: pkg-config couldn't find Gallium Nine module

I've sent a patch for this.

> 
> Regards
> 
> Mike
> 
> On Tue, 6 Mar 2018 at 02:17 Mike Lothian  wrote:
> 
> Hi
> 
> I've been trying to get a Gentoo ebuild ready for meson
> 
> I've had to fudge the llvm-config for cross compiling a 32bit mesa on
> a 64bit machine

If you're using a new enough meson (0.45) you can specify the llvm-config you
want to use in the cross file.

> 
> I notice that -Dvulkan-drivers= doesn't accept intel,radeon like
> autotools used to, it also seems as long as one value is correct the
> other is ignored

we're using amd instead of radeon. After 18.0 branches I want to bump the meson
requirement so we can use meson's list argument type, which will check for such
problems.

> 
> Also -Dva-libs-path= doesn't play well with absolute paths, or rather
> install_megadrivers.py is doing something strange - normally gentoo
> installs everything to a temporary image path then puts those files
> into the live system. It seems install_megadrivers.py doesn't do this
> and installs directly to the live system - I worked around it by
> dropping the /usr

There's a patch from someone in FreeBSD that might fix this (the way we do
symlinking in install_megadrivers is wrong).

Sorry it took me so long to find this email, notmuch applied some odd tags to
it.

Dylan


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

[Mesa-dev] [PATCH] meson: Add moduledir to d3d.pc

[Dylan Baker]

This is required to build wine with the nine patchset

Fixes: 6b4c7047d57178d3362a710ad503057c6a582ca3
   ("meson: build gallium nine state_tracker")
Reported-by: Mike Lothian 
Signed-off-by: Dylan Baker 
---
 src/gallium/targets/d3dadapter9/meson.build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/targets/d3dadapter9/meson.build 
b/src/gallium/targets/d3dadapter9/meson.build
index fd608be9bf6..e3f4ae58f53 100644
--- a/src/gallium/targets/d3dadapter9/meson.build
+++ b/src/gallium/targets/d3dadapter9/meson.build
@@ -72,4 +72,5 @@ pkg.generate(
   description : 'Native D3D driver modules',
   version : '.'.join(nine_version),
   requires_private : 'libdrm >= 2.4.75',
+  variables : ['moduledir=${prefix}/@0@'.format(d3d_drivers_path)],
 )
-- 
2.16.2

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

Re: [Mesa-dev] [PATCH] radv: Increase maxDescriptorSet{Uniform, Storage}BuffersDynamic limits

[Bas Nieuwenhuizen]

Sorry, for the delay, I just sent a patch that makes the limits 16 + 8.

Going forward it might be an idea to just make this a dynamically
sized array and seriously increase the limits.

On Fri, Mar 9, 2018 at 5:15 PM, Alex Smith  wrote:
> Ping.
>
> Maybe it'd be better to just increase MAX_DYNAMIC_BUFFERS? I can't see any
> side effects of that other than increasing the size of radv_cmd_buffer?
>
> Alex
>
> On 5 March 2018 at 09:59, Alex Smith  wrote:
>>
>> I just checked what Rise of the Tomb Raider is using. Maximum it hits for
>> uniform buffers is 15, and 6 for storage buffers. The highest combined total
>> is 15.
>>
>> Alex
>>
>> On 2 March 2018 at 20:11, Bas Nieuwenhuizen 
>> wrote:
>>>
>>> Hi Alex,
>>>
>>> How many do you need of either type?
>>>
>>> - Bas
>>>
>>> On Fri, Mar 2, 2018 at 4:28 PM, Alex Smith 
>>> wrote:
>>> > These were set to MAX_DYNAMIC_BUFFERS / 2, which is too restrictive
>>> > since an app may have it's total usage of both uniform and storage
>>> > within MAX_DYNAMIC_BUFFERS, but exceed the limit for one of the types.
>>> >
>>> > Recently the validation layers have started raising errors for when
>>> > these limits are exceeded, so these are firing for something that
>>> > actually works just fine.
>>> >
>>> > Set the limit for both to MAX_DYNAMIC_BUFFERS. Not ideal because it
>>> > now allows the total across both to exceed the real limit, but we have
>>> > no way to express that limit properly.
>>> >
>>> > Cc: 
>>> > Signed-off-by: Alex Smith 
>>> > ---
>>> >  src/amd/vulkan/radv_device.c | 4 ++--
>>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>>> >
>>> > diff --git a/src/amd/vulkan/radv_device.c
>>> > b/src/amd/vulkan/radv_device.c
>>> > index 36d7a406bf..1e81ddb891 100644
>>> > --- a/src/amd/vulkan/radv_device.c
>>> > +++ b/src/amd/vulkan/radv_device.c
>>> > @@ -717,9 +717,9 @@ void radv_GetPhysicalDeviceProperties(
>>> > .maxPerStageResources =
>>> > max_descriptor_set_size,
>>> > .maxDescriptorSetSamplers =
>>> > max_descriptor_set_size,
>>> > .maxDescriptorSetUniformBuffers   =
>>> > max_descriptor_set_size,
>>> > -   .maxDescriptorSetUniformBuffersDynamic=
>>> > MAX_DYNAMIC_BUFFERS / 2,
>>> > +   .maxDescriptorSetUniformBuffersDynamic=
>>> > MAX_DYNAMIC_BUFFERS,
>>> > .maxDescriptorSetStorageBuffers   =
>>> > max_descriptor_set_size,
>>> > -   .maxDescriptorSetStorageBuffersDynamic=
>>> > MAX_DYNAMIC_BUFFERS / 2,
>>> > +   .maxDescriptorSetStorageBuffersDynamic=
>>> > MAX_DYNAMIC_BUFFERS,
>>> > .maxDescriptorSetSampledImages=
>>> > max_descriptor_set_size,
>>> > .maxDescriptorSetStorageImages=
>>> > max_descriptor_set_size,
>>> > .maxDescriptorSetInputAttachments =
>>> > max_descriptor_set_size,
>>> > --
>>> > 2.14.3
>>> >
>>> > ___
>>> > 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] radv: Increase the number of dynamic uniform buffers.

[Bas Nieuwenhuizen]

The vulkan API is not ideal as it does not allow us have a
shared limit.

Feral needs 15+6 for one of their games, and I'm not a fan
of overcommitting the limits, so increase the number of
dynamic uniform buffers to 16.

CC: 
CC: Alex Smith 
---
 src/amd/vulkan/radv_device.c  | 4 ++--
 src/amd/vulkan/radv_private.h | 4 +++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 7a11e08f97..0ed3e27c7b 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -775,9 +775,9 @@ void radv_GetPhysicalDeviceProperties(
.maxPerStageResources = 
max_descriptor_set_size,
.maxDescriptorSetSamplers = 
max_descriptor_set_size,
.maxDescriptorSetUniformBuffers   = 
max_descriptor_set_size,
-   .maxDescriptorSetUniformBuffersDynamic= MAX_DYNAMIC_BUFFERS 
/ 2,
+   .maxDescriptorSetUniformBuffersDynamic= 
MAX_DYNAMIC_UNIFORM_BUFFERS,
.maxDescriptorSetStorageBuffers   = 
max_descriptor_set_size,
-   .maxDescriptorSetStorageBuffersDynamic= MAX_DYNAMIC_BUFFERS 
/ 2,
+   .maxDescriptorSetStorageBuffersDynamic= 
MAX_DYNAMIC_STORAGE_BUFFERS,
.maxDescriptorSetSampledImages= 
max_descriptor_set_size,
.maxDescriptorSetStorageImages= 
max_descriptor_set_size,
.maxDescriptorSetInputAttachments = 
max_descriptor_set_size,
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 0f8ddb2e10..439522585a 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -87,7 +87,9 @@ typedef uint32_t xcb_window_t;
 #define MAX_DISCARD_RECTANGLES 4
 #define MAX_PUSH_CONSTANTS_SIZE 128
 #define MAX_PUSH_DESCRIPTORS 32
-#define MAX_DYNAMIC_BUFFERS 16
+#define MAX_DYNAMIC_UNIFORM_BUFFERS 16
+#define MAX_DYNAMIC_STORAGE_BUFFERS 8
+#define MAX_DYNAMIC_BUFFERS (MAX_DYNAMIC_UNIFORM_BUFFERS + 
MAX_DYNAMIC_STORAGE_BUFFERS)
 #define MAX_SAMPLES_LOG2 4
 #define NUM_META_FS_KEYS 13
 #define RADV_MAX_DRM_DEVICES 8
-- 
2.16.1

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

Re: [Mesa-dev] [PATCH] radv: Increase maxDescriptorSet{Uniform, Storage}BuffersDynamic limits

[Alex Smith]

Ping.

Maybe it'd be better to just increase MAX_DYNAMIC_BUFFERS? I can't see any
side effects of that other than increasing the size of radv_cmd_buffer?

Alex

On 5 March 2018 at 09:59, Alex Smith  wrote:

> I just checked what Rise of the Tomb Raider is using. Maximum it hits for
> uniform buffers is 15, and 6 for storage buffers. The highest combined
> total is 15.
>
> Alex
>
> On 2 March 2018 at 20:11, Bas Nieuwenhuizen 
> wrote:
>
>> Hi Alex,
>>
>> How many do you need of either type?
>>
>> - Bas
>>
>> On Fri, Mar 2, 2018 at 4:28 PM, Alex Smith 
>> wrote:
>> > These were set to MAX_DYNAMIC_BUFFERS / 2, which is too restrictive
>> > since an app may have it's total usage of both uniform and storage
>> > within MAX_DYNAMIC_BUFFERS, but exceed the limit for one of the types.
>> >
>> > Recently the validation layers have started raising errors for when
>> > these limits are exceeded, so these are firing for something that
>> > actually works just fine.
>> >
>> > Set the limit for both to MAX_DYNAMIC_BUFFERS. Not ideal because it
>> > now allows the total across both to exceed the real limit, but we have
>> > no way to express that limit properly.
>> >
>> > Cc: 
>> > Signed-off-by: Alex Smith 
>> > ---
>> >  src/amd/vulkan/radv_device.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
>> > index 36d7a406bf..1e81ddb891 100644
>> > --- a/src/amd/vulkan/radv_device.c
>> > +++ b/src/amd/vulkan/radv_device.c
>> > @@ -717,9 +717,9 @@ void radv_GetPhysicalDeviceProperties(
>> > .maxPerStageResources =
>> max_descriptor_set_size,
>> > .maxDescriptorSetSamplers =
>> max_descriptor_set_size,
>> > .maxDescriptorSetUniformBuffers   =
>> max_descriptor_set_size,
>> > -   .maxDescriptorSetUniformBuffersDynamic=
>> MAX_DYNAMIC_BUFFERS / 2,
>> > +   .maxDescriptorSetUniformBuffersDynamic=
>> MAX_DYNAMIC_BUFFERS,
>> > .maxDescriptorSetStorageBuffers   =
>> max_descriptor_set_size,
>> > -   .maxDescriptorSetStorageBuffersDynamic=
>> MAX_DYNAMIC_BUFFERS / 2,
>> > +   .maxDescriptorSetStorageBuffersDynamic=
>> MAX_DYNAMIC_BUFFERS,
>> > .maxDescriptorSetSampledImages=
>> max_descriptor_set_size,
>> > .maxDescriptorSetStorageImages=
>> max_descriptor_set_size,
>> > .maxDescriptorSetInputAttachments =
>> max_descriptor_set_size,
>> > --
>> > 2.14.3
>> >
>> > ___
>> > 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 04/56] anv/entrypoints: Generalize the string map a bit

[Jason Ekstrand]

On March 9, 2018 00:35:06 Michel Dänzer  wrote:


On 2018-03-08 07:53 PM, Jason Ekstrand wrote:

On Thu, Mar 8, 2018 at 8:45 AM, Dylan Baker > wrote:

> I know we've always given a lot of flexibility to vendor specific code
> (i965 or nouveau), but you hope everyone can understand my frustration
> with a 56 patch series that I sent review for 8 hours after it was
> posted to the list and I got told "Oh, I merged that hours ago,
> patches welcome."

I can. I guess Jason got a bit carried away by the Vulkan 1.1
excitement.


Perhaps.  :-)  I do think that being there day-1 is important.


The code was there on day 1 anyway. If being available in Git ASAP is
that important (not sure why though), it can be made available in a
repository other than the main shared one.


Thanks to things such as the oibaf ppa, landing in master means also 
landing in the hands of users.  There's a little extra delay but there are 
piles of people who now have a Vulkan 1.1 driver who wouldn't build from 
source.  Maybe not a huge deal but landing in master does matter over 
having a branch.



If nothing else, it shows the rest of the graphics community (who already
fears the concept of open-source) that working in the open isn't going
to cramp their style.


It wasn't following the normal Mesa development process, so I'm not sure
it's really useful for showing anything about that to anyone.


I'm not sure I follow.


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

[Mesa-dev] WineConf 2018

[Henri Verbeet]

I hope this won't be considered spam, in which case I'd like to
apologise in advance.

The annual Wine conference will this year take place from Friday June
29 until Sunday July 1, in The Hague, The Netherlands. In the interest
of outreach to other projects, and since I believe Wine would be
considered a significant user of Mesa, perhaps there are some Mesa
developers that would like to meetup with some Wine developers, or
perhaps there are Mesa developers that simply happen to be in the area
around that time and would like to drop by. For more information,
please see https://wiki.winehq.org/WineConf2018.

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

[Mesa-dev] [PATCH] vulkan: simplify VK_USE_PLATFORM_*_KHR handling

[Emil Velikov]

From: Emil Velikov 

Instead of having multiple guards littered through the code, simply
introduce static inline no-op functions when the respective macros are
not set.

Inspired by the same convention from the kernel.

Cc: Eric Engestrom 
Signed-off-by: Emil Velikov 
---
Here is an example of my earlier suggestion.
NOTE: not even compile tested!
---
 src/vulkan/wsi/wsi_common.c |  8 
 src/vulkan/wsi/wsi_common_private.h | 27 +++
 2 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index fe262b4968d..c91075325b9 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -79,17 +79,13 @@ wsi_device_init(struct wsi_device *wsi,
WSI_GET_CB(WaitForFences);
 #undef WSI_GET_CB
 
-#ifdef VK_USE_PLATFORM_XCB_KHR
result = wsi_x11_init_wsi(wsi, alloc);
if (result != VK_SUCCESS)
   goto fail;
-#endif
 
-#ifdef VK_USE_PLATFORM_WAYLAND_KHR
result = wsi_wl_init_wsi(wsi, alloc, pdevice);
if (result != VK_SUCCESS)
   goto fail;
-#endif
 
return VK_SUCCESS;
 
@@ -102,12 +98,8 @@ void
 wsi_device_finish(struct wsi_device *wsi,
   const VkAllocationCallbacks *alloc)
 {
-#ifdef VK_USE_PLATFORM_WAYLAND_KHR
wsi_wl_finish_wsi(wsi, alloc);
-#endif
-#ifdef VK_USE_PLATFORM_XCB_KHR
wsi_x11_finish_wsi(wsi, alloc);
-#endif
 }
 
 VkResult
diff --git a/src/vulkan/wsi/wsi_common_private.h 
b/src/vulkan/wsi/wsi_common_private.h
index b608119b969..501bbf0498e 100644
--- a/src/vulkan/wsi/wsi_common_private.h
+++ b/src/vulkan/wsi/wsi_common_private.h
@@ -129,16 +129,43 @@ struct wsi_interface {
 struct wsi_swapchain **swapchain);
 };
 
+#ifdef VK_USE_PLATFORM_XCB_KHR
 VkResult wsi_x11_init_wsi(struct wsi_device *wsi_device,
   const VkAllocationCallbacks *alloc);
 void wsi_x11_finish_wsi(struct wsi_device *wsi_device,
 const VkAllocationCallbacks *alloc);
+#else
+static inline
+VkResult wsi_x11_init_wsi(struct wsi_device *wsi_device,
+  const VkAllocationCallbacks *alloc)
+{
+   return VK_SUCCESS;
+}
+
+static inline
+void wsi_x11_finish_wsi(struct wsi_device *wsi_device,
+const VkAllocationCallbacks *alloc) { }
+#endif
+
+#ifdef VK_USE_PLATFORM_WAYLAND_KHR
 VkResult wsi_wl_init_wsi(struct wsi_device *wsi_device,
  const VkAllocationCallbacks *alloc,
  VkPhysicalDevice physical_device);
 void wsi_wl_finish_wsi(struct wsi_device *wsi_device,
const VkAllocationCallbacks *alloc);
+#else
+static inline
+VkResult wsi_wl_init_wsi(struct wsi_device *wsi_device,
+ const VkAllocationCallbacks *alloc,
+ VkPhysicalDevice physical_device);
+{
+   return VK_SUCCESS;
+}
 
+static inline
+void wsi_wl_finish_wsi(struct wsi_device *wsi_device,
+   const VkAllocationCallbacks *alloc) {}
+#endif
 
 #define WSI_DEFINE_NONDISP_HANDLE_CASTS(__wsi_type, __VkType)  \
\
-- 
2.16.0

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

[Mesa-dev] [Bug 105139] Assertion in Dying Light

[bugzilla-daemon]

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

--- Comment #3 from vadym  ---
Tried to run DyingLight on Ubuntu 16.04 but got an error that detected opengl
version is 3.0 but needed is 3.3. But in glxinfo I can see 4.5 version of
opengl. After this game is loaded and some audio is played but nothing on the
screen. 

My setup info:

My setup info:
OS: Ubuntu 16.04 LTS 64 bit
Firefox: 58.0.2 (64-bit)
Mesa: 18.1.0-devel (git-33633690aa) 
CPU: Intel® Core™ i7-8550U CPU @ 1.80GHz × 8 
GPU: Intel® UHD Graphics 620 (Kabylake GT2)

-- 
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] draw: fix alpha value for very short aa lines

[Brian Paul]

Reviewed-by: Brian Paul 

On 03/08/2018 09:30 PM, srol...@vmware.com wrote:

From: Roland Scheidegger 

The logic would not work correctly for line lengths smaller than 1.0,
even a degenerated line with length 0 would still produce a fragment
with anyhwere between alpha 0.0 and 0.5.
---
  src/gallium/auxiliary/draw/draw_pipe_aaline.c  | 25 -
  src/gallium/auxiliary/draw/draw_pipe_stipple.c |  1 -
  2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c 
b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
index 14a4b2f..66a943a 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
@@ -370,7 +370,30 @@ aaline_line(struct draw_stage *stage, struct prim_header 
*header)
 float t_l, t_w;
 uint i;
  
-   half_length = 0.5f * sqrtf(dx * dx + dy * dy) + 0.5f;

+   half_length = 0.5f * sqrtf(dx * dx + dy * dy);
+
+   if (half_length < 0.5f) {
+  /*
+   * The logic we use for "normal" sized segments is incorrect
+   * for very short segments (basically because we only have
+   * one value to interpolate, not a distance to each endpoint).
+   * Therefore, we calculate half_length differently, so that for
+   * original line length (near) 0, we get alpha 0 - otherwise
+   * max alpha would still be 0.5. This also prevents us from
+   * artifacts due to degenerated lines (the endpoints being
+   * identical, which would still receive anywhere from alpha
+   * 0-0.5 otherwise) (at least the pstipple stage may generate
+   * such lines due to float inaccuracies if line length is very
+   * close to a integer).
+   * Might not be fully accurate neither (because the "strength" of
+   * the line is going to be determined by how close to the pixel
+   * center those 1 or 2 fragments are) but it's probably the best
+   * we can do.
+   */
+  half_length = 2.0f * half_length;
+   } else {
+  half_length = half_length + 0.5f;
+   }
  
 t_w = half_width;

 t_l = 0.5f;
diff --git a/src/gallium/auxiliary/draw/draw_pipe_stipple.c 
b/src/gallium/auxiliary/draw/draw_pipe_stipple.c
index 3a44e96..d30572c 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_stipple.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_stipple.c
@@ -150,7 +150,6 @@ stipple_line(struct draw_stage *stage, struct prim_header 
*header)
 if (header->flags & DRAW_PIPE_RESET_STIPPLE)
stipple->counter = 0;
  
-

 /* XXX ToDo: instead of iterating pixel-by-pixel, use a look-up table.
  */
 for (i = 0; i < length; i++) {



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

Re: [Mesa-dev] [PATCH] mesa: Make gl_vertex_array contain pointers to first order VAO members.

[Brian Paul]

On 03/09/2018 12:32 AM, mathias.froehl...@gmx.net wrote:

From: Mathias Fröhlich 

Hi Brian,

The updated patch to be sure. The changes with removing the gl prefix lead to
an other small change in _tnl_import_array not to have attrib twice in the
argument list. Therefore the v2 again for review.
I did also rename the current values from curr_glattrib to current without
being requested by review.
So, to be sure: your RB is still valid for v2 then?


Looks good, Reviewed-by: Brian Paul 



Plenty thanks for your review these weeks!!


You're welcome.

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

Re: [Mesa-dev] [PATCH] r600: implement callstack workaround for evergreen.

[Elie Tournier]

On Fri, Mar 09, 2018 at 04:09:43PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This is ported from the sb backend, there are some issues with
> evergreen stacks on the boundary between entries and ALU_PUSH_BEFORE
> instructions.
> 
> Whenever we are going to use a push before, we check the stack
> usage and if we have to use the workaround, then we switch to
> a separate push.
> 
> I noticed this problem dealing with some of the soft fp64 shaders,
> in nosb mode, they are quite stack happy.
More than happy actually!
On my system, I get:
[1375/1375] skip: 4, pass: 1368, fail: 3
So thanks a lot.
> 
> This fixes all the glitches and inconsistencies I've seen with them
> 
> Signed-off-by: Dave Airlie 
Tested-by: Elie Tournier 
> ---
>  src/gallium/drivers/r600/r600_shader.c | 39 
> +++---
>  1 file changed, 31 insertions(+), 8 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/r600_shader.c 
> b/src/gallium/drivers/r600/r600_shader.c
> index 48750fb..3ca7890 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -377,7 +377,7 @@ struct r600_shader_tgsi_instruction {
>  static int emit_gs_ring_writes(struct r600_shader_ctx *ctx, const struct 
> pipe_stream_output_info *so, int stream, bool ind);
>  static const struct r600_shader_tgsi_instruction 
> r600_shader_tgsi_instruction[], eg_shader_tgsi_instruction[], 
> cm_shader_tgsi_instruction[];
>  static int tgsi_helper_tempx_replicate(struct r600_shader_ctx *ctx);
> -static inline void callstack_push(struct r600_shader_ctx *ctx, unsigned 
> reason);
> +static inline int callstack_push(struct r600_shader_ctx *ctx, unsigned 
> reason);
>  static void fc_pushlevel(struct r600_shader_ctx *ctx, int type);
>  static int tgsi_else(struct r600_shader_ctx *ctx);
>  static int tgsi_endif(struct r600_shader_ctx *ctx);
> @@ -393,6 +393,15 @@ static void r600_bytecode_src(struct 
> r600_bytecode_alu_src *bc_src,
>  static int do_lds_fetch_values(struct r600_shader_ctx *ctx, unsigned 
> temp_reg,
>  unsigned dst_reg, unsigned mask);
>  
> +static bool ctx_needs_stack_workaround_8xx(struct r600_shader_ctx *ctx)
> +{
> + if (ctx->bc->family == CHIP_HEMLOCK ||
> + ctx->bc->family == CHIP_CYPRESS ||
> + ctx->bc->family == CHIP_JUNIPER)
> + return false;
> + return true;
> +}
> +
>  static bool ctx_has_doubles(struct r600_shader_ctx *ctx)
>  {
>   if (ctx->bc->family == CHIP_ARUBA ||
> @@ -10182,7 +10191,7 @@ static int pops(struct r600_shader_ctx *ctx, int pops)
>   return 0;
>  }
>  
> -static inline void callstack_update_max_depth(struct r600_shader_ctx *ctx,
> +static inline int callstack_update_max_depth(struct r600_shader_ctx *ctx,
>unsigned reason)
>  {
>   struct r600_stack_info *stack = >bc->stack;
> @@ -10200,7 +10209,7 @@ static inline void callstack_update_max_depth(struct 
> r600_shader_ctx *ctx,
>   /* pre-r8xx: if any non-WQM PUSH instruction is invoked, 2 
> elements on
>* the stack must be reserved to hold the current 
> active/continue
>* masks */
> - if (reason == FC_PUSH_VPM) {
> + if (reason == FC_PUSH_VPM || stack->push > 0) {
>   elements += 2;
>   }
>   break;
> @@ -10226,7 +10235,7 @@ static inline void callstack_update_max_depth(struct 
> r600_shader_ctx *ctx,
>*NOTE: it seems we also need to reserve additional element 
> in some
>*other cases, e.g. when we have 4 levels of PUSH_VPM in 
> the shader,
>*then STACK_SIZE should be 2 instead of 1 */
> - if (reason == FC_PUSH_VPM) {
> + if (reason == FC_PUSH_VPM || stack->push > 0) {
>   elements += 1;
>   }
>   break;
> @@ -10245,6 +10254,7 @@ static inline void callstack_update_max_depth(struct 
> r600_shader_ctx *ctx,
>  
>   if (entries > stack->max_entries)
>   stack->max_entries = entries;
> + return elements;
>  }
>  
>  static inline void callstack_pop(struct r600_shader_ctx *ctx, unsigned 
> reason)
> @@ -10268,7 +10278,7 @@ static inline void callstack_pop(struct 
> r600_shader_ctx *ctx, unsigned reason)
>   }
>  }
>  
> -static inline void callstack_push(struct r600_shader_ctx *ctx, unsigned 
> reason)
> +static inline int callstack_push(struct r600_shader_ctx *ctx, unsigned 
> reason)
>  {
>   switch (reason) {
>   case FC_PUSH_VPM:
> @@ -10276,6 +10286,7 @@ static inline void callstack_push(struct 
> r600_shader_ctx *ctx, unsigned reason)
>   break;
>   case FC_PUSH_WQM:
>   ++ctx->bc->stack.push_wqm;
> + break;
>   case FC_LOOP:
>   ++ctx->bc->stack.loop;
>   break;
> @@ -10283,7 

Re: [Mesa-dev] [PATCH mesa] vulkan/wsi: clean up cleanup path

[Eric Engestrom]

On Thursday, 2018-03-08 18:16:11 +, Emil Velikov wrote:
> On 26 February 2018 at 13:51, Eric Engestrom  
> wrote:
> > Cc: Keith Packard 
> > Signed-off-by: Eric Engestrom 
> > ---
> > This will make Keith's addition much cleaner as well :)
> 
> Hey, every little helps. Fwiw
> Reviewed-by: Emil Velikov 

Thanks; pushed

> 
> Another idea - make the wsi_*_{init,fini}_wsi kernel style stubs ;-)

I'm not sure what you mean by that?

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

Re: [Mesa-dev] [PATCH mesa 01/21] vulkan: Add KHR_display extension using DRM [v4]

[Eric Engestrom]

On Thursday, 2018-03-08 10:04:03 -0800, Keith Packard wrote:
> Eric Engestrom  writes:
> 
> > I'm still slightly bothered by the build options inconsistency between
> > autotools: reuse --with-platform=drm
> > meson: new   -D platform=display
> >
> > I'd be happy with either one being used everywhere, but from what you
> > said last time I think you'd prefer to reuse `platform=drm`; can we
> > drop the meson hunks above and use `with_platform_drm` in
> > src/vulkan/wsi/meson.build?
> 
> Thanks for the reminder; I got totally bound up in Jason's code fixes
> and rebasing onto current master that I just forgot. I've got three tiny
> patches on my drm-lease-v2 branch which does this (one for core, one for
> anv, one for radv).
> 
> > About that hunk, have you looked at my patch?
> > https://patchwork.freedesktop.org/patch/206818/
> 
> Yeah, that definitely looks nicer. I've reviewed it to make sure calling
> the various finish functions is harmless when called before the matching
> init function. If it gets applied before my series, I'll adapt :-)

I just pushed it; your `if (result != VK_SUCCESS)` should now just be
`goto fail;` :)

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

Re: [Mesa-dev] [PATCH] autotools: include all meson.build files

[Emil Velikov]

On 2 March 2018 at 18:00, Dylan Baker  wrote:
> Otherwise SWR cannot be built with meson from an autotools generated
> tarball, such as the 18.0.0-rc4 tarball.
>
> CC: George Kyriazis 
> CC: Emil Velikov 
> Fixes: 16bf81383080 ("meson/swr: re-shuffle generated files")
> Signed-off-by: Dylan Baker 
> ---
>  src/gallium/drivers/swr/Makefile.am | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/drivers/swr/Makefile.am 
> b/src/gallium/drivers/swr/Makefile.am
> index 2edaf666f11..13c7f8b7345 100644
> --- a/src/gallium/drivers/swr/Makefile.am
> +++ b/src/gallium/drivers/swr/Makefile.am
> @@ -364,7 +364,9 @@ endif
>  EXTRA_DIST = \
> SConscript \
> meson.build \
> +   rasterizer/jitter/meson.build \
> rasterizer/codegen/meson.build \
> +   rasterizer/core/backends/meson.build \

Hmm I don't recall seeing these two files fly-by. Anyhow:
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH] etnaviv: allow mixing different bit depths for color and depth surfaces

[Christian Gmeiner]

2018-03-08 10:20 GMT+01:00 Lucas Stach :
> Vivante hardware supports this just fine. There is no reason why this 
> shouldn't
> be advertised as a valid combination.
>
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_screen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index f589bd44eaf4..de341c855ba5 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -139,6 +139,7 @@ etna_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
> case PIPE_CAP_TGSI_TEXCOORD:
> case PIPE_CAP_VERTEX_COLOR_UNCLAMPED:
> +   case PIPE_CAP_MIXED_COLOR_DEPTH_BITS:
>return 1;
> case PIPE_CAP_NATIVE_FENCE_FD:
>return screen->drm_version >= ETNA_DRM_VERSION_FENCE_FD;
> @@ -238,7 +239,6 @@ etna_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_MAX_WINDOW_RECTANGLES:
> case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED:
> case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS:
> -   case PIPE_CAP_MIXED_COLOR_DEPTH_BITS:
> case PIPE_CAP_TGSI_ARRAY_COMPONENTS:
> case PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS:
> case PIPE_CAP_TGSI_CAN_READ_OUTPUTS:
> --
> 2.16.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



-- 
greets
--
Christian Gmeiner, MSc

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

[Mesa-dev] [PATCH 2/2] nir/spirv: add support for the SubgroupBallotKHR SPIR-V capability

[Daniel Schürmann]

This capability is required for the VK_EXT_shader_subgroup_ballot extension.

Signed-off-by: Daniel Schürmann 
---
 src/compiler/spirv/spirv_to_nir.c |  3 +++
 src/compiler/spirv/vtn_subgroup.c | 17 ++---
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index a7e01a705b..ff32338bfe 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3936,6 +3936,9 @@ vtn_handle_body_instruction(struct vtn_builder *b, SpvOp 
opcode,
case SpvOpGroupNonUniformLogicalXor:
case SpvOpGroupNonUniformQuadBroadcast:
case SpvOpGroupNonUniformQuadSwap:
+   case SpvOpSubgroupBallotKHR:
+   case SpvOpSubgroupFirstInvocationKHR:
+   case SpvOpSubgroupReadInvocationKHR:
case SpvOpSubgroupAllKHR:
case SpvOpSubgroupAnyKHR:
case SpvOpSubgroupAllEqualKHR:
diff --git a/src/compiler/spirv/vtn_subgroup.c 
b/src/compiler/spirv/vtn_subgroup.c
index 0042217616..6a593cc3fd 100644
--- a/src/compiler/spirv/vtn_subgroup.c
+++ b/src/compiler/spirv/vtn_subgroup.c
@@ -87,12 +87,13 @@ vtn_handle_subgroup(struct vtn_builder *b, SpvOp opcode,
   break;
}
 
-   case SpvOpGroupNonUniformBallot: {
+   case SpvOpGroupNonUniformBallot: ++w;
+   case SpvOpSubgroupBallotKHR: {
   vtn_fail_if(val->type->type != glsl_vector_type(GLSL_TYPE_UINT, 4),
   "OpGroupNonUniformBallot must return a uvec4");
   nir_intrinsic_instr *ballot =
  nir_intrinsic_instr_create(b->nb.shader, nir_intrinsic_ballot);
-  ballot->src[0] = nir_src_for_ssa(vtn_ssa_value(b, w[4])->def);
+  ballot->src[0] = nir_src_for_ssa(vtn_ssa_value(b, w[3])->def);
   nir_ssa_dest_init(>instr, >dest, 4, 32, NULL);
   ballot->num_components = 4;
   nir_builder_instr_insert(>nb, >instr);
@@ -173,15 +174,17 @@ vtn_handle_subgroup(struct vtn_builder *b, SpvOp opcode,
   break;
}
 
-   case SpvOpGroupNonUniformBroadcastFirst:
+   case SpvOpGroupNonUniformBroadcastFirst: ++w;
+   case SpvOpSubgroupFirstInvocationKHR:
   vtn_build_subgroup_instr(b, nir_intrinsic_read_first_invocation,
-   val->ssa, vtn_ssa_value(b, w[4]), NULL, 0, 0);
+   val->ssa, vtn_ssa_value(b, w[3]), NULL, 0, 0);
   break;
 
-   case SpvOpGroupNonUniformBroadcast:
+   case SpvOpGroupNonUniformBroadcast: ++w;
+   case SpvOpSubgroupReadInvocationKHR:
   vtn_build_subgroup_instr(b, nir_intrinsic_read_invocation,
-   val->ssa, vtn_ssa_value(b, w[4]),
-   vtn_ssa_value(b, w[5])->def, 0, 0);
+   val->ssa, vtn_ssa_value(b, w[3]),
+   vtn_ssa_value(b, w[4])->def, 0, 0);
   break;
 
case SpvOpGroupNonUniformAll:
-- 
2.14.1

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

[Mesa-dev] [PATCH 1/2] nir/spirv: add support for the SubgroupVoteKHR SPIR-V capability

[Daniel Schürmann]

This capability is required for the VK_EXT_shader_subgroup_vote extension.

Signed-off-by: Daniel Schürmann 
---
 src/compiler/spirv/spirv_to_nir.c |  4 
 src/compiler/spirv/vtn_subgroup.c | 20 
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 6a358c5973..a7e01a705b 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3299,6 +3299,7 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
  spv_check_supported(subgroup_basic, cap);
  break;
 
+  case SpvCapabilitySubgroupVoteKHR:
   case SpvCapabilityGroupNonUniformVote:
  spv_check_supported(subgroup_vote, cap);
  break;
@@ -3935,6 +3936,9 @@ vtn_handle_body_instruction(struct vtn_builder *b, SpvOp 
opcode,
case SpvOpGroupNonUniformLogicalXor:
case SpvOpGroupNonUniformQuadBroadcast:
case SpvOpGroupNonUniformQuadSwap:
+   case SpvOpSubgroupAllKHR:
+   case SpvOpSubgroupAnyKHR:
+   case SpvOpSubgroupAllEqualKHR:
   vtn_handle_subgroup(b, opcode, w, count);
   break;
 
diff --git a/src/compiler/spirv/vtn_subgroup.c 
b/src/compiler/spirv/vtn_subgroup.c
index 73420b7e43..0042217616 100644
--- a/src/compiler/spirv/vtn_subgroup.c
+++ b/src/compiler/spirv/vtn_subgroup.c
@@ -186,18 +186,24 @@ vtn_handle_subgroup(struct vtn_builder *b, SpvOp opcode,
 
case SpvOpGroupNonUniformAll:
case SpvOpGroupNonUniformAny:
-   case SpvOpGroupNonUniformAllEqual: {
+   case SpvOpGroupNonUniformAllEqual:
+   case SpvOpSubgroupAllKHR:
+   case SpvOpSubgroupAnyKHR:
+   case SpvOpSubgroupAllEqualKHR: {
   vtn_fail_if(val->type->type != glsl_bool_type(),
   "OpGroupNonUniform(All|Any|AllEqual) must return a bool");
   nir_intrinsic_op op;
   switch (opcode) {
   case SpvOpGroupNonUniformAll:
+  case SpvOpSubgroupAllKHR:
  op = nir_intrinsic_vote_all;
  break;
   case SpvOpGroupNonUniformAny:
+  case SpvOpSubgroupAnyKHR:
  op = nir_intrinsic_vote_any;
  break;
-  case SpvOpGroupNonUniformAllEqual: {
+  case SpvOpGroupNonUniformAllEqual:
+  case SpvOpSubgroupAllEqualKHR: {
  switch (glsl_get_base_type(val->type->type)) {
  case GLSL_TYPE_FLOAT:
  case GLSL_TYPE_DOUBLE:
@@ -219,8 +225,14 @@ vtn_handle_subgroup(struct vtn_builder *b, SpvOp opcode,
  unreachable("Unhandled opcode");
   }
 
-  nir_ssa_def *src0 = vtn_ssa_value(b, w[4])->def;
-
+  nir_ssa_def *src0;
+  if (opcode == SpvOpGroupNonUniformAll ||
+  opcode == SpvOpGroupNonUniformAny ||
+  opcode == SpvOpGroupNonUniformAllEqual) {
+ src0 = vtn_ssa_value(b, w[4])->def;
+ } else {
+ src0 = vtn_ssa_value(b, w[3])->def;
+  }
   nir_intrinsic_instr *intrin =
  nir_intrinsic_instr_create(b->nb.shader, op);
   intrin->num_components = src0->num_components;
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH 1/2] nir: add nir_opt_move_load_ubo() optimization pass

[Samuel Pitoiset]

On 03/08/2018 11:48 PM, Ian Romanick wrote:

On 03/08/2018 06:50 AM, Samuel Pitoiset wrote:

This pass moves load UBO operations just before their first use,
loosely based on nir_opt_move_comparisons.


If I'm reading this correctly, it moves UBO loads closer to the first
use in the same block.  My assumption is the benefit in the next patch
occurs because live ranges are smaller.  It seems like this could also
hurt performance since it may be harder for the schedule to hide the
latency of the load when register pressure is not an issue.  Have you
measured performance of running apps to see if this is an issue?

I'm mostly asking because Jason had a series for global code motion that
does, in some cases, the opposite of this patch by moving UBO loads up
to earlier blocks.


Yeah, it's definitely not perfect but I have noticed that a bunch of 
shaders load a ton of constants from UBOs at beginning, which might 
explain why we (RADV) spill. Though, this is probably not the only issue.


The RADV shader stats are nice from my point of view, but according to 
Timothy's comment we should probably have a deeper look in there.


Thanks!




Signed-off-by: Samuel Pitoiset 
---
  src/compiler/Makefile.sources|   1 +
  src/compiler/nir/meson.build |   1 +
  src/compiler/nir/nir.h   |   2 +
  src/compiler/nir/nir_opt_move_load_ubo.c | 116 +++
  4 files changed, 120 insertions(+)
  create mode 100644 src/compiler/nir/nir_opt_move_load_ubo.c

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 37340ba809..55143dbc66 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -266,6 +266,7 @@ NIR_FILES = \
nir/nir_opt_intrinsics.c \
nir/nir_opt_loop_unroll.c \
nir/nir_opt_move_comparisons.c \
+   nir/nir_opt_move_load_ubo.c \
nir/nir_opt_peephole_select.c \
nir/nir_opt_remove_phis.c \
nir/nir_opt_shrink_load.c \
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index a70c236b95..289bb9ea78 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -160,6 +160,7 @@ files_libnir = files(
'nir_opt_intrinsics.c',
'nir_opt_loop_unroll.c',
'nir_opt_move_comparisons.c',
+  'nir_opt_move_load_ubo.c',
'nir_opt_peephole_select.c',
'nir_opt_remove_phis.c',
'nir_opt_shrink_load.c',
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 5b28c727c8..4224da5f82 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2786,6 +2786,8 @@ bool nir_opt_loop_unroll(nir_shader *shader, 
nir_variable_mode indirect_mask);
  
  bool nir_opt_move_comparisons(nir_shader *shader);
  
+bool nir_opt_move_load_ubo(nir_shader *shader);

+
  bool nir_opt_peephole_select(nir_shader *shader, unsigned limit);
  
  bool nir_opt_remove_phis(nir_shader *shader);

diff --git a/src/compiler/nir/nir_opt_move_load_ubo.c 
b/src/compiler/nir/nir_opt_move_load_ubo.c
new file mode 100644
index 00..642651152b
--- /dev/null
+++ b/src/compiler/nir/nir_opt_move_load_ubo.c
@@ -0,0 +1,116 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ * Copyright © 2018 Valve Corporation
+ *
+ * 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 "nir.h"
+
+/**
+ * \file nir_opt_move_load_ubo.c
+ *
+ * This pass moves load UBO operations just before their first use.
+ */
+static bool
+move_load_ubo_source(nir_src *src, nir_block *block, nir_instr *before)
+{
+   if (!src->is_ssa)
+  return false;
+
+   nir_instr *src_instr = src->ssa->parent_instr;
+
+   if (src_instr->block == block &&
+   src_instr->type == nir_instr_type_intrinsic &&
+   nir_instr_as_intrinsic(src_instr)->intrinsic == nir_intrinsic_load_ubo) 
{
+
+  exec_node_remove(_instr->node);
+
+  if (before)
+ 

[Mesa-dev] [Bug 105412] [OpenGL] [HD 7790] - VSYNC always ON in all videogames

[bugzilla-daemon]

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

--- Comment #1 from Michel Dänzer  ---
Please attach the Xorg log file and the output of dmesg and

 LIBGL_DEBUG=verbose vblank_mode=0 glxgears -info

-- 
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 2/2] radv: run nir_opt_move_load_ubo

[Samuel Pitoiset]

The spilled SGPRs/VGPRs is quite nice, but yes the VGPRs increase is not 
totally good, this is why the number of waves decreased...


On 03/08/2018 11:42 PM, Timothy Arceri wrote:
I gave this a run on radeonsi and the results were mixed. On the one 
hand we reduced some spills on the other hand we increase VGPR use and 
max waves dropped. I wonder if we should look more closely into whats 
going on here.


72280 shaders in 43328 tests
Totals:
SGPRS: 2930328 -> 2922464 (-0.27 %)
VGPRS: 1736292 -> 1738480 (0.13 %)
Spilled SGPRs: 9430 -> 8917 (-5.44 %)
Spilled VGPRs: 57 -> 53 (-7.02 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 48 -> 40 (-16.67 %) dwords per thread
Code Size: 63877120 -> 63762236 (-0.18 %) bytes
LDS: 438 -> 438 (0.00 %) blocks
Max Waves: 556299 -> 555981 (-0.06 %)
Wait states: 0 -> 0 (0.00 %)

On 09/03/18 01:50, Samuel Pitoiset wrote:

Polaris10:
Totals from affected shaders:
SGPRS: 106656 -> 105952 (-0.66 %)
VGPRS: 73464 -> 73400 (-0.09 %)
Spilled SGPRs: 7121 -> 6861 (-3.65 %)
Code Size: 4157792 -> 4158716 (0.02 %) bytes
Max Waves: 9316 -> 9330 (0.15 %)

Vega10:
Totals from affected shaders:
SGPRS: 106720 -> 106032 (-0.64 %)
VGPRS: 67828 -> 67752 (-0.11 %)
Spilled SGPRs: 7113 -> 6853 (-3.66 %)
Code Size: 3704432 -> 3705112 (0.02 %) bytes
Max Waves: 10547 -> 10571 (0.23 %)

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

diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 85672e600d..6a1db81660 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -152,6 +152,7 @@ radv_optimize_nir(struct nir_shader *shader)
  } while (progress);
  NIR_PASS(progress, shader, nir_opt_shrink_load);
+    NIR_PASS(progress, shader, nir_opt_move_load_ubo);
  }
  nir_shader *


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

Re: [Mesa-dev] [PATCH 04/56] anv/entrypoints: Generalize the string map a bit

[Michel Dänzer]

On 2018-03-08 07:53 PM, Jason Ekstrand wrote:
> On Thu, Mar 8, 2018 at 8:45 AM, Dylan Baker  > wrote:
> 
> > I know we've always given a lot of flexibility to vendor specific code
> > (i965 or nouveau), but you hope everyone can understand my frustration
> > with a 56 patch series that I sent review for 8 hours after it was
> > posted to the list and I got told "Oh, I merged that hours ago,
> > patches welcome."
> 
> I can. I guess Jason got a bit carried away by the Vulkan 1.1
> excitement.
> 
> 
> Perhaps.  :-)  I do think that being there day-1 is important.

The code was there on day 1 anyway. If being available in Git ASAP is
that important (not sure why though), it can be made available in a
repository other than the main shared one.


> If nothing else, it shows the rest of the graphics community (who already
> fears the concept of open-source) that working in the open isn't going
> to cramp their style.

It wasn't following the normal Mesa development process, so I'm not sure
it's really useful for showing anything about that to anyone.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] nir: add support for min/max/median of 3 srcs

[Samuel Pitoiset]

For the series:

Reviewed-by: Samuel Pitoiset 

On 03/08/2018 11:14 PM, Daniel Schürmann wrote:

From: Dave Airlie 

These are needed for SPV_AMD_shader_trinary_minmax,
the AMD HW supports these.

Co-authored-by: Daniel Schürmann 
Signed-off-by: Dave Airlie 
---
  src/compiler/nir/nir_opcodes.py | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index 65d1320062..fdf90ef3f5 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -658,6 +658,20 @@ triop("flrp", tfloat, "src0 * (1 - src2) + src1 * src2")
  
  
  triop("fcsel", tfloat32, "(src0 != 0.0f) ? src1 : src2")

+
+# 3 way min/max/med
+triop("fmin3", tfloat, "fminf(src0, fminf(src1, src2))")
+triop("imin3", tint, "MIN2(src0, MIN2(src1, src2))")
+triop("umin3", tuint, "MIN2(src0, MIN2(src1, src2))")
+
+triop("fmax3", tfloat, "fmaxf(src0, fmaxf(src1, src2))")
+triop("imax3", tint, "MAX2(src0, MAX2(src1, src2))")
+triop("umax3", tuint, "MAX2(src0, MAX2(src1, src2))")
+
+triop("fmed3", tfloat, "fmaxf(fminf(fmaxf(src0, src1), src2), fminf(src0, 
src1))")
+triop("imed3", tint, "MAX2(MIN2(MAX2(src0, src1), src2), MIN2(src0, src1))")
+triop("umed3", tuint, "MAX2(MIN2(MAX2(src0, src1), src2), MIN2(src0, src1))")
+
  opcode("bcsel", 0, tuint, [0, 0, 0],
[tbool, tuint, tuint], "", "src0 ? src1 : src2")
  


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

Re: [Mesa-dev] [PATCH] radv: Fix autotools build.

[Samuel Pitoiset]

Acked-by: Samuel Pitoiset 

Can you please push this asap?

On 03/09/2018 08:44 AM, Bas Nieuwenhuizen wrote:

Forgot it again 

Fixes: b6347807a9 "radv: Generate icd files."
---
  src/amd/vulkan/Makefile.am | 17 +++--
  1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
index 80937e38d3..99d9e578d8 100644
--- a/src/amd/vulkan/Makefile.am
+++ b/src/amd/vulkan/Makefile.am
@@ -142,10 +142,9 @@ BUILT_SOURCES = $(VULKAN_GENERATED_FILES)
  CLEANFILES = $(BUILT_SOURCES) dev_icd.json radeon_icd.@host_cpu@.json
  EXTRA_DIST = \
$(top_srcdir)/include/vulkan/vk_icd.h \
-   dev_icd.json.in \
-   radeon_icd.json.in \
radv_entrypoints_gen.py \
radv_extensions.py \
+   radv_icd.py \
vk_format_layout.csv \
vk_format_parse.py \
vk_format_table.py \
@@ -169,14 +168,12 @@ icdconf_DATA = radeon_icd.@host_cpu@.json
  # The following is used for development purposes, by setting VK_ICD_FILENAMES.
  noinst_DATA = dev_icd.json
  
-dev_icd.json : dev_icd.json.in

-   $(AM_V_GEN) $(SED) \
-   -e 
"s#@libvulkan_radeon_path@#${abs_top_builddir}/${LIB_DIR}/libvulkan_radeon.so#" 
\
-   < $(srcdir)/dev_icd.json.in > $@
+dev_icd.json : radv_extensions.py radv_icd.py
+   $(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_icd.py \
+   --lib-path="${abs_top_builddir}/${LIB_DIR}" --out $@
  
-radeon_icd.@host_cpu@.json : radeon_icd.json.in

-   $(AM_V_GEN) $(SED) \
-   -e "s#@install_libdir@#${libdir}#" \
-   < $(srcdir)/radeon_icd.json.in > $@
+vulkan/radeon_icd.@host_cpu@.json : radv_extensions.py radv_icd.py
+   $(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_icd.py \
+   --lib-path="${libdir}" --out $@
  
  include $(top_srcdir)/install-lib-links.mk



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

Re: [Mesa-dev] [PATCH 4/4] radv: enable VK_AMD_shader_trinary_minmax extension

[Bas Nieuwenhuizen]

With the comments that have already been made resolved:

Reviewed-by: Bas Nieuwenhuizen 

for the series.

On Thu, Mar 8, 2018 at 11:14 PM, Daniel Schürmann
 wrote:
> ---
>  src/amd/vulkan/radv_extensions.py | 1 +
>  src/amd/vulkan/radv_shader.c  | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_extensions.py 
> b/src/amd/vulkan/radv_extensions.py
> index 469b09a160..12efaa04c6 100644
> --- a/src/amd/vulkan/radv_extensions.py
> +++ b/src/amd/vulkan/radv_extensions.py
> @@ -94,6 +94,7 @@ EXTENSIONS = [
>  Extension('VK_AMD_gcn_shader',1, True),
>  Extension('VK_AMD_rasterization_order',   1, 
> 'device->rad_info.chip_class >= VI && device->rad_info.max_se >= 2'),
>  Extension('VK_AMD_shader_info',   1, True),
> +Extension('VK_AMD_shader_trinary_minmax', 1, True),
>  ]
>
>  class VkVersion:
> diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
> index 85672e600d..9073b7d043 100644
> --- a/src/amd/vulkan/radv_shader.c
> +++ b/src/amd/vulkan/radv_shader.c
> @@ -214,6 +214,7 @@ radv_shader_compile_to_nir(struct radv_device *device,
> .multiview = true,
> .subgroup_basic = true,
> .variable_pointers = true,
> +   .AMD_shader_trinary_minmax = true,
> },
> .exts = {
> .AMD_gcn_shader = true,
> --
> 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

Re: [Mesa-dev] [PATCH] radv: implement multisample image copies

[Bas Nieuwenhuizen]

Hi Dave,

I'd appreciate if you could split all the ac stuff into a separate patch.

The big issue I see with the patch is that we don't support
multisample image stores yet. In particular, you have to copy over the
fmask value (and find a way to skip over the fmask lookup in the tex
instruction) or clear the fmask just for the dst rect.

- Bas

On Fri, Mar 9, 2018 at 7:30 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> It appears its quite legal to do image copies on multisample
> images, however due to a bug in our txf handling and incomplete
> tests we never actually noticed we didn't do it properly in radv.
>
> This patch implements a compute shader to copy multiple samples
> of an image to another image. It implements the nir txf_ms_mcs
> opcode for getting the fmask value, and then uses that value
> to either copy sample 0 to all samples, or iterate across
> the valid samples copying them.
>
> The shader is inspired by one RE'd from AMDVLK.
>
> Fixes:
> dEQP-VK.api.copy_and_blit.core.resolve_image.whole_array_image*
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_nir_to_llvm.c |  54 ++---
>  src/amd/vulkan/radv_meta_bufimage.c | 229 
> ++--
>  src/amd/vulkan/radv_meta_copy.c |   2 +-
>  src/amd/vulkan/radv_private.h   |   2 +-
>  4 files changed, 258 insertions(+), 29 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 9b850698608..071f54a5b61 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -2277,6 +2277,7 @@ static LLVMValueRef build_tex_intrinsic(struct 
> ac_nir_context *ctx,
> switch (instr->op) {
> case nir_texop_txf:
> case nir_texop_txf_ms:
> +   case nir_texop_txf_ms_mcs:
> case nir_texop_samples_identical:
> args->opcode = lod_is_zero ||
>instr->sampler_dim == GLSL_SAMPLER_DIM_MS ?
> @@ -3417,6 +3418,24 @@ glsl_is_array_image(const struct glsl_type *type)
>  }
>
>
> +static LLVMValueRef get_fmask_desc_valid(struct ac_llvm_context *ctx,
> +   LLVMValueRef fmask_desc_ptr)
> +{
> +   LLVMValueRef fmask_desc =
> +   LLVMBuildBitCast(ctx->builder, fmask_desc_ptr,
> +ctx->v8i32, "");
> +
> +   LLVMValueRef fmask_word1 =
> +   LLVMBuildExtractElement(ctx->builder, fmask_desc,
> +   ctx->i32_1, "");
> +
> +   LLVMValueRef word1_is_nonzero =
> +   LLVMBuildICmp(ctx->builder, LLVMIntNE,
> + fmask_word1, ctx->i32_0, "");
> +
> +   return word1_is_nonzero;
> +}
> +
>  /* Adjust the sample index according to FMASK.
>   *
>   * For uncompressed MSAA surfaces, FMASK should return 0x76543210,
> @@ -3475,17 +3494,7 @@ static LLVMValueRef 
> adjust_sample_index_using_fmask(struct ac_llvm_context *ctx,
> /* Don't rewrite the sample index if WORD1.DATA_FORMAT of the FMASK
>  * resource descriptor is 0 (invalid),
>  */
> -   LLVMValueRef fmask_desc =
> -   LLVMBuildBitCast(ctx->builder, fmask_desc_ptr,
> -ctx->v8i32, "");
> -
> -   LLVMValueRef fmask_word1 =
> -   LLVMBuildExtractElement(ctx->builder, fmask_desc,
> -   ctx->i32_1, "");
> -
> -   LLVMValueRef word1_is_nonzero =
> -   LLVMBuildICmp(ctx->builder, LLVMIntNE,
> - fmask_word1, ctx->i32_0, "");
> +   LLVMValueRef word1_is_nonzero = get_fmask_desc_valid(ctx, 
> fmask_desc_ptr);
>
> /* Replace the MSAA sample index. */
> sample_index =
> @@ -3518,7 +3527,7 @@ static LLVMValueRef get_image_coords(struct 
> ac_nir_context *ctx,
> bool gfx9_1d = ctx->ac.chip_class >= GFX9 && dim == 
> GLSL_SAMPLER_DIM_1D;
> count = image_type_to_components_count(dim, is_array);
>
> -   if (is_ms) {
> +   if (is_ms && instr->intrinsic == nir_intrinsic_image_load) {
> LLVMValueRef fmask_load_address[3];
> int chan;
>
> @@ -4899,7 +4908,7 @@ static void tex_fetch_ptrs(struct ac_nir_context *ctx,
> if (instr->sampler_dim < GLSL_SAMPLER_DIM_RECT)
> *samp_ptr = sici_fix_sampler_aniso(ctx, *res_ptr, 
> *samp_ptr);
> }
> -   if (fmask_ptr && !instr->sampler && (instr->op == nir_texop_txf_ms ||
> +   if (fmask_ptr && !instr->sampler && (instr->op == nir_texop_txf_ms || 
> instr->op == nir_texop_txf_ms_mcs ||
>  instr->op == 
> nir_texop_samples_identical))
> *fmask_ptr = get_sampler_desc(ctx, instr->texture, 
> AC_DESC_FMASK, instr, false, false);
>  }
> @@ -5150,7 +5159,7 @@ static void visit_tex(struct ac_nir_context *ctx, 
> nir_tex_instr *instr)
>