[Mesa-dev] [PATCH v3 74/78] i965/vec4: Enable NIR-vec4 pass on ARB_vertex_programs

[Eduardo Lima Mitev]

From: Antia Puentes 

---
 src/mesa/drivers/dri/i965/brw_vec4.cpp | 47 +-
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 8d83887..88b601a 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1732,18 +1732,16 @@ vec4_visitor::run(gl_clip_plane *clip_planes)
 
emit_prolog();
 
-   if (shader) {
-  if (use_vec4_nir) {
- assert(prog->nir != NULL);
- emit_nir_code();
- if (failed)
-return false;
-  } else {
- /* Generate VS IR for main().  (the visitor only descends into
-  * functions called "main").
-  */
- visit_instructions(shader->base.ir);
-  }
+   if (use_vec4_nir) {
+  assert(prog->nir != NULL);
+  emit_nir_code();
+  if (failed)
+ return false;
+   } else if (shader) {
+  /* Generate VS IR for main().  (the visitor only descends into
+   * functions called "main").
+   */
+  visit_instructions(shader->base.ir);
} else {
   emit_program_code();
}
@@ -1921,18 +1919,21 @@ brw_vs_emit(struct brw_context *brw,
if (unlikely(INTEL_DEBUG & DEBUG_VS))
   brw_dump_ir("vertex", prog, &shader->base, &vp->Base);
 
-   if (brw->intelScreen->compiler->scalar_vs) {
-  if (!vp->Base.nir) {
- /* Normally we generate NIR in LinkShader() or
-  * ProgramStringNotify(), but Mesa's fixed-function vertex program
-  * handling doesn't notify the driver at all.  Just do it here, at
-  * the last minute, even though it's lame.
-  */
- assert(vp->Base.Id == 0 && prog == NULL);
- vp->Base.nir =
-brw_create_nir(brw, NULL, &vp->Base, MESA_SHADER_VERTEX, true);
-  }
+   if (!vp->Base.nir &&
+   (brw->intelScreen->compiler->scalar_vs ||
+
brw->intelScreen->compiler->glsl_compiler_options[MESA_SHADER_VERTEX].NirOptions
 != NULL)) {
+  /* Normally we generate NIR in LinkShader() or
+   * ProgramStringNotify(), but Mesa's fixed-function vertex program
+   * handling doesn't notify the driver at all.  Just do it here, at
+   * the last minute, even though it's lame.
+   */
+  assert(vp->Base.Id == 0 && prog == NULL);
+  vp->Base.nir =
+ brw_create_nir(brw, NULL, &vp->Base, MESA_SHADER_VERTEX,
+brw->intelScreen->compiler->scalar_vs);
+   }
 
+   if (brw->intelScreen->compiler->scalar_vs) {
   prog_data->base.dispatch_mode = DISPATCH_MODE_SIMD8;
 
   fs_visitor v(brw->intelScreen->compiler, brw,
-- 
2.4.6

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

[Mesa-dev] [PATCH v3 09/78] i965/nir: Pass a is_scalar boolean to brw_create_nir()

[Eduardo Lima Mitev]

The upcoming introduction of NIR->vec4 pass will require that some NIR lowering
passes are enabled/disabled depending on the type of shader (scalar vs. vector).

With this patch we pass a 'is_scalar' variable to the process of constructing 
the
NIR, to let an external context decide how the shader should be handled.
---
 src/mesa/drivers/dri/i965/brw_nir.c  | 3 ++-
 src/mesa/drivers/dri/i965/brw_nir.h  | 3 ++-
 src/mesa/drivers/dri/i965/brw_program.c  | 5 +++--
 src/mesa/drivers/dri/i965/brw_shader.cpp | 6 --
 src/mesa/drivers/dri/i965/brw_vec4.cpp   | 2 +-
 5 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_nir.c 
b/src/mesa/drivers/dri/i965/brw_nir.c
index 3e154c1..4aa893a 100644
--- a/src/mesa/drivers/dri/i965/brw_nir.c
+++ b/src/mesa/drivers/dri/i965/brw_nir.c
@@ -61,7 +61,8 @@ nir_shader *
 brw_create_nir(struct brw_context *brw,
const struct gl_shader_program *shader_prog,
const struct gl_program *prog,
-   gl_shader_stage stage)
+   gl_shader_stage stage,
+   bool is_scalar)
 {
struct gl_context *ctx = &brw->ctx;
const nir_shader_compiler_options *options =
diff --git a/src/mesa/drivers/dri/i965/brw_nir.h 
b/src/mesa/drivers/dri/i965/brw_nir.h
index 3131109..c76defd 100644
--- a/src/mesa/drivers/dri/i965/brw_nir.h
+++ b/src/mesa/drivers/dri/i965/brw_nir.h
@@ -77,7 +77,8 @@ void brw_nir_analyze_boolean_resolves(nir_shader *nir);
 nir_shader *brw_create_nir(struct brw_context *brw,
const struct gl_shader_program *shader_prog,
const struct gl_program *prog,
-   gl_shader_stage stage);
+   gl_shader_stage stage,
+   bool is_scalar);
 
 #ifdef __cplusplus
 }
diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index 85e271d..467a893 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -143,7 +143,7 @@ brwProgramStringNotify(struct gl_context *ctx,
   brw_add_texrect_params(prog);
 
   if (ctx->Const.ShaderCompilerOptions[MESA_SHADER_FRAGMENT].NirOptions) {
- prog->nir = brw_create_nir(brw, NULL, prog, MESA_SHADER_FRAGMENT);
+ prog->nir = brw_create_nir(brw, NULL, prog, MESA_SHADER_FRAGMENT, 
true);
   }
 
   brw_fs_precompile(ctx, NULL, prog);
@@ -169,7 +169,8 @@ brwProgramStringNotify(struct gl_context *ctx,
   brw_add_texrect_params(prog);
 
   if (ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].NirOptions) {
- prog->nir = brw_create_nir(brw, NULL, prog, MESA_SHADER_VERTEX);
+ prog->nir = brw_create_nir(brw, NULL, prog, MESA_SHADER_VERTEX,
+brw->intelScreen->compiler->scalar_vs);
   }
 
   brw_vs_precompile(ctx, NULL, prog);
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp 
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 524798c..7c5095d 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -398,8 +398,10 @@ brw_link_shader(struct gl_context *ctx, struct 
gl_shader_program *shProg)
 
   brw_add_texrect_params(prog);
 
-  if (options->NirOptions)
- prog->nir = brw_create_nir(brw, shProg, prog, (gl_shader_stage) 
stage);
+  if (options->NirOptions) {
+ prog->nir = brw_create_nir(brw, shProg, prog, (gl_shader_stage) stage,
+is_scalar_shader_stage(brw, stage));
+  }
 
   _mesa_reference_program(ctx, &prog, NULL);
}
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index ce04f1b..4e55185 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1919,7 +1919,7 @@ brw_vs_emit(struct brw_context *brw,
   */
  assert(vp->Base.Id == 0 && prog == NULL);
  vp->Base.nir =
-brw_create_nir(brw, NULL, &vp->Base, MESA_SHADER_VERTEX);
+brw_create_nir(brw, NULL, &vp->Base, MESA_SHADER_VERTEX, true);
   }
 
   prog_data->base.dispatch_mode = DISPATCH_MODE_SIMD8;
-- 
2.4.6

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

Re: [Mesa-dev] [PATCH v2 00/78] i965: A new vec4 backend based on NIR

[Eduardo Lima Mitev]

On 07/31/2015 10:48 AM, Eduardo Lima Mitev wrote:
> On 07/30/2015 09:48 PM, Jason Ekstrand wrote:
>>
>> On Jul 27, 2015 3:39 PM, "Jason Ekstrand" > > wrote:
>>>
>>> On Mon, Jul 27, 2015 at 2:07 PM, Eduardo Lima Mitev > > wrote:
 On 07/25/2015 03:08 AM, Jason Ekstrand wrote:
> Alright, I got through it again...
>
> I asked for a few trivial changes on a few of the patches.  With those
> fixed, everything except patch 65 and 66 are
>

 Thanks! we have fixed most of the patches already.

> Reviewed-by: Jason Ekstrand > >
>
> While the requested changes on the texturing patches are not
> complicated, I would like to see the updated version of those two
> patches before I give a formal R-B.
>

 Sure, we will send new versions of patch 65 and 66 as soon as we have
 them ready and tested.

> There is one caveat to the above review: Something is badly broken on
> HSW.  I'm not sure what, but one of the patches badly breaks HSW even
> in the non-NIR case.  We need to figure out what that is before
> pushing anything.  That said, please don't re-send the full series;
> just figure out where the bug is, fix it, and re-send the one patch.
>

 We have done extensive testing today, trying to find something strange
 that explains this breakage you are experiencing. Most of us have HSW
 laptops so it is our normal development environments.

 However, we have not been able to reproduce any fail that would suggest
 our branch breaks something. Using current master as baseline, I have
 tested both nir-vec4 and vec4_visitor against it (piglit and dEQP), and
 we see no regressions other that the one we described in the cover
>> letter.

 Please, could you be more specific about the symptoms of this breakage
 and give us any possible info that would help us reproduce it locally?
 Maybe details of your system, kernel and gcc version; anything that
 might be different to a standard linux system.
>>>
>>> I'm not sure what happened there.  I may have had a bad rebase or
>>> something.  I pulled your branch, rebased on master, and tried it
>>> again.  Now it seems to be ok.  On Broadwell and Cherryview, however,
>>> it's not so ok.  It looks like you may have accidentally broken scalar
>>> VS or something like that.  I can't even run glxgears on BDW without
>>> hitting an assert.  If your dev machine is a HSW, you can use
>>> INTEL_DEVID_OVERRIDE to tell it to compile shaders as if it's a BDW
>>> and figure out why it's crashing.  The patch titled "nir/nir_lower_io:
>>> Add vec4 support" makes glxgears render black on BDW.  It seems like a
>>> later patch is causing the crash.  In any case, you should be able to
>>> use INTEL_DEVID_OVERRIDE and compare the shader results.
>>>
>>> --Jason
>>
>> Any progress on this?
>>
> 
> Yes, I think I found the issue and fixed it, (at least the only one I
> was able to find so far); and it was indeed the one causing the assert
> in glxgears.
> 
> Basically, it was a silly mistake in one of the patches I authored:
> https://github.com/Igalia/mesa/commit/2d72ae5f9e26c3c11dce9e779407984ef9774a52
> 
> You can see that I passed 'false' in 'is_scalar' argument of
> brw_create_nir() for ARB_vertex_programs, ignoring that in BDW those are
> scalar too. The fix was to pass 'brw->intelScreen->compiler->scalar_vs'
> instead of 'false' there.
> 
> Indirectly, this error was messing up the lowering passes in brw_nir,
> assuming non-scalar when it was scalar. Specifically, the pass
> nir_lower_alu_to_scalar() was not called because we disabled it on
> non-scalar shaders.
> 
> I will send a new version of the patch I changed, in case you want to
> have a look. I also updated the git-tree of the branch with the fix and
> rebased against master:
> 

I sent new versions of patches 09/78 and 74/78, which are the ones
modified to fix the issue in BDW. As I commented there, the changes are
trivial, but I send the new versions for the sake of reference and
completeness.

> https://github.com/Igalia/mesa/tree/nir-vec4-v2
> 

This branch has also been updated with the changes. In general, it is
safe to assume that this branch always contain the latest version of the
series we have.

> Please, let us know if you find more issues.
> 
> 
> Right now we have ~8 new piglit regressions (in HSW) after rebasing
> master. I'm currently analyzing them and hope to fix them soon. They are
> under "arb_shader_atomic_counters" set, so that you know in case you see
> them.
> 

I fixed this regressions already. Patch "i965: Lift the constness
restriction on surface indices passed to untyped ops." broke our the
atomics intrinsic code, but the fix was easy to trace.

So now the branch is back at zero regressions at least in 6 <= gen < 8.

> Thank you Jason!
> 
> Eduardo
> 
 Thanks again for the 

[Mesa-dev] [RFC] [PATCH] nir: Add a loop analysis pass

[Thomas Helland]

I was meant to send out this yesterday, but my git send-email
got corrupted again. Don't know what's up with that. But enough
with the chit-chat, here it is.

The pass is now working! It detects the induction variables
and calculates the unroll count correctly on the one shader
I've tried it on as of now. There'll be a lot more testing
to ensure that it works for other types of induction
variables than your average i++, and with other types than int.

There's still some stuff that's not up to par. There is a lot
of copying of results between the pass's structures and the
structures I've set up for permanent storage. I'm not really
happy about that, so I'll do a job at reducing the duplication.

There is also something fishy with the var-to-basic-ind
hash table. As of now I don't set up a new table and copy
over the information, so it will plain fail when used.

I haven't looked over the coding style at all, so there is
probably a lot of style issues, so don't spend to much time
looking into that.

And I see now that the makefile-changes is wrong. I'll fix that.

I also need to do something wrt swizzles. That will be my next
big thing on the list, as I also need to do a job witht that for
the value range propagation pass I'm writing.

With that said, those are mainly mechanical changes. I don't
expect the aproach I've taken to change a lot, so I think
it is now ready to be put on the list for a round of comments.

Signed-off-by: Thomas Helland 
---
 src/glsl/Makefile.sources   |   2 +
 src/glsl/nir/nir.h  |  75 +++-
 src/glsl/nir/nir_loop_analyze.c | 929 
 src/glsl/nir/nir_metadata.c |   2 +
 4 files changed, 1007 insertions(+), 1 deletion(-)
 create mode 100644 src/glsl/nir/nir_loop_analyze.c

diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
index d784a81..9e286b6 100644
--- a/src/glsl/Makefile.sources
+++ b/src/glsl/Makefile.sources
@@ -30,6 +30,8 @@ NIR_FILES = \
nir/nir_intrinsics.c \
nir/nir_intrinsics.h \
nir/nir_live_variables.c \
+   nir/nir_loop_analyze.c \
+   nir/nir_loop_analyze.h \
nir/nir_lower_alu_to_scalar.c \
nir/nir_lower_atomics.c \
nir/nir_lower_global_vars_to_local.c \
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index a0b4e5c..3818aba 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -70,7 +70,6 @@ struct nir_function;
 struct nir_shader;
 struct nir_instr;
 
-
 /**
  * Description of built-in state associated with a uniform
  *
@@ -1272,10 +1271,78 @@ nir_if_last_else_node(nir_if *if_stmt)
return exec_node_data(nir_cf_node, tail, node);
 }
 
+typedef enum {
+   undefined,
+   invariant,
+   basic_induction
+} nir_loop_variable_type;
+
+typedef struct {
+   /* The ssa_def associated with this info */
+   nir_ssa_def *def;
+
+   /* The type of this ssa_def */
+   nir_loop_variable_type type;
+
+   /* Link to the loop_variable list for the loop */
+   struct list_head loop_vars_link;
+
+   /* A link for a list of invariant variables */
+   struct list_head invariant_link;
+
+   /* A link for a list of induction variables */
+   struct list_head induction_link;
+
+   /* If the ssa-def is constant */
+   bool is_constant;
+
+   bool in_conditional_block;
+
+   bool in_nested_loop;
+} nir_loop_variable;
+
+typedef struct {
+   nir_op alu_op;/* The type of alu-operation  
  */
+   nir_loop_variable *alu_def;   /* The def of the 
alu-operation */
+   nir_loop_variable *invariant; /* The invariant alu-operand  
  */
+   nir_loop_variable *phi;   /* The other alu-operand  
  */
+   nir_loop_variable *def_outside_loop;  /* The phi-src outside the 
loop */
+} nir_basic_induction_var;
+
+typedef struct {
+   nir_if *nif;
+
+   /* Some more suitable fields like maybe indicated trip-count? */
+   nir_instr *conditional_instr;
+
+   struct list_head loop_terminator_link;
+} nir_loop_terminator;
+
+typedef struct {
+   /* Loop_variable for all ssa_defs in loop */
+   struct list_head loop_vars_list;
+
+   /* How many times the loop is run (if known) */
+   uint32_t trip_count;
+   bool is_trip_count_known;
+
+   nir_loop_terminator *limiting_terminator;
+
+   /* A list of loop_terminators terminating this loop XXX: These (apart from 
the limiting terminator) can be dead-code-eliminated */
+   struct list_head loop_terminator_list;
+
+   /* The ssa_defs that are invariant */
+   struct list_head invariant_list;
+
+   struct hash_table *var_to_basic_ind;
+} nir_loop_info;
+
 typedef struct {
nir_cf_node cf_node;
 
struct exec_list body; /** < list of nir_cf_node */
+
+   nir_loop_info *info;
 } nir_loop;
 
 static inline nir_cf_node *
@@ -1299,6 +1366,7 @@ typedef enum {
nir_metadata_block_index = 0x1,
nir_metadata_dominance = 0x2,
nir_metadata_live_variables = 0x4,
+   nir_metadata_loop_analysis = 0x5,
 } nir_metadata;
 
 typedef struc

Re: [Mesa-dev] [PATCH] includes/GL: remove duplicated extension declarations from glx.h

[Emil Velikov]

On 30 July 2015 at 16:44, Ian Romanick  wrote:
> On 07/30/2015 07:50 AM, Emil Velikov wrote:
>> On 30 July 2015 at 15:22, Emil Velikov  wrote:
>>> All three of GLX_NV_float_buffer, GLX_EXT_texture_from_pixmap and
>>> GLX_MESA_query_renderer have been in glxext.h for a while now.
>>>
>>> As such we can drop this workaround/hack from the header.
>>>
>>> Signed-off-by: Emil Velikov 
>>> ---
>>>
>>> Not to mention that glxext.h honours GLX_GLXEXT_PROTOTYPES and provides
>>> the relevant typedefs and/or function declarations when appropriate.
>>>
>>> -Emil
>>>
>>>  include/GL/glx.h | 88 
>>> 
>>>  1 file changed, 88 deletions(-)
>>>
>>> diff --git a/include/GL/glx.h b/include/GL/glx.h
>>> index 78f5052..d612b79 100644
>>> --- a/include/GL/glx.h
>>> +++ b/include/GL/glx.h
>>> @@ -371,14 +371,6 @@ extern Bool glXDrawableAttribARB(Display *dpy, 
>>> GLXDrawable draw, const int *attr
>>>  /*
>>>   * Remove this when glxext.h is updated.
>>>   */
>> Seems like I should drop this comment as well.
>>
>> On a related note: there are a few more extensions that never made it
>> (i.e. are missing from the Khronos public spec page) but are still
>> around.
>>
>> Namely
>> GLX_NV_vertex_array_range
>> - Shipped with nvidia's glxext.h, but unused in the binary driver
>> (version 352.21).
>> - Referenced in GLX_MESA_agp_offset - "GLX_NV_vertex_array_range is required"
>>
>> GLX_ARB_render_texture
>> - No hints in nvidia headers/binary.
>> - Referenced in GLX_EXT_texture_from_pixmap -  "Adapted spec language
>> from draft version of GLX_ARB_render_texture"
>> - The Khronos meeting minutes state "GLX_ARB_render_texture hasn't
>> been kept up to date, but there's no reason it can't be completed."
>> [1]
>>
>> GLX_MESA_swap_frame_usage
>> - No hints in nvidia headers/binary.
>> - No reference to in the public specs.
>>
>> GLX_MESA_swap_control
>> - No hints in nvidia headers/binary.
>> - Referenced by GLX_EXT_swap_control, "Based on GLX_MESA_swap_control
>> version 1.1"
>
> I think both of these have specs in the Mesa tree.
>
Indeed they are. As mentioned before I'm not advocating against them,
but merely curious if there are known users.

Which does bring another question - why some MESA/WL/CHROMIUM
extensions have made it to Khronos/opengl.org while others haven't ?
Are there any technical obstacles or it's mostly down to finding the
time to get it sorted ?

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

Re: [Mesa-dev] [PATCH 1/6] egl/x11: bail out if we cannot fetch the xcb connection

[Emil Velikov]

On 29 July 2015 at 18:17, Matt Turner  wrote:
> On Wed, Jul 29, 2015 at 9:19 AM, Emil Velikov  
> wrote:
>> Strictly speaking the xcb_connection_has_error() might be sufficient,
>> yet the documentation does not mention what will happen if NULL is fed
>> to the function.
>>
>> Keep things explicit, which will allow us to remove the dri2_dpy->conn
>> checking with the next commit.
>
> Its implementation is
>
> int xcb_connection_has_error(xcb_connection_t *c)
> {
> /* doesn't need locking because it's read and written atomically. */
> return c->has_error;
> }
>
> so passing NULL is certainly not okay. :)
Nice find Matt. I've updated the commit message as follows:

The documentation of xcb_connection_has_error() does not mention
what will happen, if NULL is fed to the function.

Upon closer look (props to Matt), it seems that we'll crash as the
implementation dereferences conn.

This will also allow us to remove the dri2_dpy->conn checking with the
next commit.

v2: Reword commit message as per Matt's findings.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 09/78] i965/nir: Pass a is_scalar boolean to brw_create_nir()

[Jason Ekstrand]

This looks better. Sorry I didn't catch the scalar vs problems before.
R-B
On Aug 1, 2015 5:16 AM, "Eduardo Lima Mitev"  wrote:

> The upcoming introduction of NIR->vec4 pass will require that some NIR
> lowering
> passes are enabled/disabled depending on the type of shader (scalar vs.
> vector).
>
> With this patch we pass a 'is_scalar' variable to the process of
> constructing the
> NIR, to let an external context decide how the shader should be handled.
> ---
>  src/mesa/drivers/dri/i965/brw_nir.c  | 3 ++-
>  src/mesa/drivers/dri/i965/brw_nir.h  | 3 ++-
>  src/mesa/drivers/dri/i965/brw_program.c  | 5 +++--
>  src/mesa/drivers/dri/i965/brw_shader.cpp | 6 --
>  src/mesa/drivers/dri/i965/brw_vec4.cpp   | 2 +-
>  5 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_nir.c
> b/src/mesa/drivers/dri/i965/brw_nir.c
> index 3e154c1..4aa893a 100644
> --- a/src/mesa/drivers/dri/i965/brw_nir.c
> +++ b/src/mesa/drivers/dri/i965/brw_nir.c
> @@ -61,7 +61,8 @@ nir_shader *
>  brw_create_nir(struct brw_context *brw,
> const struct gl_shader_program *shader_prog,
> const struct gl_program *prog,
> -   gl_shader_stage stage)
> +   gl_shader_stage stage,
> +   bool is_scalar)
>  {
> struct gl_context *ctx = &brw->ctx;
> const nir_shader_compiler_options *options =
> diff --git a/src/mesa/drivers/dri/i965/brw_nir.h
> b/src/mesa/drivers/dri/i965/brw_nir.h
> index 3131109..c76defd 100644
> --- a/src/mesa/drivers/dri/i965/brw_nir.h
> +++ b/src/mesa/drivers/dri/i965/brw_nir.h
> @@ -77,7 +77,8 @@ void brw_nir_analyze_boolean_resolves(nir_shader *nir);
>  nir_shader *brw_create_nir(struct brw_context *brw,
> const struct gl_shader_program *shader_prog,
> const struct gl_program *prog,
> -   gl_shader_stage stage);
> +   gl_shader_stage stage,
> +   bool is_scalar);
>
>  #ifdef __cplusplus
>  }
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c
> b/src/mesa/drivers/dri/i965/brw_program.c
> index 85e271d..467a893 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.c
> +++ b/src/mesa/drivers/dri/i965/brw_program.c
> @@ -143,7 +143,7 @@ brwProgramStringNotify(struct gl_context *ctx,
>brw_add_texrect_params(prog);
>
>if
> (ctx->Const.ShaderCompilerOptions[MESA_SHADER_FRAGMENT].NirOptions) {
> - prog->nir = brw_create_nir(brw, NULL, prog,
> MESA_SHADER_FRAGMENT);
> + prog->nir = brw_create_nir(brw, NULL, prog,
> MESA_SHADER_FRAGMENT, true);
>}
>
>brw_fs_precompile(ctx, NULL, prog);
> @@ -169,7 +169,8 @@ brwProgramStringNotify(struct gl_context *ctx,
>brw_add_texrect_params(prog);
>
>if
> (ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].NirOptions) {
> - prog->nir = brw_create_nir(brw, NULL, prog, MESA_SHADER_VERTEX);
> + prog->nir = brw_create_nir(brw, NULL, prog, MESA_SHADER_VERTEX,
> +
> brw->intelScreen->compiler->scalar_vs);
>}
>
>brw_vs_precompile(ctx, NULL, prog);
> diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
> b/src/mesa/drivers/dri/i965/brw_shader.cpp
> index 524798c..7c5095d 100644
> --- a/src/mesa/drivers/dri/i965/brw_shader.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
> @@ -398,8 +398,10 @@ brw_link_shader(struct gl_context *ctx, struct
> gl_shader_program *shProg)
>
>brw_add_texrect_params(prog);
>
> -  if (options->NirOptions)
> - prog->nir = brw_create_nir(brw, shProg, prog, (gl_shader_stage)
> stage);
> +  if (options->NirOptions) {
> + prog->nir = brw_create_nir(brw, shProg, prog, (gl_shader_stage)
> stage,
> +is_scalar_shader_stage(brw, stage));
> +  }
>
>_mesa_reference_program(ctx, &prog, NULL);
> }
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index ce04f1b..4e55185 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -1919,7 +1919,7 @@ brw_vs_emit(struct brw_context *brw,
>*/
>   assert(vp->Base.Id == 0 && prog == NULL);
>   vp->Base.nir =
> -brw_create_nir(brw, NULL, &vp->Base, MESA_SHADER_VERTEX);
> +brw_create_nir(brw, NULL, &vp->Base, MESA_SHADER_VERTEX,
> true);
>}
>
>prog_data->base.dispatch_mode = DISPATCH_MODE_SIMD8;
> --
> 2.4.6
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 74/78] i965/vec4: Enable NIR-vec4 pass on ARB_vertex_programs

[Jason Ekstrand]

LGTM RB
On Aug 1, 2015 5:16 AM, "Eduardo Lima Mitev"  wrote:

> From: Antia Puentes 
>
> ---
>  src/mesa/drivers/dri/i965/brw_vec4.cpp | 47
> +-
>  1 file changed, 24 insertions(+), 23 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index 8d83887..88b601a 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -1732,18 +1732,16 @@ vec4_visitor::run(gl_clip_plane *clip_planes)
>
> emit_prolog();
>
> -   if (shader) {
> -  if (use_vec4_nir) {
> - assert(prog->nir != NULL);
> - emit_nir_code();
> - if (failed)
> -return false;
> -  } else {
> - /* Generate VS IR for main().  (the visitor only descends into
> -  * functions called "main").
> -  */
> - visit_instructions(shader->base.ir);
> -  }
> +   if (use_vec4_nir) {
> +  assert(prog->nir != NULL);
> +  emit_nir_code();
> +  if (failed)
> + return false;
> +   } else if (shader) {
> +  /* Generate VS IR for main().  (the visitor only descends into
> +   * functions called "main").
> +   */
> +  visit_instructions(shader->base.ir);
> } else {
>emit_program_code();
> }
> @@ -1921,18 +1919,21 @@ brw_vs_emit(struct brw_context *brw,
> if (unlikely(INTEL_DEBUG & DEBUG_VS))
>brw_dump_ir("vertex", prog, &shader->base, &vp->Base);
>
> -   if (brw->intelScreen->compiler->scalar_vs) {
> -  if (!vp->Base.nir) {
> - /* Normally we generate NIR in LinkShader() or
> -  * ProgramStringNotify(), but Mesa's fixed-function vertex
> program
> -  * handling doesn't notify the driver at all.  Just do it here,
> at
> -  * the last minute, even though it's lame.
> -  */
> - assert(vp->Base.Id == 0 && prog == NULL);
> - vp->Base.nir =
> -brw_create_nir(brw, NULL, &vp->Base, MESA_SHADER_VERTEX,
> true);
> -  }
> +   if (!vp->Base.nir &&
> +   (brw->intelScreen->compiler->scalar_vs ||
> +
> brw->intelScreen->compiler->glsl_compiler_options[MESA_SHADER_VERTEX].NirOptions
> != NULL)) {
> +  /* Normally we generate NIR in LinkShader() or
> +   * ProgramStringNotify(), but Mesa's fixed-function vertex program
> +   * handling doesn't notify the driver at all.  Just do it here, at
> +   * the last minute, even though it's lame.
> +   */
> +  assert(vp->Base.Id == 0 && prog == NULL);
> +  vp->Base.nir =
> + brw_create_nir(brw, NULL, &vp->Base, MESA_SHADER_VERTEX,
> +brw->intelScreen->compiler->scalar_vs);
> +   }
>
> +   if (brw->intelScreen->compiler->scalar_vs) {
>prog_data->base.dispatch_mode = DISPATCH_MODE_SIMD8;
>
>fs_visitor v(brw->intelScreen->compiler, brw,
> --
> 2.4.6
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/7] mesa: Replace uses of IROUND{, 64} with libm functions.

[Brian Paul]

I don't remember the specifics, but I recall some of the old conformance
tests being sensitive to float->int conversion in a few areas.  Matt, if
you have access to the conform tests and can run the old swrast driver with
your change, that'd be interesting.

-Brian


On Fri, Jul 31, 2015 at 7:52 PM, Roland Scheidegger 
wrote:

> I have some doubts of this. Given that IROUND was just plain incorrect,
> I think we should just use _mesa_lroundevenf() and see what happens.
> lroundf() is quite the shocker, my libm's implementation is totalling 40
> instructions (!) for it (not counting the last return, vs 1 for lrintf).
> Now it's probably not THAT bad (not all these 40 instructions will be
> executed), it still looks expensive (and gcc won't attempt to use a
> built-in for that mess, quite understandable).
> I don't see GL mentioning requiring such explicit rounding in general
> (though for instance the EXT_texture_shared_exponent does this
> implicitly, albeit I'm wondering if that was by choice or accident...).
> Different tie breaker (which we'd get with lrintf) sounds like a win
> over just bogus rounding (which we got before) any day to me.
>
> Roland
>
>
> Am 01.08.2015 um 01:26 schrieb Matt Turner:
> > lroundf is the most common replacement. I replaced uses of IROUND()
> > where there was a comment saying "rounded to nearest integer" with
> > _mesa_lroundevenf.
> >
> > IROUND64 is replaced with llroundf.
> > ---
> >  src/mesa/main/drawpix.c | 21 +++--
> >  src/mesa/main/eval.c| 14 +++---
> >  src/mesa/main/get.c | 28 ++--
> >  src/mesa/main/imports.h | 18 --
> >  src/mesa/main/light.c   |  8 
> >  src/mesa/main/pixel.c   |  2 +-
> >  src/mesa/main/pixelstore.c  |  3 ++-
> >  src/mesa/main/samplerobj.c  |  8 
> >  src/mesa/main/texparam.c|  8 
> >  src/mesa/main/uniform_query.cpp |  2 +-
> >  src/mesa/swrast/s_blit.c|  2 +-
> >  src/mesa/swrast/s_context.h |  2 +-
> >  12 files changed, 50 insertions(+), 66 deletions(-)
> >
> > diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c
> > index 720a082..025cf7e 100644
> > --- a/src/mesa/main/drawpix.c
> > +++ b/src/mesa/main/drawpix.c
> > @@ -22,6 +22,7 @@
> >   * OTHER DEALINGS IN THE SOFTWARE.
> >   */
> >
> > +#include "c99_math.h"
> >  #include "glheader.h"
> >  #include "imports.h"
> >  #include "bufferobj.h"
> > @@ -51,14 +52,14 @@ _mesa_DrawPixels( GLsizei width, GLsizei height,
> > FLUSH_VERTICES(ctx, 0);
> >
> > if (MESA_VERBOSE & VERBOSE_API)
> > -  _mesa_debug(ctx, "glDrawPixels(%d, %d, %s, %s, %p) // to %s at
> %d, %d\n",
> > +  _mesa_debug(ctx, "glDrawPixels(%d, %d, %s, %s, %p) // to %s at
> %ld, %ld\n",
> >width, height,
> >_mesa_enum_to_string(format),
> >_mesa_enum_to_string(type),
> >pixels,
> >
> _mesa_enum_to_string(ctx->DrawBuffer->ColorDrawBuffer[0]),
> > -  IROUND(ctx->Current.RasterPos[0]),
> > -  IROUND(ctx->Current.RasterPos[1]));
> > +  lroundf(ctx->Current.RasterPos[0]),
> > +  lroundf(ctx->Current.RasterPos[1]));
> >
> >
> > if (width < 0 || height < 0) {
> > @@ -140,8 +141,8 @@ _mesa_DrawPixels( GLsizei width, GLsizei height,
> > if (ctx->RenderMode == GL_RENDER) {
> >if (width > 0 && height > 0) {
> >   /* Round, to satisfy conformance tests (matches SGI's OpenGL)
> */
> > - GLint x = IROUND(ctx->Current.RasterPos[0]);
> > - GLint y = IROUND(ctx->Current.RasterPos[1]);
> > + GLint x = lroundf(ctx->Current.RasterPos[0]);
> > + GLint y = lroundf(ctx->Current.RasterPos[1]);
> >
> >   if (_mesa_is_bufferobj(ctx->Unpack.BufferObj)) {
> >  /* unpack from PBO */
> > @@ -196,13 +197,13 @@ _mesa_CopyPixels( GLint srcx, GLint srcy, GLsizei
> width, GLsizei height,
> >
> > if (MESA_VERBOSE & VERBOSE_API)
> >_mesa_debug(ctx,
> > -  "glCopyPixels(%d, %d, %d, %d, %s) // from %s to %s at
> %d, %d\n",
> > +  "glCopyPixels(%d, %d, %d, %d, %s) // from %s to %s at
> %ld, %ld\n",
> >srcx, srcy, width, height,
> >_mesa_enum_to_string(type),
> >
> _mesa_enum_to_string(ctx->ReadBuffer->ColorReadBuffer),
> >
> _mesa_enum_to_string(ctx->DrawBuffer->ColorDrawBuffer[0]),
> > -  IROUND(ctx->Current.RasterPos[0]),
> > -  IROUND(ctx->Current.RasterPos[1]));
> > +  lroundf(ctx->Current.RasterPos[0]),
> > +  lroundf(ctx->Current.RasterPos[1]));
> >
> > if (width < 0 || height < 0) {
> >_mesa_error(ctx, GL_INVALID_VALUE, "glCopyPixels(width or height
> < 0)");
> > @@ -264,8 +265,8 @@ _mesa_CopyPixels( GLint srcx, GLint srcy, GLsizei
> width, GLsizei height,
> > if (ctx->RenderMode == GL_REN

Re: [Mesa-dev] [PATCH] i965: Fix missing BRW_NEW_FS_PROG_DATA in gen6_renderbuffer_surfaces.

[Emil Velikov]

On 6 July 2015 at 21:40, Kenneth Graunke  wrote:
> On Monday, July 06, 2015 12:18:18 PM Matt Turner wrote:
>> On Mon, Jul 6, 2015 at 9:55 AM, Kenneth Graunke  
>> wrote:
>> > It looks like this was forgotten in commit 3c9dc2d31b80fc73bffa1f40a
>> > (i965: Make a brw_stage_prog_data for storing the SURF_INDEX
>> > information.)   In other words, it's been missing since we moved to
>> > dynamic binding table slot assignments.
>>
>> Author: Eric Anholt 
>> AuthorDate: Wed Oct 2 14:07:40 2013 -0700
>> CommitDate: Tue Oct 15 10:18:42 2013 -0700
>>
>> Dang.
>>
>> How did you find this?
>
> After reading Eero's latest performance analysis observations, I decided
> to try marking render targets uncached (MOCS = UC) when blending and
> logic ops (i.e. things that cause render target reads) are disabled.
>
> This necessitated adding _NEW_COLOR.  Then I realized
> BRW_NEW_FS_PROG_DATA was just plain missing.
>
Seems like this patch has fallen between the cracks. Can anyone take a
look or let me know if it's no longer applicable.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] i965/bdw: Fix 3DSTATE_VF_INSTANCING when the edge flag is used

[Emil Velikov]

Hello Neil,

On 10 July 2015 at 18:04, Neil Roberts  wrote:
> When the edge flag element is enabled then the elements are slightly
> reordered so that the edge flag is always the last one. This was
> confusing the code to upload the 3DSTATE_VF_INSTANCING state because
> that is uploaded with a separate loop which has an instruction for
> each element. The indices used in these instructions weren't taking
> into account the reordering so the state would be incorrect.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91292
> Cc: "10.6 10.5" 
Based of Chris's response can you please confirm if there are any
plans of pushing this patch or alternative approach will be used ?
I'm going through the list of nominated patches and would like to know
if we should keep or drop this one.

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

Re: [Mesa-dev] [PATCH 1/2] gallium/drivers: Add threadsafe wrappers for pipe_context v2

[Emil Velikov]

On 11 July 2015 at 02:55, Tom Stellard  wrote:
> These wrappers can be used by state trackers to ensure threadsafe access
> to pipe_context objects.
>
> v2:
>   - Don't add wrappers for pipe_screen.
>   - Build system cleanups
>
> CC: 10.6 
Humble ping.

Seems that this series never landed in master, despite Marek/Francisco's review.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] clover: Fix bug with computing hard_event status

[Emil Velikov]

On 16 July 2015 at 19:16, Tom Stellard  wrote:
> On Sat, Jul 11, 2015 at 02:35:53PM +0300, Francisco Jerez wrote:
>> Tom Stellard  writes:
>>
>> > pipe_context::flush() can return a NULL fence if the queue is already
>> > empty, so we should not assume that an event with a NULL fence
>> > has the status of CL_QUEUED.
>> >
>>
>> This seems suspicious...  On the one hand it doesn't seem to be a
>> documented "feature" of pipe_context::flush to return NULL except in
>> error conditions (I'm pretty sure other drivers like nouveau won't), and
>> it seems like it could easily break assumptions of other state trackers.
>>
>> IMO pipe_context::flush() should respect the invariant that whatever is
>> returned in the fence output argument (unless some error occurred) be a
>> valid argument for pipe_screen::fence_finish() and ::fence_signalled()
>> -- I don't think NULL is?
>>
>> On the other hand this leaves me wondering how could the queue already
>> be empty when clover calls pipe_context::flush() -- I assume by queue
>> you mean the pipe driver's?  The fact that clover calls
>> pipe_context::flush() implies that clover's event queue is not empty
>> (i.e. there have been commands enqueued to the pipe driver since the
>> last call to pipe_context::flush()).  It sounds like this mismatch
>> between clover's and the pipe driver's command queue might be caused by
>> some race condition elsewhere?
>>
>> Thanks.
>>
>
> The bug appears in programs which call clFinish() without ever
> adding anything to the command queue.  In this case, radeonsi
> sees that no commands have been submitted to the GPU, so it doesn't
> submit the fence and sets the fence parameter to NULL.
>
Gents, do we still need this considering the recent fixes by
Marek/Michel in radeonsi/r600 ?

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] clover: Fix bug with computing hard_event status

[Marek Olšák]

No, we don't need this. radeonsi doesn't return a NULL fence anymore.

Marek

On Sat, Aug 1, 2015 at 6:54 PM, Emil Velikov  wrote:
> On 16 July 2015 at 19:16, Tom Stellard  wrote:
>> On Sat, Jul 11, 2015 at 02:35:53PM +0300, Francisco Jerez wrote:
>>> Tom Stellard  writes:
>>>
>>> > pipe_context::flush() can return a NULL fence if the queue is already
>>> > empty, so we should not assume that an event with a NULL fence
>>> > has the status of CL_QUEUED.
>>> >
>>>
>>> This seems suspicious...  On the one hand it doesn't seem to be a
>>> documented "feature" of pipe_context::flush to return NULL except in
>>> error conditions (I'm pretty sure other drivers like nouveau won't), and
>>> it seems like it could easily break assumptions of other state trackers.
>>>
>>> IMO pipe_context::flush() should respect the invariant that whatever is
>>> returned in the fence output argument (unless some error occurred) be a
>>> valid argument for pipe_screen::fence_finish() and ::fence_signalled()
>>> -- I don't think NULL is?
>>>
>>> On the other hand this leaves me wondering how could the queue already
>>> be empty when clover calls pipe_context::flush() -- I assume by queue
>>> you mean the pipe driver's?  The fact that clover calls
>>> pipe_context::flush() implies that clover's event queue is not empty
>>> (i.e. there have been commands enqueued to the pipe driver since the
>>> last call to pipe_context::flush()).  It sounds like this mismatch
>>> between clover's and the pipe driver's command queue might be caused by
>>> some race condition elsewhere?
>>>
>>> Thanks.
>>>
>>
>> The bug appears in programs which call clFinish() without ever
>> adding anything to the command queue.  In this case, radeonsi
>> sees that no commands have been submitted to the GPU, so it doesn't
>> submit the fence and sets the fence parameter to NULL.
>>
> Gents, do we still need this considering the recent fixes by
> Marek/Michel in radeonsi/r600 ?
>
> -Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH 16/18] i965: Prevent coordinate overflow in intel_emit_linear_blit

[Emil Velikov]

Hello all,

On 20 July 2015 at 18:08, Anuj Phogat  wrote:
> On Sat, Jul 18, 2015 at 1:24 AM, Chris Wilson  
> wrote:
>> On Fri, Jul 17, 2015 at 05:12:54PM -0700, Anuj Phogat wrote:
>>> On Mon, Jul 6, 2015 at 3:33 AM, Chris Wilson  
>>> wrote:
>>> > +   do {
>>> > +  /* The pitch given to the GPU must be DWORD aligned, and
>>> > +   * we want width to match pitch. Max width is (1 << 15 - 1),
>>> > +   * rounding that down to the nearest DWORD is 1 << 15 - 4
>>> > +   */
>>> > +  pitch = ROUND_DOWN_TO(MIN2(size, (1 << 15) - 64), 4);
>>> I understand why you are subtracting 64 in above statement, it'll
>>> be nice to update above comment explaining the reason.
>>
>> We use the pitch to set the copy width, so the maximum x coordinate
>> becomes src_x + pitch. Since src_x has a maximum value of 63, we want to
>> make sure that pitch is less than 32627-63. Simplified above.
>>
>>> > +  height = (size < pitch || pitch == 0) ? 1 : size / pitch;
>> ...
>>> > +  pitch *= height;
>>> > +  if (size <= pitch)
>>> I think size < pitch will never be true. How about:
>>> assert(size < pitch);
>>
>> For a single row copy, size can be less than pitch.
> right.
>
> Reviewed-by: Anuj Phogat 
It doesn't seem that the patch has landed in master despite the review
from Anuj. Is it missing something or did it fell through the cracks ?

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] xa: add xa_surface_from_handle2

[Emil Velikov]

On 22 July 2015 at 00:00, Rob Clark  wrote:
> From: Rob Clark 
>
> Like xa_surface_from_handle(), but takes a handle type, rather than
> hard-coding 'shared' handle.  This is needed to fix bugs seen with
> xf86-video-freedreno with xrandr rotation, for example.  The root issue
> is that doing a GEM_OPEN ioctl on a bo that already has a GEM handle
> associated with the drm_file will result in two unique handles for the
> same bo.  Which causes all sorts of follow-on fail.
>
> Cc: "10.5 10.6" 
> Signed-off-by: Rob Clark 
> ---
> Note: it would be good to get this in stable too, since I have a patch
> for xf86-video-freedreno which will depend on this.
>
Bth, I'm not too excited about having new APIs in the stable branch,
despite them being trivial as this one.
Regardless it would be nice to get a pair of eyes looking in this direction.

The patch does exactly what it says on the tin, although I do wonder
if we should bump XA_TRACKER_VERSION_MINOR ?

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

Re: [Mesa-dev] [PATCH 5/5] vc4: add missing nir include, to fix the build

[Emil Velikov]

On 21 July 2015 at 13:14, Emil Velikov  wrote:
> On 17/07/15 18:17, Emil Velikov wrote:
>> Cc: 10.6 
>> Cc: Eric Anholt 
>> Signed-off-by: Emil Velikov 
>> ---
>>  src/gallium/drivers/vc4/Makefile.am | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/src/gallium/drivers/vc4/Makefile.am 
>> b/src/gallium/drivers/vc4/Makefile.am
>> index a4a7f86..3b78502 100644
>> --- a/src/gallium/drivers/vc4/Makefile.am
>> +++ b/src/gallium/drivers/vc4/Makefile.am
>> @@ -28,6 +28,7 @@ SIM_LDFLAGS = -lsimpenrose
>>  endif
>>
>>  AM_CFLAGS = \
>> + -I$(top_builddir)/src/glsl/nir \
>>   $(LIBDRM_CFLAGS) \
>>   $(GALLIUM_DRIVER_CFLAGS) \
>>   $(SIM_CFLAGS)
>>
> With all the interest that 1/5 has inspired, this (dare I say it)
> crusial patch has gone unnoticed.
>
> Eric,
> Can you kindly let me know how manage to build vc4, without this one ?
> Things just fail on my machine (note I'm doing an out-of-tree builds).
>
Humble ping ?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/12] bmake inspired fixes

[Emil Velikov]

On 17 July 2015 at 19:53, Emil Velikov  wrote:
> On 17 July 2015 at 19:09, Matt Turner  wrote:
>> On Fri, Jul 17, 2015 at 10:29 AM, Emil Velikov  
>> wrote:
>>> Hello all,
>>>
>>> A few days ago I realised that BSD make (bmake) is available in the
>>> Archlinux repos, so I decided to give it a try for drm & mesa.
>>>
>>> While the former was working (minus a small patch) mesa is not so lucky.
>>>
>>> This series attempts to remove the GNU make idioms, with the first two
>>> being the base essential for a successful build from tarball.
>>
>> ... why should we care about non-GNU make? GNU make has nice features
>> that we want to use and we use them. I don't see the benefit.
>>
> A few reasons:
>  - It will allow the OpenBSD people to use upstream mesa and devote
> that time to something more useful ?
>  - Mostly a single pattern/issue/thinko seems to be at fault.
>  - The rules already look a bit shaky :-)
>
> Note that part from fixing the bmake build the rules are written to
> honour the relevant FLAGS and be consistent.
>
Matt would the above sound reasonable ? I'll be great to be more
welcoming to the OpenBSD people, esp. since there aren't that many or
serious "issues".

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] clover: Fix bug with computing hard_event status

[Emil Velikov]

On 1 August 2015 at 17:57, Marek Olšák  wrote:
> No, we don't need this. radeonsi doesn't return a NULL fence anymore.
>
Glad to hear. On the other hand is that fix in stable ? I believe the
following commit resolves the issue, yet it's a bit short of
nomination.
Can anyone confirm if we need it for 10.6 ?

commit 800efb0690e962750b9a072bcbab279fdaae24a1
Author: Michel Dänzer 
Date:   Wed Jul 22 16:11:39 2015 +0900

radeonsi: Flush when we're asked to return a fence but don't have one yet

Reviewed-by: Marek Olšák 


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

[Mesa-dev] [Bug 91468] LLVM 3.8(svn): llvm changes llvm-config output again?

[bugzilla-daemon]

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

Krzysztof A. Sobiecki  changed:

   What|Removed |Added

 CC||sob...@gmail.com,
   ||sylves...@debian.org

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] clover: Fix bug with computing hard_event status

[Marek Olšák]

On Sat, Aug 1, 2015 at 7:29 PM, Emil Velikov  wrote:
> On 1 August 2015 at 17:57, Marek Olšák  wrote:
>> No, we don't need this. radeonsi doesn't return a NULL fence anymore.
>>
> Glad to hear. On the other hand is that fix in stable ? I believe the
> following commit resolves the issue, yet it's a bit short of
> nomination.
> Can anyone confirm if we need it for 10.6 ?
>
> commit 800efb0690e962750b9a072bcbab279fdaae24a1
> Author: Michel Dänzer 
> Date:   Wed Jul 22 16:11:39 2015 +0900
>
> radeonsi: Flush when we're asked to return a fence but don't have one yet
>
> Reviewed-by: Marek Olšák 

This and Tom's patch fix a bug introduced in:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=f1be3d8cdde17a9b9ae283e1bab2f46b992d3bf3

which is not in 10.6 as far as I know, so none of these fixes need to
be in 10.6.

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

[Mesa-dev] [PATCH] vl/mpeg12: Silence GCC unused-variable warning.

[Vinson Lee]

vl/vl_mpeg12_bitstream.c: In function 'decode_slice':
vl/vl_mpeg12_bitstream.c:928:19: warning: unused variable 'extra' 
[-Wunused-variable]
  unsigned extra = vl_vlc_get_uimsbf(&bs->vlc, 1);
   ^

Signed-off-by: Vinson Lee 
---
 src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c 
b/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
index 539a991..52ce6c4 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
@@ -929,6 +929,7 @@ decode_slice(struct vl_mpg12_bs *bs, struct 
pipe_video_buffer *target)
  mb.PMV[1][0][0] = mb.PMV[0][0][0];
  mb.PMV[1][0][1] = mb.PMV[0][0][1];
  assert(extra);
+ (void) extra;
   } else if (mb.macroblock_type & PIPE_MPEG12_MB_TYPE_INTRA ||
 !(mb.macroblock_type & (PIPE_MPEG12_MB_TYPE_MOTION_FORWARD |
 PIPE_MPEG12_MB_TYPE_MOTION_BACKWARD))) 
{
-- 
2.1.4

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

[Mesa-dev] [Bug 73512] [clover] mesa.icd. should contain full path

[bugzilla-daemon]

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

Igor Gnatenko  changed:

   What|Removed |Added

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

--- Comment #15 from Igor Gnatenko  ---
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4d7e0fa8c731776ad5d630f37b36c535f1907371

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] xa: add xa_surface_from_handle2

[Rob Clark]

On Sat, Aug 1, 2015 at 1:16 PM, Emil Velikov  wrote:
> On 22 July 2015 at 00:00, Rob Clark  wrote:
>> From: Rob Clark 
>>
>> Like xa_surface_from_handle(), but takes a handle type, rather than
>> hard-coding 'shared' handle.  This is needed to fix bugs seen with
>> xf86-video-freedreno with xrandr rotation, for example.  The root issue
>> is that doing a GEM_OPEN ioctl on a bo that already has a GEM handle
>> associated with the drm_file will result in two unique handles for the
>> same bo.  Which causes all sorts of follow-on fail.
>>
>> Cc: "10.5 10.6" 
>> Signed-off-by: Rob Clark 
>> ---
>> Note: it would be good to get this in stable too, since I have a patch
>> for xf86-video-freedreno which will depend on this.
>>
> Bth, I'm not too excited about having new APIs in the stable branch,
> despite them being trivial as this one.
> Regardless it would be nice to get a pair of eyes looking in this direction.
>
> The patch does exactly what it says on the tin, although I do wonder
> if we should bump XA_TRACKER_VERSION_MINOR ?

well, I guess we can punt on this one.. it seems kind of asymmetrical
to the get_handle API to not support the various different sorts of
handles..  But I still end up running into problems, since I end up
with two different 'fd_device' instances (so two sets of hashtables to
track already-imported-handles/etc) between the ddx code and xa
(gallium)..

In the end just using -modesetting+glamor seems like an easier fix..

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] xa: add xa_surface_from_handle2

[Thomas Hellstrom]

Hi!

On 08/01/2015 07:16 PM, Emil Velikov wrote:
> On 22 July 2015 at 00:00, Rob Clark  wrote:
>> From: Rob Clark 
>>
>> Like xa_surface_from_handle(), but takes a handle type, rather than
>> hard-coding 'shared' handle.  This is needed to fix bugs seen with
>> xf86-video-freedreno with xrandr rotation, for example.  The root issue
>> is that doing a GEM_OPEN ioctl on a bo that already has a GEM handle
>> associated with the drm_file will result in two unique handles for the
>> same bo.  Which causes all sorts of follow-on fail.
>>
>> Cc: "10.5 10.6" 
>> Signed-off-by: Rob Clark 
>> ---
>> Note: it would be good to get this in stable too, since I have a patch
>> for xf86-video-freedreno which will depend on this.
>>
> Bth, I'm not too excited about having new APIs in the stable branch,
> despite them being trivial as this one.
> Regardless it would be nice to get a pair of eyes looking in this direction.
>
> The patch does exactly what it says on the tin, although I do wonder
> if we should bump XA_TRACKER_VERSION_MINOR ?

I haven't had time yet to look at the patch itself (I'm on vacation and
back next week), but having XA recognize handle types, in particular
dma-buf fds is, IMO a good thing.

Regarding adding new interfaces to XA, the XA documentation is pretty
explicit about how this should be handled and recognized, with version
numbers. As long as all XA users follow this, it should be pretty
straightforward also in a stable mesa branch. IIRC, the XA minor must be
bumped in this case, and an out-of-mesa-tree user can't rely on the
symbol being present, since an old libxatracker with the same major
number might be present, but needs to use dlsym() or something similar.

/Thomas

>
> Thanks
> Emil

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

Re: [Mesa-dev] [PATCH 01/20] mesa: fix and simplify resource query for arrays

[Matt Turner]

On Wed, Jul 29, 2015 at 6:56 AM, Timothy Arceri  wrote:
> This removes the need for multiple functions designed to validate an array
> subscript and replaces them with a call to a single function.
>
> The change also means that validation is now only done once and the index
> is retrived at the same time, as a result the getUniformLocation code can
> be simplified saving an extra hash table lookup (and yet another
> validation call).
>
> This chage also fixes some tests in:
> ES31-CTS.program_interface_query.uniform
>
> V3: rebase on subroutines, and move the resource index array == 0
> check into _mesa_GetProgramResourceIndex() to simplify things further
>
> V2: Fix bounds checks for program input/output, split unrelated comment fix
> and _mesa_get_uniform_location() removal into their own patch.
>
> Cc: Tapani Pälli 
> ---
>  src/mesa/main/program_resource.c |  14 ++--
>  src/mesa/main/shader_query.cpp   | 174 
> +--
>  src/mesa/main/shaderapi.c|   2 +-
>  src/mesa/main/shaderapi.h|   3 +-
>  src/mesa/main/uniforms.c |   5 +-
>  5 files changed, 106 insertions(+), 92 deletions(-)
>
> diff --git a/src/mesa/main/program_resource.c 
> b/src/mesa/main/program_resource.c
> index 641ef22..fdbd5b3 100644
> --- a/src/mesa/main/program_resource.c
> +++ b/src/mesa/main/program_resource.c
> @@ -229,6 +229,7 @@ _mesa_GetProgramResourceIndex(GLuint program, GLenum 
> programInterface,
>const GLchar *name)
>  {
> GET_CURRENT_CONTEXT(ctx);
> +   unsigned array_index = 0;
> struct gl_program_resource *res;
> struct gl_shader_program *shProg =
>_mesa_lookup_shader_program_err(ctx, program,
> @@ -268,13 +269,10 @@ _mesa_GetProgramResourceIndex(GLuint program, GLenum 
> programInterface,
> case GL_PROGRAM_OUTPUT:
> case GL_UNIFORM:
> case GL_TRANSFORM_FEEDBACK_VARYING:
> -  /* Validate name syntax for array variables */
> -  if (!valid_program_resource_index_name(name))
> - return GL_INVALID_INDEX;
> -  /* fall-through */
> case GL_UNIFORM_BLOCK:
> -  res = _mesa_program_resource_find_name(shProg, programInterface, name);
> -  if (!res)
> +  res = _mesa_program_resource_find_name(shProg, programInterface, name,
> + &array_index);
> +  if (!res || array_index > 0)
>   return GL_INVALID_INDEX;
>
>return _mesa_program_resource_index(shProg, res);
> @@ -403,7 +401,7 @@ _mesa_GetProgramResourceLocation(GLuint program, GLenum 
> programInterface,
> struct gl_shader_program *shProg =
>lookup_linked_program(program, "glGetProgramResourceLocation");
>
> -   if (!shProg || !name || invalid_array_element_syntax(name))
> +   if (!shProg || !name)
>return -1;
>
> /* Validate programInterface. */
> @@ -453,7 +451,7 @@ _mesa_GetProgramResourceLocationIndex(GLuint program, 
> GLenum programInterface,
> struct gl_shader_program *shProg =
>lookup_linked_program(program, "glGetProgramResourceLocationIndex");
>
> -   if (!shProg || !name || invalid_array_element_syntax(name))
> +   if (!shProg || !name)
>return -1;
>
> /* From the GL_ARB_program_interface_query spec:
> diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
> index 3e52a09..dd11b81 100644
> --- a/src/mesa/main/shader_query.cpp
> +++ b/src/mesa/main/shader_query.cpp
> @@ -44,7 +44,8 @@ extern "C" {
>
>  static GLint
>  program_resource_location(struct gl_shader_program *shProg,
> -  struct gl_program_resource *res, const char *name);
> +  struct gl_program_resource *res, const char *name,
> +  unsigned array_index);
>
>  /**
>   * Declare convenience functions to return resource data in a given type.
> @@ -272,13 +273,15 @@ _mesa_GetAttribLocation(GLhandleARB program, const 
> GLcharARB * name)
> if (shProg->_LinkedShaders[MESA_SHADER_VERTEX] == NULL)
>return -1;
>
> +   unsigned array_index = 0;
> struct gl_program_resource *res =
> -  _mesa_program_resource_find_name(shProg, GL_PROGRAM_INPUT, name);
> +  _mesa_program_resource_find_name(shProg, GL_PROGRAM_INPUT, name,
> +   &array_index);
>
> if (!res)
>return -1;
>
> -   GLint loc = program_resource_location(shProg, res, name);
> +   GLint loc = program_resource_location(shProg, res, name, array_index);
>
> /* The extra check against against 0 is made because of builtin-attribute
>  * locations that have offset applied. Function program_resource_location
> @@ -456,13 +459,15 @@ _mesa_GetFragDataLocation(GLuint program, const GLchar 
> *name)
> if (shProg->_LinkedShaders[MESA_SHADER_FRAGMENT] == NULL)
>return -1;
>
> +   unsigned array_index = 0;
> struct gl_program_resource *res =
> -  _mesa_program_resource_find_name(shProg, GL_PROGRAM_OUTPUT, name);
> +  _mesa_p

Re: [Mesa-dev] [PATCH 01/20] mesa: fix and simplify resource query for arrays

[Timothy Arceri]

On Sat, 2015-08-01 at 15:58 -0700, Matt Turner wrote:
> On Wed, Jul 29, 2015 at 6:56 AM, Timothy Arceri  
> wrote:
> > This removes the need for multiple functions designed to validate an array
> > subscript and replaces them with a call to a single function.
> > 
> > The change also means that validation is now only done once and the index
> > is retrived at the same time, as a result the getUniformLocation code can
> > be simplified saving an extra hash table lookup (and yet another
> > validation call).
> > 
> > This chage also fixes some tests in:
> > ES31-CTS.program_interface_query.uniform
> > 
> > V3: rebase on subroutines, and move the resource index array == 0
> > check into _mesa_GetProgramResourceIndex() to simplify things further
> > 
> > V2: Fix bounds checks for program input/output, split unrelated comment 
> > fix
> > and _mesa_get_uniform_location() removal into their own patch.
> > 
> > Cc: Tapani Pälli 
> > ---
> >  src/mesa/main/program_resource.c |  14 ++--
> >  src/mesa/main/shader_query.cpp   | 174 +-
> > -
> >  src/mesa/main/shaderapi.c|   2 +-
> >  src/mesa/main/shaderapi.h|   3 +-
> >  src/mesa/main/uniforms.c |   5 +-
> >  5 files changed, 106 insertions(+), 92 deletions(-)
> > 
> > diff --git a/src/mesa/main/program_resource.c 
> > b/src/mesa/main/program_resource.c
> > index 641ef22..fdbd5b3 100644
> > --- a/src/mesa/main/program_resource.c
> > +++ b/src/mesa/main/program_resource.c
> > @@ -229,6 +229,7 @@ _mesa_GetProgramResourceIndex(GLuint program, GLenum 
> > programInterface,
> >const GLchar *name)
> >  {
> > GET_CURRENT_CONTEXT(ctx);
> > +   unsigned array_index = 0;
> > struct gl_program_resource *res;
> > struct gl_shader_program *shProg =
> >_mesa_lookup_shader_program_err(ctx, program,
> > @@ -268,13 +269,10 @@ _mesa_GetProgramResourceIndex(GLuint program, GLenum 
> > programInterface,
> > case GL_PROGRAM_OUTPUT:
> > case GL_UNIFORM:
> > case GL_TRANSFORM_FEEDBACK_VARYING:
> > -  /* Validate name syntax for array variables */
> > -  if (!valid_program_resource_index_name(name))
> > - return GL_INVALID_INDEX;
> > -  /* fall-through */
> > case GL_UNIFORM_BLOCK:
> > -  res = _mesa_program_resource_find_name(shProg, programInterface, 
> > name);
> > -  if (!res)
> > +  res = _mesa_program_resource_find_name(shProg, programInterface, 
> > name,
> > + &array_index);
> > +  if (!res || array_index > 0)
> >   return GL_INVALID_INDEX;
> > 
> >return _mesa_program_resource_index(shProg, res);
> > @@ -403,7 +401,7 @@ _mesa_GetProgramResourceLocation(GLuint program, 
> > GLenum programInterface,
> > struct gl_shader_program *shProg =
> >lookup_linked_program(program, "glGetProgramResourceLocation");
> > 
> > -   if (!shProg || !name || invalid_array_element_syntax(name))
> > +   if (!shProg || !name)
> >return -1;
> > 
> > /* Validate programInterface. */
> > @@ -453,7 +451,7 @@ _mesa_GetProgramResourceLocationIndex(GLuint program, 
> > GLenum programInterface,
> > struct gl_shader_program *shProg =
> >lookup_linked_program(program, 
> > "glGetProgramResourceLocationIndex");
> > 
> > -   if (!shProg || !name || invalid_array_element_syntax(name))
> > +   if (!shProg || !name)
> >return -1;
> > 
> > /* From the GL_ARB_program_interface_query spec:
> > diff --git a/src/mesa/main/shader_query.cpp 
> > b/src/mesa/main/shader_query.cpp
> > index 3e52a09..dd11b81 100644
> > --- a/src/mesa/main/shader_query.cpp
> > +++ b/src/mesa/main/shader_query.cpp
> > @@ -44,7 +44,8 @@ extern "C" {
> > 
> >  static GLint
> >  program_resource_location(struct gl_shader_program *shProg,
> > -  struct gl_program_resource *res, const char 
> > *name);
> > +  struct gl_program_resource *res, const char 
> > *name,
> > +  unsigned array_index);
> > 
> >  /**
> >   * Declare convenience functions to return resource data in a given type.
> > @@ -272,13 +273,15 @@ _mesa_GetAttribLocation(GLhandleARB program, const 
> > GLcharARB * name)
> > if (shProg->_LinkedShaders[MESA_SHADER_VERTEX] == NULL)
> >return -1;
> > 
> > +   unsigned array_index = 0;
> > struct gl_program_resource *res =
> > -  _mesa_program_resource_find_name(shProg, GL_PROGRAM_INPUT, name);
> > +  _mesa_program_resource_find_name(shProg, GL_PROGRAM_INPUT, name,
> > +   &array_index);
> > 
> > if (!res)
> >return -1;
> > 
> > -   GLint loc = program_resource_location(shProg, res, name);
> > +   GLint loc = program_resource_location(shProg, res, name, array_index);
> > 
> > /* The extra check against against 0 is made because of builtin
> > -attribute
> >  * locations that have offset applied. Function 
> > program_resource_loc

[Mesa-dev] [PATCH] mesa: fix type for array indexing validation

[Timothy Arceri]

parse_program_resource_name returns -1 when the index is invalid this needs to
be tested before assigning the value to the unsigned array_index.

In link_varyings.cpp (the other place parse_program_resource_name is used) after
the -1 check is done the value is just assigned to an unsigned variable so it
seems long is just used so we can return the -1 rather than actually expecting
index values to be ridiculously large.

Cc: Matt Turner 
Cc: Tapani Pälli 
---
 src/mesa/main/shader_query.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index b49fd38..a85e4c4 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -506,7 +506,7 @@ _mesa_program_resource_array_size(struct 
gl_program_resource *res)
 static bool
 valid_array_index(const GLchar *name, unsigned *array_index)
 {
-   unsigned idx = 0;
+   long idx = 0;
const GLchar *out_base_name_end;
 
idx = parse_program_resource_name(name, &out_base_name_end);
-- 
2.4.3

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

[Mesa-dev] [PATCH] nir: Use a single bit for the dual-source blend index

[Timothy Arceri]

The only values allowed are 0 and 1, and the value is checked before
assigning.

This is a copy of 8eeca7a56c that seems to have been made to the glsl
ir type after it was copied for use in nir but before nir landed.
---
 src/glsl/nir/nir.h | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index 4551d09..d47f352 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -293,9 +293,13 @@ typedef struct {
   unsigned int driver_location;
 
   /**
-   * output index for dual source blending.
+   * Output index for dual source blending.
+   *
+   * \note
+   * The GLSL spec only allows the values 0 or 1 for the index in \b dual
+   * source blending.
*/
-  int index;
+  unsigned index:1;
 
   /**
* Initial binding point for a sampler or UBO.
-- 
2.4.3

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