Re: [Mesa-dev] [RFC] spec: MESA_program_binary

[Timothy Arceri]

On 16/02/17 17:55, Tapani Pälli wrote:


On 02/16/2017 04:52 AM, Timothy Arceri wrote:

In order add functionality to ARB_get_program_binary we need
binary format enums.


I've understood that this is a driver internal enumeration. When
application gets the binary it also receives enum (integer value) what
format we gave. Then when loading application needs to query what
formats are supported by the implementation and load the correct binary.
We just need to internally make agreement on format list and return
correct one matching the current driver in use?


Not that it's actually likely to happen but if we were to only have a 
single MESA enum an application could only distribute a single binary. 
e.g either for AMD, INTEL or NVIDIA but not one for each. That is unless 
we were to compile and pack all gpu vendor binarys at the same time 
which seems overly complicated and expensive.


I could see an intenal id being used for gpu generations from hardware 
vendors.






---

Techland games such as Dead Island and Dying Light make use of
GetProgramBinary(). My current guess is the Dead Island crash
https://bugs.freedesktop.org/show_bug.cgi?id=85564 is caused
due to buggy handling of this feature not being available.

Anyway I'm not sure how we go about getting Khronos to assign
enums for the binary formats but thought I'd send this to the
list for discussion.

 docs/specs/MESA_program_binary.txt | 78
++
 1 file changed, 78 insertions(+)
 create mode 100644 docs/specs/MESA_program_binary.txt

diff --git a/docs/specs/MESA_program_binary.txt
b/docs/specs/MESA_program_binary.txt
new file mode 100644
index 000..b34e42e
--- /dev/null
+++ b/docs/specs/MESA_program_binary.txt
@@ -0,0 +1,78 @@
+Name
+
+MESA_program_binary
+
+Name Strings
+
+GL_MESA_program_binary
+
+Contact
+
+Timothy Arceri (tarceri 'at' itsqueeze.com)
+
+Status
+
+Complete.
+
+Version
+
+Last Modified Date: February 16, 2017
+Revision: #1
+
+Number
+
+???
+
+Dependencies
+
+OpenGL ES 2.0 is required.
+
+Written based on the wording of the OpenGL ES 2.0 specification.
+
+This extension interacts with OES_get_program_binary.
+
+Overview
+
+MESA provides drivers for multiple hardware vendors. This extension
+provides binary formats in order to avoid conflicts between
drivers when
+loading precompiled binaries.
+
+New Procedures and Functions
+
+None.
+
+New Tokens
+
+Accepted by the  parameter of ShaderBinary:
+
+MESA_PROGRAM_BINARY_AMD
+MESA_PROGRAM_BINARY_NV 
+MESA_PROGRAM_BINARY_INTEL  
+MESA_PROGRAM_BINARY_BCOM   
+MESA_PROGRAM_BINARY_QCOM   
+
+Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL
Operation)
+
+Add the following paragraph to the end of section 2.10.2:
+
+"Depending on the hardware in use the apropriate  is
+returned when querying the list of SHADER_BINARY_FORMATS.
+
+Pre-compiled shader binaries in this format may be loaded via
ShaderBinary.
+
+When a binary fails to load, an INVALID_VALUE error is generated
and a
+more detailed error message is appended to the shader's info log."
+
+Errors
+
+INVALID_VALUE is generated if the  parameter to
ShaderBinary was
+produced with an incompatible version of the MESA shader compiler.
+
+New State
+
+None.
+
+Revision History
+
+#0102/16/2010Timothy Arceri   First draft.
+


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

Re: [Mesa-dev] [PATCH v3 08/24] i965/fs: fix dst stride in IVB/BYT type conversions

[Samuel Iglesias Gonsálvez]

On Thu, 2017-02-16 at 08:11 +0100, Samuel Iglesias Gonsálvez wrote:
> On Wed, 2017-02-15 at 12:08 -0800, Francisco Jerez wrote:
> > Samuel Iglesias Gonsálvez  writes:
> > 
> > > From: "Juan A. Suarez Romero" 
> > > 
> > > When converting a DF to 32-bit conversions, we set dst stride to
> > > 2,
> > > to fulfill alignment restrictions because the upper Dword of
> > > every
> > > Qword will be written with undefined value.
> > > 
> > > But in IVB/BYT, this is not necessary, as each DF conversion
> > > already
> > > writes 2, the first one the real value, and the second one a 0.
> > > That is, IVB/BYT already set stride = 2 implicitly, so we must
> > > set
> > > it to
> > > 1 explicitly to avoid ending up with stride = 4.
> > > 
> > > v2:
> > > - Fix typo (Matt)
> > > 
> > > v3:
> > > - Fix stride in the destination's brw_reg, don't modity IR
> > > (Curro)
> > > 
> > > Signed-off-by: Juan A. Suarez Romero 
> > > Signed-off-by: Samuel Iglesias Gonsálvez 
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 76
> > > +++---
> > >  1 file changed, 45 insertions(+), 31 deletions(-)
> > > 
> > > diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > > b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > > index 2f60ddd8706..e0a80d73b70 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > > +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > > @@ -55,7 +55,7 @@ brw_file_from_reg(fs_reg *reg)
> > >  
> > >  static struct brw_reg
> > >  brw_reg_from_fs_reg(const struct gen_device_info *devinfo,
> > > fs_inst
> > > *inst,
> > > -fs_reg *reg, bool compressed)
> > > +fs_reg *reg, bool is_dst, bool compressed)
> > >  {
> > > struct brw_reg brw_reg;
> > >  
> > > @@ -94,34 +94,48 @@ brw_reg_from_fs_reg(const struct
> > > gen_device_info *devinfo, fs_inst *inst,
> > >   const unsigned width = MIN2(reg_width, phys_width);
> > >   brw_reg = brw_vecn_reg(width, brw_file_from_reg(reg),
> > > reg->nr, 0);
> > >   brw_reg = stride(brw_reg, width * reg->stride, width,
> > > reg->stride);
> > > - /* From the IvyBridge PRM (EU Changes by Processor
> > > Generation, page 13):
> > > -  *  "Each DF (Double Float) operand uses an element
> > > size
> > > of 4 rather
> > > -  *   than 8 and all regioning parameters are twice what
> > > the values
> > > -  *   would be based on the true element size: ExecSize,
> > > Width,
> > > -  *   HorzStride, and VertStride. Each DF operand uses a
> > > pair of
> > > -  *   channels and all masking and swizzing should be
> > > adjusted
> > > -  *   appropriately."
> > > -  *
> > > -  * From the IvyBridge PRM (Special Requirements for
> > > Handling Double
> > > -  * Precision Data Types, page 71):
> > > -  *  "In Align1 mode, all regioning parameters like
> > > stride, execution
> > > -  *   size, and width must use the syntax of a pair of
> > > packed
> > > -  *   floats. The offsets for these data types must be
> > > 64-
> > > bit
> > > -  *   aligned. The execution size and regioning
> > > parameters
> > > are in terms
> > > -  *   of floats."
> > > -  *
> > > -  * Summarized: when handling DF-typed arguments,
> > > ExecSize,
> > > -  * VertStride, and Width must be doubled, and
> > > HorzStride
> > > must be
> > > -  * doubled when the region is not scalar.
> > > -  *
> > > -  * It applies to BayTrail too.
> > > -  */
> > > - if (devinfo->gen == 7 && !devinfo->is_haswell &&
> > > - type_sz(reg->type) == 8) {
> > > -brw_reg.width++;
> > > -if (brw_reg.vstride > 0)
> > > -   brw_reg.vstride++;
> > > -assert(brw_reg.hstride == BRW_HORIZONTAL_STRIDE_1);
> > > +
> > > + if (devinfo->gen == 7 && !devinfo->is_haswell) {
> > > +/* From the IvyBridge PRM (EU Changes by Processor
> > > Generation, page 13):
> > > + *  "Each DF (Double Float) operand uses an element
> > > size of 4 rather
> > > + *   than 8 and all regioning parameters are twice
> > > what the values
> > > + *   would be based on the true element size:
> > > ExecSize, Width,
> > > + *   HorzStride, and VertStride. Each DF operand
> > > uses
> > > a pair of
> > > + *   channels and all masking and swizzing should be
> > > adjusted
> > > + *   appropriately."
> > > + *
> > > + * From the IvyBridge PRM (Special Requirements for
> > > Handling Double
> > > + * Precision Data Types, page 71):
> > > + *  "In Align1 mode, all regioning parameters like
> > > stride, execution
> > > + *   size, and width must use the syntax of a pair
> > > of
> > 

Re: [Mesa-dev] [PATCH v3 08/24] i965/fs: fix dst stride in IVB/BYT type conversions

[Samuel Iglesias Gonsálvez]

On Wed, 2017-02-15 at 12:08 -0800, Francisco Jerez wrote:
> Samuel Iglesias Gonsálvez  writes:
> 
> > From: "Juan A. Suarez Romero" 
> > 
> > When converting a DF to 32-bit conversions, we set dst stride to 2,
> > to fulfill alignment restrictions because the upper Dword of every
> > Qword will be written with undefined value.
> > 
> > But in IVB/BYT, this is not necessary, as each DF conversion
> > already
> > writes 2, the first one the real value, and the second one a 0.
> > That is, IVB/BYT already set stride = 2 implicitly, so we must set
> > it to
> > 1 explicitly to avoid ending up with stride = 4.
> > 
> > v2:
> > - Fix typo (Matt)
> > 
> > v3:
> > - Fix stride in the destination's brw_reg, don't modity IR (Curro)
> > 
> > Signed-off-by: Juan A. Suarez Romero 
> > Signed-off-by: Samuel Iglesias Gonsálvez 
> > ---
> >  src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 76
> > +++---
> >  1 file changed, 45 insertions(+), 31 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > index 2f60ddd8706..e0a80d73b70 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > @@ -55,7 +55,7 @@ brw_file_from_reg(fs_reg *reg)
> >  
> >  static struct brw_reg
> >  brw_reg_from_fs_reg(const struct gen_device_info *devinfo, fs_inst
> > *inst,
> > -fs_reg *reg, bool compressed)
> > +fs_reg *reg, bool is_dst, bool compressed)
> >  {
> > struct brw_reg brw_reg;
> >  
> > @@ -94,34 +94,48 @@ brw_reg_from_fs_reg(const struct
> > gen_device_info *devinfo, fs_inst *inst,
> >   const unsigned width = MIN2(reg_width, phys_width);
> >   brw_reg = brw_vecn_reg(width, brw_file_from_reg(reg),
> > reg->nr, 0);
> >   brw_reg = stride(brw_reg, width * reg->stride, width,
> > reg->stride);
> > - /* From the IvyBridge PRM (EU Changes by Processor
> > Generation, page 13):
> > -  *  "Each DF (Double Float) operand uses an element size
> > of 4 rather
> > -  *   than 8 and all regioning parameters are twice what
> > the values
> > -  *   would be based on the true element size: ExecSize,
> > Width,
> > -  *   HorzStride, and VertStride. Each DF operand uses a
> > pair of
> > -  *   channels and all masking and swizzing should be
> > adjusted
> > -  *   appropriately."
> > -  *
> > -  * From the IvyBridge PRM (Special Requirements for
> > Handling Double
> > -  * Precision Data Types, page 71):
> > -  *  "In Align1 mode, all regioning parameters like
> > stride, execution
> > -  *   size, and width must use the syntax of a pair of
> > packed
> > -  *   floats. The offsets for these data types must be 64-
> > bit
> > -  *   aligned. The execution size and regioning parameters
> > are in terms
> > -  *   of floats."
> > -  *
> > -  * Summarized: when handling DF-typed arguments,
> > ExecSize,
> > -  * VertStride, and Width must be doubled, and HorzStride
> > must be
> > -  * doubled when the region is not scalar.
> > -  *
> > -  * It applies to BayTrail too.
> > -  */
> > - if (devinfo->gen == 7 && !devinfo->is_haswell &&
> > - type_sz(reg->type) == 8) {
> > -brw_reg.width++;
> > -if (brw_reg.vstride > 0)
> > -   brw_reg.vstride++;
> > -assert(brw_reg.hstride == BRW_HORIZONTAL_STRIDE_1);
> > +
> > + if (devinfo->gen == 7 && !devinfo->is_haswell) {
> > +/* From the IvyBridge PRM (EU Changes by Processor
> > Generation, page 13):
> > + *  "Each DF (Double Float) operand uses an element
> > size of 4 rather
> > + *   than 8 and all regioning parameters are twice
> > what the values
> > + *   would be based on the true element size:
> > ExecSize, Width,
> > + *   HorzStride, and VertStride. Each DF operand uses
> > a pair of
> > + *   channels and all masking and swizzing should be
> > adjusted
> > + *   appropriately."
> > + *
> > + * From the IvyBridge PRM (Special Requirements for
> > Handling Double
> > + * Precision Data Types, page 71):
> > + *  "In Align1 mode, all regioning parameters like
> > stride, execution
> > + *   size, and width must use the syntax of a pair of
> > packed
> > + *   floats. The offsets for these data types must be
> > 64-bit
> > + *   aligned. The execution size and regioning
> > parameters are in terms
> > + *   of floats."
> > + *
> > + * Summarized: when handling DF-typed arguments,
> > ExecSize,
> > + * VertStride, and Width must 

Re: [Mesa-dev] [PATCH v3 06/24] i965: Use <0, 2, 1> region for scalar DF sources on IVB/BYT.

[Samuel Iglesias Gonsálvez]

On Wed, 2017-02-15 at 11:45 -0800, Francisco Jerez wrote:
> Samuel Iglesias Gonsálvez  writes:
> 
> > From: Matt Turner 
> > 
> > On HSW+, scalar DF sources can be accessed using the normal <0,1,0>
> > region, but on IVB and BYT DF regions must be programmed in terms
> > of
> > floats. A <0,2,1> region accomplishes this.
> > 
> > v2:
> > - Apply region <0,2,1> in brw_reg_from_fs_reg() (Curro).
> > 
> > Signed-off-by: Samuel Iglesias Gonsálvez 
> > ---
> >  src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > index b0d5732ac5c..2f60ddd8706 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > @@ -145,6 +145,15 @@ brw_reg_from_fs_reg(const struct
> > gen_device_info *devinfo, fs_inst *inst,
> >    unreachable("not reached");
> > }
> >  
> 
> Maybe put a short comment here along the same lines as the commit
> message so you don't need to run git-blame to figure out what this is
> about?  Either way patch is:
> 

Good idea. I will add it.

> Reviewed-by: Francisco Jerez 

Thanks!

Sam

> 
> > +   if (devinfo->gen == 7 && !devinfo->is_haswell &&
> > +   type_sz(reg->type) == 8 &&
> > +   brw_reg.vstride == BRW_VERTICAL_STRIDE_0 &&
> > +   brw_reg.width == BRW_WIDTH_1 &&
> > +   brw_reg.hstride == BRW_HORIZONTAL_STRIDE_0) {
> > +  brw_reg.width = BRW_WIDTH_2;
> > +  brw_reg.hstride = BRW_HORIZONTAL_STRIDE_1;
> > +   }
> > +
> > return brw_reg;
> >  }
> >  
> > -- 
> > 2.11.0
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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 v3 04/24] i965/fs: double regioning parameters and execsize for DF in IVB/BYT

[Samuel Iglesias Gonsálvez]

On Wed, 2017-02-15 at 11:41 -0800, Francisco Jerez wrote:
> Samuel Iglesias Gonsálvez  writes:
> 
> > From: "Juan A. Suarez Romero" 
> > 
> > In IVB and BYT, both regioning parameters and execution sizes are
> > measured as
> > 32-bits element size.
> > 
> > So when we have something like:
> > 
> > mov(8) g2<1>DF g3<4,4,1>DF
> > 
> > We are not actually moving 8 doubles (our intention), but 4
> > doubles.
> > 
> > We need to double the parameters to cope with this issue. However,
> > horizontal strides don't behave as they're supposed to on IVB
> > for DF regions, they will cause each 32-bit half of DF sources to
> > be
> > strided individually, and doubling the value won't make any
> > difference.
> > 
> > v2:
> > - Use devinfo directly (Matt).
> > - Use Baytrail instead of Valleview (Matt).
> > - Use IvyBridge instead of Ivy (Matt)
> > - Double the exec_size in code emission (Curro)
> > 
> > v3:
> > - Change hstride doubling by an assert and fix commit log (Curro).
> > - Substitute remaining compiler->devinfo by devinfo (Curro).
> > 
> > Signed-off-by: Samuel Iglesias Gonsálvez 
> > ---
> >  src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 51
> > ++
> >  1 file changed, 44 insertions(+), 7 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > index 26ffbb169d2..b0d5732ac5c 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> > @@ -54,13 +54,14 @@ brw_file_from_reg(fs_reg *reg)
> >  }
> >  
> >  static struct brw_reg
> > -brw_reg_from_fs_reg(fs_inst *inst, fs_reg *reg, unsigned gen, bool
> > compressed)
> > +brw_reg_from_fs_reg(const struct gen_device_info *devinfo, fs_inst
> > *inst,
> > +fs_reg *reg, bool compressed)
> >  {
> > struct brw_reg brw_reg;
> >  
> > switch (reg->file) {
> > case MRF:
> > -  assert((reg->nr & ~BRW_MRF_COMPR4) < BRW_MAX_MRF(gen));
> > +  assert((reg->nr & ~BRW_MRF_COMPR4) < BRW_MAX_MRF(devinfo-
> > >gen));
> >    /* Fallthrough */
> > case VGRF:
> >    if (reg->stride == 0) {
> > @@ -93,6 +94,35 @@ brw_reg_from_fs_reg(fs_inst *inst, fs_reg *reg,
> > unsigned gen, bool compressed)
> >   const unsigned width = MIN2(reg_width, phys_width);
> >   brw_reg = brw_vecn_reg(width, brw_file_from_reg(reg),
> > reg->nr, 0);
> >   brw_reg = stride(brw_reg, width * reg->stride, width,
> > reg->stride);
> > + /* From the IvyBridge PRM (EU Changes by Processor
> > Generation, page 13):
> > +  *  "Each DF (Double Float) operand uses an element size
> > of 4 rather
> > +  *   than 8 and all regioning parameters are twice what
> > the values
> > +  *   would be based on the true element size: ExecSize,
> > Width,
> > +  *   HorzStride, and VertStride. Each DF operand uses a
> > pair of
> > +  *   channels and all masking and swizzing should be
> > adjusted
> > +  *   appropriately."
> > +  *
> > +  * From the IvyBridge PRM (Special Requirements for
> > Handling Double
> > +  * Precision Data Types, page 71):
> > +  *  "In Align1 mode, all regioning parameters like
> > stride, execution
> > +  *   size, and width must use the syntax of a pair of
> > packed
> > +  *   floats. The offsets for these data types must be 64-
> > bit
> > +  *   aligned. The execution size and regioning parameters
> > are in terms
> > +  *   of floats."
> > +  *
> > +  * Summarized: when handling DF-typed arguments,
> > ExecSize,
> > +  * VertStride, and Width must be doubled, and HorzStride
> > must be
> > +  * doubled when the region is not scalar.
> > +  *
> 
> The comment above seems misleading still, doubling the HorzStride
> value
> is almost guaranteed not to give the intended result, regardless of
> whether the region is scalar.  With that clarified patch is:
> 
> Reviewed-by: Francisco Jerez 
> 

OK. Thanks!

Sam

> > +  * It applies to BayTrail too.
> > +  */
> > + if (devinfo->gen == 7 && !devinfo->is_haswell &&
> > + type_sz(reg->type) == 8) {
> > +brw_reg.width++;
> > +if (brw_reg.vstride > 0)
> > +   brw_reg.vstride++;
> > +assert(brw_reg.hstride == BRW_HORIZONTAL_STRIDE_1);
> > + }
> >    }
> >  
> >    brw_reg = retype(brw_reg, reg->type);
> > @@ -1586,9 +1616,8 @@ fs_generator::generate_code(const cfg_t *cfg,
> > int dispatch_width)
> >    brw_set_default_group(p, inst->group);
> >  
> >    for (unsigned int i = 0; i < inst->sources; i++) {
> > - src[i] = brw_reg_from_fs_reg(inst, >src[i],
> > devinfo->gen,
> > -  compressed);
> > -
> > + src[i] = 

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

[Tapani Pälli]

On 02/16/2017 04:52 AM, Timothy Arceri wrote:

In order add functionality to ARB_get_program_binary we need
binary format enums.


I've understood that this is a driver internal enumeration. When 
application gets the binary it also receives enum (integer value) what 
format we gave. Then when loading application needs to query what 
formats are supported by the implementation and load the correct binary. 
We just need to internally make agreement on format list and return 
correct one matching the current driver in use?




---

Techland games such as Dead Island and Dying Light make use of
GetProgramBinary(). My current guess is the Dead Island crash
https://bugs.freedesktop.org/show_bug.cgi?id=85564 is caused
due to buggy handling of this feature not being available.

Anyway I'm not sure how we go about getting Khronos to assign
enums for the binary formats but thought I'd send this to the
list for discussion.

 docs/specs/MESA_program_binary.txt | 78 ++
 1 file changed, 78 insertions(+)
 create mode 100644 docs/specs/MESA_program_binary.txt

diff --git a/docs/specs/MESA_program_binary.txt 
b/docs/specs/MESA_program_binary.txt
new file mode 100644
index 000..b34e42e
--- /dev/null
+++ b/docs/specs/MESA_program_binary.txt
@@ -0,0 +1,78 @@
+Name
+
+MESA_program_binary
+
+Name Strings
+
+GL_MESA_program_binary
+
+Contact
+
+Timothy Arceri (tarceri 'at' itsqueeze.com)
+
+Status
+
+Complete.
+
+Version
+
+Last Modified Date: February 16, 2017
+Revision: #1
+
+Number
+
+???
+
+Dependencies
+
+OpenGL ES 2.0 is required.
+
+Written based on the wording of the OpenGL ES 2.0 specification.
+
+This extension interacts with OES_get_program_binary.
+
+Overview
+
+MESA provides drivers for multiple hardware vendors. This extension
+provides binary formats in order to avoid conflicts between drivers when
+loading precompiled binaries.
+
+New Procedures and Functions
+
+None.
+
+New Tokens
+
+Accepted by the  parameter of ShaderBinary:
+
+MESA_PROGRAM_BINARY_AMD
+MESA_PROGRAM_BINARY_NV 
+MESA_PROGRAM_BINARY_INTEL  
+MESA_PROGRAM_BINARY_BCOM   
+MESA_PROGRAM_BINARY_QCOM   
+
+Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL Operation)
+
+Add the following paragraph to the end of section 2.10.2:
+
+"Depending on the hardware in use the apropriate  is
+returned when querying the list of SHADER_BINARY_FORMATS.
+
+Pre-compiled shader binaries in this format may be loaded via ShaderBinary.
+
+When a binary fails to load, an INVALID_VALUE error is generated and a
+more detailed error message is appended to the shader's info log."
+
+Errors
+
+INVALID_VALUE is generated if the  parameter to ShaderBinary was
+produced with an incompatible version of the MESA shader compiler.
+
+New State
+
+None.
+
+Revision History
+
+#0102/16/2010Timothy Arceri   First draft.
+


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

[Mesa-dev] [PATCH v2 2/2] i965: Make a helper for emitting 3DSTATE_CONSTANT_XS packets.

[Kenneth Graunke]

This separates the logic from filling out a 3DSTATE_CONSTANT_XS
packet from the decisions about what to put in the various buffers.

It also should make it easier to use more than one buffer, should
we decide to do so.  It also provides a nice place to enforce the
various restrictions via assertions.

By marking the helper as inline, the code for unused buffers should
be constant folded away.

v2: Don't lose MOCS setting on Gen7-7.5.

Signed-off-by: Kenneth Graunke 
Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/gen6_constant_state.c | 170 
 1 file changed, 117 insertions(+), 53 deletions(-)

Patch 1/2 remains unchanged so I didn't bother to send it again

diff --git a/src/mesa/drivers/dri/i965/gen6_constant_state.c 
b/src/mesa/drivers/dri/i965/gen6_constant_state.c
index 6c0c32b26f7..83c1dbab97b 100644
--- a/src/mesa/drivers/dri/i965/gen6_constant_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_constant_state.c
@@ -27,70 +27,134 @@
 #include "intel_batchbuffer.h"
 #include "program/prog_parameter.h"
 
+#define F(RELOC, BATCH, buf, x) \
+   if (buf) { \
+  RELOC(buf, I915_GEM_DOMAIN_RENDER, 0, x); \
+   } else { \
+  BATCH(x); \
+   }
+#define OUT_PTR64(buf, x) F(OUT_RELOC64, OUT_BATCH64, buf, x)
+#define OUT_PTR(buf, x)   F(OUT_RELOC,   OUT_BATCH,   buf, x)
+
+static inline void
+emit_3dstate_constant(struct brw_context *brw,
+  uint32_t opcode,
+  drm_intel_bo *bufs[4],
+  uint16_t read_lengths[4],
+  uint64_t offsets[4])
+{
+   /* Buffer 0 is relative to Dynamic State Base Address, which we program
+* to the start of the batch buffer.  All others are graphics virtual
+* addresses regardless of the INSTPM settings.
+*/
+   assert(bufs[0] == NULL || bufs[0] == brw->batch.bo);
+
+   assert(read_lengths[0] == 0 || bufs[0] != NULL);
+   assert(read_lengths[1] == 0 || bufs[1] != NULL);
+   assert(read_lengths[2] == 0 || bufs[2] != NULL);
+   assert(read_lengths[3] == 0 || bufs[3] != NULL);
+
+   if (brw->gen >= 8) {
+  BEGIN_BATCH(11);
+  OUT_BATCH(opcode << 16 | (11 - 2));
+  OUT_BATCH(read_lengths[0] | read_lengths[1] << 16);
+  OUT_BATCH(read_lengths[2] | read_lengths[3] << 16);
+  OUT_BATCH64(offsets[0]);
+  OUT_PTR64(bufs[1], offsets[1]);
+  OUT_PTR64(bufs[2], offsets[2]);
+  OUT_PTR64(bufs[3], offsets[3]);
+  ADVANCE_BATCH();
+   } else if (brw->gen == 7) {
+  /* From the Ivybridge PRM, Volume 2, Part 1, Page 112:
+   * "Constant buffers must be enabled in order from Constant Buffer 0 to
+   *  Constant Buffer 3 within this command.  For example, it is not
+   *  allowed to enable Constant Buffer 1 by programming a non-zero value
+   *  in the VS Constant Buffer 1 Read Length without a non-zero value in
+   *  VS Constant Buffer 0 Read Length."
+   *
+   * Haswell removes this restriction.
+   */
+  if (!brw->is_haswell) {
+ assert(read_lengths[3] == 0 || (read_lengths[2] > 0 &&
+ read_lengths[1] > 0 &&
+ read_lengths[0] > 0));
+ assert(read_lengths[2] == 0 || (read_lengths[1] > 0 &&
+ read_lengths[0] > 0));
+ assert(read_lengths[1] == 0 || read_lengths[0] > 0);
+  }
+
+  BEGIN_BATCH(7);
+  OUT_BATCH(opcode << 16 | (7 - 2));
+  OUT_BATCH(read_lengths[0] | read_lengths[1] << 16);
+  OUT_BATCH(read_lengths[2] | read_lengths[3] << 16);
+  OUT_BATCH(offsets[0] | GEN7_MOCS_L3);
+  OUT_PTR(bufs[1], offsets[1]);
+  OUT_PTR(bufs[2], offsets[2]);
+  OUT_PTR(bufs[3], offsets[3]);
+  ADVANCE_BATCH();
+   } else if (brw->gen == 6) {
+  /* From the Sandybridge PRM, Volume 2, Part 1, Page 138:
+   * "The sum of all four read length fields (each incremented to
+   *  represent the actual read length) must be less than or equal
+   *  to 32."
+   */
+  assert(read_lengths[0] + read_lengths[1] +
+ read_lengths[2] + read_lengths[3] < 32);
+
+  BEGIN_BATCH(5);
+  OUT_BATCH(opcode << 16 | (5 - 2) |
+(read_lengths[0] ? GEN6_CONSTANT_BUFFER_0_ENABLE : 0) |
+(read_lengths[1] ? GEN6_CONSTANT_BUFFER_1_ENABLE : 0) |
+(read_lengths[2] ? GEN6_CONSTANT_BUFFER_2_ENABLE : 0) |
+(read_lengths[3] ? GEN6_CONSTANT_BUFFER_3_ENABLE : 0));
+  OUT_BATCH(offsets[0] | (read_lengths[0] - 1));
+  OUT_PTR(bufs[1], offsets[1] | (read_lengths[1] - 1));
+  OUT_PTR(bufs[2], offsets[2] | (read_lengths[2] - 1));
+  OUT_PTR(bufs[3], offsets[3] | (read_lengths[3] - 1));
+  ADVANCE_BATCH();
+   } else {
+  unreachable("unhandled gen in emit_3dstate_constant");
+   }
+}
+
 void
 gen7_upload_constant_state(struct brw_context *brw,
const struct brw_stage_state 

Re: [Mesa-dev] [PATCH 2/2] i965: Make a helper for emitting 3DSTATE_CONSTANT_XS packets.

[Kenneth Graunke]

On Wednesday, February 15, 2017 3:23:14 PM PST Jordan Justen wrote:
> On 2017-02-14 13:45:49, Kenneth Graunke wrote:
[snip]
> > diff --git a/src/mesa/drivers/dri/i965/gen6_constant_state.c 
> > b/src/mesa/drivers/dri/i965/gen6_constant_state.c
> > index 6c0c32b26f7..7e6fa92ecf2 100644
> > --- a/src/mesa/drivers/dri/i965/gen6_constant_state.c
> > +++ b/src/mesa/drivers/dri/i965/gen6_constant_state.c
> > @@ -27,6 +27,97 @@
> >  #include "intel_batchbuffer.h"
> >  #include "program/prog_parameter.h"
> >  
> > +#define F(RELOC, BATCH, buf, x) \
> > +   if (buf) { \
> > +  RELOC(buf, I915_GEM_DOMAIN_RENDER, 0, x); \
> > +   } else { \
> > +  BATCH(x); \
> > +   }
> > +#define OUT_PTR64(buf, x) F(OUT_RELOC64, OUT_BATCH64, buf, x)
> > +#define OUT_PTR(buf, x)   F(OUT_RELOC,   OUT_BATCH,   buf, x)
> 
> Is there a better name than 'x'? Unfortunately, I couldn't think of a
> suggestion. :)

Probably...but I couldn't think of one.  It's some bits that get OR'd
in...and can be pretty arbitrary.  OUT_RELOC calls it "delta", but I'm
not sure that historical name makes much sense these days.  OUT_BATCH
uses "d" which is arguably not better.

[snip]

> I didn't see where the 'mocs' value usage moved to in the new code.
> 
> -Jordan

Good point.  It's zero on Gen6 and Gen8, but I accidentally dropped
GEN7_MOCS_L3 on Gen7-7.5.  I'll fix that and send a v2.

Thanks for reading carefully!


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] [RFC] spec: MESA_program_binary

[Timothy Arceri]

On 16/02/17 15:42, Edward O'Callaghan wrote:



On 02/16/2017 01:52 PM, Timothy Arceri wrote:

In order add functionality to ARB_get_program_binary we need
binary format enums.
---

Techland games such as Dead Island and Dying Light make use of
GetProgramBinary(). My current guess is the Dead Island crash
https://bugs.freedesktop.org/show_bug.cgi?id=85564 is caused
due to buggy handling of this feature not being available.

Anyway I'm not sure how we go about getting Khronos to assign
enums for the binary formats but thought I'd send this to the
list for discussion.

 docs/specs/MESA_program_binary.txt | 78 ++
 1 file changed, 78 insertions(+)
 create mode 100644 docs/specs/MESA_program_binary.txt

diff --git a/docs/specs/MESA_program_binary.txt 
b/docs/specs/MESA_program_binary.txt
new file mode 100644
index 000..b34e42e
--- /dev/null
+++ b/docs/specs/MESA_program_binary.txt
@@ -0,0 +1,78 @@
+Name
+
+MESA_program_binary
+
+Name Strings
+
+GL_MESA_program_binary
+
+Contact
+
+Timothy Arceri (tarceri 'at' itsqueeze.com)
+
+Status
+
+Complete.
+
+Version
+
+Last Modified Date: February 16, 2017
+Revision: #1
+
+Number
+
+???
+
+Dependencies
+
+OpenGL ES 2.0 is required.
+
+Written based on the wording of the OpenGL ES 2.0 specification.
+
+This extension interacts with OES_get_program_binary.
+
+Overview
+
+MESA provides drivers for multiple hardware vendors. This extension
+provides binary formats in order to avoid conflicts between drivers when
+loading precompiled binaries.
+
+New Procedures and Functions
+
+None.
+
+New Tokens
+
+Accepted by the  parameter of ShaderBinary:
+
+MESA_PROGRAM_BINARY_AMD


Hey Timothy,

What happens in the case when say, non-GCN vs. GCN vs.
other-shinny-new-ISA?


I believe the intention is to turn the driver into a form of offline 
compiler, so in theory you could compile and store precompiled shaders 
for multiple generations in the same binary.


In practice we would probably just return INVALID_ENUM from 
ProgramBinary/ShaderBinary which would tell the app it needs to 
recompile the program.



Since this is for mesa_ would it be better to have
something like,

MESA_PROGRAM_BINARY_GALLIUM, MESA_PROGRAM_BINARY_NIR or am I
misunderstanding something (probably?)


I think it would be better to divide things up by hardware vendor rather 
than trying to force sharing where it may or may not make sense. Other's 
may have other ideas, we will wait and see.




Kindest Regards,
Edward.


+MESA_PROGRAM_BINARY_NV 
+MESA_PROGRAM_BINARY_INTEL  
+MESA_PROGRAM_BINARY_BCOM   
+MESA_PROGRAM_BINARY_QCOM   
+
+Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL Operation)
+
+Add the following paragraph to the end of section 2.10.2:
+
+"Depending on the hardware in use the apropriate  is
+returned when querying the list of SHADER_BINARY_FORMATS.
+
+Pre-compiled shader binaries in this format may be loaded via ShaderBinary.
+
+When a binary fails to load, an INVALID_VALUE error is generated and a
+more detailed error message is appended to the shader's info log."
+
+Errors
+
+INVALID_VALUE is generated if the  parameter to ShaderBinary was
+produced with an incompatible version of the MESA shader compiler.
+
+New State
+
+None.
+
+Revision History
+
+#0102/16/2010Timothy Arceri   First draft.
+




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

Re: [Mesa-dev] [PATCH 1/3] radeon/ac: add emit umsb shared code.

[Edward O'Callaghan]

This series is,
Reviewed-by: Edward O'Callaghan 

On 02/16/2017 02:55 PM, Dave Airlie wrote:
> From: Dave Airlie 
> 
> Since we shared imsb, makes sense to share umsb.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_llvm_build.c | 25 +
>  src/amd/common/ac_llvm_build.h |  4 
>  2 files changed, 29 insertions(+)
> 
> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
> index dda2c0b..ed31a56 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -788,3 +788,28 @@ ac_emit_imsb(struct ac_llvm_context *ctx,
>  
>   return LLVMBuildSelect(ctx->builder, cond, all_ones, msb, "");
>  }
> +
> +LLVMValueRef
> +ac_emit_umsb(struct ac_llvm_context *ctx,
> +  LLVMValueRef arg,
> +  LLVMTypeRef dst_type)
> +{
> + LLVMValueRef args[2] = {
> + arg,
> + LLVMConstInt(ctx->i32, 1, 0),
> + };
> + LLVMValueRef msb = ac_emit_llvm_intrinsic(ctx, "llvm.ctlz.i32",
> +   dst_type, args, 
> ARRAY_SIZE(args),
> +   AC_FUNC_ATTR_READNONE);
> +
> + /* The HW returns the last bit index from MSB, but TGSI/NIR wants
> +  * the index from LSB. Invert it by doing "31 - msb". */
> + msb = LLVMBuildSub(ctx->builder, LLVMConstInt(ctx->i32, 31, false),
> +msb, "");
> +
> + /* check for zero */
> + return LLVMBuildSelect(ctx->builder,
> +LLVMBuildICmp(ctx->builder, LLVMIntEQ, arg,
> +  LLVMConstInt(ctx->i32, 0, 0), ""),
> +LLVMConstInt(ctx->i32, -1, true), msb, "");
> +}
> diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
> index 0ff04e4..3258e5e 100644
> --- a/src/amd/common/ac_llvm_build.h
> +++ b/src/amd/common/ac_llvm_build.h
> @@ -186,6 +186,10 @@ LLVMValueRef ac_emit_imsb(struct ac_llvm_context *ctx,
> LLVMValueRef arg,
> LLVMTypeRef dst_type);
>  
> +LLVMValueRef ac_emit_umsb(struct ac_llvm_context *ctx,
> +   LLVMValueRef arg,
> +   LLVMTypeRef dst_type);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> 



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

Re: [Mesa-dev] [PATCH 1/4] radeon/ac: add ac_emit_imsb helper.

[Edward O'Callaghan]

This series is,
Reviewed-by: Edward O'Callaghan 

On 02/16/2017 02:48 PM, Dave Airlie wrote:
> From: Dave Airlie 
> 
> We want to use a different intrinsic on newer llvm, so move this
> code to a shared area.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_llvm_build.c | 24 
>  src/amd/common/ac_llvm_build.h |  4 
>  2 files changed, 28 insertions(+)
> 
> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
> index 20216a7..180fd24 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -763,3 +763,27 @@ ac_emit_sendmsg(struct ac_llvm_context *ctx,
>   ac_emit_llvm_intrinsic(ctx, intr_name, ctx->voidt,
>  args, 2, 0);
>  }
> +
> +LLVMValueRef
> +ac_emit_imsb(struct ac_llvm_context *ctx,
> +  LLVMValueRef arg,
> +  LLVMTypeRef dst_type)
> +{
> + LLVMValueRef msb = ac_emit_llvm_intrinsic(ctx, "llvm.AMDGPU.flbit.i32",
> +   dst_type, , 1,
> +   AC_FUNC_ATTR_READNONE);
> +
> + /* The HW returns the last bit index from MSB, but NIR/TGSI wants
> +  * the index from LSB. Invert it by doing "31 - msb". */
> + msb = LLVMBuildSub(ctx->builder, LLVMConstInt(ctx->i32, 31, false),
> +msb, "");
> +
> + LLVMValueRef all_ones = LLVMConstInt(ctx->i32, -1, true);
> + LLVMValueRef cond = LLVMBuildOr(ctx->builder,
> + LLVMBuildICmp(ctx->builder, LLVMIntEQ,
> +   arg, 
> LLVMConstInt(ctx->i32, 0, 0), ""),
> + LLVMBuildICmp(ctx->builder, LLVMIntEQ,
> +   arg, all_ones, ""), "");
> +
> + return LLVMBuildSelect(ctx->builder, cond, all_ones, msb, "");
> +}
> diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
> index e88874a..0ff04e4 100644
> --- a/src/amd/common/ac_llvm_build.h
> +++ b/src/amd/common/ac_llvm_build.h
> @@ -182,6 +182,10 @@ void ac_emit_sendmsg(struct ac_llvm_context *ctx,
>uint32_t msg,
>LLVMValueRef wave_id);
>  
> +LLVMValueRef ac_emit_imsb(struct ac_llvm_context *ctx,
> +   LLVMValueRef arg,
> +   LLVMTypeRef dst_type);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> 



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

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

[Edward O'Callaghan]

On 02/16/2017 01:52 PM, Timothy Arceri wrote:
> In order add functionality to ARB_get_program_binary we need
> binary format enums.
> ---
> 
> Techland games such as Dead Island and Dying Light make use of 
> GetProgramBinary(). My current guess is the Dead Island crash
> https://bugs.freedesktop.org/show_bug.cgi?id=85564 is caused
> due to buggy handling of this feature not being available.
> 
> Anyway I'm not sure how we go about getting Khronos to assign
> enums for the binary formats but thought I'd send this to the
> list for discussion.
> 
>  docs/specs/MESA_program_binary.txt | 78 
> ++
>  1 file changed, 78 insertions(+)
>  create mode 100644 docs/specs/MESA_program_binary.txt
> 
> diff --git a/docs/specs/MESA_program_binary.txt 
> b/docs/specs/MESA_program_binary.txt
> new file mode 100644
> index 000..b34e42e
> --- /dev/null
> +++ b/docs/specs/MESA_program_binary.txt
> @@ -0,0 +1,78 @@
> +Name
> +
> +MESA_program_binary
> +
> +Name Strings
> +
> +GL_MESA_program_binary
> +
> +Contact
> +
> +Timothy Arceri (tarceri 'at' itsqueeze.com)
> +
> +Status
> +
> +Complete.
> +
> +Version
> +
> +Last Modified Date: February 16, 2017
> +Revision: #1
> +
> +Number
> +
> +???
> +
> +Dependencies
> +
> +OpenGL ES 2.0 is required.
> +
> +Written based on the wording of the OpenGL ES 2.0 specification.
> +
> +This extension interacts with OES_get_program_binary.
> +
> +Overview
> +
> +MESA provides drivers for multiple hardware vendors. This extension
> +provides binary formats in order to avoid conflicts between drivers when
> +loading precompiled binaries.
> +
> +New Procedures and Functions
> +
> +None.
> +
> +New Tokens
> +
> +Accepted by the  parameter of ShaderBinary:
> +
> +MESA_PROGRAM_BINARY_AMD

Hey Timothy,

What happens in the case when say, non-GCN vs. GCN vs.
other-shinny-new-ISA? Since this is for mesa_ would it be better to have
something like,

MESA_PROGRAM_BINARY_GALLIUM, MESA_PROGRAM_BINARY_NIR or am I
misunderstanding something (probably?)

Kindest Regards,
Edward.

> +MESA_PROGRAM_BINARY_NV 
> +MESA_PROGRAM_BINARY_INTEL  
> +MESA_PROGRAM_BINARY_BCOM   
> +MESA_PROGRAM_BINARY_QCOM   
> +
> +Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL Operation)
> +
> +Add the following paragraph to the end of section 2.10.2:
> +
> +"Depending on the hardware in use the apropriate  is
> +returned when querying the list of SHADER_BINARY_FORMATS.
> +
> +Pre-compiled shader binaries in this format may be loaded via 
> ShaderBinary.
> +
> +When a binary fails to load, an INVALID_VALUE error is generated and a
> +more detailed error message is appended to the shader's info log."
> +
> +Errors
> +
> +INVALID_VALUE is generated if the  parameter to ShaderBinary was
> +produced with an incompatible version of the MESA shader compiler.
> +
> +New State
> +
> +None.
> +
> +Revision History
> +
> +#0102/16/2010Timothy Arceri   First draft.
> +
> 



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

Re: [Mesa-dev] [PATCH v2 2/2] [swr] remove unneeded extern "C"

[Ilia Mirkin]

Thanks for taking care of these!

Reviewed-by: Ilia Mirkin 

On Wed, Feb 15, 2017 at 10:53 PM, George Kyriazis
 wrote:
> the guards have been added to the header files that needed them.
> ---
>  src/gallium/drivers/swr/swr_context.cpp | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/src/gallium/drivers/swr/swr_context.cpp 
> b/src/gallium/drivers/swr/swr_context.cpp
> index 2e37bac..3e17edc 100644
> --- a/src/gallium/drivers/swr/swr_context.cpp
> +++ b/src/gallium/drivers/swr/swr_context.cpp
> @@ -34,11 +34,8 @@
>  #include "util/u_format.h"
>  #include "util/u_atomic.h"
>  #include "util/u_upload_mgr.h"
> -
> -extern "C" {
>  #include "util/u_transfer.h"
>  #include "util/u_surface.h"
> -}
>
>  #include "api.h"
>  #include "backend.h"
> --
> 2.7.4
>
> ___
> 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/2] [util] add extern "C" guards

[Ilia Mirkin]

On Wed, Feb 15, 2017 at 10:53 PM, George Kyriazis
 wrote:
> Added extern "C" __cplusplus guards on headers that did not have them.
> ---
>  src/gallium/auxiliary/util/u_transfer.h   | 8 
>  src/gallium/auxiliary/util/u_upload_mgr.h | 7 +++
>  2 files changed, 15 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_transfer.h 
> b/src/gallium/auxiliary/util/u_transfer.h
> index ab787ab..1408498 100644
> --- a/src/gallium/auxiliary/util/u_transfer.h
> +++ b/src/gallium/auxiliary/util/u_transfer.h
> @@ -10,6 +10,10 @@
>  struct pipe_context;
>  struct winsys_handle;
>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif

I'm a little weak on the details, but I wonder if this has to
encompass the type forward decls above. I know that the C extern
convention affects function name mangling, but it would stand to
reason that it could also affect types. Not sure. e.g. u_blit.h and
u_blitter.h include the forward decls inside the extern section.

With that figured out one way or the other, this is

Reviewed-by: Ilia Mirkin 

> +
>  boolean u_default_resource_get_handle(struct pipe_screen *screen,
>struct pipe_resource *resource,
>struct winsys_handle *handle);
> @@ -95,4 +99,8 @@ void u_transfer_flush_region_vtbl( struct pipe_context 
> *pipe,
>  void u_transfer_unmap_vtbl( struct pipe_context *rm_ctx,
>  struct pipe_transfer *transfer );
>
> +#ifdef __cplusplus
> +} // extern "C" {
> +#endif
> +
>  #endif
> diff --git a/src/gallium/auxiliary/util/u_upload_mgr.h 
> b/src/gallium/auxiliary/util/u_upload_mgr.h
> index 633291e..4538291 100644
> --- a/src/gallium/auxiliary/util/u_upload_mgr.h
> +++ b/src/gallium/auxiliary/util/u_upload_mgr.h
> @@ -38,6 +38,9 @@
>  struct pipe_context;
>  struct pipe_resource;
>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
>
>  /**
>   * Create the upload manager.
> @@ -109,4 +112,8 @@ void u_upload_data(struct u_upload_mgr *upload,
> unsigned *out_offset,
> struct pipe_resource **outbuf);
>
> +#ifdef __cplusplus
> +} // extern "C" {
> +#endif
> +
>  #endif
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] radv/ac: use shader umsb helper.

[Dave Airlie]

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index b28812e..c1e838e 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -937,23 +937,7 @@ static LLVMValueRef emit_ifind_msb(struct 
nir_to_llvm_context *ctx,
 static LLVMValueRef emit_ufind_msb(struct nir_to_llvm_context *ctx,
   LLVMValueRef src0)
 {
-   LLVMValueRef args[2] = {
-   src0,
-   ctx->i32one,
-   };
-   LLVMValueRef msb = ac_emit_llvm_intrinsic(>ac, "llvm.ctlz.i32",
-  ctx->i32, args, ARRAY_SIZE(args),
-  AC_FUNC_ATTR_READNONE);
-
-   /* The HW returns the last bit index from MSB, but NIR wants
-* the index from LSB. Invert it by doing "31 - msb". */
-   msb = LLVMBuildSub(ctx->builder, LLVMConstInt(ctx->i32, 31, false),
-  msb, "");
-
-   return LLVMBuildSelect(ctx->builder,
-  LLVMBuildICmp(ctx->builder, LLVMIntEQ, src0,
-ctx->i32zero, ""),
-  LLVMConstInt(ctx->i32, -1, true), msb, "");
+   return ac_emit_umsb(>ac, src0, ctx->i32);
 }
 
 static LLVMValueRef emit_minmax_int(struct nir_to_llvm_context *ctx,
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/3] radeonsi: use shared emit_umsb helper.

[Dave Airlie]

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 24 ++-
 1 file changed, 2 insertions(+), 22 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
index 879deb1..e03d053 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
@@ -555,30 +555,10 @@ static void emit_umsb(const struct lp_build_tgsi_action 
*action,
  struct lp_build_tgsi_context *bld_base,
  struct lp_build_emit_data *emit_data)
 {
-   struct gallivm_state *gallivm = bld_base->base.gallivm;
-   LLVMBuilderRef builder = gallivm->builder;
-   LLVMValueRef args[2] = {
-   emit_data->args[0],
-   /* Don't generate code for handling zero: */
-   LLVMConstInt(LLVMInt1TypeInContext(gallivm->context), 1, 0)
-   };
-
-   LLVMValueRef msb =
-   lp_build_intrinsic(builder, "llvm.ctlz.i32",
-   emit_data->dst_type, args, ARRAY_SIZE(args),
-   LP_FUNC_ATTR_READNONE);
-
-   /* The HW returns the last bit index from MSB, but TGSI wants
-* the index from LSB. Invert it by doing "31 - msb". */
-   msb = LLVMBuildSub(builder, lp_build_const_int32(gallivm, 31),
-  msb, "");
+   struct si_shader_context *ctx = si_shader_context(bld_base);
 
-   /* Check for zero: */
emit_data->output[emit_data->chan] =
-   LLVMBuildSelect(builder,
-   LLVMBuildICmp(builder, LLVMIntEQ, args[0],
- bld_base->uint_bld.zero, ""),
-   lp_build_const_int32(gallivm, -1), msb, "");
+   ac_emit_umsb(>ac, emit_data->args[0], emit_data->dst_type);
 }
 
 /* Find the last bit opposite of the sign bit. */
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/3] radeon/ac: add emit umsb shared code.

[Dave Airlie]

From: Dave Airlie 

Since we shared imsb, makes sense to share umsb.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_llvm_build.c | 25 +
 src/amd/common/ac_llvm_build.h |  4 
 2 files changed, 29 insertions(+)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index dda2c0b..ed31a56 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -788,3 +788,28 @@ ac_emit_imsb(struct ac_llvm_context *ctx,
 
return LLVMBuildSelect(ctx->builder, cond, all_ones, msb, "");
 }
+
+LLVMValueRef
+ac_emit_umsb(struct ac_llvm_context *ctx,
+LLVMValueRef arg,
+LLVMTypeRef dst_type)
+{
+   LLVMValueRef args[2] = {
+   arg,
+   LLVMConstInt(ctx->i32, 1, 0),
+   };
+   LLVMValueRef msb = ac_emit_llvm_intrinsic(ctx, "llvm.ctlz.i32",
+ dst_type, args, 
ARRAY_SIZE(args),
+ AC_FUNC_ATTR_READNONE);
+
+   /* The HW returns the last bit index from MSB, but TGSI/NIR wants
+* the index from LSB. Invert it by doing "31 - msb". */
+   msb = LLVMBuildSub(ctx->builder, LLVMConstInt(ctx->i32, 31, false),
+  msb, "");
+
+   /* check for zero */
+   return LLVMBuildSelect(ctx->builder,
+  LLVMBuildICmp(ctx->builder, LLVMIntEQ, arg,
+LLVMConstInt(ctx->i32, 0, 0), ""),
+  LLVMConstInt(ctx->i32, -1, true), msb, "");
+}
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index 0ff04e4..3258e5e 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -186,6 +186,10 @@ LLVMValueRef ac_emit_imsb(struct ac_llvm_context *ctx,
  LLVMValueRef arg,
  LLVMTypeRef dst_type);
 
+LLVMValueRef ac_emit_umsb(struct ac_llvm_context *ctx,
+ LLVMValueRef arg,
+ LLVMTypeRef dst_type);
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 1/2] [util] add extern "C" guards

[George Kyriazis]

Added extern "C" __cplusplus guards on headers that did not have them.
---
 src/gallium/auxiliary/util/u_transfer.h   | 8 
 src/gallium/auxiliary/util/u_upload_mgr.h | 7 +++
 2 files changed, 15 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_transfer.h 
b/src/gallium/auxiliary/util/u_transfer.h
index ab787ab..1408498 100644
--- a/src/gallium/auxiliary/util/u_transfer.h
+++ b/src/gallium/auxiliary/util/u_transfer.h
@@ -10,6 +10,10 @@
 struct pipe_context;
 struct winsys_handle;
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 boolean u_default_resource_get_handle(struct pipe_screen *screen,
   struct pipe_resource *resource,
   struct winsys_handle *handle);
@@ -95,4 +99,8 @@ void u_transfer_flush_region_vtbl( struct pipe_context *pipe,
 void u_transfer_unmap_vtbl( struct pipe_context *rm_ctx,
 struct pipe_transfer *transfer );
 
+#ifdef __cplusplus
+} // extern "C" {
+#endif
+
 #endif
diff --git a/src/gallium/auxiliary/util/u_upload_mgr.h 
b/src/gallium/auxiliary/util/u_upload_mgr.h
index 633291e..4538291 100644
--- a/src/gallium/auxiliary/util/u_upload_mgr.h
+++ b/src/gallium/auxiliary/util/u_upload_mgr.h
@@ -38,6 +38,9 @@
 struct pipe_context;
 struct pipe_resource;
 
+#ifdef __cplusplus
+extern "C" {
+#endif
 
 /**
  * Create the upload manager.
@@ -109,4 +112,8 @@ void u_upload_data(struct u_upload_mgr *upload,
unsigned *out_offset,
struct pipe_resource **outbuf);
 
+#ifdef __cplusplus
+} // extern "C" {
+#endif
+
 #endif
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 2/2] [swr] remove unneeded extern "C"

[George Kyriazis]

the guards have been added to the header files that needed them.
---
 src/gallium/drivers/swr/swr_context.cpp | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_context.cpp 
b/src/gallium/drivers/swr/swr_context.cpp
index 2e37bac..3e17edc 100644
--- a/src/gallium/drivers/swr/swr_context.cpp
+++ b/src/gallium/drivers/swr/swr_context.cpp
@@ -34,11 +34,8 @@
 #include "util/u_format.h"
 #include "util/u_atomic.h"
 #include "util/u_upload_mgr.h"
-
-extern "C" {
 #include "util/u_transfer.h"
 #include "util/u_surface.h"
-}
 
 #include "api.h"
 #include "backend.h"
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/4] radeon/ac: add ac_emit_imsb helper.

[Dave Airlie]

From: Dave Airlie 

We want to use a different intrinsic on newer llvm, so move this
code to a shared area.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_llvm_build.c | 24 
 src/amd/common/ac_llvm_build.h |  4 
 2 files changed, 28 insertions(+)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 20216a7..180fd24 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -763,3 +763,27 @@ ac_emit_sendmsg(struct ac_llvm_context *ctx,
ac_emit_llvm_intrinsic(ctx, intr_name, ctx->voidt,
   args, 2, 0);
 }
+
+LLVMValueRef
+ac_emit_imsb(struct ac_llvm_context *ctx,
+LLVMValueRef arg,
+LLVMTypeRef dst_type)
+{
+   LLVMValueRef msb = ac_emit_llvm_intrinsic(ctx, "llvm.AMDGPU.flbit.i32",
+ dst_type, , 1,
+ AC_FUNC_ATTR_READNONE);
+
+   /* The HW returns the last bit index from MSB, but NIR/TGSI wants
+* the index from LSB. Invert it by doing "31 - msb". */
+   msb = LLVMBuildSub(ctx->builder, LLVMConstInt(ctx->i32, 31, false),
+  msb, "");
+
+   LLVMValueRef all_ones = LLVMConstInt(ctx->i32, -1, true);
+   LLVMValueRef cond = LLVMBuildOr(ctx->builder,
+   LLVMBuildICmp(ctx->builder, LLVMIntEQ,
+ arg, 
LLVMConstInt(ctx->i32, 0, 0), ""),
+   LLVMBuildICmp(ctx->builder, LLVMIntEQ,
+ arg, all_ones, ""), "");
+
+   return LLVMBuildSelect(ctx->builder, cond, all_ones, msb, "");
+}
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index e88874a..0ff04e4 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -182,6 +182,10 @@ void ac_emit_sendmsg(struct ac_llvm_context *ctx,
 uint32_t msg,
 LLVMValueRef wave_id);
 
+LLVMValueRef ac_emit_imsb(struct ac_llvm_context *ctx,
+ LLVMValueRef arg,
+ LLVMTypeRef dst_type);
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/4] radv/ac: use shader imsb emission code.

[Dave Airlie]

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 0564dd1..b28812e 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -931,23 +931,7 @@ static LLVMValueRef emit_find_lsb(struct 
nir_to_llvm_context *ctx,
 static LLVMValueRef emit_ifind_msb(struct nir_to_llvm_context *ctx,
   LLVMValueRef src0)
 {
-   LLVMValueRef msb = ac_emit_llvm_intrinsic(>ac, 
"llvm.AMDGPU.flbit.i32",
-  ctx->i32, , 1,
-  AC_FUNC_ATTR_READNONE);
-
-   /* The HW returns the last bit index from MSB, but NIR wants
-* the index from LSB. Invert it by doing "31 - msb". */
-   msb = LLVMBuildSub(ctx->builder, LLVMConstInt(ctx->i32, 31, false),
-  msb, "");
-
-   LLVMValueRef all_ones = LLVMConstInt(ctx->i32, -1, true);
-   LLVMValueRef cond = LLVMBuildOr(ctx->builder,
-   LLVMBuildICmp(ctx->builder, LLVMIntEQ,
- src0, ctx->i32zero, ""),
-   LLVMBuildICmp(ctx->builder, LLVMIntEQ,
- src0, all_ones, ""), "");
-
-   return LLVMBuildSelect(ctx->builder, cond, all_ones, msb, "");
+   return ac_emit_imsb(>ac, src0, ctx->i32);
 }
 
 static LLVMValueRef emit_ufind_msb(struct nir_to_llvm_context *ctx,
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/4] radeonsi: use shared emit imsb code.

[Dave Airlie]

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 28 +++
 1 file changed, 3 insertions(+), 25 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
index 085fd5b..879deb1 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
@@ -586,32 +586,10 @@ static void emit_imsb(const struct lp_build_tgsi_action 
*action,
  struct lp_build_tgsi_context *bld_base,
  struct lp_build_emit_data *emit_data)
 {
-   struct gallivm_state *gallivm = bld_base->base.gallivm;
-   LLVMBuilderRef builder = gallivm->builder;
-   LLVMValueRef arg = emit_data->args[0];
-
-   LLVMValueRef msb =
-   lp_build_intrinsic(builder, "llvm.AMDGPU.flbit.i32",
-   emit_data->dst_type, , 1,
-   LP_FUNC_ATTR_READNONE);
-
-   /* The HW returns the last bit index from MSB, but TGSI wants
-* the index from LSB. Invert it by doing "31 - msb". */
-   msb = LLVMBuildSub(builder, lp_build_const_int32(gallivm, 31),
-  msb, "");
-
-   /* If arg == 0 || arg == -1 (0x), return -1. */
-   LLVMValueRef all_ones = lp_build_const_int32(gallivm, -1);
-
-   LLVMValueRef cond =
-   LLVMBuildOr(builder,
-   LLVMBuildICmp(builder, LLVMIntEQ, arg,
- bld_base->uint_bld.zero, ""),
-   LLVMBuildICmp(builder, LLVMIntEQ, arg,
- all_ones, ""), "");
-
+   struct si_shader_context *ctx = si_shader_context(bld_base);
emit_data->output[emit_data->chan] =
-   LLVMBuildSelect(builder, cond, all_ones, msb, "");
+   ac_emit_imsb(>ac, emit_data->args[0],
+emit_data->dst_type);
 }
 
 static void emit_iabs(const struct lp_build_tgsi_action *action,
-- 
2.7.4

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

[Mesa-dev] [PATCH 4/4] radeon/ac: use llvm.amdgcn.sffbh intrinsic instead of AMDGPU.flbit.i32

[Dave Airlie]

From: Dave Airlie 

Use the newer intrinsic.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_llvm_build.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 180fd24..dda2c0b 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -769,7 +769,8 @@ ac_emit_imsb(struct ac_llvm_context *ctx,
 LLVMValueRef arg,
 LLVMTypeRef dst_type)
 {
-   LLVMValueRef msb = ac_emit_llvm_intrinsic(ctx, "llvm.AMDGPU.flbit.i32",
+   const char *intr_name = (HAVE_LLVM < 0x0400) ? "llvm.AMDGPU.flbit.i32" 
: "llvm.amdgcn.sffbh";
+   LLVMValueRef msb = ac_emit_llvm_intrinsic(ctx, intr_name,
  dst_type, , 1,
  AC_FUNC_ATTR_READNONE);
 
-- 
2.7.4

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

[Mesa-dev] [RFC] spec: MESA_program_binary

[Timothy Arceri]

In order add functionality to ARB_get_program_binary we need
binary format enums.
---

Techland games such as Dead Island and Dying Light make use of 
GetProgramBinary(). My current guess is the Dead Island crash
https://bugs.freedesktop.org/show_bug.cgi?id=85564 is caused
due to buggy handling of this feature not being available.

Anyway I'm not sure how we go about getting Khronos to assign
enums for the binary formats but thought I'd send this to the
list for discussion.

 docs/specs/MESA_program_binary.txt | 78 ++
 1 file changed, 78 insertions(+)
 create mode 100644 docs/specs/MESA_program_binary.txt

diff --git a/docs/specs/MESA_program_binary.txt 
b/docs/specs/MESA_program_binary.txt
new file mode 100644
index 000..b34e42e
--- /dev/null
+++ b/docs/specs/MESA_program_binary.txt
@@ -0,0 +1,78 @@
+Name
+
+MESA_program_binary
+
+Name Strings
+
+GL_MESA_program_binary
+
+Contact
+
+Timothy Arceri (tarceri 'at' itsqueeze.com)
+
+Status
+
+Complete.
+
+Version
+
+Last Modified Date: February 16, 2017
+Revision: #1
+
+Number
+
+???
+
+Dependencies
+
+OpenGL ES 2.0 is required.
+
+Written based on the wording of the OpenGL ES 2.0 specification.
+
+This extension interacts with OES_get_program_binary.
+
+Overview
+
+MESA provides drivers for multiple hardware vendors. This extension
+provides binary formats in order to avoid conflicts between drivers when
+loading precompiled binaries.
+
+New Procedures and Functions
+
+None.
+
+New Tokens
+
+Accepted by the  parameter of ShaderBinary:
+
+MESA_PROGRAM_BINARY_AMD
+MESA_PROGRAM_BINARY_NV 
+MESA_PROGRAM_BINARY_INTEL  
+MESA_PROGRAM_BINARY_BCOM   
+MESA_PROGRAM_BINARY_QCOM   
+
+Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL Operation)
+
+Add the following paragraph to the end of section 2.10.2:
+
+"Depending on the hardware in use the apropriate  is
+returned when querying the list of SHADER_BINARY_FORMATS.
+
+Pre-compiled shader binaries in this format may be loaded via ShaderBinary.
+
+When a binary fails to load, an INVALID_VALUE error is generated and a
+more detailed error message is appended to the shader's info log."
+
+Errors
+
+INVALID_VALUE is generated if the  parameter to ShaderBinary was
+produced with an incompatible version of the MESA shader compiler.
+
+New State
+
+None.
+
+Revision History
+
+#0102/16/2010Timothy Arceri   First draft.
+
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH] mesa: Always expose GREMEDY_string_marker.

[Ilia Mirkin]

I don't think that's right. Gremedy is a debugger application that exposes
the extension to allow the app to send info to a debugger. It should not be
exposed under normal circumstances as it may enable debug code paths in
applications.

If the issue is that an application is erroneously calling this function,
the solution is to not make calling the function an error, but leave the
extension off under normal circumstances.

Also in that case, don't call the driver function as it will cause the
driver to do things. Nouveau also emits the contents into the command
stream.

On Feb 15, 2017 7:59 PM, "Kenneth Graunke"  wrote:

> Equivalent marker functionality is already included in KHR_debug, which
> we already expose unconditionally in all drivers (dummy_true).
>
> Grim Fandango Remastered apparently calls glStringMarkerGREMEDY()
> without checking for the extension, spewing GL errors.  Assuming the
> existence of the extension is definitely not valid, but it also seems
> kinda mean to spew GL errors when we could simply expose the feature
> and silently ignore the provided string markers.
>
> This patch enables GREMEDY_string_marker everywhere, and makes the calls
> no-ops if the driver doesn't provide the EmitStringMarker() hook, just
> like we did for the KHR_debug functionality.
>
> This may impact freedreno, which actually puts markers in its command
> buffers.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/main/debug_output.c   | 4 +---
>  src/mesa/main/extensions_table.h   | 2 +-
>  src/mesa/state_tracker/st_debug.c  | 1 -
>  src/mesa/state_tracker/st_debug.h  | 3 +--
>  src/mesa/state_tracker/st_extensions.c | 4 
>  5 files changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/src/mesa/main/debug_output.c b/src/mesa/main/debug_output.c
> index bc933db93d4..1d2dee128b4 100644
> --- a/src/mesa/main/debug_output.c
> +++ b/src/mesa/main/debug_output.c
> @@ -1308,12 +1308,10 @@ void GLAPIENTRY
>  _mesa_StringMarkerGREMEDY(GLsizei len, const GLvoid *string)
>  {
> GET_CURRENT_CONTEXT(ctx);
> -   if (ctx->Extensions.GREMEDY_string_marker) {
> +   if (ctx->Driver.EmitStringMarker) {
>/* if length not specified, string will be null terminated: */
>if (len <= 0)
>   len = strlen(string);
>ctx->Driver.EmitStringMarker(ctx, string, len);
> -   } else {
> -  _mesa_error(ctx, GL_INVALID_OPERATION, "StringMarkerGREMEDY");
> }
>  }
> diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_
> table.h
> index 7ea56c8422d..ec48aadde3f 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -285,7 +285,7 @@ EXT(EXT_vertex_array,
> dummy_true
>  EXT(EXT_vertex_array_bgra   , EXT_vertex_array_bgra
> , GLL, GLC,  x ,  x , 2008)
>  EXT(EXT_window_rectangles   , EXT_window_rectangles
> , GLL, GLC,  x ,  30, 2016)
>
> -EXT(GREMEDY_string_marker   , GREMEDY_string_marker
> , GLL, GLC,  x ,  x , 2007)
> +EXT(GREMEDY_string_marker   , dummy_true
>, GLL, GLC,  x ,  x , 2007)
>
>  EXT(IBM_multimode_draw_arrays   , dummy_true
>, GLL, GLC,  x ,  x , 1998)
>  EXT(IBM_rasterpos_clip  , dummy_true
>, GLL,  x ,  x ,  x , 1996)
> diff --git a/src/mesa/state_tracker/st_debug.c
> b/src/mesa/state_tracker/st_debug.c
> index d6cb5cd57d8..f2e982c8c7a 100644
> --- a/src/mesa/state_tracker/st_debug.c
> +++ b/src/mesa/state_tracker/st_debug.c
> @@ -58,7 +58,6 @@ static const struct debug_named_value st_debug_flags[] =
> {
> { "buffer",   DEBUG_BUFFER, NULL },
> { "wf",   DEBUG_WIREFRAME, NULL },
> { "precompile",  DEBUG_PRECOMPILE, NULL },
> -   { "gremedy",  DEBUG_GREMEDY, "Enable GREMEDY debug extensions" },
> { "noreadpixcache", DEBUG_NOREADPIXCACHE, NULL },
> DEBUG_NAMED_VALUE_END
>  };
> diff --git a/src/mesa/state_tracker/st_debug.h
> b/src/mesa/state_tracker/st_debug.h
> index 6c1e915f68c..4b92a669a37 100644
> --- a/src/mesa/state_tracker/st_debug.h
> +++ b/src/mesa/state_tracker/st_debug.h
> @@ -50,8 +50,7 @@ st_print_current(void);
>  #define DEBUG_BUFFER0x200
>  #define DEBUG_WIREFRAME 0x400
>  #define DEBUG_PRECOMPILE   0x800
> -#define DEBUG_GREMEDY   0x1000
> -#define DEBUG_NOREADPIXCACHE 0x2000
> +#define DEBUG_NOREADPIXCACHE 0x1000
>
>  #ifdef DEBUG
>  extern int ST_DEBUG;
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extensions.c
> index 37fe4469c37..d9057c77657 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -1167,10 +1167,6 @@ void st_init_extensions(struct pipe_screen *screen,
>extensions->ARB_vertex_attrib_64bit = GL_TRUE;
> }
>
> -   if ((ST_DEBUG & DEBUG_GREMEDY) &&
> -   screen->get_param(screen, 

[Mesa-dev] [PATCH] mesa: Always expose GREMEDY_string_marker.

[Kenneth Graunke]

Equivalent marker functionality is already included in KHR_debug, which
we already expose unconditionally in all drivers (dummy_true).

Grim Fandango Remastered apparently calls glStringMarkerGREMEDY()
without checking for the extension, spewing GL errors.  Assuming the
existence of the extension is definitely not valid, but it also seems
kinda mean to spew GL errors when we could simply expose the feature
and silently ignore the provided string markers.

This patch enables GREMEDY_string_marker everywhere, and makes the calls
no-ops if the driver doesn't provide the EmitStringMarker() hook, just
like we did for the KHR_debug functionality.

This may impact freedreno, which actually puts markers in its command
buffers.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/main/debug_output.c   | 4 +---
 src/mesa/main/extensions_table.h   | 2 +-
 src/mesa/state_tracker/st_debug.c  | 1 -
 src/mesa/state_tracker/st_debug.h  | 3 +--
 src/mesa/state_tracker/st_extensions.c | 4 
 5 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/src/mesa/main/debug_output.c b/src/mesa/main/debug_output.c
index bc933db93d4..1d2dee128b4 100644
--- a/src/mesa/main/debug_output.c
+++ b/src/mesa/main/debug_output.c
@@ -1308,12 +1308,10 @@ void GLAPIENTRY
 _mesa_StringMarkerGREMEDY(GLsizei len, const GLvoid *string)
 {
GET_CURRENT_CONTEXT(ctx);
-   if (ctx->Extensions.GREMEDY_string_marker) {
+   if (ctx->Driver.EmitStringMarker) {
   /* if length not specified, string will be null terminated: */
   if (len <= 0)
  len = strlen(string);
   ctx->Driver.EmitStringMarker(ctx, string, len);
-   } else {
-  _mesa_error(ctx, GL_INVALID_OPERATION, "StringMarkerGREMEDY");
}
 }
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 7ea56c8422d..ec48aadde3f 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -285,7 +285,7 @@ EXT(EXT_vertex_array, dummy_true
 EXT(EXT_vertex_array_bgra   , EXT_vertex_array_bgra
  , GLL, GLC,  x ,  x , 2008)
 EXT(EXT_window_rectangles   , EXT_window_rectangles
  , GLL, GLC,  x ,  30, 2016)
 
-EXT(GREMEDY_string_marker   , GREMEDY_string_marker
  , GLL, GLC,  x ,  x , 2007)
+EXT(GREMEDY_string_marker   , dummy_true   
  , GLL, GLC,  x ,  x , 2007)
 
 EXT(IBM_multimode_draw_arrays   , dummy_true   
  , GLL, GLC,  x ,  x , 1998)
 EXT(IBM_rasterpos_clip  , dummy_true   
  , GLL,  x ,  x ,  x , 1996)
diff --git a/src/mesa/state_tracker/st_debug.c 
b/src/mesa/state_tracker/st_debug.c
index d6cb5cd57d8..f2e982c8c7a 100644
--- a/src/mesa/state_tracker/st_debug.c
+++ b/src/mesa/state_tracker/st_debug.c
@@ -58,7 +58,6 @@ static const struct debug_named_value st_debug_flags[] = {
{ "buffer",   DEBUG_BUFFER, NULL },
{ "wf",   DEBUG_WIREFRAME, NULL },
{ "precompile",  DEBUG_PRECOMPILE, NULL },
-   { "gremedy",  DEBUG_GREMEDY, "Enable GREMEDY debug extensions" },
{ "noreadpixcache", DEBUG_NOREADPIXCACHE, NULL },
DEBUG_NAMED_VALUE_END
 };
diff --git a/src/mesa/state_tracker/st_debug.h 
b/src/mesa/state_tracker/st_debug.h
index 6c1e915f68c..4b92a669a37 100644
--- a/src/mesa/state_tracker/st_debug.h
+++ b/src/mesa/state_tracker/st_debug.h
@@ -50,8 +50,7 @@ st_print_current(void);
 #define DEBUG_BUFFER0x200
 #define DEBUG_WIREFRAME 0x400
 #define DEBUG_PRECOMPILE   0x800
-#define DEBUG_GREMEDY   0x1000
-#define DEBUG_NOREADPIXCACHE 0x2000
+#define DEBUG_NOREADPIXCACHE 0x1000
 
 #ifdef DEBUG
 extern int ST_DEBUG;
diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 37fe4469c37..d9057c77657 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -1167,10 +1167,6 @@ void st_init_extensions(struct pipe_screen *screen,
   extensions->ARB_vertex_attrib_64bit = GL_TRUE;
}
 
-   if ((ST_DEBUG & DEBUG_GREMEDY) &&
-   screen->get_param(screen, PIPE_CAP_STRING_MARKER))
-  extensions->GREMEDY_string_marker = GL_TRUE;
-
if (screen->get_param(screen, PIPE_CAP_COMPUTE)) {
   int compute_supported_irs =
  screen->get_shader_param(screen, PIPE_SHADER_COMPUTE,
-- 
2.11.1

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

[Mesa-dev] [Bug 99817] [softpipe] piglit glsl-fs-tan-1 regression

[bugzilla-daemon]

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

--- Comment #4 from Vinson Lee  ---
attachment 129616 fixes the regression.

Tested-by: Vinson Lee 

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

Re: [Mesa-dev] [PATCH 2/2] i965: Make a helper for emitting 3DSTATE_CONSTANT_XS packets.

[Jordan Justen]

On 2017-02-14 13:45:49, Kenneth Graunke wrote:
> This separates the logic from filling out a 3DSTATE_CONSTANT_XS
> packet from the decisions about what to put in the various buffers.
> 
> It also should make it easier to use more than one buffer, should
> we decide to do so.  It also provides a nice place to enforce the
> various restrictions via assertions.
> 
> By marking the helper as inline, the code for unused buffers should
> be constant folded away.
> 
> Signed-off-by: Kenneth Graunke 
> Signed-off-by: Ben Widawsky 
> ---
>  src/mesa/drivers/dri/i965/gen6_constant_state.c | 169 
> +---
>  1 file changed, 118 insertions(+), 51 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/gen6_constant_state.c 
> b/src/mesa/drivers/dri/i965/gen6_constant_state.c
> index 6c0c32b26f7..7e6fa92ecf2 100644
> --- a/src/mesa/drivers/dri/i965/gen6_constant_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_constant_state.c
> @@ -27,6 +27,97 @@
>  #include "intel_batchbuffer.h"
>  #include "program/prog_parameter.h"
>  
> +#define F(RELOC, BATCH, buf, x) \
> +   if (buf) { \
> +  RELOC(buf, I915_GEM_DOMAIN_RENDER, 0, x); \
> +   } else { \
> +  BATCH(x); \
> +   }
> +#define OUT_PTR64(buf, x) F(OUT_RELOC64, OUT_BATCH64, buf, x)
> +#define OUT_PTR(buf, x)   F(OUT_RELOC,   OUT_BATCH,   buf, x)

Is there a better name than 'x'? Unfortunately, I couldn't think of a
suggestion. :)

> +
> +static inline void
> +emit_3dstate_constant(struct brw_context *brw,
> +  uint32_t opcode,
> +  uint32_t mocs,
> +  drm_intel_bo *bufs[4],
> +  uint16_t read_lengths[4],
> +  uint64_t offsets[4])
> +{
> +   /* Buffer 0 is relative to Dynamic State Base Address, which we program
> +* to the start of the batch buffer.  All others are graphics virtual
> +* addresses regardless of the INSTPM settings.
> +*/
> +   assert(bufs[0] == NULL || bufs[0] == brw->batch.bo);
> +
> +   assert(read_lengths[0] == 0 || bufs[0] != NULL);
> +   assert(read_lengths[1] == 0 || bufs[1] != NULL);
> +   assert(read_lengths[2] == 0 || bufs[2] != NULL);
> +   assert(read_lengths[3] == 0 || bufs[3] != NULL);
> +
> +   if (brw->gen >= 8) {
> +  BEGIN_BATCH(11);
> +  OUT_BATCH(opcode << 16 | (11 - 2));
> +  OUT_BATCH(read_lengths[0] | read_lengths[1] << 16);
> +  OUT_BATCH(read_lengths[2] | read_lengths[3] << 16);
> +  OUT_BATCH64(offsets[0]);
> +  OUT_PTR64(bufs[1], offsets[1]);
> +  OUT_PTR64(bufs[2], offsets[2]);
> +  OUT_PTR64(bufs[3], offsets[3]);
> +  ADVANCE_BATCH();
> +   } else if (brw->gen == 7) {
> +  /* From the Ivybridge PRM, Volume 2, Part 1, Page 112:
> +   * "Constant buffers must be enabled in order from Constant Buffer 0 to
> +   *  Constant Buffer 3 within this command.  For example, it is not
> +   *  allowed to enable Constant Buffer 1 by programming a non-zero value
> +   *  in the VS Constant Buffer 1 Read Length without a non-zero value in
> +   *  VS Constant Buffer 0 Read Length."
> +   *
> +   * Haswell removes this restriction.
> +   */
> +  if (!brw->is_haswell) {
> + assert(read_lengths[3] == 0 || (read_lengths[2] > 0 &&
> + read_lengths[1] > 0 &&
> + read_lengths[0] > 0));
> + assert(read_lengths[2] == 0 || (read_lengths[1] > 0 &&
> + read_lengths[0] > 0));
> + assert(read_lengths[1] == 0 || read_lengths[0] > 0);
> +  }
> +
> +  BEGIN_BATCH(7);
> +  OUT_BATCH(opcode << 16 | (7 - 2));
> +  OUT_BATCH(read_lengths[0] | read_lengths[1] << 16);
> +  OUT_BATCH(read_lengths[2] | read_lengths[3] << 16);
> +  OUT_BATCH(offsets[0]);
> +  OUT_PTR(bufs[1], offsets[1]);
> +  OUT_PTR(bufs[2], offsets[2]);
> +  OUT_PTR(bufs[3], offsets[3]);
> +  ADVANCE_BATCH();
> +   } else if (brw->gen == 6) {
> +  /* From the Sandybridge PRM, Volume 2, Part 1, Page 138:
> +   * "The sum of all four read length fields (each incremented to
> +   *  represent the actual read length) must be less than or equal
> +   *  to 32."
> +   */
> +  assert(read_lengths[0] + read_lengths[1] +
> + read_lengths[2] + read_lengths[3] < 32);
> +
> +  BEGIN_BATCH(5);
> +  OUT_BATCH(opcode << 16 | (5 - 2) |
> +(read_lengths[0] ? GEN6_CONSTANT_BUFFER_0_ENABLE : 0) |
> +(read_lengths[1] ? GEN6_CONSTANT_BUFFER_1_ENABLE : 0) |
> +(read_lengths[2] ? GEN6_CONSTANT_BUFFER_2_ENABLE : 0) |
> +(read_lengths[3] ? GEN6_CONSTANT_BUFFER_3_ENABLE : 0));
> +  OUT_BATCH(offsets[0] | (read_lengths[0] - 1));
> +  OUT_PTR(bufs[1], offsets[1] | (read_lengths[1] - 1));
> +  OUT_PTR(bufs[2], offsets[2] | (read_lengths[2] - 1));
> +  OUT_PTR(bufs[3], 

[Mesa-dev] [Bug 99817] [softpipe] piglit glsl-fs-tan-1 regression

[bugzilla-daemon]

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

Vinson Lee  changed:

   What|Removed |Added

   Keywords||bisected
 CC||i...@freedesktop.org

--- Comment #3 from Vinson Lee  ---
e9ffd12827ac11a2d2002a42fa8eb1df847153ba is the first bad commit
commit e9ffd12827ac11a2d2002a42fa8eb1df847153ba
Author: Francisco Jerez 
Date:   Sat Jan 21 13:41:08 2017 -0800

glsl: Rewrite atan2 implementation to fix accuracy and handling of
zero/infinity.

This addresses several issues of the current atan2 implementation:

 - Negative zero (and negative denorms which end up getting flushed to
   zero) isn't handled correctly by the current implementation.  The
   reason is that it does 'y >= 0' and 'x < 0' comparisons to decide
   on which side of the branch cut the argument is, which causes us to
   return incorrect results (off by up to 2π) for very small negative
   values.

 - There is a serious precision problem for x values of large enough
   magnitude introduced by the floating point division operation being
   implemented as a mul+rcp sequence.  This can lead to the quotient
   getting flushed to zero in some cases introducing an error of over
   8e6 ULP in the result -- Or in the most catastrophic case will
   cause us to return NaN instead of the correct value ±π/2 for y=±∞
   and x very large.  We can fix this easily by scaling down both
   arguments when the absolute value of the denominator goes above
   certain threshold.  The error of this atan2 implementation remains
   below 25 ULP in most of its domain except for a neighborhood of y=0
   where it reaches a maximum error of about 180 ULP.

 - It emits a bunch of instructions including no less than three
   if-else branches per scalar component that don't seem to get
   optimized out later on.  This implementation uses about 13% less
   instructions on Intel SKL hardware and doesn't emit any control
   flow instructions.

v2: Fix up argument scaling to take into account the range and
precision of exotic FP24 hardware.  Flip coordinate system for
arguments along the vertical line as if they were on the left
half-plane in order to avoid division by zero which may give
unspecified results on non-GLSL 4.1-capable hardware.  Sprinkle in
some more comments.

Reviewed-by: Ian Romanick 

:04 04 acb11a161d3a4b78c246efd2d3720e8d66c8772a
89658b9bde1aa03b542528f4cae464516e8db300 M  src
bisect run success

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

Re: [Mesa-dev] [PATCH] anv: implement pipeline statistics queries

[Ilia Mirkin]

On Tue, Jan 24, 2017 at 5:27 PM, Robert Bragg  wrote:
> Depending on how strictly we consider that the queries should only measure
> the commands they bracket then I think some stalling will be necessary to
> serialize the work associated with a query and defer reading the end state
> until after the relevant stages have completed their work.
>
> We aren't very precise about this in GL currently, but in Begin maybe we
> should stall until everything >= the statistic-stage is idle and in End
> stall until everything <= the statistic-stage is idle before reading
> (where
> 'statistic-stage' here is the pipeline stage associated with the pipeline
> statistic being queried (or respectively the min/max stage for a set)).
>
> For reference in my implementation of INTEL_performance_query facing this
> same question, I'm currently just stalling before and after queries:
>
>
> https://github.com/rib/mesa/blob/wip/rib/oa-next/src/mesa/drivers/dri/i965/brw_performance_query.c#L994
>
> https://github.com/rib/mesa/blob/wip/rib/oa-next/src/mesa/drivers/dri/i965/brw_performance_query.c#L1136

 So that's essentially what I'm doing here, I think. (And what the GL
 driver does.)
>
> Yup, the upshot might just be a comment explaining the need for a
> stall. I think we probably need a stall in CmdEndQuery too, otherwise
> the command streamer may read the end counter before the work has
> finished.

Robert,

Can you give me some examples of how I might implement this? I'm not
so familiar with the Intel HW to know this offhand. Mostly hoping you
can point me at a mapping of which bit in what command corresponds to
which stage.

Thanks,

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

[Mesa-dev] [PATCH 4/5] nir/lower_indirect: Use nir_builder control-flow helpers

[Jason Ekstrand]

---
 src/compiler/nir/nir_lower_indirect_derefs.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/src/compiler/nir/nir_lower_indirect_derefs.c 
b/src/compiler/nir/nir_lower_indirect_derefs.c
index 09cc9a3..52adde8 100644
--- a/src/compiler/nir/nir_lower_indirect_derefs.c
+++ b/src/compiler/nir/nir_lower_indirect_derefs.c
@@ -55,20 +55,15 @@ emit_indirect_load_store(nir_builder *b, 
nir_intrinsic_instr *orig_instr,
 
   nir_ssa_def *then_dest, *else_dest;
 
-  nir_if *if_stmt = nir_if_create(b->shader);
-  if_stmt->condition = nir_src_for_ssa(nir_ilt(b, arr->indirect.ssa,
-  nir_imm_int(b, mid)));
-  nir_cf_node_insert(b->cursor, _stmt->cf_node);
-
-  b->cursor = nir_after_cf_list(_stmt->then_list);
+  nir_push_if(b, nir_ilt(b, arr->indirect.ssa, nir_imm_int(b, mid)));
   emit_indirect_load_store(b, orig_instr, deref, arr_parent,
start, mid, _dest, src);
-
-  b->cursor = nir_after_cf_list(_stmt->else_list);
+  nir_block *then_block = nir_cursor_current_block(b->cursor);
+  nir_push_else(b, NULL);
   emit_indirect_load_store(b, orig_instr, deref, arr_parent,
mid, end, _dest, src);
-
-  b->cursor = nir_after_cf_node(_stmt->cf_node);
+  nir_block *else_block = nir_cursor_current_block(b->cursor);
+  nir_pop_if(b, NULL);
 
   if (src == NULL) {
  /* We're a load.  We need to insert a phi node */
@@ -78,12 +73,12 @@ emit_indirect_load_store(nir_builder *b, 
nir_intrinsic_instr *orig_instr,
then_dest->num_components, bit_size, NULL);
 
  nir_phi_src *src0 = ralloc(phi, nir_phi_src);
- src0->pred = nir_if_last_then_block(if_stmt);
+ src0->pred = then_block;
  src0->src = nir_src_for_ssa(then_dest);
  exec_list_push_tail(>srcs, >node);
 
  nir_phi_src *src1 = ralloc(phi, nir_phi_src);
- src1->pred = nir_if_last_else_block(if_stmt);
+ src1->pred = else_block;
  src1->src = nir_src_for_ssa(else_dest);
  exec_list_push_tail(>srcs, >node);
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 0/5] nir/builder: Add control-flow helpers

[Jason Ekstrand]

I was looking at Ian's int64 lowering code last night and was thinking
about what the lowering would look like in NIR.  The fact that it uses
loops and other control flow for handling division got me thinking about
doing control flow in nir_builder again.  So I spent a little time this
morning and hacked up this API.  All in all, I'm pretty happy with it.
Comments welcome.

Jason Ekstrand (5):
  nir/builder: Add support for easily building control-flow
  glsl/nir: Use nir_builder's new control-flow helpers
  nir/lower_gs_intrinsics: Use nir_builder control-flow helpers
  nir/lower_indirect: Use nir_builder control-flow helpers
  spirv: Use nir_builder for control flow

 src/compiler/glsl/glsl_to_nir.cpp| 38 +---
 src/compiler/nir/nir_builder.h   | 67 
 src/compiler/nir/nir_lower_gs_intrinsics.c   |  9 ++--
 src/compiler/nir/nir_lower_indirect_derefs.c | 19 +++-
 src/compiler/spirv/vtn_cfg.c | 45 ++-
 5 files changed, 102 insertions(+), 76 deletions(-)

-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 3/5] nir/lower_gs_intrinsics: Use nir_builder control-flow helpers

[Jason Ekstrand]

---
 src/compiler/nir/nir_lower_gs_intrinsics.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/src/compiler/nir/nir_lower_gs_intrinsics.c 
b/src/compiler/nir/nir_lower_gs_intrinsics.c
index 3acb742..68e20dd 100644
--- a/src/compiler/nir/nir_lower_gs_intrinsics.c
+++ b/src/compiler/nir/nir_lower_gs_intrinsics.c
@@ -84,12 +84,7 @@ rewrite_emit_vertex(nir_intrinsic_instr *intrin, struct 
state *state)
 * The new if statement needs to be hooked up to the control flow graph
 * before we start inserting instructions into it.
 */
-   nir_if *if_stmt = nir_if_create(b->shader);
-   if_stmt->condition = nir_src_for_ssa(nir_ilt(b, count, max_vertices));
-   nir_builder_cf_insert(b, _stmt->cf_node);
-
-   /* Fill out the new then-block */
-   b->cursor = nir_after_cf_list(_stmt->then_list);
+   nir_push_if(b, nir_ilt(b, count, max_vertices));
 
nir_intrinsic_instr *lowered =
   nir_intrinsic_instr_create(b->shader,
@@ -103,6 +98,8 @@ rewrite_emit_vertex(nir_intrinsic_instr *intrin, struct 
state *state)
  nir_iadd(b, count, nir_imm_int(b, 1)),
  0x1); /* .x */
 
+   nir_pop_if(b, NULL);
+
nir_instr_remove(>instr);
 
state->progress = true;
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 5/5] spirv: Use nir_builder for control flow

[Jason Ekstrand]

---
 src/compiler/spirv/vtn_cfg.c | 45 ++--
 1 file changed, 14 insertions(+), 31 deletions(-)

diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 3a31657..54248b1 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -610,15 +610,10 @@ vtn_emit_cf_list(struct vtn_builder *b, struct list_head 
*cf_list,
 
   case vtn_cf_node_type_if: {
  struct vtn_if *vtn_if = (struct vtn_if *)node;
-
- nir_if *if_stmt = nir_if_create(b->shader);
- if_stmt->condition =
-nir_src_for_ssa(vtn_ssa_value(b, vtn_if->condition)->def);
- nir_cf_node_insert(b->nb.cursor, _stmt->cf_node);
-
  bool sw_break = false;
 
- b->nb.cursor = nir_after_cf_list(_stmt->then_list);
+ nir_if *nif =
+nir_push_if(>nb, vtn_ssa_value(b, vtn_if->condition)->def);
  if (vtn_if->then_type == vtn_branch_type_none) {
 vtn_emit_cf_list(b, _if->then_body,
  switch_fall_var, _break, handler);
@@ -626,7 +621,7 @@ vtn_emit_cf_list(struct vtn_builder *b, struct list_head 
*cf_list,
 vtn_emit_branch(b, vtn_if->then_type, switch_fall_var, _break);
  }
 
- b->nb.cursor = nir_after_cf_list(_stmt->else_list);
+ nir_push_else(>nb, nif);
  if (vtn_if->else_type == vtn_branch_type_none) {
 vtn_emit_cf_list(b, _if->else_body,
  switch_fall_var, _break, handler);
@@ -634,7 +629,7 @@ vtn_emit_cf_list(struct vtn_builder *b, struct list_head 
*cf_list,
 vtn_emit_branch(b, vtn_if->else_type, switch_fall_var, _break);
  }
 
- b->nb.cursor = nir_after_cf_node(_stmt->cf_node);
+ nir_pop_if(>nb, nif);
 
  /* If we encountered a switch break somewhere inside of the if,
   * then it would have been handled correctly by calling
@@ -644,13 +639,7 @@ vtn_emit_cf_list(struct vtn_builder *b, struct list_head 
*cf_list,
   */
  if (sw_break) {
 *has_switch_break = true;
-
-nir_if *switch_if = nir_if_create(b->shader);
-switch_if->condition =
-   nir_src_for_ssa(nir_load_var(>nb, switch_fall_var));
-nir_cf_node_insert(b->nb.cursor, _if->cf_node);
-
-b->nb.cursor = nir_after_cf_list(_stmt->then_list);
+nir_push_if(>nb, nir_load_var(>nb, switch_fall_var));
  }
  break;
   }
@@ -658,10 +647,7 @@ vtn_emit_cf_list(struct vtn_builder *b, struct list_head 
*cf_list,
   case vtn_cf_node_type_loop: {
  struct vtn_loop *vtn_loop = (struct vtn_loop *)node;
 
- nir_loop *loop = nir_loop_create(b->shader);
- nir_cf_node_insert(b->nb.cursor, >cf_node);
-
- b->nb.cursor = nir_after_cf_list(>body);
+ nir_loop *loop = nir_push_loop(>nb);
  vtn_emit_cf_list(b, _loop->body, NULL, NULL, handler);
 
  if (!list_empty(_loop->cont_body)) {
@@ -676,20 +662,20 @@ vtn_emit_cf_list(struct vtn_builder *b, struct list_head 
*cf_list,
 nir_store_var(>nb, do_cont, nir_imm_int(>nb, NIR_FALSE), 1);
 
 b->nb.cursor = nir_before_cf_list(>body);
-nir_if *cont_if = nir_if_create(b->shader);
-cont_if->condition = nir_src_for_ssa(nir_load_var(>nb, 
do_cont));
-nir_cf_node_insert(b->nb.cursor, _if->cf_node);
 
-b->nb.cursor = nir_after_cf_list(_if->then_list);
+nir_if *cont_if =
+   nir_push_if(>nb, nir_load_var(>nb, do_cont));
+
 vtn_emit_cf_list(b, _loop->cont_body, NULL, NULL, handler);
 
-b->nb.cursor = nir_after_cf_node(_if->cf_node);
+nir_pop_if(>nb, cont_if);
+
 nir_store_var(>nb, do_cont, nir_imm_int(>nb, NIR_TRUE), 1);
 
 b->has_loop_continue = true;
  }
 
- b->nb.cursor = nir_after_cf_node(>cf_node);
+ nir_pop_loop(>nb, loop);
  break;
   }
 
@@ -747,17 +733,14 @@ vtn_emit_cf_list(struct vtn_builder *b, struct list_head 
*cf_list,
 /* Take fallthrough into account */
 cond = nir_ior(>nb, cond, nir_load_var(>nb, fall_var));
 
-nir_if *case_if = nir_if_create(b->nb.shader);
-case_if->condition = nir_src_for_ssa(cond);
-nir_cf_node_insert(b->nb.cursor, _if->cf_node);
+nir_if *case_if = nir_push_if(>nb, cond);
 
 bool has_break = false;
-b->nb.cursor = nir_after_cf_list(_if->then_list);
 nir_store_var(>nb, fall_var, nir_imm_int(>nb, NIR_TRUE), 1);
 vtn_emit_cf_list(b, >body, fall_var, _break, handler);
 (void)has_break; /* We don't care */
 
-b->nb.cursor = nir_after_cf_node(_if->cf_node);
+nir_pop_if(>nb, case_if);
  }
  assert(i == num_cases);
 
-- 
2.5.0.400.gff86faf

___
mesa-dev 

[Mesa-dev] [PATCH 2/5] glsl/nir: Use nir_builder's new control-flow helpers

[Jason Ekstrand]

---
 src/compiler/glsl/glsl_to_nir.cpp | 38 +++---
 1 file changed, 11 insertions(+), 27 deletions(-)

diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
b/src/compiler/glsl/glsl_to_nir.cpp
index 96d8164..e46fe2c 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -520,31 +520,19 @@ nir_visitor::visit(ir_function_signature *ir)
 void
 nir_visitor::visit(ir_loop *ir)
 {
-   nir_loop *loop = nir_loop_create(this->shader);
-   nir_builder_cf_insert(, >cf_node);
-
-   b.cursor = nir_after_cf_list(>body);
+   nir_push_loop();
visit_exec_list(>body_instructions, this);
-   b.cursor = nir_after_cf_node(>cf_node);
+   nir_pop_loop(, NULL);
 }
 
 void
 nir_visitor::visit(ir_if *ir)
 {
-   nir_src condition =
-  nir_src_for_ssa(evaluate_rvalue(ir->condition));
-
-   nir_if *if_stmt = nir_if_create(this->shader);
-   if_stmt->condition = condition;
-   nir_builder_cf_insert(, _stmt->cf_node);
-
-   b.cursor = nir_after_cf_list(_stmt->then_list);
+   nir_push_if(, evaluate_rvalue(ir->condition));
visit_exec_list(>then_instructions, this);
-
-   b.cursor = nir_after_cf_list(_stmt->else_list);
+   nir_push_else(, NULL);
visit_exec_list(>else_instructions, this);
-
-   b.cursor = nir_after_cf_node(_stmt->cf_node);
+   nir_pop_if(, NULL);
 }
 
 void
@@ -1193,11 +1181,9 @@ nir_visitor::visit(ir_assignment *ir)
   copy->variables[1] = evaluate_deref(>instr, ir->rhs);
 
   if (ir->condition) {
- nir_if *if_stmt = nir_if_create(this->shader);
- if_stmt->condition = nir_src_for_ssa(evaluate_rvalue(ir->condition));
- nir_builder_cf_insert(, _stmt->cf_node);
- nir_instr_insert_after_cf_list(_stmt->then_list, >instr);
- b.cursor = nir_after_cf_node(_stmt->cf_node);
+ nir_push_if(, evaluate_rvalue(ir->condition));
+ nir_builder_instr_insert(, >instr);
+ nir_pop_if(, NULL);
   } else {
  nir_builder_instr_insert(, >instr);
   }
@@ -1232,11 +1218,9 @@ nir_visitor::visit(ir_assignment *ir)
store->src[0] = nir_src_for_ssa(src);
 
if (ir->condition) {
-  nir_if *if_stmt = nir_if_create(this->shader);
-  if_stmt->condition = nir_src_for_ssa(evaluate_rvalue(ir->condition));
-  nir_builder_cf_insert(, _stmt->cf_node);
-  nir_instr_insert_after_cf_list(_stmt->then_list, >instr);
-  b.cursor = nir_after_cf_node(_stmt->cf_node);
+  nir_push_if(, evaluate_rvalue(ir->condition));
+  nir_builder_instr_insert(, >instr);
+  nir_pop_if(, NULL);
} else {
   nir_builder_instr_insert(, >instr);
}
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 1/5] nir/builder: Add support for easily building control-flow

[Jason Ekstrand]

Each of the pop functions (and push_else) take a control flow parameter as
their second argument.  If NULL, it assumes that the builder is in a block
that's a direct child of the control-flow node you want to pop off the
virtual stack.  This is what 90% of consumers will want.  The SPIR-V pass,
however, is a bit more "creative" about how it walks the CFG and it needs
to be able to pop multiple levels at a time, hence the argument.

---
 src/compiler/nir/nir_builder.h | 67 ++
 1 file changed, 67 insertions(+)

diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
index 194d327..7fde57e 100644
--- a/src/compiler/nir/nir_builder.h
+++ b/src/compiler/nir/nir_builder.h
@@ -81,6 +81,73 @@ nir_builder_cf_insert(nir_builder *build, nir_cf_node *cf)
nir_cf_node_insert(build->cursor, cf);
 }
 
+static inline bool
+nir_builder_is_inside_cf(nir_builder *build, nir_cf_node *cf_node)
+{
+   nir_block *block = nir_cursor_current_block(build->cursor);
+   for (nir_cf_node *n = >cf_node; n; n = n->parent) {
+  if (n == cf_node)
+ return true;
+   }
+   return false;
+}
+
+static inline nir_if *
+nir_push_if(nir_builder *build, nir_ssa_def *condition)
+{
+   nir_if *nif = nir_if_create(build->shader);
+   nif->condition = nir_src_for_ssa(condition);
+   nir_builder_cf_insert(build, >cf_node);
+   build->cursor = nir_before_cf_list(>then_list);
+   return nif;
+}
+
+static inline nir_if *
+nir_push_else(nir_builder *build, nir_if *nif)
+{
+   if (nif) {
+  assert(nir_builder_is_inside_cf(build, >cf_node));
+   } else {
+  nir_block *block = nir_cursor_current_block(build->cursor);
+  nif = nir_cf_node_as_if(block->cf_node.parent);
+   }
+   build->cursor = nir_before_cf_list(>else_list);
+   return nif;
+}
+
+static inline void
+nir_pop_if(nir_builder *build, nir_if *nif)
+{
+   if (nif) {
+  assert(nir_builder_is_inside_cf(build, >cf_node));
+   } else {
+  nir_block *block = nir_cursor_current_block(build->cursor);
+  nif = nir_cf_node_as_if(block->cf_node.parent);
+   }
+   build->cursor = nir_after_cf_node(>cf_node);
+}
+
+static inline nir_loop *
+nir_push_loop(nir_builder *build)
+{
+   nir_loop *loop = nir_loop_create(build->shader);
+   nir_builder_cf_insert(build, >cf_node);
+   build->cursor = nir_before_cf_list(>body);
+   return loop;
+}
+
+static inline void
+nir_pop_loop(nir_builder *build, nir_loop *loop)
+{
+   if (loop) {
+  assert(nir_builder_is_inside_cf(build, >cf_node));
+   } else {
+  nir_block *block = nir_cursor_current_block(build->cursor);
+  loop = nir_cf_node_as_loop(block->cf_node.parent);
+   }
+   build->cursor = nir_after_cf_node(>cf_node);
+}
+
 static inline nir_ssa_def *
 nir_ssa_undef(nir_builder *build, unsigned num_components, unsigned bit_size)
 {
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH] [swr] fix windows build

[Ilia Mirkin]

Yeah, just like all the other headers:

#ifdef __cplusplus
extern "C" {
#endif

define api's

#ifdef __cplusplus
}
#endif

You can see examples in, e.g., u_bitcast.h (picked one at random).

On Wed, Feb 15, 2017 at 5:45 PM, Kyriazis, George
 wrote:
> You mean use extern "C" (inside a c++ guard) on u_upload_mgr.h and friends?
>
> Thanks,
>
> George
>
>> -Original Message-
>> From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia
>> Mirkin
>> Sent: Wednesday, February 15, 2017 4:25 PM
>> To: Kyriazis, George 
>> Cc: mesa-dev@lists.freedesktop.org
>> Subject: Re: [Mesa-dev] [PATCH] [swr] fix windows build
>>
>> I'd rather see the remainder of the headers fixed to be includable from C++
>> contexts. extern "C" { #include } is an anti-pattern...
>>
>>   -ilia
>>
>> On Wed, Feb 15, 2017 at 5:23 PM, George Kyriazis
>>  wrote:
>> > move util/u_upload_mgr.h inside extern "C"
>> > ---
>> >  src/gallium/drivers/swr/swr_context.cpp | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/src/gallium/drivers/swr/swr_context.cpp
>> > b/src/gallium/drivers/swr/swr_context.cpp
>> > index 2e37bac..04ff146 100644
>> > --- a/src/gallium/drivers/swr/swr_context.cpp
>> > +++ b/src/gallium/drivers/swr/swr_context.cpp
>> > @@ -33,9 +33,9 @@
>> >  #include "util/u_inlines.h"
>> >  #include "util/u_format.h"
>> >  #include "util/u_atomic.h"
>> > -#include "util/u_upload_mgr.h"
>> >
>> >  extern "C" {
>> > +#include "util/u_upload_mgr.h"
>> >  #include "util/u_transfer.h"
>> >  #include "util/u_surface.h"
>> >  }
>> > --
>> > 2.7.4
>> >
>> > ___
>> > 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] [swr] fix windows build

[Kyriazis, George]

You mean use extern "C" (inside a c++ guard) on u_upload_mgr.h and friends?

Thanks,

George

> -Original Message-
> From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia
> Mirkin
> Sent: Wednesday, February 15, 2017 4:25 PM
> To: Kyriazis, George 
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] [swr] fix windows build
> 
> I'd rather see the remainder of the headers fixed to be includable from C++
> contexts. extern "C" { #include } is an anti-pattern...
> 
>   -ilia
> 
> On Wed, Feb 15, 2017 at 5:23 PM, George Kyriazis
>  wrote:
> > move util/u_upload_mgr.h inside extern "C"
> > ---
> >  src/gallium/drivers/swr/swr_context.cpp | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/swr/swr_context.cpp
> > b/src/gallium/drivers/swr/swr_context.cpp
> > index 2e37bac..04ff146 100644
> > --- a/src/gallium/drivers/swr/swr_context.cpp
> > +++ b/src/gallium/drivers/swr/swr_context.cpp
> > @@ -33,9 +33,9 @@
> >  #include "util/u_inlines.h"
> >  #include "util/u_format.h"
> >  #include "util/u_atomic.h"
> > -#include "util/u_upload_mgr.h"
> >
> >  extern "C" {
> > +#include "util/u_upload_mgr.h"
> >  #include "util/u_transfer.h"
> >  #include "util/u_surface.h"
> >  }
> > --
> > 2.7.4
> >
> > ___
> > 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] util/disk_cache: do not allow space in MESA_GLSL_CACHE_MAX_SIZE

[Timothy Arceri]

On 16/02/17 03:37, Emil Velikov wrote:

On 9 February 2017 at 13:35, Emil Velikov  wrote:

From: Emil Velikov 

No other env var used in mesa allows for space in the variable contents.

Signed-off-by: Emil Velikov 
---
Worth documenting and/or even renaming them ?

Tim, with the documentation going in, we can land this ?


Sure. I didn't write this code so not sure what the think was behind 
allowing spaces.


Acked-by: Timothy Arceri 



We might even go a step further droping the lowercase aliases - k, m, g  :-)
But that for another time.

Emil
___
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] [swr] fix windows build

[Ilia Mirkin]

I'd rather see the remainder of the headers fixed to be includable
from C++ contexts. extern "C" { #include } is an anti-pattern...

  -ilia

On Wed, Feb 15, 2017 at 5:23 PM, George Kyriazis
 wrote:
> move util/u_upload_mgr.h inside extern "C"
> ---
>  src/gallium/drivers/swr/swr_context.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/swr/swr_context.cpp 
> b/src/gallium/drivers/swr/swr_context.cpp
> index 2e37bac..04ff146 100644
> --- a/src/gallium/drivers/swr/swr_context.cpp
> +++ b/src/gallium/drivers/swr/swr_context.cpp
> @@ -33,9 +33,9 @@
>  #include "util/u_inlines.h"
>  #include "util/u_format.h"
>  #include "util/u_atomic.h"
> -#include "util/u_upload_mgr.h"
>
>  extern "C" {
> +#include "util/u_upload_mgr.h"
>  #include "util/u_transfer.h"
>  #include "util/u_surface.h"
>  }
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] [swr] fix windows build

[George Kyriazis]

move util/u_upload_mgr.h inside extern "C"
---
 src/gallium/drivers/swr/swr_context.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/swr/swr_context.cpp 
b/src/gallium/drivers/swr/swr_context.cpp
index 2e37bac..04ff146 100644
--- a/src/gallium/drivers/swr/swr_context.cpp
+++ b/src/gallium/drivers/swr/swr_context.cpp
@@ -33,9 +33,9 @@
 #include "util/u_inlines.h"
 #include "util/u_format.h"
 #include "util/u_atomic.h"
-#include "util/u_upload_mgr.h"
 
 extern "C" {
+#include "util/u_upload_mgr.h"
 #include "util/u_transfer.h"
 #include "util/u_surface.h"
 }
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 2/2] anv: Use build-id for pipeline cache UUID.

[Jason Ekstrand]

On Wed, Feb 15, 2017 at 1:54 PM, Chad Versace 
wrote:

> On Wed 15 Feb 2017, Emil Velikov wrote:
> > On 14 February 2017 at 21:02, Chad Versace 
> wrote:
> > > On Tue 14 Feb 2017, Kenneth Graunke wrote:
> > >> On Tuesday, February 14, 2017 12:38:45 PM PST Chad Versace wrote:
> > >> > On Tue 14 Feb 2017, Matt Turner wrote:
> > >> >
> > >> >
> > >> > >  static bool
> > >> > > -anv_get_function_timestamp(void *ptr, uint32_t* timestamp)
> > >> > > +anv_device_get_cache_uuid(void *uuid)
> > >> > >  {
> > >> > > -   Dl_info info;
> > >> > > -   struct stat st;
> > >> > > -   if (!dladdr(ptr, ) || !info.dli_fname)
> > >> > > +   const struct note *note = build_id_find_nhdr("libvulkan_
> intel.so");
> > >> > > +   if (!note)
> > >> > >return false;
> > >> > >
> > >> > > -   if (stat(info.dli_fname, ))
> > >> > > +   unsigned len = build_id_length(note);
> > >> > > +   if (len < VK_UUID_SIZE)
> > >> > >return false;
> > >> > >
> > >> > > -   *timestamp = st.st_mtim.tv_sec;
> > >> > > -   return true;
> > >> > > -}
> > >> > > -
> > >> > > -static bool
> > >> > > -anv_device_get_cache_uuid(void *uuid)
> > >> > > -{
> > >> > > -   uint32_t timestamp;
> > >> > > -
> > >> > > -   memset(uuid, 0, VK_UUID_SIZE);
> > >> > > -   if (!anv_get_function_timestamp(anv_device_get_cache_uuid,
> ))
> > >> > > +   unsigned char *build_id = malloc(len);
> > >> > > +   if (!build_id)
> > >> > >return false;
> > >> > >
> > >> > > -   snprintf(uuid, VK_UUID_SIZE, "anv-%d", timestamp);
> > >> > > +   build_id_read(note, build_id);
> > >> > > +
> > >> > > +   memcpy(uuid, build_id, VK_UUID_SIZE);
> > >> > > +   free(build_id);
> > >> >
> > >> > The Vulkan spec frowns on memory allocations when not needed. If you
> > >> > must allocate memory here, then it should be through the VkInstance
> > >> > allocation callbacks. However, it's best to avoid the allocation by
> > >> > adding a size_t parameter, à la snprintf, to build_id_read().
> > >> >
> > >> > Otherwise, the patch looks good to me.
> > >>
> > >> You're worried about the performance of anv_physical_device_init()?
> > >> This doesn't happen on lookup...just driver start up...
> > >
> > > I'm not worried about performance here. That would be foolish.
> > >
> > > I'm concerned about complying the expectations provided to advanced
> > > users by the Vulkan spec.
>
> > Hi Chad, pardon for dropping in uninvited:
> >
> > Spec mandates that only the implementation should use the allocation
> > callbacks, and not any of it's dependencies (say something in the C
> > runtime/other library), correct ?
>
> > Or does it implicitly that "Thou Shalt override the weak
> > [mc]alloc/friends symbols provided by your C runtime" ?
>
> The spec actually says neither. It is vague on this topic, but vague in
> a hyper-detailed fashion, which is typical of Khronos specs.
>
> I interpret "Chapter 10. Memory Allocation" as saying:
>
> - If the user supplies allocation callbacks, then the spec
>   recommends that the implementation use them. (The spec doesn't say
>   *should*, *suggest*, *must*, *shall*, or anything like that here,
>   as far as I can tell. It's my interpretation that Ch10 is primarily a
>   a recommendation.
>
> - If the implementation does use an allocation callback, Ch10
>   defines precise constraints on how the implementation must use it.
>
> - Ch10 admits that the implementation may need to allocate internal
>   memory, without using the callbacks. However, Ch10 seem to say
>   that such internal allocations are soley for executable memory.
>   Again, one could interpret the spec differently here.
>
> > Although the src/intel is [almost] perfect, the i965 compiler still
> > explicitly and implicitly uses [mc]alloc. Not mean to be bashful, just
> > pointing out what may not be obvious at first.
>
> Yep. The compiler doesn't use the allocation callbacks. For that matter,
> even printf calls malloc on some libc implementations.


Yeah, I think you're worrying too much.  Sure, it might be a nicer API if
get_build_id did a copy into a provided array, but I wouldn't make any
malloc arguments.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] anv: Use build-id for pipeline cache UUID.

[Chad Versace]

On Wed 15 Feb 2017, Emil Velikov wrote:
> On 14 February 2017 at 21:02, Chad Versace  wrote:
> > On Tue 14 Feb 2017, Kenneth Graunke wrote:
> >> On Tuesday, February 14, 2017 12:38:45 PM PST Chad Versace wrote:
> >> > On Tue 14 Feb 2017, Matt Turner wrote:
> >> >
> >> >
> >> > >  static bool
> >> > > -anv_get_function_timestamp(void *ptr, uint32_t* timestamp)
> >> > > +anv_device_get_cache_uuid(void *uuid)
> >> > >  {
> >> > > -   Dl_info info;
> >> > > -   struct stat st;
> >> > > -   if (!dladdr(ptr, ) || !info.dli_fname)
> >> > > +   const struct note *note = build_id_find_nhdr("libvulkan_intel.so");
> >> > > +   if (!note)
> >> > >return false;
> >> > >
> >> > > -   if (stat(info.dli_fname, ))
> >> > > +   unsigned len = build_id_length(note);
> >> > > +   if (len < VK_UUID_SIZE)
> >> > >return false;
> >> > >
> >> > > -   *timestamp = st.st_mtim.tv_sec;
> >> > > -   return true;
> >> > > -}
> >> > > -
> >> > > -static bool
> >> > > -anv_device_get_cache_uuid(void *uuid)
> >> > > -{
> >> > > -   uint32_t timestamp;
> >> > > -
> >> > > -   memset(uuid, 0, VK_UUID_SIZE);
> >> > > -   if (!anv_get_function_timestamp(anv_device_get_cache_uuid, 
> >> > > ))
> >> > > +   unsigned char *build_id = malloc(len);
> >> > > +   if (!build_id)
> >> > >return false;
> >> > >
> >> > > -   snprintf(uuid, VK_UUID_SIZE, "anv-%d", timestamp);
> >> > > +   build_id_read(note, build_id);
> >> > > +
> >> > > +   memcpy(uuid, build_id, VK_UUID_SIZE);
> >> > > +   free(build_id);
> >> >
> >> > The Vulkan spec frowns on memory allocations when not needed. If you
> >> > must allocate memory here, then it should be through the VkInstance
> >> > allocation callbacks. However, it's best to avoid the allocation by
> >> > adding a size_t parameter, à la snprintf, to build_id_read().
> >> >
> >> > Otherwise, the patch looks good to me.
> >>
> >> You're worried about the performance of anv_physical_device_init()?
> >> This doesn't happen on lookup...just driver start up...
> >
> > I'm not worried about performance here. That would be foolish.
> >
> > I'm concerned about complying the expectations provided to advanced
> > users by the Vulkan spec.

> Hi Chad, pardon for dropping in uninvited:
> 
> Spec mandates that only the implementation should use the allocation
> callbacks, and not any of it's dependencies (say something in the C
> runtime/other library), correct ?

> Or does it implicitly that "Thou Shalt override the weak
> [mc]alloc/friends symbols provided by your C runtime" ?

The spec actually says neither. It is vague on this topic, but vague in
a hyper-detailed fashion, which is typical of Khronos specs.

I interpret "Chapter 10. Memory Allocation" as saying:

- If the user supplies allocation callbacks, then the spec
  recommends that the implementation use them. (The spec doesn't say
  *should*, *suggest*, *must*, *shall*, or anything like that here,
  as far as I can tell. It's my interpretation that Ch10 is primarily a
  a recommendation.

- If the implementation does use an allocation callback, Ch10
  defines precise constraints on how the implementation must use it.

- Ch10 admits that the implementation may need to allocate internal
  memory, without using the callbacks. However, Ch10 seem to say
  that such internal allocations are soley for executable memory.
  Again, one could interpret the spec differently here.

> Although the src/intel is [almost] perfect, the i965 compiler still
> explicitly and implicitly uses [mc]alloc. Not mean to be bashful, just
> pointing out what may not be obvious at first.

Yep. The compiler doesn't use the allocation callbacks. For that matter,
even printf calls malloc on some libc implementations.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] How about vk_features.txt?

[Romain Failliot]

I won't have time for the next 2 weeks, but after that I'll propose a file
formatted in a way that is both easy to parse and easy to edit by a human.

2017-02-12 21:58 GMT-05:00 Jason Ekstrand :

> I'm certainly not opposed.  I've considered adding such a tracking file
> for a while.  I'm not sure whether or not it's needed but it wouldn't hurt.
>
> On Sun, Feb 12, 2017 at 6:48 PM, Romain Failliot <
> romain.faill...@foolstep.com> wrote:
>
>> Hi!
>>
>> I regularly receive questions about having Mesamatrix tracking the state
>> of Vulkan API for ANV and RADV.
>>
>> I don't think there is a file in mesa repo that state the progression of
>> Vulkan on each driver. So if you're interested, I could generate a base
>> file (xml?) extracting the  tag from the official API (
>> https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0/src/
>> spec/vk.xml#L4117) and maybe the  tag as well, if you want.
>> Then you could simply add the status of each "feature" for RADV and ANV.
>>
>> I'm open to discussion if you think it's a good idea. I don't know
>> exactly what you would need to simplify the task as much as possible. But I
>> think we could use our experience on features.txt to build something both
>> more structured and easier to read (for a human and a machine)
>>
>> Cheers!
>>
>> --
>> Romain "Creak" Failliot
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>>
>


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

[Mesa-dev] [PATCH 1/3] Separate INTEL_performance_query frontend

[Robert Bragg]

To allow the backend interfaces for AMD_performance_monitor and
INTEL_performance_query to evolve independently based on the more
specific requirements of each extension this starts by separating
the frontends of these extensions.

Even though there wasn't much tying these frontends together, this
separation intentionally copies what few helpers/utilities that were
shared between the two extensions, avoiding any re-factoring specific to
INTEL_performance_query so that the evolution will be easier to follow
later.

Signed-off-by: Robert Bragg 
---
 src/mapi/glapi/gen/gl_genexec.py|   1 +
 src/mesa/Makefile.sources   |   2 +
 src/mesa/main/context.c |   3 +
 src/mesa/main/mtypes.h  |  15 +
 src/mesa/main/performance_monitor.c | 590 ---
 src/mesa/main/performance_monitor.h |  39 --
 src/mesa/main/performance_query.c   | 784 
 src/mesa/main/performance_query.h   |  84 
 8 files changed, 889 insertions(+), 629 deletions(-)
 create mode 100644 src/mesa/main/performance_query.c
 create mode 100644 src/mesa/main/performance_query.h

diff --git a/src/mapi/glapi/gen/gl_genexec.py b/src/mapi/glapi/gen/gl_genexec.py
index 183e6ff741..e63393d26a 100644
--- a/src/mapi/glapi/gen/gl_genexec.py
+++ b/src/mapi/glapi/gen/gl_genexec.py
@@ -92,6 +92,7 @@ header = """/**
 #include "main/objectlabel.h"
 #include "main/objectpurge.h"
 #include "main/performance_monitor.h"
+#include "main/performance_query.h"
 #include "main/pipelineobj.h"
 #include "main/pixel.h"
 #include "main/pixelstore.h"
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index ee737b0d7f..ae701138f5 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -150,6 +150,8 @@ MAIN_FILES = \
main/pbo.h \
main/performance_monitor.c \
main/performance_monitor.h \
+   main/performance_query.c \
+   main/performance_query.h \
main/pipelineobj.c \
main/pipelineobj.h \
main/pixel.c \
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 16e25a9bc2..f33ebe57e3 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -108,6 +108,7 @@
 #include "matrix.h"
 #include "multisample.h"
 #include "performance_monitor.h"
+#include "performance_query.h"
 #include "pipelineobj.h"
 #include "pixel.h"
 #include "pixelstore.h"
@@ -836,6 +837,7 @@ init_attrib_groups(struct gl_context *ctx)
_mesa_init_matrix( ctx );
_mesa_init_multisample( ctx );
_mesa_init_performance_monitors( ctx );
+   _mesa_init_performance_queries( ctx );
_mesa_init_pipeline( ctx );
_mesa_init_pixel( ctx );
_mesa_init_pixelstore( ctx );
@@ -1328,6 +1330,7 @@ _mesa_free_context_data( struct gl_context *ctx )
_mesa_free_varray_data(ctx);
_mesa_free_transform_feedback(ctx);
_mesa_free_performance_monitors(ctx);
+   _mesa_free_performance_queries(ctx);
 
_mesa_reference_buffer_object(ctx, >Pack.BufferObj, NULL);
_mesa_reference_buffer_object(ctx, >Unpack.BufferObj, NULL);
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 08bd929255..f3a24df589 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1874,6 +1874,20 @@ struct gl_perf_monitor_state
 
 
 /**
+ * Context state for INTEL_performance_query.
+ */
+struct gl_perf_query_state
+{
+   /** Array of performance monitor groups (indexed by group ID) */
+   const struct gl_perf_monitor_group *Groups;
+   GLuint NumGroups;
+
+   /** The table of all performance query objects. */
+   struct _mesa_HashTable *Objects;
+};
+
+
+/**
  * Names of the various vertex/fragment program register files, etc.
  *
  * NOTE: first four tokens must fit into 2 bits (see t_vb_arbprogram.c)
@@ -4512,6 +4526,7 @@ struct gl_context
struct gl_transform_feedback_state TransformFeedback;
 
struct gl_perf_monitor_state PerfMonitor;
+   struct gl_perf_query_state PerfQuery;
 
struct gl_buffer_object *DrawIndirectBuffer; /** < GL_ARB_draw_indirect */
struct gl_buffer_object *ParameterBuffer; /** < GL_ARB_indirect_parameters 
*/
diff --git a/src/mesa/main/performance_monitor.c 
b/src/mesa/main/performance_monitor.c
index 43529b2b35..a4a2f9e597 100644
--- a/src/mesa/main/performance_monitor.c
+++ b/src/mesa/main/performance_monitor.c
@@ -685,593 +685,3 @@ _mesa_perf_monitor_counter_size(const struct 
gl_perf_monitor_counter *c)
   return 0;
}
 }
-
-extern void GLAPIENTRY
-_mesa_GetFirstPerfQueryIdINTEL(GLuint *queryId)
-{
-   GET_CURRENT_CONTEXT(ctx);
-   unsigned numGroups;
-
-   init_groups(ctx);
-
-   /* The GL_INTEL_performance_query spec says:
-*
-*"If queryId pointer is equal to 0, INVALID_VALUE error is generated."
-*/
-   if (!queryId) {
-  _mesa_error(ctx, GL_INVALID_VALUE,
-  "glGetFirstPerfQueryIdINTEL(queryId == NULL)");
-  return;
-   }
-
-   numGroups = ctx->PerfMonitor.NumGroups;
-
-   /* The 

[Mesa-dev] [PATCH 2/3] Model INTEL perf query backend after query object BE

[Robert Bragg]

Instead of using the same backend interface as AMD_performance_monitor
this defines a dedicated INTEL_performance_query interface that is
modelled more on the ARB_query_buffer_object interface (considering the
similarity of the extensions) with the addition of vfuncs for
initializing and enumerating query and counter info.

Compared to the previous backend, some notable differences are:

- The backend is free to represent counters using whatever data
  structures are optimal/convenient since queries and counters are
  enumerated via an iterator api instead of declaring them using
  structures directly shared with the frontend.

  This is also done to help us support the full range of data and
  semantic types available with INTEL_performance_query which is awkward
  while using a structure shared with the AMD_performance_monitor
  backend since neither extension's types are a subset of the other.

- The backend must support waiting for a query instead of the frontend
  simply using glFinish().

- Objects go through 'Active' and 'Ready' states consistent with the
  query object backend (hopefully making them more familiar). There is
  no 'Ended' state (which used to show that a query has ended at least
  once for a given object). There is a new 'Used' state similar to the
  'EverBound' state of query objects, set when a query is first begun
  which implies that we are expecting to get results back for the object
  at some point.

The INTEL_performance_query and AMD_performance_monitor extensions are
now completely orthogonal within Mesa main (though a driver could
optionally choose to implement both extensions within a unified backend
if that were convenient for the sake of sharing state/code).

v2: (Samuel Pitoiset)
- init PerfQuery.NumQueries in frontend
- s/return_string/output_clipped_string/
- s/backed/backend/ typo
- remove redundant *bytesWritten = 0
v3:
- Add InitPerfQueryInfo for lazy probing of available queries

Signed-off-by: Robert Bragg 
---
 src/mesa/main/dd.h|  41 +++
 src/mesa/main/mtypes.h|  24 +-
 src/mesa/main/performance_query.c | 625 ++
 src/mesa/main/performance_query.h |   6 +-
 4 files changed, 295 insertions(+), 401 deletions(-)

diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 7ebd084ca3..e77df31cf2 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -780,6 +780,47 @@ struct dd_function_table {
/*@}*/
 
/**
+* \name Performance Query objects
+*/
+   /*@{*/
+   GLuint (*InitPerfQueryInfo)(struct gl_context *ctx);
+   void (*GetPerfQueryInfo)(struct gl_context *ctx,
+int queryIndex,
+const char **name,
+GLuint *dataSize,
+GLuint *numCounters,
+GLuint *numActive);
+   void (*GetPerfCounterInfo)(struct gl_context *ctx,
+  int queryIndex,
+  int counterIndex,
+  const char **name,
+  const char **desc,
+  GLuint *offset,
+  GLuint *data_size,
+  GLuint *type_enum,
+  GLuint *data_type_enum,
+  GLuint64 *raw_max);
+   struct gl_perf_query_object * (*NewPerfQueryObject)(struct gl_context *ctx,
+   int queryIndex);
+   void (*DeletePerfQuery)(struct gl_context *ctx,
+   struct gl_perf_query_object *obj);
+   GLboolean (*BeginPerfQuery)(struct gl_context *ctx,
+   struct gl_perf_query_object *obj);
+   void (*EndPerfQuery)(struct gl_context *ctx,
+struct gl_perf_query_object *obj);
+   void (*WaitPerfQuery)(struct gl_context *ctx,
+ struct gl_perf_query_object *obj);
+   GLboolean (*IsPerfQueryReady)(struct gl_context *ctx,
+ struct gl_perf_query_object *obj);
+   void (*GetPerfQueryData)(struct gl_context *ctx,
+struct gl_perf_query_object *obj,
+GLsizei dataSize,
+GLuint *data,
+GLuint *bytesWritten);
+   /*@}*/
+
+
+   /**
 * \name GREMEDY debug/marker functions
 */
/*@{*/
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index f3a24df589..e6cf1f4af6 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1860,6 +1860,23 @@ struct gl_perf_monitor_group
 
 
 /**
+ * A query object instance as described in INTEL_performance_query.
+ *
+ * NB: We want to keep this and the corresponding backend structure
+ * relatively lean considering that applications may expect to
+ * allocate enough objects to be able to query around all draw calls
+ * in a frame.
+ */

[Mesa-dev] [PATCH 3/3] i965: Implement INTEL_performance_query backend

[Robert Bragg]

This adds a bare-bones backend for the INTEL_performance_query extension
that exposes pipeline statistics.

Although this could be considered redundant given that the same
statistics are already available via query objects, they are a simple
starting point for this extension and it's expected to be convenient for
tools wanting to have a single go to api to introspect what performance
counters are available, along with names, descriptions and semantic/data
types.

This code is derived from Kenneth Graunke's work, temporarily removed
while the frontend and backend interface were reworked.

Signed-off-by: Robert Bragg 
---
 src/mesa/drivers/dri/i965/Makefile.sources|   2 +
 src/mesa/drivers/dri/i965/brw_context.c   |   3 +
 src/mesa/drivers/dri/i965/brw_context.h   |  23 +
 src/mesa/drivers/dri/i965/brw_performance_query.c | 595 ++
 src/mesa/drivers/dri/i965/brw_performance_query.h |  49 ++
 src/mesa/drivers/dri/i965/intel_extensions.c  |   3 +
 6 files changed, 675 insertions(+)
 create mode 100644 src/mesa/drivers/dri/i965/brw_performance_query.c
 create mode 100644 src/mesa/drivers/dri/i965/brw_performance_query.h

diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
b/src/mesa/drivers/dri/i965/Makefile.sources
index dd546826d1..5278e86339 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -135,6 +135,8 @@ i965_FILES = \
brw_nir_uniforms.cpp \
brw_object_purgeable.c \
brw_pipe_control.c \
+   brw_performance_query.h \
+   brw_performance_query.c \
brw_program.c \
brw_program.h \
brw_program_cache.c \
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index c56a14e3d6..393adede8a 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -1139,6 +1139,9 @@ brwCreateContext(gl_api api,
_mesa_initialize_dispatch_tables(ctx);
_mesa_initialize_vbo_vtxfmt(ctx);
 
+   if (ctx->Extensions.INTEL_performance_query)
+  brw_init_performance_queries(brw);
+
vbo_use_buffer_objects(ctx);
vbo_always_unmap_buffers(ctx);
 
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 01e651b09f..a6d91bcce0 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -655,6 +655,19 @@ struct shader_times;
 
 struct gen_l3_config;
 
+enum brw_query_kind {
+   PIPELINE_STATS
+};
+
+struct brw_perf_query_info
+{
+   enum brw_query_kind kind;
+   const char *name;
+   struct brw_perf_query_counter *counters;
+   int n_counters;
+   size_t data_size;
+};
+
 /**
  * brw_context is derived from gl_context.
  */
@@ -1132,6 +1145,13 @@ struct brw_context
   bool supported;
} predicate;
 
+   struct {
+  struct brw_perf_query_info *queries;
+  int n_queries;
+
+  int n_active_pipeline_stats_queries;
+   } perfquery;
+
int num_atoms[BRW_NUM_PIPELINES];
const struct brw_tracked_state render_atoms[76];
const struct brw_tracked_state compute_atoms[11];
@@ -1434,6 +1454,9 @@ bool brw_render_target_supported(struct brw_context *brw,
  struct gl_renderbuffer *rb);
 uint32_t brw_depth_format(struct brw_context *brw, mesa_format format);
 
+/* brw_performance_query.c */
+void brw_init_performance_queries(struct brw_context *brw);
+
 /* intel_buffer_objects.c */
 int brw_bo_map(struct brw_context *brw, drm_intel_bo *bo, int write_enable,
const char *bo_name);
diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c 
b/src/mesa/drivers/dri/i965/brw_performance_query.c
new file mode 100644
index 00..48f834878d
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/brw_performance_query.c
@@ -0,0 +1,595 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH 

[Mesa-dev] [PATCH 0/3] i965: INTEL_performance_query for pipeline stats

[Robert Bragg]

To hopefully make progress towards landing support for OA unit metrics exposed
via INTEL_performance_query the idea here is to first just tackle upstreaming
the backend rework with an initial implementation supporting pipeline
statistics.

In case anyone wants to look ahead, my branch with these patches as well as OA
unit support can be found at https://github.com/rib/mesa - wip/rib/oa-next

Regards,
- Robert

Robert Bragg (3):
  Separate INTEL_performance_query frontend
  Model INTEL perf query backend after query object BE
  i965: Implement INTEL_performance_query backend

 src/mapi/glapi/gen/gl_genexec.py  |   1 +
 src/mesa/Makefile.sources |   2 +
 src/mesa/drivers/dri/i965/Makefile.sources|   2 +
 src/mesa/drivers/dri/i965/brw_context.c   |   3 +
 src/mesa/drivers/dri/i965/brw_context.h   |  23 +
 src/mesa/drivers/dri/i965/brw_performance_query.c | 595 
 src/mesa/drivers/dri/i965/brw_performance_query.h |  49 ++
 src/mesa/drivers/dri/i965/intel_extensions.c  |   3 +
 src/mesa/main/context.c   |   3 +
 src/mesa/main/dd.h|  41 ++
 src/mesa/main/mtypes.h|  27 +
 src/mesa/main/performance_monitor.c   | 590 
 src/mesa/main/performance_monitor.h   |  39 --
 src/mesa/main/performance_query.c | 629 ++
 src/mesa/main/performance_query.h |  80 +++
 15 files changed, 1458 insertions(+), 629 deletions(-)
 create mode 100644 src/mesa/drivers/dri/i965/brw_performance_query.c
 create mode 100644 src/mesa/drivers/dri/i965/brw_performance_query.h
 create mode 100644 src/mesa/main/performance_query.c
 create mode 100644 src/mesa/main/performance_query.h

-- 
2.11.1

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

Re: [Mesa-dev] [PATCH 2/2] anv: Use build-id for pipeline cache UUID.

[Chad Versace]

Series is
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] anv: Use build-id for pipeline cache UUID.

[Emil Velikov]

On 15 February 2017 at 19:00, Matt Turner  wrote:
> On Wed, Feb 15, 2017 at 6:05 AM, Emil Velikov  
> wrote:
>> Hi Matt,
>>
>> On 14 February 2017 at 23:58, Matt Turner  wrote:
>>> The --build-id=... ld flag has been present since binutils-2.18,
>>> released 28 Aug 2007.
>>> ---
>>>  src/intel/vulkan/Makefile.am  |  1 +
>>>  src/intel/vulkan/anv_device.c | 28 +++-
>>>  2 files changed, 8 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/src/intel/vulkan/Makefile.am b/src/intel/vulkan/Makefile.am
>>> index 95f276e..4197b0e 100644
>>> --- a/src/intel/vulkan/Makefile.am
>>> +++ b/src/intel/vulkan/Makefile.am
>>> @@ -165,6 +165,7 @@ libvulkan_intel_la_LDFLAGS = \
>>> -module \
>>> -no-undefined \
>>> -avoid-version \
>>> +   -Wl,--build-id=sha1 \
>> Did you mean to have this as-is and update to $sha1 as a follow-up commit ?
>
> I'm not sure what you mean.
>
> I added -Wl,--build-id=sha1 in this patch, because it is at this point
> that we begin relying on having a .note.gnu.build-id section.

Scratch that, I should have read the build-id man page more carefully.

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

Re: [Mesa-dev] [PATCH v3 09/24] i965/fs: fix lower SIMD width for IVB/BYT's MOV_INDIRECT

[Francisco Jerez]

Samuel Iglesias Gonsálvez  writes:

> From: "Juan A. Suarez Romero" 
>
> According to the IVB and HSW PRMs:
>
> "2.When the destination requires two registers and the sources are
>  indirect, the sources must use 1x1 regioning mode."
>
> So for DF instructions the execution size is not limited by the number
> of address registers that are available, but by the EU decompression
> logic not handling VxH indirect addressing correctly.
>
> This patch limits the SIMD width to 4 in this case.
>
> v2:
> - Fix typo (Matt).
> - Fix condition (Curro)
>
> v3:
> - Add spec quote (Curro)
>
> Signed-off-by: Samuel Iglesias Gonsálvez 
> Signed-off-by: Juan A. Suarez Romero 

Reviewed-by: Francisco Jerez 

> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 8d5b381f4a1..5c405709127 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -4872,11 +4872,22 @@ get_lowered_simd_width(const struct gen_device_info 
> *devinfo,
> case SHADER_OPCODE_URB_WRITE_SIMD8_MASKED_PER_SLOT:
>return MIN2(8, inst->exec_size);
>  
> -   case SHADER_OPCODE_MOV_INDIRECT:
> -  /* Prior to Broadwell, we only have 8 address subregisters */
> +   case SHADER_OPCODE_MOV_INDIRECT: {
> +  /* From IVB and HSW PRMs:
> +   *
> +   * "2.When the destination requires two registers and the sources are
> +   *  indirect, the sources must use 1x1 regioning mode.
> +   *
> +   * In case of DF instructions in HSW/IVB, the exec_size is limited by
> +   * the EU decompression logic not handling VxH indirect addressing
> +   * correctly.
> +   */
> +  const unsigned max_size = (devinfo->gen >= 8 ? 2 : 1) * REG_SIZE;
> +  /* Prior to Broadwell, we only have 8 address subregisters. */
>return MIN3(devinfo->gen >= 8 ? 16 : 8,
> -  2 * REG_SIZE / (inst->dst.stride * 
> type_sz(inst->dst.type)),
> +  max_size / (inst->dst.stride * type_sz(inst->dst.type)),
>inst->exec_size);
> +   }
>  
> case SHADER_OPCODE_LOAD_PAYLOAD: {
>const unsigned reg_count =
> -- 
> 2.11.0
>
> ___
> 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 v3 08/24] i965/fs: fix dst stride in IVB/BYT type conversions

[Francisco Jerez]

Samuel Iglesias Gonsálvez  writes:

> From: "Juan A. Suarez Romero" 
>
> When converting a DF to 32-bit conversions, we set dst stride to 2,
> to fulfill alignment restrictions because the upper Dword of every
> Qword will be written with undefined value.
>
> But in IVB/BYT, this is not necessary, as each DF conversion already
> writes 2, the first one the real value, and the second one a 0.
> That is, IVB/BYT already set stride = 2 implicitly, so we must set it to
> 1 explicitly to avoid ending up with stride = 4.
>
> v2:
> - Fix typo (Matt)
>
> v3:
> - Fix stride in the destination's brw_reg, don't modity IR (Curro)
>
> Signed-off-by: Juan A. Suarez Romero 
> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
>  src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 76 
> +++---
>  1 file changed, 45 insertions(+), 31 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> index 2f60ddd8706..e0a80d73b70 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> @@ -55,7 +55,7 @@ brw_file_from_reg(fs_reg *reg)
>  
>  static struct brw_reg
>  brw_reg_from_fs_reg(const struct gen_device_info *devinfo, fs_inst *inst,
> -fs_reg *reg, bool compressed)
> +fs_reg *reg, bool is_dst, bool compressed)
>  {
> struct brw_reg brw_reg;
>  
> @@ -94,34 +94,48 @@ brw_reg_from_fs_reg(const struct gen_device_info 
> *devinfo, fs_inst *inst,
>   const unsigned width = MIN2(reg_width, phys_width);
>   brw_reg = brw_vecn_reg(width, brw_file_from_reg(reg), reg->nr, 0);
>   brw_reg = stride(brw_reg, width * reg->stride, width, reg->stride);
> - /* From the IvyBridge PRM (EU Changes by Processor Generation, page 
> 13):
> -  *  "Each DF (Double Float) operand uses an element size of 4 rather
> -  *   than 8 and all regioning parameters are twice what the values
> -  *   would be based on the true element size: ExecSize, Width,
> -  *   HorzStride, and VertStride. Each DF operand uses a pair of
> -  *   channels and all masking and swizzing should be adjusted
> -  *   appropriately."
> -  *
> -  * From the IvyBridge PRM (Special Requirements for Handling Double
> -  * Precision Data Types, page 71):
> -  *  "In Align1 mode, all regioning parameters like stride, execution
> -  *   size, and width must use the syntax of a pair of packed
> -  *   floats. The offsets for these data types must be 64-bit
> -  *   aligned. The execution size and regioning parameters are in 
> terms
> -  *   of floats."
> -  *
> -  * Summarized: when handling DF-typed arguments, ExecSize,
> -  * VertStride, and Width must be doubled, and HorzStride must be
> -  * doubled when the region is not scalar.
> -  *
> -  * It applies to BayTrail too.
> -  */
> - if (devinfo->gen == 7 && !devinfo->is_haswell &&
> - type_sz(reg->type) == 8) {
> -brw_reg.width++;
> -if (brw_reg.vstride > 0)
> -   brw_reg.vstride++;
> -assert(brw_reg.hstride == BRW_HORIZONTAL_STRIDE_1);
> +
> + if (devinfo->gen == 7 && !devinfo->is_haswell) {
> +/* From the IvyBridge PRM (EU Changes by Processor Generation, 
> page 13):
> + *  "Each DF (Double Float) operand uses an element size of 4 
> rather
> + *   than 8 and all regioning parameters are twice what the 
> values
> + *   would be based on the true element size: ExecSize, Width,
> + *   HorzStride, and VertStride. Each DF operand uses a pair of
> + *   channels and all masking and swizzing should be adjusted
> + *   appropriately."
> + *
> + * From the IvyBridge PRM (Special Requirements for Handling 
> Double
> + * Precision Data Types, page 71):
> + *  "In Align1 mode, all regioning parameters like stride, 
> execution
> + *   size, and width must use the syntax of a pair of packed
> + *   floats. The offsets for these data types must be 64-bit
> + *   aligned. The execution size and regioning parameters are in 
> terms
> + *   of floats."
> + *
> + * Summarized: when handling DF-typed arguments, ExecSize,
> + * VertStride, and Width must be doubled, and HorzStride must be
> + * doubled when the region is not scalar.
> + *
> + * It applies to BayTrail too.
> + */
> +if (type_sz(reg->type) == 8) {
> +   brw_reg.width++;
> +   if (brw_reg.vstride > 0)
> +  brw_reg.vstride++;
> +  

[Mesa-dev] [Bug 99789] Memory leak on failure to create an ir_constant in calculate_iterations in loop_controls.cpp

[bugzilla-daemon]

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

Matt Turner  changed:

   What|Removed |Added

 CC|damian.di...@gmail.com  |

--- Comment #1 from Matt Turner  ---
(you don't need to Cc yourself on bugs you filed. you'll receive the emails
either way)

Yes, you are right. It looks like we should be calling ralloc_free(mem_ctx)
before the early return. The comment is not necessary.

Would you please send a patch to mesa-dev@lists.freedesktop.org? Feel free to
Cc me on it.

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

Re: [Mesa-dev] [PATCH v3 06/24] i965: Use <0, 2, 1> region for scalar DF sources on IVB/BYT.

[Francisco Jerez]

Samuel Iglesias Gonsálvez  writes:

> From: Matt Turner 
>
> On HSW+, scalar DF sources can be accessed using the normal <0,1,0>
> region, but on IVB and BYT DF regions must be programmed in terms of
> floats. A <0,2,1> region accomplishes this.
>
> v2:
> - Apply region <0,2,1> in brw_reg_from_fs_reg() (Curro).
>
> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
>  src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> index b0d5732ac5c..2f60ddd8706 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> @@ -145,6 +145,15 @@ brw_reg_from_fs_reg(const struct gen_device_info 
> *devinfo, fs_inst *inst,
>unreachable("not reached");
> }
>  

Maybe put a short comment here along the same lines as the commit
message so you don't need to run git-blame to figure out what this is
about?  Either way patch is:

Reviewed-by: Francisco Jerez 

> +   if (devinfo->gen == 7 && !devinfo->is_haswell &&
> +   type_sz(reg->type) == 8 &&
> +   brw_reg.vstride == BRW_VERTICAL_STRIDE_0 &&
> +   brw_reg.width == BRW_WIDTH_1 &&
> +   brw_reg.hstride == BRW_HORIZONTAL_STRIDE_0) {
> +  brw_reg.width = BRW_WIDTH_2;
> +  brw_reg.hstride = BRW_HORIZONTAL_STRIDE_1;
> +   }
> +
> return brw_reg;
>  }
>  
> -- 
> 2.11.0
>
> ___
> 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 1/3] radv/ac: add support for some integer size conversions.

[Bas Nieuwenhuizen]

On Wed, Feb 15, 2017, at 09:43, Dave Airlie wrote:
> From: Dave Airlie 
> 
> zero extend ->u64 and sign extend ->i64.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 883656d..e9e3d14 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1523,6 +1523,13 @@ static void visit_alu(struct nir_to_llvm_context
> *ctx, nir_alu_instr *instr)
>   case nir_op_b2f:
>   result = emit_b2f(ctx, src[0]);
>   break;
> +   case nir_op_u2i64:
> +   case nir_op_u2u64:
> +   result = LLVMBuildZExt(ctx->builder, src[0], ctx->i64,
> "");

Do these not have to work for vectors?

> +   break;
> +   case nir_op_i2i64:
> +   result = LLVMBuildSExt(ctx->builder, src[0], ctx->i64,
> "");
> +   break;
>   case nir_op_fquantize2f16:
>   src[0] = to_float(ctx, src[0]);
>   result = LLVMBuildFPTrunc(ctx->builder, src[0], ctx->f16, "");
> -- 
> 2.9.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 04/24] i965/fs: double regioning parameters and execsize for DF in IVB/BYT

[Francisco Jerez]

Samuel Iglesias Gonsálvez  writes:

> From: "Juan A. Suarez Romero" 
>
> In IVB and BYT, both regioning parameters and execution sizes are measured as
> 32-bits element size.
>
> So when we have something like:
>
> mov(8) g2<1>DF g3<4,4,1>DF
>
> We are not actually moving 8 doubles (our intention), but 4 doubles.
>
> We need to double the parameters to cope with this issue. However,
> horizontal strides don't behave as they're supposed to on IVB
> for DF regions, they will cause each 32-bit half of DF sources to be
> strided individually, and doubling the value won't make any difference.
>
> v2:
> - Use devinfo directly (Matt).
> - Use Baytrail instead of Valleview (Matt).
> - Use IvyBridge instead of Ivy (Matt)
> - Double the exec_size in code emission (Curro)
>
> v3:
> - Change hstride doubling by an assert and fix commit log (Curro).
> - Substitute remaining compiler->devinfo by devinfo (Curro).
>
> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
>  src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 51 
> ++
>  1 file changed, 44 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> index 26ffbb169d2..b0d5732ac5c 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> @@ -54,13 +54,14 @@ brw_file_from_reg(fs_reg *reg)
>  }
>  
>  static struct brw_reg
> -brw_reg_from_fs_reg(fs_inst *inst, fs_reg *reg, unsigned gen, bool 
> compressed)
> +brw_reg_from_fs_reg(const struct gen_device_info *devinfo, fs_inst *inst,
> +fs_reg *reg, bool compressed)
>  {
> struct brw_reg brw_reg;
>  
> switch (reg->file) {
> case MRF:
> -  assert((reg->nr & ~BRW_MRF_COMPR4) < BRW_MAX_MRF(gen));
> +  assert((reg->nr & ~BRW_MRF_COMPR4) < BRW_MAX_MRF(devinfo->gen));
>/* Fallthrough */
> case VGRF:
>if (reg->stride == 0) {
> @@ -93,6 +94,35 @@ brw_reg_from_fs_reg(fs_inst *inst, fs_reg *reg, unsigned 
> gen, bool compressed)
>   const unsigned width = MIN2(reg_width, phys_width);
>   brw_reg = brw_vecn_reg(width, brw_file_from_reg(reg), reg->nr, 0);
>   brw_reg = stride(brw_reg, width * reg->stride, width, reg->stride);
> + /* From the IvyBridge PRM (EU Changes by Processor Generation, page 
> 13):
> +  *  "Each DF (Double Float) operand uses an element size of 4 rather
> +  *   than 8 and all regioning parameters are twice what the values
> +  *   would be based on the true element size: ExecSize, Width,
> +  *   HorzStride, and VertStride. Each DF operand uses a pair of
> +  *   channels and all masking and swizzing should be adjusted
> +  *   appropriately."
> +  *
> +  * From the IvyBridge PRM (Special Requirements for Handling Double
> +  * Precision Data Types, page 71):
> +  *  "In Align1 mode, all regioning parameters like stride, execution
> +  *   size, and width must use the syntax of a pair of packed
> +  *   floats. The offsets for these data types must be 64-bit
> +  *   aligned. The execution size and regioning parameters are in 
> terms
> +  *   of floats."
> +  *
> +  * Summarized: when handling DF-typed arguments, ExecSize,
> +  * VertStride, and Width must be doubled, and HorzStride must be
> +  * doubled when the region is not scalar.
> +  *

The comment above seems misleading still, doubling the HorzStride value
is almost guaranteed not to give the intended result, regardless of
whether the region is scalar.  With that clarified patch is:

Reviewed-by: Francisco Jerez 

> +  * It applies to BayTrail too.
> +  */
> + if (devinfo->gen == 7 && !devinfo->is_haswell &&
> + type_sz(reg->type) == 8) {
> +brw_reg.width++;
> +if (brw_reg.vstride > 0)
> +   brw_reg.vstride++;
> +assert(brw_reg.hstride == BRW_HORIZONTAL_STRIDE_1);
> + }
>}
>  
>brw_reg = retype(brw_reg, reg->type);
> @@ -1586,9 +1616,8 @@ fs_generator::generate_code(const cfg_t *cfg, int 
> dispatch_width)
>brw_set_default_group(p, inst->group);
>  
>for (unsigned int i = 0; i < inst->sources; i++) {
> - src[i] = brw_reg_from_fs_reg(inst, >src[i], devinfo->gen,
> -  compressed);
> -
> + src[i] = brw_reg_from_fs_reg(devinfo, inst,
> +  >src[i], compressed);
>/* The accumulator result appears to get used for the
> * conditional modifier generation.  When negating a UD
> * value, there is a 33rd bit generated for the sign in the
> @@ -1599,7 +1628,8 @@ fs_generator::generate_code(const cfg_t *cfg, int 
> dispatch_width)
>

Re: [Mesa-dev] [PATCH 3/4] docs/submittingpatches.html: remove version tag for nominations

[Eric Anholt]

Emil Velikov  writes:

> From: Emil Velikov 
>
> The version tag used to nominate has bitten even experienced mesa
> developers. Not to mention that it deviates from the one used in the
> kernel leading to further confusion.
>
> Simplify things and omit it all together.
>
> Signed-off-by: Emil Velcro 
> ---
> Another option would be to align it with the kernel one, but that could
> bring even further confusion.

I like this a lot -- I'm usually just copy-and-pasting someone else's cc
stable line, so I'll probably occasionally nominate my stuff for an
inactive stable branch.  I'm not too worried about patches accidentally
applying to too-old code.

FWIW, this is more or less how the kernel's stable branches have been
working for me -- I write a "Fixes:  short commit subject"
line in the commit, and Greg cherry-picks it back to all stable branches
since that sha1 that it applies to.


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 99467] [radv] DOOM 2016 + wine. Green screen everywhere (but can be started)

[bugzilla-daemon]

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

--- Comment #18 from Bogomil Vasilev  ---
I can confirm the same. The blurry colors are gone. The game works perfect so
far.
David, are you polishing the patches before pushing them? I'm asking is because
I don't see any reason not to submit it to mainline mesa, except that "illegal"
use of the API.

-- 
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 1/2] util: Add utility build-id code.

[Matt Turner]

Provides the ability to read the .note.gnu.build-id section of ELF
binaries, which is inserted by the --build-id=... flag to ld.

Reviewed-by: Emil Velikov 
---
 configure.ac  |   6 +++
 src/util/Makefile.sources |   2 +
 src/util/build_id.c   | 109 ++
 src/util/build_id.h   |  38 
 4 files changed, 155 insertions(+)
 create mode 100644 src/util/build_id.c
 create mode 100644 src/util/build_id.h

diff --git a/configure.ac b/configure.ac
index f001743..e4a5b48 100644
--- a/configure.ac
+++ b/configure.ac
@@ -768,6 +768,8 @@ LIBS="$LIBS $DLOPEN_LIBS"
 AC_CHECK_FUNCS([dladdr])
 LIBS="$save_LIBS"
 
+AC_CHECK_FUNC([dl_iterate_phdr], [DEFINES="$DEFINES -DHAVE_DL_ITERATE_PHDR"])
+
 case "$host_os" in
 darwin*)
 ;;
@@ -1773,6 +1775,10 @@ AC_ARG_WITH([vulkan-icddir],
 AC_SUBST([VULKAN_ICD_INSTALL_DIR])
 
 if test -n "$with_vulkan_drivers"; then
+if test "x$ac_cv_func_dl_iterate_phdr" = xno; then
+AC_MSG_ERROR([Vulkan drivers require the dl_iterate_phdr function])
+fi
+
 VULKAN_DRIVERS=`IFS=', '; echo $with_vulkan_drivers`
 for driver in $VULKAN_DRIVERS; do
 case "x$driver" in
diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
index eec0311..40d183c 100644
--- a/src/util/Makefile.sources
+++ b/src/util/Makefile.sources
@@ -2,6 +2,8 @@ MESA_UTIL_FILES :=  \
bitscan.c \
bitscan.h \
bitset.h \
+   build_id.c \
+   build_id.h \
crc32.c \
crc32.h \
debug.c \
diff --git a/src/util/build_id.c b/src/util/build_id.c
new file mode 100644
index 000..2993a80
--- /dev/null
+++ b/src/util/build_id.c
@@ -0,0 +1,109 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifdef HAVE_DL_ITERATE_PHDR
+#include 
+#include 
+#include 
+
+#include "build_id.h"
+
+#define ALIGN(val, align)  (((val) + (align) - 1) & ~((align) - 1))
+
+struct build_id_note {
+   ElfW(Nhdr) nhdr;
+
+   char name[4]; /* Note name for build-id is "GNU\0" */
+   uint8_t build_id[0];
+};
+
+struct callback_data {
+   const char *filename;
+   struct build_id_note *note;
+};
+
+static int
+build_id_find_nhdr_callback(struct dl_phdr_info *info, size_t size, void 
*data_)
+{
+   struct callback_data *data = data_;
+
+   char *ptr = strstr(info->dlpi_name, data->filename);
+   if (ptr == NULL || ptr[strlen(data->filename)] != '\0')
+  return 0;
+
+   for (unsigned i = 0; i < info->dlpi_phnum; i++) {
+  if (info->dlpi_phdr[i].p_type != PT_NOTE)
+ continue;
+
+  struct build_id_note *note = (void *)(info->dlpi_addr +
+info->dlpi_phdr[i].p_vaddr);
+  ptrdiff_t len = info->dlpi_phdr[i].p_filesz;
+
+  while (len >= sizeof(struct build_id_note)) {
+ if (note->nhdr.n_type == NT_GNU_BUILD_ID &&
+note->nhdr.n_descsz != 0 &&
+note->nhdr.n_namesz == 4 &&
+memcmp(note->name, "GNU", 4) == 0) {
+data->note = note;
+return 1;
+ }
+
+ size_t offset = sizeof(ElfW(Nhdr)) +
+ ALIGN(note->nhdr.n_namesz, 4) +
+ ALIGN(note->nhdr.n_descsz, 4);
+ note = (struct build_id_note *)((char *)note + offset);
+ len -= offset;
+  }
+   }
+
+   return 0;
+}
+
+const struct build_id_note *
+build_id_find_nhdr(const char *filename)
+{
+   struct callback_data data = {
+  .filename = filename,
+  .note = NULL,
+   };
+
+   if (!dl_iterate_phdr(build_id_find_nhdr_callback, ))
+  return NULL;
+
+   return data.note;
+}
+
+unsigned
+build_id_length(const struct build_id_note *note)
+{
+   return note->nhdr.n_descsz;
+}
+
+void
+build_id_read(const struct build_id_note *note,
+  unsigned char *build_id, size_t n)
+{
+   

[Mesa-dev] [PATCH 2/2] anv: Use build-id for pipeline cache UUID.

[Matt Turner]

The --build-id=... ld flag has been present since binutils-2.18,
released 28 Aug 2007.
---
 src/intel/vulkan/Makefile.am  |  1 +
 src/intel/vulkan/anv_device.c | 28 +++-
 2 files changed, 8 insertions(+), 21 deletions(-)

diff --git a/src/intel/vulkan/Makefile.am b/src/intel/vulkan/Makefile.am
index 95f276e..4197b0e 100644
--- a/src/intel/vulkan/Makefile.am
+++ b/src/intel/vulkan/Makefile.am
@@ -165,6 +165,7 @@ libvulkan_intel_la_LDFLAGS = \
-module \
-no-undefined \
-avoid-version \
+   -Wl,--build-id=sha1 \
$(BSYMBOLIC) \
$(GC_SECTIONS) \
$(LD_NO_UNDEFINED)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index d1a6cc8..cae5fef 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -21,18 +21,17 @@
  * IN THE SOFTWARE.
  */
 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
 #include "anv_private.h"
 #include "util/strtod.h"
 #include "util/debug.h"
+#include "util/build_id.h"
 #include "util/vk_util.h"
 
 #include "genxml/gen7_pack.h"
@@ -56,30 +55,17 @@ compiler_perf_log(void *data, const char *fmt, ...)
 }
 
 static bool
-anv_get_function_timestamp(void *ptr, uint32_t* timestamp)
-{
-   Dl_info info;
-   struct stat st;
-   if (!dladdr(ptr, ) || !info.dli_fname)
-  return false;
-
-   if (stat(info.dli_fname, ))
-  return false;
-
-   *timestamp = st.st_mtim.tv_sec;
-   return true;
-}
-
-static bool
 anv_device_get_cache_uuid(void *uuid)
 {
-   uint32_t timestamp;
+   const struct build_id_note *note = build_id_find_nhdr("libvulkan_intel.so");
+   if (!note)
+  return false;
 
-   memset(uuid, 0, VK_UUID_SIZE);
-   if (!anv_get_function_timestamp(anv_device_get_cache_uuid, ))
+   unsigned len = build_id_length(note);
+   if (len < VK_UUID_SIZE)
   return false;
 
-   snprintf(uuid, VK_UUID_SIZE, "anv-%d", timestamp);
+   build_id_read(note, uuid, VK_UUID_SIZE);
return true;
 }
 
-- 
2.10.2

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

Re: [Mesa-dev] [PATCH] softpipe: implement clear_texture

[Roland Scheidegger]

Yes, I guess a new util_clear_texture helper would work -
util_clear_render_target and util_clear_depth_stencil are modeled after
the respective pipe functions too, so why not have a util_clear_texture
modeled after the respective pipe function... Maybe rip out most of the
actual implementation of the "old" clear functions into a new helper to
be shared by the new ones or something like that...

Roland

Am 15.02.2017 um 16:16 schrieb Lars Hamre:
> Happy to rework the implementation.
> Would creating a util_clear_texture function which pulls out the
> necessary components from util_clear_render_target be in alignment
> with what you're imagining?
> The idea would be to have util_clear_texture take a pipe_resource
> instead of a pipe_surface.
> Something similar would also be done for clear_depth_stencil.
> 
> Lars
> 
> On Mon, Feb 13, 2017 at 7:41 PM, Roland Scheidegger  
> wrote:
>> Am 13.02.2017 um 16:20 schrieb Lars Hamre:
>>> Implements the ARB_clear_texture extension for softpipe.
>>> Passes all corresponding piglit tests.
>>>
>>> Signed-off-by: Lars Hamre 
>>>
>>> ---
>>>
>>> NOTE: someone with access will need to commit this post
>>>   review process
>>>
>>>  src/gallium/drivers/softpipe/sp_screen.c  |  3 +-
>>>  src/gallium/drivers/softpipe/sp_texture.c | 60 
>>> +++
>>>  2 files changed, 62 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/drivers/softpipe/sp_screen.c 
>>> b/src/gallium/drivers/softpipe/sp_screen.c
>>> index 02eff91..aa061d7 100644
>>> --- a/src/gallium/drivers/softpipe/sp_screen.c
>>> +++ b/src/gallium/drivers/softpipe/sp_screen.c
>>> @@ -260,6 +260,8 @@ softpipe_get_param(struct pipe_screen *screen, enum 
>>> pipe_cap param)
>>> case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
>>> case PIPE_CAP_TGSI_ARRAY_COMPONENTS:
>>>return 1;
>>> +   case PIPE_CAP_CLEAR_TEXTURE:
>>> +  return 1;
>>> case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
>>> case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
>>> case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
>>> @@ -268,7 +270,6 @@ softpipe_get_param(struct pipe_screen *screen, enum 
>>> pipe_cap param)
>>> case PIPE_CAP_TGSI_TXQS:
>>> case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
>>> case PIPE_CAP_SHAREABLE_SHADERS:
>>> -   case PIPE_CAP_CLEAR_TEXTURE:
>>> case PIPE_CAP_DRAW_PARAMETERS:
>>> case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
>>> case PIPE_CAP_MULTI_DRAW_INDIRECT:
>>> diff --git a/src/gallium/drivers/softpipe/sp_texture.c 
>>> b/src/gallium/drivers/softpipe/sp_texture.c
>>> index 8dca158..3794cf3 100644
>>> --- a/src/gallium/drivers/softpipe/sp_texture.c
>>> +++ b/src/gallium/drivers/softpipe/sp_texture.c
>>> @@ -37,6 +37,7 @@
>>>  #include "util/u_math.h"
>>>  #include "util/u_memory.h"
>>>  #include "util/u_transfer.h"
>>> +#include "util/u_surface.h"
>>>
>>>  #include "sp_context.h"
>>>  #include "sp_flush.h"
>>> @@ -341,6 +342,64 @@ softpipe_surface_destroy(struct pipe_context *pipe,
>>>  }
>>>
>>>
>>> +static void
>>> +softpipe_clear_texture(struct pipe_context *pipe,
>>> +   struct pipe_resource *tex,
>>> +   unsigned level,
>>> +   const struct pipe_box *box,
>>> +   const void *data)
>>> +{
>>> +   struct pipe_surface tmpl = {{0}};
>>> +   struct pipe_surface *sf;
>>> +   const struct util_format_description *desc =
>>> +  util_format_description(tex->format);
>>> +
>>> +   if (level > tex->last_level)
>>> +  return;
>>> +
>>> +   tmpl.format = tex->format;
>>> +   tmpl.u.tex.first_layer = box->z;
>>> +   tmpl.u.tex.last_layer = box->z + box->depth - 1;
>>> +   tmpl.u.tex.level = level;
>>> +   sf = pipe->create_surface(pipe, tex, );
>> I am not quite convinced of that solution. The problem is you're not
>> supposed to call create_surface() on resources which didn't have the
>> appropriate bind flag (although unlike llvmpipe softpipe won't warn
>> about this). And in fact, there's formats where clear_texture is
>> supposed to work which are definitely not renderable, so it really is an
>> error to do this (even though softpipe won't actually care).
>>
>> But OTOH I suppose this method works...
>>
>> Roland
>>
>>
>>> +   if (!sf)
>>> +  return;
>>> +
>>> +   if (util_format_is_depth_or_stencil(tex->format)) {
>>> +  unsigned clear = 0;
>>> +  float depth = 0.0f;
>>> +  uint8_t stencil = 0;
>>> +
>>> +  if (util_format_has_depth(desc)) {
>>> + clear |= PIPE_CLEAR_DEPTH;
>>> + desc->unpack_z_float(, 0, data, 0, 1, 1);
>>> +  }
>>> +
>>> +  if (util_format_has_stencil(desc)) {
>>> + clear |= PIPE_CLEAR_STENCIL;
>>> + desc->unpack_s_8uint(, 0, data, 0, 1, 1);
>>> +  }
>>> +
>>> +  pipe->clear_depth_stencil(pipe, sf, clear, depth, stencil,
>>> +box->x, box->y,
>>> +box->width, box->height, false);
>>> +   } else {

Re: [Mesa-dev] [PATCH 2/2] anv: Use build-id for pipeline cache UUID.

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

Thanks for getting this figured out!

On Tue, Feb 14, 2017 at 3:58 PM, Matt Turner  wrote:

> The --build-id=... ld flag has been present since binutils-2.18,
> released 28 Aug 2007.
> ---
>  src/intel/vulkan/Makefile.am  |  1 +
>  src/intel/vulkan/anv_device.c | 28 +++-
>  2 files changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/src/intel/vulkan/Makefile.am b/src/intel/vulkan/Makefile.am
> index 95f276e..4197b0e 100644
> --- a/src/intel/vulkan/Makefile.am
> +++ b/src/intel/vulkan/Makefile.am
> @@ -165,6 +165,7 @@ libvulkan_intel_la_LDFLAGS = \
> -module \
> -no-undefined \
> -avoid-version \
> +   -Wl,--build-id=sha1 \
> $(BSYMBOLIC) \
> $(GC_SECTIONS) \
> $(LD_NO_UNDEFINED)
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 91ee67f..b52287c 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -21,18 +21,17 @@
>   * IN THE SOFTWARE.
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>
>  #include "anv_private.h"
>  #include "util/strtod.h"
>  #include "util/debug.h"
> +#include "util/build_id.h"
>
>  #include "genxml/gen7_pack.h"
>
> @@ -55,30 +54,17 @@ compiler_perf_log(void *data, const char *fmt, ...)
>  }
>
>  static bool
> -anv_get_function_timestamp(void *ptr, uint32_t* timestamp)
> -{
> -   Dl_info info;
> -   struct stat st;
> -   if (!dladdr(ptr, ) || !info.dli_fname)
> -  return false;
> -
> -   if (stat(info.dli_fname, ))
> -  return false;
> -
> -   *timestamp = st.st_mtim.tv_sec;
> -   return true;
> -}
> -
> -static bool
>  anv_device_get_cache_uuid(void *uuid)
>  {
> -   uint32_t timestamp;
> +   const struct build_id_note *note = build_id_find_nhdr("libvulkan_
> intel.so");
> +   if (!note)
> +  return false;
>
> -   memset(uuid, 0, VK_UUID_SIZE);
> -   if (!anv_get_function_timestamp(anv_device_get_cache_uuid,
> ))
> +   unsigned len = build_id_length(note);
> +   if (len < VK_UUID_SIZE)
>return false;
>
> -   snprintf(uuid, VK_UUID_SIZE, "anv-%d", timestamp);
> +   build_id_read(note, uuid, VK_UUID_SIZE);
> return true;
>  }
>
> --
> 2.10.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] util: Add utility build-id code.

[Jason Ekstrand]

On Wed, Feb 15, 2017 at 10:57 AM, Matt Turner  wrote:

> On Wed, Feb 15, 2017 at 4:03 AM, Emil Velikov 
> wrote:
> > Hi Matt,
> >
> > Afaics dl_iterate_phdr is available on musl, (some?) BSDs and Solaris
> > - thank you for opting for it.
> >
> > Out of curiosity:
> > Have you checked if on those platforms the "GNU\0" strcmp is
> > applicable and not another string ? Worth adding a note/comment ?
>
> It's generated by GNU ld in all cases I'm aware of, so I think it's the
> same.
>
> > On 14 February 2017 at 23:58, Matt Turner  wrote:
> >> Provides the ability to read the .note.gnu.build-id section of ELF
> >> binaries, which is inserted by the --build-id=... flag to ld.
> >> ---
> >>  configure.ac  |   2 +
> >>  src/util/Makefile.sources |   2 +
> >>  src/util/build_id.c   | 110 ++
> 
> >>  src/util/build_id.h   |  34 ++
> >>  4 files changed, 148 insertions(+)
> >>  create mode 100644 src/util/build_id.c
> >>  create mode 100644 src/util/build_id.h
> >>
> >> diff --git a/configure.ac b/configure.ac
> >> index f001743..99c74f0 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -768,6 +768,8 @@ LIBS="$LIBS $DLOPEN_LIBS"
> >>  AC_CHECK_FUNCS([dladdr])
> >>  LIBS="$save_LIBS"
> >>
> >> +AC_CHECK_FUNC([dl_iterate_phdr], [DEFINES="$DEFINES
> -DHAVE_DL_ITERATE_PHDR"])
> >> +
> > What we want here is a local (in-configure) variable -> have_foo,
> > which will be checked by ANV/others that depend on an actual
> > implementation.
> > As-is things will compile but we'll get a link error.
> >
> >
> >> +const struct build_id_note *
> >> +build_id_find_nhdr(const char *filename)
> >> +{
> >> +   struct callback_data data = {
> >> +  .filename = filename,
> >> +  .note = NULL,
> >> +   };
> >> +
> >> +   if (dl_iterate_phdr(build_id_find_nhdr_callback, )) {
> >> +  return data.note;
> >> +   } else {
> >> +  return NULL;
> >> +   }
> > Nit:
> >
> >if (!dl_iterate_phdr(build_id_find_nhdr_callback, ))
> >   return NULL;
> >
> >return data.note;
> >
> >
> >> diff --git a/src/util/build_id.h b/src/util/build_id.h
> >> new file mode 100644
> >> index 000..20db4ac
> >> --- /dev/null
> >> +++ b/src/util/build_id.h
> >
> >> +struct build_id_note;
> >> +
> >> +const struct build_id_note *
> >> +build_id_find_nhdr(const char *filename);
> >> +
> >> +unsigned
> >> +build_id_length(const struct build_id_note *note);
> >> +
> >> +void
> >> +build_id_read(const struct build_id_note *note,
> >> +  unsigned char *build_id, size_t n);
> >
> > With the configure fix, one can bring back the stubs here. Having a
> > function declaration w/o a definition is a bit iffy.
>
> I think having stubs was a bad idea from the outset. In any case one
> of these stubs is called, something bad is going to happen.
>
> I'll wrap the header in #ifdef HAVE_DL_ITERATE_PHDR instead.
>

For the sake of other code which needs to #if around whether or not to call
these functions, it might be a good idea to have a

#define HAVE_BUILD_ID

inside of the #ifdef HAVE_DL_ITERATE_PHDR.  It's a bit more convenient and
allows for a potential future where we have some method for getting a
build-id on windows or similar.

--Jason


> > With the above:
> > Reviewed-by: Emil Velikov 
>
> Thanks. I'll incorporate these changes and send a v3.
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 99467] [radv] DOOM 2016 + wine. Green screen everywhere (but can be started)

[bugzilla-daemon]

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

--- Comment #17 from Joeri Capens  ---
The new patches work great for me. No more brightly colored fog which occurred
randomly and often made the game impossible to play.

I'm on Gentoo with a 4.9.9 kernel, RX 460 card.

Thank you for the amazing work!

-- 
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/2] anv: Use build-id for pipeline cache UUID.

[Matt Turner]

On Wed, Feb 15, 2017 at 6:05 AM, Emil Velikov  wrote:
> Hi Matt,
>
> On 14 February 2017 at 23:58, Matt Turner  wrote:
>> The --build-id=... ld flag has been present since binutils-2.18,
>> released 28 Aug 2007.
>> ---
>>  src/intel/vulkan/Makefile.am  |  1 +
>>  src/intel/vulkan/anv_device.c | 28 +++-
>>  2 files changed, 8 insertions(+), 21 deletions(-)
>>
>> diff --git a/src/intel/vulkan/Makefile.am b/src/intel/vulkan/Makefile.am
>> index 95f276e..4197b0e 100644
>> --- a/src/intel/vulkan/Makefile.am
>> +++ b/src/intel/vulkan/Makefile.am
>> @@ -165,6 +165,7 @@ libvulkan_intel_la_LDFLAGS = \
>> -module \
>> -no-undefined \
>> -avoid-version \
>> +   -Wl,--build-id=sha1 \
> Did you mean to have this as-is and update to $sha1 as a follow-up commit ?

I'm not sure what you mean.

I added -Wl,--build-id=sha1 in this patch, because it is at this point
that we begin relying on having a .note.gnu.build-id section.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] util: Add utility build-id code.

[Matt Turner]

On Wed, Feb 15, 2017 at 4:03 AM, Emil Velikov  wrote:
> Hi Matt,
>
> Afaics dl_iterate_phdr is available on musl, (some?) BSDs and Solaris
> - thank you for opting for it.
>
> Out of curiosity:
> Have you checked if on those platforms the "GNU\0" strcmp is
> applicable and not another string ? Worth adding a note/comment ?

It's generated by GNU ld in all cases I'm aware of, so I think it's the same.

> On 14 February 2017 at 23:58, Matt Turner  wrote:
>> Provides the ability to read the .note.gnu.build-id section of ELF
>> binaries, which is inserted by the --build-id=... flag to ld.
>> ---
>>  configure.ac  |   2 +
>>  src/util/Makefile.sources |   2 +
>>  src/util/build_id.c   | 110 
>> ++
>>  src/util/build_id.h   |  34 ++
>>  4 files changed, 148 insertions(+)
>>  create mode 100644 src/util/build_id.c
>>  create mode 100644 src/util/build_id.h
>>
>> diff --git a/configure.ac b/configure.ac
>> index f001743..99c74f0 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -768,6 +768,8 @@ LIBS="$LIBS $DLOPEN_LIBS"
>>  AC_CHECK_FUNCS([dladdr])
>>  LIBS="$save_LIBS"
>>
>> +AC_CHECK_FUNC([dl_iterate_phdr], [DEFINES="$DEFINES 
>> -DHAVE_DL_ITERATE_PHDR"])
>> +
> What we want here is a local (in-configure) variable -> have_foo,
> which will be checked by ANV/others that depend on an actual
> implementation.
> As-is things will compile but we'll get a link error.
>
>
>> +const struct build_id_note *
>> +build_id_find_nhdr(const char *filename)
>> +{
>> +   struct callback_data data = {
>> +  .filename = filename,
>> +  .note = NULL,
>> +   };
>> +
>> +   if (dl_iterate_phdr(build_id_find_nhdr_callback, )) {
>> +  return data.note;
>> +   } else {
>> +  return NULL;
>> +   }
> Nit:
>
>if (!dl_iterate_phdr(build_id_find_nhdr_callback, ))
>   return NULL;
>
>return data.note;
>
>
>> diff --git a/src/util/build_id.h b/src/util/build_id.h
>> new file mode 100644
>> index 000..20db4ac
>> --- /dev/null
>> +++ b/src/util/build_id.h
>
>> +struct build_id_note;
>> +
>> +const struct build_id_note *
>> +build_id_find_nhdr(const char *filename);
>> +
>> +unsigned
>> +build_id_length(const struct build_id_note *note);
>> +
>> +void
>> +build_id_read(const struct build_id_note *note,
>> +  unsigned char *build_id, size_t n);
>
> With the configure fix, one can bring back the stubs here. Having a
> function declaration w/o a definition is a bit iffy.

I think having stubs was a bad idea from the outset. In any case one
of these stubs is called, something bad is going to happen.

I'll wrap the header in #ifdef HAVE_DL_ITERATE_PHDR instead.

> With the above:
> Reviewed-by: Emil Velikov 

Thanks. I'll incorporate these changes and send a v3.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] getteximage: Return correct error value when texure object is not found

[Eduardo Lima Mitev]

On 02/15/2017 01:56 PM, Nicolai Hähnle wrote:
> On 15.02.2017 12:14, Eduardo Lima Mitev wrote:
>> glGetTextureSubImage() and glGetCompressedTextureSubImage() are currently
>> returning INVALID_OPERATION error when the passed texture argument
>> does not
>> correspond to an existing texture object. However, the error should be
>> INVALID_VALUE instead. From OpenGL 4.5 spec PDF, section '8.11. Texture
>> Queries', page 236:
>>
>> "An INVALID_VALUE error is generated if texture is not the name of
>>  an existing texture object."
>>
>> Same wording applies to the compressed version.
>>
>> The INVALID_OPERATION error is coming from the call to
>> _mesa_lookup_texture_err(). This patch uses _mesa_lookup_texture()
>> instead
>> and emits the correct error in the caller instead.
>>
>> Fixes: GL45-CTS.get_texture_sub_image.errors_test
> 
> Reviewed-by: Nicolai Hähnle 
> 

Just merged the patch. Thanks, Nicolai!

I forgot to comment that there is a piglit regression with this patch,
but it is an error in the test. I have submitted a fix for it too:

https://lists.freedesktop.org/archives/piglit/2017-February/021804.html

Eduardo

>> ---
>>  src/mesa/main/texgetimage.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
>> index b0ced1eac0f..c0c50b0518b 100644
>> --- a/src/mesa/main/texgetimage.c
>> +++ b/src/mesa/main/texgetimage.c
>> @@ -1459,9 +1459,10 @@ _mesa_GetTextureSubImage(GLuint texture, GLint
>> level,
>> GET_CURRENT_CONTEXT(ctx);
>> static const char *caller = "glGetTextureSubImage";
>> struct gl_texture_object *texObj =
>> -  _mesa_lookup_texture_err(ctx, texture, caller);
>> +  _mesa_lookup_texture(ctx, texture);
>>
>> if (!texObj) {
>> +  _mesa_error(ctx, GL_INVALID_VALUE, "%s(texture)", caller);
>>return;
>> }
>>
>> @@ -1775,8 +1776,9 @@ _mesa_GetCompressedTextureSubImage(GLuint
>> texture, GLint level,
>> static const char *caller = "glGetCompressedTextureImage";
>> struct gl_texture_object *texObj;
>>
>> -   texObj = _mesa_lookup_texture_err(ctx, texture, caller);
>> +   texObj = _mesa_lookup_texture(ctx, texture);
>> if (!texObj) {
>> +  _mesa_error(ctx, GL_INVALID_VALUE, "%s(texture)", caller);
>>return;
>> }
>>
>>
> 
> 

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

Re: [Mesa-dev] [PATCH] anv/formats: handle correctly multisamples in gen7

[Jason Ekstrand]

On Wed, Feb 15, 2017 at 10:09 AM, Juan A. Suarez Romero  wrote:

> According to Ivybridge PRM, Volume 4 Part 1 p73, signed integer formats
> cannot be multisampled.
>
> Also in the same PRM p63, any format with greater than 64 bits per
> element cannot be multisampled.
>
> This fixes the following Vulkan CTS tests in Haswell:
>
> dEQP-VK.memory.requirements.image.regular_tiling_optimal
> dEQP-VK.memory.requirements.image.transient_tiling_optimal
>
> It also fixes crashes in the following Vulkan CTS tests in Haswell
> (becoming now
> skip):
>
> dEQP-VK.glsl.texture_functions.query.texturesamples.isampler2dms_fragment
> dEQP-VK.glsl.texture_functions.query.texturesamples.isampler2dms_vertex
> dEQP-VK.glsl.texture_functions.query.texturesamples.
> isampler2dmsarray_fragment
> dEQP-VK.glsl.texture_functions.query.texturesamples.
> isampler2dmsarray_vertex
> dEQP-VK.pipeline.multisample.sampled_image.64x64_1.r16g16_sint.samples_4
> dEQP-VK.pipeline.multisample.sampled_image.64x64_1.r16g16_sint.samples_8
> dEQP-VK.pipeline.multisample.sampled_image.64x64_1.
> r32g32b32a32_sfloat.samples_4
> dEQP-VK.pipeline.multisample.sampled_image.64x64_1.
> r32g32b32a32_sfloat.samples_8
> dEQP-VK.pipeline.multisample.sampled_image.64x64_4.r16g16_sint.samples_4
> dEQP-VK.pipeline.multisample.sampled_image.64x64_4.r16g16_sint.samples_8
> dEQP-VK.pipeline.multisample.sampled_image.64x64_4.
> r32g32b32a32_sfloat.samples_4
> dEQP-VK.pipeline.multisample.sampled_image.64x64_4.
> r32g32b32a32_sfloat.samples_8
> dEQP-VK.pipeline.multisample.sampled_image.79x31_1.r16g16_sint.samples_4
> dEQP-VK.pipeline.multisample.sampled_image.79x31_1.r16g16_sint.samples_8
> dEQP-VK.pipeline.multisample.sampled_image.79x31_1.
> r32g32b32a32_sfloat.samples_4
> dEQP-VK.pipeline.multisample.sampled_image.79x31_1.
> r32g32b32a32_sfloat.samples_8
> dEQP-VK.pipeline.multisample.sampled_image.79x31_4.r16g16_sint.samples_4
> dEQP-VK.pipeline.multisample.sampled_image.79x31_4.r16g16_sint.samples_8
> dEQP-VK.pipeline.multisample.sampled_image.79x31_4.
> r32g32b32a32_sfloat.samples_4
> dEQP-VK.pipeline.multisample.sampled_image.79x31_4.
> r32g32b32a32_sfloat.samples_8
>
> Signed-off-by: Juan A. Suarez Romero 
> ---
>  src/intel/vulkan/anv_device.c  |  4 ++--
>  src/intel/vulkan/anv_formats.c | 32 
>  2 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index d1a6cc8..a8ab8c3 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -622,12 +622,12 @@ void anv_GetPhysicalDeviceProperties(
>.maxFramebufferWidth  = (1 << 14),
>.maxFramebufferHeight = (1 << 14),
>.maxFramebufferLayers = (1 << 11),
> -  .framebufferColorSampleCounts = sample_counts,
> +  .framebufferColorSampleCounts = devinfo->gen == 7 ?
> VK_SAMPLE_COUNT_1_BIT : sample_counts,
>.framebufferDepthSampleCounts = sample_counts,
>.framebufferStencilSampleCounts   = sample_counts,
>.framebufferNoAttachmentsSampleCounts = sample_counts,
>.maxColorAttachments  = MAX_RTS,
> -  .sampledImageColorSampleCounts= sample_counts,
> +  .sampledImageColorSampleCounts= devinfo->gen == 7 ?
> VK_SAMPLE_COUNT_1_BIT : sample_counts,
>

The Vulkan spec says we're supposed to support at least 1x and 4x on both
of these.

So I guess the real question is what's the best choice that will let apps
run.  My feeling is that setting these fields to 1x and 4x and then just
dying horribly if they use an integer format is probably actually the
better choice.  That said, we should definitely make sure we're dying
horribly if they use an integer format!


>.sampledImageIntegerSampleCounts  = VK_SAMPLE_COUNT_1_BIT,
>.sampledImageDepthSampleCounts= sample_counts,
>.sampledImageStencilSampleCounts  = sample_counts,
> diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_
> formats.c
> index 6005791..3eac931 100644
> --- a/src/intel/vulkan/anv_formats.c
> +++ b/src/intel/vulkan/anv_formats.c
> @@ -561,6 +561,38 @@ anv_get_image_format_properties(
>sampleCounts = isl_device_get_sample_counts(&
> physical_device->isl_dev);
> }
>
> +   /*
> +* From the Ivybridge PRM, Volume 4 Part 1 p73, SURFACE_STATE, Number
> of
> +* Multisamples:
> +*
> +*- This field must be set to MULTISAMPLECOUNT_1 for SINT MSRTs
> when
> +*  all RT channels are not written.
> +*
> +* And errata from the Ivybridge PRM, Volume 4 Part 1 p77,
> +* RENDER_SURFACE_STATE, MCS Enable:
> +*
> +*   This field must be set to 0 [MULTISAMPLECOUNT_1] for all SINT
> MSRTs
> +*   when all RT channels are not written.
> +*
> +* Note that the above 

[Mesa-dev] [PATCH] anv/formats: handle correctly multisamples in gen7

[Juan A. Suarez Romero]

According to Ivybridge PRM, Volume 4 Part 1 p73, signed integer formats
cannot be multisampled.

Also in the same PRM p63, any format with greater than 64 bits per
element cannot be multisampled.

This fixes the following Vulkan CTS tests in Haswell:

dEQP-VK.memory.requirements.image.regular_tiling_optimal
dEQP-VK.memory.requirements.image.transient_tiling_optimal

It also fixes crashes in the following Vulkan CTS tests in Haswell (becoming now
skip):

dEQP-VK.glsl.texture_functions.query.texturesamples.isampler2dms_fragment
dEQP-VK.glsl.texture_functions.query.texturesamples.isampler2dms_vertex
dEQP-VK.glsl.texture_functions.query.texturesamples.isampler2dmsarray_fragment
dEQP-VK.glsl.texture_functions.query.texturesamples.isampler2dmsarray_vertex
dEQP-VK.pipeline.multisample.sampled_image.64x64_1.r16g16_sint.samples_4
dEQP-VK.pipeline.multisample.sampled_image.64x64_1.r16g16_sint.samples_8
dEQP-VK.pipeline.multisample.sampled_image.64x64_1.r32g32b32a32_sfloat.samples_4
dEQP-VK.pipeline.multisample.sampled_image.64x64_1.r32g32b32a32_sfloat.samples_8
dEQP-VK.pipeline.multisample.sampled_image.64x64_4.r16g16_sint.samples_4
dEQP-VK.pipeline.multisample.sampled_image.64x64_4.r16g16_sint.samples_8
dEQP-VK.pipeline.multisample.sampled_image.64x64_4.r32g32b32a32_sfloat.samples_4
dEQP-VK.pipeline.multisample.sampled_image.64x64_4.r32g32b32a32_sfloat.samples_8
dEQP-VK.pipeline.multisample.sampled_image.79x31_1.r16g16_sint.samples_4
dEQP-VK.pipeline.multisample.sampled_image.79x31_1.r16g16_sint.samples_8
dEQP-VK.pipeline.multisample.sampled_image.79x31_1.r32g32b32a32_sfloat.samples_4
dEQP-VK.pipeline.multisample.sampled_image.79x31_1.r32g32b32a32_sfloat.samples_8
dEQP-VK.pipeline.multisample.sampled_image.79x31_4.r16g16_sint.samples_4
dEQP-VK.pipeline.multisample.sampled_image.79x31_4.r16g16_sint.samples_8
dEQP-VK.pipeline.multisample.sampled_image.79x31_4.r32g32b32a32_sfloat.samples_4
dEQP-VK.pipeline.multisample.sampled_image.79x31_4.r32g32b32a32_sfloat.samples_8

Signed-off-by: Juan A. Suarez Romero 
---
 src/intel/vulkan/anv_device.c  |  4 ++--
 src/intel/vulkan/anv_formats.c | 32 
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index d1a6cc8..a8ab8c3 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -622,12 +622,12 @@ void anv_GetPhysicalDeviceProperties(
   .maxFramebufferWidth  = (1 << 14),
   .maxFramebufferHeight = (1 << 14),
   .maxFramebufferLayers = (1 << 11),
-  .framebufferColorSampleCounts = sample_counts,
+  .framebufferColorSampleCounts = devinfo->gen == 7 ? 
VK_SAMPLE_COUNT_1_BIT : sample_counts,
   .framebufferDepthSampleCounts = sample_counts,
   .framebufferStencilSampleCounts   = sample_counts,
   .framebufferNoAttachmentsSampleCounts = sample_counts,
   .maxColorAttachments  = MAX_RTS,
-  .sampledImageColorSampleCounts= sample_counts,
+  .sampledImageColorSampleCounts= devinfo->gen == 7 ? 
VK_SAMPLE_COUNT_1_BIT : sample_counts,
   .sampledImageIntegerSampleCounts  = VK_SAMPLE_COUNT_1_BIT,
   .sampledImageDepthSampleCounts= sample_counts,
   .sampledImageStencilSampleCounts  = sample_counts,
diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_formats.c
index 6005791..3eac931 100644
--- a/src/intel/vulkan/anv_formats.c
+++ b/src/intel/vulkan/anv_formats.c
@@ -561,6 +561,38 @@ anv_get_image_format_properties(
   sampleCounts = isl_device_get_sample_counts(_device->isl_dev);
}
 
+   /*
+* From the Ivybridge PRM, Volume 4 Part 1 p73, SURFACE_STATE, Number of
+* Multisamples:
+*
+*- This field must be set to MULTISAMPLECOUNT_1 for SINT MSRTs when
+*  all RT channels are not written.
+*
+* And errata from the Ivybridge PRM, Volume 4 Part 1 p77,
+* RENDER_SURFACE_STATE, MCS Enable:
+*
+*   This field must be set to 0 [MULTISAMPLECOUNT_1] for all SINT MSRTs
+*   when all RT channels are not written.
+*
+* Note that the above SINT restrictions apply only to *MSRTs* (that is,
+* *multisampled* render targets). The restrictions seem to permit an MCS
+* if the render target is singlesampled.
+*
+* From the IvyBridge PRM, Volume 4 Part 1 p63, SURFACE_STATE, Surface
+* Format:
+*
+*If Number of Multisamples is set to a value other than
+*MULTISAMPLECOUNT_1, this field cannot be set to the following
+*formats: any format with greater than 64 bits per element, if Number
+*of Multisamples is MULTISAMPLECOUNT_8, any compressed texture format
+*(BC*), and any YCRCB* format.
+*/
+   if (physical_device->info.gen < 8 &&
+   

Re: [Mesa-dev] [PATCH] util: Fix a typo in Makefile.sources

[Eric Engestrom]

Reviewed-by: Eric Engestrom 

On Wednesday, 2017-02-15 09:30:01 -0800, Jason Ekstrand wrote:
> ---
>  src/util/Makefile.sources | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
> index eec0311..aecb7c2 100644
> --- a/src/util/Makefile.sources
> +++ b/src/util/Makefile.sources
> @@ -45,7 +45,7 @@ MESA_UTIL_FILES :=  \
>   u_vector.c \
>   u_vector.h \
>   vk_alloc.h \
> - vk_utils.h
> + vk_util.h
>  
>  MESA_UTIL_GENERATED_FILES = \
>   format_srgb.c
> -- 
> 2.5.0.400.gff86faf
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: _eglFilterArray's filter is always non-null

[Eric Engestrom]

On Wednesday, 2017-02-15 15:36:00 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Drop the extra handling and assert() if things change in the future.
> 
> Signed-off-by: Emil Velikov 

Reviewed-by: Eric Engestrom 

> ---
>  src/egl/main/eglarray.c | 27 +--
>  1 file changed, 9 insertions(+), 18 deletions(-)
> 
> diff --git a/src/egl/main/eglarray.c b/src/egl/main/eglarray.c
> index d2f39af49a..ba6cb3e6a4 100644
> --- a/src/egl/main/eglarray.c
> +++ b/src/egl/main/eglarray.c
> @@ -26,6 +26,7 @@
>   **/
>  
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -157,25 +158,15 @@ _eglFilterArray(_EGLArray *array, void **data, EGLint 
> size,
> if (!array)
>return 0;
>  
> -   if (filter) {
> -  for (i = 0; i < array->Size; i++) {
> - if (filter(array->Elements[i], filter_data)) {
> -if (data && count < size)
> -   data[count] = array->Elements[i];
> -count++;
> - }
> - if (data && count >= size)
> -break;
> -  }
> -   }
> -   else {
> -  if (data) {
> - count = (size < array->Size) ? size : array->Size;
> - memcpy(data, array->Elements, count * sizeof(array->Elements[0]));
> -  }
> -  else {
> - count = array->Size;
> +   assert(filter);
> +   for (i = 0; i < array->Size; i++) {
> +  if (filter(array->Elements[i], filter_data)) {
> + if (data && count < size)
> +data[count] = array->Elements[i];
> + count++;
>}
> +  if (data && count >= size)
> + break;
> }
>  
> return count;
> -- 
> 2.11.0
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] util: Fix a typo in Makefile.sources

[Jason Ekstrand]

---
 src/util/Makefile.sources | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
index eec0311..aecb7c2 100644
--- a/src/util/Makefile.sources
+++ b/src/util/Makefile.sources
@@ -45,7 +45,7 @@ MESA_UTIL_FILES :=\
u_vector.c \
u_vector.h \
vk_alloc.h \
-   vk_utils.h
+   vk_util.h
 
 MESA_UTIL_GENERATED_FILES = \
format_srgb.c
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH 1/2] util: Add helpers for iterating over Vulkan extension structs

[Jason Ekstrand]

On Wed, Feb 15, 2017 at 2:14 AM, Grazvydas Ignotas 
wrote:

> On Wed, Feb 15, 2017 at 2:03 AM, Jason Ekstrand 
> wrote:
> > ---
> >  src/util/Makefile.sources |  3 ++-
> >  src/util/vk_util.h| 43 ++
> +
> >  2 files changed, 45 insertions(+), 1 deletion(-)
> >  create mode 100644 src/util/vk_util.h
> >
> > diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
> > index a68a5fe..eec0311 100644
> > --- a/src/util/Makefile.sources
> > +++ b/src/util/Makefile.sources
> > @@ -44,7 +44,8 @@ MESA_UTIL_FILES :=\
> > u_endian.h \
> > u_vector.c \
> > u_vector.h \
> > -   vk_alloc.h
> > +   vk_alloc.h \
> > +   vk_utils.h
>
> did you mean vk_util.h ?
>

Oops


> >
> >  MESA_UTIL_GENERATED_FILES = \
> > format_srgb.c
> > diff --git a/src/util/vk_util.h b/src/util/vk_util.h
> > new file mode 100644
> > index 000..e0b5d0b
> > --- /dev/null
> > +++ b/src/util/vk_util.h
>
> Gražvydas
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: define default allow_higher_compat_version value

[Matt Turner]

Reviewed-by: Matt Turner 

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

Re: [Mesa-dev] [PATCH] i965: define default allow_higher_compat_version value

[Samuel Pitoiset]

Thanks.

Reviewed-by: Samuel Pitoiset 

On 02/15/2017 05:59 PM, Lionel Landwerlin wrote:

Signed-off-by: Lionel Landwerlin 
Fixes: 9d16f3903e2 ("driconf: add allow_higher_compat_version option")
---
 src/mesa/drivers/dri/i965/intel_screen.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 83b1f3ff55..d6a88a149f 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -84,6 +84,7 @@ DRI_CONF_BEGIN
   DRI_CONF_DISABLE_BLEND_FUNC_EXTENDED("false")
   DRI_CONF_DUAL_COLOR_BLEND_BY_LOCATION("false")
   DRI_CONF_ALLOW_GLSL_EXTENSION_DIRECTIVE_MIDSHADER("false")
+  DRI_CONF_ALLOW_HIGHER_COMPAT_VERSION("false")

   DRI_CONF_OPT_BEGIN_B(shader_precompile, "true")
 DRI_CONF_DESC(en, "Perform code generation at shader link time.")


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

[Mesa-dev] [PATCH] i965: define default allow_higher_compat_version value

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
Fixes: 9d16f3903e2 ("driconf: add allow_higher_compat_version option")
---
 src/mesa/drivers/dri/i965/intel_screen.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 83b1f3ff55..d6a88a149f 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -84,6 +84,7 @@ DRI_CONF_BEGIN
   DRI_CONF_DISABLE_BLEND_FUNC_EXTENDED("false")
   DRI_CONF_DUAL_COLOR_BLEND_BY_LOCATION("false")
   DRI_CONF_ALLOW_GLSL_EXTENSION_DIRECTIVE_MIDSHADER("false")
+  DRI_CONF_ALLOW_HIGHER_COMPAT_VERSION("false")
 
   DRI_CONF_OPT_BEGIN_B(shader_precompile, "true")
 DRI_CONF_DESC(en, "Perform code generation at shader link time.")
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH v2 1/4] driconf: add allow_higher_compat_version option

[Lionel Landwerlin]

Hey Samuel,

I think you forgot to define the default value for our driver.
I'm not too familiar with this code. Is there a way to have default 
values for all dri drivers?


Thanks,

-
Lionel

On 15/02/17 16:42, Samuel Pitoiset wrote:



On 02/15/2017 05:36 PM, Mark Janes wrote:

With this series, I encounter the following crash using wflinfo:

wflinfo: src/mesa/drivers/dri/common/xmlconfig.c:1028: 
driQueryOptionb: Assertion `cache->info[i].name != ((void *)0)' failed.


Mmh.
Can you provide a full backtrace?



Samuel Pitoiset  writes:


Mesa currently doesn't allow to create 3.1+ compatibility profiles
mainly because various features are unimplemented and bugs can
happen.

However, some buggy apps request a compat profile without using
any old features unimplemented in mesa, and they fail to start.

This option should help some games to run but it's not enough
for all (eg. Dying Ligth).

v2: - s/force_compat_profile/allow_higher_compat_version

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/include/state_tracker/st_api.h  | 1 +
 src/gallium/state_trackers/dri/dri_screen.c | 3 +++
 src/mesa/drivers/dri/common/xmlpool/t_options.h | 5 +
 src/mesa/drivers/dri/i965/brw_context.c | 3 +++
 src/mesa/main/mtypes.h  | 7 +++
 src/mesa/main/version.c | 6 --
 src/mesa/state_tracker/st_extensions.c  | 2 ++
 7 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/src/gallium/include/state_tracker/st_api.h 
b/src/gallium/include/state_tracker/st_api.h

index a2e37d2e48..1b9ef290b1 100644
--- a/src/gallium/include/state_tracker/st_api.h
+++ b/src/gallium/include/state_tracker/st_api.h
@@ -245,6 +245,7 @@ struct st_config_options
unsigned force_glsl_version;
boolean force_s3tc_enable;
boolean allow_glsl_extension_directive_midshader;
+   boolean allow_higher_compat_version;
boolean glsl_zero_init;
 };

diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
b/src/gallium/state_trackers/dri/dri_screen.c

index a950f5241d..1e278c3d1c 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -70,6 +70,7 @@ const __DRIconfigOptionsExtension 
gallium_config_options = {

  DRI_CONF_DISABLE_SHADER_BIT_ENCODING("false")
  DRI_CONF_FORCE_GLSL_VERSION(0)
DRI_CONF_ALLOW_GLSL_EXTENSION_DIRECTIVE_MIDSHADER("false")
+ DRI_CONF_ALLOW_HIGHER_COMPAT_VERSION("false")
   DRI_CONF_SECTION_END

   DRI_CONF_SECTION_MISCELLANEOUS
@@ -99,6 +100,8 @@ dri_fill_st_options(struct st_config_options 
*options,

   driQueryOptionb(optionCache, "force_s3tc_enable");
options->allow_glsl_extension_directive_midshader =
   driQueryOptionb(optionCache, 
"allow_glsl_extension_directive_midshader");

+   options->allow_higher_compat_version =
+  driQueryOptionb(optionCache, "allow_higher_compat_version");
options->glsl_zero_init = driQueryOptionb(optionCache, 
"glsl_zero_init");

 }

diff --git a/src/mesa/drivers/dri/common/xmlpool/t_options.h 
b/src/mesa/drivers/dri/common/xmlpool/t_options.h

index a189bbedec..f200093177 100644
--- a/src/mesa/drivers/dri/common/xmlpool/t_options.h
+++ b/src/mesa/drivers/dri/common/xmlpool/t_options.h
@@ -115,6 +115,11 @@ 
DRI_CONF_OPT_BEGIN_B(allow_glsl_extension_directive_midshader, def) \
 DRI_CONF_DESC(en,gettext("Allow GLSL #extension directives 
in the middle of shaders")) \

 DRI_CONF_OPT_END

+#define DRI_CONF_ALLOW_HIGHER_COMPAT_VERSION(def) \
+DRI_CONF_OPT_BEGIN_B(allow_higher_compat_version, def) \
+DRI_CONF_DESC(en,gettext("Allow a higher compat profile 
(version 3.1+) for apps that request it")) \

+DRI_CONF_OPT_END
+


 /**
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c

index 7240b1f445..c56a14e3d6 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -916,6 +916,9 @@ brw_process_driconf_options(struct brw_context 
*brw)

ctx->Const.AllowGLSLExtensionDirectiveMidShader =
   driQueryOptionb(options, 
"allow_glsl_extension_directive_midshader");


+   ctx->Const.AllowHigherCompatVersion =
+  driQueryOptionb(options, "allow_higher_compat_version");
+
ctx->Const.GLSLZeroInit = driQueryOptionb(options, 
"glsl_zero_init");


brw->dual_color_blend_by_location =
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index a845a394c8..08bd929255 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3501,6 +3501,13 @@ struct gl_constants
GLboolean AllowGLSLExtensionDirectiveMidShader;

/**
+* Allow creating a higher compat profile (version 3.1+) for 
apps that
+* request it. Be careful when adding that driconf option 
because some

+* features are unimplemented and might not work correctly.
+*/
+   GLboolean AllowHigherCompatVersion;
+
+   /**
 * Force uninitialized 

Re: [Mesa-dev] [PATCH 32/32] r600/radeonsi: enable glsl/tgsi on-disk cache

[Marek Olšák]

On Wed, Feb 15, 2017 at 1:49 PM, Nicolai Hähnle  wrote:
> On 14.02.2017 23:51, Marek Olšák wrote:
>>
>> On Tue, Feb 14, 2017 at 11:47 PM, Timothy Arceri 
>> wrote:
>>>
>>>
>>>
>>> On 15/02/17 08:35, Marek Olšák wrote:


 On Tue, Feb 14, 2017 at 9:53 PM, Timothy Arceri 
 wrote:
>
>
> On 15/02/17 02:14, Marek Olšák wrote:
>
>> On Tue, Feb 14, 2017 at 1:52 AM, Timothy Arceri
>> 
>> wrote:
>>>
>>>
>>> ---
>>>src/gallium/drivers/r600/r600_pipe.c  | 10 ++
>>>src/gallium/drivers/radeon/r600_pipe_common.c |  2 +-
>>>src/gallium/drivers/radeon/r600_pipe_common.h |  1 +
>>>src/gallium/drivers/radeonsi/si_pipe.c| 11 +++
>>>src/gallium/include/pipe/p_screen.h   |  3 +++
>>>src/mesa/state_tracker/st_context.c   |  2 ++
>>>6 files changed, 28 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/drivers/r600/r600_pipe.c
>>> b/src/gallium/drivers/r600/r600_pipe.c
>>> index 5290f40..bdd8c0a 100644
>>> --- a/src/gallium/drivers/r600/r600_pipe.c
>>> +++ b/src/gallium/drivers/r600/r600_pipe.c
>>> @@ -600,6 +600,7 @@ static void r600_destroy_screen(struct
>>> pipe_screen*
>>> pscreen)
>>>   compute_memory_pool_delete(rscreen->global_pool);
>>>   }
>>>
>>> +   disk_cache_destroy(rscreen->b.b.disk_shader_cache);
>>>   r600_destroy_common_screen(>b);
>>>}
>>>
>>> @@ -633,6 +634,15 @@ struct pipe_screen *r600_screen_create(struct
>>> radeon_winsys *ws)
>>>   return NULL;
>>>   }
>>>
>>> +   uint32_t mesa_timestamp;
>>> +   if (disk_cache_get_function_timestamp(r600_screen_create,
>>> _timestamp)) {
>>> +   char *timestamp_str;
>>> +   if (asprintf(_str, "%u", mesa_timestamp) !=
>>> -1)
>>> {
>>> +   rscreen->b.b.disk_shader_cache =
>>> disk_cache_create(r600_get_chip_name(>b), timestamp_str);
>>> +   free(timestamp_str);
>>> +   }
>>> +   }
>>> +
>>>   if (rscreen->b.info.chip_class >= EVERGREEN) {
>>>   rscreen->b.b.is_format_supported =
>>> evergreen_is_format_supported;
>>>   } else {
>>> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
>>> b/src/gallium/drivers/radeon/r600_pipe_common.c
>>> index 95a6a48..4e5582f 100644
>>> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
>>> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
>>> @@ -722,7 +722,7 @@ static const char* r600_get_device_vendor(struct
>>> pipe_screen* pscreen)
>>>   return "AMD";
>>>}
>>>
>>> -static const char* r600_get_chip_name(struct r600_common_screen
>>> *rscreen)
>>> +const char* r600_get_chip_name(struct r600_common_screen *rscreen)
>>>{
>>>   switch (rscreen->info.family) {
>>>   case CHIP_R600: return "AMD R600";
>>> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
>>> b/src/gallium/drivers/radeon/r600_pipe_common.h
>>> index 6eff9aa..0449d4d 100644
>>> --- a/src/gallium/drivers/radeon/r600_pipe_common.h
>>> +++ b/src/gallium/drivers/radeon/r600_pipe_common.h
>>> @@ -765,6 +765,7 @@ void radeon_save_cs(struct radeon_winsys *ws,
>>> struct
>>> radeon_winsys_cs *cs,
>>>   struct radeon_saved_cs *saved);
>>>void radeon_clear_saved_cs(struct radeon_saved_cs *saved);
>>>bool r600_check_device_reset(struct r600_common_context *rctx);
>>> +const char* r600_get_chip_name(struct r600_common_screen *rscreen);
>>>
>>>/* r600_gpu_load.c */
>>>void r600_gpu_load_kill_thread(struct r600_common_screen
>>> *rscreen);
>>> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
>>> b/src/gallium/drivers/radeonsi/si_pipe.c
>>> index 853d850..0bb95b1 100644
>>> --- a/src/gallium/drivers/radeonsi/si_pipe.c
>>> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
>>> @@ -712,6 +712,7 @@ static void si_destroy_screen(struct pipe_screen*
>>> pscreen)
>>>   }
>>>   }
>>>   pipe_mutex_destroy(sscreen->shader_parts_mutex);
>>> +   disk_cache_destroy(sscreen->b.b.disk_shader_cache);
>>>   si_destroy_shader_cache(sscreen);
>>>   r600_destroy_common_screen(>b);
>>>}
>>> @@ -801,6 +802,16 @@ struct pipe_screen
>>> *radeonsi_screen_create(struct
>>> radeon_winsys *ws)
>>>   return NULL;
>>>   }
>>>
>>> +   uint32_t mesa_timestamp, llvm_timestamp;
>>> +   if (disk_cache_get_function_timestamp(radeonsi_screen_create,
>>> 

Re: [Mesa-dev] [PATCH v2 1/4] driconf: add allow_higher_compat_version option

[Mark Janes]

With this series, I encounter the following crash using wflinfo:

wflinfo: src/mesa/drivers/dri/common/xmlconfig.c:1028: driQueryOptionb: 
Assertion `cache->info[i].name != ((void *)0)' failed.

Samuel Pitoiset  writes:

> Mesa currently doesn't allow to create 3.1+ compatibility profiles
> mainly because various features are unimplemented and bugs can
> happen.
>
> However, some buggy apps request a compat profile without using
> any old features unimplemented in mesa, and they fail to start.
>
> This option should help some games to run but it's not enough
> for all (eg. Dying Ligth).
>
> v2: - s/force_compat_profile/allow_higher_compat_version
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/gallium/include/state_tracker/st_api.h  | 1 +
>  src/gallium/state_trackers/dri/dri_screen.c | 3 +++
>  src/mesa/drivers/dri/common/xmlpool/t_options.h | 5 +
>  src/mesa/drivers/dri/i965/brw_context.c | 3 +++
>  src/mesa/main/mtypes.h  | 7 +++
>  src/mesa/main/version.c | 6 --
>  src/mesa/state_tracker/st_extensions.c  | 2 ++
>  7 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/include/state_tracker/st_api.h 
> b/src/gallium/include/state_tracker/st_api.h
> index a2e37d2e48..1b9ef290b1 100644
> --- a/src/gallium/include/state_tracker/st_api.h
> +++ b/src/gallium/include/state_tracker/st_api.h
> @@ -245,6 +245,7 @@ struct st_config_options
> unsigned force_glsl_version;
> boolean force_s3tc_enable;
> boolean allow_glsl_extension_directive_midshader;
> +   boolean allow_higher_compat_version;
> boolean glsl_zero_init;
>  };
>  
> diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
> b/src/gallium/state_trackers/dri/dri_screen.c
> index a950f5241d..1e278c3d1c 100644
> --- a/src/gallium/state_trackers/dri/dri_screen.c
> +++ b/src/gallium/state_trackers/dri/dri_screen.c
> @@ -70,6 +70,7 @@ const __DRIconfigOptionsExtension gallium_config_options = {
>   DRI_CONF_DISABLE_SHADER_BIT_ENCODING("false")
>   DRI_CONF_FORCE_GLSL_VERSION(0)
>   DRI_CONF_ALLOW_GLSL_EXTENSION_DIRECTIVE_MIDSHADER("false")
> + DRI_CONF_ALLOW_HIGHER_COMPAT_VERSION("false")
>DRI_CONF_SECTION_END
>  
>DRI_CONF_SECTION_MISCELLANEOUS
> @@ -99,6 +100,8 @@ dri_fill_st_options(struct st_config_options *options,
>driQueryOptionb(optionCache, "force_s3tc_enable");
> options->allow_glsl_extension_directive_midshader =
>driQueryOptionb(optionCache, 
> "allow_glsl_extension_directive_midshader");
> +   options->allow_higher_compat_version =
> +  driQueryOptionb(optionCache, "allow_higher_compat_version");
> options->glsl_zero_init = driQueryOptionb(optionCache, "glsl_zero_init");
>  }
>  
> diff --git a/src/mesa/drivers/dri/common/xmlpool/t_options.h 
> b/src/mesa/drivers/dri/common/xmlpool/t_options.h
> index a189bbedec..f200093177 100644
> --- a/src/mesa/drivers/dri/common/xmlpool/t_options.h
> +++ b/src/mesa/drivers/dri/common/xmlpool/t_options.h
> @@ -115,6 +115,11 @@ 
> DRI_CONF_OPT_BEGIN_B(allow_glsl_extension_directive_midshader, def) \
>  DRI_CONF_DESC(en,gettext("Allow GLSL #extension directives in the 
> middle of shaders")) \
>  DRI_CONF_OPT_END
>  
> +#define DRI_CONF_ALLOW_HIGHER_COMPAT_VERSION(def) \
> +DRI_CONF_OPT_BEGIN_B(allow_higher_compat_version, def) \
> +DRI_CONF_DESC(en,gettext("Allow a higher compat profile (version 
> 3.1+) for apps that request it")) \
> +DRI_CONF_OPT_END
> +
>  
>  
>  /**
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 7240b1f445..c56a14e3d6 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -916,6 +916,9 @@ brw_process_driconf_options(struct brw_context *brw)
> ctx->Const.AllowGLSLExtensionDirectiveMidShader =
>driQueryOptionb(options, "allow_glsl_extension_directive_midshader");
>  
> +   ctx->Const.AllowHigherCompatVersion =
> +  driQueryOptionb(options, "allow_higher_compat_version");
> +
> ctx->Const.GLSLZeroInit = driQueryOptionb(options, "glsl_zero_init");
>  
> brw->dual_color_blend_by_location =
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index a845a394c8..08bd929255 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3501,6 +3501,13 @@ struct gl_constants
> GLboolean AllowGLSLExtensionDirectiveMidShader;
>  
> /**
> +* Allow creating a higher compat profile (version 3.1+) for apps that
> +* request it. Be careful when adding that driconf option because some
> +* features are unimplemented and might not work correctly.
> +*/
> +   GLboolean AllowHigherCompatVersion;
> +
> +   /**
>  * Force uninitialized variables to default to zero.
>  */
> GLboolean GLSLZeroInit;
> diff --git a/src/mesa/main/version.c 

Re: [Mesa-dev] [PATCH v2 6/6] anv: do not open random render node(s)

[Emil Velikov]

On 15 February 2017 at 16:38, Ilia Mirkin  wrote:

>> +anv_enumerate_devices(struct anv_instance *instance)
>> +{
>> +   /* TODO: Check for more devices ? */
>> +   drmDevicePtr devices[8];
>> +   VkResult result = VK_SUCCESS;
Should read

   VkResult result = VK_ERROR_INCOMPATIBLE_DRIVER;

>> +   int max_devices;
>> +
>> +   instance->physicalDeviceCount = 0;
>> +
>> +   max_devices = drmGetDevices2(0, devices, sizeof(devices));
>> +   if (max_devices < 1)
>> +  return VK_ERROR_INCOMPATIBLE_DRIVER;
>
> so result = VK_SUCCESS
>
>> +
>> +   for (unsigned i = 0; i < (unsigned)max_devices; i++) {
>> +  if (devices[i]->available_nodes & 1 << DRM_NODE_RENDER &&
>> +  devices[i]->bustype == DRM_BUS_PCI &&
>> +  devices[i]->deviceinfo.pci->vendor_id == 0x8086) {
>
> let's say this never triggers
>
>> +
>> + result = anv_physical_device_init(>physicalDevice,
>> +instance,
>> +devices[i]->nodes[DRM_NODE_RENDER]);
>> + if (result != VK_ERROR_INCOMPATIBLE_DRIVER)
>> +break;
>> +  }
>> +   }
>
> result is still VK_SUCCESS. Seems like it should default to
> VK_ERROR_INCOMPATIBLE_DRIVER instead?
>
You're spot on - VK_ERROR_INCOMPATIBLE_DRIVER is what we want.

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

Re: [Mesa-dev] [RFC] nir/builder: Add support for easily building control-flow

[Jason Ekstrand]

Only build-tested.

On Wed, Feb 15, 2017 at 8:43 AM, Jason Ekstrand 
wrote:

> ---
>  src/compiler/nir/nir_builder.h | 41 ++
> +++
>  1 file changed, 41 insertions(+)
>
> diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_
> builder.h
> index 194d327..cdfc15b 100644
> --- a/src/compiler/nir/nir_builder.h
> +++ b/src/compiler/nir/nir_builder.h
> @@ -81,6 +81,47 @@ nir_builder_cf_insert(nir_builder *build, nir_cf_node
> *cf)
> nir_cf_node_insert(build->cursor, cf);
>  }
>
> +static inline void
> +nir_push_if(nir_builder *build, nir_ssa_def *condition)
> +{
> +   nir_if *nif = nir_if_create(build->shader);
> +   nif->condition = nir_src_for_ssa(condition);
> +   nir_builder_cf_insert(build, >cf_node);
> +   build->cursor = nir_before_cf_list(>then_list);
> +}
> +
> +static inline void
> +nir_push_else(nir_builder *build)
> +{
> +   nir_block *block = nir_cursor_current_block(build->cursor);
> +   nir_if *nif = nir_cf_node_as_if(block->cf_node.parent);
> +   build->cursor = nir_before_cf_list(>else_list);
> +}
> +
> +static inline void
> +nir_pop_if(nir_builder *build)
> +{
> +   nir_block *block = nir_cursor_current_block(build->cursor);
> +   nir_if *nif = nir_cf_node_as_if(block->cf_node.parent);
> +   build->cursor = nir_after_cf_node(>cf_node);
> +}
> +
> +static inline void
> +nir_push_loop(nir_builder *build)
> +{
> +   nir_loop *loop = nir_loop_create(build->shader);
> +   nir_builder_cf_insert(build, >cf_node);
> +   build->cursor = nir_before_cf_list(>body);
> +}
> +
> +static inline void
> +nir_pop_loop(nir_builder *build)
> +{
> +   nir_block *block = nir_cursor_current_block(build->cursor);
> +   nir_loop *loop = nir_cf_node_as_loop(block->cf_node.parent);
> +   build->cursor = nir_after_cf_node(>cf_node);
> +}
> +
>  static inline nir_ssa_def *
>  nir_ssa_undef(nir_builder *build, unsigned num_components, unsigned
> bit_size)
>  {
> --
> 2.5.0.400.gff86faf
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [RFC] nir/builder: Add support for easily building control-flow

[Jason Ekstrand]

---
 src/compiler/nir/nir_builder.h | 41 +
 1 file changed, 41 insertions(+)

diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
index 194d327..cdfc15b 100644
--- a/src/compiler/nir/nir_builder.h
+++ b/src/compiler/nir/nir_builder.h
@@ -81,6 +81,47 @@ nir_builder_cf_insert(nir_builder *build, nir_cf_node *cf)
nir_cf_node_insert(build->cursor, cf);
 }
 
+static inline void
+nir_push_if(nir_builder *build, nir_ssa_def *condition)
+{
+   nir_if *nif = nir_if_create(build->shader);
+   nif->condition = nir_src_for_ssa(condition);
+   nir_builder_cf_insert(build, >cf_node);
+   build->cursor = nir_before_cf_list(>then_list);
+}
+
+static inline void
+nir_push_else(nir_builder *build)
+{
+   nir_block *block = nir_cursor_current_block(build->cursor);
+   nir_if *nif = nir_cf_node_as_if(block->cf_node.parent);
+   build->cursor = nir_before_cf_list(>else_list);
+}
+
+static inline void
+nir_pop_if(nir_builder *build)
+{
+   nir_block *block = nir_cursor_current_block(build->cursor);
+   nir_if *nif = nir_cf_node_as_if(block->cf_node.parent);
+   build->cursor = nir_after_cf_node(>cf_node);
+}
+
+static inline void
+nir_push_loop(nir_builder *build)
+{
+   nir_loop *loop = nir_loop_create(build->shader);
+   nir_builder_cf_insert(build, >cf_node);
+   build->cursor = nir_before_cf_list(>body);
+}
+
+static inline void
+nir_pop_loop(nir_builder *build)
+{
+   nir_block *block = nir_cursor_current_block(build->cursor);
+   nir_loop *loop = nir_cf_node_as_loop(block->cf_node.parent);
+   build->cursor = nir_after_cf_node(>cf_node);
+}
+
 static inline nir_ssa_def *
 nir_ssa_undef(nir_builder *build, unsigned num_components, unsigned bit_size)
 {
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH v2 1/4] driconf: add allow_higher_compat_version option

[Samuel Pitoiset]

On 02/15/2017 05:36 PM, Mark Janes wrote:

With this series, I encounter the following crash using wflinfo:

wflinfo: src/mesa/drivers/dri/common/xmlconfig.c:1028: driQueryOptionb: Assertion 
`cache->info[i].name != ((void *)0)' failed.


Mmh.
Can you provide a full backtrace?



Samuel Pitoiset  writes:


Mesa currently doesn't allow to create 3.1+ compatibility profiles
mainly because various features are unimplemented and bugs can
happen.

However, some buggy apps request a compat profile without using
any old features unimplemented in mesa, and they fail to start.

This option should help some games to run but it's not enough
for all (eg. Dying Ligth).

v2: - s/force_compat_profile/allow_higher_compat_version

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/include/state_tracker/st_api.h  | 1 +
 src/gallium/state_trackers/dri/dri_screen.c | 3 +++
 src/mesa/drivers/dri/common/xmlpool/t_options.h | 5 +
 src/mesa/drivers/dri/i965/brw_context.c | 3 +++
 src/mesa/main/mtypes.h  | 7 +++
 src/mesa/main/version.c | 6 --
 src/mesa/state_tracker/st_extensions.c  | 2 ++
 7 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/src/gallium/include/state_tracker/st_api.h 
b/src/gallium/include/state_tracker/st_api.h
index a2e37d2e48..1b9ef290b1 100644
--- a/src/gallium/include/state_tracker/st_api.h
+++ b/src/gallium/include/state_tracker/st_api.h
@@ -245,6 +245,7 @@ struct st_config_options
unsigned force_glsl_version;
boolean force_s3tc_enable;
boolean allow_glsl_extension_directive_midshader;
+   boolean allow_higher_compat_version;
boolean glsl_zero_init;
 };

diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
b/src/gallium/state_trackers/dri/dri_screen.c
index a950f5241d..1e278c3d1c 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -70,6 +70,7 @@ const __DRIconfigOptionsExtension gallium_config_options = {
  DRI_CONF_DISABLE_SHADER_BIT_ENCODING("false")
  DRI_CONF_FORCE_GLSL_VERSION(0)
  DRI_CONF_ALLOW_GLSL_EXTENSION_DIRECTIVE_MIDSHADER("false")
+ DRI_CONF_ALLOW_HIGHER_COMPAT_VERSION("false")
   DRI_CONF_SECTION_END

   DRI_CONF_SECTION_MISCELLANEOUS
@@ -99,6 +100,8 @@ dri_fill_st_options(struct st_config_options *options,
   driQueryOptionb(optionCache, "force_s3tc_enable");
options->allow_glsl_extension_directive_midshader =
   driQueryOptionb(optionCache, "allow_glsl_extension_directive_midshader");
+   options->allow_higher_compat_version =
+  driQueryOptionb(optionCache, "allow_higher_compat_version");
options->glsl_zero_init = driQueryOptionb(optionCache, "glsl_zero_init");
 }

diff --git a/src/mesa/drivers/dri/common/xmlpool/t_options.h 
b/src/mesa/drivers/dri/common/xmlpool/t_options.h
index a189bbedec..f200093177 100644
--- a/src/mesa/drivers/dri/common/xmlpool/t_options.h
+++ b/src/mesa/drivers/dri/common/xmlpool/t_options.h
@@ -115,6 +115,11 @@ 
DRI_CONF_OPT_BEGIN_B(allow_glsl_extension_directive_midshader, def) \
 DRI_CONF_DESC(en,gettext("Allow GLSL #extension directives in the middle of 
shaders")) \
 DRI_CONF_OPT_END

+#define DRI_CONF_ALLOW_HIGHER_COMPAT_VERSION(def) \
+DRI_CONF_OPT_BEGIN_B(allow_higher_compat_version, def) \
+DRI_CONF_DESC(en,gettext("Allow a higher compat profile (version 3.1+) for 
apps that request it")) \
+DRI_CONF_OPT_END
+


 /**
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 7240b1f445..c56a14e3d6 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -916,6 +916,9 @@ brw_process_driconf_options(struct brw_context *brw)
ctx->Const.AllowGLSLExtensionDirectiveMidShader =
   driQueryOptionb(options, "allow_glsl_extension_directive_midshader");

+   ctx->Const.AllowHigherCompatVersion =
+  driQueryOptionb(options, "allow_higher_compat_version");
+
ctx->Const.GLSLZeroInit = driQueryOptionb(options, "glsl_zero_init");

brw->dual_color_blend_by_location =
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index a845a394c8..08bd929255 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3501,6 +3501,13 @@ struct gl_constants
GLboolean AllowGLSLExtensionDirectiveMidShader;

/**
+* Allow creating a higher compat profile (version 3.1+) for apps that
+* request it. Be careful when adding that driconf option because some
+* features are unimplemented and might not work correctly.
+*/
+   GLboolean AllowHigherCompatVersion;
+
+   /**
 * Force uninitialized variables to default to zero.
 */
GLboolean GLSLZeroInit;
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 85ec9de612..3d54d21a04 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -566,8 +566,10 @@ 

Re: [Mesa-dev] [PATCH v2 6/6] anv: do not open random render node(s)

[Ilia Mirkin]

On Wed, Feb 15, 2017 at 10:51 AM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> drmGetDevices2() provides us with enough flexibility to build heuristics
> upon. Opening a random node on the other hand will wake up the device,
> regardless if it's the one we're interested or not.
>
> v2:
>  - Explicitly require/check for libdrm.
>  - Zero physicalDeviceCount when drmGetDevices2() returns < 1 devices.
>
> Cc: Jason Ekstrand 
> Signed-off-by: Emil Velikov 
> Reviewed-by: Eric Engestrom  (v1)
> ---
>  configure.ac  |  1 +
>  src/intel/vulkan/Makefile.am  |  3 ++-
>  src/intel/vulkan/anv_device.c | 53 
> +++
>  3 files changed, 41 insertions(+), 16 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 4b7f2298f7..23ce256da6 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1780,6 +1780,7 @@ if test -n "$with_vulkan_drivers"; then
>  if test "x$HAVE_I965_DRI" != xyes; then
>  AC_MSG_ERROR([Intel Vulkan driver requires the i965 dri 
> driver])
>  fi
> +require_libdrm "ANV"
>  HAVE_INTEL_VULKAN=yes;
>
>  ;;
> diff --git a/src/intel/vulkan/Makefile.am b/src/intel/vulkan/Makefile.am
> index 95f276ed7e..bf2590e643 100644
> --- a/src/intel/vulkan/Makefile.am
> +++ b/src/intel/vulkan/Makefile.am
> @@ -68,7 +68,7 @@ AM_CPPFLAGS += \
>  endif
>
>  AM_CPPFLAGS += \
> -   $(INTEL_CFLAGS) \
> +   $(LIBDRM_CFLAGS) \
> $(VALGRIND_CFLAGS) \
> $(DEFINES)
>
> @@ -133,6 +133,7 @@ VULKAN_LIB_DEPS += \
> $(top_builddir)/src/intel/isl/libisl.la \
> $(top_builddir)/src/intel/blorp/libblorp.la \
> $(PER_GEN_LIBS) \
> +   $(LIBDRM_LIBS) \
> $(PTHREAD_LIBS) \
> $(DLOPEN_LIBS) \
> -lm
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index d1a6cc8e9c..808f6f18cc 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "anv_private.h"
>  #include "util/strtod.h"
> @@ -388,6 +389,40 @@ void anv_DestroyInstance(
> vk_free(>alloc, instance);
>  }
>
> +static VkResult
> +anv_enumerate_devices(struct anv_instance *instance)
> +{
> +   /* TODO: Check for more devices ? */
> +   drmDevicePtr devices[8];
> +   VkResult result = VK_SUCCESS;
> +   int max_devices;
> +
> +   instance->physicalDeviceCount = 0;
> +
> +   max_devices = drmGetDevices2(0, devices, sizeof(devices));
> +   if (max_devices < 1)
> +  return VK_ERROR_INCOMPATIBLE_DRIVER;

so result = VK_SUCCESS

> +
> +   for (unsigned i = 0; i < (unsigned)max_devices; i++) {
> +  if (devices[i]->available_nodes & 1 << DRM_NODE_RENDER &&
> +  devices[i]->bustype == DRM_BUS_PCI &&
> +  devices[i]->deviceinfo.pci->vendor_id == 0x8086) {

let's say this never triggers

> +
> + result = anv_physical_device_init(>physicalDevice,
> +instance,
> +devices[i]->nodes[DRM_NODE_RENDER]);
> + if (result != VK_ERROR_INCOMPATIBLE_DRIVER)
> +break;
> +  }
> +   }

result is still VK_SUCCESS. Seems like it should default to
VK_ERROR_INCOMPATIBLE_DRIVER instead?

> +
> +   if (result == VK_SUCCESS)
> +  instance->physicalDeviceCount = 1;
> +
> +   return result;
> +}
> +
> +
>  VkResult anv_EnumeratePhysicalDevices(
>  VkInstance  _instance,
>  uint32_t*   pPhysicalDeviceCount,
> @@ -397,22 +432,10 @@ VkResult anv_EnumeratePhysicalDevices(
> VkResult result;
>
> if (instance->physicalDeviceCount < 0) {
> -  char path[20];
> -  for (unsigned i = 0; i < 8; i++) {
> - snprintf(path, sizeof(path), "/dev/dri/renderD%d", 128 + i);
> - result = anv_physical_device_init(>physicalDevice,
> -   instance, path);
> - if (result != VK_ERROR_INCOMPATIBLE_DRIVER)
> -break;
> -  }
> -
> -  if (result == VK_ERROR_INCOMPATIBLE_DRIVER) {
> - instance->physicalDeviceCount = 0;
> -  } else if (result == VK_SUCCESS) {
> - instance->physicalDeviceCount = 1;
> -  } else {
> +  result = anv_enumerate_devices(instance);
> +  if (result != VK_SUCCESS &&
> +  result != VK_ERROR_INCOMPATIBLE_DRIVER)
>   return result;
> -  }
> }
>
> /* pPhysicalDeviceCount is an out parameter if pPhysicalDevices is NULL;
> --
> 2.11.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

Re: [Mesa-dev] [PATCH] util/disk_cache: do not allow space in MESA_GLSL_CACHE_MAX_SIZE

[Emil Velikov]

On 9 February 2017 at 13:35, Emil Velikov  wrote:
> From: Emil Velikov 
>
> No other env var used in mesa allows for space in the variable contents.
>
> Signed-off-by: Emil Velikov 
> ---
> Worth documenting and/or even renaming them ?
Tim, with the documentation going in, we can land this ?

We might even go a step further droping the lowercase aliases - k, m, g  :-)
But that for another time.

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

[Mesa-dev] [PATCH] anv: remove spec quote from anv_EnumeratePhysicalDevices

[Emil Velikov]

From: Emil Velikov 

The VK_SUCCESS/VK_INCOMPLETE pattern is quite common.

Signed-off-by: Emil Velikov 
---
Based on top of the drmGetDevice2 series sent earlier.

 src/intel/vulkan/anv_device.c | 17 -
 1 file changed, 17 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index d804963cce..137f7fdd64 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -437,23 +437,6 @@ VkResult anv_EnumeratePhysicalDevices(
  return result;
}
 
-   /* pPhysicalDeviceCount is an out parameter if pPhysicalDevices is NULL;
-* otherwise it's an inout parameter.
-*
-* The Vulkan spec (git aaed022) says:
-*
-*pPhysicalDeviceCount is a pointer to an unsigned integer variable
-*that is initialized with the number of devices the application is
-*prepared to receive handles to. pname:pPhysicalDevices is pointer to
-*an array of at least this many VkPhysicalDevice handles [...].
-*
-*Upon success, if pPhysicalDevices is NULL, vkEnumeratePhysicalDevices
-*overwrites the contents of the variable pointed to by
-*pPhysicalDeviceCount with the number of physical devices in in the
-*instance; otherwise, vkEnumeratePhysicalDevices overwrites
-*pPhysicalDeviceCount with the number of physical handles written to
-*pPhysicalDevices.
-*/
if (!pPhysicalDevices) {
   *pPhysicalDeviceCount = instance->physicalDeviceCount;
} else if (*pPhysicalDeviceCount >= 1) {
-- 
2.11.0

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

[Mesa-dev] [PATCH v2 3/6] winsys/amdgpu: use drmGetDevice2 API

[Emil Velikov]

From: Emil Velikov 

Analogous to previous commit

Signed-off-by: Emil Velikov 
Reviewed-by: Michel Dänzer 
Reviewed-by: Marek Olšák 
Reviewed-by: Eric Engestrom 
---
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
index db0087c094..ecbef6bca8 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
@@ -108,9 +108,9 @@ static bool do_winsys_init(struct amdgpu_winsys *ws, int fd)
drmDevicePtr devinfo;
 
/* Get PCI info. */
-   r = drmGetDevice(fd, );
+   r = drmGetDevice2(fd, 0, );
if (r) {
-  fprintf(stderr, "amdgpu: drmGetDevice failed.\n");
+  fprintf(stderr, "amdgpu: drmGetDevice2 failed.\n");
   goto fail;
}
ws->info.pci_domain = devinfo->businfo.pci->domain;
-- 
2.11.0

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

[Mesa-dev] [PATCH v2 2/6] loader: use drmGetDevice[s]2 API

[Emil Velikov]

From: Emil Velikov 

By this allows us to fetch the device list/info w/o the revision field.
At the moment retrieving the latter wakes up the device.

Note: kernel patch to resolve that should be in 4.10.

Signed-off-by: Emil Velikov 
Reviewed-by: Michel Dänzer 
Reviewed-by: Eric Engestrom 
---
Due to a libtool bug^Wfeature one can get link time errors if libdrm is
in a non-default prefix. To workaround set LD_LIBRARY_PATH before your
mesa `make install'.

^^ was seemingly hit on the Intel CI. Will need to check with Mark as
he gets up.
---
 src/loader/loader.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 3b28a0e7db..281e0898ca 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -145,7 +145,7 @@ static char *drm_get_id_path_tag_for_fd(int fd)
drmDevicePtr device;
char *tag;
 
-   if (drmGetDevice(fd, ) != 0)
+   if (drmGetDevice2(fd, 0, ) != 0)
return NULL;
 
tag = drm_construct_id_path_tag(device);
@@ -179,7 +179,7 @@ int loader_get_user_preferred_fd(int default_fd, int 
*different_device)
if (default_tag == NULL)
   goto err;
 
-   num_devices = drmGetDevices(devices, MAX_DRM_DEVICES);
+   num_devices = drmGetDevices2(0, devices, MAX_DRM_DEVICES);
if (num_devices < 0)
   goto err;
 
@@ -275,7 +275,7 @@ drm_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
drmDevicePtr device;
int ret;
 
-   if (drmGetDevice(fd, ) == 0) {
+   if (drmGetDevice2(fd, 0, ) == 0) {
   if (device->bustype == DRM_BUS_PCI) {
  *vendor_id = device->deviceinfo.pci->vendor_id;
  *chip_id = device->deviceinfo.pci->device_id;
-- 
2.11.0

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

[Mesa-dev] [PATCH v2 5/6] radv: do not open random render node(s)

[Emil Velikov]

From: Emil Velikov 

drmGetDevices2() provides us with enough flexibility to build heuristics
upon. Opening a random node on the other hand will wake up the device,
regardless if it's the one we're interested or not.

v2: Rebase.

Cc: Michel Dänzer 
Cc: Dave Airlie 
Signed-off-by: Emil Velikov 
Reviewed-by: Bas Nieuwenhuizen  (v1)
Reviewed-by: Eric Engestrom  (v1)
---
 src/amd/vulkan/radv_device.c | 48 +---
 1 file changed, 36 insertions(+), 12 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 1132eeb52d..a0080933ad 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -384,28 +384,52 @@ void radv_DestroyInstance(
vk_free(>alloc, instance);
 }
 
-VkResult radv_EnumeratePhysicalDevices(
-   VkInstance  _instance,
-   uint32_t*   pPhysicalDeviceCount,
-   VkPhysicalDevice*   pPhysicalDevices)
+static VkResult
+radv_enumerate_devices(struct radv_instance *instance)
 {
-   RADV_FROM_HANDLE(radv_instance, instance, _instance);
-   VkResult result;
+   /* TODO: Check for more devices ? */
+   drmDevicePtr devices[8];
+   VkResult result = VK_SUCCESS;
+   int max_devices;
+
+   instance->physicalDeviceCount = 0;
+
+   max_devices = drmGetDevices2(0, devices, sizeof(devices));
+   if (max_devices < 1)
+   return VK_ERROR_INCOMPATIBLE_DRIVER;
+
+   for (unsigned i = 0; i < (unsigned)max_devices; i++) {
+   if (devices[i]->available_nodes & 1 << DRM_NODE_RENDER &&
+   devices[i]->bustype == DRM_BUS_PCI &&
+   devices[i]->deviceinfo.pci->vendor_id == 0x1002) {
 
-   if (instance->physicalDeviceCount < 0) {
-   char path[20];
-   instance->physicalDeviceCount = 0;
-   for (unsigned i = 0; i < RADV_MAX_DRM_DEVICES; i++) {
-   snprintf(path, sizeof(path), "/dev/dri/renderD%d", 128 
+ i);
result = 
radv_physical_device_init(instance->physicalDevices +
   
instance->physicalDeviceCount,
-  instance, path);
+  instance,
+  
devices[i]->nodes[DRM_NODE_RENDER]);
if (result == VK_SUCCESS)
++instance->physicalDeviceCount;
else if (result != VK_ERROR_INCOMPATIBLE_DRIVER)
return result;
}
}
+   return result;
+}
+
+VkResult radv_EnumeratePhysicalDevices(
+   VkInstance  _instance,
+   uint32_t*   pPhysicalDeviceCount,
+   VkPhysicalDevice*   pPhysicalDevices)
+{
+   RADV_FROM_HANDLE(radv_instance, instance, _instance);
+   VkResult result;
+
+   if (instance->physicalDeviceCount < 0) {
+   result = radv_enumerate_devices(instance);
+   if (result != VK_SUCCESS &&
+   result != VK_ERROR_INCOMPATIBLE_DRIVER)
+   return result;
+   }
 
if (!pPhysicalDevices) {
*pPhysicalDeviceCount = instance->physicalDeviceCount;
-- 
2.11.0

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

[Mesa-dev] [PATCH v2 0/6] Use drmGetDevice[s]2 API

[Emil Velikov]

Hi all,

This is mostly a resent from v1, with a couple of fixes on the ANV 
patch and commit message polish as per Eric/Michel's input.

In case you've forgotten:
Using the non "2" API fetches the PCI revision field, which wakes up 
the device [even if we don't end up using it], which can lead to 
noticeable delays in startup times.

Emil

Emil Velikov (6):
  autoconf/scons: bump libdrm to 2.4.75
  loader: use drmGetDevice[s]2 API
  winsys/amdgpu: use drmGetDevice2 API
  radv/winsys: use drmGetDevice2 API
  radv: do not open random render node(s)
  anv: do not open random render node(s)

 configure.ac  |  3 +-
 scons/gallium.py  |  2 +-
 src/amd/vulkan/radv_device.c  | 48 +++-
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c |  4 +-
 src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c |  4 +-
 src/intel/vulkan/Makefile.am  |  3 +-
 src/intel/vulkan/anv_device.c | 53 ---
 src/loader/loader.c   |  6 +--
 8 files changed, 86 insertions(+), 37 deletions(-)

-- 
2.11.0

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

[Mesa-dev] [PATCH v2 4/6] radv/winsys: use drmGetDevice2 API

[Emil Velikov]

From: Emil Velikov 

Analogous to previous commit

Cc: Dave Airlie 
Signed-off-by: Emil Velikov 
Reviewed-by: Michel Dänzer 
Reviewed-by: Bas Nieuwenhuizen 
Reviewed-by: Eric Engestrom 
---
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c 
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c
index 35b6bc57a4..b66f6a1222 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c
@@ -123,9 +123,9 @@ do_winsys_init(struct radv_amdgpu_winsys *ws, int fd)
int r;
int i, j;
/* Get PCI info. */
-   r = drmGetDevice(fd, );
+   r = drmGetDevice2(fd, 0, );
if (r) {
-   fprintf(stderr, "amdgpu: drmGetDevice failed.\n");
+   fprintf(stderr, "amdgpu: drmGetDevice2 failed.\n");
goto fail;
}
ws->info.pci_domain = devinfo->businfo.pci->domain;
-- 
2.11.0

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

[Mesa-dev] [PATCH v2 1/6] autoconf/scons: bump libdrm to 2.4.75

[Emil Velikov]

From: Emil Velikov 

We'll be using the drmGetDevice[s]2 API in src/loader with next patch.

v2: Rebase.

Signed-off-by: Emil Velikov 
Reviewed-by: Michel Dänzer  (v1)
Reviewed-by: Eric Engestrom  (v1)
---
 configure.ac | 2 +-
 scons/gallium.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index f001743ea2..4b7f2298f7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -72,7 +72,7 @@ AC_SUBST([OPENCL_VERSION])
 # codifies which drivers need which version of libdrm. Any libdrm
 # version dependencies in non-driver-specific code should be reflected
 # in the first entry.
-LIBDRM_REQUIRED=2.4.66
+LIBDRM_REQUIRED=2.4.75
 LIBDRM_RADEON_REQUIRED=2.4.56
 LIBDRM_AMDGPU_REQUIRED=2.4.63
 LIBDRM_INTEL_REQUIRED=2.4.75
diff --git a/scons/gallium.py b/scons/gallium.py
index 665d66afc7..a411277324 100755
--- a/scons/gallium.py
+++ b/scons/gallium.py
@@ -648,7 +648,7 @@ def generate(env):
 env.PkgCheckModules('X11', ['x11', 'xext', 'xdamage >= 1.1', 'xfixes', 
'glproto >= 1.4.13', 'dri2proto >= 2.8'])
 env.PkgCheckModules('XCB', ['x11-xcb', 'xcb-glx >= 1.8.1', 'xcb-dri2 >= 
1.8'])
 env.PkgCheckModules('XF86VIDMODE', ['xxf86vm'])
-env.PkgCheckModules('DRM', ['libdrm >= 2.4.66'])
+env.PkgCheckModules('DRM', ['libdrm >= 2.4.75'])
 
 if env['x11']:
 env.Append(CPPPATH = env['X11_CPPPATH'])
-- 
2.11.0

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

[Mesa-dev] [PATCH v2 6/6] anv: do not open random render node(s)

[Emil Velikov]

From: Emil Velikov 

drmGetDevices2() provides us with enough flexibility to build heuristics
upon. Opening a random node on the other hand will wake up the device,
regardless if it's the one we're interested or not.

v2:
 - Explicitly require/check for libdrm.
 - Zero physicalDeviceCount when drmGetDevices2() returns < 1 devices.

Cc: Jason Ekstrand 
Signed-off-by: Emil Velikov 
Reviewed-by: Eric Engestrom  (v1)
---
 configure.ac  |  1 +
 src/intel/vulkan/Makefile.am  |  3 ++-
 src/intel/vulkan/anv_device.c | 53 +++
 3 files changed, 41 insertions(+), 16 deletions(-)

diff --git a/configure.ac b/configure.ac
index 4b7f2298f7..23ce256da6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1780,6 +1780,7 @@ if test -n "$with_vulkan_drivers"; then
 if test "x$HAVE_I965_DRI" != xyes; then
 AC_MSG_ERROR([Intel Vulkan driver requires the i965 dri 
driver])
 fi
+require_libdrm "ANV"
 HAVE_INTEL_VULKAN=yes;
 
 ;;
diff --git a/src/intel/vulkan/Makefile.am b/src/intel/vulkan/Makefile.am
index 95f276ed7e..bf2590e643 100644
--- a/src/intel/vulkan/Makefile.am
+++ b/src/intel/vulkan/Makefile.am
@@ -68,7 +68,7 @@ AM_CPPFLAGS += \
 endif
 
 AM_CPPFLAGS += \
-   $(INTEL_CFLAGS) \
+   $(LIBDRM_CFLAGS) \
$(VALGRIND_CFLAGS) \
$(DEFINES)
 
@@ -133,6 +133,7 @@ VULKAN_LIB_DEPS += \
$(top_builddir)/src/intel/isl/libisl.la \
$(top_builddir)/src/intel/blorp/libblorp.la \
$(PER_GEN_LIBS) \
+   $(LIBDRM_LIBS) \
$(PTHREAD_LIBS) \
$(DLOPEN_LIBS) \
-lm
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index d1a6cc8e9c..808f6f18cc 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "anv_private.h"
 #include "util/strtod.h"
@@ -388,6 +389,40 @@ void anv_DestroyInstance(
vk_free(>alloc, instance);
 }
 
+static VkResult
+anv_enumerate_devices(struct anv_instance *instance)
+{
+   /* TODO: Check for more devices ? */
+   drmDevicePtr devices[8];
+   VkResult result = VK_SUCCESS;
+   int max_devices;
+
+   instance->physicalDeviceCount = 0;
+
+   max_devices = drmGetDevices2(0, devices, sizeof(devices));
+   if (max_devices < 1)
+  return VK_ERROR_INCOMPATIBLE_DRIVER;
+
+   for (unsigned i = 0; i < (unsigned)max_devices; i++) {
+  if (devices[i]->available_nodes & 1 << DRM_NODE_RENDER &&
+  devices[i]->bustype == DRM_BUS_PCI &&
+  devices[i]->deviceinfo.pci->vendor_id == 0x8086) {
+
+ result = anv_physical_device_init(>physicalDevice,
+instance,
+devices[i]->nodes[DRM_NODE_RENDER]);
+ if (result != VK_ERROR_INCOMPATIBLE_DRIVER)
+break;
+  }
+   }
+
+   if (result == VK_SUCCESS)
+  instance->physicalDeviceCount = 1;
+
+   return result;
+}
+
+
 VkResult anv_EnumeratePhysicalDevices(
 VkInstance  _instance,
 uint32_t*   pPhysicalDeviceCount,
@@ -397,22 +432,10 @@ VkResult anv_EnumeratePhysicalDevices(
VkResult result;
 
if (instance->physicalDeviceCount < 0) {
-  char path[20];
-  for (unsigned i = 0; i < 8; i++) {
- snprintf(path, sizeof(path), "/dev/dri/renderD%d", 128 + i);
- result = anv_physical_device_init(>physicalDevice,
-   instance, path);
- if (result != VK_ERROR_INCOMPATIBLE_DRIVER)
-break;
-  }
-
-  if (result == VK_ERROR_INCOMPATIBLE_DRIVER) {
- instance->physicalDeviceCount = 0;
-  } else if (result == VK_SUCCESS) {
- instance->physicalDeviceCount = 1;
-  } else {
+  result = anv_enumerate_devices(instance);
+  if (result != VK_SUCCESS &&
+  result != VK_ERROR_INCOMPATIBLE_DRIVER)
  return result;
-  }
}
 
/* pPhysicalDeviceCount is an out parameter if pPhysicalDevices is NULL;
-- 
2.11.0

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

[Mesa-dev] [PATCH] egl: _eglFilterArray's filter is always non-null

[Emil Velikov]

From: Emil Velikov 

Drop the extra handling and assert() if things change in the future.

Signed-off-by: Emil Velikov 
---
 src/egl/main/eglarray.c | 27 +--
 1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/src/egl/main/eglarray.c b/src/egl/main/eglarray.c
index d2f39af49a..ba6cb3e6a4 100644
--- a/src/egl/main/eglarray.c
+++ b/src/egl/main/eglarray.c
@@ -26,6 +26,7 @@
  **/
 
 
+#include 
 #include 
 #include 
 
@@ -157,25 +158,15 @@ _eglFilterArray(_EGLArray *array, void **data, EGLint 
size,
if (!array)
   return 0;
 
-   if (filter) {
-  for (i = 0; i < array->Size; i++) {
- if (filter(array->Elements[i], filter_data)) {
-if (data && count < size)
-   data[count] = array->Elements[i];
-count++;
- }
- if (data && count >= size)
-break;
-  }
-   }
-   else {
-  if (data) {
- count = (size < array->Size) ? size : array->Size;
- memcpy(data, array->Elements, count * sizeof(array->Elements[0]));
-  }
-  else {
- count = array->Size;
+   assert(filter);
+   for (i = 0; i < array->Size; i++) {
+  if (filter(array->Elements[i], filter_data)) {
+ if (data && count < size)
+data[count] = array->Elements[i];
+ count++;
   }
+  if (data && count >= size)
+ break;
}
 
return count;
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH] softpipe: implement clear_texture

[Lars Hamre]

Happy to rework the implementation.
Would creating a util_clear_texture function which pulls out the
necessary components from util_clear_render_target be in alignment
with what you're imagining?
The idea would be to have util_clear_texture take a pipe_resource
instead of a pipe_surface.
Something similar would also be done for clear_depth_stencil.

Lars

On Mon, Feb 13, 2017 at 7:41 PM, Roland Scheidegger  wrote:
> Am 13.02.2017 um 16:20 schrieb Lars Hamre:
>> Implements the ARB_clear_texture extension for softpipe.
>> Passes all corresponding piglit tests.
>>
>> Signed-off-by: Lars Hamre 
>>
>> ---
>>
>> NOTE: someone with access will need to commit this post
>>   review process
>>
>>  src/gallium/drivers/softpipe/sp_screen.c  |  3 +-
>>  src/gallium/drivers/softpipe/sp_texture.c | 60 
>> +++
>>  2 files changed, 62 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/drivers/softpipe/sp_screen.c 
>> b/src/gallium/drivers/softpipe/sp_screen.c
>> index 02eff91..aa061d7 100644
>> --- a/src/gallium/drivers/softpipe/sp_screen.c
>> +++ b/src/gallium/drivers/softpipe/sp_screen.c
>> @@ -260,6 +260,8 @@ softpipe_get_param(struct pipe_screen *screen, enum 
>> pipe_cap param)
>> case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
>> case PIPE_CAP_TGSI_ARRAY_COMPONENTS:
>>return 1;
>> +   case PIPE_CAP_CLEAR_TEXTURE:
>> +  return 1;
>> case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
>> case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
>> case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
>> @@ -268,7 +270,6 @@ softpipe_get_param(struct pipe_screen *screen, enum 
>> pipe_cap param)
>> case PIPE_CAP_TGSI_TXQS:
>> case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
>> case PIPE_CAP_SHAREABLE_SHADERS:
>> -   case PIPE_CAP_CLEAR_TEXTURE:
>> case PIPE_CAP_DRAW_PARAMETERS:
>> case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
>> case PIPE_CAP_MULTI_DRAW_INDIRECT:
>> diff --git a/src/gallium/drivers/softpipe/sp_texture.c 
>> b/src/gallium/drivers/softpipe/sp_texture.c
>> index 8dca158..3794cf3 100644
>> --- a/src/gallium/drivers/softpipe/sp_texture.c
>> +++ b/src/gallium/drivers/softpipe/sp_texture.c
>> @@ -37,6 +37,7 @@
>>  #include "util/u_math.h"
>>  #include "util/u_memory.h"
>>  #include "util/u_transfer.h"
>> +#include "util/u_surface.h"
>>
>>  #include "sp_context.h"
>>  #include "sp_flush.h"
>> @@ -341,6 +342,64 @@ softpipe_surface_destroy(struct pipe_context *pipe,
>>  }
>>
>>
>> +static void
>> +softpipe_clear_texture(struct pipe_context *pipe,
>> +   struct pipe_resource *tex,
>> +   unsigned level,
>> +   const struct pipe_box *box,
>> +   const void *data)
>> +{
>> +   struct pipe_surface tmpl = {{0}};
>> +   struct pipe_surface *sf;
>> +   const struct util_format_description *desc =
>> +  util_format_description(tex->format);
>> +
>> +   if (level > tex->last_level)
>> +  return;
>> +
>> +   tmpl.format = tex->format;
>> +   tmpl.u.tex.first_layer = box->z;
>> +   tmpl.u.tex.last_layer = box->z + box->depth - 1;
>> +   tmpl.u.tex.level = level;
>> +   sf = pipe->create_surface(pipe, tex, );
> I am not quite convinced of that solution. The problem is you're not
> supposed to call create_surface() on resources which didn't have the
> appropriate bind flag (although unlike llvmpipe softpipe won't warn
> about this). And in fact, there's formats where clear_texture is
> supposed to work which are definitely not renderable, so it really is an
> error to do this (even though softpipe won't actually care).
>
> But OTOH I suppose this method works...
>
> Roland
>
>
>> +   if (!sf)
>> +  return;
>> +
>> +   if (util_format_is_depth_or_stencil(tex->format)) {
>> +  unsigned clear = 0;
>> +  float depth = 0.0f;
>> +  uint8_t stencil = 0;
>> +
>> +  if (util_format_has_depth(desc)) {
>> + clear |= PIPE_CLEAR_DEPTH;
>> + desc->unpack_z_float(, 0, data, 0, 1, 1);
>> +  }
>> +
>> +  if (util_format_has_stencil(desc)) {
>> + clear |= PIPE_CLEAR_STENCIL;
>> + desc->unpack_s_8uint(, 0, data, 0, 1, 1);
>> +  }
>> +
>> +  pipe->clear_depth_stencil(pipe, sf, clear, depth, stencil,
>> +box->x, box->y,
>> +box->width, box->height, false);
>> +   } else {
>> +  union pipe_color_union color;
>> +
>> +  if (util_format_is_pure_uint(tex->format))
>> + desc->unpack_rgba_uint(color.ui, 0, data, 0, 1, 1);
>> +  else if (util_format_is_pure_sint(tex->format))
>> + desc->unpack_rgba_sint(color.i, 0, data, 0, 1, 1);
>> +  else
>> + desc->unpack_rgba_float(color.f, 0, data, 0, 1, 1);
>> +
>> +  util_clear_render_target(pipe, sf, , box->x, box->y,
>> +   box->width, box->height);
>> +   }
>> +   pipe_surface_reference(, NULL);
>> +}
>> +
>> +
>>  /**
>>   * Geta 

[Mesa-dev] [PATCHv2 2/6] docs/releasing: tweak the glxinfo/glxgear/etc. command lines

[Emil Velikov]

From: Emil Velikov 

Print only the information needed. Namely:
*info: the DRI module picked and the vendor/renderer strings
*gears: everything but the "...configuration file..." line(s)

v2: (Eric) Use "2>&1 |" over "|&", properly escape &.

Signed-off-by: Emil Velikov 
---
 docs/releasing.html | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/docs/releasing.html b/docs/releasing.html
index ec1baee094..1bf88474f3 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -366,24 +366,28 @@ Here is one solution that I've been using.
--enable-egl \
--with-egl-platforms=x11,drm,wayland
make -j2  DESTDIR=`pwd`/test make -j6 install
+   __glxinfo_cmd='glxinfo 2>1 | egrep -o "Mesa.*|Gallium.*|.*dri\.so"'
+   __glxgears_cmd='glxgears 2>1 | grep -v "configuration file"'
+   __es2info_cmd='es2_info 2>1 | egrep 
"GL_VERSION|GL_RENDERER|.*dri\.so"'
+   __es2gears_cmd='es2gears_x11 2>1 | grep -v "configuration file"'
export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/
export LIBGL_DRIVERS_PATH=`pwd`/test/usr/local/lib/dri/
export LIBGL_DEBUG=verbose
-   glxinfo | egrep -o "Mesa.*"
-   glxgears
-   es2_info | egrep "GL_VERSION|GL_RENDERER"
-   es2gears_x11
+   eval $__glxinfo_cmd
+   eval $__glxgears_cmd
+   eval $__es2info_cmd
+   eval $__es2gears_cmd
export LIBGL_ALWAYS_SOFTWARE=1
-   glxinfo | egrep -o "Mesa.*|Gallium.*"
-   glxgears
-   es2_info | egrep "GL_VERSION|GL_RENDERER"
-   es2gears_x11
+   eval $__glxinfo_cmd
+   eval $__glxgears_cmd
+   eval $__es2info_cmd
+   eval $__es2gears_cmd
export LIBGL_ALWAYS_SOFTWARE=1
export GALLIUM_DRIVER=softpipe
-   glxinfo | egrep -o "Mesa.*|Gallium.*"
-   glxgears
-   es2_info | egrep "GL_VERSION|GL_RENDERER"
-   es2gears_x11
+   eval $__glxinfo_cmd
+   eval $__glxgears_cmd
+   eval $__es2info_cmd
+   eval $__es2gears_cmd
# Smoke test DOTA2
unset LD_LIBRARY_PATH
unset LIBGL_DRIVERS_PATH
-- 
2.11.0

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] i965/fs: fix indirect load DF uniforms on BSW/BXT

[Samuel Iglesias Gonsálvez]

On Tue, 2017-02-14 at 11:11 -0800, Francisco Jerez wrote:
> Samuel Iglesias Gonsálvez  writes:
> 
> > Previously we were emitting two MOV_INDIRECT instructions by
> > calculating
> > source's indirect offsets for each 32-bit half of a DF source.
> > However,
> > this is not needed as we can just emit two 32-bit MOV INDIRECT
> > without
> > doing that calculation.
> > 
> 
> Maybe mention here the main motivation for fixing this and nominating
> it
> for stable: The lowered BSW/BXT indirect move instructions had
> incorrect
> source types, which luckily wasn't causing incorrect assembly to be
> generated due to the bug fixed in the next patch, but would have
> confused the remaining back-end IR infrastructure due to the mismatch
> between the IR source types and the emitted machine code.
> 

OK, thanks.

> > Signed-off-by: Samuel Iglesias Gonsálvez 
> > Cc: "17.0" 
> > ---
> >  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 23 ++
> > -
> >  1 file changed, 10 insertions(+), 13 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > index 991c20fad62..8975940e10b 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > @@ -3878,31 +3878,28 @@ fs_visitor::nir_emit_intrinsic(const
> > fs_builder , nir_intrinsic_instr *instr
> >   unsigned read_size = instr->const_index[1] -
> >  (instr->num_components - 1) * type_sz(dest.type);
> >  
> > - fs_reg indirect_chv_high_32bit;
> > - bool is_chv_bxt_64bit =
> > -(devinfo->is_cherryview || devinfo->is_broxton) &&
> > -type_sz(dest.type) == 8;
> > - if (is_chv_bxt_64bit) {
> > -indirect_chv_high_32bit = vgrf(glsl_type::uint_type);
> > -/* Calculate indirect address to read high 32 bits */
> > -bld.ADD(indirect_chv_high_32bit, indirect,
> > brw_imm_ud(4));
> > - }
> > + bool supports_64bit_indirects =
> > +!devinfo->is_cherryview && !devinfo->is_broxton;
> >  
> >   for (unsigned j = 0; j < instr->num_components; j++) {
> > -if (!is_chv_bxt_64bit) {
> > +if (type_sz(dest.type) != 8 ||
> > supports_64bit_indirects) {
> > bld.emit(SHADER_OPCODE_MOV_INDIRECT,
> >  offset(dest, bld, j), offset(src, bld, j),
> >  indirect, brw_imm_ud(read_size));
> >  } else {
> > +   /* We are going to read 64-bit data in two 32-bit
> > MOV INDIRECTS,
> > +* each one reading half of the data.
> > +*/
> > +   read_size /= 2;
> 
> I don't think this is right, data for both halves is interleaved so
> the
> read size will be roughly the same as for the 64 bit indirect move.
> 

OK

> > bld.emit(SHADER_OPCODE_MOV_INDIRECT,
> >  subscript(offset(dest, bld, j),
> > BRW_REGISTER_TYPE_UD, 0),
> > -offset(src, bld, j),
> > +subscript(offset(src, bld, j),
> > BRW_REGISTER_TYPE_UD, 0),
> >  indirect, brw_imm_ud(read_size));
> >  
> > bld.emit(SHADER_OPCODE_MOV_INDIRECT,
> >  subscript(offset(dest, bld, j),
> > BRW_REGISTER_TYPE_UD, 1),
> > -offset(src, bld, j),
> > -indirect_chv_high_32bit,
> > brw_imm_ud(read_size));
> > +subscript(offset(src, bld, j),
> > BRW_REGISTER_TYPE_UD, 1),
> > +indirect, brw_imm_ud(read_size));
> 
> Given that this makes both emit statements nearly identical except
> for
> the 0/1 indices passed to subscript(), wouldn't it make sense to
> remove
> one of them and wrap it in a loop?
> 

Right, I am going to refactor it.

Sam

> >  }
> >   }
> >    }
> > -- 
> > 2.11.0
> > 
> > ___
> > mesa-stable mailing list
> > mesa-sta...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-stable

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] spirv: handle SpvOpUConvert in proper place.

[Jason Ekstrand]

Oops... R-b

On Feb 15, 2017 12:27 AM, "Dave Airlie"  wrote:

> From: Dave Airlie 
>
> This was falling into the quantizetof16 path.
>
> Signed-off-by: Dave Airlie 
> ---
>  src/compiler/spirv/vtn_alu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
> index 55f7f2e..0738fe0 100644
> --- a/src/compiler/spirv/vtn_alu.c
> +++ b/src/compiler/spirv/vtn_alu.c
> @@ -286,8 +286,8 @@ vtn_nir_alu_op_for_spirv_opcode(SpvOp opcode, bool
> *swap,
>
> /* Conversions: */
> case SpvOpBitcast:   return nir_op_imov;
> -   case SpvOpUConvert:
> case SpvOpQuantizeToF16: return nir_op_fquantize2f16;
> +   case SpvOpUConvert:
> case SpvOpConvertFToU:
> case SpvOpConvertFToS:
> case SpvOpConvertSToF:
> --
> 2.9.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] docs/submittingpatches.html: remove version tag for nominations

[Emil Velikov]

On 15 February 2017 at 12:33, Nicolai Hähnle  wrote:
> On 13.02.2017 20:23, Emil Velikov wrote:
>>
>> From: Emil Velikov 
>>
>> The version tag used to nominate has bitten even experienced mesa
>> developers. Not to mention that it deviates from the one used in the
>> kernel leading to further confusion.
>>
>> Simplify things and omit it all together.
>>
>> Signed-off-by: Emil Velcro 
>
>
> LOL. How did that happen? :)
>
Forgot to add my family name to the dictionary. So now I'm a Velcro :-P

> I do like the change, thanks. In the rare case where a patch might apply to
> an older branch textually but cause problems, we can always state that in
> the commit message. What do you think?
>
That's fine with me. Thanks for the help Nicolai.

I will keep the patches around for a few more days/a week for people
to ack/nack the proposed changes.

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

Re: [Mesa-dev] [PATCH] glsl: link error if unsized array not-last in ssbo

[Chema Casanova]

I've forgot the --annotate to submit this comment about this patch, so
here it is:

This patch fixes an incorrect behavior exposed by the piglit tests about
SSBOs
and unsized arrays submitted by Dave Airlie not yet in master
https://lists.freedesktop.org/archives/piglit/2016-May/019852.html

Chema

El 15/02/17 a las 15:12, Jose Maria Casanova Crespo escribió:
> If an unsized declared array is not the last in an SSBO
> and an implicit size can not be defined on linking time,
> the linker should raise an error instead of reaching
> an assertion on GL.
>
> This reverts part of commit 3da08e166415a745139c1127040a24e8a45dc553
> getting back to the behavior of commit 
> 5b2675093e863a52b610f112884ae12d42513770
>
> The original patch was correct for GLES that should produce
> a compile-time error but the linker error is still necessary in
> desktop GL.
>
> Signed-off-by: Jose Maria Casanova Crespo 
> ---
>  src/compiler/glsl/link_uniform_blocks.cpp | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/compiler/glsl/link_uniform_blocks.cpp 
> b/src/compiler/glsl/link_uniform_blocks.cpp
> index ba01269..839fd07 100644
> --- a/src/compiler/glsl/link_uniform_blocks.cpp
> +++ b/src/compiler/glsl/link_uniform_blocks.cpp
> @@ -146,7 +146,13 @@ private:
> */
>const glsl_type *type_for_size = type;
>if (type->is_unsized_array()) {
> - assert(last_field);
> + if (!last_field) {
> +linker_error(prog, "unsized array `%s' definition: "
> + "only last member of a shader storage block "
> + "can be defined as unsized array",
> + name);
> + }
> +
>   type_for_size = type->without_array();
>}
>  

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