Re: [Mesa-dev] [PATCH 02/12] i965/urb: Trigger upload_urb on NEW_BLORP

[Jason Ekstrand]

On Sat, Jul 1, 2017 at 8:13 PM, Kenneth Graunke 
wrote:

> On Monday, June 26, 2017 4:22:35 PM PDT Ian Romanick wrote:
> > From: Jason Ekstrand 
> >
> > It's a bit rare, but blorp can trigger a urb reconfiguration.  When that
> > happens, we need to re-upload the URB config.  Fortunately, this isn't as
> > bad as it looks because gen7_upload_urb will not re-emit the packet if it
> > would end up being a no-op so this doesn't mean that running blorp always
> > triggers a URB reconfig.
> >
> > v2 (idr): Sort BRW_NEW_ tokens to match brw_recalculate_urb_fence and
> > gen6_urb.
> >
> > v3 (idr): Don't whack BRW_NEW_URB_SIZE in blorp.  Suggested by Jason.
> > ---
> >  src/mesa/drivers/dri/i965/gen7_urb.c| 3 ++-
> >  src/mesa/drivers/dri/i965/genX_blorp_exec.c | 2 --
> >  2 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c
> b/src/mesa/drivers/dri/i965/gen7_urb.c
> > index 525c9c4..c4b479c 100644
> > --- a/src/mesa/drivers/dri/i965/gen7_urb.c
> > +++ b/src/mesa/drivers/dri/i965/gen7_urb.c
> > @@ -236,7 +236,8 @@ gen7_upload_urb(struct brw_context *brw, unsigned
> vs_size,
> >  const struct brw_tracked_state gen7_urb = {
> > .dirty = {
> >.mesa = 0,
> > -  .brw = BRW_NEW_CONTEXT |
> > +  .brw = BRW_NEW_BLORP |
> > + BRW_NEW_CONTEXT |
> >   BRW_NEW_URB_SIZE |
> >   BRW_NEW_GS_PROG_DATA |
> >   BRW_NEW_TCS_PROG_DATA |
> > diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> > index 8fd17fb..af3d609 100644
> > --- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> > +++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> > @@ -183,8 +183,6 @@ blorp_emit_urb_config(struct blorp_batch *batch,
> > brw->urb.vsize >= vs_entry_size)
> >return;
> >
> > -   brw->ctx.NewDriverState |= BRW_NEW_URB_SIZE;
> > -
> > gen7_upload_urb(brw, vs_entry_size, false, false);
> >  #elif GEN_GEN == 6
> > gen6_upload_urb(brw, vs_entry_size, false, 0);
> >
>
> The commit message is a bit confusing.  It makes it sound like we were
> failing to re-emit 3DSTATE_URB_* from the main drawing path after BLORP
> trashed it.  However, the brw->ctx.NewDriverState |= BRW_NEW_URB_SIZE
> line that you deleted here guaranteed that it would happen.
>
> The real benefit appears to be that flagging BRW_NEW_URB_SIZE ("the
> total size of the URB portion of the L3 cache has changed") causes
> BLORP to think it needs to re-configure it again, so say, back-to-back
> BLORP operations would configure it every time.
>

You are correct, sir.  Originally the patch didn't have the second hunk and
the commit message made sense even though it was wrong.  With the hunk
added, a new commit message would be good.


> Using BRW_NEW_BLORP is definitely better - that's what it's there for.
>
> Reviewed-by: Kenneth Graunke 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 1/3] util: Add util_strncpy

[Robert Foss]

On Sun, 2017-07-02 at 21:06 -0700, Matt Turner wrote:
> Otherwise known as strlcpy()?

I didn't realize this, a wrapper would be needed for all platformsou 
that don't support it natively.

Do you know which platforms support strlcpy?


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

Re: [Mesa-dev] [PATCH v3 1/3] util: Add util_strncpy

[Matt Turner]

On Sun, Jul 2, 2017 at 8:49 PM, Robert Foss  wrote:
> Add strncpy wrapper that makes sure that the string is always ends
> with a null byte.

Otherwise known as strlcpy()?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Why are we using server-side GLX fbconfigs?

[Michel Dänzer]

On 01/07/17 02:16 AM, Kristian Høgsberg wrote:
> On Fri, Jun 30, 2017 at 2:49 AM, Thomas Hellstrom  
> wrote:
>> On 06/29/2017 07:30 PM, Kristian Høgsberg wrote:
>>> On Thu, Jun 29, 2017 at 7:36 AM, Thomas Hellstrom 
>>> wrote:

 Hi!

 I was spending some time going through the GLX code to try to fix up the
 GLX_OML_swap_method extension implementation.

 I then stumbled across the fact that when we, for direct rendering
 connections, construct the list of fbconfigs, we start out with the
 server
 provided fbconfigs from the AIGLX driver and then try to match each
 fbconfig
 with a corresponding client driver driconfig. Effectively making us use
 the
 intersection of the server AIGLX capabilities and the client Direct
 rendering capabilities.

 Wouldn't it be more correct, or at least "better" if we, for direct
 rendering, took a list of client driver driconfigs, matched each with a
 server provided visual and if we have a match, built an fbconfig from
 that
 driconfig? That would make us essentialy exposing all client driver
 capabilities regardless of what the server is using, as long as we have a
 matching visual?

 Any insights into this would be greatly appreciated.
>>>
>>> I'm largely to blame for that. Historically it was part me trying to
>>> keep things working they did before as well as having to pay more
>>> attention to server side configs as DRI2 tried to share aux buffers
>>> (not just color) between clients. I think mesa today only shares color
>>> buffers with DRI2 and DRI3 is obviously fine, so what you're proposing
>>> sounds like a nice simplification of the code as well as something
>>> that might expose more configs to the client.
>>>
>>> Kristian
>>
>>
>> OK. Thanks Kristian.
>>
>> FWIW, from what I can tell, dri3 only shares the real front. Has dri2 been
>> modified to also allocate local buffers?
> 
> No, DRI2 still uses DRI2GetBuffers or DRI2GetBuffersWithFormat to ask
> the X server to allocate buffers, which then shares the buffers with
> the client by sending the gem name back in the reply.

True for the back and fake front buffers, but Mesa no longer uses this
mechanism for other (mostly depth/stencil) buffers.


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

[Mesa-dev] [PATCH v3 2/3] gallium/hud: Prevent buffer overflow in hud_thread_counter_install

[Robert Foss]

Switch to using util_strncpy to avoid potential overflow of
name array in struct hud_graph.

Also extract the name element length into a define so that it can
be used for strncpy et al.

Coverity-id: 1413761

Signed-off-by: Robert Foss 
---
Changes since v2:
  Brian Paul 
- Combined patch with precious patch that only added define
- Switched to using new util_strncpy function

 src/gallium/auxiliary/hud/hud_cpu.c | 3 ++-
 src/gallium/auxiliary/hud/hud_private.h | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/hud/hud_cpu.c 
b/src/gallium/auxiliary/hud/hud_cpu.c
index 4caaab6977..0a4ebf93bc 100644
--- a/src/gallium/auxiliary/hud/hud_cpu.c
+++ b/src/gallium/auxiliary/hud/hud_cpu.c
@@ -33,6 +33,7 @@
 #include "os/os_thread.h"
 #include "util/u_memory.h"
 #include "util/u_queue.h"
+#include "util/u_string.h"
 #include 
 #include 
 #ifdef PIPE_OS_WINDOWS
@@ -362,7 +363,7 @@ void hud_thread_counter_install(struct hud_pane *pane, 
const char *name,
if (!gr)
   return;
 
-   strcpy(gr->name, name);
+   util_strncpy(gr->name, name, HUD_GRAPH_NAME_LEN);
 
gr->query_data = CALLOC_STRUCT(counter_info);
if (!gr->query_data) {
diff --git a/src/gallium/auxiliary/hud/hud_private.h 
b/src/gallium/auxiliary/hud/hud_private.h
index 2b1717d2c4..3a958d3146 100644
--- a/src/gallium/auxiliary/hud/hud_private.h
+++ b/src/gallium/auxiliary/hud/hud_private.h
@@ -87,6 +87,7 @@ struct hud_context {
bool has_srgb;
 };
 
+#define HUD_GRAPH_NAME_LEN 128
 struct hud_graph {
/* initialized by common code */
struct list_head head;
@@ -95,7 +96,7 @@ struct hud_graph {
float *vertices; /* ring buffer of vertices */
 
/* name and query */
-   char name[128];
+   char name[HUD_GRAPH_NAME_LEN];
void *query_data;
void (*begin_query)(struct hud_graph *gr);
void (*query_new_value)(struct hud_graph *gr);
-- 
2.11.0

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

[Mesa-dev] [PATCH v3 3/3] gallium/hud: Prevent buffer overflow in hud_thread_busy_install

[Robert Foss]

Switch to using util_strncat to avoid potential overflow of
name array in struct hud_graph.

Coverity-id: 1413760

Signed-off-by: Robert Foss 
---
Changes since v2:
  Brian Paul 
   - Switch to using new util_strncpy function

Changes since v1:
  Gustaw Smolarczyk 
  - Fix strcpy -> strncpy typo

 src/gallium/auxiliary/hud/hud_cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/hud/hud_cpu.c 
b/src/gallium/auxiliary/hud/hud_cpu.c
index 0a4ebf93bc..64836dab2c 100644
--- a/src/gallium/auxiliary/hud/hud_cpu.c
+++ b/src/gallium/auxiliary/hud/hud_cpu.c
@@ -289,7 +289,7 @@ hud_thread_busy_install(struct hud_pane *pane, const char 
*name, bool main)
if (!gr)
   return;
 
-   strcpy(gr->name, name);
+   util_strncpy(gr->name, name, HUD_GRAPH_NAME_LEN);
 
gr->query_data = CALLOC_STRUCT(thread_info);
if (!gr->query_data) {
-- 
2.11.0

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

[Mesa-dev] [PATCH v3 1/3] util: Add util_strncpy

[Robert Foss]

Add strncpy wrapper that makes sure that the string is always ends
with a null byte.

Signed-off-by: Robert Foss 
---
Changes since v2:
  Brian Paul 
- Patch added

 src/util/u_string.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/util/u_string.h b/src/util/u_string.h
index e88e13f42c..a8fb92174e 100644
--- a/src/util/u_string.h
+++ b/src/util/u_string.h
@@ -48,6 +48,15 @@
 extern "C" {
 #endif
 
+static inline char*
+util_strncpy(char *dst, const char *src, size_t n)
+{
+   strncpy(dst, src, n);
+   dst[n-1] = '\0';
+
+   return dst;
+}
+
 #ifdef _GNU_SOURCE
 
 #define util_strchrnul strchrnul
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH 06/92] nir/lower_system_values: add support for the FRAG_COORD system value

[Timothy Arceri]

On 03/07/17 10:46, Timothy Arceri wrote:
This and the previous patch seem a bit hacky to me. It seems it would be 
better to either plum the system value all the way through NIR for all 
drivers or simply disable GLSLFragCoordIsSysVal when radeonsi is going 
to be using the NIR path.


Well maybe not disable, but surely we could ignore it.



On 27/06/17 00:09, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

Arguably this could convert to a load intrinsic, but other code paths
already expect this as a fragment shader input.
---
  src/compiler/nir/nir_lower_system_values.c | 36 
++

  1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/src/compiler/nir/nir_lower_system_values.c 
b/src/compiler/nir/nir_lower_system_values.c

index 810100a..64a1354 100644
--- a/src/compiler/nir/nir_lower_system_values.c
+++ b/src/compiler/nir/nir_lower_system_values.c
@@ -21,22 +21,46 @@
   * IN THE SOFTWARE.
   *
   * Authors:
   *Connor Abbott (cwabbo...@gmail.com)
   *
   */
  #include "nir.h"
  #include "nir_builder.h"
+static nir_ssa_def *
+get_frag_coord(nir_builder *b, nir_shader *shader, nir_variable *orig)
+{
+   nir_variable *pos = NULL;
+
+   assert(shader->stage == MESA_SHADER_FRAGMENT);
+
+   nir_foreach_variable(var, >inputs) {
+  if (var->data.location == VARYING_SLOT_POS) {
+ pos = var;
+ break;
+  }
+   }
+
+   if (!pos) {
+  pos = nir_variable_create(shader, nir_var_shader_in, 
glsl_vec4_type(), "gl_FragCoord");

+  pos->data.location = VARYING_SLOT_POS;
+  pos->data.pixel_center_integer = orig->data.pixel_center_integer;
+  pos->data.origin_upper_left = orig->data.origin_upper_left;
+   }
+
+   return nir_load_var(b, pos);
+}
+
  static bool
-convert_block(nir_block *block, nir_builder *b)
+convert_block(nir_block *block, nir_builder *b, nir_shader *shader)
  {
 bool progress = false;
 nir_foreach_instr_safe(instr, block) {
if (instr->type != nir_instr_type_intrinsic)
   continue;
nir_intrinsic_instr *load_var = nir_instr_as_intrinsic(instr);
if (load_var->intrinsic != nir_intrinsic_load_var)
@@ -109,59 +133,63 @@ convert_block(nir_block *block, nir_builder *b)
  sysval = nir_load_vertex_id(b);
   }
   break;
case SYSTEM_VALUE_INSTANCE_INDEX:
   sysval = nir_iadd(b,
 nir_load_instance_id(b),
 nir_load_base_instance(b));
   break;
+  case SYSTEM_VALUE_FRAG_COORD:
+ sysval = get_frag_coord(b, shader, var);
+ break;
+
default:
   break;
}
if (sysval == NULL) {
   nir_intrinsic_op sysval_op =
  nir_intrinsic_from_system_value(var->data.location);
   sysval = nir_load_system_value(b, sysval_op, 0);
}
nir_ssa_def_rewrite_uses(_var->dest.ssa, 
nir_src_for_ssa(sysval));

nir_instr_remove(_var->instr);
progress = true;
 }
 return progress;
  }
  static bool
-convert_impl(nir_function_impl *impl)
+convert_impl(nir_function_impl *impl, nir_shader *shader)
  {
 bool progress = false;
 nir_builder builder;
 nir_builder_init(, impl);
 nir_foreach_block(block, impl) {
-  progress |= convert_block(block, );
+  progress |= convert_block(block, , shader);
 }
 nir_metadata_preserve(impl, nir_metadata_block_index |
 nir_metadata_dominance);
 return progress;
  }
  bool
  nir_lower_system_values(nir_shader *shader)
  {
 bool progress = false;
 nir_foreach_function(function, shader) {
if (function->impl)
- progress = convert_impl(function->impl) || progress;
+ progress = convert_impl(function->impl, shader) || progress;
 }
 exec_list_make_empty(>system_values);
 return progress;
  }


___
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 06/92] nir/lower_system_values: add support for the FRAG_COORD system value

[Timothy Arceri]

This and the previous patch seem a bit hacky to me. It seems it would be 
better to either plum the system value all the way through NIR for all 
drivers or simply disable GLSLFragCoordIsSysVal when radeonsi is going 
to be using the NIR path.


On 27/06/17 00:09, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

Arguably this could convert to a load intrinsic, but other code paths
already expect this as a fragment shader input.
---
  src/compiler/nir/nir_lower_system_values.c | 36 ++
  1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/src/compiler/nir/nir_lower_system_values.c 
b/src/compiler/nir/nir_lower_system_values.c
index 810100a..64a1354 100644
--- a/src/compiler/nir/nir_lower_system_values.c
+++ b/src/compiler/nir/nir_lower_system_values.c
@@ -21,22 +21,46 @@
   * IN THE SOFTWARE.
   *
   * Authors:
   *Connor Abbott (cwabbo...@gmail.com)
   *
   */
  
  #include "nir.h"

  #include "nir_builder.h"
  
+static nir_ssa_def *

+get_frag_coord(nir_builder *b, nir_shader *shader, nir_variable *orig)
+{
+   nir_variable *pos = NULL;
+
+   assert(shader->stage == MESA_SHADER_FRAGMENT);
+
+   nir_foreach_variable(var, >inputs) {
+  if (var->data.location == VARYING_SLOT_POS) {
+ pos = var;
+ break;
+  }
+   }
+
+   if (!pos) {
+  pos = nir_variable_create(shader, nir_var_shader_in, glsl_vec4_type(), 
"gl_FragCoord");
+  pos->data.location = VARYING_SLOT_POS;
+  pos->data.pixel_center_integer = orig->data.pixel_center_integer;
+  pos->data.origin_upper_left = orig->data.origin_upper_left;
+   }
+
+   return nir_load_var(b, pos);
+}
+
  static bool
-convert_block(nir_block *block, nir_builder *b)
+convert_block(nir_block *block, nir_builder *b, nir_shader *shader)
  {
 bool progress = false;
  
 nir_foreach_instr_safe(instr, block) {

if (instr->type != nir_instr_type_intrinsic)
   continue;
  
nir_intrinsic_instr *load_var = nir_instr_as_intrinsic(instr);
  
if (load_var->intrinsic != nir_intrinsic_load_var)

@@ -109,59 +133,63 @@ convert_block(nir_block *block, nir_builder *b)
  sysval = nir_load_vertex_id(b);
   }
   break;
  
case SYSTEM_VALUE_INSTANCE_INDEX:

   sysval = nir_iadd(b,
 nir_load_instance_id(b),
 nir_load_base_instance(b));
   break;
  
+  case SYSTEM_VALUE_FRAG_COORD:

+ sysval = get_frag_coord(b, shader, var);
+ break;
+
default:
   break;
}
  
if (sysval == NULL) {

   nir_intrinsic_op sysval_op =
  nir_intrinsic_from_system_value(var->data.location);
   sysval = nir_load_system_value(b, sysval_op, 0);
}
  
nir_ssa_def_rewrite_uses(_var->dest.ssa, nir_src_for_ssa(sysval));

nir_instr_remove(_var->instr);
  
progress = true;

 }
  
 return progress;

  }
  
  static bool

-convert_impl(nir_function_impl *impl)
+convert_impl(nir_function_impl *impl, nir_shader *shader)
  {
 bool progress = false;
 nir_builder builder;
 nir_builder_init(, impl);
  
 nir_foreach_block(block, impl) {

-  progress |= convert_block(block, );
+  progress |= convert_block(block, , shader);
 }
  
 nir_metadata_preserve(impl, nir_metadata_block_index |

 nir_metadata_dominance);
 return progress;
  }
  
  bool

  nir_lower_system_values(nir_shader *shader)
  {
 bool progress = false;
  
 nir_foreach_function(function, shader) {

if (function->impl)
- progress = convert_impl(function->impl) || progress;
+ progress = convert_impl(function->impl, shader) || progress;
 }
  
 exec_list_make_empty(>system_values);
  
 return progress;

  }


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

Re: [Mesa-dev] [PATCH 02/92] glsl_to_nir: zero-initialize var->data.descriptor_set

[Timothy Arceri]

I wonder if we should just change to using:

  nir_variable *var = rzalloc(shader, nir_variable)

Either way:

Reviewed-by: Timothy Arceri 

On 27/06/17 00:09, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

This is convenient for backends that support both Vulkan and OpenGL while
lowering samplers to derefs with nir_lower_samplers_as_deref.
---
  src/compiler/glsl/glsl_to_nir.cpp | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index 6513484..2153004 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -417,20 +417,21 @@ nir_visitor::visit(ir_variable *ir)
var->data.depth_layout = nir_depth_layout_less;
break;
 case ir_depth_layout_unchanged:
var->data.depth_layout = nir_depth_layout_unchanged;
break;
 default:
unreachable("not reached");
 }
  
 var->data.index = ir->data.index;

+   var->data.descriptor_set = 0;
 var->data.binding = ir->data.binding;
 var->data.offset = ir->data.offset;
 var->data.image.read_only = ir->data.memory_read_only;
 var->data.image.write_only = ir->data.memory_write_only;
 var->data.image.coherent = ir->data.memory_coherent;
 var->data.image._volatile = ir->data.memory_volatile;
 var->data.image.restrict_flag = ir->data.memory_restrict;
 var->data.image.format = ir->data.image_format;
 var->data.fb_fetch_output = ir->data.fb_fetch_output;
  


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

[Mesa-dev] [PATCH v2 3/3] glsl: disable array splitting for AoA

[Timothy Arceri]

While it produces functioning code the pass creates worse code
for arrays of arrays. See the comment added in this patch for more
detail.

V2: skip splitting of AoA of matrices too.
---
 src/compiler/glsl/opt_array_splitting.cpp | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/src/compiler/glsl/opt_array_splitting.cpp 
b/src/compiler/glsl/opt_array_splitting.cpp
index fb6d77b..d2e81665 100644
--- a/src/compiler/glsl/opt_array_splitting.cpp
+++ b/src/compiler/glsl/opt_array_splitting.cpp
@@ -140,6 +140,29 @@ ir_array_reference_visitor::get_variable_entry(ir_variable 
*var)
if (var->type->is_unsized_array())
   return NULL;
 
+   /* FIXME: arrays of arrays are not handled correctly by this pass so we
+* skip it for now. While the pass will create functioning code it actually
+* produces worse code.
+*
+* For example the array:
+*
+*int[3][2] a;
+*
+* ends up being split up into:
+*
+*int[3][2] a_0;
+*int[3][2] a_1;
+*int[3][2] a_2;
+*
+* And we end up referencing each of these new arrays for example:
+*
+*a[0][1] will be turned into a_0[0][1]
+*a[1][0] will be turned into a_1[1][0]
+*a[2][0] will be turned into a_2[2][0]
+*/
+   if (var->type->is_array() && var->type->fields.array->is_array())
+  return NULL;
+
foreach_in_list(variable_entry, entry, >variable_list) {
   if (entry->var == var)
  return entry;
-- 
2.9.4

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

[Mesa-dev] [PATCH v2 2/3] nir: fix nir_opt_copy_prop_vars() for arrays of arrays

[Timothy Arceri]

Previous we only incremented the guide for a single
dimension/wildcard.

V2: rework logic to avoid code duplication
---
 src/compiler/nir/nir_opt_copy_prop_vars.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/compiler/nir/nir_opt_copy_prop_vars.c 
b/src/compiler/nir/nir_opt_copy_prop_vars.c
index 7f17469..89ddc8d 100644
--- a/src/compiler/nir/nir_opt_copy_prop_vars.c
+++ b/src/compiler/nir/nir_opt_copy_prop_vars.c
@@ -469,8 +469,8 @@ specialize_wildcards(nir_deref_var *deref,
nir_deref_var *ret = nir_deref_var_create(mem_ctx, deref->var);
 
nir_deref *deref_tail = deref->deref.child;
-   nir_deref *guide_tail = guide->deref.child;
-   nir_deref *spec_tail = specific->deref.child;
+   nir_deref *guide_tail = >deref;
+   nir_deref *spec_tail = >deref;
nir_deref *ret_tail = >deref;
while (deref_tail) {
   switch (deref_tail->deref_type) {
@@ -495,14 +495,14 @@ specialize_wildcards(nir_deref_var *deref,
  * the entry deref to find its corresponding wildcard and fill
  * this slot in with the value from the src.
  */
-while (guide_tail) {
+while (guide_tail->child) {
+   guide_tail = guide_tail->child;
+   spec_tail = spec_tail->child;
+
if (guide_tail->deref_type == nir_deref_type_array &&
nir_deref_as_array(guide_tail)->deref_array_type ==
nir_deref_array_type_wildcard)
   break;
-
-   guide_tail = guide_tail->child;
-   spec_tail = spec_tail->child;
 }
 
 nir_deref_array *spec_arr = nir_deref_as_array(spec_tail);
-- 
2.9.4

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

[Mesa-dev] [PATCH v2 1/3] nir: NULL check lower_copies_to_load_store()

[Timothy Arceri]

Allows us to disable array spliting for arrays of arrays without
regressing tests such as:

ES31-CTS.functional.shaders.arrays_of_arrays.return.explicit.struct_3x1x3_fragment
---
 src/compiler/nir/nir_lower_vars_to_ssa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_lower_vars_to_ssa.c 
b/src/compiler/nir/nir_lower_vars_to_ssa.c
index e5a12eb..31f7e7a 100644
--- a/src/compiler/nir/nir_lower_vars_to_ssa.c
+++ b/src/compiler/nir/nir_lower_vars_to_ssa.c
@@ -441,7 +441,7 @@ static bool
 lower_copies_to_load_store(struct deref_node *node,
struct lower_variables_state *state)
 {
-   if (!node->copies)
+   if (!node || !node->copies)
   return true;
 
struct set_entry *copy_entry;
-- 
2.9.4

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

Re: [Mesa-dev] [Bug 101666] bitfieldExtract is marked as a built-in function on OpenGL ES 3.0, but was added in OpenGL ES 3.1

[Ilia Mirkin]

To be clear, I'm saying this is broken in Mesa for *any* situation that
involves redefining a function that appears in a future GL version or ext.
There are some limitations to this, based on when the error is triggered, I
don't have the code in front of me. At least it happens for es 3.0.

On Jul 2, 2017 15:10,  wrote:

*Comment # 4  on
bug 101666  from Ilia
Mirkin  *

The predicate is correct, just never checked.

On Jul 2, 2017 15:08,  wrote:

> *Comment # 3  
>  on
> bug 101666  
>  from
> Kenneth Graunke  *

>> I don't think you need to change any infrastructure, we just didn't add the
> proper built-in availability predicate to the bitfieldExtract functions in
> builtin_functions.cpp.  it should be trivial to fix - this is by no means a 
> new
> case...
>
> --
> 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
>
>

--
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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 101666] bitfieldExtract is marked as a built-in function on OpenGL ES 3.0, but was added in OpenGL ES 3.1

[bugzilla-daemon]

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

--- Comment #5 from Ilia Mirkin  ---
To be clear, I'm saying this is broken in Mesa for *any* situation that
involves redefining a function that appears in a future GL version or ext.
There are some limitations to this, based on when the error is triggered, I
don't have the code in front of me. At least it happens for es 3.0.

On Jul 2, 2017 15:10,  wrote:

*Comment # 4  on
bug 101666  from Ilia
Mirkin  *

The predicate is correct, just never checked.

On Jul 2, 2017 15:08,  wrote:

> *Comment # 3  
>  on
> bug 101666  
>  from
> Kenneth Graunke  *

>> I don't think you need to change any infrastructure, we just didn't add the
> proper built-in availability predicate to the bitfieldExtract functions in
> builtin_functions.cpp.  it should be trivial to fix - this is by no means a 
> new
> case...
>
> --
> 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
>
>

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

-- 
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 101666] bitfieldExtract is marked as a built-in function on OpenGL ES 3.0, but was added in OpenGL ES 3.1

[bugzilla-daemon]

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

--- Comment #4 from Ilia Mirkin  ---
The predicate is correct, just never checked.

On Jul 2, 2017 15:08,  wrote:

> *Comment # 3  on
> bug 101666  from
> Kenneth Graunke  *
>
> I don't think you need to change any infrastructure, we just didn't add the
> proper built-in availability predicate to the bitfieldExtract functions in
> builtin_functions.cpp.  it should be trivial to fix - this is by no means a 
> new
> case...
>
> --
> 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
>
>

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

Re: [Mesa-dev] [Bug 101666] bitfieldExtract is marked as a built-in function on OpenGL ES 3.0, but was added in OpenGL ES 3.1

[Ilia Mirkin]

The predicate is correct, just never checked.

On Jul 2, 2017 15:08,  wrote:

> *Comment # 3  on
> bug 101666  from
> Kenneth Graunke  *
>
> I don't think you need to change any infrastructure, we just didn't add the
> proper built-in availability predicate to the bitfieldExtract functions in
> builtin_functions.cpp.  it should be trivial to fix - this is by no means a 
> new
> case...
>
> --
> 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 101666] bitfieldExtract is marked as a built-in function on OpenGL ES 3.0, but was added in OpenGL ES 3.1

[bugzilla-daemon]

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

--- Comment #3 from Kenneth Graunke  ---
I don't think you need to change any infrastructure, we just didn't add the
proper built-in availability predicate to the bitfieldExtract functions in
builtin_functions.cpp.  it should be trivial to fix - this is by no means a new
case...

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

[Mesa-dev] [PATCH 2/4] svga: move assertion in draw_vgpu10()

[Brian Paul]

The buffer binding flags aren't ensured until after the
svga_buffer_handle() call, so move the assertion after it.
---
 src/gallium/drivers/svga/svga_draw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/svga/svga_draw.c 
b/src/gallium/drivers/svga/svga_draw.c
index 6510c42..5919bd3 100644
--- a/src/gallium/drivers/svga/svga_draw.c
+++ b/src/gallium/drivers/svga/svga_draw.c
@@ -548,9 +548,9 @@ draw_vgpu10(struct svga_hwtnl *hwtnl,
   struct svga_buffer *sbuf = 
svga_buffer(hwtnl->cmd.vbufs[i].buffer.resource);
 
   if (sbuf) {
- assert(sbuf->key.flags & SVGA3D_SURFACE_BIND_VERTEX_BUFFER);
  vbuffer_handles[i] = svga_buffer_handle(svga, >b.b,
  PIPE_BIND_VERTEX_BUFFER);
+ assert(sbuf->key.flags & SVGA3D_SURFACE_BIND_VERTEX_BUFFER);
  if (vbuffer_handles[i] == NULL)
 return PIPE_ERROR_OUT_OF_MEMORY;
  vbuffers[i] = >b.b;
-- 
1.9.1

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

[Mesa-dev] [PATCH 3/4] svga: fix texture buffer object regression

[Brian Paul]

With change 8aba778fa2cd98a0b5a7429d3c5057778a0c808c we stopped binding
sampler objects for texture buffers.  That broke our texture sample /
sampler view setup code.

Now, we loop over the max(num samplers, num sampler views) and handle
the sampler and view information separately.  For texture buffers,
the sampler will be NULL but the sampler view non-null.
---
 src/gallium/drivers/svga/svga_shader.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_shader.c 
b/src/gallium/drivers/svga/svga_shader.c
index d069b0d..ef3b021 100644
--- a/src/gallium/drivers/svga/svga_shader.c
+++ b/src/gallium/drivers/svga/svga_shader.c
@@ -199,13 +199,13 @@ svga_init_shader_key_common(const struct svga_context 
*svga,
/* In case the number of samplers and sampler_views doesn't match,
 * loop over the lower of the two counts.
 */
-   key->num_textures = MIN2(svga->curr.num_sampler_views[shader],
+   key->num_textures = MAX2(svga->curr.num_sampler_views[shader],
 svga->curr.num_samplers[shader]);
 
for (i = 0; i < key->num_textures; i++) {
   struct pipe_sampler_view *view = svga->curr.sampler_views[shader][i];
   const struct svga_sampler_state *sampler = svga->curr.sampler[shader][i];
-  if (view && sampler) {
+  if (view) {
  assert(view->texture);
  assert(view->texture->target < (1 << 4)); /* texture_target:4 */
 
@@ -224,13 +224,6 @@ svga_init_shader_key_common(const struct svga_context 
*svga,
 }
  }
 
- if (!sampler->normalized_coords) {
-assert(idx < (1 << 5));  /* width_height_idx:5 bitfield */
-key->tex[i].width_height_idx = idx++;
-key->tex[i].unnormalized = TRUE;
-++key->num_unnormalized_coords;
- }
-
  swizzle_tab = (!util_format_has_alpha(view->format) &&
 svga_texture_device_format_has_alpha(view->texture)) ?
 set_alpha : copy_alpha;
@@ -246,6 +239,15 @@ svga_init_shader_key_common(const struct svga_context 
*svga,
  key->tex[i].swizzle_b = swizzle_tab[view->swizzle_b];
  key->tex[i].swizzle_a = swizzle_tab[view->swizzle_a];
   }
+
+  if (sampler) {
+ if (!sampler->normalized_coords) {
+assert(idx < (1 << 5));  /* width_height_idx:5 bitfield */
+key->tex[i].width_height_idx = idx++;
+key->tex[i].unnormalized = TRUE;
+++key->num_unnormalized_coords;
+ }
+  }
}
 }
 
-- 
1.9.1

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

[Mesa-dev] [PATCH 1/4] svga: fix buffer binding flags initialization

[Brian Paul]

If a buffer is created/initialized with glNamedBufferData we will
have no target (GL_ARRAY_BUFFER, GL_UNIFORM_BUFFER, etc) so the
svga_buffer::bind_flags will be zero until we try to get the buffer
handle.

This patch initializes the svga_buffer::bind_flags field when it's
zero.

This fixes the Piglit arb_uniform_buffer_object-rendering-dsa test.

Note that there's still issues in this area that'll have to be
addressed in the future.  For example, creating a buffer object
as GL_UNIFORM_BUFFER and later using it as a vertex buffer will
fail.
---
 src/gallium/drivers/svga/svga_resource_buffer_upload.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/gallium/drivers/svga/svga_resource_buffer_upload.c 
b/src/gallium/drivers/svga/svga_resource_buffer_upload.c
index 61f6fb0..104cb6d 100644
--- a/src/gallium/drivers/svga/svga_resource_buffer_upload.c
+++ b/src/gallium/drivers/svga/svga_resource_buffer_upload.c
@@ -1003,6 +1003,12 @@ svga_buffer_handle(struct svga_context *svga, struct 
pipe_resource *buf,
 return NULL;
   }
} else {
+  if (!sbuf->bind_flags) {
+ sbuf->bind_flags = tobind_flags;
+  }
+
+  assert((sbuf->bind_flags & tobind_flags) == tobind_flags);
+
   /* This call will set sbuf->handle */
   if (svga_have_gb_objects(svga)) {
  ret = svga_buffer_update_hw(svga, sbuf, sbuf->bind_flags);
-- 
1.9.1

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

[Mesa-dev] [PATCH 4/4] svga: don't call svga_texture_device_format_has_alpha() for PIPE_BUFFER

[Brian Paul]

svga_texture_device_format_has_alpha() is only intended to work for
texture resources, not buffer resources.  This fixes a failed assertion
in the svga_texture() cast function when running texture buffer tests.

Also, add an assertion in svga_texture_device_format_has_alpha() to
catch the issue sooner.
---
 src/gallium/drivers/svga/svga_resource_texture.c | 3 +++
 src/gallium/drivers/svga/svga_shader.c   | 3 ++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/svga/svga_resource_texture.c 
b/src/gallium/drivers/svga/svga_resource_texture.c
index 84441d1..5a684b7 100644
--- a/src/gallium/drivers/svga/svga_resource_texture.c
+++ b/src/gallium/drivers/svga/svga_resource_texture.c
@@ -1539,6 +1539,9 @@ svga_texture_transfer_unmap_upload(struct svga_context 
*svga,
 boolean
 svga_texture_device_format_has_alpha(struct pipe_resource *texture)
 {
+   /* the svga_texture() call below is invalid for PIPE_BUFFER resources */
+   assert(texture->target != PIPE_BUFFER);
+
enum svga3d_block_desc block_desc =
   svga3dsurface_get_desc(svga_texture(texture)->key.format)->block_desc;
 
diff --git a/src/gallium/drivers/svga/svga_shader.c 
b/src/gallium/drivers/svga/svga_shader.c
index ef3b021..5ff6f03 100644
--- a/src/gallium/drivers/svga/svga_shader.c
+++ b/src/gallium/drivers/svga/svga_shader.c
@@ -224,7 +224,8 @@ svga_init_shader_key_common(const struct svga_context *svga,
 }
  }
 
- swizzle_tab = (!util_format_has_alpha(view->format) &&
+ swizzle_tab = (view->texture->target != PIPE_BUFFER &&
+!util_format_has_alpha(view->format) &&
 svga_texture_device_format_has_alpha(view->texture)) ?
 set_alpha : copy_alpha;
 
-- 
1.9.1

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

[Mesa-dev] [PATCH] wglcontext: assorted updates

[Brian Paul]

Print context flags, vendor, renderer strings.
Default to not setting the WGL_CONTEXT_PROFILE_MASK_ARB attribute so we
can test that scenario.
Fix profile_mask_to_string() to use GL_*_BIT instead of WGL_*_BIT flags.
Try calling glGenLists() to see if it generates an error.  This helps to
check if core/forward compatible profile error checking is realy working.
Restructure some context setup code.
---
 src/wgl/wglcontext.c | 107 +--
 1 file changed, 86 insertions(+), 21 deletions(-)

diff --git a/src/wgl/wglcontext.c b/src/wgl/wglcontext.c
index 92df7cc..b116270 100644
--- a/src/wgl/wglcontext.c
+++ b/src/wgl/wglcontext.c
@@ -24,6 +24,19 @@
 #include 
 #include 
 #include 
+#include 
+
+#ifndef GL_CONTEXT_FLAG_DEBUG_BIT
+#define GL_CONTEXT_FLAG_DEBUG_BIT 0x0002
+#endif
+#ifndef GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT
+#define GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT 0x0004
+#endif
+
+#ifndef GL_CONTEXT_FLAG_NO_ERROR_BIT_KHR
+#define GL_CONTEXT_FLAG_NO_ERROR_BIT_KHR  0x0008
+#endif
+
 
 static LRESULT CALLBACK
 WndProc(HWND hWnd,
@@ -61,28 +74,59 @@ static char *
 profile_mask_to_string(GLint profileMask)
 {
switch (profileMask) {
-   case WGL_CONTEXT_CORE_PROFILE_BIT_ARB:
-  return "WGL_CONTEXT_CORE_PROFILE_BIT_ARB";
-   case WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB:
-  return "WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB";
+   case GL_CONTEXT_CORE_PROFILE_BIT:
+  return "GL_CONTEXT_CORE_PROFILE_BIT";
+   case GL_CONTEXT_COMPATIBILITY_PROFILE_BIT:
+  return "GL_CONTEXT_COMPATIBILITY_PROFILE_BIT";
default:
   return "0";
}
 }
 
+static char *
+context_flags_to_string(GLint flags)
+{
+   static char buf[1000] = {0};
+   if (flags & GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT)
+  strcat(buf, "GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT | ");
+   if (flags & GL_CONTEXT_FLAG_DEBUG_BIT)
+  strcat(buf, "GL_CONTEXT_FLAG_DEBUG_BIT | ");
+   if (flags & GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT)
+  strcat(buf, "GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT | ");
+   if (flags & GL_CONTEXT_FLAG_NO_ERROR_BIT_KHR)
+  strcat(buf, "GL_CONTEXT_FLAG_NO_ERROR_BIT_KHR | ");
+
+   int n = strlen(buf);
+   if (n >= 3) {
+  /* rm the trailing " | " */
+  buf[n-3] = 0;
+   }
+   else {
+  strcat(buf, "(none)");
+   }
+
+   return buf;
+}
+
 static void
 print_context_infos(void)
 {
GLint majorVersion;
GLint minorVersion;
-   GLint profileMask;
-   const char *version;
+   GLint profileMask, flags;
+   const char *version, *vendor, *renderer;
 
fprintf(stdout, "Context Informations\n");
 
version = (const char *)glGetString(GL_VERSION);
fprintf(stdout, "GL_VERSION: %s\n", version);
 
+   vendor = (const char *)glGetString(GL_VENDOR);
+   fprintf(stdout, "GL_VENDOR: %s\n", vendor);
+
+   renderer = (const char *)glGetString(GL_RENDERER);
+   fprintf(stdout, "GL_RENDERER: %s\n", renderer);
+
// Request informations with the new 3.x features.
if (sscanf(version, "%d.%d", , ) != 2)
   return;
@@ -90,10 +134,28 @@ print_context_infos(void)
if (majorVersion >= 3) {
   glGetIntegerv(GL_MAJOR_VERSION, );
   glGetIntegerv(GL_MINOR_VERSION, );
-  glGetIntegerv(GL_CONTEXT_PROFILE_MASK, );
   fprintf(stdout, "GL_MAJOR_VERSION: %d\n", majorVersion);
   fprintf(stdout, "GL_MINOR_VERSION: %d\n", minorVersion);
-  fprintf(stdout, "GL_CONTEXT_PROFILE_MASK: %s\n", 
profile_mask_to_string(profileMask));
+   }
+   if (majorVersion * 10 + minorVersion >= 32) {
+  glGetIntegerv(GL_CONTEXT_PROFILE_MASK, );
+  glGetIntegerv(GL_CONTEXT_FLAGS, );
+  fprintf(stdout, "GL_CONTEXT_PROFILE_MASK: %s\n",
+  profile_mask_to_string(profileMask));
+  fprintf(stdout, "GL_CONTEXT_FLAGS: %s\n",
+  context_flags_to_string(flags));
+   }
+
+   /* Test if deprecated features work or generate an error */
+   while (glGetError() != GL_NO_ERROR)
+  ;
+
+   (void) glGenLists(1);
+   if (glGetError()) {
+  fprintf(stdout, "glGenLists generated an error.\n");
+   }
+   else {
+  fprintf(stdout, "glGenLists generated no error.\n");
}
 }
 
@@ -107,13 +169,6 @@ create_context(int majorVersion, int minorVersion, int 
profileMask, int contextF
int pixelFormat;
HGLRC tmp, ctx;
PFNWGLCREATECONTEXTATTRIBSARBPROC wglCreateContextAttribsARB;
-   int attribsList[] = {
-  WGL_CONTEXT_MAJOR_VERSION_ARB, 1,
-  WGL_CONTEXT_MINOR_VERSION_ARB, 0,
-  WGL_CONTEXT_FLAGS_ARB, 0,
-  WGL_CONTEXT_PROFILE_MASK_ARB, WGL_CONTEXT_CORE_PROFILE_BIT_ARB,
-  0
-   };
 
memset(, 0, sizeof(wc));
wc.style = CS_OWNDC | CS_HREDRAW | CS_VREDRAW;
@@ -190,10 +245,21 @@ create_context(int majorVersion, int minorVersion, int 
profileMask, int contextF
   return;
}
 
-   attribsList[1] = majorVersion;
-   attribsList[3] = minorVersion;
-   attribsList[5] = contextFlags;
-   attribsList[7] = profileMask;
+   int attribsList[20];
+   int i = 0;
+   attribsList[i++] = 

Re: [Mesa-dev] [PATCH v2 2/3] gallium/hud: Prevent buffer overflow in hud_thread_counter_install

[Brian Paul]

On 06/30/2017 05:59 PM, Robert Foss wrote:

On Thu, 2017-06-29 at 07:28 -0600, Brian Paul wrote:

On 06/29/2017 07:21 AM, Robert Foss wrote:

Switch to using strncopy to avoid potential overflow of
name array in struct hud_graph.

Coverity-id: 1413761

Signed-off-by: Robert Foss 
---
   src/gallium/auxiliary/hud/hud_cpu.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/hud/hud_cpu.c
b/src/gallium/auxiliary/hud/hud_cpu.c
index 4caaab6977..468c36207b 100644
--- a/src/gallium/auxiliary/hud/hud_cpu.c
+++ b/src/gallium/auxiliary/hud/hud_cpu.c
@@ -362,7 +362,7 @@ void hud_thread_counter_install(struct hud_pane
*pane, const char *name,
  if (!gr)
 return;

-   strcpy(gr->name, name);
+   strncpy(gr->name, name, HUD_GRAPH_NAME_LEN);


strncpy() doesn't null terminate the destination if strlen(name) >=
HUD_GRAPH_NAME_LEN

If you're concerned with overflow, you need to address that too.

You might looks if we have a gallium util function for strncpy with
null
termination.


I had a look at adding a stncpy analog to src/util/u_string.h but it
would seem that these implementation are only intended for _WIN32
platforms.


The util_*() functions are portability wrappers.  For Linux/etc we 
define the functions as macros which alias standard functions.  For 
Windows we have to roll our own.


I'd suggest adding a new util_strncpy() function that always does null 
termination.


-Brian


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

Re: [Mesa-dev] [PATCH 2/2] st/mesa: fix texture image resource selection in st_render_texture()

[Brian Paul]

On 07/01/2017 04:56 AM, Nicolai Hähnle wrote:

On 29.06.2017 00:12, Brian Paul wrote:

If we're rendering to an incomplete/inconsistent (cube) texture, the
different faces/levels of the texture may be stored in different
resources.  Before, we always used the texture object resource.  Now,
we use the texture image resource.  In normal circumstances, that's
the same resource.  But in some cases, such as the Piglit
fbo-incomplete-texture-03 test, the cube faces are in different
resources and we need to render to the texture image resource.

Fixes fbo-incomplete-texture-03 with VMware driver.
---
  src/mesa/state_tracker/st_cb_fbo.c | 19 ++-
  1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 2559c23..a4d710c 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -470,6 +470,21 @@ st_update_renderbuffer_surface(struct st_context
*st,
 strb->surface = *psurf;
  }
+
+/**
+ * Return the pipe_resource which stores a particular texture image.
+ */
+static struct pipe_resource *
+get_teximage_resource(struct gl_texture_object *texObj,
+  unsigned face, unsigned level)
+{
+   struct st_texture_image *stImg =
+  st_texture_image(texObj->Image[face][level]);
+
+   return stImg->pt;
+}
+
+
  /**
   * Called by ctx->Driver.RenderTexture
   */
@@ -487,7 +502,9 @@ st_render_texture(struct gl_context *ctx,
 if (!st_finalize_texture(ctx, pipe, att->Texture, att->CubeMapFace))
return;
-   pt = st_get_texobj_resource(att->Texture);
+   pt = get_teximage_resource(att->Texture,
+  att->CubeMapFace,
+  att->TextureLevel);


When st_AllocTextureImageBuffer allocates a pipe resource for a "loose"
image, it allocates a single level, even if the image is not a mip level
0. So I wonder if we need to adjust the level selection in the
pipe_surface somehow. Is this covered by the incomplete texture tests?


I think we're good.  In st_update_renderbuffer_surface() we actually 
search the resources's mipmap levels to find the one that matches the 
expected surface size.


-Brian

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

[Mesa-dev] [PATCH] docs: update bug reporting guidelines

[Brian Paul]

Suggest attaching output of glxinfo/wglinfo.  Suggest providing
an apitrace.
---
 docs/bugs.html | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/docs/bugs.html b/docs/bugs.html
index 445d9ca..44955d3 100644
--- a/docs/bugs.html
+++ b/docs/bugs.html
@@ -37,11 +37,14 @@ Please follow these bug reporting guidelines:
 the problem.
 Check if your bug is already reported in the database.
 Monitor your bug report for requests for additional information, etc.
+Attach the output of running glxinfo or wglinfo.
+This will tell us the Mesa version, which device driver you're using, etc.
 If you're reporting a crash, try to use your debugger (gdb) to get a stack
 trace. Also, recompile Mesa in debug mode to get more detailed information.
 Describe in detail how to reproduce the bug, especially with games
 and applications that the Mesa developers might not be familiar with.
-Provide a simple GLUT-based test program if possible
+Provide an https://github.com/apitrace/apitrace;>apitrace
+or simple GLUT-based test program if possible.
 
 
 
-- 
1.9.1

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

Re: [Mesa-dev] Mesa (master): build systems: uniformize git_sha1.h generation

[Brian Paul]

On 07/01/2017 03:44 AM, Eric Engestrom wrote:

On 1 July 2017 00:18:31 BST, Brian Paul  wrote:

Hi Eric,

Shouldn't the new script file be put in the bin/ directory with the
other helper scripts?


I guess you're right, not sure why I didn't do that.
Feel free to move it (just make sure to ../ the --git-dir too), or I can
do that when I get back in front of a computer next week.


No rush.  If you can do it, great.



Should we also merge bin/ and scripts/, maybe?
I think get_reviewers.pl would stay in scripts/ because that path
is in everyone's configuration, but I think everything in bin/ is
manually invoked, right?


Rob Clark put get_reviewer.pl in scripts/ so he's probably the person to 
ask.  I guess I'd prefer everything in bin/ and no scripts/ but it's not 
a big deal.


-Brian



On 06/29/2017 09:52 AM, Eric Engeström wrote:

Module: Mesa
Branch: master
Commit: 3fd425aed764fb771f2f49ddb6b30b389a114504
URL:

https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_mesa_mesa_commit_-3Fid-3D3fd425aed764fb771f2f49ddb6b30b389a114504=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA=C2QHFlT8FYNq-A29CoLU1hnnK3jQhP0A-EpQrqbU_GQ=ZjxcahOcytLNOgFBZuod2dWN2xvP8Ph32iP3dluOunQ=


Author: Eric Engestrom 
Date:   Tue Jun 27 12:08:41 2017 +0100

build systems: uniformize git_sha1.h generation

Signed-off-by: Eric Engestrom 
Reviewed-by: Matt Turner 
Reviewed-by: Emil Velikov 

---

   git_sha1_gen.sh  | 12 
   src/Makefile.am  | 13 +
   src/SConscript   | 28



   src/mesa/Android.libmesa_git_sha1.mk |  7 +--
   4 files changed, 22 insertions(+), 38 deletions(-)

diff --git a/git_sha1_gen.sh b/git_sha1_gen.sh
new file mode 100755
index 00..20ab8df8ea
--- /dev/null
+++ b/git_sha1_gen.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+# run git from the sources directory
+cd "$(dirname "$0")"
+
+# don't print anything if git fails
+if ! git_sha1=$(git --git-dir=.git rev-parse --short=10 HEAD

2>/dev/null)

+then
+  exit
+fi
+
+printf '#define MESA_GIT_SHA1 "git-%s"\n' "$git_sha1"
diff --git a/src/Makefile.am b/src/Makefile.am
index df912c442a..d8a2ee59fc 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -21,18 +21,7 @@

   .PHONY: git_sha1.h.tmp
   git_sha1.h.tmp:
-   @# Don't assume that $(top_srcdir)/.git is a directory. It may be
-   @# a gitlink file if $(top_srcdir) is a submodule checkout or a

linked

-   @# worktree.
-   @# If we are building from a release tarball copy the bundled

header.

-   @touch git_sha1.h.tmp
-   @if test -e $(top_srcdir)/.git; then \
-   if which git > /dev/null; then \
-   printf '#define MESA_GIT_SHA1 "git-%s"\n' \
-   `git --git-dir=$(top_srcdir)/.git rev-parse --short=10 
HEAD` \
-   > git_sha1.h.tmp ; \
-   fi \
-   fi
+   @sh $(top_srcdir)/git_sha1_gen.sh > $@

   git_sha1.h: git_sha1.h.tmp
@echo "updating git_sha1.h"
diff --git a/src/SConscript b/src/SConscript
index d861af8e4d..5e1171b524 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -22,27 +22,15 @@ def write_git_sha1_h_file(filename):
   to retrieve the git hashid and write the header file.  An

empty file

   will be created if anything goes wrong."""

-args = [ 'git', 'rev-parse', '--short=10', 'HEAD' ]
-try:
-(commit, foo) = subprocess.Popen(args,

stdout=subprocess.PIPE).communicate()

-except:
-print "Warning: exception in write_git_sha1_h_file()"
-# git log command didn't work
-if not os.path.exists(filename):
-dirname = os.path.dirname(filename)
-if dirname and not os.path.exists(dirname):
-os.makedirs(dirname)
-# create an empty file if none already exists
-f = open(filename, "w")
-f.close()
-return
-
-# note that commit[:-1] removes the trailing newline character
-commit = '#define MESA_GIT_SHA1 "git-%s"\n' % commit[:-1]
   tempfile = "git_sha1.h.tmp"
-f = open(tempfile, "w")
-f.write(commit)
-f.close()
+with open(tempfile, "w") as f:
+args = [ 'sh', Dir('#').abspath + '/git_sha1_gen.sh' ]
+try:
+subprocess.Popen(args, stdout=f)
+except:
+print "Warning: exception in write_git_sha1_h_file()"
+return
+
   if not os.path.exists(filename) or not filecmp.cmp(tempfile,

filename):

   # The filename does not exist or it's different from the

new file,

   # so replace old file with new.
diff --git a/src/mesa/Android.libmesa_git_sha1.mk

b/src/mesa/Android.libmesa_git_sha1.mk

index 0fd176bf7d..a5a1ebb37f 100644
--- a/src/mesa/Android.libmesa_git_sha1.mk
+++ 

[Mesa-dev] [Bug 101666] bitfieldExtract is marked as a built-in function on OpenGL ES 3.0, but was added in OpenGL ES 3.1

[bugzilla-daemon]

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

--- Comment #2 from Ilia Mirkin  ---
Aha. I see.

_mesa_glsl_has_builtin_function() needs to take a state, and only return true
if sig->is_builtin_available(state). Unclear if
_mesa_glsl_find_builtin_function needs to do the same.

Should be easy enough. I can hack it up tonight maybe, or someone else can take
it.

-- 
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 101666] bitfieldExtract is marked as a built-in function on OpenGL ES 3.0, but was added in OpenGL ES 3.1

[bugzilla-daemon]

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

--- Comment #1 from Ilia Mirkin  ---
Despite the code looking just fine, I can repro this with a shader_test:

[require]
GL ES >= 3.0
GLSL ES >= 3.00

[vertex shader]
#version 300 es

uint bitfieldExtract(uint val, int off, int size) {
uint mask = uint((1 << size) - 1);
return uint(val >> off) & mask;
}

void main() {
  gl_Position = vec4(bitfieldExtract(1u, 2, 3));
}

[fragment shader]
#version 300 es
out vec4 color;
void main() { color = vec4(0,1,0,1); }

[test]
link success


results in

Failed to compile VS: 0:3(6): error: A shader cannot redefine or overload
built-in function `bitfieldExtract' in GLSL ES 3.00
0:9(21): error: no matching function for call to `bitfieldExtract(uint, int,
int)'; candidates are:
0:9(16): error: cannot construct `vec4' from a non-numeric data type

Will require some code reading, because the builtin_functions.cpp signature
seems fine. It must not be getting validated at the right times...

[And to avoid any confusion, this was on SNB, so ES 3.1 wasn't even an option.]

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

Re: [Mesa-dev] [PATCH 30/92] ac/nir: start using ac_shader_abi

[Bas Nieuwenhuizen]

Hi Nicolai,

Can we use LLVMValueRef instead of int for the shader_abi? That way we
don't force the values to be function parameters. I don't think the
shared code should have to know about that, and it is more flexible
when we want to pass those slightly differently between the two
drivers, as we can then convert them in the prologue.

- Bas

On Mon, Jun 26, 2017 at 4:10 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> ---
>  src/amd/common/ac_nir_to_llvm.c | 74 
> +++--
>  1 file changed, 41 insertions(+), 33 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 68865bd..e65f167 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -23,20 +23,21 @@
>
>  #include "ac_nir_to_llvm.h"
>  #include "ac_llvm_build.h"
>  #include "ac_llvm_util.h"
>  #include "ac_binary.h"
>  #include "sid.h"
>  #include "nir/nir.h"
>  #include "../vulkan/radv_descriptor_set.h"
>  #include "util/bitscan.h"
>  #include 
> +#include "ac_shader_abi.h"
>  #include "ac_shader_info.h"
>  #include "ac_exp_param.h"
>
>  enum radeon_llvm_calling_convention {
> RADEON_LLVM_AMDGPU_VS = 87,
> RADEON_LLVM_AMDGPU_GS = 88,
> RADEON_LLVM_AMDGPU_PS = 89,
> RADEON_LLVM_AMDGPU_CS = 90,
>  };
>
> @@ -50,45 +51,42 @@ enum desc_type {
> DESC_IMAGE,
> DESC_FMASK,
> DESC_SAMPLER,
> DESC_BUFFER,
>  };
>
>  struct nir_to_llvm_context {
> struct ac_llvm_context ac;
> const struct ac_nir_compiler_options *options;
> struct ac_shader_variant_info *shader_info;
> +   struct ac_shader_abi abi;
> +
> unsigned max_workgroup_size;
> LLVMContextRef context;
> LLVMModuleRef module;
> LLVMBuilderRef builder;
> LLVMValueRef main_function;
>
> struct hash_table *defs;
> struct hash_table *phis;
>
> LLVMValueRef descriptor_sets[AC_UD_MAX_SETS];
> LLVMValueRef ring_offsets;
> LLVMValueRef push_constants;
> LLVMValueRef num_work_groups;
> LLVMValueRef workgroup_ids;
> LLVMValueRef local_invocation_ids;
> LLVMValueRef tg_size;
>
> LLVMValueRef vertex_buffers;
> -   LLVMValueRef base_vertex;
> -   LLVMValueRef start_instance;
> -   LLVMValueRef draw_index;
> -   LLVMValueRef vertex_id;
> LLVMValueRef rel_auto_id;
> LLVMValueRef vs_prim_id;
> -   LLVMValueRef instance_id;
> LLVMValueRef ls_out_layout;
> LLVMValueRef es2gs_offset;
>
> LLVMValueRef tcs_offchip_layout;
> LLVMValueRef tcs_out_offsets;
> LLVMValueRef tcs_out_layout;
> LLVMValueRef tcs_in_layout;
> LLVMValueRef oc_lds;
> LLVMValueRef tess_factor_offset;
> LLVMValueRef tcs_patch_id;
> @@ -258,65 +256,70 @@ struct arg_info {
> LLVMValueRef *assign[MAX_ARGS];
> unsigned array_params_mask;
> uint8_t count;
> uint8_t user_sgpr_count;
> uint8_t sgpr_count;
> uint8_t num_user_sgprs_used;
> uint8_t num_sgprs_used;
> uint8_t num_vgprs_used;
>  };
>
> -static inline void
> +static inline int
>  add_argument(struct arg_info *info,
>  LLVMTypeRef type, LLVMValueRef *param_ptr)
>  {
> -   assert(info->count < MAX_ARGS);
> -   info->assign[info->count] = param_ptr;
> -   info->types[info->count] = type;
> +   int idx = info->count;
> +   assert(idx < MAX_ARGS);
> +   info->assign[idx] = param_ptr;
> +   info->types[idx] = type;
> info->count++;
> +   return idx;
>  }
>
> -static inline void
> +static inline int
>  add_sgpr_argument(struct arg_info *info,
>   LLVMTypeRef type, LLVMValueRef *param_ptr)
>  {
> -   add_argument(info, type, param_ptr);
> +   int idx = add_argument(info, type, param_ptr);
> info->num_sgprs_used += llvm_get_type_size(type) / 4;
> info->sgpr_count++;
> +   return idx;
>  }
>
> -static inline void
> +static inline int
>  add_user_sgpr_argument(struct arg_info *info,
>LLVMTypeRef type,
>LLVMValueRef *param_ptr)
>  {
> -   add_sgpr_argument(info, type, param_ptr);
> +   int idx = add_sgpr_argument(info, type, param_ptr);
> info->num_user_sgprs_used += llvm_get_type_size(type) / 4;
> info->user_sgpr_count++;
> +   return idx;
>  }
>
> -static inline void
> +static inline int
>  add_vgpr_argument(struct arg_info *info,
>   LLVMTypeRef type,
>   LLVMValueRef *param_ptr)
>  {
> -   add_argument(info, type, param_ptr);
> +   int idx = add_argument(info, type, param_ptr);
> info->num_vgprs_used += llvm_get_type_size(type) / 4;
> +   return idx;
>  }
>
> -static inline void
> +static inline int
>  add_user_sgpr_array_argument(struct arg_info 

[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Bug 99762 Summary: "Black Mesa" not launching
https://bugs.freedesktop.org/show_bug.cgi?id=99762

   What|Removed |Added

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

-- 
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 90264] [Regression, bisected] Tooltip corruption in Chrome

[bugzilla-daemon]

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

--- Comment #78 from Robert Orzanna  ---
Sorry, I shared the wrong link to the video in my previous comment:

https://youtu.be/3mXXnlwrXm0

-- 
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 90264] [Regression, bisected] Tooltip corruption in Chrome

[bugzilla-daemon]

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

--- Comment #77 from Robert Orzanna  ---
Thank you, omerfarukdoga...@hotmail.com.

I could reproduce this problem in Chrome and tried to capture it in this video:

https://www.useloom.com/share/14090a28f6d64fb6a4ba74056aac14f5

Does the problem have to be addressed in Chrome and Chromium?

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