[Mesa-dev] [PATCH] i965/fs: Recognize constants can be loaded by subtracting from 1.0.

[Matt Turner]

Some shaders from Synmark contain this loop:

   for (float i = 0.02; i < 0.9; i += 0.11)

and in its body it uses both i and (1.0 - i). All 16 immediates are
promoted to registers (they're used by 3-src MAD instructions). By
recognizing that we can load 8 of these into a single register and then
subtract that from 1.0 to produce the other 8 values, we can load the 16
values in 9 instructions rather than 16:

   total instructions in shared programs: 7121101 -> 7120611 (-0.01%)
   instructions in affected programs: 12915 -> 12425 (-3.79%)
   helped: 70

More importantly, because of the false dependencies between the mov(1)
instructions, instruction scheduling is not able to schedule enough work
after texture operations. With this patch, the mov(1)s and the add(8)
are emitted together and avoid the scheduling problems:

   total cycles in shared programs: 65013218 -> 64895688 (-0.18%)
   cycles in affected programs: 378700 -> 261170 (-31.04%)
   helped: 70

Synmark's OglPSPom improves by 2.42872% +/- 0.158891% (n=120) on a
Haswell GT3e.
---
I've had this in a branch for more than a year now. Might as well send it.

 .../drivers/dri/i965/brw_fs_combine_constants.cpp  | 93 ++
 1 file changed, 93 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_combine_constants.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_combine_constants.cpp
index d7a1456..f272263 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_combine_constants.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_combine_constants.cpp
@@ -133,6 +133,9 @@ struct imm {
 */
bool must_promote;
 
+   /** Whether this constant has been inserted via a different method. */
+   bool inserted;
+
uint16_t first_use_ip;
uint16_t last_use_ip;
 };
@@ -168,6 +171,90 @@ new_imm(struct table *table, void *mem_ctx)
 }
 
 /**
+ * Recognizes when a group of 8 immediates can be loaded by subtracting other
+ * constants we're already loading from 1.0.
+ */
+static void
+try_recognize_1_minus_x(fs_visitor *v, struct table *table)
+{
+   struct {
+  int a_index, b_index;
+  float a_val, b_val;
+
+  bool valid;
+  bool found;
+   } info[table->len] = {0};
+
+   int c = 0;
+   bblock_t *block = NULL;
+
+   for (int i = 0; i < table->len; i++) {
+  /* Skip some values that aren't useful to include this in optimization */
+  if (table->imm[i].val == 0.0f ||
+  table->imm[i].val == 0.5f ||
+  table->imm[i].val == 1.0f)
+ continue;
+
+  for (int j = 0; j < table->len; j++) {
+ if (table->imm[i].val == 1.0f - table->imm[j].val) {
+if (info[j].found)
+   continue;
+
+if (block == NULL)
+   block = table->imm[i].block;
+if (block != table->imm[i].block)
+   continue;
+
+info[i].a_index = i;
+info[i].b_index = j;
+info[i].a_val = table->imm[i].val;
+info[i].b_val = table->imm[j].val;
+info[i].valid = true;
+
+info[i].found = true;
+info[j].found = true;
+c++;
+ }
+  }
+   }
+
+   if (c == 8) {
+  backend_instruction *inst = block->first_non_control_flow_inst();
+  const fs_builder bld = v->bld.at(block, inst).exec_all().group(1, 0);
+
+  fs_reg first(VGRF, v->alloc.allocate(v->dispatch_width / 8));
+  fs_reg second(VGRF, v->alloc.allocate(v->dispatch_width / 8));
+  first.stride = 0;
+
+  for (int i = 0; i < table->len; i++) {
+ if (!info[i].valid)
+continue;
+
+ fs_inst *mov = bld.MOV(first, brw_imm_f(info[i].a_val));
+ mov->no_dd_clear = first.subreg_offset != 28;
+ mov->no_dd_check = first.subreg_offset != 0;
+
+ int a = info[i].a_index;
+ int b = info[i].b_index;
+
+ table->imm[a].inserted = true;
+ table->imm[a].nr = first.nr;
+ table->imm[a].subreg_offset = first.subreg_offset;
+
+ table->imm[b].inserted = true;
+ table->imm[b].nr = second.nr;
+ table->imm[b].subreg_offset = first.subreg_offset;
+
+ first.subreg_offset += sizeof(float);
+  }
+
+  first.stride = 1;
+  first.subreg_offset = 0;
+  bld.group(8, 0).ADD(second, negate(first), brw_imm_f(1.0f));
+   }
+}
+
+/**
  * Comparator used for sorting an array of imm structures.
  *
  * We sort by basic block number, then last use IP, then first use IP (least
@@ -241,6 +328,7 @@ fs_visitor::opt_combine_constants()
 imm->val = val;
 imm->uses_by_coissue = could_coissue(devinfo, inst);
 imm->must_promote = must_promote_imm(devinfo, inst);
+imm->inserted = false;
 imm->first_use_ip = ip;
 imm->last_use_ip = ip;
  }
@@ -267,11 +355,16 @@ fs_visitor::opt_combine_constants()
if (cfg->num_blocks != 1)
   qsort(table.imm, table.len, sizeof(struct imm), compare);
 
+   try_recognize_1_minus_x(this, );
+
/* Insert MOVs to load the 

Re: [Mesa-dev] [PATCH] glsl: Initialize gl_shader_program::EmptyUniformLocations.

[Tapani Pälli]

Reviewed-by: Tapani Palli 

On 02/29/2016 09:12 PM, Matt Turner wrote:

Commit 65dfb30 added exec_list EmptyUniformLocations, but only
initialized the list if ARB_explicit_uniform_location was enabled,
leading to crashes if the extension was not available.

Cc: "11.2" 
---
  src/compiler/glsl/linker.cpp | 1 -
  src/mesa/main/shaderobj.c| 2 ++
  2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 5326bfd..3039232 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -3180,7 +3180,6 @@ check_explicit_uniform_locations(struct gl_context *ctx,
}
 }

-   exec_list_make_empty(>EmptyUniformLocations);
 struct empty_uniform_block *current_block = NULL;

 for (unsigned i = 0; i < prog->NumUniformRemapTable; i++) {
diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 203ccef..9a4eb6b 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -240,6 +240,8 @@ init_shader_program(struct gl_shader_program *prog)

 prog->TransformFeedback.BufferMode = GL_INTERLEAVED_ATTRIBS;

+   exec_list_make_empty(>EmptyUniformLocations);
+
 prog->InfoLog = ralloc_strdup(prog, "");
  }



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

Re: [Mesa-dev] [PATCH v3 0/6] OpenSWR driver addition

[Roland Scheidegger]

Am 01.03.2016 um 00:56 schrieb Rowley, Timothy O:
> 
> On Feb 29, 2016, at 3:47 PM, Roland Scheidegger
> > wrote:
> 
> Am 29.02.2016 um 22:07 schrieb Rowley, Timothy O: Modest ping:
> haven’t had any comments on these patches for a few days. Patches
> look ok to me (for the parts I looked at and commented on).
> 
> I don’t have freedesktop git write privileges, so once the patches 
> are cleared it would be great if someone could push them.
> 
> I don't think that's going to work. A driver needs to be maintained,
> and a complete driver where the maintainer doesn't have commit access
> sounds like a bad idea to me. You should probably apply for git
> access, unless you can find someone else who wants to work on the
> driver…
> 
> I’m willing to be the maintainer, but was trying to follow the path
> usually taken towards commit access: build up a history of patches
> and then ask for access.  I can request early access if you think
> this will help the process.
> 

Yes, that generally makes sense, but you've got a whole driver which you
basically own, so you really ought to be able to commit without having
to ask someone else to do it.
Besides, while you may not have written all that many patches, those
initial patches look like enough LOCs to me ;-).

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

Re: [Mesa-dev] [RFC PATCH] include/GL: add mesa_glinterop.h for OpenGL-OpenCL interop

[Michel Dänzer]

On 01.03.2016 03:11, Marek Olšák wrote:
> From: Marek Olšák 

[...]

> +/**
> + * Device information returned by Mesa.
> + */
> +typedef struct {
> +   uint32_t size; /* size of this structure */
> +
> +   /* PCI location */
> +   uint32_t pci_segment_group;
> +   uint32_t pci_bus;
> +   uint32_t pci_device;
> +   uint32_t pci_function;
> +
> +   /* Device identification */
> +   uint32_t vendor_id;
> +   uint32_t device_id;
> +} mesa_glinterop_device_info;
> +
> +
> +/**
> + * Input parameters to Mesa interop export functions.
> + */
> +typedef struct {
> +   uint32_t size; /* size of this structure */
> +
> +   /* One of the following:
> +* - GL_TEXTURE_BUFFER
> +* - GL_TEXTURE_1D
> +* - GL_TEXTURE_2D
> +* - GL_TEXTURE_3D
> +* - GL_TEXTURE_RECTANGLE
> +* - GL_TEXTURE_1D_ARRAY
> +* - GL_TEXTURE_2D_ARRAY
> +* - GL_TEXTURE_CUBE_MAP_ARRAY
> +* - GL_TEXTURE_CUBE_MAP
> +* - GL_TEXTURE_CUBE_MAP_POSITIVE_X
> +* - GL_TEXTURE_CUBE_MAP_NEGATIVE_X
> +* - GL_TEXTURE_CUBE_MAP_POSITIVE_Y
> +* - GL_TEXTURE_CUBE_MAP_NEGATIVE_Y
> +* - GL_TEXTURE_CUBE_MAP_POSITIVE_Z
> +* - GL_TEXTURE_CUBE_MAP_NEGATIVE_Z
> +* - GL_TEXTURE_2D_MULTISAMPLE
> +* - GL_TEXTURE_2D_MULTISAMPLE_ARRAY
> +* - GL_TEXTURE_EXTERNAL_OES
> +* - GL_RENDERBUFFER
> +* - GL_ARRAY_BUFFER
> +*/
> +   GLenum target;
> +
> +   /* If target is GL_ARRAY_BUFFER, it's a buffer object.
> +* If target is GL_RENDERBUFFER, it's a renderbuffer object.
> +* If target is GL_TEXTURE_*, it's a texture object.
> +*/
> +   GLuint obj;
> +
> +   /* Mipmap level. Ignored for non-texture objects. */
> +   GLuint miplevel;
> +
> +   /* One of MESA_GLINTEROP_ACCESS_* flags. This describes how the exported
> +* object is going to be used.
> +*/
> +   uint32_t access;
> +
> +   /* Size of memory pointed to by out_driver_data. */
> +   uint32_t out_driver_data_size;
> +
> +   /* If the caller wants to query driver-specific data about the OpenGL
> +* object, this should point to the memory where that dta will be stored.

Typo: "dta"


> +*/
> +   void *out_driver_data;
> +} mesa_glinterop_export_in;
> +
> +
> +/**
> + * Outputs of Mesa interop export functions.
> + */
> +typedef struct {
> +   uint32_t size; /* size of this structure */
> +
> +   /* The DMABUF handle. It must closed by the caller using the POSIX close()
> +* function when it's not needed anymore. Mesa is not responsible for
> +* closing the handle.
> +*/
> +   int dmabuf_fd;
> +
> +   /* The mutable OpenGL internal format specified by glTextureView or
> +* glTexBuffer. If the object is not one of those, the original internal
> +* format specified by glTexStorage, glTexImage, or glRenderbufferStorage
> +* will be returned.
> +*/
> +   GLenum internalformat;
> +
> +   /* Parameters specified by glTexBufferRange for GL_TEXTURE_BUFFER. */
> +   GLintptr buf_offset;
> +   GLsizeiptr buf_size;
> +
> +   /* Parameters specified by glTextureView. If the object is not a texture
> +* view, default parameters covering the whole texture will be returned.
> +*/
> +   GLuint view_minlevel;
> +   GLuint view_numlevels;
> +   GLuint view_minlayer;
> +   GLuint view_numlayers;
> +} mesa_glinterop_export_out;
> +
> +
> +/**
> + * Query device information.
> + *
> + * \param dpyGLX display
> + * \param contextGLX context
> + * \param outwhere to return the information
> + *
> + * \return MESA_GLINTEROP_SUCCESS or MESA_GLINTEROP_* != 0 on error
> + */
> +GLAPI int GLAPIENTRY
> +MesaGLInteropGLXQueryDeviceInfo(Display *dpy, GLXContext context,
> +mesa_glinterop_device_info *out);
> +
> +
> +/**
> + * Same as MesaGLInteropGLXQueryDeviceInfo except that it accepts EGLDisplay
> + * and EGLContext.
> + */
> +GLAPI int GLAPIENTRY
> +MesaGLInteropEGLQueryDeviceInfo(EGLDisplay dpy, EGLContext context,
> +mesa_glinterop_device_info *out);
> +
> +
> +/**
> + * Create and return a DMABUF handle corresponding to the given OpenGL
> + * object, and return other parameters about the OpenGL object.
> + *
> + * \param dpyGLX display
> + * \param contextGLX context
> + * \param in input parameters
> + * \param outreturn values
> + *
> + * \return MESA_GLINTEROP_SUCCESS or MESA_GLINTEROP_* != 0 on error
> + */
> +GLAPI int GLAPIENTRY
> +MesaGLInteropGLXExportObject(Display *dpy, GLXContext context,
> + mesa_glinterop_export_in *in,
> + mesa_glinterop_export_out *out);
> +
> +
> +/**
> + * Same as MesaGLInteropGLXExportGLObject except that it accepts
> + * EGLDisplay and EGLContext.
> + */
> +GLAPI int GLAPIENTRY
> +MesaGLInteropEGLExportObject(EGLDisplay dpy, EGLContext context,
> + mesa_glinterop_export_in *in,
> + mesa_glinterop_export_out *out);

The caller doesn't know 

Re: [Mesa-dev] [PATCH 13/15] program: Remove NV_fragment_program opcode parsing.

[Matt Turner]

On Mon, Feb 29, 2016 at 4:29 PM, Ian Romanick  wrote:
> On 02/29/2016 03:34 PM, Matt Turner wrote:
>> ---
>>  src/mesa/program/program_lexer.l  | 8 
>>  src/mesa/program/program_parser.h | 1 -
>>  2 files changed, 9 deletions(-)
>>
>> diff --git a/src/mesa/program/program_lexer.l 
>> b/src/mesa/program/program_lexer.l
>> index 2fcd71f..baaa58a 100644
>> --- a/src/mesa/program/program_lexer.l
>> +++ b/src/mesa/program/program_lexer.l
>> @@ -32,7 +32,6 @@
>>
>>  #define require_ARB_vp (yyextra->mode == ARB_vertex)
>>  #define require_ARB_fp (yyextra->mode == ARB_fragment)
>> -#define require_NV_fp  (yyextra->option.NV_fragment)
>>  #define require_shadow (yyextra->option.Shadow)
>>  #define require_rect   (yyextra->option.TexRect)
>>  #define require_texarray(yyextra->option.TexArray)
>> @@ -191,8 +190,6 @@ ARL{ return_opcode(require_ARB_vp, ARL, 
>> ARL, 3); }
>>  CMP{sat}   { return_opcode(require_ARB_fp, TRI_OP, CMP, 3); }
>>  COS{szf}{cc}{sat}  { return_opcode(require_ARB_fp, SCALAR_OP, COS, 3); }
>
> I think all of the {cc} business can go too.  I think that's for parsing
> the condition codes that you remove in patch 6.

Oh, good call. I'll strip out the sz/szf/cc stuff and squash it into patch 6.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 94344] Requesting git commit access to mesa

[bugzilla-daemon]

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

--- Comment #1 from Tim Rowley  ---
Created attachment 122049
  --> https://bugs.freedesktop.org/attachment.cgi?id=122049=edit
gpg public key

-- 
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 94344] Requesting git commit access to mesa

[bugzilla-daemon]

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

Bug ID: 94344
   Summary: Requesting git commit access to mesa
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: timothy.o.row...@intel.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 122048
  --> https://bugs.freedesktop.org/attachment.cgi?id=122048=edit
ssh public key

Hi.  I'm in the process of submitting a new driver OpenSWR to Mesa.  On
mesa-dev it was suggested that I should request commit access to maintain the
driver, even though I don't have the traditional patch history one acquires
before asking.

Name: Tim Rowley
Email: timothy.o.row...@intel.com
Preferred account name: tor

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

Re: [Mesa-dev] [PATCH 2/5] i965: Add support for swizzling arbitrary immediates to (brw_)swizzle().

[Francisco Jerez]

Iago Toral  writes:

> On Fri, 2016-02-26 at 22:02 -0800, Francisco Jerez wrote:
>> Scalar immediates used to be handled correctly by swizzle() (as the
>> identity) but since commit 58fa9d47b536403c4e3ca5d6a2495691338388fd it
>> will corrupt the contents of the immediate.  Vector immediates were
>> never handled correctly, but we had ad-hoc code to swizzle VF
>> immediates in the vec4 copy propagation pass.  This takes care of
>> swizzling V and UV in addition.
>> ---
>>  src/mesa/drivers/dri/i965/brw_eu.c  | 39 
>> +
>>  src/mesa/drivers/dri/i965/brw_ir_vec4.h |  6 -
>>  src/mesa/drivers/dri/i965/brw_reg.h |  7 --
>>  3 files changed, 49 insertions(+), 3 deletions(-)
>> 
>> diff --git a/src/mesa/drivers/dri/i965/brw_eu.c 
>> b/src/mesa/drivers/dri/i965/brw_eu.c
>> index 40ec87d..36bdc7c 100644
>> --- a/src/mesa/drivers/dri/i965/brw_eu.c
>> +++ b/src/mesa/drivers/dri/i965/brw_eu.c
>> @@ -110,6 +110,45 @@ brw_swap_cmod(uint32_t cmod)
>> }
>>  }
>>  
>> +/**
>> + * Get the least significant bit offset of the i+1-th component of immediate
>> + * type \p type.  For \p i equal to the two's complement of j, return the
>> + * offset of the j-th component starting from the end of the vector.  For
>> + * scalar register types return zero.
>> + */
>> +static unsigned
>> +imm_shift(enum brw_reg_type type, unsigned i)
>> +{
>> +   if (type == BRW_REGISTER_TYPE_VF)
>> +  return 8 * (i & 3);
>> +   else if (type == BRW_REGISTER_TYPE_UV || type == BRW_REGISTER_TYPE_V)
>> +  return 4 * (i & 7);
>> +   else
>> +  return 0;
>> +}
>> +
>> +/**
>> + * Swizzle an arbitrary immediate \p x of the given type according to the
>> + * permutation specified as \p swz.
>> + */
>> +uint32_t
>> +brw_swizzle_immediate(enum brw_reg_type type, uint32_t x, unsigned swz)
>> +{
>> +   if (imm_shift(type, 1)) {
>> +  const unsigned n = 32 / imm_shift(type, 1);
>
> You can assign imm_shift(type, 1) to a variable before the if and reuse
> it here.
>

Heh, I did that mainly out of laziness because it was less noise than
declaring a new variable.  It shouldn't make any practical difference
-- Or was your suggestion on purely stylistic grounds?

>> +  uint32_t y = 0;
>> +
>> +  for (unsigned i = 0; i < n; i++)
>> + y |= x >> imm_shift(type, (i & ~3) + BRW_GET_SWZ(swz, i & 3))
>> +<< imm_shift(type, ~0u)
>> +>> imm_shift(type, ~0u - i);
>> +
>
> Ugh, took me a while to understand what this was doing even with the
> comment in imm_shift(). Another comment here explaining what this series
> of operations are doing might save future readers some time... ;)
>
Sure, I'll throw in some more comments.

> The implementation looks correct to me:
> Reviewed-by: Iago Toral Quiroga 
>
Thanks.

>> +  return y;
>> +   } else {
>> +  return x;
>> +   }
>> +}
>> +
>>  void
>>  brw_set_default_exec_size(struct brw_codegen *p, unsigned value)
>>  {
>> diff --git a/src/mesa/drivers/dri/i965/brw_ir_vec4.h 
>> b/src/mesa/drivers/dri/i965/brw_ir_vec4.h
>> index 660beca..2b6872e 100644
>> --- a/src/mesa/drivers/dri/i965/brw_ir_vec4.h
>> +++ b/src/mesa/drivers/dri/i965/brw_ir_vec4.h
>> @@ -76,7 +76,11 @@ offset(src_reg reg, unsigned delta)
>>  static inline src_reg
>>  swizzle(src_reg reg, unsigned swizzle)
>>  {
>> -   reg.swizzle = brw_compose_swizzle(swizzle, reg.swizzle);
>> +   if (reg.file == IMM)
>> +  reg.ud = brw_swizzle_immediate(reg.type, reg.ud, swizzle);
>> +   else
>> +  reg.swizzle = brw_compose_swizzle(swizzle, reg.swizzle);
>> +
>> return reg;
>>  }
>>  
>> diff --git a/src/mesa/drivers/dri/i965/brw_reg.h 
>> b/src/mesa/drivers/dri/i965/brw_reg.h
>> index a4bcfca..74ff67f 100644
>> --- a/src/mesa/drivers/dri/i965/brw_reg.h
>> +++ b/src/mesa/drivers/dri/i965/brw_reg.h
>> @@ -223,6 +223,7 @@ enum PACKED brw_reg_type {
>>  unsigned brw_reg_type_to_hw_type(const struct brw_device_info *devinfo,
>>   enum brw_reg_type type, enum brw_reg_file 
>> file);
>>  const char *brw_reg_type_letters(unsigned brw_reg_type);
>> +uint32_t brw_swizzle_immediate(enum brw_reg_type type, uint32_t x, unsigned 
>> swz);
>>  
>>  #define REG_SIZE (8*4)
>>  
>> @@ -876,9 +877,11 @@ get_element_d(struct brw_reg reg, unsigned elt)
>>  static inline struct brw_reg
>>  brw_swizzle(struct brw_reg reg, unsigned swz)
>>  {
>> -   assert(reg.file != BRW_IMMEDIATE_VALUE);
>> +   if (reg.file == BRW_IMMEDIATE_VALUE)
>> +  reg.ud = brw_swizzle_immediate(reg.type, reg.ud, swz);
>> +   else
>> +  reg.swizzle = brw_compose_swizzle(swz, reg.swizzle);
>>  
>> -   reg.swizzle = brw_compose_swizzle(swz, reg.swizzle);
>> return reg;
>>  }
>>  


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

Re: [Mesa-dev] [PATCH 4/5] i965: Don't try copy propagation if constant propagation succeeded.

[Francisco Jerez]

Matt Turner  writes:

>> i965: Don't try copy propagation if constant propagation succeeded.
>>
>> It cannot get any better.
>
> That's not obvious to me. How do we know that?

Because it's impossible to copy-propagate anything into a source that's
already an immediate. ;)


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

Re: [Mesa-dev] [PATCH] i965: set VIEWPORT_BOUNDS_RANGE value depending of the supported OpenGL version

[Kenneth Graunke]

On Friday, February 26, 2016 8:37:33 AM PST Samuel Iglesias Gonsálvez wrote:
> From ARB_viewport_array spec:
> 
> " * On GL3-capable hardware the VIEWPORT_BOUNDS_RANGE should be at least
> [-16384, 16383].
>   * On GL4-capable hardware the VIEWPORT_BOUNDS_RANGE should be at least
> [-32768, 32767]."
> 
> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
>  src/mesa/drivers/dri/i965/brw_context.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/
i965/brw_context.c
> index 31b6b2a..1569992 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -687,10 +687,15 @@ brw_initialize_context_constants(struct brw_context 
*brw)
>ctx->Const.MaxViewports = GEN6_NUM_VIEWPORTS;
>ctx->Const.ViewportSubpixelBits = 0;
>  
> -  /* Cast to float before negating because MaxViewportWidth is 
unsigned.
> -   */
> -  ctx->Const.ViewportBounds.Min = -(float)ctx->Const.MaxViewportWidth;
> -  ctx->Const.ViewportBounds.Max = ctx->Const.MaxViewportWidth;
> +  if (brw->intelScreen->driScrnPriv->max_gl_core_version >= 40) {
> + ctx->Const.ViewportBounds.Min = -32768;
> + ctx->Const.ViewportBounds.Max = 32767;
> +  } else {
> + /* Cast to float before negating because MaxViewportWidth is 
unsigned.
> +  */
> + ctx->Const.ViewportBounds.Min = -(float)ctx-
>Const.MaxViewportWidth;
> + ctx->Const.ViewportBounds.Max = ctx->Const.MaxViewportWidth;
> +  }
> }
>  
> /* ARB_gpu_shader5 */
> 

Shouldn't we just support a 32k x 32k viewport?  In other words, change
MaxViewportWidth/MaxViewportHeight?

--Ken


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/15] program: Remove remnants of NV_fragment_program and other cruft

[Ian Romanick]

On 02/29/2016 03:34 PM, Matt Turner wrote:
> We removed NV_vertex_program and NV_fragment_program{,_option} in 2012 yet we
> continue finding more pieces of them years later. Last year we discussed
> removing some remaining bits of NV_fragment_program_option that were used by
> a broken Viewperf11 test [1]. Hopefully it's been long enough and we can strip
> out the rest of the condition code support from Mesa IR.
> 
> If not... then I guess I can try to rebase that out of the series. I hope it
> doesn't come to that. I'd really like to replace Mesa IR with NIR. idr
> suggested a alternate plan that's making more and more sense to me though: 
> push
> Mesa IR down to just something i915 and r200 consume or get rid of it 
> entirely.
> 
> That would require 1) a NIR -> Mesa IR translator (for i915 and r200)
>2) changing the program parser to generate NIR
>3) ...?

We've discussed a couple times that it may be useful to have Mesa
support the various NV assembly extensions.  There are a bunch of
applications that use Cg to generate assembly.  If you don't support the
magic NV extensions, you don't get the nice eye candy... or you do, but
you get it with rubbish code.

I think the sensible way to get to that future is to remove the existing
support (as this series does), convert to NIR, then gradually add
support back.  There's a LOT of stuff that would be done differently.
Not having any of that in the way will make a transition to NIR easier
to implement and easier to verify.

This series is

Reviewed-by: Ian Romanick 

I sent a comment on patch 13, and you'll probably end up with another
patch. :)

> And with Rob's work to bring NIR to Gallium (and probably some more), we can
> probably cut out Mesa IR -> TGSI as well.
> 
> [1] https://lists.freedesktop.org/archives/mesa-dev/2015-February/077015.html
> 
> ___
> 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 13/15] program: Remove NV_fragment_program opcode parsing.

[Ian Romanick]

On 02/29/2016 03:34 PM, Matt Turner wrote:
> ---
>  src/mesa/program/program_lexer.l  | 8 
>  src/mesa/program/program_parser.h | 1 -
>  2 files changed, 9 deletions(-)
> 
> diff --git a/src/mesa/program/program_lexer.l 
> b/src/mesa/program/program_lexer.l
> index 2fcd71f..baaa58a 100644
> --- a/src/mesa/program/program_lexer.l
> +++ b/src/mesa/program/program_lexer.l
> @@ -32,7 +32,6 @@
>  
>  #define require_ARB_vp (yyextra->mode == ARB_vertex)
>  #define require_ARB_fp (yyextra->mode == ARB_fragment)
> -#define require_NV_fp  (yyextra->option.NV_fragment)
>  #define require_shadow (yyextra->option.Shadow)
>  #define require_rect   (yyextra->option.TexRect)
>  #define require_texarray(yyextra->option.TexArray)
> @@ -191,8 +190,6 @@ ARL{ return_opcode(require_ARB_vp, ARL, 
> ARL, 3); }
>  CMP{sat}   { return_opcode(require_ARB_fp, TRI_OP, CMP, 3); }
>  COS{szf}{cc}{sat}  { return_opcode(require_ARB_fp, SCALAR_OP, COS, 3); }

I think all of the {cc} business can go too.  I think that's for parsing
the condition codes that you remove in patch 6.

> -DDX{szf}{cc}{sat}  { return_opcode(require_NV_fp,  VECTOR_OP, DDX, 3); }
> -DDY{szf}{cc}{sat}  { return_opcode(require_NV_fp,  VECTOR_OP, DDY, 3); }
>  DP3{sz}{cc}{sat}   { return_opcode( 1, BIN_OP, DP3, 3); }
>  DP4{sz}{cc}{sat}   { return_opcode( 1, BIN_OP, DP4, 3); }
>  DPH{sz}{cc}{sat}   { return_opcode( 1, BIN_OP, DPH, 3); }
> @@ -223,19 +220,14 @@ RCP{szf}{cc}{sat}  { return_opcode( 1, 
> SCALAR_OP, RCP, 3); }
>  RSQ{szf}{cc}{sat}  { return_opcode( 1, SCALAR_OP, RSQ, 3); }
>  
>  SCS{sat}   { return_opcode(require_ARB_fp, SCALAR_OP, SCS, 3); }
> -SEQ{sz}{cc}{sat}   { return_opcode(require_NV_fp,  BIN_OP, SEQ, 3); }
>  SGE{sz}{cc}{sat}   { return_opcode( 1, BIN_OP, SGE, 3); }
> -SGT{sz}{cc}{sat}   { return_opcode(require_NV_fp,  BIN_OP, SGT, 3); }
>  SIN{szf}{cc}{sat}  { return_opcode(require_ARB_fp, SCALAR_OP, SIN, 3); }
> -SLE{sz}{cc}{sat}   { return_opcode(require_NV_fp,  BIN_OP, SLE, 3); }
>  SLT{sz}{cc}{sat}   { return_opcode( 1, BIN_OP, SLT, 3); }
> -SNE{sz}{cc}{sat}   { return_opcode(require_NV_fp,  BIN_OP, SNE, 3); }
>  SUB{sz}{cc}{sat}   { return_opcode( 1, BIN_OP, SUB, 3); }
>  SWZ{sat}   { return_opcode( 1, SWZ, SWZ, 3); }
>  
>  TEX{cc}{sat}   { return_opcode(require_ARB_fp, SAMPLE_OP, TEX, 3); }
>  TXB{cc}{sat}   { return_opcode(require_ARB_fp, SAMPLE_OP, TXB, 3); }
> -TXD{cc}{sat}   { return_opcode(require_NV_fp,  TXD_OP, TXD, 3); }
>  TXP{cc}{sat}   { return_opcode(require_ARB_fp, SAMPLE_OP, TXP, 3); }
>  
>  XPD{sat}   { return_opcode( 1, BIN_OP, XPD, 3); }
> diff --git a/src/mesa/program/program_parser.h 
> b/src/mesa/program/program_parser.h
> index d5a1e22..af7b2a0 100644
> --- a/src/mesa/program/program_parser.h
> +++ b/src/mesa/program/program_parser.h
> @@ -207,7 +207,6 @@ struct asm_parser_state {
>unsigned Shadow:1;
>unsigned TexRect:1;
>unsigned TexArray:1;
> -  unsigned NV_fragment:1;
>unsigned OriginUpperLeft:1;
>unsigned PixelCenterInteger:1;
> } option;
> 

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

Re: [Mesa-dev] [PATCH 3/5] i965/vec4: Use swizzle() to swizzle immediates during constant propagation.

[Francisco Jerez]

Matt Turner  writes:

> On Mon, Feb 29, 2016 at 2:20 PM, Francisco Jerez  
> wrote:
>> Matt Turner  writes:
>>
>>> On Mon, Feb 29, 2016 at 7:30 AM, Iago Toral  wrote:
 On Fri, 2016-02-26 at 22:02 -0800, Francisco Jerez wrote:
> swizzle() works for vector immediates other than VF.
> ---
>  .../drivers/dri/i965/brw_vec4_copy_propagation.cpp| 19 
> +--
>  1 file changed, 1 insertion(+), 18 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> index 6bd9928..5c25164 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> @@ -76,22 +76,6 @@ is_channel_updated(vec4_instruction *inst, src_reg 
> *values[4], int ch)
> inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch)));
>  }
>
> -static unsigned
> -swizzle_vf_imm(unsigned vf4, unsigned swizzle)
> -{
> -   union {
> -  unsigned vf4;
> -  uint8_t vf[4];
> -   } v = { vf4 }, ret;
> -
> -   ret.vf[0] = v.vf[BRW_GET_SWZ(swizzle, 0)];
> -   ret.vf[1] = v.vf[BRW_GET_SWZ(swizzle, 1)];
> -   ret.vf[2] = v.vf[BRW_GET_SWZ(swizzle, 2)];
> -   ret.vf[3] = v.vf[BRW_GET_SWZ(swizzle, 3)];
> -
> -   return ret.vf4;
> -}
> -
>  static bool
>  is_logic_op(enum opcode opcode)
>  {
> @@ -144,8 +128,7 @@ try_constant_propagate(const struct brw_device_info 
> *devinfo,
>}
> }
>
> -   if (value.type == BRW_REGISTER_TYPE_VF)
> -  value.ud = swizzle_vf_imm(value.ud, inst->src[arg].swizzle);
> +   value = swizzle(value, inst->src[arg].swizzle);

 so I guess V/UV was broken before this?
>>>
>>> My question is in the same vein -- what does swizzling V/UV even mean?
>>> Swizzles operate on 4-component things, but V/UV have 8 components.
>>>
>> swizzle() operates on 8-component things 99% of the time.  Its semantics
>> are determined by the equivalence of:
>
> Swizzle operates on vec4s. The fact that SIMD8 instructions operate on
> 2x vec4s doesn't matter as far as I can tell.
>
> This seems analogous to SSE instructions that operate on the top and
> bottom halves of a 128-bit register independently. Yes, the
> instruction operates on 128-bits, but the operation treats the halves
> completely independently.
>
> But all of this is beside the point. I really can't believe we have
> these sorts of disagreements.
>
The defining property of swizzle() that I pointed out in my last e-mail
doesn't impose any restriction on how many components the argument has
(and it's in practice hardly ever a vec4).  This patch simply makes the
implementation of swizzle() match its defining property for all inputs.

Where's the disagreement?  Do you disagree with its defining property?
With the hardware's extension of swizzles to vecN?  Or do you disagree
with this specific implementation of the definition?

>>
>>  OP ..., swizzle(x, swz)
>>
>> to:
>>
>>  MOV tmp, x
>>  OP ..., tmp.swz
>>
>> where the MOV has the same execution type and width as the arbitrary
>> instruction OP.  With this in mind there are no restrictions on what x
>> can be, as long as it can be read from, you just do what the hardware
>> does.
>>
>>> Concretely, for an immediate of 0x1234567UV, what does applying a
>>> swizzle of .yxzw do? Does it swap two dwords (each containing two
>>> values) and produce 0x34125678UV? Or does it operate on both halves
>>> individually and produce 0x21346578UV?
>>>
>> At the hardware level a swizzle specifies a permutation of 4 which is
>> cyclically extended to whatever the vector width is.  So assuming your
>> immediate is 0x01234567UV the correct answer is 0x01324576UV.
>
> Sorry, right. I meant 0x01234567UV.
>
>>
>>> Moreover, using one of these immediate types requires a W destination,
>>
>> I don't think that's right.
>
> The IVB PRM (3.3.4 Immediate) says
>
>
> Restriction: When an immediate vector is used in an instruction, the
> destination must be 128-bit aligned with destination horizontal stride
> equivalent to a word for an immediate integer vector (v) and
> equivalent to a dword for an immediate float vector (vf).
>
> So you could use a byte destination with a stride of 2. But my point
> is that you can't use them with a destination type of D/UD.
>
Yeah, I had seen a similar comment in the BSpec, but I suspect the text
is outdated.  There are restrictions on where you can use integer vector
immediates but I believe they relate mainly to the execution data type
of the instruction, which the destination datatype and alignment doesn't
necessarily have an influence on.  Anyway it looks like there are cases
where one could legitimately use V in Align16 mode, let's discuss more
about the restrictions of 

[Mesa-dev] [PATCH] Support unlimited number of display connections

[George Kyriazis]

There is a limit of 10 display connections, which was a
problem for apps/tests that were continuously opening/closing display
connections.

This fix uses XAddExtension() and XESetCloseDisplay() to keep track
of the status of the display connections from the X server, freeing
mesa-related data as X displays get destroyed by the X server.

Poster child is the VTK "TimingTests"

---
 src/gallium/state_trackers/glx/xlib/xm_api.c | 121 ++-
 1 file changed, 102 insertions(+), 19 deletions(-)

diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c 
b/src/gallium/state_trackers/glx/xlib/xm_api.c
index 2f5e1f5..2130f90 100644
--- a/src/gallium/state_trackers/glx/xlib/xm_api.c
+++ b/src/gallium/state_trackers/glx/xlib/xm_api.c
@@ -110,14 +110,6 @@ void xmesa_set_driver( const struct xm_driver *templ )
 }
 
 
-/*
- * XXX replace this with a linked list, or better yet, try to attach the
- * gallium/mesa extra bits to the X Display object with XAddExtension().
- */
-#define MAX_DISPLAYS 10
-static struct xmesa_display Displays[MAX_DISPLAYS];
-static int NumDisplays = 0;
-
 static int
 xmesa_get_param(struct st_manager *smapi,
 enum st_manager_param param)
@@ -130,31 +122,121 @@ xmesa_get_param(struct st_manager *smapi,
}
 }
 
+/* linked list of XMesaDisplay hooks per display */
+typedef struct _XMesaExtDisplayInfo {
+   struct _XMesaExtDisplayInfo *next;
+   Display *display;
+   XExtCodes *codes;
+   struct xmesa_display mesaDisplay;
+} XMesaExtDisplayInfo;
+
+typedef struct _XMesaExtInfo {
+   XMesaExtDisplayInfo *head;
+   int ndisplays;
+} XMesaExtInfo;
+
+static XMesaExtInfo MesaExtInfo;
+
+/* hook to delete XMesaDisplay on XDestroyDisplay */
+static int
+xmesa_close_display(Display *display, XExtCodes *codes)
+{
+   XMesaExtDisplayInfo *info, *prev;
+
+   assert(MesaExtInfo.ndisplays > 0);
+   assert(MesaExtInfo.head);
+
+   _XLockMutex(_Xglobal_lock);
+   /* first find display */
+   prev = NULL;
+   for (info = MesaExtInfo.head; info; info = info->next) {
+  if (info->display == display) {
+ prev = info;
+ break;
+  }
+   }
+
+   if (info == NULL) {
+  /* no display found */
+  _XUnlockMutex(_Xglobal_lock);
+  return 0;
+   }
+
+   /* remove display entry from list */
+   if (prev != MesaExtInfo.head) {
+  prev->next = info->next;
+   } else {
+  MesaExtInfo.head = info->next;
+   }
+   MesaExtInfo.ndisplays--;
+
+   _XUnlockMutex(_Xglobal_lock);
+
+   /* don't forget to clean up mesaDisplay */
+   XMesaDisplay xmdpy = >mesaDisplay;
+
+   if (xmdpy->screen) {
+  xmdpy->screen->destroy(xmdpy->screen);
+   }
+   free(xmdpy->smapi);
+
+   XFree((char *) info);
+   return 1;
+}
+
 static XMesaDisplay
 xmesa_init_display( Display *display )
 {
pipe_static_mutex(init_mutex);
XMesaDisplay xmdpy;
-   int i;
+   XMesaExtDisplayInfo *info;
+
+   if (display == NULL) {
+  return NULL;
+   }
 
pipe_mutex_lock(init_mutex);
 
-   /* Look for XMesaDisplay which corresponds to 'display' */
-   for (i = 0; i < NumDisplays; i++) {
-  if (Displays[i].display == display) {
+   /* Look for XMesaDisplay which corresponds to this display */
+   info = MesaExtInfo.head;
+   while(info) {
+  if (info->display == display) {
  /* Found it */
  pipe_mutex_unlock(init_mutex);
- return [i];
+ return  >mesaDisplay;
   }
+  info = info->next;
}
 
-   /* Create new XMesaDisplay */
+   /* Not found.  Create new XMesaDisplay */
+   /* first allocate X-related resources and hook destroy callback */
 
-   assert(NumDisplays < MAX_DISPLAYS);
-   xmdpy = [NumDisplays];
-   NumDisplays++;
-
-   if (!xmdpy->display && display) {
+   /* allocate mesa display info */
+   info = (XMesaExtDisplayInfo *) Xmalloc(sizeof(XMesaExtDisplayInfo));
+   if (info == NULL) {
+  pipe_mutex_unlock(init_mutex);
+  return NULL;
+   }
+   info->display = display;
+   info->codes = XAddExtension(display);
+   if (info->codes == NULL) {
+  /* could not allocate extension.  Fail */
+  Xfree(info);
+  pipe_mutex_unlock(init_mutex);
+  return NULL;
+   }
+   XESetCloseDisplay(display, info->codes->extension, xmesa_close_display);
+   xmdpy = >mesaDisplay; /* to be filled out below */
+
+   /* chain to the list of displays */
+   _XLockMutex(_Xglobal_lock);
+   info->next = MesaExtInfo.head;
+   MesaExtInfo.head = info;
+   MesaExtInfo.ndisplays++;
+   _XUnlockMutex(_Xglobal_lock);
+
+   /* now create the new XMesaDisplay info */
+   if (display) {
   xmdpy->display = display;
   xmdpy->screen = driver.create_pipe_screen(display);
   xmdpy->smapi = CALLOC_STRUCT(st_manager);
@@ -185,6 +267,7 @@ xmesa_init_display( Display *display )
return xmdpy;
 }
 
+
 /**/
 /* X Utility Functions*/
 /**/
-- 

Re: [Mesa-dev] [PATCH v3 0/6] OpenSWR driver addition

[Kenneth Graunke]

On Monday, February 29, 2016 11:56:29 PM PST Rowley, Timothy O wrote:
> 
> On Feb 29, 2016, at 3:47 PM, Roland Scheidegger 
> wrote:
> 
> Am 29.02.2016 um 22:07 schrieb Rowley, Timothy O:
> Modest ping: haven’t had any comments on these patches for a few
> days.
> Patches look ok to me (for the parts I looked at and commented on).
> 
> I don’t have freedesktop git write privileges, so once the patches
> are cleared it would be great if someone could push them.
> 
> I don't think that's going to work. A driver needs to be maintained, and
> a complete driver where the maintainer doesn't have commit access sounds
> like a bad idea to me. You should probably apply for git access, unless
> you can find someone else who wants to work on the driver…
> 
> I’m willing to be the maintainer, but was trying to follow the path usually 
taken towards commit access: build up a history of patches and then ask for 
access.  I can request early access if you think this will help the process.
> 
> -Tim

Hi Tim,

Please apply for a freedesktop.org account as documented here:
https://www.freedesktop.org/wiki/AccountRequests/

and mention that you'd like commit access for the Mesa project,
as you're going to maintain the new OpenSWR driver.

If you're contributing a driver, you ought to be able to commit to it :)

--Ken


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/15] program: Remove remnants of NV_fragment_program and other cruft

[Kenneth Graunke]

On Monday, February 29, 2016 3:34:34 PM PST Matt Turner wrote:
> We removed NV_vertex_program and NV_fragment_program{,_option} in 2012 yet 
we
> continue finding more pieces of them years later. Last year we discussed
> removing some remaining bits of NV_fragment_program_option that were used by
> a broken Viewperf11 test [1]. Hopefully it's been long enough and we can 
strip
> out the rest of the condition code support from Mesa IR.
> 
> If not... then I guess I can try to rebase that out of the series. I hope it
> doesn't come to that. I'd really like to replace Mesa IR with NIR. idr
> suggested a alternate plan that's making more and more sense to me though: 
push
> Mesa IR down to just something i915 and r200 consume or get rid of it 
entirely.
> 
> That would require 1) a NIR -> Mesa IR translator (for i915 and r200)
>2) changing the program parser to generate NIR
>3) ...?
> 
> And with Rob's work to bring NIR to Gallium (and probably some more), we can
> probably cut out Mesa IR -> TGSI as well.
> 
> 
> [1] https://lists.freedesktop.org/archives/mesa-dev/2015-February/
077015.html

Series is:
Reviewed-by: Kenneth Graunke 

I think that you should get an Ack from Brian or Roland, though.


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Push most TES inputs in vec4 mode.

[Matt Turner]

On Wed, Feb 17, 2016 at 3:05 PM, Kenneth Graunke  wrote:
> (This is commit 4a1c8a3037cd29938b2a6e2c680c341e9903cfbe for vec4 mode.)
>
> Using the push model for inputs is much more efficient than pulling
> inputs - the hardware can simply copy a large chunk into URB registers
> at thread creation time, rather than having the thread send messages to
> request data from the L3 cache.  Unfortunately, it's possible to have
> more TES inputs than fit in registers, so we have to fall back to the
> pull model in some cases.
>
> However, it turns out that most tessellation evaluation shaders are
> fairly simple, and don't use many inputs.  An arbitrary cut-off of
> 24 vec4 slots (12 registers) should suffice.  (I chose this instead of
> the 32 vec4 slots used in the scalar backend to avoid regressing a few
> Piglit tests due to the vec4 register allocator being too stupid to
> figure out what to do.  We probably ought to fix that, but it's a
> separate issue.)
>
> Improves performance in GPUTest's tessmark_x64 microbenchmark by
> 41.5394% +/- 0.288519% (n = 115) at 1024x768 on my Clevo W740SU
> (with Iris Pro 5200).
>
> Improves performance in Synmark's Gl40TerrainFlyTess microbenchmark by
> 38.3576% +/- 0.759748% (n = 42).
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_vec4_nir.cpp |  4 +-
>  src/mesa/drivers/dri/i965/brw_vec4_tes.cpp | 86 
> +++---
>  2 files changed, 56 insertions(+), 34 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> index 74ec4f0..9b721e5 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> @@ -685,9 +685,7 @@ vec4_visitor::nir_emit_intrinsic(nir_intrinsic_instr 
> *instr)
> case nir_intrinsic_load_instance_id:
> case nir_intrinsic_load_base_instance:
> case nir_intrinsic_load_draw_id:
> -   case nir_intrinsic_load_invocation_id:
> -   case nir_intrinsic_load_tess_level_inner:
> -   case nir_intrinsic_load_tess_level_outer: {
> +   case nir_intrinsic_load_invocation_id: {
>gl_system_value sv = nir_system_value_from_intrinsic(instr->intrinsic);
>src_reg val = src_reg(nir_system_values[sv]);
>assert(val.file != BAD_FILE);
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp
> index ce5fefc..90cbd2b8 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_tes.cpp
> @@ -28,6 +28,7 @@
>   */
>
>  #include "brw_vec4_tes.h"
> +#include "brw_cfg.h"
>
>  namespace brw {
>
> @@ -53,39 +54,10 @@ vec4_tes_visitor::make_reg_for_system_value(int location, 
> const glsl_type *type)
>  void
>  vec4_tes_visitor::nir_setup_system_value_intrinsic(nir_intrinsic_instr 
> *instr)
>  {
> -   const struct brw_tes_prog_data *tes_prog_data =
> -  (const struct brw_tes_prog_data *) prog_data;
> -
> switch (instr->intrinsic) {
> -   case nir_intrinsic_load_tess_level_outer: {
> -  dst_reg dst(this, glsl_type::vec4_type);
> -  nir_system_values[SYSTEM_VALUE_TESS_LEVEL_OUTER] = dst;
> -
> -  dst_reg temp(this, glsl_type::vec4_type);
> -  vec4_instruction *read =
> - emit(VEC4_OPCODE_URB_READ, temp, input_read_header);
> -  read->offset = 1;
> -  read->urb_write_flags = BRW_URB_WRITE_PER_SLOT_OFFSET;
> -  emit(MOV(dst, swizzle(src_reg(temp), BRW_SWIZZLE_WZYX)));
> +   case nir_intrinsic_load_tess_level_outer:
> +   case nir_intrinsic_load_tess_level_inner:
>break;
> -   }
> -   case nir_intrinsic_load_tess_level_inner: {
> -  dst_reg dst(this, glsl_type::vec2_type);
> -  nir_system_values[SYSTEM_VALUE_TESS_LEVEL_INNER] = dst;
> -
> -  /* Set up the message header to reference the proper parts of the URB 
> */
> -  dst_reg temp(this, glsl_type::vec4_type);
> -  vec4_instruction *read =
> - emit(VEC4_OPCODE_URB_READ, temp, input_read_header);
> -  read->urb_write_flags = BRW_URB_WRITE_PER_SLOT_OFFSET;
> -  if (tes_prog_data->domain == BRW_TESS_DOMAIN_QUAD) {
> - emit(MOV(dst, swizzle(src_reg(temp), BRW_SWIZZLE_WZYX)));
> -  } else {
> - read->offset = 1;
> - emit(MOV(dst, src_reg(temp)));
> -  }
> -  break;
> -   }
> default:
>vec4_visitor::nir_setup_system_value_intrinsic(instr);
> }
> @@ -105,6 +77,27 @@ vec4_tes_visitor::setup_payload()
>
> reg = setup_uniforms(reg);
>
> +   foreach_block_and_inst(block, vec4_instruction, inst, cfg) {
> +  for (int i = 0; i < 3; i++) {
> + if (inst->src[i].file != ATTR)
> +continue;
> +
> + struct brw_reg grf =
> +brw_vec4_grf(reg + inst->src[i].nr / 2, 4 * (inst->src[i].nr % 
> 2));
> + grf = stride(grf, 0, 4, 1);
> + grf.swizzle = inst->src[i].swizzle;
> + grf.type = inst->src[i].type;
> + if (inst->src[i].abs)

Re: [Mesa-dev] [PATCH v3 0/6] OpenSWR driver addition

[Rowley, Timothy O]

On Feb 29, 2016, at 3:47 PM, Roland Scheidegger 
> wrote:

Am 29.02.2016 um 22:07 schrieb Rowley, Timothy O:
Modest ping: haven’t had any comments on these patches for a few
days.
Patches look ok to me (for the parts I looked at and commented on).

I don’t have freedesktop git write privileges, so once the patches
are cleared it would be great if someone could push them.

I don't think that's going to work. A driver needs to be maintained, and
a complete driver where the maintainer doesn't have commit access sounds
like a bad idea to me. You should probably apply for git access, unless
you can find someone else who wants to work on the driver…

I’m willing to be the maintainer, but was trying to follow the path usually 
taken towards commit access: build up a history of patches and then ask for 
access.  I can request early access if you think this will help the process.

-Tim

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

Re: [Mesa-dev] [PATCH 01/26] docs: git tips

[Kenneth Graunke]

On Monday, February 29, 2016 11:13:44 AM PST Matt Turner wrote:
> On Mon, Feb 29, 2016 at 8:13 AM, Emil Velikov  
wrote:
> > On 29 February 2016 at 01:17, Timothy Arceri
> >  wrote:
> >> From: Timothy Arceri 
> >>
> >> ---
> >>  docs/devinfo.html | 18 ++
> >>  1 file changed, 18 insertions(+)
> >>
> >> diff --git a/docs/devinfo.html b/docs/devinfo.html
> >> index 8ebf80f..ed9eb9b 100644
> >> --- a/docs/devinfo.html
> >> +++ b/docs/devinfo.html
> >> @@ -162,6 +162,24 @@ components.
> >>  perhaps, in very trivial cases.)
> >>  
> >>
> >> +Git Tips
> >> +
> >> +
> >> +Test for build breakage between patches e.g last 8 commits.
> >> +
> >> +git rebase -i --exec="make -j4" HEAD~8
> >> +
> >> +Sets the default mailing address for your repo.
> >> +
> >> +git config --local sendemail.to mesa-dev@lists.freedesktop.org
> >> +
> >> + Add version to subject line of patch series in this case for the 
last 8
> >> +commits before sending.
> >> +
> >> +git send-email --subject-prefix="PATCH v4" HEAD~8
> >
> > Fwiw some of us tend to use the shorter version:
> >
> > $ git send-email -v4 -8
> >
> > Whether we want it or not I prefer if others decise.
> 
> Since I didn't know either of those arguments, and Ken just replied
> and suggested one but not the other, it seems valuable to note them
> instead :)

Nice!  I knew about -1, but I didn't realize you could put an arbitrary
integer there to get more than one patch.  Thanks :)


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 13/15] program: Remove NV_fragment_program opcode parsing.

[Matt Turner]

---
 src/mesa/program/program_lexer.l  | 8 
 src/mesa/program/program_parser.h | 1 -
 2 files changed, 9 deletions(-)

diff --git a/src/mesa/program/program_lexer.l b/src/mesa/program/program_lexer.l
index 2fcd71f..baaa58a 100644
--- a/src/mesa/program/program_lexer.l
+++ b/src/mesa/program/program_lexer.l
@@ -32,7 +32,6 @@
 
 #define require_ARB_vp (yyextra->mode == ARB_vertex)
 #define require_ARB_fp (yyextra->mode == ARB_fragment)
-#define require_NV_fp  (yyextra->option.NV_fragment)
 #define require_shadow (yyextra->option.Shadow)
 #define require_rect   (yyextra->option.TexRect)
 #define require_texarray(yyextra->option.TexArray)
@@ -191,8 +190,6 @@ ARL{ return_opcode(require_ARB_vp, ARL, 
ARL, 3); }
 CMP{sat}   { return_opcode(require_ARB_fp, TRI_OP, CMP, 3); }
 COS{szf}{cc}{sat}  { return_opcode(require_ARB_fp, SCALAR_OP, COS, 3); }
 
-DDX{szf}{cc}{sat}  { return_opcode(require_NV_fp,  VECTOR_OP, DDX, 3); }
-DDY{szf}{cc}{sat}  { return_opcode(require_NV_fp,  VECTOR_OP, DDY, 3); }
 DP3{sz}{cc}{sat}   { return_opcode( 1, BIN_OP, DP3, 3); }
 DP4{sz}{cc}{sat}   { return_opcode( 1, BIN_OP, DP4, 3); }
 DPH{sz}{cc}{sat}   { return_opcode( 1, BIN_OP, DPH, 3); }
@@ -223,19 +220,14 @@ RCP{szf}{cc}{sat}  { return_opcode( 1, 
SCALAR_OP, RCP, 3); }
 RSQ{szf}{cc}{sat}  { return_opcode( 1, SCALAR_OP, RSQ, 3); }
 
 SCS{sat}   { return_opcode(require_ARB_fp, SCALAR_OP, SCS, 3); }
-SEQ{sz}{cc}{sat}   { return_opcode(require_NV_fp,  BIN_OP, SEQ, 3); }
 SGE{sz}{cc}{sat}   { return_opcode( 1, BIN_OP, SGE, 3); }
-SGT{sz}{cc}{sat}   { return_opcode(require_NV_fp,  BIN_OP, SGT, 3); }
 SIN{szf}{cc}{sat}  { return_opcode(require_ARB_fp, SCALAR_OP, SIN, 3); }
-SLE{sz}{cc}{sat}   { return_opcode(require_NV_fp,  BIN_OP, SLE, 3); }
 SLT{sz}{cc}{sat}   { return_opcode( 1, BIN_OP, SLT, 3); }
-SNE{sz}{cc}{sat}   { return_opcode(require_NV_fp,  BIN_OP, SNE, 3); }
 SUB{sz}{cc}{sat}   { return_opcode( 1, BIN_OP, SUB, 3); }
 SWZ{sat}   { return_opcode( 1, SWZ, SWZ, 3); }
 
 TEX{cc}{sat}   { return_opcode(require_ARB_fp, SAMPLE_OP, TEX, 3); }
 TXB{cc}{sat}   { return_opcode(require_ARB_fp, SAMPLE_OP, TXB, 3); }
-TXD{cc}{sat}   { return_opcode(require_NV_fp,  TXD_OP, TXD, 3); }
 TXP{cc}{sat}   { return_opcode(require_ARB_fp, SAMPLE_OP, TXP, 3); }
 
 XPD{sat}   { return_opcode( 1, BIN_OP, XPD, 3); }
diff --git a/src/mesa/program/program_parser.h 
b/src/mesa/program/program_parser.h
index d5a1e22..af7b2a0 100644
--- a/src/mesa/program/program_parser.h
+++ b/src/mesa/program/program_parser.h
@@ -207,7 +207,6 @@ struct asm_parser_state {
   unsigned Shadow:1;
   unsigned TexRect:1;
   unsigned TexArray:1;
-  unsigned NV_fragment:1;
   unsigned OriginUpperLeft:1;
   unsigned PixelCenterInteger:1;
} option;
-- 
2.4.10

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

[Mesa-dev] [Bug 94295] [swrast] piglit shader_runner fast_color_clear/all-colors regression

[bugzilla-daemon]

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

--- Comment #6 from Vinson Lee  ---
(In reply to Plamena Manolova from comment #5)
> Could you please try out the new patch?

#0  find_empty_block (uniform=, prog=) at
glsl/link_uniforms.cpp:1054
1054   foreach_list_typed_safe(struct empty_uniform_block, block, link,
(gdb) l
1049   const unsigned entries = MAX2(1, uniform->array_elements);
1050
1051   if (exec_list_is_empty(>EmptyUniformLocations))
1052  return -1;
1053
1054   foreach_list_typed_safe(struct empty_uniform_block, block, link,
1055   >EmptyUniformLocations) {
1056  /* Found a block with enough slots to fit the uniform */
1057  if (block->slots == entries) {
1058 unsigned start = block->start;
(gdb) print block
$1 = (empty_uniform_block *) 0x0

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

[Mesa-dev] [PATCH 14/15] mesa: Remove NV_fragment_program_option enable bit.

[Matt Turner]

---
 src/mesa/main/extensions_table.h | 1 -
 src/mesa/main/mtypes.h   | 1 -
 2 files changed, 2 deletions(-)

diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index c80e543..50e050e 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -283,7 +283,6 @@ EXT(NV_depth_clamp  , 
ARB_depth_clamp
 EXT(NV_draw_buffers , dummy_true   
  ,  x ,  x ,  x , ES2, 2011)
 EXT(NV_fbo_color_attachments, dummy_true   
  ,  x ,  x ,  x , ES2, 2010)
 EXT(NV_fog_distance , NV_fog_distance  
  , GLL,  x ,  x ,  x , 2001)
-EXT(NV_fragment_program_option  , NV_fragment_program_option   
  , GLL,  x ,  x ,  x , 2005)
 EXT(NV_light_max_exponent   , dummy_true   
  , GLL,  x ,  x ,  x , 1999)
 EXT(NV_packed_depth_stencil , dummy_true   
  , GLL, GLC,  x ,  x , 2000)
 EXT(NV_point_sprite , NV_point_sprite  
  , GLL, GLC,  x ,  x , 2001)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index d5f0b62..5de8800 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3921,7 +3921,6 @@ struct gl_extensions
GLboolean MESA_ycbcr_texture;
GLboolean NV_conditional_render;
GLboolean NV_fog_distance;
-   GLboolean NV_fragment_program_option;
GLboolean NV_point_sprite;
GLboolean NV_primitive_restart;
GLboolean NV_texture_barrier;
-- 
2.4.10

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

[Mesa-dev] [PATCH 10/15] program: Remove NV_fragment_program Abs support.

[Matt Turner]

---
 src/mesa/main/ffvertex_prog.c |  1 -
 src/mesa/program/ir_to_mesa.cpp   |  1 -
 src/mesa/program/prog_execute.c   | 15 --
 src/mesa/program/prog_instruction.h   |  5 +
 src/mesa/program/prog_opt_constant_fold.c |  8 
 src/mesa/program/prog_optimize.c  |  4 +---
 src/mesa/program/prog_print.c |  8 ++--
 src/mesa/program/prog_to_nir.c|  6 --
 src/mesa/program/program_parse.y  | 33 ---
 src/mesa/state_tracker/st_mesa_to_tgsi.c  |  3 ---
 10 files changed, 4 insertions(+), 80 deletions(-)

diff --git a/src/mesa/main/ffvertex_prog.c b/src/mesa/main/ffvertex_prog.c
index 537c746..d72bc71 100644
--- a/src/mesa/main/ffvertex_prog.c
+++ b/src/mesa/main/ffvertex_prog.c
@@ -537,7 +537,6 @@ static void emit_arg( struct prog_src_register *src,
src->File = reg.file;
src->Index = reg.idx;
src->Swizzle = reg.swz;
-   src->Abs = reg.abs;
src->Negate = reg.negate ? NEGATE_XYZW : NEGATE_NONE;
src->RelAddr = 0;
/* Check that bitfield sizes aren't exceeded */
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index a208c05..10d931c 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2180,7 +2180,6 @@ mesa_src_reg_from_ir_src_reg(src_reg reg)
mesa_reg.Swizzle = reg.swizzle;
mesa_reg.RelAddr = reg.reladdr != NULL;
mesa_reg.Negate = reg.negate;
-   mesa_reg.Abs = 0;
 
return mesa_reg;
 }
diff --git a/src/mesa/program/prog_execute.c b/src/mesa/program/prog_execute.c
index fec72ee..8f167be 100644
--- a/src/mesa/program/prog_execute.c
+++ b/src/mesa/program/prog_execute.c
@@ -200,12 +200,6 @@ fetch_vector4(const struct prog_src_register *source,
   result[3] = src[GET_SWZ(source->Swizzle, 3)];
}
 
-   if (source->Abs) {
-  result[0] = fabsf(result[0]);
-  result[1] = fabsf(result[1]);
-  result[2] = fabsf(result[2]);
-  result[3] = fabsf(result[3]);
-   }
if (source->Negate) {
   assert(source->Negate == NEGATE_XYZW);
   result[0] = -result[0];
@@ -258,12 +252,6 @@ fetch_vector4_deriv(struct gl_context * ctx,
   result[2] = deriv[GET_SWZ(source->Swizzle, 2)];
   result[3] = deriv[GET_SWZ(source->Swizzle, 3)];
   
-  if (source->Abs) {
- result[0] = fabsf(result[0]);
- result[1] = fabsf(result[1]);
- result[2] = fabsf(result[2]);
- result[3] = fabsf(result[3]);
-  }
   if (source->Negate) {
  assert(source->Negate == NEGATE_XYZW);
  result[0] = -result[0];
@@ -289,9 +277,6 @@ fetch_vector1(const struct prog_src_register *source,
 
result[0] = src[GET_SWZ(source->Swizzle, 0)];
 
-   if (source->Abs) {
-  result[0] = fabsf(result[0]);
-   }
if (source->Negate) {
   result[0] = -result[0];
}
diff --git a/src/mesa/program/prog_instruction.h 
b/src/mesa/program/prog_instruction.h
index 9dc869b..0120227 100644
--- a/src/mesa/program/prog_instruction.h
+++ b/src/mesa/program/prog_instruction.h
@@ -198,11 +198,8 @@ struct prog_src_register
GLuint Swizzle:12;
GLuint RelAddr:1;
 
-   /** Take the component-wise absolute value */
-   GLuint Abs:1;
-
/**
-* Post-Abs negation.
+* Negation.
 * This will either be NEGATE_NONE or NEGATE_XYZW, except for the SWZ
 * instruction which allows per-component negation.
 */
diff --git a/src/mesa/program/prog_opt_constant_fold.c 
b/src/mesa/program/prog_opt_constant_fold.c
index e2518e6..1d796dc 100644
--- a/src/mesa/program/prog_opt_constant_fold.c
+++ b/src/mesa/program/prog_opt_constant_fold.c
@@ -82,7 +82,6 @@ src_regs_are_same(const struct prog_src_register *a,
return (a->File == b->File)
   && (a->Index == b->Index)
   && (a->Swizzle == b->Swizzle)
-  && (a->Abs == b->Abs)
   && (a->Negate == b->Negate)
   && (a->RelAddr == 0)
   && (b->RelAddr == 0);
@@ -99,13 +98,6 @@ get_value(struct gl_program *prog, struct prog_src_register 
*r, float *data)
data[2] = value[GET_SWZ(r->Swizzle, 2)].f;
data[3] = value[GET_SWZ(r->Swizzle, 3)].f;
 
-   if (r->Abs) {
-  data[0] = fabsf(data[0]);
-  data[1] = fabsf(data[1]);
-  data[2] = fabsf(data[2]);
-  data[3] = fabsf(data[3]);
-   }
-
if (r->Negate & 0x01) {
   data[0] = -data[0];
}
diff --git a/src/mesa/program/prog_optimize.c b/src/mesa/program/prog_optimize.c
index a416402..c6d2264 100644
--- a/src/mesa/program/prog_optimize.c
+++ b/src/mesa/program/prog_optimize.c
@@ -447,7 +447,6 @@ can_downward_mov_be_modifed(const struct prog_instruction 
*mov)
   mov->Opcode == OPCODE_MOV &&
   mov->SrcReg[0].RelAddr == 0 &&
   mov->SrcReg[0].Negate == 0 &&
-  mov->SrcReg[0].Abs == 0 &&
   mov->DstReg.RelAddr == 0;
 }
 
@@ -516,8 +515,7 @@ _mesa_remove_extra_move_use(struct gl_program *prog)
 
if (inst2->SrcReg[arg].File != mov->DstReg.File ||
inst2->SrcReg[arg].Index != 

[Mesa-dev] [PATCH 11/15] program: Remove NV_fragment_program_option parsing support.

[Matt Turner]

---
 src/mesa/program/program_parse.y | 49 
 1 file changed, 5 insertions(+), 44 deletions(-)

diff --git a/src/mesa/program/program_parse.y b/src/mesa/program/program_parse.y
index 4c32bc8..5651bdb 100644
--- a/src/mesa/program/program_parse.y
+++ b/src/mesa/program/program_parse.y
@@ -1813,46 +1813,7 @@ optionalSign: '+'{ $$ = FALSE; }
|{ $$ = FALSE; }
;
 
-TEMP_statement: optVarSize TEMP { $$ = $2; } varNameList
-   ;
-
-optVarSize: string
-   {
-  /* NV_fragment_program_option defines the size qualifiers in a
-   * fairly broken way.  "SHORT" or "LONG" can optionally be used
-   * before TEMP or OUTPUT.  However, neither is a reserved word!
-   * This means that we have to parse it as an identifier, then check
-   * to make sure it's one of the valid values.  *sigh*
-   *
-   * In addition, the grammar in the extension spec does *not* allow
-   * the size specifier to be optional, but all known implementations
-   * do.
-   */
-  if (!state->option.NV_fragment) {
- yyerror(& @1, state, "unexpected IDENTIFIER");
- YYERROR;
-  }
-
-  if (strcmp("SHORT", $1) == 0) {
-  } else if (strcmp("LONG", $1) == 0) {
-  } else {
- char *const err_str =
-make_error_string("invalid storage size specifier \"%s\"",
-  $1);
-
- yyerror(& @1, state, (err_str != NULL)
- ? err_str : "invalid storage size specifier");
-
- if (err_str != NULL) {
-free(err_str);
- }
-
- YYERROR;
-  }
-   }
-   |
-   {
-   }
+TEMP_statement: TEMP { $$ = $1; } varNameList
;
 
 ADDRESS_statement: ADDRESS { $$ = $1; } varNameList
@@ -1874,16 +1835,16 @@ varNameList: varNameList ',' IDENTIFIER
}
;
 
-OUTPUT_statement: optVarSize OUTPUT IDENTIFIER '=' resultBinding
+OUTPUT_statement: OUTPUT IDENTIFIER '=' resultBinding
{
   struct asm_symbol *const s =
- declare_variable(state, $3, at_output, & @3);
+ declare_variable(state, $2, at_output, & @2);
 
   if (s == NULL) {
- free($3);
+ free($2);
  YYERROR;
   } else {
- s->output_binding = $5;
+ s->output_binding = $4;
   }
}
;
-- 
2.4.10

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

[Mesa-dev] [PATCH 12/15] program: Remove NV_fragment_program scalar suffix parsing.

[Matt Turner]

---
 src/mesa/program/program_parse.y | 17 -
 1 file changed, 17 deletions(-)

diff --git a/src/mesa/program/program_parse.y b/src/mesa/program/program_parse.y
index 5651bdb..ad94fe0 100644
--- a/src/mesa/program/program_parse.y
+++ b/src/mesa/program/program_parse.y
@@ -564,23 +564,6 @@ scalarUse:  srcReg scalarSuffix
   $$.Base.Swizzle = _mesa_combine_swizzles($$.Base.Swizzle,
$2.swizzle);
}
-   | paramConstScalarUse
-   {
-  struct asm_symbol temp_sym;
-
-  if (!state->option.NV_fragment) {
- yyerror(& @1, state, "expected scalar suffix");
- YYERROR;
-  }
-
-  memset(& temp_sym, 0, sizeof(temp_sym));
-  temp_sym.param_binding_begin = ~0;
-  initialize_symbol_from_const(state->prog, & temp_sym, & $1, GL_TRUE);
-
-  set_src_reg_swz(& $$, PROGRAM_CONSTANT,
-   temp_sym.param_binding_begin,
-   temp_sym.param_binding_swizzle);
-   }
;
 
 swizzleSrcReg: optionalSign srcReg swizzleSuffix
-- 
2.4.10

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

[Mesa-dev] [PATCH 03/15] program: Mark table const.

[Matt Turner]

---
 src/mesa/program/prog_noise.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/program/prog_noise.c b/src/mesa/program/prog_noise.c
index ac920c2..e2e209e 100644
--- a/src/mesa/program/prog_noise.c
+++ b/src/mesa/program/prog_noise.c
@@ -188,7 +188,7 @@ grad4(int hash, float x, float y, float z, float t)
  * Details can be found where this table is used, in the 4D noise method.
  * TODO: This should not be required, backport it from Bill's GLSL code!
  */
-static unsigned char simplex[64][4] = {
+static const unsigned char simplex[64][4] = {
{0, 1, 2, 3}, {0, 1, 3, 2}, {0, 0, 0, 0}, {0, 2, 3, 1},
{0, 0, 0, 0}, {0, 0, 0, 0}, {0, 0, 0, 0}, {1, 2, 3, 0},
{0, 2, 1, 3}, {0, 0, 0, 0}, {0, 3, 1, 2}, {0, 3, 2, 1},
-- 
2.4.10

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

[Mesa-dev] [PATCH 09/15] program: Remove incorrect comment about OPCODE_TXD.

[Matt Turner]

The table in prog_instruction.h is correct.
---
 src/mesa/program/prog_execute.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/program/prog_execute.c b/src/mesa/program/prog_execute.c
index 0755ac8..fec72ee 100644
--- a/src/mesa/program/prog_execute.c
+++ b/src/mesa/program/prog_execute.c
@@ -1203,7 +1203,7 @@ _mesa_execute_program(struct gl_context * ctx,
 store_vector4(inst, machine, color);
  }
  break;
-  case OPCODE_TXD: /* GL_NV_fragment_program only */
+  case OPCODE_TXD:
  /* Texture lookup w/ partial derivatives for LOD */
  {
 GLfloat texcoord[4], dtdx[4], dtdy[4], color[4];
-- 
2.4.10

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

[Mesa-dev] [PATCH 01/15] docs: Remove descriptions of long dead Emit* fields.

[Matt Turner]

Dead since commit d8a366200 in 2010.
---
 docs/shading.html | 17 -
 1 file changed, 17 deletions(-)

diff --git a/docs/shading.html b/docs/shading.html
index e9fe3dd..df23694 100644
--- a/docs/shading.html
+++ b/docs/shading.html
@@ -222,34 +222,17 @@ struct gl_shader_state
 {
...
/** Driver-selectable options: */
-   GLboolean EmitHighLevelInstructions;
GLboolean EmitCondCodes;
-   GLboolean EmitComments;
 };
 
 
 
-EmitHighLevelInstructions
-
-This option controls instruction selection for loops and conditionals.
-If the option is set high-level IF/ELSE/ENDIF, LOOP/ENDLOOP, CONT/BRK
-instructions will be emitted.
-Otherwise, those constructs will be implemented with BRA instructions.
-
-
 EmitCondCodes
 
 If set, condition codes (ala GL_NV_fragment_program) will be used for
 branching and looping.
 Otherwise, ordinary registers will be used (the IF instruction will
 examine the first operand's X component and do the if-part if non-zero).
-This option is only relevant if EmitHighLevelInstructions is set.
-
-
-EmitComments
-
-If set, instructions will be annotated with comments to help with debugging.
-Extra NOP instructions will also be inserted.
 
 
 
-- 
2.4.10

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

[Mesa-dev] [PATCH 15/15] mesa: Remove NV_fragment_program remnants from dlist.c.

[Matt Turner]

---
 src/mesa/main/dlist.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index afd2d83..6dfb84b 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -304,8 +304,8 @@ typedef enum
OPCODE_SAMPLE_COVERAGE,
/* GL_ARB_window_pos */
OPCODE_WINDOW_POS_ARB,
-   /* GL_NV_fragment_program */
-   OPCODE_BIND_PROGRAM_NV,
+   /* GL_ARB_vertex_program */
+   OPCODE_BIND_PROGRAM_ARB,
OPCODE_PROGRAM_LOCAL_PARAMETER_ARB,
/* GL_EXT_stencil_two_side */
OPCODE_ACTIVE_STENCIL_FACE_EXT,
@@ -4957,15 +4957,15 @@ save_SampleCoverageARB(GLclampf value, GLboolean invert)
 
 
 /*
- * GL_NV_fragment_program
+ * GL_ARB_vertex_program
  */
 static void GLAPIENTRY
-save_BindProgramNV(GLenum target, GLuint id)
+save_BindProgramARB(GLenum target, GLuint id)
 {
GET_CURRENT_CONTEXT(ctx);
Node *n;
ASSERT_OUTSIDE_SAVE_BEGIN_END_AND_FLUSH(ctx);
-   n = alloc_instruction(ctx, OPCODE_BIND_PROGRAM_NV, 2);
+   n = alloc_instruction(ctx, OPCODE_BIND_PROGRAM_ARB, 2);
if (n) {
   n[1].e = target;
   n[2].ui = id;
@@ -8607,7 +8607,7 @@ execute_list(struct gl_context *ctx, GLuint list)
  case OPCODE_WINDOW_POS_ARB:   /* GL_ARB_window_pos */
 CALL_WindowPos3f(ctx->Exec, (n[1].f, n[2].f, n[3].f));
 break;
- case OPCODE_BIND_PROGRAM_NV:  /* GL_ARB_vertex_program */
+ case OPCODE_BIND_PROGRAM_ARB:  /* GL_ARB_vertex_program */
 CALL_BindProgramARB(ctx->Exec, (n[1].e, n[2].ui));
 break;
  case OPCODE_PROGRAM_LOCAL_PARAMETER_ARB:
@@ -9787,13 +9787,6 @@ _mesa_initialize_save_table(const struct gl_context *ctx)
SET_WindowPos4sMESA(table, save_WindowPos4sMESA);
SET_WindowPos4svMESA(table, save_WindowPos4svMESA);
 
-   /* 233. GL_NV_vertex_program */
-   /* The following commands DO NOT go into display lists:
-* AreProgramsResidentNV, IsProgramNV, GenProgramsNV, DeleteProgramsNV,
-* VertexAttribPointerNV, GetProgram*, GetVertexAttrib*
-*/
-   SET_BindProgramARB(table, save_BindProgramNV);
-
/* 245. GL_ATI_fragment_shader */
SET_BindFragmentShaderATI(table, save_BindFragmentShaderATI);
SET_SetFragmentShaderConstantATI(table, save_SetFragmentShaderConstantATI);
@@ -9838,7 +9831,7 @@ _mesa_initialize_save_table(const struct gl_context *ctx)
/* ARB 27. GL_ARB_fragment_program */
/* glVertexAttrib* functions alias the NV ones, handled elsewhere */
SET_ProgramStringARB(table, save_ProgramStringARB);
-   SET_BindProgramARB(table, save_BindProgramNV);
+   SET_BindProgramARB(table, save_BindProgramARB);
SET_ProgramEnvParameter4dARB(table, save_ProgramEnvParameter4dARB);
SET_ProgramEnvParameter4dvARB(table, save_ProgramEnvParameter4dvARB);
SET_ProgramEnvParameter4fARB(table, save_ProgramEnvParameter4fARB);
-- 
2.4.10

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

[Mesa-dev] [PATCH 02/15] mesa: Remove EmitCondCodes.

[Matt Turner]

---
 docs/shading.html| 28 
 src/mesa/drivers/dri/i915/i915_context.c |  1 -
 src/mesa/drivers/dri/i965/brw_compiler.c |  1 -
 src/mesa/main/mtypes.h   |  1 -
 src/mesa/program/ir_to_mesa.cpp  | 24 ++--
 5 files changed, 2 insertions(+), 53 deletions(-)

diff --git a/docs/shading.html b/docs/shading.html
index df23694..cf989ce 100644
--- a/docs/shading.html
+++ b/docs/shading.html
@@ -209,34 +209,6 @@ The final vertex and fragment programs may be interpreted 
in software
 (see drivers/dri/i915/i915_fragprog.c for example).
 
 
-Code Generation Options
-
-
-Internally, there are several options that control the compiler's code
-generation and instruction selection.
-These options are seen in the gl_shader_state struct and may be set
-by the device driver to indicate its preferences:
-
-
-struct gl_shader_state
-{
-   ...
-   /** Driver-selectable options: */
-   GLboolean EmitCondCodes;
-};
-
-
-
-EmitCondCodes
-
-If set, condition codes (ala GL_NV_fragment_program) will be used for
-branching and looping.
-Otherwise, ordinary registers will be used (the IF instruction will
-examine the first operand's X component and do the if-part if non-zero).
-
-
-
-
 Compiler Validation
 
 
diff --git a/src/mesa/drivers/dri/i915/i915_context.c 
b/src/mesa/drivers/dri/i915/i915_context.c
index 57b033c..83aaf9e 100644
--- a/src/mesa/drivers/dri/i915/i915_context.c
+++ b/src/mesa/drivers/dri/i915/i915_context.c
@@ -254,7 +254,6 @@ i915CreateContext(int api,
/* FINISHME: Are there other options that should be enabled for software
 * FINISHME: vertex shaders?
 */
-   ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].EmitCondCodes = true;
ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].EmitNoIndirectSampler =
   true;
 
diff --git a/src/mesa/drivers/dri/i965/brw_compiler.c 
b/src/mesa/drivers/dri/i965/brw_compiler.c
index 1489207..2f05a26 100644
--- a/src/mesa/drivers/dri/i965/brw_compiler.c
+++ b/src/mesa/drivers/dri/i965/brw_compiler.c
@@ -143,7 +143,6 @@ brw_compiler_create(void *mem_ctx, const struct 
brw_device_info *devinfo)
   compiler->glsl_compiler_options[i].MaxIfDepth =
  devinfo->gen < 6 ? 16 : UINT_MAX;
 
-  compiler->glsl_compiler_options[i].EmitCondCodes = true;
   compiler->glsl_compiler_options[i].EmitNoNoise = true;
   compiler->glsl_compiler_options[i].EmitNoMainReturn = true;
   compiler->glsl_compiler_options[i].EmitNoIndirectInput = true;
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 12d3863..d5f0b62 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2946,7 +2946,6 @@ struct gl_pipeline_shader_state
 struct gl_shader_compiler_options
 {
/** Driver-selectable options: */
-   GLboolean EmitCondCodes; /**< Use condition codes? */
GLboolean EmitNoLoops;
GLboolean EmitNoFunctions;
GLboolean EmitNoCont;  /**< Emit CONT opcode? */
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 4db6250..6d33b1b 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2124,32 +2124,12 @@ ir_to_mesa_visitor::visit(ir_discard *ir)
 void
 ir_to_mesa_visitor::visit(ir_if *ir)
 {
-   ir_to_mesa_instruction *cond_inst, *if_inst;
-   ir_to_mesa_instruction *prev_inst;
-
-   prev_inst = (ir_to_mesa_instruction *)this->instructions.get_tail();
+   ir_to_mesa_instruction *if_inst;
 
ir->condition->accept(this);
assert(this->result.file != PROGRAM_UNDEFINED);
 
-   if (this->options->EmitCondCodes) {
-  cond_inst = (ir_to_mesa_instruction *)this->instructions.get_tail();
-
-  /* See if we actually generated any instruction for generating
-   * the condition.  If not, then cook up a move to a temp so we
-   * have something to set cond_update on.
-   */
-  if (cond_inst == prev_inst) {
-src_reg temp = get_temp(glsl_type::bool_type);
-cond_inst = emit(ir->condition, OPCODE_MOV, dst_reg(temp), result);
-  }
-  cond_inst->cond_update = GL_TRUE;
-
-  if_inst = emit(ir->condition, OPCODE_IF);
-  if_inst->dst.cond_mask = COND_NE;
-   } else {
-  if_inst = emit(ir->condition, OPCODE_IF, undef_dst, this->result);
-   }
+   if_inst = emit(ir->condition, OPCODE_IF, undef_dst, this->result);
 
this->instructions.push_tail(if_inst);
 
-- 
2.4.10

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

[Mesa-dev] [PATCH 00/15] program: Remove remnants of NV_fragment_program and other cruft

[Matt Turner]

We removed NV_vertex_program and NV_fragment_program{,_option} in 2012 yet we
continue finding more pieces of them years later. Last year we discussed
removing some remaining bits of NV_fragment_program_option that were used by
a broken Viewperf11 test [1]. Hopefully it's been long enough and we can strip
out the rest of the condition code support from Mesa IR.

If not... then I guess I can try to rebase that out of the series. I hope it
doesn't come to that. I'd really like to replace Mesa IR with NIR. idr
suggested a alternate plan that's making more and more sense to me though: push
Mesa IR down to just something i915 and r200 consume or get rid of it entirely.

That would require 1) a NIR -> Mesa IR translator (for i915 and r200)
   2) changing the program parser to generate NIR
   3) ...?

And with Rob's work to bring NIR to Gallium (and probably some more), we can
probably cut out Mesa IR -> TGSI as well.


[1] https://lists.freedesktop.org/archives/mesa-dev/2015-February/077015.html

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

[Mesa-dev] [PATCH 08/15] program: Remove OPCODE_TXP_NV.

[Matt Turner]

---
 src/mesa/program/prog_execute.c | 20 
 src/mesa/program/prog_instruction.c |  1 -
 src/mesa/program/prog_instruction.h |  1 -
 src/mesa/program/prog_to_nir.c  |  7 ---
 src/mesa/program/programopt.c   |  1 -
 5 files changed, 30 deletions(-)

diff --git a/src/mesa/program/prog_execute.c b/src/mesa/program/prog_execute.c
index d336c51..0755ac8 100644
--- a/src/mesa/program/prog_execute.c
+++ b/src/mesa/program/prog_execute.c
@@ -1253,26 +1253,6 @@ _mesa_execute_program(struct gl_context * ctx,
 store_vector4(inst, machine, color);
  }
  break;
-  case OPCODE_TXP_NV:  /* GL_NV_fragment_program only */
- /* Texture lookup w/ projective divide, as above, but do not
-  * do the divide by w if sampling from a cube map.
-  */
- {
-GLfloat texcoord[4], color[4];
-
-fetch_vector4(>SrcReg[0], machine, texcoord);
-if (inst->TexSrcTarget != TEXTURE_CUBE_INDEX &&
-texcoord[3] != 0.0F) {
-   texcoord[0] /= texcoord[3];
-   texcoord[1] /= texcoord[3];
-   texcoord[2] /= texcoord[3];
-}
-
-fetch_texel(ctx, machine, inst, texcoord, 0.0, color);
-
-store_vector4(inst, machine, color);
- }
- break;
   case OPCODE_TRUNC:   /* truncate toward zero */
  {
 GLfloat a[4], result[4];
diff --git a/src/mesa/program/prog_instruction.c 
b/src/mesa/program/prog_instruction.c
index 612c0c2..0b80383 100644
--- a/src/mesa/program/prog_instruction.c
+++ b/src/mesa/program/prog_instruction.c
@@ -184,7 +184,6 @@ static const struct instruction_info InstInfo[MAX_OPCODE] = 
{
{ OPCODE_TXD,"TXD", 3, 1 },
{ OPCODE_TXL,"TXL", 1, 1 },
{ OPCODE_TXP,"TXP", 1, 1 },
-   { OPCODE_TXP_NV, "TXP_NV",  1, 1 },
{ OPCODE_TRUNC,  "TRUNC",   1, 1 },
{ OPCODE_XPD,"XPD", 2, 1 }
 };
diff --git a/src/mesa/program/prog_instruction.h 
b/src/mesa/program/prog_instruction.h
index ceec16c..9dc869b 100644
--- a/src/mesa/program/prog_instruction.h
+++ b/src/mesa/program/prog_instruction.h
@@ -173,7 +173,6 @@ enum prog_opcode {
OPCODE_TXD,   /*X X   */
OPCODE_TXL,   /*3   2 X   */
OPCODE_TXP,   /*X X   */
-   OPCODE_TXP_NV,/*3   X */
OPCODE_TRUNC, /*  X   */
OPCODE_XPD,   /*   XX */
MAX_OPCODE
diff --git a/src/mesa/program/prog_to_nir.c b/src/mesa/program/prog_to_nir.c
index 74cbbfb..fa31dfc 100644
--- a/src/mesa/program/prog_to_nir.c
+++ b/src/mesa/program/prog_to_nir.c
@@ -592,11 +592,6 @@ ptn_tex(nir_builder *b, nir_alu_dest dest, nir_ssa_def 
**src,
   op = nir_texop_tex;
   num_srcs = 2;
   break;
-   case OPCODE_TXP_NV:
-  assert(!"not handled");
-  op = nir_texop_tex;
-  num_srcs = 2;
-  break;
default:
   fprintf(stderr, "unknown tex op %d\n", prog_inst->Opcode);
   abort();
@@ -743,7 +738,6 @@ static const nir_op op_trans[MAX_OPCODE] = {
[OPCODE_TXD] = 0,
[OPCODE_TXL] = 0,
[OPCODE_TXP] = 0,
-   [OPCODE_TXP_NV] = 0,
[OPCODE_XPD] = 0,
 };
 
@@ -882,7 +876,6 @@ ptn_emit_instruction(struct ptn_compile *c, struct 
prog_instruction *prog_inst)
case OPCODE_TXD:
case OPCODE_TXL:
case OPCODE_TXP:
-   case OPCODE_TXP_NV:
   ptn_tex(b, dest, src, prog_inst);
   break;
 
diff --git a/src/mesa/program/programopt.c b/src/mesa/program/programopt.c
index 24dde57..4dd9998 100644
--- a/src/mesa/program/programopt.c
+++ b/src/mesa/program/programopt.c
@@ -426,7 +426,6 @@ is_texture_instruction(const struct prog_instruction *inst)
case OPCODE_TXD:
case OPCODE_TXL:
case OPCODE_TXP:
-   case OPCODE_TXP_NV:
   return GL_TRUE;
default:
   return GL_FALSE;
-- 
2.4.10

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

[Mesa-dev] [PATCH 04/15] program: Remove RelAddr2 support.

[Matt Turner]

Looks like more never-used crap from the first geometry shader attempt.
---
 src/mesa/program/ir_to_mesa.cpp  |  3 ---
 src/mesa/program/prog_instruction.h  | 16 
 src/mesa/program/prog_optimize.c |  2 --
 src/mesa/program/prog_print.c| 14 +++---
 src/mesa/state_tracker/st_mesa_to_tgsi.c |  9 -
 5 files changed, 3 insertions(+), 41 deletions(-)

diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 6d33b1b..6051df1 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2187,9 +2187,6 @@ mesa_src_reg_from_ir_src_reg(src_reg reg)
mesa_reg.RelAddr = reg.reladdr != NULL;
mesa_reg.Negate = reg.negate;
mesa_reg.Abs = 0;
-   mesa_reg.HasIndex2 = GL_FALSE;
-   mesa_reg.RelAddr2 = 0;
-   mesa_reg.Index2 = 0;
 
return mesa_reg;
 }
diff --git a/src/mesa/program/prog_instruction.h 
b/src/mesa/program/prog_instruction.h
index d56f96c..d839268 100644
--- a/src/mesa/program/prog_instruction.h
+++ b/src/mesa/program/prog_instruction.h
@@ -235,22 +235,6 @@ struct prog_src_register
 * instruction which allows per-component negation.
 */
GLuint Negate:4;
-
-   /**
-* Is the register two-dimensional.
-* Two dimensional registers are of the
-* REGISTER[index][index2] format.
-* They are used by the geometry shaders where
-* the first index is the index within an array
-* and the second index is the semantic of the
-* array, e.g. gl_PositionIn[index] would become
-* INPUT[index][gl_PositionIn]
-*/
-   GLuint HasIndex2:1;
-   GLuint RelAddr2:1;
-   GLint Index2:(INST_INDEX_BITS+1); /**< Extra bit here for sign bit.
-   * May be negative for relative
-   * addressing. */
 };
 
 
diff --git a/src/mesa/program/prog_optimize.c b/src/mesa/program/prog_optimize.c
index f9e9035..9f7d0e3 100644
--- a/src/mesa/program/prog_optimize.c
+++ b/src/mesa/program/prog_optimize.c
@@ -465,8 +465,6 @@ can_downward_mov_be_modifed(const struct prog_instruction 
*mov)
   mov->SrcReg[0].RelAddr == 0 &&
   mov->SrcReg[0].Negate == 0 &&
   mov->SrcReg[0].Abs == 0 &&
-  mov->SrcReg[0].HasIndex2 == 0 &&
-  mov->SrcReg[0].RelAddr2 == 0 &&
   mov->DstReg.RelAddr == 0 &&
   mov->DstReg.CondMask == COND_TR;
 }
diff --git a/src/mesa/program/prog_print.c b/src/mesa/program/prog_print.c
index bb7c2c6..2bc07cb 100644
--- a/src/mesa/program/prog_print.c
+++ b/src/mesa/program/prog_print.c
@@ -354,8 +354,7 @@ arb_output_attrib_string(GLuint index, GLenum progType)
  */
 static const char *
 reg_string(gl_register_file f, GLint index, gl_prog_print_mode mode,
-   GLboolean relAddr, const struct gl_program *prog,
-   GLboolean hasIndex2, GLboolean relAddr2, GLint index2)
+   GLboolean relAddr, const struct gl_program *prog)
 {
static char str[100];
const char *addr = relAddr ? "ADDR+" : "";
@@ -366,11 +365,6 @@ reg_string(gl_register_file f, GLint index, 
gl_prog_print_mode mode,
case PROG_PRINT_DEBUG:
   sprintf(str, "%s[%s%d]",
   _mesa_register_file_name(f), addr, index);
-  if (hasIndex2) {
- int offset = strlen(str);
- const char *addr2 = relAddr2 ? "ADDR+" : "";
- sprintf(str+offset, "[%s%d]", addr2, index2);
-  }
   break;
 
case PROG_PRINT_ARB:
@@ -534,8 +528,7 @@ fprint_dst_reg(FILE * f,
 {
fprintf(f, "%s%s",
   reg_string((gl_register_file) dstReg->File,
- dstReg->Index, mode, dstReg->RelAddr, prog,
-  GL_FALSE, GL_FALSE, 0),
+ dstReg->Index, mode, dstReg->RelAddr, prog),
   _mesa_writemask_string(dstReg->WriteMask));

if (dstReg->CondMask != COND_TR) {
@@ -565,8 +558,7 @@ fprint_src_reg(FILE *f,
fprintf(f, "%s%s%s%s",
   abs,
   reg_string((gl_register_file) srcReg->File,
- srcReg->Index, mode, srcReg->RelAddr, prog,
-  srcReg->HasIndex2, srcReg->RelAddr2, srcReg->Index2),
+ srcReg->Index, mode, srcReg->RelAddr, prog),
   _mesa_swizzle_string(srcReg->Swizzle,
srcReg->Negate, GL_FALSE),
   abs);
diff --git a/src/mesa/state_tracker/st_mesa_to_tgsi.c 
b/src/mesa/state_tracker/st_mesa_to_tgsi.c
index be47823..62f0aee7 100644
--- a/src/mesa/state_tracker/st_mesa_to_tgsi.c
+++ b/src/mesa/state_tracker/st_mesa_to_tgsi.c
@@ -311,15 +311,6 @@ translate_src( struct st_translate *t,
 {
struct ureg_src src = src_register( t, SrcReg->File, SrcReg->Index );
 
-   if (t->procType == TGSI_PROCESSOR_GEOMETRY && SrcReg->HasIndex2) {
-  src = src_register( t, SrcReg->File, SrcReg->Index2 );
-  if (SrcReg->RelAddr2)
- src = ureg_src_dimension_indirect( src, ureg_src(t->address[0]),
-SrcReg->Index);
-  else
- src 

[Mesa-dev] [PATCH 07/15] program: Clean up after previous commit.

[Matt Turner]

---
 src/mesa/program/prog_optimize.c | 84 
 1 file changed, 41 insertions(+), 43 deletions(-)

diff --git a/src/mesa/program/prog_optimize.c b/src/mesa/program/prog_optimize.c
index d9d7c9e..a416402 100644
--- a/src/mesa/program/prog_optimize.c
+++ b/src/mesa/program/prog_optimize.c
@@ -60,49 +60,47 @@ get_src_arg_mask(const struct prog_instruction *inst,
assert(arg < _mesa_num_inst_src_regs(inst->Opcode));
 
/* Form the dst register, find the written channels */
-   {
-  switch (inst->Opcode) {
-  case OPCODE_MOV:
-  case OPCODE_MIN:
-  case OPCODE_MAX:
-  case OPCODE_ABS:
-  case OPCODE_ADD:
-  case OPCODE_MAD:
-  case OPCODE_MUL:
-  case OPCODE_SUB:
-  case OPCODE_CMP:
-  case OPCODE_FLR:
-  case OPCODE_FRC:
-  case OPCODE_LRP:
-  case OPCODE_SEQ:
-  case OPCODE_SGE:
-  case OPCODE_SGT:
-  case OPCODE_SLE:
-  case OPCODE_SLT:
-  case OPCODE_SNE:
-  case OPCODE_SSG:
- channel_mask = inst->DstReg.WriteMask & dst_mask;
- break;
-  case OPCODE_RCP:
-  case OPCODE_SIN:
-  case OPCODE_COS:
-  case OPCODE_RSQ:
-  case OPCODE_POW:
-  case OPCODE_EX2:
-  case OPCODE_LOG:
- channel_mask = WRITEMASK_X;
- break;
-  case OPCODE_DP2:
- channel_mask = WRITEMASK_XY;
- break;
-  case OPCODE_DP3:
-  case OPCODE_XPD:
- channel_mask = WRITEMASK_XYZ;
- break;
-  default:
- channel_mask = WRITEMASK_XYZW;
- break;
-  }
+   switch (inst->Opcode) {
+   case OPCODE_MOV:
+   case OPCODE_MIN:
+   case OPCODE_MAX:
+   case OPCODE_ABS:
+   case OPCODE_ADD:
+   case OPCODE_MAD:
+   case OPCODE_MUL:
+   case OPCODE_SUB:
+   case OPCODE_CMP:
+   case OPCODE_FLR:
+   case OPCODE_FRC:
+   case OPCODE_LRP:
+   case OPCODE_SEQ:
+   case OPCODE_SGE:
+   case OPCODE_SGT:
+   case OPCODE_SLE:
+   case OPCODE_SLT:
+   case OPCODE_SNE:
+   case OPCODE_SSG:
+  channel_mask = inst->DstReg.WriteMask & dst_mask;
+  break;
+   case OPCODE_RCP:
+   case OPCODE_SIN:
+   case OPCODE_COS:
+   case OPCODE_RSQ:
+   case OPCODE_POW:
+   case OPCODE_EX2:
+   case OPCODE_LOG:
+  channel_mask = WRITEMASK_X;
+  break;
+   case OPCODE_DP2:
+  channel_mask = WRITEMASK_XY;
+  break;
+   case OPCODE_DP3:
+   case OPCODE_XPD:
+  channel_mask = WRITEMASK_XYZ;
+  break;
+   default:
+  channel_mask = WRITEMASK_XYZW;
+  break;
}
 
/* Now, given the src swizzle and the written channels, find which
-- 
2.4.10

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

[Mesa-dev] [PATCH 06/15] program: Remove condition-code and precision support.

[Matt Turner]

---
 src/mesa/main/ffvertex_prog.c  |   2 -
 src/mesa/program/ir_to_mesa.cpp|   7 --
 src/mesa/program/prog_execute.c| 145 -
 src/mesa/program/prog_execute.h|   1 -
 src/mesa/program/prog_instruction.c|   3 -
 src/mesa/program/prog_instruction.h|  78 +---
 src/mesa/program/prog_optimize.c   |  23 +
 src/mesa/program/prog_print.c  |  51 +-
 src/mesa/program/program_parse.y   |  89 +-
 src/mesa/program/program_parse_extra.c | 103 +---
 src/mesa/program/program_parser.h  |  13 ---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp |   6 --
 src/mesa/swrast/s_fragprog.c   |   6 --
 src/mesa/tnl/t_vb_program.c|   6 --
 14 files changed, 27 insertions(+), 506 deletions(-)

diff --git a/src/mesa/main/ffvertex_prog.c b/src/mesa/main/ffvertex_prog.c
index 34cc921..537c746 100644
--- a/src/mesa/main/ffvertex_prog.c
+++ b/src/mesa/main/ffvertex_prog.c
@@ -552,8 +552,6 @@ static void emit_dst( struct prog_dst_register *dst,
dst->Index = reg.idx;
/* allow zero as a shorthand for xyzw */
dst->WriteMask = mask ? mask : WRITEMASK_XYZW;
-   dst->CondMask = COND_TR;  /* always pass cond test */
-   dst->CondSwizzle = SWIZZLE_NOOP;
/* Check that bitfield sizes aren't exceeded */
assert(dst->Index == reg.idx);
 }
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index c7ca3dc..a208c05 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -105,7 +105,6 @@ public:
   this->file = file;
   this->index = 0;
   this->writemask = writemask;
-  this->cond_mask = COND_TR;
   this->reladdr = NULL;
}
 
@@ -114,7 +113,6 @@ public:
   this->file = PROGRAM_UNDEFINED;
   this->index = 0;
   this->writemask = 0;
-  this->cond_mask = COND_TR;
   this->reladdr = NULL;
}
 
@@ -123,7 +121,6 @@ public:
gl_register_file file; /**< PROGRAM_* from Mesa */
int index; /**< temporary index, VERT_ATTRIB_*, VARYING_SLOT_*, etc. */
int writemask; /**< Bitfield of WRITEMASK_[XYZW] */
-   GLuint cond_mask:4;
/** Register index should be offset by the integer in this reg. */
src_reg *reladdr;
 };
@@ -144,7 +141,6 @@ dst_reg::dst_reg(src_reg reg)
this->file = reg.file;
this->index = reg.index;
this->writemask = WRITEMASK_XYZW;
-   this->cond_mask = COND_TR;
this->reladdr = reg.reladdr;
 }
 
@@ -159,7 +155,6 @@ public:
src_reg src[3];
/** Pointer to the ir source this tree came from for debugging */
ir_instruction *ir;
-   GLboolean cond_update;
bool saturate;
int sampler; /**< sampler index */
int tex_target; /**< One of TEXTURE_*_INDEX */
@@ -2769,12 +2764,10 @@ get_mesa_program(struct gl_context *ctx,
i = 0;
foreach_in_list(const ir_to_mesa_instruction, inst, ) {
   mesa_inst->Opcode = inst->op;
-  mesa_inst->CondUpdate = inst->cond_update;
   if (inst->saturate)
 mesa_inst->Saturate = GL_TRUE;
   mesa_inst->DstReg.File = inst->dst.file;
   mesa_inst->DstReg.Index = inst->dst.index;
-  mesa_inst->DstReg.CondMask = inst->dst.cond_mask;
   mesa_inst->DstReg.WriteMask = inst->dst.writemask;
   mesa_inst->DstReg.RelAddr = inst->dst.reladdr != NULL;
   mesa_inst->SrcReg[0] = mesa_src_reg_from_ir_src_reg(inst->src[0]);
diff --git a/src/mesa/program/prog_execute.c b/src/mesa/program/prog_execute.c
index 33f52fb..d336c51 100644
--- a/src/mesa/program/prog_execute.c
+++ b/src/mesa/program/prog_execute.c
@@ -329,66 +329,6 @@ fetch_texel(struct gl_context *ctx,
 
 
 /**
- * Test value against zero and return GT, LT, EQ or UN if NaN.
- */
-static inline GLuint
-generate_cc(float value)
-{
-   if (value != value)
-  return COND_UN;   /* NaN */
-   if (value > 0.0F)
-  return COND_GT;
-   if (value < 0.0F)
-  return COND_LT;
-   return COND_EQ;
-}
-
-
-/**
- * Test if the ccMaskRule is satisfied by the given condition code.
- * Used to mask destination writes according to the current condition code.
- */
-static inline GLboolean
-test_cc(GLuint condCode, GLuint ccMaskRule)
-{
-   switch (ccMaskRule) {
-   case COND_EQ: return (condCode == COND_EQ);
-   case COND_NE: return (condCode != COND_EQ);
-   case COND_LT: return (condCode == COND_LT);
-   case COND_GE: return (condCode == COND_GT || condCode == COND_EQ);
-   case COND_LE: return (condCode == COND_LT || condCode == COND_EQ);
-   case COND_GT: return (condCode == COND_GT);
-   case COND_TR: return GL_TRUE;
-   case COND_FL: return GL_FALSE;
-   default:  return GL_TRUE;
-   }
-}
-
-
-/**
- * Evaluate the 4 condition codes against a predicate and return GL_TRUE
- * or GL_FALSE to indicate result.
- */
-static inline GLboolean
-eval_condition(const struct gl_program_machine *machine,
-   const struct prog_instruction *inst)
-{
-   const 

[Mesa-dev] [PATCH 05/15] program: Remove OPCODE_KIL_NV.

[Matt Turner]

---
 src/mesa/drivers/dri/i915/i915_fragprog.c | 20 
 src/mesa/program/ir_to_mesa.cpp   | 13 ++---
 src/mesa/program/prog_execute.c   |  5 -
 src/mesa/program/prog_instruction.c   |  1 -
 src/mesa/program/prog_instruction.h   |  1 -
 src/mesa/program/prog_print.c | 10 --
 src/mesa/program/program_parse.y  |  7 ---
 src/mesa/state_tracker/st_mesa_to_tgsi.c  |  3 ---
 8 files changed, 6 insertions(+), 54 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c 
b/src/mesa/drivers/dri/i915/i915_fragprog.c
index 59d7959..691bae3 100644
--- a/src/mesa/drivers/dri/i915/i915_fragprog.c
+++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
@@ -598,26 +598,6 @@ upload_program(struct i915_fragment_program *p)
  0, src0, T0_TEXKILL);
  break;
 
-  case OPCODE_KIL_NV:
-if (inst->DstReg.CondMask == COND_TR) {
-   tmp = i915_get_utemp(p);
-
-   /* The KIL instruction discards the fragment if any component of
-* the source is < 0.  Emit an immediate operand of {-1}.xywz.
-*/
-   i915_emit_texld(p, get_live_regs(p, inst),
-   tmp, A0_DEST_CHANNEL_ALL,
-   0, /* use a dummy dest reg */
-   negate(swizzle(tmp, ONE, ONE, ONE, ONE),
-  1, 1, 1, 1),
-   T0_TEXKILL);
-} else {
-   p->error = 1;
-   i915_program_error(p, "Unsupported KIL_NV condition code: %d",
-  inst->DstReg.CondMask);
-}
-break;
-
   case OPCODE_LG2:
  src0 = src_vector(p, >SrcReg[0], program);
 
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 6051df1..c7ca3dc 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2112,13 +2112,12 @@ ir_to_mesa_visitor::visit(ir_return *ir)
 void
 ir_to_mesa_visitor::visit(ir_discard *ir)
 {
-   if (ir->condition) {
-  ir->condition->accept(this);
-  this->result.negate = ~this->result.negate;
-  emit(ir, OPCODE_KIL, undef_dst, this->result);
-   } else {
-  emit(ir, OPCODE_KIL_NV);
-   }
+   if (!ir->condition)
+  ir->condition = new(mem_ctx) ir_constant(true);
+
+   ir->condition->accept(this);
+   this->result.negate = ~this->result.negate;
+   emit(ir, OPCODE_KIL, undef_dst, this->result);
 }
 
 void
diff --git a/src/mesa/program/prog_execute.c b/src/mesa/program/prog_execute.c
index 2c52d0d..33f52fb 100644
--- a/src/mesa/program/prog_execute.c
+++ b/src/mesa/program/prog_execute.c
@@ -805,11 +805,6 @@ _mesa_execute_program(struct gl_context * ctx,
   case OPCODE_ENDIF:
  /* nothing */
  break;
-  case OPCODE_KIL_NV:  /* NV_f_p only (conditional) */
- if (eval_condition(machine, inst)) {
-return GL_FALSE;
- }
- break;
   case OPCODE_KIL: /* ARB_f_p only */
  {
 GLfloat a[4];
diff --git a/src/mesa/program/prog_instruction.c 
b/src/mesa/program/prog_instruction.c
index 21ef353..bba6c14 100644
--- a/src/mesa/program/prog_instruction.c
+++ b/src/mesa/program/prog_instruction.c
@@ -154,7 +154,6 @@ static const struct instruction_info InstInfo[MAX_OPCODE] = 
{
{ OPCODE_FRC,"FRC", 1, 1 },
{ OPCODE_IF, "IF",  1, 0 },
{ OPCODE_KIL,"KIL", 1, 0 },
-   { OPCODE_KIL_NV, "KIL_NV",  0, 0 },
{ OPCODE_LG2,"LG2", 1, 1 },
{ OPCODE_LIT,"LIT", 1, 1 },
{ OPCODE_LOG,"LOG", 1, 1 },
diff --git a/src/mesa/program/prog_instruction.h 
b/src/mesa/program/prog_instruction.h
index d839268..b7ebe06 100644
--- a/src/mesa/program/prog_instruction.h
+++ b/src/mesa/program/prog_instruction.h
@@ -166,7 +166,6 @@ enum prog_opcode {
OPCODE_FRC,   /*   XX   2   X X   */
OPCODE_IF,/* opt  */
OPCODE_KIL,   /*X X   */
-   OPCODE_KIL_NV,/*X X   */
OPCODE_LG2,   /*   XX   2   X X   */
OPCODE_LIT,   /*   XX   X   X */
OPCODE_LOG,   /*   XX */
diff --git a/src/mesa/program/prog_print.c b/src/mesa/program/prog_print.c
index 2bc07cb..25684b2 100644
--- a/src/mesa/program/prog_print.c
+++ b/src/mesa/program/prog_print.c
@@ -706,16 +706,6 @@ _mesa_fprint_instruction_opt(FILE *f,
   fprint_src_reg(f, >SrcReg[0], mode, prog);
   fprint_comment(f, inst);
   break;
-   case OPCODE_KIL_NV:
-  fprintf(f, "%s", _mesa_opcode_string(inst->Opcode));
-  fprintf(f, " ");
-  fprintf(f, "%s.%s",
- _mesa_condcode_string(inst->DstReg.CondMask),
- _mesa_swizzle_string(inst->DstReg.CondSwizzle,
-  

Re: [Mesa-dev] [PATCH 5/5] i965/vec4: Propagate swizzles correctly during copy propagation.

[Matt Turner]

On Fri, Feb 26, 2016 at 10:02 PM, Francisco Jerez  wrote:
> This simplifies the code that iterates over the per-component values
> found in the matching copy_entry struct and checks whether the
> register regions that were copied to each component are similar enough
> to be treated as a single (reswizzled) value which can be propagated
> into the current instruction.
>
> Aside from being scattered between opt_copy_propagation(),
> try_copy_propagate(), and try_constant_propagate(), what I found
> terribly confusing about the preexisting logic was that
> opt_copy_propagation() tried to reorder the array of values according
> to the swizzle of the instruction source, which meant one would have
> had to invert the reordering applied at the top level in order to find
> out which component to take from each value (we were just taking the
> i-th component from the i-th value, which is not correct in general).
> The saturate mask was also being swizzled incorrectly.
>
> This consolidates the logic for matching multiple components of a
> copy_entry into a single function which returns the result as a
> regular src_reg on success, as if the copy had been performed with a
> single MOV instruction copying all components of the src_reg into the
> destination.
>
> Fixes several ARB_vertex_program MOV test-cases from:
>  https://cgit.freedesktop.org/~kwg/piglit/log/?h=arb_program

Thanks a ton for fixing this. I tried a few times before to simply
understand how the code worked -- even before I knew there was a bug
-- and each time gave up.

I still don't fully understand the issue. Too much or too little
swizzling. Doesn't matter. Fixes the bug and is a net reduction in
LOC.

Nice work. A few code formatting comments below, but this patch gets an

Acked-by: Matt Turner 

> ---
>  .../drivers/dri/i965/brw_vec4_copy_propagation.cpp | 123 
> ++---
>  1 file changed, 57 insertions(+), 66 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> index b4a150a..fc8b721 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> @@ -85,21 +85,65 @@ is_logic_op(enum opcode opcode)
> opcode == BRW_OPCODE_NOT);
>  }
>
> +/**
> + * Get the origin of a copy as a single register if all components present in
> + * the given readmask originate from the same register and have compatible
> + * regions, otherwise return a BAD_FILE register.
> + */
> +static src_reg
> +get_copy_value(const copy_entry , unsigned readmask)
> +{
> +   unsigned swz[4] = {};
> +   src_reg value;
> +
> +   for (unsigned i = 0; i < 4; i++) {
> +  if (readmask & (1 << i)) {
> + if (entry.value[i]) {
> +src_reg src = *entry.value[i];
> +
> +if (src.file == IMM) {
> +   swz[i] = i;
> +} else {
> +   swz[i] = BRW_GET_SWZ(src.swizzle, i);
> +   /* Overwrite the original swizzle so the src_reg::equals call
> +* below doesn't care about it, the correct swizzle will be
> +* calculated once the swizzles of all components are known.
> +*/
> +   src.swizzle = BRW_SWIZZLE_XYZW;
> +}
> +
> +if (value.file == BAD_FILE)
> +   value = src;
> +
> +else if (!value.equals(src))
> +   return src_reg();

Parentheses required in nested if statements. With that, there's no
need for the blank lines after them.

> +
> + } else {
> +return src_reg();
> + }
> +  }
> +   }
> +
> +   return swizzle(value, brw_compose_swizzle(
> + brw_swizzle_for_mask(readmask),
> + BRW_SWIZZLE4(swz[0], swz[1], swz[2], swz[3])));

Lets wrap this as

   return swizzle(value,
  brw_compose_swizzle(brw_swizzle_for_mask(readmask),
  BRW_SWIZZLE4(swz[0], swz[1],
   swz[2], swz[3])));

(GMail might mess that up, so just align each argument with the open
parenthesis)

> +}
> +
>  static bool
>  try_constant_propagate(const struct brw_device_info *devinfo,
> vec4_instruction *inst,
> -   int arg, struct copy_entry *entry)
> +   int arg, const copy_entry *entry)
>  {
> /* For constant propagation, we only handle the same constant
>  * across all 4 channels.  Some day, we should handle the 8-bit
>  * float vector format, which would let us constant propagate
>  * vectors better.
> +* We could be more aggressive here -- some channels might not get used
> +* based on the destination writemask.
>  */
> -   src_reg value = *entry->value[0];
> -   for (int i = 1; i < 4; i++) {
> -  if (!value.equals(*entry->value[i]))
> -

Re: [Mesa-dev] [PATCH 3/5] i965/vec4: Use swizzle() to swizzle immediates during constant propagation.

[Matt Turner]

On Mon, Feb 29, 2016 at 2:20 PM, Francisco Jerez  wrote:
> Matt Turner  writes:
>
>> On Mon, Feb 29, 2016 at 7:30 AM, Iago Toral  wrote:
>>> On Fri, 2016-02-26 at 22:02 -0800, Francisco Jerez wrote:
 swizzle() works for vector immediates other than VF.
 ---
  .../drivers/dri/i965/brw_vec4_copy_propagation.cpp| 19 
 +--
  1 file changed, 1 insertion(+), 18 deletions(-)

 diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp 
 b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
 index 6bd9928..5c25164 100644
 --- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
 +++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
 @@ -76,22 +76,6 @@ is_channel_updated(vec4_instruction *inst, src_reg 
 *values[4], int ch)
 inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch)));
  }

 -static unsigned
 -swizzle_vf_imm(unsigned vf4, unsigned swizzle)
 -{
 -   union {
 -  unsigned vf4;
 -  uint8_t vf[4];
 -   } v = { vf4 }, ret;
 -
 -   ret.vf[0] = v.vf[BRW_GET_SWZ(swizzle, 0)];
 -   ret.vf[1] = v.vf[BRW_GET_SWZ(swizzle, 1)];
 -   ret.vf[2] = v.vf[BRW_GET_SWZ(swizzle, 2)];
 -   ret.vf[3] = v.vf[BRW_GET_SWZ(swizzle, 3)];
 -
 -   return ret.vf4;
 -}
 -
  static bool
  is_logic_op(enum opcode opcode)
  {
 @@ -144,8 +128,7 @@ try_constant_propagate(const struct brw_device_info 
 *devinfo,
}
 }

 -   if (value.type == BRW_REGISTER_TYPE_VF)
 -  value.ud = swizzle_vf_imm(value.ud, inst->src[arg].swizzle);
 +   value = swizzle(value, inst->src[arg].swizzle);
>>>
>>> so I guess V/UV was broken before this?
>>
>> My question is in the same vein -- what does swizzling V/UV even mean?
>> Swizzles operate on 4-component things, but V/UV have 8 components.
>>
> swizzle() operates on 8-component things 99% of the time.  Its semantics
> are determined by the equivalence of:

Swizzle operates on vec4s. The fact that SIMD8 instructions operate on
2x vec4s doesn't matter as far as I can tell.

This seems analogous to SSE instructions that operate on the top and
bottom halves of a 128-bit register independently. Yes, the
instruction operates on 128-bits, but the operation treats the halves
completely independently.

But all of this is beside the point. I really can't believe we have
these sorts of disagreements.

>
>  OP ..., swizzle(x, swz)
>
> to:
>
>  MOV tmp, x
>  OP ..., tmp.swz
>
> where the MOV has the same execution type and width as the arbitrary
> instruction OP.  With this in mind there are no restrictions on what x
> can be, as long as it can be read from, you just do what the hardware
> does.
>
>> Concretely, for an immediate of 0x1234567UV, what does applying a
>> swizzle of .yxzw do? Does it swap two dwords (each containing two
>> values) and produce 0x34125678UV? Or does it operate on both halves
>> individually and produce 0x21346578UV?
>>
> At the hardware level a swizzle specifies a permutation of 4 which is
> cyclically extended to whatever the vector width is.  So assuming your
> immediate is 0x01234567UV the correct answer is 0x01324576UV.

Sorry, right. I meant 0x01234567UV.

>
>> Moreover, using one of these immediate types requires a W destination,
>
> I don't think that's right.

The IVB PRM (3.3.4 Immediate) says


Restriction: When an immediate vector is used in an instruction, the
destination must be 128-bit aligned with destination horizontal stride
equivalent to a word for an immediate integer vector (v) and
equivalent to a dword for an immediate float vector (vf).

So you could use a byte destination with a stride of 2. But my point
is that you can't use them with a destination type of D/UD.

>
>> which isn't possible in align16 instructions -- so swizzling V/UV
>> seems pointless.
>
> We use V *and* a W destination in Align16 mode in
> gen6_gs_visitor.cpp:617.  Admittedly the instruction looks rather weird
> and I considered replacing it with something else, but there's no harm

Oh, weird. I definitely was not aware of that.

> in swizzle() handling its whole domain consistently, and I didn't feel
> comfortable about leaving this one case unimplemented and letting the
> program crash whenever a V/UV immediate comes up in some optimization
> pass that happens to use swizzle(), which may happen as long as
> something in the vec4 back-end continues using V/UV.

That's fair given that there is an actual use in the vec4 backend.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/6] winsys/radeon: drop support for DRM 2.12.0

[Marek Olšák]

On Thu, Feb 25, 2016 at 3:05 AM, Emil Velikov  wrote:
> On 25 February 2016 at 01:27, Dave Airlie  wrote:
>> On 25 February 2016 at 11:15, Emil Velikov  wrote:
>>> Hi Marek,
>>>
>>> On 24 February 2016 at 23:09, Marek Olšák  wrote:
 From: Marek Olšák 

 in order to make some winsys interface changes easier
>>>
>>> Please add to the commit message the linux kernel version - 3.2.0 .
>>>
>>> Out of curiosity I looked at current kernel versions of currently
>>> supported distros. Here are names that might cause contention points,
>>> although I seriously doubt any of these will use bleeding edge mesa
>>> ;-) Marek feel free to any of it in the commit message.
>>>
>>> Distrokernel  mesaeol
>>> SLES 10   2.6.16  6.4.2   2016-07
>>> SLED 11   3.0 9.0.3   2022-03
>>> RHEL 52.6.18  6.5.1   2017-03
>>> RHEL 62.6.32  10.4.3  2020-11
>>> Debian 6  2.6.32  7.7.1   2016-02
>>
>> At least for RHEL6 we might use latest mesa, but we also backport the
>> kernel drm layer
>> so it supports a newer version.
>>
> Thanks Dave. Bth I'm not sure if I should feel happy or a bit sad,
> considering the serious backporting that will be required.
> You guys are crazy - in a good way :-)
>
> Egbert, can you check with the team if the above would be fine with
> you guys ? [Please say yes, please say yes]
> I take it that you're not planning on doing drm backports ?

They are probably not using old DRM + new mesa. It's a dangerous
combination and I don't think such old DRM supported all of r600g
hardware even and was likely not super stable either.

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

[Mesa-dev] [Bug 94341] Incorrect results with dFdx / dFdy

[bugzilla-daemon]

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

--- Comment #1 from Brian Paul  ---
Are you using the old "swrast" driver?  If so, the derivative functions only
work correctly for some values (the interpolated texcoords, colors, etc.).

If you can switch to the llvmpipe driver you shouldn't have that problem (and
your code should run faster).

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

Re: [Mesa-dev] [PATCH 2/3] svga: add new svga_winsys_context::get_command_buffer_size()

[Brian Paul]

On 02/29/2016 02:52 PM, Charmaine Lee wrote:



From: Brian Paul 
Sent: Monday, February 29, 2016 1:28 PM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee
Subject: [PATCH 2/3] svga: add new 
svga_winsys_context::get_command_buffer_size()



To ask how large the current command buffer is.  Will be used for
a new GALLIUM_HUD graph.
---
src/gallium/drivers/svga/svga_winsys.h| 6 ++
src/gallium/winsys/svga/drm/vmw_context.c | 8 
2 files changed, 14 insertions(+)



diff --git a/src/gallium/drivers/svga/svga_winsys.h 
b/src/gallium/drivers/svga/svga_winsys.h
index 2238d18..7da2c4e 100644
--- a/src/gallium/drivers/svga/svga_winsys.h
+++ b/src/gallium/drivers/svga/svga_winsys.h
@@ -109,6 +109,12 @@ struct svga_winsys_context
  uint32_t nr_bytes, uint32_t nr_relocs );

/**
+* Returns current size of command buffer, in bytes.
+*/
+   unsigned
+   (*get_command_buffer_size)(struct svga_winsys_context *swc);
+
+   /**
 * Emit a relocation for a host surface.
 *
 * @param flags bitmask of SVGA_RELOC_* flags
diff --git a/src/gallium/winsys/svga/drm/vmw_context.c 
b/src/gallium/winsys/svga/drm/vmw_context.c
index dae121e..3944733 100644
--- a/src/gallium/winsys/svga/drm/vmw_context.c
+++ b/src/gallium/winsys/svga/drm/vmw_context.c
@@ -315,6 +315,13 @@ vmw_swc_reserve(struct svga_winsys_context *swc,
return vswc->command.buffer + vswc->command.used;
}

+static unsigned
+vmw_wddm_swc_get_command_buffer_size(struct svga_winsys_context *swc)
+{
+   const struct vmw_svga_winsys_context *vswc = vmw_svga_winsys_context(swc);
+   return vswc->command.used;
+}
+
static void
vmw_swc_context_relocation(struct svga_winsys_context *swc,
   uint32 *cid)
@@ -761,6 +768,7 @@ vmw_svga_winsys_context_create(struct svga_winsys_screen 
*sws)

vswc->base.destroy = vmw_swc_destroy;
vswc->base.reserve = vmw_swc_reserve;
+   vswc->base.get_command_buffer_size = vmw_wddm_swc_get_command_buffer_size;
vswc->base.surface_relocation = vmw_swc_surface_relocation;
vswc->base.region_relocation = vmw_swc_region_relocation;
vswc->base.mob_relocation = vmw_swc_mob_relocation;
--
1.9.1


Rename vmw_wddm_swc_get_command_buffer_size to vmw_swc_get_command_buffer_size.
Other than that, the series looks fine to me.


Copy and paste left-over.  Will fix.  Thanks!

-Brian



Reviewed-by: Charmaine Lee 



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

Re: [Mesa-dev] [PATCH 3/5] i965/vec4: Use swizzle() to swizzle immediates during constant propagation.

[Francisco Jerez]

Matt Turner  writes:

> On Mon, Feb 29, 2016 at 7:30 AM, Iago Toral  wrote:
>> On Fri, 2016-02-26 at 22:02 -0800, Francisco Jerez wrote:
>>> swizzle() works for vector immediates other than VF.
>>> ---
>>>  .../drivers/dri/i965/brw_vec4_copy_propagation.cpp| 19 
>>> +--
>>>  1 file changed, 1 insertion(+), 18 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp 
>>> b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
>>> index 6bd9928..5c25164 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
>>> +++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
>>> @@ -76,22 +76,6 @@ is_channel_updated(vec4_instruction *inst, src_reg 
>>> *values[4], int ch)
>>> inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch)));
>>>  }
>>>
>>> -static unsigned
>>> -swizzle_vf_imm(unsigned vf4, unsigned swizzle)
>>> -{
>>> -   union {
>>> -  unsigned vf4;
>>> -  uint8_t vf[4];
>>> -   } v = { vf4 }, ret;
>>> -
>>> -   ret.vf[0] = v.vf[BRW_GET_SWZ(swizzle, 0)];
>>> -   ret.vf[1] = v.vf[BRW_GET_SWZ(swizzle, 1)];
>>> -   ret.vf[2] = v.vf[BRW_GET_SWZ(swizzle, 2)];
>>> -   ret.vf[3] = v.vf[BRW_GET_SWZ(swizzle, 3)];
>>> -
>>> -   return ret.vf4;
>>> -}
>>> -
>>>  static bool
>>>  is_logic_op(enum opcode opcode)
>>>  {
>>> @@ -144,8 +128,7 @@ try_constant_propagate(const struct brw_device_info 
>>> *devinfo,
>>>}
>>> }
>>>
>>> -   if (value.type == BRW_REGISTER_TYPE_VF)
>>> -  value.ud = swizzle_vf_imm(value.ud, inst->src[arg].swizzle);
>>> +   value = swizzle(value, inst->src[arg].swizzle);
>>
>> so I guess V/UV was broken before this?
>
> My question is in the same vein -- what does swizzling V/UV even mean?
> Swizzles operate on 4-component things, but V/UV have 8 components.
>
swizzle() operates on 8-component things 99% of the time.  Its semantics
are determined by the equivalence of:

 OP ..., swizzle(x, swz)

to:

 MOV tmp, x
 OP ..., tmp.swz

where the MOV has the same execution type and width as the arbitrary
instruction OP.  With this in mind there are no restrictions on what x
can be, as long as it can be read from, you just do what the hardware
does.

> Concretely, for an immediate of 0x1234567UV, what does applying a
> swizzle of .yxzw do? Does it swap two dwords (each containing two
> values) and produce 0x34125678UV? Or does it operate on both halves
> individually and produce 0x21346578UV?
>
At the hardware level a swizzle specifies a permutation of 4 which is
cyclically extended to whatever the vector width is.  So assuming your
immediate is 0x01234567UV the correct answer is 0x01324576UV.

> Moreover, using one of these immediate types requires a W destination,

I don't think that's right.

> which isn't possible in align16 instructions -- so swizzling V/UV
> seems pointless.

We use V *and* a W destination in Align16 mode in
gen6_gs_visitor.cpp:617.  Admittedly the instruction looks rather weird
and I considered replacing it with something else, but there's no harm
in swizzle() handling its whole domain consistently, and I didn't feel
comfortable about leaving this one case unimplemented and letting the
program crash whenever a V/UV immediate comes up in some optimization
pass that happens to use swizzle(), which may happen as long as
something in the vec4 back-end continues using V/UV.

>
> Remove the V/UV code from 2/5 and 3/5?


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

[Mesa-dev] [Bug 94341] Incorrect results with dFdx / dFdy

[bugzilla-daemon]

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

Roland Scheidegger  changed:

   What|Removed |Added

 Attachment #122036|text/plain  |image/png
  mime type||

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

Re: [Mesa-dev] [PATCH 2/3] svga: add new svga_winsys_context::get_command_buffer_size()

[Charmaine Lee]

>From: Brian Paul 
>Sent: Monday, February 29, 2016 1:28 PM
>To: mesa-dev@lists.freedesktop.org
>Cc: Charmaine Lee
>Subject: [PATCH 2/3] svga: add new 
>svga_winsys_context::get_command_buffer_size()

>To ask how large the current command buffer is.  Will be used for
>a new GALLIUM_HUD graph.
>---
> src/gallium/drivers/svga/svga_winsys.h| 6 ++
> src/gallium/winsys/svga/drm/vmw_context.c | 8 
> 2 files changed, 14 insertions(+)

>diff --git a/src/gallium/drivers/svga/svga_winsys.h 
>b/src/gallium/drivers/svga/svga_winsys.h
>index 2238d18..7da2c4e 100644
>--- a/src/gallium/drivers/svga/svga_winsys.h
>+++ b/src/gallium/drivers/svga/svga_winsys.h
>@@ -109,6 +109,12 @@ struct svga_winsys_context
>  uint32_t nr_bytes, uint32_t nr_relocs );
>
>/**
>+* Returns current size of command buffer, in bytes.
>+*/
>+   unsigned
>+   (*get_command_buffer_size)(struct svga_winsys_context *swc);
>+
>+   /**
> * Emit a relocation for a host surface.
> *
> * @param flags bitmask of SVGA_RELOC_* flags
>diff --git a/src/gallium/winsys/svga/drm/vmw_context.c 
>b/src/gallium/winsys/svga/drm/vmw_context.c
>index dae121e..3944733 100644
>--- a/src/gallium/winsys/svga/drm/vmw_context.c
>+++ b/src/gallium/winsys/svga/drm/vmw_context.c
>@@ -315,6 +315,13 @@ vmw_swc_reserve(struct svga_winsys_context *swc,
>return vswc->command.buffer + vswc->command.used;
> }
>
>+static unsigned
>+vmw_wddm_swc_get_command_buffer_size(struct svga_winsys_context *swc)
>+{
>+   const struct vmw_svga_winsys_context *vswc = vmw_svga_winsys_context(swc);
>+   return vswc->command.used;
>+}
>+
> static void
> vmw_swc_context_relocation(struct svga_winsys_context *swc,
>   uint32 *cid)
>@@ -761,6 +768,7 @@ vmw_svga_winsys_context_create(struct svga_winsys_screen 
>*sws)
>
>vswc->base.destroy = vmw_swc_destroy;
>vswc->base.reserve = vmw_swc_reserve;
>+   vswc->base.get_command_buffer_size = vmw_wddm_swc_get_command_buffer_size;
>vswc->base.surface_relocation = vmw_swc_surface_relocation;
>vswc->base.region_relocation = vmw_swc_region_relocation;
>vswc->base.mob_relocation = vmw_swc_mob_relocation;
>--
>1.9.1

Rename vmw_wddm_swc_get_command_buffer_size to vmw_swc_get_command_buffer_size.
Other than that, the series looks fine to me.

Reviewed-by: Charmaine Lee 

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

Re: [Mesa-dev] [PATCH v3 0/6] OpenSWR driver addition

[Roland Scheidegger]

Am 29.02.2016 um 22:07 schrieb Rowley, Timothy O:
> Modest ping: haven’t had any comments on these patches for a few
> days.
Patches look ok to me (for the parts I looked at and commented on).

> I don’t have freedesktop git write privileges, so once the patches
> are cleared it would be great if someone could push them.

I don't think that's going to work. A driver needs to be maintained, and
a complete driver where the maintainer doesn't have commit access sounds
like a bad idea to me. You should probably apply for git access, unless
you can find someone else who wants to work on the driver...

Roland


> 
> Thanks.
> 
> -Tim
> 
>> On Feb 24, 2016, at 9:20 PM, Rowley, Timothy O
>>  wrote:
>> 
>> Updating parts 3 through 6 (1 and 2 are still current) based on
>> review comments.  Since we're only targeting linux at the moment,
>> I've removed the scons build and libgl-gdi changes to simplify the
>> review process.  In the future when we get windows working as well
>> we'll get the scons build system changes ready for review.
>> 
>> Tim Rowley (6): OpenSWR driver OpenSWR rasterizer gallium/auxilary:
>> more __cplusplus exports gallium/target-helpers: add OpenSWR
>> driver mesa/build: add OpenSWR to build gallium/docs - add OpenSWR
>> documentation
>> 
>> configure.ac   |   38 + 
>> m4/ax_cxx_compile_stdcxx.m4|  558 ++ 
>> src/gallium/Makefile.am|6 + 
>> src/gallium/auxiliary/gallivm/lp_bld_flow.h|7 + 
>> src/gallium/auxiliary/gallivm/lp_bld_init.h|7 + 
>> src/gallium/auxiliary/gallivm/lp_bld_sample.h  |6 + 
>> src/gallium/auxiliary/gallivm/lp_bld_tgsi.h|8 + 
>> .../auxiliary/target-helpers/inline_sw_helper.h|   12 +- 
>> src/gallium/auxiliary/util/u_dl.h  |6 + 
>> src/gallium/docs/source/drivers/openswr.rst|   21 + 
>> src/gallium/docs/source/drivers/openswr/faq.rst|  141 + 
>> src/gallium/docs/source/drivers/openswr/knobs.rst  |  114 + 
>> .../docs/source/drivers/openswr/profiling.rst  |   67 + 
>> src/gallium/docs/source/drivers/openswr/usage.rst  |   38 + 
>> src/gallium/drivers/swr/.clang-format  |   64 + 
>> src/gallium/drivers/swr/Makefile.am|   31 + 
>> src/gallium/drivers/swr/Makefile.sources   |   23 + 
>> src/gallium/drivers/swr/Makefile.sources-arch  |  111 + 
>> src/gallium/drivers/swr/avx/Makefile.am|   99 + 
>> src/gallium/drivers/swr/avx2/Makefile.am   |   99 + 
>> .../drivers/swr/rasterizer/common/containers.hpp   |  208 + 
>> .../drivers/swr/rasterizer/common/formats.cpp  | 5469
>>  .../drivers/swr/rasterizer/common/formats.h
>> |  251 + src/gallium/drivers/swr/rasterizer/common/isa.hpp  |  235
>> + src/gallium/drivers/swr/rasterizer/common/os.h |  221 + 
>> .../swr/rasterizer/common/rdtsc_buckets.cpp|  188 + 
>> .../drivers/swr/rasterizer/common/rdtsc_buckets.h  |  229 + 
>> .../swr/rasterizer/common/rdtsc_buckets_shared.h   |  167 + 
>> .../drivers/swr/rasterizer/common/simdintrin.h |  787 +++ 
>> .../drivers/swr/rasterizer/common/swr_assert.cpp   |  238 + 
>> .../drivers/swr/rasterizer/common/swr_assert.h |  109 + 
>> src/gallium/drivers/swr/rasterizer/core/api.cpp| 1511 ++ 
>> src/gallium/drivers/swr/rasterizer/core/api.h  |  500 ++ 
>> src/gallium/drivers/swr/rasterizer/core/arena.cpp  |  166 + 
>> src/gallium/drivers/swr/rasterizer/core/arena.h|   69 + 
>> .../drivers/swr/rasterizer/core/backend.cpp| 1899 +++ 
>> src/gallium/drivers/swr/rasterizer/core/backend.h  |   59 + 
>> src/gallium/drivers/swr/rasterizer/core/blend.h|  318 ++ 
>> src/gallium/drivers/swr/rasterizer/core/clip.cpp   |  201 + 
>> src/gallium/drivers/swr/rasterizer/core/clip.h |  868  
>> src/gallium/drivers/swr/rasterizer/core/context.h  |  495 ++ 
>> .../drivers/swr/rasterizer/core/depthstencil.h |  245 + 
>> src/gallium/drivers/swr/rasterizer/core/fifo.hpp   |  136 + 
>> .../swr/rasterizer/core/format_conversion.h|  196 + 
>> .../drivers/swr/rasterizer/core/format_traits.h| 3548
>> + .../drivers/swr/rasterizer/core/format_types.h |
>> 1075  .../drivers/swr/rasterizer/core/frontend.cpp   | 2345
>> + src/gallium/drivers/swr/rasterizer/core/frontend.h |  327
>> ++ src/gallium/drivers/swr/rasterizer/core/knobs.h|  142 + 
>> .../drivers/swr/rasterizer/core/knobs_init.h   |   98 + 
>> .../drivers/swr/rasterizer/core/multisample.cpp|   51 + 
>> .../drivers/swr/rasterizer/core/multisample.h  |  620 +++ 
>> src/gallium/drivers/swr/rasterizer/core/pa.h   | 1208 + 
>> src/gallium/drivers/swr/rasterizer/core/pa_avx.cpp | 1177 + 
>> .../drivers/swr/rasterizer/core/rasterizer.cpp | 1393 + 
>> .../drivers/swr/rasterizer/core/rasterizer.h   |   35 + 
>> .../drivers/swr/rasterizer/core/rdtsc_core.cpp  

[Mesa-dev] [PATCH 3/3] svga: add new command-buffer-size HUD query

[Brian Paul]

To plot a graph of the command buffer size.
---
 src/gallium/drivers/svga/svga_context.c|  3 +++
 src/gallium/drivers/svga/svga_context.h| 16 +---
 src/gallium/drivers/svga/svga_pipe_query.c |  9 +
 src/gallium/drivers/svga/svga_screen.c |  2 ++
 4 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_context.c 
b/src/gallium/drivers/svga/svga_context.c
index 53971bc..48fbd4e 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -308,6 +308,9 @@ void svga_context_flush( struct svga_context *svga,
 */
svga_context_flush_buffers(svga);
 
+   svga->hud.command_buffer_size +=
+  svga->swc->get_command_buffer_size(svga->swc);
+
/* Flush pending commands to hardware:
 */
svga->swc->flush(svga->swc, );
diff --git a/src/gallium/drivers/svga/svga_context.h 
b/src/gallium/drivers/svga/svga_context.h
index f1a2041..2a1ad14 100644
--- a/src/gallium/drivers/svga/svga_context.h
+++ b/src/gallium/drivers/svga/svga_context.h
@@ -52,16 +52,17 @@
 #define SVGA_QUERY_MAP_BUFFER_TIME (PIPE_QUERY_DRIVER_SPECIFIC + 4)
 #define SVGA_QUERY_NUM_RESOURCES_MAPPED(PIPE_QUERY_DRIVER_SPECIFIC + 5)
 #define SVGA_QUERY_NUM_BYTES_UPLOADED  (PIPE_QUERY_DRIVER_SPECIFIC + 6)
+#define SVGA_QUERY_COMMAND_BUFFER_SIZE (PIPE_QUERY_DRIVER_SPECIFIC + 7)
 
 /* running total counters */
-#define SVGA_QUERY_MEMORY_USED (PIPE_QUERY_DRIVER_SPECIFIC + 7)
-#define SVGA_QUERY_NUM_SHADERS (PIPE_QUERY_DRIVER_SPECIFIC + 8)
-#define SVGA_QUERY_NUM_RESOURCES   (PIPE_QUERY_DRIVER_SPECIFIC + 9)
-#define SVGA_QUERY_NUM_STATE_OBJECTS   (PIPE_QUERY_DRIVER_SPECIFIC + 10)
-#define SVGA_QUERY_NUM_SURFACE_VIEWS   (PIPE_QUERY_DRIVER_SPECIFIC + 11)
-#define SVGA_QUERY_NUM_GENERATE_MIPMAP (PIPE_QUERY_DRIVER_SPECIFIC + 12)
+#define SVGA_QUERY_MEMORY_USED (PIPE_QUERY_DRIVER_SPECIFIC + 8)
+#define SVGA_QUERY_NUM_SHADERS (PIPE_QUERY_DRIVER_SPECIFIC + 9)
+#define SVGA_QUERY_NUM_RESOURCES   (PIPE_QUERY_DRIVER_SPECIFIC + 10)
+#define SVGA_QUERY_NUM_STATE_OBJECTS   (PIPE_QUERY_DRIVER_SPECIFIC + 11)
+#define SVGA_QUERY_NUM_SURFACE_VIEWS   (PIPE_QUERY_DRIVER_SPECIFIC + 12)
+#define SVGA_QUERY_NUM_GENERATE_MIPMAP (PIPE_QUERY_DRIVER_SPECIFIC + 13)
 /*SVGA_QUERY_MAX has to be last because it is size of an array*/
-#define SVGA_QUERY_MAX (PIPE_QUERY_DRIVER_SPECIFIC + 13)
+#define SVGA_QUERY_MAX (PIPE_QUERY_DRIVER_SPECIFIC + 14)
 
 /**
  * Maximum supported number of constant buffers per shader
@@ -502,6 +503,7 @@ struct svga_context
   uint64_t num_validations;  /**< SVGA_QUERY_NUM_VALIDATIONS */
   uint64_t map_buffer_time;  /**< SVGA_QUERY_MAP_BUFFER_TIME */
   uint64_t num_resources_mapped; /**< SVGA_QUERY_NUM_RESOURCES_MAPPED */
+  uint64_t command_buffer_size;  /**< SVGA_QUERY_COMMAND_BUFFER_SIZE */
   uint64_t num_shaders;  /**< SVGA_QUERY_NUM_SHADERS */
   uint64_t num_state_objects;/**< SVGA_QUERY_NUM_STATE_OBJECTS */
   uint64_t num_surface_views;/**< SVGA_QUERY_NUM_SURFACE_VIEWS */
diff --git a/src/gallium/drivers/svga/svga_pipe_query.c 
b/src/gallium/drivers/svga/svga_pipe_query.c
index 1427314..8037fec 100644
--- a/src/gallium/drivers/svga/svga_pipe_query.c
+++ b/src/gallium/drivers/svga/svga_pipe_query.c
@@ -730,6 +730,7 @@ svga_create_query(struct pipe_context *pipe,
case SVGA_QUERY_MAP_BUFFER_TIME:
case SVGA_QUERY_NUM_RESOURCES_MAPPED:
case SVGA_QUERY_NUM_BYTES_UPLOADED:
+   case SVGA_QUERY_COMMAND_BUFFER_SIZE:
case SVGA_QUERY_MEMORY_USED:
case SVGA_QUERY_NUM_SHADERS:
case SVGA_QUERY_NUM_RESOURCES:
@@ -799,6 +800,7 @@ svga_destroy_query(struct pipe_context *pipe, struct 
pipe_query *q)
case SVGA_QUERY_MAP_BUFFER_TIME:
case SVGA_QUERY_NUM_RESOURCES_MAPPED:
case SVGA_QUERY_NUM_BYTES_UPLOADED:
+   case SVGA_QUERY_COMMAND_BUFFER_SIZE:
case SVGA_QUERY_MEMORY_USED:
case SVGA_QUERY_NUM_SHADERS:
case SVGA_QUERY_NUM_RESOURCES:
@@ -887,6 +889,9 @@ svga_begin_query(struct pipe_context *pipe, struct 
pipe_query *q)
case SVGA_QUERY_NUM_BYTES_UPLOADED:
   sq->begin_count = svga->hud.num_bytes_uploaded;
   break;
+   case SVGA_QUERY_COMMAND_BUFFER_SIZE:
+  sq->begin_count = svga->hud.command_buffer_size;
+  break;
case SVGA_QUERY_MEMORY_USED:
case SVGA_QUERY_NUM_SHADERS:
case SVGA_QUERY_NUM_RESOURCES:
@@ -981,6 +986,9 @@ svga_end_query(struct pipe_context *pipe, struct pipe_query 
*q)
case SVGA_QUERY_NUM_BYTES_UPLOADED:
   sq->end_count = svga->hud.num_bytes_uploaded;
   break;
+   case SVGA_QUERY_COMMAND_BUFFER_SIZE:
+  sq->end_count = svga->hud.command_buffer_size;
+  break;
case SVGA_QUERY_MEMORY_USED:
case SVGA_QUERY_NUM_SHADERS:
case SVGA_QUERY_NUM_RESOURCES:
@@ -1079,6 +1087,7 @@ svga_get_query_result(struct pipe_context *pipe,

[Mesa-dev] [PATCH 2/3] svga: add new svga_winsys_context::get_command_buffer_size()

[Brian Paul]

To ask how large the current command buffer is.  Will be used for
a new GALLIUM_HUD graph.
---
 src/gallium/drivers/svga/svga_winsys.h| 6 ++
 src/gallium/winsys/svga/drm/vmw_context.c | 8 
 2 files changed, 14 insertions(+)

diff --git a/src/gallium/drivers/svga/svga_winsys.h 
b/src/gallium/drivers/svga/svga_winsys.h
index 2238d18..7da2c4e 100644
--- a/src/gallium/drivers/svga/svga_winsys.h
+++ b/src/gallium/drivers/svga/svga_winsys.h
@@ -109,6 +109,12 @@ struct svga_winsys_context
  uint32_t nr_bytes, uint32_t nr_relocs );

/**
+* Returns current size of command buffer, in bytes.
+*/
+   unsigned
+   (*get_command_buffer_size)(struct svga_winsys_context *swc);
+
+   /**
 * Emit a relocation for a host surface.
 * 
 * @param flags bitmask of SVGA_RELOC_* flags
diff --git a/src/gallium/winsys/svga/drm/vmw_context.c 
b/src/gallium/winsys/svga/drm/vmw_context.c
index dae121e..3944733 100644
--- a/src/gallium/winsys/svga/drm/vmw_context.c
+++ b/src/gallium/winsys/svga/drm/vmw_context.c
@@ -315,6 +315,13 @@ vmw_swc_reserve(struct svga_winsys_context *swc,
return vswc->command.buffer + vswc->command.used;
 }
 
+static unsigned
+vmw_wddm_swc_get_command_buffer_size(struct svga_winsys_context *swc)
+{
+   const struct vmw_svga_winsys_context *vswc = vmw_svga_winsys_context(swc);
+   return vswc->command.used;
+}
+
 static void
 vmw_swc_context_relocation(struct svga_winsys_context *swc,
   uint32 *cid)
@@ -761,6 +768,7 @@ vmw_svga_winsys_context_create(struct svga_winsys_screen 
*sws)
 
vswc->base.destroy = vmw_swc_destroy;
vswc->base.reserve = vmw_swc_reserve;
+   vswc->base.get_command_buffer_size = vmw_wddm_swc_get_command_buffer_size;
vswc->base.surface_relocation = vmw_swc_surface_relocation;
vswc->base.region_relocation = vmw_swc_region_relocation;
vswc->base.mob_relocation = vmw_swc_mob_relocation;
-- 
1.9.1

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

[Mesa-dev] [PATCH 1/3] svga: reorder SVGA_QUERY_ switch cases to match declaration order

[Brian Paul]

---
 src/gallium/drivers/svga/svga_pipe_query.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_pipe_query.c 
b/src/gallium/drivers/svga/svga_pipe_query.c
index ebf4c6a..1427314 100644
--- a/src/gallium/drivers/svga/svga_pipe_query.c
+++ b/src/gallium/drivers/svga/svga_pipe_query.c
@@ -726,15 +726,15 @@ svga_create_query(struct pipe_context *pipe,
case SVGA_QUERY_NUM_DRAW_CALLS:
case SVGA_QUERY_NUM_FALLBACKS:
case SVGA_QUERY_NUM_FLUSHES:
+   case SVGA_QUERY_NUM_VALIDATIONS:
+   case SVGA_QUERY_MAP_BUFFER_TIME:
+   case SVGA_QUERY_NUM_RESOURCES_MAPPED:
+   case SVGA_QUERY_NUM_BYTES_UPLOADED:
case SVGA_QUERY_MEMORY_USED:
case SVGA_QUERY_NUM_SHADERS:
case SVGA_QUERY_NUM_RESOURCES:
case SVGA_QUERY_NUM_STATE_OBJECTS:
-   case SVGA_QUERY_NUM_VALIDATIONS:
-   case SVGA_QUERY_MAP_BUFFER_TIME:
case SVGA_QUERY_NUM_SURFACE_VIEWS:
-   case SVGA_QUERY_NUM_RESOURCES_MAPPED:
-   case SVGA_QUERY_NUM_BYTES_UPLOADED:
case SVGA_QUERY_NUM_GENERATE_MIPMAP:
   break;
default:
@@ -795,15 +795,15 @@ svga_destroy_query(struct pipe_context *pipe, struct 
pipe_query *q)
case SVGA_QUERY_NUM_DRAW_CALLS:
case SVGA_QUERY_NUM_FALLBACKS:
case SVGA_QUERY_NUM_FLUSHES:
+   case SVGA_QUERY_NUM_VALIDATIONS:
+   case SVGA_QUERY_MAP_BUFFER_TIME:
+   case SVGA_QUERY_NUM_RESOURCES_MAPPED:
+   case SVGA_QUERY_NUM_BYTES_UPLOADED:
case SVGA_QUERY_MEMORY_USED:
case SVGA_QUERY_NUM_SHADERS:
case SVGA_QUERY_NUM_RESOURCES:
case SVGA_QUERY_NUM_STATE_OBJECTS:
-   case SVGA_QUERY_NUM_VALIDATIONS:
-   case SVGA_QUERY_MAP_BUFFER_TIME:
case SVGA_QUERY_NUM_SURFACE_VIEWS:
-   case SVGA_QUERY_NUM_RESOURCES_MAPPED:
-   case SVGA_QUERY_NUM_BYTES_UPLOADED:
case SVGA_QUERY_NUM_GENERATE_MIPMAP:
   /* nothing */
   break;
@@ -1076,9 +1076,9 @@ svga_get_query_result(struct pipe_context *pipe,
case SVGA_QUERY_NUM_FALLBACKS:
case SVGA_QUERY_NUM_FLUSHES:
case SVGA_QUERY_NUM_VALIDATIONS:
+   case SVGA_QUERY_MAP_BUFFER_TIME:
case SVGA_QUERY_NUM_RESOURCES_MAPPED:
case SVGA_QUERY_NUM_BYTES_UPLOADED:
-   case SVGA_QUERY_MAP_BUFFER_TIME:
   vresult->u64 = sq->end_count - sq->begin_count;
   break;
/* These are running total counters */
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH v3 0/6] OpenSWR driver addition

[Rowley, Timothy O]

Modest ping: haven’t had any comments on these patches for a few days.

I don’t have freedesktop git write privileges, so once the patches are cleared 
it would be great if someone could push them.

Thanks.

-Tim

> On Feb 24, 2016, at 9:20 PM, Rowley, Timothy O  
> wrote:
> 
> Updating parts 3 through 6 (1 and 2 are still current) based on review
> comments.  Since we're only targeting linux at the moment, I've
> removed the scons build and libgl-gdi changes to simplify the review
> process.  In the future when we get windows working as well we'll get
> the scons build system changes ready for review.
> 
> Tim Rowley (6):
>  OpenSWR driver
>  OpenSWR rasterizer
>  gallium/auxilary: more __cplusplus exports
>  gallium/target-helpers: add OpenSWR driver
>  mesa/build: add OpenSWR to build
>  gallium/docs - add OpenSWR documentation
> 
> configure.ac   |   38 +
> m4/ax_cxx_compile_stdcxx.m4|  558 ++
> src/gallium/Makefile.am|6 +
> src/gallium/auxiliary/gallivm/lp_bld_flow.h|7 +
> src/gallium/auxiliary/gallivm/lp_bld_init.h|7 +
> src/gallium/auxiliary/gallivm/lp_bld_sample.h  |6 +
> src/gallium/auxiliary/gallivm/lp_bld_tgsi.h|8 +
> .../auxiliary/target-helpers/inline_sw_helper.h|   12 +-
> src/gallium/auxiliary/util/u_dl.h  |6 +
> src/gallium/docs/source/drivers/openswr.rst|   21 +
> src/gallium/docs/source/drivers/openswr/faq.rst|  141 +
> src/gallium/docs/source/drivers/openswr/knobs.rst  |  114 +
> .../docs/source/drivers/openswr/profiling.rst  |   67 +
> src/gallium/docs/source/drivers/openswr/usage.rst  |   38 +
> src/gallium/drivers/swr/.clang-format  |   64 +
> src/gallium/drivers/swr/Makefile.am|   31 +
> src/gallium/drivers/swr/Makefile.sources   |   23 +
> src/gallium/drivers/swr/Makefile.sources-arch  |  111 +
> src/gallium/drivers/swr/avx/Makefile.am|   99 +
> src/gallium/drivers/swr/avx2/Makefile.am   |   99 +
> .../drivers/swr/rasterizer/common/containers.hpp   |  208 +
> .../drivers/swr/rasterizer/common/formats.cpp  | 5469 
> .../drivers/swr/rasterizer/common/formats.h|  251 +
> src/gallium/drivers/swr/rasterizer/common/isa.hpp  |  235 +
> src/gallium/drivers/swr/rasterizer/common/os.h |  221 +
> .../swr/rasterizer/common/rdtsc_buckets.cpp|  188 +
> .../drivers/swr/rasterizer/common/rdtsc_buckets.h  |  229 +
> .../swr/rasterizer/common/rdtsc_buckets_shared.h   |  167 +
> .../drivers/swr/rasterizer/common/simdintrin.h |  787 +++
> .../drivers/swr/rasterizer/common/swr_assert.cpp   |  238 +
> .../drivers/swr/rasterizer/common/swr_assert.h |  109 +
> src/gallium/drivers/swr/rasterizer/core/api.cpp| 1511 ++
> src/gallium/drivers/swr/rasterizer/core/api.h  |  500 ++
> src/gallium/drivers/swr/rasterizer/core/arena.cpp  |  166 +
> src/gallium/drivers/swr/rasterizer/core/arena.h|   69 +
> .../drivers/swr/rasterizer/core/backend.cpp| 1899 +++
> src/gallium/drivers/swr/rasterizer/core/backend.h  |   59 +
> src/gallium/drivers/swr/rasterizer/core/blend.h|  318 ++
> src/gallium/drivers/swr/rasterizer/core/clip.cpp   |  201 +
> src/gallium/drivers/swr/rasterizer/core/clip.h |  868 
> src/gallium/drivers/swr/rasterizer/core/context.h  |  495 ++
> .../drivers/swr/rasterizer/core/depthstencil.h |  245 +
> src/gallium/drivers/swr/rasterizer/core/fifo.hpp   |  136 +
> .../swr/rasterizer/core/format_conversion.h|  196 +
> .../drivers/swr/rasterizer/core/format_traits.h| 3548 +
> .../drivers/swr/rasterizer/core/format_types.h | 1075 
> .../drivers/swr/rasterizer/core/frontend.cpp   | 2345 +
> src/gallium/drivers/swr/rasterizer/core/frontend.h |  327 ++
> src/gallium/drivers/swr/rasterizer/core/knobs.h|  142 +
> .../drivers/swr/rasterizer/core/knobs_init.h   |   98 +
> .../drivers/swr/rasterizer/core/multisample.cpp|   51 +
> .../drivers/swr/rasterizer/core/multisample.h  |  620 +++
> src/gallium/drivers/swr/rasterizer/core/pa.h   | 1208 +
> src/gallium/drivers/swr/rasterizer/core/pa_avx.cpp | 1177 +
> .../drivers/swr/rasterizer/core/rasterizer.cpp | 1393 +
> .../drivers/swr/rasterizer/core/rasterizer.h   |   35 +
> .../drivers/swr/rasterizer/core/rdtsc_core.cpp |   91 +
> .../drivers/swr/rasterizer/core/rdtsc_core.h   |  177 +
> src/gallium/drivers/swr/rasterizer/core/state.h| 1027 
> .../drivers/swr/rasterizer/core/tessellator.h  |   88 +
> .../drivers/swr/rasterizer/core/threads.cpp|  962 
> src/gallium/drivers/swr/rasterizer/core/threads.h  |   63 +
> .../drivers/swr/rasterizer/core/tilemgr.cpp|  105 +
> src/gallium/drivers/swr/rasterizer/core/tilemgr.h  |  390 ++
> src/gallium/drivers/swr/rasterizer/core/utils.cpp  |  148 +
> 

[Mesa-dev] [PATCH v2 3/3] gk110/ir: add missing src predicate emission for BAR.RED

[Samuel Pitoiset]

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index 46caa3c..facef1d 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -1299,6 +1299,14 @@ CodeEmitterGK110::emitBAR(const Instruction *i)
   code[1] |= imm->reg.data.u32 >> 9;
   code[1] |= 0x4000;
}
+
+   if (i->srcExists(2) && (i->predSrc != 2)) {
+  srcId(i->src(2), 32 + 10);
+  if (i->src(2).mod == Modifier(NV50_IR_MOD_NOT))
+ code[1] |= 1 << 13;
+   } else {
+  code[1] |= 7 << 10;
+   }
 }
 
 void CodeEmitterGK110::emitMEMBAR(const Instruction *i)
-- 
2.7.1

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

[Mesa-dev] [PATCH v2 2/3] gk110/ir: allow to emit immediates for BAR

[Samuel Pitoiset]

Signed-off-by: Samuel Pitoiset 
---
 .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index 21138b1..46caa3c 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -1279,8 +1279,26 @@ CodeEmitterGK110::emitBAR(const Instruction *i)
 
emitPredicate(i);
 
-   srcId(i->src(0), 10);
-   srcId(i->src(1), 23);
+   // barrier id
+   if (i->src(0).getFile() == FILE_GPR) {
+  srcId(i->src(0), 10);
+   } else {
+  ImmediateValue *imm = i->getSrc(0)->asImm();
+  assert(imm);
+  code[0] |= imm->reg.data.u32 << 10;
+  code[1] |= 0x8000;
+   }
+
+   // thread count
+   if (i->src(1).getFile() == FILE_GPR) {
+  srcId(i->src(1), 23);
+   } else {
+  ImmediateValue *imm = i->getSrc(0)->asImm();
+  assert(imm);
+  code[0] |= imm->reg.data.u32 << 23;
+  code[1] |= imm->reg.data.u32 >> 9;
+  code[1] |= 0x4000;
+   }
 }
 
 void CodeEmitterGK110::emitMEMBAR(const Instruction *i)
-- 
2.7.1

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

[Mesa-dev] [PATCH v2 1/3] gk110/ir: fix wrong emission of BAR.SYNC

[Samuel Pitoiset]

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index b6b3ec7..21138b1 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -1273,7 +1273,6 @@ CodeEmitterGK110::emitBAR(const Instruction *i)
case NV50_IR_SUBOP_BAR_RED_OR:   code[1] |= 0x90; break;
case NV50_IR_SUBOP_BAR_RED_POPC: code[1] |= 0x10; break;
default:
-  code[1] |= 0x20;
   assert(i->subOp == NV50_IR_SUBOP_BAR_SYNC);
   break;
}
-- 
2.7.1

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

[Mesa-dev] [Bug 94341] Incorrect results with dFdx / dFdy

[bugzilla-daemon]

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

Bug ID: 94341
   Summary: Incorrect results with dFdx / dFdy
   Product: Mesa
   Version: 11.1
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: ik...@box.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 122036
  --> https://bugs.freedesktop.org/attachment.cgi?id=122036=edit
Correct result (left) and incorrect result (right)

Context: I am using Chrome and osmesa to perform "headless" WebGL rendering.
Many of the Three.js examples (http://threejs.org/examples/) do not render
correctly. I think I have narrowed the problem down to incorrect results
produced by dFdx / dFdy. Three.js uses these functions for several things
including: flat-shading and bump / normal mapping.

I have created a JSFiddle that demonstrates the problem:

https://jsfiddle.net/iangkerr/08x72ge9/

The fiddle renders two triangles, rotated 45 degrees, with a perspective
projection. The fragment shader attempts to compute the surface normal and
assigns the result to gl_FragColor. I expect a purplish colour, due to the
normal having positive X and Z components (R and B), and I get this result on
my Mac. However, when running Chrome + osmesa on Ubuntu, I get a bluish colour
(positive Z component). I have attached a screenshot of the correct result and
the incorrect result.

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

Re: [Mesa-dev] [PATCH v7 0/7] add clLinkProgram

[Francisco Jerez]

Serge Martin  writes:

> Ping
>
Thanks for trying to split some of the LLVM interfacing changes into
separate patches.  I'm about 80% done cleaning up the mess that
llvm/invocation.cpp is, I'll take care of rebasing your series and pong
you once I'm done.  Unfortunately the core/api changes from this series
are too tightly coupled to the llvm stuff to land any of it in the
meantime (except maybe PATCH 5).

> On Saturday 13 February 2016 23:08:34 Serge Martin wrote:
>> This serie add clLinkProgram function needed for CL 1.2.
>> However, it lacks the binary type part that is mandatory for input
>> validation and also for CL_PROGRAM_BINARY_TYPE query. This will be adressed
>> in another serie once we agree on the way to store it.
>> 
>> Serge Martin (7):
>>   clover: add a LLVM compiler class
>>   clover: make use of llvm_ir_compiler
>>   clover: program::build change opts to std::string
>>   clover: separate compilation and link stages
>>   clover: override ret_object
>>   clover: add clLinkProgram (CL 1.2)
>>   clover: add -create-library option support
>> 
>>  src/gallium/state_trackers/clover/Makefile.sources |   3 +-
>>  src/gallium/state_trackers/clover/api/program.cpp  |  50 ++-
>>  src/gallium/state_trackers/clover/api/util.hpp |  12 +
>>  .../state_trackers/clover/core/compiler.hpp|   7 +-
>>  src/gallium/state_trackers/clover/core/error.hpp   |   7 +
>>  src/gallium/state_trackers/clover/core/program.cpp |  40 ++-
>>  src/gallium/state_trackers/clover/core/program.hpp |  10 +-
>>  .../state_trackers/clover/llvm/invocation.cpp  | 345
>> +++-- .../state_trackers/clover/llvm/ir_compiler.cpp |
>> 337  .../state_trackers/clover/llvm/ir_compiler.hpp
>> |  65 
>>  10 files changed, 619 insertions(+), 257 deletions(-)
>>  create mode 100644 src/gallium/state_trackers/clover/llvm/ir_compiler.cpp
>>  create mode 100644 src/gallium/state_trackers/clover/llvm/ir_compiler.hpp
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 01/26] docs: git tips

[Marek Olšák]

On Mon, Feb 29, 2016 at 2:17 AM, Timothy Arceri
 wrote:
> From: Timothy Arceri 
>
> ---
>  docs/devinfo.html | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/docs/devinfo.html b/docs/devinfo.html
> index 8ebf80f..ed9eb9b 100644
> --- a/docs/devinfo.html
> +++ b/docs/devinfo.html
> @@ -162,6 +162,24 @@ components.
>  perhaps, in very trivial cases.)
>  
>
> +Git Tips
> +
> +
> +Test for build breakage between patches e.g last 8 commits.
> +
> +git rebase -i --exec="make -j4" HEAD~8
> +
> +Sets the default mailing address for your repo.
> +
> +git config --local sendemail.to mesa-dev@lists.freedesktop.org

This is what I have in ~/.gitconfig:

[sendemail]
...
# don't cc addresses in commit messages
suppresscc = all
...
[alias]
# nice short log looking like the cgit web, type "git l"
# (this should be one line - silly gmail wrapping)
l = log --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold cyan)<%an>%Creset'

# e.g. type "git send-mesa -5" to send top 5 commits to mesa-dev
send-mesa = send-email --to=mesa-dev@lists.freedesktop.org
send-piglit = send-email --to=pig...@lists.freedesktop.org
send-dri = send-email --to=dri-de...@lists.freedesktop.org
send-llvm = send-email --to=llvm-comm...@lists.llvm.org
[push]
# push the current branch to its upstream branch, but refuse to
# push if the upstream branch’s name is different from the local one
default = simple
[rebase]
# add --stat to rebase and pull --rebase
stat = true
[branch]
# git pull on new branches will always do rebase
autosetuprebase = always
[branch "master"]
# for master: always do pull --rebase, applies to existing branches as well
rebase = true

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

Re: [Mesa-dev] [PATCH 01/26] docs: git tips

[Matt Turner]

On Mon, Feb 29, 2016 at 8:13 AM, Emil Velikov  wrote:
> On 29 February 2016 at 01:17, Timothy Arceri
>  wrote:
>> From: Timothy Arceri 
>>
>> ---
>>  docs/devinfo.html | 18 ++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/docs/devinfo.html b/docs/devinfo.html
>> index 8ebf80f..ed9eb9b 100644
>> --- a/docs/devinfo.html
>> +++ b/docs/devinfo.html
>> @@ -162,6 +162,24 @@ components.
>>  perhaps, in very trivial cases.)
>>  
>>
>> +Git Tips
>> +
>> +
>> +Test for build breakage between patches e.g last 8 commits.
>> +
>> +git rebase -i --exec="make -j4" HEAD~8
>> +
>> +Sets the default mailing address for your repo.
>> +
>> +git config --local sendemail.to mesa-dev@lists.freedesktop.org
>> +
>> + Add version to subject line of patch series in this case for the last 8
>> +commits before sending.
>> +
>> +git send-email --subject-prefix="PATCH v4" HEAD~8
>
> Fwiw some of us tend to use the shorter version:
>
> $ git send-email -v4 -8
>
> Whether we want it or not I prefer if others decise.

Since I didn't know either of those arguments, and Ken just replied
and suggested one but not the other, it seems valuable to note them
instead :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: Initialize gl_shader_program::EmptyUniformLocations.

[Matt Turner]

Commit 65dfb30 added exec_list EmptyUniformLocations, but only
initialized the list if ARB_explicit_uniform_location was enabled,
leading to crashes if the extension was not available.

Cc: "11.2" 
---
 src/compiler/glsl/linker.cpp | 1 -
 src/mesa/main/shaderobj.c| 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 5326bfd..3039232 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -3180,7 +3180,6 @@ check_explicit_uniform_locations(struct gl_context *ctx,
   }
}
 
-   exec_list_make_empty(>EmptyUniformLocations);
struct empty_uniform_block *current_block = NULL;
 
for (unsigned i = 0; i < prog->NumUniformRemapTable; i++) {
diff --git a/src/mesa/main/shaderobj.c b/src/mesa/main/shaderobj.c
index 203ccef..9a4eb6b 100644
--- a/src/mesa/main/shaderobj.c
+++ b/src/mesa/main/shaderobj.c
@@ -240,6 +240,8 @@ init_shader_program(struct gl_shader_program *prog)
 
prog->TransformFeedback.BufferMode = GL_INTERLEAVED_ATTRIBS;
 
+   exec_list_make_empty(>EmptyUniformLocations);
+
prog->InfoLog = ralloc_strdup(prog, "");
 }
 
-- 
2.4.10

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

Re: [Mesa-dev] [PATCH 3/5] i965/vec4: Use swizzle() to swizzle immediates during constant propagation.

[Matt Turner]

On Mon, Feb 29, 2016 at 7:30 AM, Iago Toral  wrote:
> On Fri, 2016-02-26 at 22:02 -0800, Francisco Jerez wrote:
>> swizzle() works for vector immediates other than VF.
>> ---
>>  .../drivers/dri/i965/brw_vec4_copy_propagation.cpp| 19 
>> +--
>>  1 file changed, 1 insertion(+), 18 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp 
>> b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
>> index 6bd9928..5c25164 100644
>> --- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
>> @@ -76,22 +76,6 @@ is_channel_updated(vec4_instruction *inst, src_reg 
>> *values[4], int ch)
>> inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch)));
>>  }
>>
>> -static unsigned
>> -swizzle_vf_imm(unsigned vf4, unsigned swizzle)
>> -{
>> -   union {
>> -  unsigned vf4;
>> -  uint8_t vf[4];
>> -   } v = { vf4 }, ret;
>> -
>> -   ret.vf[0] = v.vf[BRW_GET_SWZ(swizzle, 0)];
>> -   ret.vf[1] = v.vf[BRW_GET_SWZ(swizzle, 1)];
>> -   ret.vf[2] = v.vf[BRW_GET_SWZ(swizzle, 2)];
>> -   ret.vf[3] = v.vf[BRW_GET_SWZ(swizzle, 3)];
>> -
>> -   return ret.vf4;
>> -}
>> -
>>  static bool
>>  is_logic_op(enum opcode opcode)
>>  {
>> @@ -144,8 +128,7 @@ try_constant_propagate(const struct brw_device_info 
>> *devinfo,
>>}
>> }
>>
>> -   if (value.type == BRW_REGISTER_TYPE_VF)
>> -  value.ud = swizzle_vf_imm(value.ud, inst->src[arg].swizzle);
>> +   value = swizzle(value, inst->src[arg].swizzle);
>
> so I guess V/UV was broken before this?

My question is in the same vein -- what does swizzling V/UV even mean?
Swizzles operate on 4-component things, but V/UV have 8 components.

Concretely, for an immediate of 0x1234567UV, what does applying a
swizzle of .yxzw do? Does it swap two dwords (each containing two
values) and produce 0x34125678UV? Or does it operate on both halves
individually and produce 0x21346578UV?

Moreover, using one of these immediate types requires a W destination,
which isn't possible in align16 instructions -- so swizzling V/UV
seems pointless.

Remove the V/UV code from 2/5 and 3/5?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/26] docs: git tips

[Kenneth Graunke]

On Monday, February 29, 2016 12:17:41 PM PST Timothy Arceri wrote:
> From: Timothy Arceri 
> 
> ---
>  docs/devinfo.html | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/docs/devinfo.html b/docs/devinfo.html
> index 8ebf80f..ed9eb9b 100644
> --- a/docs/devinfo.html
> +++ b/docs/devinfo.html
> @@ -162,6 +162,24 @@ components.
>  perhaps, in very trivial cases.)
>  
>  
> +Git Tips
> +
> +
> +Test for build breakage between patches e.g last 8 commits.
> +
> +git rebase -i --exec="make -j4" HEAD~8
> +
> +Sets the default mailing address for your repo.
> +
> +git config --local sendemail.to mesa-dev@lists.freedesktop.org
> +
> + Add version to subject line of patch series in this case for the last 
8
> +commits before sending.
> +
> +git send-email --subject-prefix="PATCH v4" HEAD~8

Even easier, you can just do:

$ git send-email -v4 HEAD~8

Note that "-v 4" won't work - it has to be "-v4".  This also isn't
listed in the git-send-email man page IIRC, as it's inherited from
some other commands.

> +
> +
> +
>  Patch formatting
>  
>  
> 



signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/5] i965: Don't try copy propagation if constant propagation succeeded.

[Matt Turner]

> i965: Don't try copy propagation if constant propagation succeeded.
>
> It cannot get any better.

That's not obvious to me. How do we know that?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] i965: Pass symbolic swizzle to brw_swizzle() as a single argument.

[Matt Turner]

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

Re: [Mesa-dev] vulkan: features.pipelineStatisticsQuery is true, but vkCreateQueryPool fails for VK_QUERY_TYPE_PIPELINE_STATISTICS

[Kristian Høgsberg]

Ah, yes, we don't support that just yet. I've disabled the bit for now, thanks.

Kristian

On Sun, Feb 28, 2016 at 5:01 AM, Jacek Konieczny  wrote:
> Hi,
>
> Even if it is unfinished, this probably should not be that inconsistent:
>
> anv_GetPhysicalDeviceFeatures() in anv_device.c:
>
>   .pipelineStatisticsQuery  = true,
>
> anv_CreateQueryPool() in anv_query.c:
>
>case VK_QUERY_TYPE_PIPELINE_STATISTICS:
>   return VK_ERROR_INCOMPATIBLE_DRIVER;
>
> Jacek
> ___
> 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] ANNOUNCE: An open-source Vulkan driver for Intel hardware

[Jason Ekstrand]

On Fri, Feb 26, 2016 at 2:18 AM, Olivier Galibert 
wrote:

> Ok, I can tell you that 3DSTATE_DEPTH_BUFFER and
> 3DSTATE_STENCIL_BUFFER seem perfectly correct (assuming the gem
> address-patching-in works for the depth buffer address).  I'll see if
> I can find a past version that works.
>

FYI, this hang has been fixed now and most of the demos work more-or-less.
--Jason


>
>   OG.
>
>
> On Wed, Feb 17, 2016 at 4:31 PM, Jason Ekstrand 
> wrote:
> > On Tue, Feb 16, 2016 at 11:22 PM, Olivier Galibert 
> > wrote:
> >>
> >> I'm actually interested about how one goes about debugging that kind
> >> of problem, if you have pointers.  I would have an idea or two on how
> >> to go about it if it was in userspace only, but once it crosses into
> >> the kernel I'm not sure what strategies are best.
> >
> >
> > This is almost certainly a userspace problem.  I mentioned before that
> it's
> > probably a depth/stencil problem.  I remember having similar problems a
> few
> > months ago when I was reviving gen7.  I know that depth/stencil did work
> at
> > some point.
> >
> > I would start by looking at is where we emit the 3DSTATE_DEPTH_BUFFER and
> > 3DSTATE_STENCIL_BUFFER and trying to see if we're setting something up
> > wrong.  Sometimes it's just a matter of looking at the documentation and
> > comparing the values we're setting to the docs and seeing if the make
> sense.
> > That's where I'd start.
> >
> > You could also try to go back a little ways (don't to past the update to
> > 1.0) to see if you can find a point where depth/stencil worked and try
> and
> > bisect to find where it broke.  That may also provide hints as to what's
> > going wrong.
> >
> > Hope that helps,
> > --Jason
> >
> >>
> >>
> >> Best,
> >>
> >>   OG.
> >>
> >>
> >> On Wed, Feb 17, 2016 at 2:51 AM, Jason Ekstrand 
> >> wrote:
> >> > On Tue, Feb 16, 2016 at 1:21 PM, Olivier Galibert  >
> >> > wrote:
> >> >>
> >> >>   Hi,
> >> >>
> >> >> I'm getting gpu hangs with the lunarg examples (cube and tri) on my
> >> >> Haswell (64 bits).  I attach /sys/class/drm/card0/error fwiw.  How
> >> >> should I go about debugging that?
> >> >
> >> >
> >> > It's a depth-stencil issue and we know about it.   The gen7 code needs
> >> > some
> >> > love.   I think Kristian and Jordan have been working on it.
> >> > --Jason
> >> >
> >> >>
> >> >>
> >> >>   OG.
> >> >>
> >> >>
> >> >> On Tue, Feb 16, 2016 at 4:19 PM, Jason Ekstrand <
> ja...@jlekstrand.net>
> >> >> wrote:
> >> >> > The Intel mesa team is pleased to announce a brand-new open-source
> >> >> > Vulkan
> >> >> > driver for Intel hardware.  We've been working hard on this over
> the
> >> >> > course
> >> >> > of the past year or so and are excited to finally share it with the
> >> >> > community.  We will work on up-streaming the driver in the next few
> >> >> > weeks
> >> >> > and hope to have it all in place in time for mesa 11.3 (mesa 12?).
> >> >> > In
> >> >> > the
> >> >> > mean time, the driver can be found in the "vulkan" branch of the
> mesa
> >> >> > git
> >> >> > repo on freedesktop.org:
> >> >> >
> >> >> > https://cgit.freedesktop.org/mesa/mesa/log/?h=vulkan
> >> >> >
> >> >> > More information on building the driver and running a few simple
> apps
> >> >> > can
> >> >> > be found on the 01.org web site:
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> https://01.org/linuxgraphics/blogs/jekstrand/2016/open-source-vulkan-drivers-intel-hardware
> >> >> >
> >> >> > We have talked to people at Red Hat and Cannonical and binaries
> >> >> > should
> >> >> > be
> >> >> > available for Fedora and Ubuntu soon.  We will update the page on
> >> >> > 01.org
> >> >> > with links as soon as they are available.
> >> >> >
> >> >> > We have also created a small test suite called crucible which
> >> >> > contains a
> >> >> > few hundred tests (mostly for miptrees) that we created when
> bringing
> >> >> > up
> >> >> > the driver.  This isn't really intended to be the piglit of vulkan.
> >> >> > With
> >> >> > the CTS being publicly available, most cross-platform tests should
> go
> >> >> > there.  We mostly made crucible so that we could write a few tests
> >> >> > early
> >> >> > on
> >> >> > to get us going and for tests that were targetted specifically at
> our
> >> >> > implementation.  None the less, they may prove useful to someone
> and
> >> >> > we
> >> >> > are
> >> >> > happy to share them.  The crucible source code can be found at
> >> >> >
> >> >> > https://cgit.freedesktop.org/mesa/crucible/
> >> >> >
> >> >> > Frequently Asked Questions:
> >> >> >
> >> >> > What all hardware does it support?
> >> >> >
> >> >> >The driver currently supports Sky Lake all the way back to Ivy
> >> >> > Bridge.
> >> >> >The driver is Vulkan 1.0 conformant for 64-bit builds on Sky
> Lake,
> >> >> >Broadwell, and Braswell.  We are still having a couple of 32-bit
> >> >> > issues
> >> >> >and support for 

[Mesa-dev] [Bug 91556] [Clover / OpenCL] struct and union arguments handled incorrectly, producing CL_INVALID_ARG_SIZE

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 CC||riva...@gmail.com
Version|11.1|11.2
Summary|Struct / union sizes being  |[Clover / OpenCL] struct
   |calculated incorrectly  |and union arguments handled
   ||incorrectly, producing
   ||CL_INVALID_ARG_SIZE

--- Comment #10 from Vedran Miletić  ---
Slightly change bug summary.

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

[Mesa-dev] [RFC PATCH] include/GL: add mesa_glinterop.h for OpenGL-OpenCL interop

[Marek Olšák]

From: Marek Olšák 

---
 include/GL/mesa_glinterop.h | 226 
 1 file changed, 226 insertions(+)
 create mode 100644 include/GL/mesa_glinterop.h

diff --git a/include/GL/mesa_glinterop.h b/include/GL/mesa_glinterop.h
new file mode 100644
index 000..ecb5459
--- /dev/null
+++ b/include/GL/mesa_glinterop.h
@@ -0,0 +1,226 @@
+/*
+ * Mesa 3-D graphics library
+ *
+ * Copyright 2016 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/* Mesa OpenGL inter-driver interoperability interface. */
+
+#ifndef MESA_GLINTEROP_H
+#define MESA_GLINTEROP_H
+
+#include 
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define MESA_GLINTEROP_VERSION 1
+
+/** Returned error codes. */
+#define MESA_GLINTEROP_SUCCESS  0
+#define MESA_GLINTEROP_OUT_OF_RESOURCES 1
+#define MESA_GLINTEROP_INVALID_OPERATION2
+#define MESA_GLINTEROP_INVALID_VALUE3
+#define MESA_GLINTEROP_INVALID_DISPLAY  4
+#define MESA_GLINTEROP_INVALID_CONTEXT  5
+#define MESA_GLINTEROP_INVALID_TARGET   6
+#define MESA_GLINTEROP_INVALID_OBJECT   7
+#define MESA_GLINTEROP_INVALID_MIP_LEVEL8
+
+/** Access flags. */
+#define MESA_GLINTEROP_ACCESS_READ_WRITE0
+#define MESA_GLINTEROP_ACCESS_READ_ONLY 1
+#define MESA_GLINTEROP_ACCESS_WRITE_ONLY2
+
+
+/**
+ * Device information returned by Mesa.
+ */
+typedef struct {
+   uint32_t size; /* size of this structure */
+
+   /* PCI location */
+   uint32_t pci_segment_group;
+   uint32_t pci_bus;
+   uint32_t pci_device;
+   uint32_t pci_function;
+
+   /* Device identification */
+   uint32_t vendor_id;
+   uint32_t device_id;
+} mesa_glinterop_device_info;
+
+
+/**
+ * Input parameters to Mesa interop export functions.
+ */
+typedef struct {
+   uint32_t size; /* size of this structure */
+
+   /* One of the following:
+* - GL_TEXTURE_BUFFER
+* - GL_TEXTURE_1D
+* - GL_TEXTURE_2D
+* - GL_TEXTURE_3D
+* - GL_TEXTURE_RECTANGLE
+* - GL_TEXTURE_1D_ARRAY
+* - GL_TEXTURE_2D_ARRAY
+* - GL_TEXTURE_CUBE_MAP_ARRAY
+* - GL_TEXTURE_CUBE_MAP
+* - GL_TEXTURE_CUBE_MAP_POSITIVE_X
+* - GL_TEXTURE_CUBE_MAP_NEGATIVE_X
+* - GL_TEXTURE_CUBE_MAP_POSITIVE_Y
+* - GL_TEXTURE_CUBE_MAP_NEGATIVE_Y
+* - GL_TEXTURE_CUBE_MAP_POSITIVE_Z
+* - GL_TEXTURE_CUBE_MAP_NEGATIVE_Z
+* - GL_TEXTURE_2D_MULTISAMPLE
+* - GL_TEXTURE_2D_MULTISAMPLE_ARRAY
+* - GL_TEXTURE_EXTERNAL_OES
+* - GL_RENDERBUFFER
+* - GL_ARRAY_BUFFER
+*/
+   GLenum target;
+
+   /* If target is GL_ARRAY_BUFFER, it's a buffer object.
+* If target is GL_RENDERBUFFER, it's a renderbuffer object.
+* If target is GL_TEXTURE_*, it's a texture object.
+*/
+   GLuint obj;
+
+   /* Mipmap level. Ignored for non-texture objects. */
+   GLuint miplevel;
+
+   /* One of MESA_GLINTEROP_ACCESS_* flags. This describes how the exported
+* object is going to be used.
+*/
+   uint32_t access;
+
+   /* Size of memory pointed to by out_driver_data. */
+   uint32_t out_driver_data_size;
+
+   /* If the caller wants to query driver-specific data about the OpenGL
+* object, this should point to the memory where that dta will be stored.
+*/
+   void *out_driver_data;
+} mesa_glinterop_export_in;
+
+
+/**
+ * Outputs of Mesa interop export functions.
+ */
+typedef struct {
+   uint32_t size; /* size of this structure */
+
+   /* The DMABUF handle. It must closed by the caller using the POSIX close()
+* function when it's not needed anymore. Mesa is not responsible for
+* closing the handle.
+*/
+   int dmabuf_fd;
+
+   /* The mutable OpenGL internal format specified by glTextureView or
+* glTexBuffer. If the object is not one of those, the original internal
+* format specified by glTexStorage, glTexImage, or glRenderbufferStorage
+* will be returned.
+*/
+   GLenum internalformat;
+
+   /* 

Re: [Mesa-dev] [PATCH v7 0/7] add clLinkProgram

[Serge Martin]

Ping

On Saturday 13 February 2016 23:08:34 Serge Martin wrote:
> This serie add clLinkProgram function needed for CL 1.2.
> However, it lacks the binary type part that is mandatory for input
> validation and also for CL_PROGRAM_BINARY_TYPE query. This will be adressed
> in another serie once we agree on the way to store it.
> 
> Serge Martin (7):
>   clover: add a LLVM compiler class
>   clover: make use of llvm_ir_compiler
>   clover: program::build change opts to std::string
>   clover: separate compilation and link stages
>   clover: override ret_object
>   clover: add clLinkProgram (CL 1.2)
>   clover: add -create-library option support
> 
>  src/gallium/state_trackers/clover/Makefile.sources |   3 +-
>  src/gallium/state_trackers/clover/api/program.cpp  |  50 ++-
>  src/gallium/state_trackers/clover/api/util.hpp |  12 +
>  .../state_trackers/clover/core/compiler.hpp|   7 +-
>  src/gallium/state_trackers/clover/core/error.hpp   |   7 +
>  src/gallium/state_trackers/clover/core/program.cpp |  40 ++-
>  src/gallium/state_trackers/clover/core/program.hpp |  10 +-
>  .../state_trackers/clover/llvm/invocation.cpp  | 345
> +++-- .../state_trackers/clover/llvm/ir_compiler.cpp |
> 337  .../state_trackers/clover/llvm/ir_compiler.hpp
> |  65 
>  10 files changed, 619 insertions(+), 257 deletions(-)
>  create mode 100644 src/gallium/state_trackers/clover/llvm/ir_compiler.cpp
>  create mode 100644 src/gallium/state_trackers/clover/llvm/ir_compiler.hpp

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

Re: [Mesa-dev] [PATCH 05/11] nvc0: allow to use more than 7 UBOs for compute on Kepler

[Samuel Pitoiset]

On 02/27/2016 11:26 PM, Ilia Mirkin wrote:

On Sat, Feb 27, 2016 at 9:02 AM, Samuel Pitoiset
 wrote:

The launch descriptor only allows to set up 8 CBs, but OpenGL
requires at least 14 UBOs. To bypass this limitation, we store
the addrs into the driver constbuf and we directly load from
the global memory.

Signed-off-by: Samuel Pitoiset 
---
  .../drivers/nouveau/codegen/nv50_ir_driver.h   |  1 +
  .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp  | 22 +++
  src/gallium/drivers/nouveau/nvc0/nvc0_context.h|  6 +-
  src/gallium/drivers/nouveau/nvc0/nvc0_program.c|  1 +
  src/gallium/drivers/nouveau/nvc0/nve4_compute.c| 25 ++
  5 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
index 479e426..a66aa67 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
@@ -183,6 +183,7 @@ struct nv50_ir_prog_info
uint16_t sampleInfoBase;   /* base address for sample positions */
uint8_t msInfoCBSlot;  /* cX[] used for multisample info */
uint16_t msInfoBase;   /* base address for multisample info */
+  uint16_t uboInfoBase;  /* base address for compute UBOs (gk104+) */
 } io;

 /* driver callback to assign input/output locations */
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index d6dfed3..2928963 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -1997,6 +1997,28 @@ NVC0LoweringPass::visit(Instruction *i)
  i->setIndirect(0, 0, ptr);
  i->subOp = NV50_IR_SUBOP_LDC_IS;
   }
+
+ if (targ->getChipset() >= NVISA_GK104_CHIPSET &&
+ prog->getType() == Program::TYPE_COMPUTE) {
+/* The launch descriptor only allows to set up 8 CBs, but OpenGL
+ * requires at least 14 UBOs. To bypass this limitation, we store
+ * the addrs into the driver constbuf and we directly load from the
+ * global memory. */
+if (i->getSrc(0)->reg.fileIndex >= 7) {
+   uint32_t addr = prog->driver->io.uboInfoBase;
+   uint8_t b = prog->driver->io.resInfoCBSlot;
+
+   addr += (i->getSrc(0)->reg.fileIndex % 7) * 0x8;


I think you wanted - 7 here.


+
+   Instruction *ld = bld.mkLoad(TYPE_U64, bld.getSSA(8, FILE_GPR),
+  bld.mkSymbol(FILE_MEMORY_CONST, b, TYPE_U32, addr), NULL);
+
+   bld.mkLoad(i->dType, i->getDef(0),
+  bld.mkSymbol(FILE_MEMORY_GLOBAL, 0, TYPE_U32, 0),
+   ld->getDef(0));
+   bld.remove(i);


So... let's say I make a UBO array with indirect block indexing...
what do you do? (Hint: this won't work.) More interestingly, what does
the blob do?

Right now you're totally ignoring the indirect ptr for these >= 7
things. But even if you did it "properly", if I create a ubo block
array that spans the "real cb" and "fake cb" boundary... not sure what
to do.


Yes, this has to be improved. I'll make a test and trace the blob to see 
how does it handle this weird case.





+}
+ }
} else if (i->src(0).getFile() == FILE_SHADER_OUTPUT) {
   assert(prog->getType() == Program::TYPE_TESSELLATION_CONTROL);
   i->op = OP_VFETCH;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
index dcb0bda..06c1fc6 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
@@ -91,7 +91,8 @@
  #define NVC0_BIND_CP_SCREEN  51
  #define NVC0_BIND_CP_QUERY   52
  #define NVC0_BIND_CP_BUF 53
-#define NVC0_BIND_CP_COUNT   54
+#define NVC0_BIND_CP_UBO 54
+#define NVC0_BIND_CP_COUNT   55

  /* bufctx for other operations */
  #define NVC0_BIND_2D0
@@ -116,6 +117,9 @@
  /* 8 sets of 32-buts pairs MS offsets */
  #define NVC0_CB_AUX_MS_INFO 0x100 /* CP */
  #define NVC0_CB_AUX_MS_SIZE (8 * 2 * 4)
+/* 7 sets of 32-bits integer addrs */
+#define NVC0_CB_AUX_UBO_INFO0x140 /* CP */
+#define NVC0_CB_AUX_UBO_SIZE(7 * 2 * 4)
  /* 8 sets of 32-bits integer pairs sample offsets */
  #define NVC0_CB_AUX_SAMPLE_INFO 0x180 /* FP */
  #define NVC0_CB_AUX_SAMPLE_SIZE (8 * 4 * 2)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
index afb909c..aba0eda 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
@@ -544,6 +544,7 @@ 

Re: [Mesa-dev] [PATCH 08/11] nvc0: add indirect compute support on Kepler

[Samuel Pitoiset]

On 02/27/2016 11:29 PM, Ilia Mirkin wrote:

On Sat, Feb 27, 2016 at 9:02 AM, Samuel Pitoiset
 wrote:

The grid size is stored as three 32-bits integers in the indirect
buffer but the launch descriptor uses a 32-bits integer for both
griddim_y and griddim_z like this (z << 16) | y. To make it work,
the 16 high bits of griddim_y are overwritten by griddim_z.

Signed-off-by: Samuel Pitoiset 
---
  src/gallium/drivers/nouveau/nvc0/nve4_compute.c | 113 +---
  1 file changed, 81 insertions(+), 32 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nve4_compute.c 
b/src/gallium/drivers/nouveau/nvc0/nve4_compute.c
index 3932e89..1faef23 100644
--- a/src/gallium/drivers/nouveau/nvc0/nve4_compute.c
+++ b/src/gallium/drivers/nouveau/nvc0/nve4_compute.c
@@ -425,9 +425,7 @@ nve4_compute_state_validate(struct nvc0_context *nvc0)
  static void
  nve4_compute_upload_input(struct nvc0_context *nvc0,
struct nve4_cp_launch_desc *desc,
-  const void *input,
-  const uint *block_layout,
-  const uint *grid_layout)
+  const struct pipe_grid_info *info)
  {
 struct nvc0_screen *screen = nvc0->screen;
 struct nouveau_pushbuf *push = nvc0->base.pushbuf;
@@ -445,7 +443,7 @@ nve4_compute_upload_input(struct nvc0_context *nvc0,
PUSH_DATA (push, 0x1);
BEGIN_1IC0(push, NVE4_CP(UPLOAD_EXEC), 1 + (cp->parm_size / 4));
PUSH_DATA (push, NVE4_COMPUTE_UPLOAD_EXEC_LINEAR | (0x20 << 1));
-  PUSH_DATAp(push, input, cp->parm_size / 4);
+  PUSH_DATAp(push, info->input, cp->parm_size / 4);

/* Bind user parameters coming from clover. */
/* TODO: This should be harmonized with uniform_bo. */
@@ -460,8 +458,17 @@ nve4_compute_upload_input(struct nvc0_context *nvc0,
 PUSH_DATA (push, 0x1);
 BEGIN_1IC0(push, NVE4_CP(UPLOAD_EXEC), 1 + 7);
 PUSH_DATA (push, NVE4_COMPUTE_UPLOAD_EXEC_LINEAR | (0x20 << 1));
-   PUSH_DATAp(push, block_layout, 3);
-   PUSH_DATAp(push, grid_layout, 3);
+   PUSH_DATAp(push, info->block, 3);
+   if (unlikely(info->indirect)) {
+  struct nv04_resource *res = nv04_resource(info->indirect);
+  uint32_t offset = res->offset + info->indirect_offset;
+
+  PUSH_REFN(push, res->bo, NOUVEAU_BO_RD | res->domain);
+  nouveau_pushbuf_data(push, res->bo, offset,
+   NVC0_IB_ENTRY_1_NO_PREFETCH | 3 * 4);
+   } else {
+  PUSH_DATAp(push, info->grid, 3);
+   }
 PUSH_DATA (push, 0);

 BEGIN_NVC0(push, NVE4_CP(FLUSH), 1);
@@ -481,9 +488,7 @@ nve4_compute_derive_cache_split(struct nvc0_context *nvc0, 
uint32_t shared_size)
  static void
  nve4_compute_setup_launch_desc(struct nvc0_context *nvc0,
 struct nve4_cp_launch_desc *desc,
-   uint32_t label,
-   const uint *block_layout,
-   const uint *grid_layout)
+   const struct pipe_grid_info *info)
  {
 const struct nvc0_screen *screen = nvc0->screen;
 struct nouveau_pushbuf *push = nvc0->base.pushbuf;
@@ -493,14 +498,14 @@ nve4_compute_setup_launch_desc(struct nvc0_context *nvc0,

 nve4_cp_launch_desc_init_default(desc);

-   desc->entry = nvc0_program_symbol_offset(cp, label);
+   desc->entry = nvc0_program_symbol_offset(cp, info->pc);

-   desc->griddim_x = grid_layout[0];
-   desc->griddim_y = grid_layout[1];
-   desc->griddim_z = grid_layout[2];
-   desc->blockdim_x = block_layout[0];
-   desc->blockdim_y = block_layout[1];
-   desc->blockdim_z = block_layout[2];
+   desc->griddim_x = info->grid[0];
+   desc->griddim_y = info->grid[1];
+   desc->griddim_z = info->grid[2];
+   desc->blockdim_x = info->block[0];
+   desc->blockdim_y = info->block[1];
+   desc->blockdim_z = info->block[2];

 desc->shared_size = align(cp->cp.smem_size, 0x100);
 desc->local_size_p = align(cp->cp.lmem_size, 0x10);
@@ -585,30 +590,74 @@ nve4_launch_grid(struct pipe_context *pipe, const struct 
pipe_grid_info *info)
 if (ret)
goto out;

-   nve4_compute_setup_launch_desc(nvc0, desc, info->pc,
-  info->block, info->grid);
+   nve4_compute_setup_launch_desc(nvc0, desc, info);

-   nve4_compute_upload_input(nvc0, desc, info->input, info->block, info->grid);
+   nve4_compute_upload_input(nvc0, desc, info);

  #ifdef DEBUG
 if (debug_get_num_option("NV50_PROG_DEBUG", 0))
nve4_compute_dump_launch_desc(desc);
  #endif

+   if (unlikely(info->indirect)) {
+  struct nv04_resource *res = nv04_resource(info->indirect);
+  uint32_t offset = res->offset + info->indirect_offset;
+
+  /* upload the first part of the descriptor */
+  BEGIN_NVC0(push, NVE4_CP(UPLOAD_DST_ADDRESS_HIGH), 2);
+  PUSH_DATAh(push, desc_gpuaddr);
+  PUSH_DATA (push, desc_gpuaddr);
+  

Re: [Mesa-dev] [PATCH 02/11] nvc0: bind driver cb for compute on c7[] for Kepler

[Samuel Pitoiset]

On 02/27/2016 10:50 PM, Ilia Mirkin wrote:

I think you're trying to resolve conflicts with images here again...
please do that separately, and in a way that makes images available
everywhere, not just compute. I don't think this needs to be part of
this series though.


I removed the first patch of the series.



On Sat, Feb 27, 2016 at 9:01 AM, Samuel Pitoiset
 wrote:

Signed-off-by: Samuel Pitoiset 
---
  .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp  |  2 +-
  src/gallium/drivers/nouveau/nvc0/nvc0_context.h| 11 ++-
  src/gallium/drivers/nouveau/nvc0/nvc0_program.c| 10 +++---
  src/gallium/drivers/nouveau/nvc0/nve4_compute.c| 38 ++
  src/gallium/drivers/nouveau/nvc0/nve4_compute.h| 25 --
  5 files changed, 41 insertions(+), 45 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 8abdd93..d6dfed3 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -1734,7 +1734,7 @@ NVC0LoweringPass::handleRDSV(Instruction *i)
}
addr += prog->driver->prop.cp.gridInfoBase;
bld.mkLoad(TYPE_U32, i->getDef(0),
- bld.mkSymbol(FILE_MEMORY_CONST, 0, TYPE_U32, addr), NULL);
+ bld.mkSymbol(FILE_MEMORY_CONST, 7, TYPE_U32, addr), NULL);
break;
 case SV_SAMPLE_INDEX:
// TODO: Properly pass source as an address in the PIX address space
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
index 203e479..dcb0bda 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
@@ -102,7 +102,7 @@
  #define NVC0_CB_USR_INFO(s) (s << 16)
  #define NVC0_CB_USR_SIZE(6 << 16)
  /* 6 driver constbuts, at 1K each */
-#define NVC0_CB_AUX_INFO(s) NVC0_CB_USR_SIZE + (s << 10)
+#define NVC0_CB_AUX_INFO(s) NVC0_CB_USR_SIZE + (s << 12)
  #define NVC0_CB_AUX_SIZE(6 << 10)
  /* TIC/TSC entries (6 user clip planes, base instance id) */
  #define NVC0_CB_AUX_TXC_INFO0x000
@@ -113,14 +113,23 @@
  /* 8 user clip planes, at 4 32-bits floats each */
  #define NVC0_CB_AUX_UCP_INFO0x100
  #define NVC0_CB_AUX_UCP_SIZE(PIPE_MAX_CLIP_PLANES * 4 * 4)
+/* 8 sets of 32-buts pairs MS offsets */
+#define NVC0_CB_AUX_MS_INFO 0x100 /* CP */
+#define NVC0_CB_AUX_MS_SIZE (8 * 2 * 4)
  /* 8 sets of 32-bits integer pairs sample offsets */
  #define NVC0_CB_AUX_SAMPLE_INFO 0x180 /* FP */
  #define NVC0_CB_AUX_SAMPLE_SIZE (8 * 4 * 2)
  /* draw parameters (index bais, base instance, drawid) */
  #define NVC0_CB_AUX_DRAW_INFO   0x180 /* VP */
+/* block/grid size, at 3 32-bits integers each and gridid */
+#define NVC0_CB_AUX_GRID_INFO   0x180 /* CP */
+#define NVC0_CB_AUX_GRID_SIZE   (7 * 4)
  /* 32 user buffers, at 4 32-bits integers each */
  #define NVC0_CB_AUX_BUF_INFO(i) 0x200 + (i) * 4 * 4
  #define NVC0_CB_AUX_BUF_SIZE(NVC0_MAX_BUFFERS * 4 * 4)
+/* 32 surfaces, at 16 32-bits integers each */
+#define NVC0_CB_AUX_SUF_INFO(i) 0x400 + (i) * 16 * 4
+#define NVC0_CB_AUX_SUF_SIZE(32 * 16 * 4)
  /* 4 32-bits floats for the vertex runout, put at the end */
  #define NVC0_CB_AUX_RUNOUT_INFO NVC0_CB_USR_SIZE + NVC0_CB_AUX_SIZE

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
index d01de73..8f1f942 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
@@ -540,10 +540,10 @@ nvc0_program_translate(struct nvc0_program *prog, 
uint16_t chipset,

 if (prog->type == PIPE_SHADER_COMPUTE) {
if (chipset >= NVISA_GK104_CHIPSET) {
- info->io.resInfoCBSlot = 0;
- info->io.texBindBase = NVE4_CP_INPUT_TEX(0);
- info->io.suInfoBase = NVE4_CP_INPUT_SUF(0);
- info->prop.cp.gridInfoBase = NVE4_CP_INPUT_GRID_INFO(0);
+ info->io.resInfoCBSlot = 7;
+ info->io.texBindBase = NVC0_CB_AUX_TEX_INFO(0);
+ info->io.suInfoBase = NVC0_CB_AUX_SUF_INFO(0);
+ info->prop.cp.gridInfoBase = NVC0_CB_AUX_GRID_INFO;
   info->io.bufInfoBase = 0; /* TODO */
} else {
   info->io.resInfoCBSlot = 15;
@@ -551,7 +551,7 @@ nvc0_program_translate(struct nvc0_program *prog, uint16_t 
chipset,
   info->io.suInfoBase = 0; /* TODO */
}
info->io.msInfoCBSlot = 0;
-  info->io.msInfoBase = NVE4_CP_INPUT_MS_OFFSETS;
+  info->io.msInfoBase = NVC0_CB_AUX_MS_INFO;
 } else {
if (chipset >= NVISA_GK104_CHIPSET) {
   info->io.texBindBase = NVC0_CB_AUX_TEX_INFO(0);
diff --git a/src/gallium/drivers/nouveau/nvc0/nve4_compute.c 

Re: [Mesa-dev] [PATCH 04/11] nvc0: bind constant buffers for compute on Kepler

[Samuel Pitoiset]

On 02/27/2016 11:20 PM, Ilia Mirkin wrote:

On Sat, Feb 27, 2016 at 9:02 AM, Samuel Pitoiset
 wrote:

--- a/src/gallium/drivers/nouveau/nvc0/nve4_compute.h
+++ b/src/gallium/drivers/nouveau/nvc0/nve4_compute.h
@@ -56,7 +56,7 @@ static inline void
  nve4_cp_launch_desc_set_cb(struct nve4_cp_launch_desc *desc,
 unsigned index,
 struct nouveau_bo *bo,
-   uint32_t base, uint16_t size)
+   uint32_t base, uint32_t size)


Nope, cb's are max 64k. And I think size == 0 means 64k. Not 100% sure
I guess. You also appear to only update the prototype and not the
actual function (at least in this commit)


Nope, 0 means 0, and this function is static inline.





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

Re: [Mesa-dev] [PATCH 01/26] docs: git tips

[Emil Velikov]

On 29 February 2016 at 01:17, Timothy Arceri
 wrote:
> From: Timothy Arceri 
>
> ---
>  docs/devinfo.html | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/docs/devinfo.html b/docs/devinfo.html
> index 8ebf80f..ed9eb9b 100644
> --- a/docs/devinfo.html
> +++ b/docs/devinfo.html
> @@ -162,6 +162,24 @@ components.
>  perhaps, in very trivial cases.)
>  
>
> +Git Tips
> +
> +
> +Test for build breakage between patches e.g last 8 commits.
> +
> +git rebase -i --exec="make -j4" HEAD~8
> +
> +Sets the default mailing address for your repo.
> +
> +git config --local sendemail.to mesa-dev@lists.freedesktop.org
> +
> + Add version to subject line of patch series in this case for the last 8
> +commits before sending.
> +
> +git send-email --subject-prefix="PATCH v4" HEAD~8

Fwiw some of us tend to use the shorter version:

$ git send-email -v4 -8

Whether we want it or not I prefer if others decise.

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

Re: [Mesa-dev] [PATCH 01/26] docs: git tips

[Aaron Watry]

Well, I learned something from that (subject prefix), so I wouldn't mind
seeing it become more easily discoverable.

--Aaron

On Sun, Feb 28, 2016 at 7:25 PM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:

> On Mon, 2016-02-29 at 12:17 +1100, Timothy Arceri wrote:
> > From: Timothy Arceri 
> >
>
> Whoops I didn't intend to send this with the series its just been
> sitting in my repo as I wanted to add the commands I always forget
> somewhere. We can still add it if others think its useful.
>
> > ---
> >  docs/devinfo.html | 18 ++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/docs/devinfo.html b/docs/devinfo.html
> > index 8ebf80f..ed9eb9b 100644
> > --- a/docs/devinfo.html
> > +++ b/docs/devinfo.html
> > @@ -162,6 +162,24 @@ components.
> >  perhaps, in very trivial cases.)
> >  
> >
> > +Git Tips
> > +
> > +
> > +Test for build breakage between patches e.g last 8 commits.
> > +
> > +git rebase -i --exec="make -j4" HEAD~8
> > +
> > +Sets the default mailing address for your repo.
> > +
> > +git config --local sendemail.to mesa-dev@lists.freedesktop.org
> > +
> > + Add version to subject line of patch series in this case for
> > the last 8
> > +commits before sending.
> > +
> > +git send-email --subject-prefix="PATCH v4" HEAD~8
> > +
> > +
> > +
> >  Patch formatting
> >
> >  
> ___
> 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 01/26] docs: git tips

[Brian Paul]

On 02/28/2016 06:17 PM, Timothy Arceri wrote:

From: Timothy Arceri 

---
  docs/devinfo.html | 18 ++
  1 file changed, 18 insertions(+)

diff --git a/docs/devinfo.html b/docs/devinfo.html
index 8ebf80f..ed9eb9b 100644
--- a/docs/devinfo.html
+++ b/docs/devinfo.html
@@ -162,6 +162,24 @@ components.
  perhaps, in very trivial cases.)
  

+Git Tips
+
+
+Test for build breakage between patches e.g last 8 commits.
+
+git rebase -i --exec="make -j4" HEAD~8
+
+Sets the default mailing address for your repo.
+
+git config --local sendemail.to mesa-dev@lists.freedesktop.org
+
+ Add version to subject line of patch series in this case for the last 8
+commits before sending.
+
+git send-email --subject-prefix="PATCH v4" HEAD~8
+
+
+
  Patch formatting

  



Reviewed-by: Brian Paul 

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

Re: [Mesa-dev] [PATCH] radeon/uvd: disable MPEG1

[Emil Velikov]

Hi Christian,

On 29 February 2016 at 11:27, Christian König  wrote:
> From: Christian König 
>
> The hardware simply doesn't support that correctly.
>
Friendly suggestion - if there is a reference with more information on
the topic, please add a link to it.

I'd imagine you guys want to have this in stable as well ? If so add
the following

Cc: "11.1 11.2" 

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

Re: [Mesa-dev] [PATCH] radeon/uvd: disable MPEG1

[Alex Deucher]

On Mon, Feb 29, 2016 at 6:27 AM, Christian König
 wrote:
> From: Christian König 
>
> The hardware simply doesn't support that correctly.
>
> Signed-off-by: Christian König 

Reviewed-by: Alex Deucher 


> ---
>  src/gallium/drivers/radeon/radeon_video.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/radeon/radeon_video.c 
> b/src/gallium/drivers/radeon/radeon_video.c
> index ec29d8c..4b3e2cf 100644
> --- a/src/gallium/drivers/radeon/radeon_video.c
> +++ b/src/gallium/drivers/radeon/radeon_video.c
> @@ -237,6 +237,7 @@ int rvid_get_video_param(struct pipe_screen *screen,
> case PIPE_VIDEO_CAP_SUPPORTED:
> switch (codec) {
> case PIPE_VIDEO_FORMAT_MPEG12:
> +   return profile != PIPE_VIDEO_PROFILE_MPEG1;
> case PIPE_VIDEO_FORMAT_MPEG4:
> case PIPE_VIDEO_FORMAT_MPEG4_AVC:
> if (rscreen->family < CHIP_PALM)
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/5] i965: Don't try copy propagation if constant propagation succeeded.

[Iago Toral]

On Fri, 2016-02-26 at 22:02 -0800, Francisco Jerez wrote:
> It cannot get any better.
> ---
>  src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp   | 2 +-
>  src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
> index 9dbe13d..01fbde1 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
> @@ -738,7 +738,7 @@ fs_visitor::opt_copy_propagate_local(void *copy_prop_ctx, 
> bblock_t *block,
>  if (try_constant_propagate(inst, entry))
> progress = true;
>  
> -if (try_copy_propagate(inst, i, entry))
> +else if (try_copy_propagate(inst, i, entry))

Maybe remove the blank line between the if and the else if?

Reviewed-by: Iago Toral Quiroga 

> progress = true;
>   }
>}
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> index 5c25164..b4a150a 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> @@ -454,7 +454,7 @@ vec4_visitor::opt_copy_propagation(bool do_constant_prop)
>   if (do_constant_prop && try_constant_propagate(devinfo, inst, i, 
> ))
>  progress = true;
>  
> - if (try_copy_propagate(devinfo, inst, i, , 
> attributes_per_reg))
> + else if (try_copy_propagate(devinfo, inst, i, , 
> attributes_per_reg))
>   progress = true;
>}
>  


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

Re: [Mesa-dev] [PATCH 3/5] i965/vec4: Use swizzle() to swizzle immediates during constant propagation.

[Iago Toral]

On Fri, 2016-02-26 at 22:02 -0800, Francisco Jerez wrote:
> swizzle() works for vector immediates other than VF.
> ---
>  .../drivers/dri/i965/brw_vec4_copy_propagation.cpp| 19 
> +--
>  1 file changed, 1 insertion(+), 18 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> index 6bd9928..5c25164 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
> @@ -76,22 +76,6 @@ is_channel_updated(vec4_instruction *inst, src_reg 
> *values[4], int ch)
> inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch)));
>  }
>  
> -static unsigned
> -swizzle_vf_imm(unsigned vf4, unsigned swizzle)
> -{
> -   union {
> -  unsigned vf4;
> -  uint8_t vf[4];
> -   } v = { vf4 }, ret;
> -
> -   ret.vf[0] = v.vf[BRW_GET_SWZ(swizzle, 0)];
> -   ret.vf[1] = v.vf[BRW_GET_SWZ(swizzle, 1)];
> -   ret.vf[2] = v.vf[BRW_GET_SWZ(swizzle, 2)];
> -   ret.vf[3] = v.vf[BRW_GET_SWZ(swizzle, 3)];
> -
> -   return ret.vf4;
> -}
> -
>  static bool
>  is_logic_op(enum opcode opcode)
>  {
> @@ -144,8 +128,7 @@ try_constant_propagate(const struct brw_device_info 
> *devinfo,
>}
> }
>  
> -   if (value.type == BRW_REGISTER_TYPE_VF)
> -  value.ud = swizzle_vf_imm(value.ud, inst->src[arg].swizzle);
> +   value = swizzle(value, inst->src[arg].swizzle);

so I guess V/UV was broken before this?

Reviewed-by: Iago Toral Quiroga 


> switch (inst->opcode) {
> case BRW_OPCODE_MOV:


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

Re: [Mesa-dev] [PATCH 2/5] i965: Add support for swizzling arbitrary immediates to (brw_)swizzle().

[Iago Toral]

On Fri, 2016-02-26 at 22:02 -0800, Francisco Jerez wrote:
> Scalar immediates used to be handled correctly by swizzle() (as the
> identity) but since commit 58fa9d47b536403c4e3ca5d6a2495691338388fd it
> will corrupt the contents of the immediate.  Vector immediates were
> never handled correctly, but we had ad-hoc code to swizzle VF
> immediates in the vec4 copy propagation pass.  This takes care of
> swizzling V and UV in addition.
> ---
>  src/mesa/drivers/dri/i965/brw_eu.c  | 39 
> +
>  src/mesa/drivers/dri/i965/brw_ir_vec4.h |  6 -
>  src/mesa/drivers/dri/i965/brw_reg.h |  7 --
>  3 files changed, 49 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_eu.c 
> b/src/mesa/drivers/dri/i965/brw_eu.c
> index 40ec87d..36bdc7c 100644
> --- a/src/mesa/drivers/dri/i965/brw_eu.c
> +++ b/src/mesa/drivers/dri/i965/brw_eu.c
> @@ -110,6 +110,45 @@ brw_swap_cmod(uint32_t cmod)
> }
>  }
>  
> +/**
> + * Get the least significant bit offset of the i+1-th component of immediate
> + * type \p type.  For \p i equal to the two's complement of j, return the
> + * offset of the j-th component starting from the end of the vector.  For
> + * scalar register types return zero.
> + */
> +static unsigned
> +imm_shift(enum brw_reg_type type, unsigned i)
> +{
> +   if (type == BRW_REGISTER_TYPE_VF)
> +  return 8 * (i & 3);
> +   else if (type == BRW_REGISTER_TYPE_UV || type == BRW_REGISTER_TYPE_V)
> +  return 4 * (i & 7);
> +   else
> +  return 0;
> +}
> +
> +/**
> + * Swizzle an arbitrary immediate \p x of the given type according to the
> + * permutation specified as \p swz.
> + */
> +uint32_t
> +brw_swizzle_immediate(enum brw_reg_type type, uint32_t x, unsigned swz)
> +{
> +   if (imm_shift(type, 1)) {
> +  const unsigned n = 32 / imm_shift(type, 1);

You can assign imm_shift(type, 1) to a variable before the if and reuse
it here.

> +  uint32_t y = 0;
> +
> +  for (unsigned i = 0; i < n; i++)
> + y |= x >> imm_shift(type, (i & ~3) + BRW_GET_SWZ(swz, i & 3))
> +<< imm_shift(type, ~0u)
> +>> imm_shift(type, ~0u - i);
> +

Ugh, took me a while to understand what this was doing even with the
comment in imm_shift(). Another comment here explaining what this series
of operations are doing might save future readers some time... ;)

The implementation looks correct to me:
Reviewed-by: Iago Toral Quiroga 

> +  return y;
> +   } else {
> +  return x;
> +   }
> +}
> +
>  void
>  brw_set_default_exec_size(struct brw_codegen *p, unsigned value)
>  {
> diff --git a/src/mesa/drivers/dri/i965/brw_ir_vec4.h 
> b/src/mesa/drivers/dri/i965/brw_ir_vec4.h
> index 660beca..2b6872e 100644
> --- a/src/mesa/drivers/dri/i965/brw_ir_vec4.h
> +++ b/src/mesa/drivers/dri/i965/brw_ir_vec4.h
> @@ -76,7 +76,11 @@ offset(src_reg reg, unsigned delta)
>  static inline src_reg
>  swizzle(src_reg reg, unsigned swizzle)
>  {
> -   reg.swizzle = brw_compose_swizzle(swizzle, reg.swizzle);
> +   if (reg.file == IMM)
> +  reg.ud = brw_swizzle_immediate(reg.type, reg.ud, swizzle);
> +   else
> +  reg.swizzle = brw_compose_swizzle(swizzle, reg.swizzle);
> +
> return reg;
>  }
>  
> diff --git a/src/mesa/drivers/dri/i965/brw_reg.h 
> b/src/mesa/drivers/dri/i965/brw_reg.h
> index a4bcfca..74ff67f 100644
> --- a/src/mesa/drivers/dri/i965/brw_reg.h
> +++ b/src/mesa/drivers/dri/i965/brw_reg.h
> @@ -223,6 +223,7 @@ enum PACKED brw_reg_type {
>  unsigned brw_reg_type_to_hw_type(const struct brw_device_info *devinfo,
>   enum brw_reg_type type, enum brw_reg_file 
> file);
>  const char *brw_reg_type_letters(unsigned brw_reg_type);
> +uint32_t brw_swizzle_immediate(enum brw_reg_type type, uint32_t x, unsigned 
> swz);
>  
>  #define REG_SIZE (8*4)
>  
> @@ -876,9 +877,11 @@ get_element_d(struct brw_reg reg, unsigned elt)
>  static inline struct brw_reg
>  brw_swizzle(struct brw_reg reg, unsigned swz)
>  {
> -   assert(reg.file != BRW_IMMEDIATE_VALUE);
> +   if (reg.file == BRW_IMMEDIATE_VALUE)
> +  reg.ud = brw_swizzle_immediate(reg.type, reg.ud, swz);
> +   else
> +  reg.swizzle = brw_compose_swizzle(swz, reg.swizzle);
>  
> -   reg.swizzle = brw_compose_swizzle(swz, reg.swizzle);
> return reg;
>  }
>  


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

Re: [Mesa-dev] [PATCH 1/5] i965: Pass symbolic swizzle to brw_swizzle() as a single argument.

[Iago Toral]

Reviewed-by: Iago Toral Quiroga 

On Fri, 2016-02-26 at 22:02 -0800, Francisco Jerez wrote:
> And replace brw_swizzle1() with brw_swizzle().  Seems slightly cleaner
> and will allow reusing brw_swizzle() in the vec4 back-end more easily.
> ---
>  src/mesa/drivers/dri/i965/brw_clip_unfilled.c |  6 --
>  src/mesa/drivers/dri/i965/brw_clip_util.c | 13 +++--
>  src/mesa/drivers/dri/i965/brw_eu_emit.c   |  2 +-
>  src/mesa/drivers/dri/i965/brw_reg.h   | 15 ---
>  4 files changed, 16 insertions(+), 20 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_clip_unfilled.c 
> b/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
> index 3c18858..d333d10 100644
> --- a/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
> +++ b/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
> @@ -85,8 +85,10 @@ static void compute_tri_direction( struct brw_clip_compile 
> *c )
> /* Take their crossproduct:
>  */
> brw_set_default_access_mode(p, BRW_ALIGN_16);
> -   brw_MUL(p, vec4(brw_null_reg()), brw_swizzle(e, 1,2,0,3),  
> brw_swizzle(f,2,0,1,3));
> -   brw_MAC(p, vec4(e),  negate(brw_swizzle(e, 2,0,1,3)), 
> brw_swizzle(f,1,2,0,3));
> +   brw_MUL(p, vec4(brw_null_reg()), brw_swizzle(e, BRW_SWIZZLE_YZXW),
> +   brw_swizzle(f, BRW_SWIZZLE_ZXYW));
> +   brw_MAC(p, vec4(e),  negate(brw_swizzle(e, BRW_SWIZZLE_ZXYW)),
> +   brw_swizzle(f, BRW_SWIZZLE_YZXW));
> brw_set_default_access_mode(p, BRW_ALIGN_1);
>  
> brw_MUL(p, c->reg.dir, c->reg.dir, vec4(e));
> diff --git a/src/mesa/drivers/dri/i965/brw_clip_util.c 
> b/src/mesa/drivers/dri/i965/brw_clip_util.c
> index 7ef3305..3e6664e 100644
> --- a/src/mesa/drivers/dri/i965/brw_clip_util.c
> +++ b/src/mesa/drivers/dri/i965/brw_clip_util.c
> @@ -98,7 +98,8 @@ void brw_clip_project_position(struct brw_clip_compile *c, 
> struct brw_reg pos )
> /* value.xyz *= value.rhw
>  */
> brw_set_default_access_mode(p, BRW_ALIGN_16);
> -   brw_MUL(p, brw_writemask(pos, WRITEMASK_XYZ), pos, brw_swizzle1(pos, W));
> +   brw_MUL(p, brw_writemask(pos, WRITEMASK_XYZ), pos,
> +   brw_swizzle(pos, BRW_SWIZZLE_));
> brw_set_default_access_mode(p, BRW_ALIGN_1);
>  }
>  
> @@ -194,11 +195,11 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
>brw_set_default_access_mode(p, BRW_ALIGN_16);
>brw_MOV(p,
>brw_writemask(t_nopersp, WRITEMASK_ZW),
> -  brw_swizzle(tmp, 0, 1, 0, 1));
> +  brw_swizzle(tmp, BRW_SWIZZLE_XYXY));
>  
>/* t_nopersp = vec4(v1.xy, dest.xy) - v0.xyxy */
>brw_ADD(p, t_nopersp, t_nopersp,
> -  negate(brw_swizzle(v0_ndc_copy, 0, 1, 0, 1)));
> +  negate(brw_swizzle(v0_ndc_copy, BRW_SWIZZLE_XYXY)));
>  
>/* Add the absolute values of the X and Y deltas so that if
> * the points aren't in the same place on the screen we get
> @@ -212,8 +213,8 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
> */
>brw_ADD(p,
>brw_writemask(t_nopersp, WRITEMASK_XY),
> -  brw_abs(brw_swizzle(t_nopersp, 0, 2, 0, 0)),
> -  brw_abs(brw_swizzle(t_nopersp, 1, 3, 0, 0)));
> +  brw_abs(brw_swizzle(t_nopersp, BRW_SWIZZLE_XZXZ)),
> +  brw_abs(brw_swizzle(t_nopersp, BRW_SWIZZLE_YWYW)));
>brw_set_default_access_mode(p, BRW_ALIGN_1);
>  
>/* If the points are in the same place, just substitute a
> @@ -234,7 +235,7 @@ void brw_clip_interp_vertex( struct brw_clip_compile *c,
>brw_MUL(p, vec1(t_nopersp), vec1(t_nopersp),
>  vec1(suboffset(t_nopersp, 1)));
>brw_set_default_access_mode(p, BRW_ALIGN_16);
> -  brw_MOV(p, t_nopersp, brw_swizzle(t_nopersp, 0, 0, 0, 0));
> +  brw_MOV(p, t_nopersp, brw_swizzle(t_nopersp, BRW_SWIZZLE_));
>brw_set_default_access_mode(p, BRW_ALIGN_1);
>  
>release_tmp(c, tmp);
> diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
> b/src/mesa/drivers/dri/i965/brw_eu_emit.c
> index 35d8039..2e4d7be 100644
> --- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
> +++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
> @@ -3399,7 +3399,7 @@ brw_broadcast(struct brw_codegen *p,
>*/
>   inst = brw_MOV(p,
>  brw_null_reg(),
> -stride(brw_swizzle1(idx, 0), 0, 4, 1));
> +stride(brw_swizzle(idx, BRW_SWIZZLE_), 0, 4, 1));
>   brw_inst_set_pred_control(devinfo, inst, BRW_PREDICATE_NONE);
>   brw_inst_set_cond_modifier(devinfo, inst, BRW_CONDITIONAL_NZ);
>   brw_inst_set_flag_reg_nr(devinfo, inst, 1);
> diff --git a/src/mesa/drivers/dri/i965/brw_reg.h 
> b/src/mesa/drivers/dri/i965/brw_reg.h
> index a2a4a40..a4bcfca 100644
> --- a/src/mesa/drivers/dri/i965/brw_reg.h
> +++ b/src/mesa/drivers/dri/i965/brw_reg.h
> @@ -81,7 +81,9 @@ struct brw_device_info;
>  #define BRW_SWIZZLE_  BRW_SWIZZLE4(2,2,2,2)
>  #define 

[Mesa-dev] Mesa 11.2.0 release candidate 2

[Emil Velikov]

The second release candidate for Mesa 11.2.0 is now available.


Brian Paul (1):
  st/mesa: fix frontbuffer glReadPixels regressions

Derek Foreman (1):
  egl/wayland: Try to use wl_surface.damage_buffer for SwapBuffersWithDamage

Emil Velikov (6):
  st/nine: don't forget to bundle the nine_limits.h file
  automake: add nine to make distcheck
  install-gallium-links: port changes from install-lib-links
  automake: add more missing options for make distcheck
  mesa; add get-extra-pick-list.sh script into bin/
  Update version to 11.2.0-rc2

Ilia Mirkin (1):
  nv50,nvc0: bump minimum texture buffer offset alignment

Koop Mast (1):
  st/clover: Add libelf cflags to the build

Marc-André Lureau (1):
  virtio_gpu: Add virtio 1.0 PCI ID to driver map

Marek Olšák (1):
  tgsi/scan: handle holes between VS inputs, assert-fail in other cases

Matt Turner (2):
  glsl: Consider ubo_load to be a horizontal operation.
  i965/fs: Don't CSE negated multiplies with saturation.

Oded Gabbay (5):
  gallium/radeon: Correctly translate colorswaps for big endian
  gallium/radeon: return correct values for BE in r600_translate_colorswap
  gallium/radeon: remove separate BE path in r600_translate_colorswap
  gallium/r600: Don't let h/w do endian swap for colorformat
  gallium/radeon: disable evergreen_do_fast_color_clear for BE

Rob Herring (9):
  Android: fix build break from nir/glsl move to compiler/
  Android: remove dependence on .SECONDEXPANSION
  Android: glsl: fix dependence on YACC_HEADER_SUFFIX from build system
  Android: add -Wno-date-time flag for clang
  Android: remove headers from LOCAL_SRC_FILES
  Android: clean-up and fix DRI module path handling
  freedreno: drop unnecessary -Wno-packed-bitfield-compat
  gallium/radeon: Add space between string literal and identifier
  r600: Make enum alu_op_flags unsigned

Samuel Pitoiset (1):
  nvc0/ir: add missing emission of locked load predicate

Thomas Hindoe Paaboel Andersen (1):
  mesa: use sizeof on the correct type


git tag: mesa-11.2.0-rc2

ftp://ftp.freedesktop.org/pub/mesa/11.2.0/mesa-11.2.0-rc2.tar.gz
MD5: afbe52546f4becbe8e4ba535bcb08e5e  mesa-11.2.0-rc2.tar.gz
SHA1: 05b84a022ee671c466892725737be0cc557e7ad4  mesa-11.2.0-rc2.tar.gz
SHA256: f1ed83a456bc4a26febba1e84b548a5f67921f0ed81c1c70dde086778e2e09f8
 mesa-11.2.0-rc2.tar.gz
PGP: ftp://ftp.freedesktop.org/pub/mesa/11.2.0/mesa-11.2.0-rc2.tar.gz.sig

ftp://ftp.freedesktop.org/pub/mesa/11.2.0/mesa-11.2.0-rc2.tar.xz
MD5: d87674d04d012b43a6c85b34040c3183  mesa-11.2.0-rc2.tar.xz
SHA1: 6ee8fd41dbf747faa41f91a41cbfde7150d21dae  mesa-11.2.0-rc2.tar.xz
SHA256: d68bcfc27e34ca7407be665fb2b7de7ef76c03496cdaddf3b189017bec8b631a
 mesa-11.2.0-rc2.tar.xz
PGP: ftp://ftp.freedesktop.org/pub/mesa/11.2.0/mesa-11.2.0-rc2.tar.xz.sig

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

Re: [Mesa-dev] [PATCH 0/3] Cleanup unused EGL extensions plumbing

[Emil Velikov]

On 10 February 2016 at 12:21, Emil Velikov  wrote:
> Hi all,
>
> The title says most of it with the remainder - ... the extensions
> (KHR_reusable_sync, KHR_vg_parent_image and MESA_drm_display) have been
> unimplemented since the removal of st/egl.
>
Humble ping anyone ?

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

Re: [Mesa-dev] building with -Wshadow

[Emil Velikov]

On 10 February 2016 at 18:50, Ian Romanick  wrote:
> On 02/10/2016 10:48 AM, Ian Romanick wrote:
>> On 02/09/2016 08:43 PM, Dave Airlie wrote:
>>> I was just messing with warning flags on virglrenderer and noticed
>>> -Wshadow generated a fair few warnings with gallium, so I did a mesa
>>> build with -Wshadow enabled and it was fairly messy,
>>>
>>> do we care? there could be bugs hiding in -Wshadow land.
>>
>> I have mixed feelings about -Wshadow.  In principle, it's a good warning
>> to use, and it can catch real bugs.  However, thanks to standard library
>> functions with jackass names like "index", the signal-to-noise ratio
>> chases even me away. :(
>
> Though acording to the link Emil sent, GCC 4.8 may have fixed this.  Yay!
>
Almost... we're either abusing the C++ standard or GCC/GXX (5.2.0
here) still needs some tweaks.
If we enable the warning for both gcc and g++ we get around 5891
warnings and ~100 (iirc) for gcc only.

So g++ is out of the question, whereas for gcc ... maybe.

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

Re: [Mesa-dev] [PATCH] virtio_gpu: Add virtio 1.0 PCI ID to driver map

[Emil Velikov]

On 24 February 2016 at 15:49, Marc-André Lureau
 wrote:
> Hi
>
> On Mon, Feb 22, 2016 at 8:06 PM, Emil Velikov  
> wrote:
>> Hi Marc,
>>
>> On 12 February 2016 at 21:11, Marc-André Lureau
>>  wrote:
>>> From: Marc-André Lureau 
>>>
>>> Add the virtio-gpu PCI ID for virtio 1.0 (according to the
>>> specification, "the PCI Device ID is calculated by adding 0x1040 to the
>>> Virtio Device ID")
>>>
>> Which versions of qemu + kernel work with the new PCI ID - can we
>> include this one in the commit message ?
>>
>
> It is fairly recent, afaik. virtio 1 support was added in qemu 2.4,
> but that is same as when virtio-gpu landed basically. I guess the same
> is true for the kernel, but I don't know in details.
>
Seems like no-one else got to pushing this, so I've added the qemu
note and landed this.

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

[Mesa-dev] [Bug 93524] Clover doesn't build

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

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

--- Comment #2 from Emil Velikov  ---
Just tweaked the patch and landed it in master. It should find it's way in the
stable branches in due time.

For the future, please send patches directly to the mailing list.
Thanks

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

[Mesa-dev] [PATCH] radeon/uvd: disable MPEG1

[Christian König]

From: Christian König 

The hardware simply doesn't support that correctly.

Signed-off-by: Christian König 
---
 src/gallium/drivers/radeon/radeon_video.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/radeon/radeon_video.c 
b/src/gallium/drivers/radeon/radeon_video.c
index ec29d8c..4b3e2cf 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -237,6 +237,7 @@ int rvid_get_video_param(struct pipe_screen *screen,
case PIPE_VIDEO_CAP_SUPPORTED:
switch (codec) {
case PIPE_VIDEO_FORMAT_MPEG12:
+   return profile != PIPE_VIDEO_PROFILE_MPEG1;
case PIPE_VIDEO_FORMAT_MPEG4:
case PIPE_VIDEO_FORMAT_MPEG4_AVC:
if (rscreen->family < CHIP_PALM)
-- 
2.5.0

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

Re: [Mesa-dev] [PATCH 0/8] Fixes for building AOSP master

[Emil Velikov]

On 25 February 2016 at 01:47, Emil Velikov  wrote:
> On 24 February 2016 at 18:56, Rob Herring  wrote:

>> Rob Herring (8):
>>   Android: remove dependence on .SECONDEXPANSION
>>   Android: glsl: fix dependence on YACC_HEADER_SUFFIX from build system
>>   Android: add -Wno-date-time flag for clang
>>   Android: remove headers from LOCAL_SRC_FILES
>>   Android: clean-up and fix DRI module path handling
>>   freedreno: drop unnecessary -Wno-packed-bitfield-compat
>>   gallium/radeon: fix C++11 invalid suffix on literal error
>>   gallium/radeon: fix c++11-narrowing errors
>>
> From a quick look, all these look great (barring the small suggestion
> on the fdno one). I'll double check tomorrow and squeeze them in.
>
Tweaked the commit message as suggested by Michel, kept the freedreno
warning commented out and pushed the lot. Big thanks for these.

With the glsl/nir fix in, only the pipe-loader patch is remaining, right ?

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

Re: [Mesa-dev] [PATCH] mesa/fbobject: propogate Layered when reusing attachments.

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Mon, Feb 29, 2016 at 8:17 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> When reusing a depth attachment as a stencil, we need to propogate
> the layered bit, otherwise we fail to complete the framebuffer.
>
> discovered running ./bin/fbo-depth-array depth-layered-clear
> on virgl on haswell.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/mesa/main/fbobject.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 84f399d..f618663 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -2815,6 +2815,7 @@ reuse_framebuffer_texture_attachment(struct 
> gl_framebuffer *fb,
> dst_att->Complete = src_att->Complete;
> dst_att->TextureLevel = src_att->TextureLevel;
> dst_att->Zoffset = src_att->Zoffset;
> +   dst_att->Layered = src_att->Layered;
>  }
>
>
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 1/8] st/mesa: don't force per-sample interp if only sampleid/pos are used

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Sat, Feb 27, 2016 at 5:21 PM, Ilia Mirkin  wrote:
> The OES extensions clarify this behaviour to differentiate between
> per-sample invocation and per-sample interpolation. Using sampleid/pos
> will force per-sample invocation but not per-sample interpolation.
>
> See https://www.khronos.org/bugzilla/show_bug.cgi?id=1462
>
> Signed-off-by: Ilia Mirkin 
> ---
>  src/mesa/state_tracker/st_atom_shader.c | 4 
>  src/mesa/state_tracker/st_program.c | 4 
>  2 files changed, 8 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_atom_shader.c 
> b/src/mesa/state_tracker/st_atom_shader.c
> index a88f035..f261ce3 100644
> --- a/src/mesa/state_tracker/st_atom_shader.c
> +++ b/src/mesa/state_tracker/st_atom_shader.c
> @@ -71,14 +71,10 @@ update_fp( struct st_context *st )
>   st->ctx->Color._ClampFragmentColor;
>
> /* Don't set it if the driver can force the interpolation by itself.
> -* If SAMPLE_ID or SAMPLE_POS are used, the interpolation is set
> -* automatically.
>  * Ignore sample qualifier while computing this flag.
>  */
> key.persample_shading =
>st->force_persample_in_shader &&
> -  !(stfp->Base.Base.SystemValuesRead & (SYSTEM_BIT_SAMPLE_ID |
> -SYSTEM_BIT_SAMPLE_POS)) &&
>_mesa_get_min_invocations_per_fragment(st->ctx, >Base, true) > 1;
>
> st->fp_variant = st_get_fp_variant(st, stfp, );
> diff --git a/src/mesa/state_tracker/st_program.c 
> b/src/mesa/state_tracker/st_program.c
> index 2e21d02..c9f390a 100644
> --- a/src/mesa/state_tracker/st_program.c
> +++ b/src/mesa/state_tracker/st_program.c
> @@ -573,10 +573,6 @@ st_translate_fragment_program(struct st_context *st,
>   else
>  interpLocation[slot] = TGSI_INTERPOLATE_LOC_CENTER;
>
> - if (stfp->Base.Base.SystemValuesRead & (SYSTEM_BIT_SAMPLE_ID |
> - SYSTEM_BIT_SAMPLE_POS))
> -interpLocation[slot] = TGSI_INTERPOLATE_LOC_SAMPLE;
> -
>   switch (attr) {
>   case VARYING_SLOT_POS:
>  input_semantic_name[slot] = TGSI_SEMANTIC_POSITION;
> --
> 2.4.10
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/3] gallium/r600: Don't let h/w do endian swap for colorformat

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Fri, Feb 26, 2016 at 5:12 PM, Oded Gabbay  wrote:
> Since the rework on gallium pipe formats, there is no more need to do
> endian swap of the colorformat in the h/w, because the conversion between
> mesa format and gallium (pipe) format takes endianess into account (see
> the big #if in p_format.h).
>
> v2: return ENDIAN_NONE only for four 8-bits components
> (V_0280A0_COLOR_8_8_8_8)
>
> Signed-off-by: Oded Gabbay 
> Cc: "11.1 11.2" 
> ---
>  src/gallium/drivers/r600/r600_state_common.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/src/gallium/drivers/r600/r600_state_common.c 
> b/src/gallium/drivers/r600/r600_state_common.c
> index c3346f2..b231d1e 100644
> --- a/src/gallium/drivers/r600/r600_state_common.c
> +++ b/src/gallium/drivers/r600/r600_state_common.c
> @@ -2721,6 +2721,13 @@ uint32_t r600_colorformat_endian_swap(uint32_t 
> colorformat)
>
> /* 32-bit buffers. */
> case V_0280A0_COLOR_8_8_8_8:
> +   /*
> +* No need to do endian swaps on four 8-bits 
> components,
> +* as mesa<-->pipe formats conversion take into 
> account
> +* the endianess
> +*/
> +   return ENDIAN_NONE;
> +
> case V_0280A0_COLOR_2_10_10_10:
> case V_0280A0_COLOR_8_24:
> case V_0280A0_COLOR_24_8:
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600g: Fix ARB_texture_rgb10_a2ui support in big-endian

[Oded Gabbay]

On Mon, Feb 29, 2016 at 7:44 AM, Ilia Mirkin  wrote:
> On Mon, Feb 29, 2016 at 12:31 AM, Oded Gabbay  wrote:
>> On Mon, Feb 29, 2016 at 3:51 AM, Michel Dänzer  wrote:
>>> On 28.02.2016 05:48, Oded Gabbay wrote:
 This patch enables the correct detection of PIPE_FORMAT_R10G10B10A2_UINT
 and PIPE_FORMAT_B10G10R10A2_UINT formats in r600g in big-endian mode, by
 adjusting the order of channels in various functions.

 This enables support for ARB_texture_rgb10_a2ui, which otherwise is not
 detected as supported.

 Signed-off-by: Oded Gabbay 
 ---
  src/gallium/drivers/r600/r600_state_common.c | 15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)

 diff --git a/src/gallium/drivers/r600/r600_state_common.c 
 b/src/gallium/drivers/r600/r600_state_common.c
 index b231d1e..b02b6a9 100644
 --- a/src/gallium/drivers/r600/r600_state_common.c
 +++ b/src/gallium/drivers/r600/r600_state_common.c
 @@ -2468,10 +2468,13 @@ uint32_t r600_translate_texformat(struct 
 pipe_screen *screen,
   result = FMT_1_5_5_5;
   goto out_word4;
   }
 - if (desc->channel[0].size == 10 &&
 - desc->channel[1].size == 10 &&
 - desc->channel[2].size == 10 &&
 - desc->channel[3].size == 2) {
 + if ((desc->channel[1].size == 10 &&
 +   desc->channel[2].size == 10) &&
 + ((desc->channel[0].size == 10 &&
 +   desc->channel[3].size == 2) ||
 +  (R600_BIG_ENDIAN &&
 +   desc->channel[0].size == 2 &&
 +   desc->channel[3].size == 10))) {
   result = FMT_2_10_10_10;
   goto out_word4;
   }
 @@ -2694,9 +2697,11 @@ uint32_t r600_translate_colorformat(enum chip_class 
 chip, enum pipe_format forma
   }
   } else if (HAS_SIZE(5,5,5,1)) {
   return V_0280A0_COLOR_1_5_5_5;
 - } else if (HAS_SIZE(10,10,10,2)) {
 + } else if (HAS_SIZE(10,10,10,2) ||
 + (R600_BIG_ENDIAN && HAS_SIZE(2,10,10,10))) {
>>>
>>> Since the components of these formats cross byte boundaries, these
>>> formats should really be treated as packed by the core Gallium code, in
>>> which case this change probably wouldn't be necessary. In other words,
>>> this is probably working around a core Gallium bug.
>>>
>>
>> so ?
>
> I think the point here is that RGB10A2 in LE != A2BGR10 in BE. They're
> both packed integer formats, and the byteswapping that happens between
> LE/BE does not happen on component boundaries. So there's no way this
> works, and if it does, it's purely by luck. Instead of breaking this
> spot, fix the other spot where it's currently broken.
>
>   -ilia

Thanks Michel & Ilia,

I'll investigate it and get back with a new patch.

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

[Mesa-dev] [Bug 94295] [swrast] piglit shader_runner fast_color_clear/all-colors regression

[bugzilla-daemon]

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

--- Comment #5 from Plamena Manolova  ---
(In reply to Vinson Lee from comment #3)
> (In reply to Plamena Manolova from comment #2)
> 
> > Could you verify whether this patch fixes this issue for you?
> 
> Test still segfaults with patch id=121982.
> 
> #0  find_empty_block (uniform=, prog=) at
> glsl/link_uniforms.cpp:1054
> 1054 foreach_list_typed(struct empty_uniform_block, block, link,
> (gdb) l
> 1049 const unsigned entries = MAX2(1, uniform->array_elements);
> 1050  
> 1051 if (exec_list_is_empty(>EmptyUniformLocations))
> 1052return -1;
> 1053  
> 1054 foreach_list_typed(struct empty_uniform_block, block, link,
> 1055>EmptyUniformLocations) {
> 1056/* Found a block with enough slots to fit the uniform */
> 1057if (block->slots == entries) {
> 1058   unsigned start = block->start;
> (gdb) print block
> $1 = (empty_uniform_block *) 0x0

Could you please try out the new patch?

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

[Mesa-dev] [Bug 94295] [swrast] piglit shader_runner fast_color_clear/all-colors regression

[bugzilla-daemon]

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

--- Comment #4 from Plamena Manolova  ---
Created attachment 122023
  --> https://bugs.freedesktop.org/attachment.cgi?id=122023=edit
Proposed Patch v2

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