Re: [Mesa-dev] [PATCH] nir: delete magic number

[tournier.elie]

On 8 February 2017 at 17:12, Jason Ekstrand  wrote:

> On Wed, Feb 8, 2017 at 8:56 AM, Elie Tournier 
> wrote:
>
>> Explaining what is the "26" for.
>>
>> PS: I don't have git rights. Can you push this patch for me?
>>
>> Signed-off-by: Elie Tournier 
>> ---
>>  src/compiler/nir/nir_opt_loop_unroll.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/compiler/nir/nir_opt_loop_unroll.c
>> b/src/compiler/nir/nir_opt_loop_unroll.c
>> index 37cbced43d..2bb1a57791 100644
>> --- a/src/compiler/nir/nir_opt_loop_unroll.c
>> +++ b/src/compiler/nir/nir_opt_loop_unroll.c
>> @@ -26,6 +26,8 @@
>>  #include "nir_control_flow.h"
>>  #include "nir_loop_analyze.h"
>>
>> +#define GLSL_IR_UNROLL_LIMIT 26
>>
>
> Maybe just call this LOOP_UNROLL_LIMIT?  It's not exactly the same as the
> GLSL IR limit.  Also, a comment would be good.  How about:
>
> This limit is chosen fairly arbitrarily.  The GLSL IR limit is 25.
> However, due to slight differences in the way the two IRs count
> instructions, some loops that would unroll with GLSL IR fail to unroll if
> we set this to 25 so we set it to 26.
>

Thanks for the review. I will submit a v2.

>
>
>> +
>>  /* Prepare this loop for unrolling by first converting to lcssa and then
>>   * converting the phis from the loops first block and the block that
>> follows
>>   * the loop into regs.  Partially converting out of SSA allows us to
>> unroll
>> @@ -460,7 +462,7 @@ is_loop_small_enough_to_unroll(nir_shader *shader,
>> nir_loop_info *li)
>>return true;
>>
>> bool loop_not_too_large =
>> -  li->num_instructions * li->trip_count <= max_iter * 26;
>> +  li->num_instructions * li->trip_count <= max_iter *
>> GLSL_IR_UNROLL_LIMIT;
>>
>> return loop_not_too_large;
>>  }
>> --
>> 2.11.0
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] docs: reword sentence that my brain can't parse

[tournier.elie]

Reviewed-by: Elie Tournier 

On 9 February 2017 at 11:46, Eric Engestrom 
wrote:

> Signed-off-by: Eric Engestrom 
> ---
>  docs/egl.html | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/docs/egl.html b/docs/egl.html
> index 6868448bc4..c22aa4a338 100644
> --- a/docs/egl.html
> +++ b/docs/egl.html
> @@ -83,9 +83,9 @@
>  List the platforms (window systems) to support.  Its argument is a
> comma
>  separated string such as --with-egl-platforms=x11,drm.  It
> decides
>  the platforms a driver may support.  The first listed platform is also
> used by
> -the main library to decide the native platform: the platform the EGL
> native
> +the main library to decide the native platform: this defines EGL native
>  types such as EGLNativeDisplayType or
> -EGLNativeWindowType defined for.
> +EGLNativeWindowType.
>
>  The available platforms are x11, drm,
>  wayland, surfaceless, android,
> --
> Cheers,
>   Eric
>
> ___
> 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] nir: delete magic number

[tournier.elie]

On 9 February 2017 at 02:48, Timothy Arceri  wrote:

> On Wed, 8 Feb 2017 15:54:46 -0800
> Jason Ekstrand  wrote:
>
> > On Wed, Feb 8, 2017 at 2:20 PM, Elie Tournier
> >  wrote:
> >
> > > Signed-off-by: Elie Tournier 
> > > ---
> > >  src/compiler/nir/nir_opt_loop_unroll.c | 10 +-
> > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/compiler/nir/nir_opt_loop_unroll.c
> > > b/src/compiler/nir/nir_opt_loop_unroll.c
> > > index 37cbced43d..035a030239 100644
> > > --- a/src/compiler/nir/nir_opt_loop_unroll.c
> > > +++ b/src/compiler/nir/nir_opt_loop_unroll.c
> > > @@ -26,6 +26,14 @@
> > >  #include "nir_control_flow.h"
> > >  #include "nir_loop_analyze.h"
> > >
> > > +
> > > +/* This limit is chosen fairly arbitrarily.  The GLSL IR limit is
> > > 25.
> > > + * However, due to slight differences in the way the two IRs count
> > > + * instructions, some loops that would unroll with GLSL IR fail to
> > > unroll
> > > + * if we set this to 25 so we set it to 26.
> > >
> >
> > Ok, I lied in my comment.  It's not 25, it's 32.  Tim, can you
> > explain the discrepancy?
> > --Jason
>  
> Max iteration is 32 this is number of instructions, in GLSL IR it was
> counting nodes and the magic number was 5. There is no 1:1 mapping 25
> was picked because it seemed to give about the same results. Around 5
> instructions per node. 
>
>
So to resume. Is this comment correct for you?

This limit is chosen fairly arbitrarily.
GLSL IR max iteration is 32 instructions. (Counting nodes by magic number 5).
But there is no 1:1 mapping between GLSL IR and NIR so 25 was picked because
it seemed to give about the same results. Around 5 instructions per node.
But some loops that would unroll with GLSL IR fail to unroll if we set
this to 25 so we set it to 26.

>
> >
> > > + */
> > > +#define LOOP_UNROLL_LIMIT 26
> > > +
> > >  /* Prepare this loop for unrolling by first converting to lcssa
> > > and then
> > >   * converting the phis from the loops first block and the block
> > > that follows
> > >   * the loop into regs.  Partially converting out of SSA allows us
> > > to unroll
> > > @@ -460,7 +468,7 @@ is_loop_small_enough_to_unroll(nir_shader
> > > *shader, nir_loop_info *li)
> > >return true;
> > >
> > > bool loop_not_too_large =
> > > -  li->num_instructions * li->trip_count <= max_iter * 26;
> > > +  li->num_instructions * li->trip_count <= max_iter *
> > > LOOP_UNROLL_LIMIT;
> > >
> > > return loop_not_too_large;
> > >  }
> > > --
> > > 2.11.0
> > >
> > >
>
>
On 9 February 2017 at 02:48, Timothy Arceri  wrote:On Wed, 8 Feb 2017 15:54:46 -0800
Jason Ekstrand  wrote:

> On Wed, Feb 8, 2017 at 2:20 PM, Elie Tournier
>  wrote:
>
> > Signed-off-by: Elie Tournier 
> > ---
> >  src/compiler/nir/nir_opt_loop_unroll.c | 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/compiler/nir/nir_opt_loop_unroll.c
> > b/src/compiler/nir/nir_opt_loop_unroll.c
> > index 37cbced43d..035a030239 100644
> > --- a/src/compiler/nir/nir_opt_loop_unroll.c
> > +++ b/src/compiler/nir/nir_opt_loop_unroll.c
> > @@ -26,6 +26,14 @@
> >  #include "nir_control_flow.h"
> >  #include "nir_loop_analyze.h"
> >
> > +
> > +/* This limit is chosen fairly arbitrarily.  The GLSL IR limit is
> > 25.
> > + * However, due to slight differences in the way the two IRs count
> > + * instructions, some loops that would unroll with GLSL IR fail to
> > unroll
> > + * if we set this to 25 so we set it to 26.
> >
>
> Ok, I lied in my comment.  It's not 25, it's 32.  Tim, can you
> explain the discrepancy?
> --Jason 
Max iteration is 32 this is number of instructions, in GLSL IR it was
counting nodes and the magic number was 5. There is no 1:1 mapping 25
was picked because it seemed to give about the same results. Around 5
instructions per node. 
So to resume. Is this comment correct for you?Max iteration is 32 this is number of instructions, in GLSL IR it was
counting nodes and the magic number was 5. There is no 1:1 mapping 25
was picked because it seemed to give about the same results. Around 5
instructions per node. But some loops that would unroll with GLSL IR failto unroll if we set this to 25 so we set it to 26. 
>
>
> > + */
> > +#define LOOP_UNROLL_LIMIT 26
> > +
> >  /* Prepare this loop for unrolling by first converting to lcssa
> > and then
> >   * converting the phis from the loops first block and the block
> > that follows
> >   * the loop into regs.  Partially converting out of SSA allows us
> > to unroll
> > @@ -460,7 +468,7 @@ is_loop_small_enough_to_unroll(nir_shader
> > *shader, nir_loop_info *li)
> >        return true;
> >
> >     bool loop_not_too_large =
> > -      li->num_instructions * li->trip_count <= max_iter * 26;
> > +      li->num_instructions * li->trip_count <= max_iter *
> > LOOP_UNROLL_LIMIT;
> >
> >     return loop_not_too_large;
> >  }
> > --
> > 2.11.0
> >

Re: [Mesa-dev] [PATCH v2] nir: delete magic number

[tournier.elie]

Whoops I answer 2 times.

Would the comment bellow be appropriate?

This limit is chosen fairly arbitrarily.
GLSL IR max iteration is 32 instructions. (Multiply counting nodes and
magic number 5).
But there is no 1:1 mapping between GLSL IR and NIR so 25 was picked because
it seemed to give about the same results. Around 5 instructions per node.
But some loops that would unroll with GLSL IR fail to unroll if we set
this to 25 so we set it to 26.

Elie


On 13 February 2017 at 01:00, tournier.elie  wrote:

>
> On 9 February 2017 at 02:48, Timothy Arceri  wrote:
>
> > On Wed, 8 Feb 2017 15:54:46 -0800
> > Jason Ekstrand  wrote:
> >
> > > On Wed, Feb 8, 2017 at 2:20 PM, Elie Tournier
> > >  wrote:
> > >
> > > > Signed-off-by: Elie Tournier 
> > > > ---
> > > >  src/compiler/nir/nir_opt_loop_unroll.c | 10 +-
> > > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/src/compiler/nir/nir_opt_loop_unroll.c
> > > > b/src/compiler/nir/nir_opt_loop_unroll.c
> > > > index 37cbced43d..035a030239 100644
> > > > --- a/src/compiler/nir/nir_opt_loop_unroll.c
> > > > +++ b/src/compiler/nir/nir_opt_loop_unroll.c
> > > > @@ -26,6 +26,14 @@
> > > >  #include "nir_control_flow.h"
> > > >  #include "nir_loop_analyze.h"
> > > >
> > > > +
> > > > +/* This limit is chosen fairly arbitrarily.  The GLSL IR limit is
> > > > 25.
> > > > + * However, due to slight differences in the way the two IRs count
> > > > + * instructions, some loops that would unroll with GLSL IR fail to
> > > > unroll
> > > > + * if we set this to 25 so we set it to 26.
> > > >
> > >
> > > Ok, I lied in my comment.  It's not 25, it's 32.  Tim, can you
> > > explain the discrepancy?
> > > --Jason
> >
> > Max iteration is 32 this is number of instructions, in GLSL IR it was
> > counting nodes and the magic number was 5. There is no 1:1 mapping 25
> > was picked because it seemed to give about the same results. Around 5
> > instructions per node.
> >
> >
> So to resume. Is this comment correct for you?
>
> This limit is chosen fairly arbitrarily.
> GLSL IR max iteration is 32 instructions. (Counting nodes by magic number
> 5).
> But there is no 1:1 mapping between GLSL IR and NIR so 25 was picked
> because
> it seemed to give about the same results. Around 5 instructions per node.
> But some loops that would unroll with GLSL IR fail to unroll if we set
> this to 25 so we set it to 26.
>
> >
> > >
> > > > + */
> > > > +#define LOOP_UNROLL_LIMIT 26
> > > > +
> > > >  /* Prepare this loop for unrolling by first converting to lcssa
> > > > and then
> > > >   * converting the phis from the loops first block and the block
> > > > that follows
> > > >   * the loop into regs.  Partially converting out of SSA allows us
> > > > to unroll
> > > > @@ -460,7 +468,7 @@ is_loop_small_enough_to_unroll(nir_shader
> > > > *shader, nir_loop_info *li)
> > > >return true;
> > > >
> > > > bool loop_not_too_large =
> > > > -  li->num_instructions * li->trip_count <= max_iter * 26;
> > > > +  li->num_instructions * li->trip_count <= max_iter *
> > > > LOOP_UNROLL_LIMIT;
> > > >
> > > > return loop_not_too_large;
> > > >  }
> > > > --
> > > > 2.11.0
> > > >
> > > >
> >
> >
>
>
> On 9 February 2017 at 02:48, Timothy Arceri  wrote:
>
>> On Wed, 8 Feb 2017 15:54:46 -0800
>> Jason Ekstrand  wrote:
>>
>> > On Wed, Feb 8, 2017 at 2:20 PM, Elie Tournier
>> >  wrote:
>> >
>> > > Signed-off-by: Elie Tournier 
>> > > ---
>> > >  src/compiler/nir/nir_opt_loop_unroll.c | 10 +-
>> > >  1 file changed, 9 insertions(+), 1 deletion(-)
>> > >
>> > > diff --git a/src/compiler/nir/nir_opt_loop_unroll.c
>> > > b/src/compiler/nir/nir_opt_loop_unroll.c
>> > > index 37cbced43d..035a030239 100644
>> > > --- a/src/compiler/nir/nir_opt_loop_unroll.c
>> > > +++ b/src/compiler/nir/nir_opt_loop_unroll.c
>> > > @@ -26,6 +26,14 @@
>> > >  #include "nir_control_flow.h"
>> > >  #include "nir_loop_analyze.h"
>> > >
>> > > +

Re: [Mesa-dev] [PATCH] glsl/tests: Add UINT64 and INT64 types

[tournier.elie]

On 13 February 2017 at 20:35, Rhys Kidd  wrote:

>
> On Mon, Feb 13, 2017 at 9:43 AM Elie Tournier 
> wrote:
>
>> Seems good to me.
>>
>> Reviewed-by: Elie Tournier 
>>
>
> Thanks Elie.
>
> Given we are both "new-er" Mesa contributors I might wait for one more
> Reviewed-by before asking for it to be merged.
>

Ping.
Are you OK with this patch? If yes, can you merge it please?
Thanks
Elie

>
>
>> On Sat, Feb 11, 2017 at 05:31:09PM -0500, Rhys Kidd wrote:
>> > glsl/tests/uniform_initializer_utils.cpp:83:14: warning: enumeration
>> value ‘GLSL_TYPE_UINT64’ not handled in switch [-Wswitch]
>> >switch (type->base_type) {
>> >   ^
>> > glsl/tests/uniform_initializer_utils.cpp:83:14: warning: enumeration
>> value ‘GLSL_TYPE_INT64’ not handled in switch [-Wswitch]
>> >
>> > Fixes: 8ce53d4a2f3 ("glsl: Add basic ARB_gpu_shader_int64 types")
>> > Signed-off-by: Rhys Kidd 
>> > ---
>> >  src/compiler/glsl/tests/uniform_initializer_utils.cpp | 18
>> ++
>> >  1 file changed, 18 insertions(+)
>> >
>> > diff --git a/src/compiler/glsl/tests/uniform_initializer_utils.cpp
>> b/src/compiler/glsl/tests/uniform_initializer_utils.cpp
>> > index ec64be1..2a1a168 100644
>> > --- a/src/compiler/glsl/tests/uniform_initializer_utils.cpp
>> > +++ b/src/compiler/glsl/tests/uniform_initializer_utils.cpp
>> > @@ -96,6 +96,12 @@ generate_data_element(void *mem_ctx, const glsl_type
>> *type,
>> >case GLSL_TYPE_DOUBLE:
>> >data.d[i] = double(values[idx]);
>> >break;
>> > +  case GLSL_TYPE_UINT64:
>> > +  data.u64[i] = (uint64_t) values[idx];
>> > +  break;
>> > +  case GLSL_TYPE_INT64:
>> > +  data.i64[i] = (int64_t) values[idx];
>> > +  break;
>> >case GLSL_TYPE_ATOMIC_UINT:
>> >case GLSL_TYPE_STRUCT:
>> >case GLSL_TYPE_ARRAY:
>> > @@ -130,6 +136,12 @@ generate_data_element(void *mem_ctx, const
>> glsl_type *type,
>> >case GLSL_TYPE_DOUBLE:
>> >ASSERT_EQ(data.d[i], val->value.d[i]);
>> >break;
>> > +  case GLSL_TYPE_UINT64:
>> > +  ASSERT_EQ(data.u64[i], val->value.u64[i]);
>> > +  break;
>> > +  case GLSL_TYPE_INT64:
>> > +  ASSERT_EQ(data.i64[i], val->value.i64[i]);
>> > +  break;
>> >case GLSL_TYPE_ATOMIC_UINT:
>> >case GLSL_TYPE_STRUCT:
>> >case GLSL_TYPE_ARRAY:
>> > @@ -236,6 +248,12 @@ verify_data(gl_constant_value *storage, unsigned
>> storage_array_size,
>> >case GLSL_TYPE_DOUBLE:
>> >   EXPECT_EQ(val->value.d[i], *(double *)&storage[i*2].i);
>> >   break;
>> > +  case GLSL_TYPE_UINT64:
>> > + EXPECT_EQ(val->value.u64[i], *(uint64_t *)&storage[i*2].i);
>> > + break;
>> > +  case GLSL_TYPE_INT64:
>> > + EXPECT_EQ(val->value.i64[i], *(int64_t *)&storage[i*2].i);
>> > + break;
>> >   case GLSL_TYPE_ATOMIC_UINT:
>> >case GLSL_TYPE_STRUCT:
>> >case GLSL_TYPE_ARRAY:
>> > --
>> > 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 1/4] compiler: style clean-ups in blob.h

[tournier.elie]

Reviewed-by: Elie Tournier 

On 24 February 2017 at 04:34, Timothy Arceri  wrote:

> ---
>  src/compiler/glsl/blob.h | 42 +-
>  1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/src/compiler/glsl/blob.h b/src/compiler/glsl/blob.h
> index 81b9917..21fa43d 100644
> --- a/src/compiler/glsl/blob.h
> +++ b/src/compiler/glsl/blob.h
> @@ -71,81 +71,81 @@ struct blob_reader {
> uint8_t *current;
> bool overrun;
>  };
>
>  /**
>   * Create a new, empty blob, belonging to \mem_ctx.
>   *
>   * \return The new blob, (or NULL in case of allocation failure).
>   */
>  struct blob *
> -blob_create (void *mem_ctx);
> +blob_create(void *mem_ctx);
>
>  /**
>   * Add some unstructured, fixed-size data to a blob.
>   *
>   * \return True unless allocation failed.
>   */
>  bool
> -blob_write_bytes (struct blob *blob, const void *bytes, size_t to_write);
> +blob_write_bytes(struct blob *blob, const void *bytes, size_t to_write);
>
>  /**
>   * Reserve space in \blob for a number of bytes.
>   *
>   * Space will be allocated within the blob for these byes, but the bytes
> will
>   * be left uninitialized. The caller is expected to use the return value
> to
>   * write directly (and immediately) to these bytes.
>   *
>   * \note The return value is valid immediately upon return, but can be
>   * invalidated by any other call to a blob function. So the caller should
> call
>   * blob_reserve_byes immediately before writing through the returned
> pointer.
>   *
>   * This function is intended to be used when interfacing with an existing
> API
>   * that is not aware of the blob API, (so that blob_write_bytes cannot be
>   * called).
>   *
>   * \return A pointer to space allocated within \blob to which \to_write
> bytes
>   * can be written, (or NULL in case of any allocation error).
>   */
>  uint8_t *
> -blob_reserve_bytes (struct blob *blob, size_t to_write);
> +blob_reserve_bytes(struct blob *blob, size_t to_write);
>
>  /**
>   * Overwrite some data previously written to the blob.
>   *
>   * Writes data to an existing portion of the blob at an offset of \offset.
>   * This data range must have previously been written to the blob by one
> of the
>   * blob_write_* calls.
>   *
>   * For example usage, see blob_overwrite_uint32
>   *
>   * \return True unless the requested offset or offset+to_write lie outside
>   * the current blob's size.
>   */
>  bool
> -blob_overwrite_bytes (struct blob *blob,
> -  size_t offset,
> -  const void *bytes,
> -  size_t to_write);
> +blob_overwrite_bytes(struct blob *blob,
> + size_t offset,
> + const void *bytes,
> + size_t to_write);
>
>  /**
>   * Add a uint32_t to a blob.
>   *
>   * \note This function will only write to a uint32_t-aligned offset from
> the
>   * beginning of the blob's data, so some padding bytes may be added to the
>   * blob if this write follows some unaligned write (such as
>   * blob_write_string).
>   *
>   * \return True unless allocation failed.
>   */
>  bool
> -blob_write_uint32 (struct blob *blob, uint32_t value);
> +blob_write_uint32(struct blob *blob, uint32_t value);
>
>  /**
>   * Overwrite a uint32_t previously written to the blob.
>   *
>   * Writes a uint32_t value to an existing portion of the blob at an
> offset of
>   * \offset.  This data range must have previously been written to the
> blob by
>   * one of the blob_write_* calls.
>   *
>   *
>   * The expected usage is something like the following pattern:
> @@ -154,138 +154,138 @@ blob_write_uint32 (struct blob *blob, uint32_t
> value);
>   *
>   * offset = blob->size;
>   * blob_write_uint32 (blob, 0); // placeholder
>   * ... various blob write calls, writing N items ...
>   * blob_overwrite_uint32 (blob, offset, N);
>   *
>   * \return True unless the requested position or position+to_write lie
> outside
>   * the current blob's size.
>   */
>  bool
> -blob_overwrite_uint32 (struct blob *blob,
> -   size_t offset,
> -   uint32_t value);
> +blob_overwrite_uint32(struct blob *blob,
> +  size_t offset,
> +  uint32_t value);
>
>  /**
>   * Add a uint64_t to a blob.
>   *
>   * \note This function will only write to a uint64_t-aligned offset from
> the
>   * beginning of the blob's data, so some padding bytes may be added to the
>   * blob if this write follows some unaligned write (such as
>   * blob_write_string).
>   *
>   * \return True unless allocation failed.
>   */
>  bool
> -blob_write_uint64 (struct blob *blob, uint64_t value);
> +blob_write_uint64(struct blob *blob, uint64_t value);
>
>  /**
>   * Add an intptr_t to a blob.
>   *
>   * \note This function will only write to an intptr_t-aligned offset from
> the
>   * beginning of the blob's data, so some padding bytes may be added to the
>   * blob if this write

Re: [Mesa-dev] [PATCH v2] nir: delete magic number

[tournier.elie]

Ping.


On 13 February 2017 at 10:17, tournier.elie  wrote:

> Whoops I answer 2 times.
>
> Would the comment bellow be appropriate?
>
> This limit is chosen fairly arbitrarily.
> GLSL IR max iteration is 32 instructions. (Multiply counting nodes and
> magic number 5).
> But there is no 1:1 mapping between GLSL IR and NIR so 25 was picked
> because
> it seemed to give about the same results. Around 5 instructions per node.
> But some loops that would unroll with GLSL IR fail to unroll if we set
> this to 25 so we set it to 26.
>
> Elie
>
>
> On 13 February 2017 at 01:00, tournier.elie 
> wrote:
>
>>
>> On 9 February 2017 at 02:48, Timothy Arceri 
>> wrote:
>>
>> > On Wed, 8 Feb 2017 15:54:46 -0800
>> > Jason Ekstrand  wrote:
>> >
>> > > On Wed, Feb 8, 2017 at 2:20 PM, Elie Tournier
>> > >  wrote:
>> > >
>> > > > Signed-off-by: Elie Tournier 
>> > > > ---
>> > > >  src/compiler/nir/nir_opt_loop_unroll.c | 10 +-
>> > > >  1 file changed, 9 insertions(+), 1 deletion(-)
>> > > >
>> > > > diff --git a/src/compiler/nir/nir_opt_loop_unroll.c
>> > > > b/src/compiler/nir/nir_opt_loop_unroll.c
>> > > > index 37cbced43d..035a030239 100644
>> > > > --- a/src/compiler/nir/nir_opt_loop_unroll.c
>> > > > +++ b/src/compiler/nir/nir_opt_loop_unroll.c
>> > > > @@ -26,6 +26,14 @@
>> > > >  #include "nir_control_flow.h"
>> > > >  #include "nir_loop_analyze.h"
>> > > >
>> > > > +
>> > > > +/* This limit is chosen fairly arbitrarily.  The GLSL IR limit is
>> > > > 25.
>> > > > + * However, due to slight differences in the way the two IRs count
>> > > > + * instructions, some loops that would unroll with GLSL IR fail to
>> > > > unroll
>> > > > + * if we set this to 25 so we set it to 26.
>> > > >
>> > >
>> > > Ok, I lied in my comment.  It's not 25, it's 32.  Tim, can you
>> > > explain the discrepancy?
>> > > --Jason
>> >
>> > Max iteration is 32 this is number of instructions, in GLSL IR it was
>> > counting nodes and the magic number was 5. There is no 1:1 mapping 25
>> > was picked because it seemed to give about the same results. Around 5
>> > instructions per node.
>> >
>> >
>> So to resume. Is this comment correct for you?
>>
>> This limit is chosen fairly arbitrarily.
>> GLSL IR max iteration is 32 instructions. (Counting nodes by magic number
>> 5).
>> But there is no 1:1 mapping between GLSL IR and NIR so 25 was picked
>> because
>> it seemed to give about the same results. Around 5 instructions per node.
>> But some loops that would unroll with GLSL IR fail to unroll if we set
>> this to 25 so we set it to 26.
>>
>> >
>> > >
>> > > > + */
>> > > > +#define LOOP_UNROLL_LIMIT 26
>> > > > +
>> > > >  /* Prepare this loop for unrolling by first converting to lcssa
>> > > > and then
>> > > >   * converting the phis from the loops first block and the block
>> > > > that follows
>> > > >   * the loop into regs.  Partially converting out of SSA allows us
>> > > > to unroll
>> > > > @@ -460,7 +468,7 @@ is_loop_small_enough_to_unroll(nir_shader
>> > > > *shader, nir_loop_info *li)
>> > > >return true;
>> > > >
>> > > > bool loop_not_too_large =
>> > > > -  li->num_instructions * li->trip_count <= max_iter * 26;
>> > > > +  li->num_instructions * li->trip_count <= max_iter *
>> > > > LOOP_UNROLL_LIMIT;
>> > > >
>> > > > return loop_not_too_large;
>> > > >  }
>> > > > --
>> > > > 2.11.0
>> > > >
>> > > >
>> >
>> >
>>
>>
>> On 9 February 2017 at 02:48, Timothy Arceri 
>> wrote:
>>
>>> On Wed, 8 Feb 2017 15:54:46 -0800
>>> Jason Ekstrand  wrote:
>>>
>>> > On Wed, Feb 8, 2017 at 2:20 PM, Elie Tournier
>>> >  wrote:
>>> >
>>> > > Signed-off-by: Elie Tournier 
>>> > > ---
>>> > >  src/compiler/nir/nir_opt_loop_unroll.c | 10 +-
>>> > >  1 file changed, 9 insertions

Re: [Mesa-dev] [GSoC] Update about floating point library

[tournier.elie]

Hi everyone,

It's the last week of the GSoC but not the last week of my contribution.
The library of functions isn't finish yet. I still has to debug the
multiply function and to implement the fma.
I wrote a post about my GSoC:
https://hopetech.github.io/tech/2016/08/18/Last_week_GSoC.html

Have a nice day!
Elie

2016-07-29 7:10 GMT+02:00 Connor Abbott :

> (Re-adding the list)
>
> On Mon, Jul 25, 2016 at 4:46 AM, tournier.elie 
> wrote:
> > Hi.
> >
> > Thanks for your email.
> > It seems that you don't work for nvidia. :P.
> >
> > 1.
> > In my *.shader_test files, I have:
> > [require]
> > GLSL >= 1.30
> >
> > Should I still add "#version 130" at the top of each shaders?
>
> Yes, since AFAIK that's just a requirement on the OpenGL
> implementation ("you must support at least GLSL 1.30 to run this
> test") and it doesn't actually add the version tag. If you take a look
> at any random shader_test file in piglit (e.g.
> tests/spec/glsl-1.30/execution/vs-attrib-ivec4-precision.shader_test)
> you'll see that it declares the version explicitly. And you've already
> seen the kind of shenanigans that happen when you don't add it and
> don't test with Mesa.
>
> >
> > 3.
> > I think that I just need recip and rsqrt to finish the library. (and to
> test
> > my code of course.)
> > I will check which functions does I need to implement
> > GL_ARB_gpu_shader_fp64.
>
> Ok, although I think you'll need to implement fma to get the precision
> you need to implement sqrt, inverse, and rsqrt. I believe "real"
> softfloat libraries use some kind of integer-based higher-precision
> thing, but you don't need an exact result so you don't need to be that
> fancy (again, a good reason why our implementation is probably better
> to base off of!).
>
> Connor
>
> >
> >
> > Elie
> >
> >
> > Le samedi 23 juillet 2016, Connor Abbott  a écrit :
> >>
> >> On Sat, Jul 23, 2016 at 3:32 PM, tournier.elie  >
> >> wrote:
> >> > Hello,
> >> >
> >> > I hope you are well and that you enjoy these beautiful summer days.
> >> >
> >> > You can found a new post on my blog : https://hopetech.github.io/ .
> >> > During these few days, I implemented eq_fp64, le_fp64, lt_fp64,
> >> > mul_fp64,
> >> > add_fp64 and fp64-to-fp32-conversion. The code can be found on
> >> > https://github.com/Hopetech/libSoftFloat .
> >> >
> >> > Like I say in my post, I will try to make a Docker file for Mesa and
> >> > Piglit
> >> > developers.
> >> > The goal is to have an "easy to install" working environment.
> >> > If you have any ideas/recommandations, please don't hesitate to
> contact
> >> > me.
> >> >
> >> > Have a nice day.
> >> > Elie Tournier
> >> >
> >> > ___
> >> > mesa-dev mailing list
> >> > mesa-dev@lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >> >
> >>
> >> Hi,
> >>
> >> Here are a few things to consider:
> >>
> >> 1. If you want your implementation to be pure GLSL 1.30, then you need
> >> to add "#version 130" at the top of all your shaders. Otherwise,
> >> you'll nominally get GLSL 1.10 (which doesn't support bit-twiddling at
> >> all), but certain vendors (*cough* nvidia *cough*) will take it to
> >> mean "just turn all of the extensions on." If you don't add the
> >> version tag, then you might accidentally do something that won't fly
> >> on other implementations. For example, you're using pointers all over
> >> the place in function parameters when that's not valid GLSL 1.30 (or
> >> any other unextended version of GLSL) since GLSL doesn't have the
> >> concept of pointers. Instead, you should be using out/inout parameters
> >> (e.g. "out uint zExpPtr").
> >>
> >> 2. I wouldn't worry too much about underflow, etc. since GLSL doesn't
> >> require it. The goal in the end is to implement fp64 in a way that
> >> satisfies the GLSL spec, so you don't need to worry about implementing
> >> all of IEEE if GLSL says it isn't required.
> >>
> >> 2. For sqrt, rsqrt, mod, and so on, I'd check out Intel's
> >> implementation of them in our compiler:
> >>
> >> https://cgit.freedesktop.org/mesa/mesa/tree/src/compiler/
> nir/nir_lower_double_ops.c
> >> Intel GPU's are missing a lot of the fp64 operations required by GLSL
> >> (they basically only have the ones you already implemented, plus fma),
> >> so we had to emulate the others ourselves. Once you get fma working,
> >> you can just follow the code there to implement the rest, since your
> >> goal is very similar to ours. This should be much more straightforward
> >> than basing your code on another softfloat library, since, like you,
> >> we assume the existence of all the fp32 operations and don't try to be
> >> exact when GLSL doesn't require us to be.
> >>
> >> Connor
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] docs/submitting patches: mention get_reviewers.pl

[tournier.elie]

Nice,

Reviewed-by: Elie Tournier 



2016-11-21 18:56 GMT+01:00 Emil Velikov :

> From: Emil Velikov 
>
> Mention the script - why/how to use alongside a useful trick to make it
> work interactively (thanks Rob!).
>
> Signed-off-by: Emil Velikov 
> ---
> Based on top of the "git tips" from earlier.
> ---
>  docs/submittingpatches.html | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html
> index 7ada508..2f4be5d 100644
> --- a/docs/submittingpatches.html
> +++ b/docs/submittingpatches.html
> @@ -104,6 +104,19 @@ that should be documented with:
>  Reviewed-by: Joe Hacker 
>  Acked-by: Joe Hacker 
>  
> +In order for your patch to reach the prospective reviewer
> easier/faster,
> +use the script scripts/get_reviewer.pl to get a list of individuals and
> include
> +them in the CC list.
> +
> +Please use common sense and do not blindly add everyone.
> +
> +
> +$ scripts/get_reviewer.pl --help # to get the the help screen
> +$ scripts/get_reviewer.pl -f src/egl/drivers/dri2/platform_android.c
> +Rob Herring  (reviewer:ANDROID EGL
> SUPPORT,added_lines:188/700=27%,removed_lines:58/283=20%)
> +Tomasz Figa  (reviewer:ANDROID EGL
> SUPPORT,authored:12/41=29%,added_lines:308/700=44%,
> removed_lines:115/283=41%)
> +Emil Velikov  (authored:13/41=32%,removed_
> lines:76/283=27%)
> +
>  
>
>
> @@ -335,6 +348,11 @@ commits before sending.
>  git send-email --subject-prefix="PATCH v4" HEAD~8
>  git send-email -v4 HEAD~8 # shorter version, 'inherited' from git
> format-patch
>  
> + Configure git to use the get_reviewer.pl script interactively. Thus
> you
> +can avoid adding the world to the CC list.
> +
> +git config sendemail.cccmd "./scripts/get_reviewer.pl -i"
> +
>  
>
>
> --
> 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 2/3] st/va: remove unused variable pbuff

[tournier.elie]

Reviewed-by: Elie Tournier 


2016-12-02 17:26 GMT+01:00 Emil Velikov :

> From: Emil Velikov 
>
> Signed-off-by: Emil Velikov 
> ---
>  src/gallium/state_trackers/va/surface.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/va/surface.c
> b/src/gallium/state_trackers/va/surface.c
> index f8513d9..357e85e 100644
> --- a/src/gallium/state_trackers/va/surface.c
> +++ b/src/gallium/state_trackers/va/surface.c
> @@ -94,7 +94,6 @@ vlVaSyncSurface(VADriverContextP ctx, VASurfaceID
> render_target)
> vlVaDriver *drv;
> vlVaContext *context;
> vlVaSurface *surf;
> -   void *pbuff;
>
> if (!ctx)
>return VA_STATUS_ERROR_INVALID_CONTEXT;
> --
> 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

[Mesa-dev] [GSoC] Update about floating point library

[tournier.elie]

Hello,

I hope you are well and that you enjoy these beautiful summer days.

You can found a new post on my blog : https://hopetech.github.io/ .
During these few days, I implemented eq_fp64, le_fp64, lt_fp64, mul_fp64,
add_fp64 and fp64-to-fp32-conversion. The code can be found on
https://github.com/Hopetech/libSoftFloat .

Like I say in my post, I will try to make a Docker file for Mesa and Piglit
developers.
The goal is to have an "easy to install" working environment.
If you have any ideas/recommandations, please don't hesitate to contact me.

Have a nice day.
Elie Tournier
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] doxygen: update glsl link

[tournier.elie]

2016-04-05 4:04 GMT+02:00 Rhys Kidd :

> On 4 April 2016 at 17:44, Emil Velikov  wrote:
>
>> On 4 April 2016 at 21:38, Elie TOURNIER  wrote:
>> > ---
>> >  doxygen/glsl.doxy | 7 +++
>> >  1 file changed, 3 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/doxygen/glsl.doxy b/doxygen/glsl.doxy
>> > index 9915ba2..0f4c822 100644
>> > --- a/doxygen/glsl.doxy
>> > +++ b/doxygen/glsl.doxy
>> > @@ -9,11 +9,10 @@ PROJECT_NAME   = "Mesa GLSL module"
>> >
>> #---
>> >  # configuration options related to the input files
>> >
>> #---
>> > -INPUT  = ../src/glsl/
>> > +INPUT  = ../src/compiler/glsl/
>> > +FILE_PATTERNS  = *.c *.cpp *.h
>> >  RECURSIVE  = NO
>> > -EXCLUDE= ../src/glsl/glsl_lexer.cpp \
>> > - ../src/glsl/glsl_parser.cpp \
>> > - ../src/glsl/glsl_parser.h
>> > +EXCLUDE=
>> Speaking of doxygen, has anyone managed to get it in shape ? I've seen
>> some efforts in https://fossies.org/dox/mesa-11.0.9/ although I'm not
>> sure how much thinkering was required to get that far.
>>
>
> Emil,
>
> I have a patchset to come which includes further clean ups and fixes to
> doxygen.
>
> Fixes some little oversights and copy-paste introduced bugs.
>
> Regards,
> Rhys
>


Rhys,

Do you want me to submit a v2 of this patch or will  you include this link
fix in your patchset?

I will create a doxygen file for src/compiler/nir. Like this, we will have
a complete doc for compiler.


Regards,
Elie



>
>
>> For the patch itself - I second Matt's suggestion. Let's keep the
>> generated sources out, for the time being at least.
>>
>> -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 v2] doxygen: update glsl link

[tournier.elie]

Thanks.

I wrote an other patch call "*[PATH v2] doxygen: Generate Doxygen for NIR*".

Rhys reviewed it. But I'm not sure he tested it. If it's the case, you can
push it too.

Regards,
Elie

2016-04-11 16:10 GMT+02:00 Emil Velikov :

> On 9 April 2016 at 13:55, Rhys Kidd  wrote:
> > On 7 April 2016 at 17:21, Elie TOURNIER  wrote:
> >>
> >> Signed-off-by: Elie TOURNIER 
> >> ---
> >>  doxygen/glsl.doxy | 9 +
> >>  1 file changed, 5 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/doxygen/glsl.doxy b/doxygen/glsl.doxy
> >> index 9915ba2..ef71a4a 100644
> >> --- a/doxygen/glsl.doxy
> >> +++ b/doxygen/glsl.doxy
> >> @@ -9,11 +9,12 @@ PROJECT_NAME   = "Mesa GLSL module"
> >>
> >>
> #---
> >>  # configuration options related to the input files
> >>
> >>
> #---
> >> -INPUT  = ../src/glsl/
> >> +INPUT  = ../src/compiler/glsl/
> >> +FILE_PATTERNS  = *.c *.cpp *.h
> >>  RECURSIVE  = NO
> >> -EXCLUDE= ../src/glsl/glsl_lexer.cpp \
> >> - ../src/glsl/glsl_parser.cpp \
> >> - ../src/glsl/glsl_parser.h
> >> +EXCLUDE= ../src/compiler/glsl/glsl_lexer.cpp \
> >> + ../src/compiler/glsl/glsl_parser.cpp \
> >> + ../src/compiler/glsl/glsl_parser.h
> >>  EXCLUDE_PATTERNS   =
> >>
> >>
> #---
> >>  # configuration options related to the HTML output
> >> --
> >> 1.9.1
> >>
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> >
> > Thanks Elie.
> >
> > This patch gets my:
> >
> > Reviewed-by: Rhys Kidd 
> > Tested-by: Rhys Kidd 
> >
> > However, I believe we both do not have commit privileges to the Mesa
> > repository, so perhaps Emil would be able to push this commit?
> >
> Thanks guys. Barring any comments I'll push it at the end of today.
>
> -Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [GSoC2016] Interested in implementing "Soft" double precision floating point support

[tournier.elie]

Hi everyone.

My name is Elie TOURNIER, I am enrolled in a French Engineering school
(Telecom Physique Strasbourg) specialized in Medical ICT.
I'm interested in implementing "Soft" double precision floating point
support [1].
Taking this subject seem to be a good way to get my feet wet in the Mesa
code and discover how some of its components works.

I come to you in order to become know but also to retrieve valuable
information for the success of this project.

I would like to know more about the following things to understand your
requirements :
1- "*Each double precision value would be stored in a uvec2*" The IEEE
double precision floating point standard representation requires a 64 bit:
1 for sign, 11 for exponent and the others for fraction [2].
-> How double precision value must be stored?
2- Where can I find GL_ARB_gpu_shader_fp64 documentation?


This is my first exposure to Mesa. Please excuse me if I am asking basic
questions.

Please point me to the right resources so that I can better understand the
project. I would also be happy to fix a bug to familiarize myself  with the
source code. Any suggestions on bugs that are relevant to the project will
be of great help.

Regards,
Elie

[1]
http://www.x.org/wiki/SummerOfCodeIdeas/#softdoubleprecisionfloatingpointsupport
[2] http://steve.hollasch.net/cgindex/coding/ieeefloat.html#storage

PS: If you have any questions, please don't hesitate to contact me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [GSoC2016] Interested in implementing "Soft" double precision floating point support

[tournier.elie]

First, thank you all for your answers.

So if I summarize what was said, we need
Ian:
 - add
 - negate
 - absolute value
 - multiply
 - reciprocal
 - convert to single precision
 - convert from single precision
Roland:
 - sqrt
 - comparaison (< / == / >)
 - floor/ceil
I will contact Pat Brown (His name appear in the contact field in [1]) to
know if we need the function below for implement gpu_shader_fp64.
 - pow
 - exp
 - log

About the license




*Like I mentioned in the project description, there are quite a few
existing C implementations of these functions.  Finding one of those that
you can understand and that has a compatible license is probably the best
place to start.*

Main Mesa code is under MIT license.
If I chose to use a GNU GPL license file like Linux kernel [3], my code
must be under GNU GPL and probably all the project too. Am I right?

[1] https://www.opengl.org/registry/specs/ARB/gpu_shader_fp64.txt
[2] http://www.mesa3d.org/license.html
[3]
https://github.com/torvalds/linux/blob/097f70b3c4d84ffccca15195bdfde3a37c0a7c0f/arch/arm/nwfpe/softfloat.c

2016-03-10 2:18 GMT+01:00 Roland Scheidegger :

> Am 09.03.2016 um 23:51 schrieb Ian Romanick:
> > On 03/09/2016 02:25 AM, tournier.elie wrote:
> >> Hi everyone.
> >>
> >> My name is Elie TOURNIER, I am enrolled in a French Engineering school
> >> (Telecom Physique Strasbourg) specialized in Medical ICT.
> >> I'm interested in implementing "Soft" double precision floating point
> >> support [1].
> >> Taking this subject seem to be a good way to get my feet wet in the Mesa
> >> code and discover how some of its components works.
> >>
> >> I come to you in order to become know but also to retrieve valuable
> >> information for the success of this project.
> >>
> >> I would like to know more about the following things to understand your
> >> requirements :
> >> 1- "/Each double precision value would be stored in a uvec2/" The IEEE
> >> double precision floating point standard representation requires a 64
> >> bit: 1 for sign, 11 for exponent and the others for fraction [2].
> >> -> How double precision value must be stored?
> >
> > As Emil mentioned, on GLSL 1.30, a uvec2 consists of two, 32-bit
> > unsigned integers.  Each double precision value would be stored in a
> uvec2.
> >
> >> 2- Where can I find |GL_ARB_gpu_shader_fp64 |documentation|?
> >> |
> >>
> >>
> >> This is my first exposure to Mesa. Please excuse me if I am asking basic
> >> questions.
> >
> > For this particular project, you wouldn't need Mesa at all for quite
> > some time.  All of the initial project should be done in "raw" GLSL
> > 1.30, and any OpenGL implementation capable of GLSL 1.30 can be used.
> > You would implement (and test!) a library of functions like 'uvec2
> > addDouble(uvec2 a, uvec2 b)' that would provide all of the required
> > double precision operations.
> >
> > The set of required functions should be pretty small.  I think:
> >
> >  - add
> >  - negate
> >  - absolute value
> >  - multiply
> >  - reciprocal
> >  - convert to single precision
> >  - convert from single precision
> >  - pow (maybe?)
> >  - exp (maybe?)
> >  - log (maybe?)
>
> I don't think you need exp/log. At least glsl dosen't require it, though
> the project isn't clear about it.
> (pow all hw I know of with exactly one exception (that would be intel
> graphics...) implements it as log2/mul/exp2 even for f32 anyway).
> I think though you need sqrt (or rsqrt). And some functions for
> rounding, plus comparison operations. Maybe min/max too (albeit if you
> have comparisons you can emulate them of course).
>
> Roland
>
>
> >
> > I think everything else could be implemented using those functions.
> >
> > Like I mentioned in the project description, there are quite a few
> > existing C implementations of these functions.  Finding one of those
> > that you can understand and that has a compatible license is probably
> > the best place to start.
> >
> >> Please point me to the right resources so that I can better understand
> >> the project. I would also be happy to fix a bug to familiarize myself
> >> with the source code. Any suggestions on bugs that are relevant to the
> >> project will be of great help.
> >>
> >> Regards,
> >> Elie
> >>
> >> [1]
> >>
> http://www.x.org/wiki/SummerOfCodeIdeas/#softdoubleprecisionfloatingpointsupport
> >> [2] http://steve.hollasch.net/cgi

Re: [Mesa-dev] [GSoC2016] Interested in implementing "Soft" double precision floating point support

[tournier.elie]

I found on PCC website that it was imported in OpenBSD and NetBSD system so
the license should be compatible.
I think I will use it as a base for add, multiply, absolute value, negate,
convert to/from single precision, and comparison functions.

Tomorrow, I will make a draft of my proposal for GSoC in which I will
resume everything.

2016-03-11 22:00 GMT+01:00 Ian Romanick :

> On 03/10/2016 03:09 PM, Dylan Baker wrote:
> > Quoting Marek Olšák (2016-03-10 06:57:57)
> >> On Thu, Mar 10, 2016 at 3:30 PM, tournier.elie 
> wrote:
> >>> First, thank you all for your answers.
> >>>
> >>> So if I summarize what was said, we need
> >>> Ian:
> >>>  - add
> >>>  - negate
> >>>  - absolute value
> >>>  - multiply
> >>>  - reciprocal
> >>>  - convert to single precision
> >>>  - convert from single precision
> >>> Roland:
> >>>  - sqrt
> >>>  - comparaison (< / == / >)
> >>>  - floor/ceil
> >>> I will contact Pat Brown (His name appear in the contact field in [1])
> to
> >>> know if we need the function below for implement gpu_shader_fp64.
> >>>  - pow
> >>>  - exp
> >>>  - log
> >>>
> >>> About the license
> >>>
> >>> Like I mentioned in the project description, there are quite a few
> >>> existing C implementations of these functions.  Finding one of those
> >>> that you can understand and that has a compatible license is probably
> >>> the best place to start.
> >>>
> >>> Main Mesa code is under MIT license.
> >>> If I chose to use a GNU GPL license file like Linux kernel [3], my
> code must
> >>> be under GNU GPL and probably all the project too. Am I right?
> >>>
> >>> [1] https://www.opengl.org/registry/specs/ARB/gpu_shader_fp64.txt
> >>> [2] http://www.mesa3d.org/license.html
> >>> [3]
> >>>
> https://github.com/torvalds/linux/blob/097f70b3c4d84ffccca15195bdfde3a37c0a7c0f/arch/arm/nwfpe/softfloat.c
> >>
> >> You can't use GNU GPL for this project.
> >>
> >> The kernel as a whole is licensed under GNU GPL, but some source files
> >> aren't. The file you linked doesn't mention GNU GPL. Somebody needs to
> >> verify that the file you linked can be legally re-licensed under the
> >> MIT license. If not, I think you have to forget the contents of the
> >> file immediately, but I'm not a lawyer.
> >>
> >> Marek
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> > Most BSD style licenses are legally compatible, as long as none of the
> > developers object. One of the BSD kernels should have a softfloat
> > implementation that would be license compatible.
>
> Yes, and there are a couple C compilers that have compatible licenses.
> Portable C Compiler (PCC) being one.  LLVM might also support some
> devices that lack floating-point hardware.
>
>
> > ___
> > 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] [GSoC lib soft float] Blog update

[tournier.elie]

Hi,

After a few weeks of coding, I wrote a new post on my blog (
https://hopetech.github.io/). I speak about the progress of my project, the
difficulties encountered and the tools I use.

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

Re: [Mesa-dev] [GSoC lib soft float] Blog update

[tournier.elie]

2016-06-16 1:32 GMT+02:00 Rhys Kidd :

> On Monday, June 13, 2016, tournier.elie  wrote:
>
>> Hi,
>>
>> After a few weeks of coding, I wrote a new post on my blog (
>> https://hopetech.github.io/). I speak about the progress of my project,
>> the difficulties encountered and the tools I use.
>>
>> Happy reading,
>> Elie
>>
>
> Hello Elie,
>
> Thanks for the short write up on progress so far.
>
> Whilst not going to the technical elements, I encourage you to continue
> with your project and look forward to reviewing patches.
>
> Perhaps you could also consider how the documentation might be improved in
> the areas you found lacking?
>

I don't think that doxygen documentation is necessary like in Mesa.
Add a *.shader_test template in root/exemples/ explaining how to use
shader_runner seems a good idea to me.

>
> Rhys
>

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

Re: [Mesa-dev] [PATCH] tgsi: remove unused tgsi_is_passthrough_shader()

[tournier.elie]

On 23 May 2017 at 14:31, Samuel Pitoiset  wrote:
> Signed-off-by: Samuel Pitoiset 
Reviewed-by: Elie Tournier 

> ---
>  src/gallium/auxiliary/tgsi/tgsi_scan.c | 76 
> --
>  src/gallium/auxiliary/tgsi/tgsi_scan.h |  3 --
>  2 files changed, 79 deletions(-)
>
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c 
> b/src/gallium/auxiliary/tgsi/tgsi_scan.c
> index d1ef769ec4d..847f4fce28f 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
> @@ -891,79 +891,3 @@ tgsi_scan_arrays(const struct tgsi_token *tokens,
>
> return;
>  }
> -
> -
> -/**
> - * Check if the given shader is a "passthrough" shader consisting of only
> - * MOV instructions of the form:  MOV OUT[n], IN[n]
> - *
> - */
> -boolean
> -tgsi_is_passthrough_shader(const struct tgsi_token *tokens)
> -{
> -   struct tgsi_parse_context parse;
> -
> -   /**
> -** Setup to begin parsing input shader
> -**/
> -   if (tgsi_parse_init(&parse, tokens) != TGSI_PARSE_OK) {
> -  debug_printf("tgsi_parse_init() failed in 
> tgsi_is_passthrough_shader()!\n");
> -  return FALSE;
> -   }
> -
> -   /**
> -** Loop over incoming program tokens/instructions
> -*/
> -   while (!tgsi_parse_end_of_tokens(&parse)) {
> -
> -  tgsi_parse_token(&parse);
> -
> -  switch (parse.FullToken.Token.Type) {
> -  case TGSI_TOKEN_TYPE_INSTRUCTION:
> - {
> -struct tgsi_full_instruction *fullinst =
> -   &parse.FullToken.FullInstruction;
> -const struct tgsi_full_src_register *src =
> -   &fullinst->Src[0];
> -const struct tgsi_full_dst_register *dst =
> -   &fullinst->Dst[0];
> -
> -/* Do a whole bunch of checks for a simple move */
> -if (fullinst->Instruction.Opcode != TGSI_OPCODE_MOV ||
> -(src->Register.File != TGSI_FILE_INPUT &&
> - src->Register.File != TGSI_FILE_SYSTEM_VALUE) ||
> -dst->Register.File != TGSI_FILE_OUTPUT ||
> -src->Register.Index != dst->Register.Index ||
> -
> -src->Register.Negate ||
> -src->Register.Absolute ||
> -
> -src->Register.SwizzleX != TGSI_SWIZZLE_X ||
> -src->Register.SwizzleY != TGSI_SWIZZLE_Y ||
> -src->Register.SwizzleZ != TGSI_SWIZZLE_Z ||
> -src->Register.SwizzleW != TGSI_SWIZZLE_W ||
> -
> -dst->Register.WriteMask != TGSI_WRITEMASK_XYZW)
> -{
> -   tgsi_parse_free(&parse);
> -   return FALSE;
> -}
> - }
> - break;
> -
> -  case TGSI_TOKEN_TYPE_DECLARATION:
> - /* fall-through */
> -  case TGSI_TOKEN_TYPE_IMMEDIATE:
> - /* fall-through */
> -  case TGSI_TOKEN_TYPE_PROPERTY:
> - /* fall-through */
> -  default:
> - ; /* no-op */
> -  }
> -   }
> -
> -   tgsi_parse_free(&parse);
> -
> -   /* if we get here, it's a pass-through shader */
> -   return TRUE;
> -}
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.h 
> b/src/gallium/auxiliary/tgsi/tgsi_scan.h
> index 98387c982c6..af1651b7e82 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_scan.h
> +++ b/src/gallium/auxiliary/tgsi/tgsi_scan.h
> @@ -196,9 +196,6 @@ tgsi_scan_arrays(const struct tgsi_token *tokens,
>   unsigned max_array_id,
>   struct tgsi_array_info *arrays);
>
> -extern boolean
> -tgsi_is_passthrough_shader(const struct tgsi_token *tokens);
> -
>  #ifdef __cplusplus
>  } // extern "C"
>  #endif
> --
> 2.13.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] soft fp64 on evergreen

[tournier.elie]

Hi,

First of all sorry for the mess in my repo. ;)

On 26 May 2017 at 11:16, Thomas Helland  wrote:
> 2017-05-26 8:13 GMT+02:00 Dave Airlie :
>> Hi Elie,
>>
>> Thanks for the fp64 work.
>>
>> I've pulled the latest branch from your repo and start running piglit
>> on a BARTS (r600g) GPU.
>>
>> I've noticed a few asserts with a debug build in ir_validate, do you
>> test with --enable-debug?
I run the test on my laptop using softpipe. But aboll sent me the test
he run on an r600g.
>>
>> I also notice some really large times in the GLSL->TGSI pass copy
>> propogation on mul/div tests with matrices, tests take a fair while to
>> complete.
>>
>
> Unrelated to this I have noticed on some profiles when using nvc0
> that the GLSL->TGSI passes are quite painful on compile times.
> Especially copy propagation shows up as a big one.
> Not sure if there is some easy gains to be had here as I haven't
> looked at the pass at all.
The GLSL->TGSI passes is probably slow too but I'm quite sure that my
code doesn't help...
>
>> Just wondering if you've seen anything like this?
Yes, I saw 5 different assert. All on matrices tests.
I'm trying to figure out what's wrong with that.
mul/add double works correctly so we should be able to compute
matrices. But it's not the case. :(

>>
>> Dave.
>> ___
>> 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] i965: fix missing break

[tournier.elie]

Reviewed by: Elie Tournier 

On 12 June 2017 at 10:37, Lionel Landwerlin
 wrote:
> Pretty obvious missing break statement.
>
> CID: 1412564
> Fixes: 641405f797 "i965: Use the new tracking mechanism for HiZ"
> Signed-off-by: Lionel Landwerlin 
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index eda8a0afab5..bd816816a53 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -2300,6 +2300,7 @@ intel_miptree_finish_hiz_write(struct brw_context *brw,
>   intel_miptree_set_aux_state(brw, mt, level, layer, 1,
>   ISL_AUX_STATE_AUX_INVALID);
>}
> +  break;
>
> case ISL_AUX_STATE_PASS_THROUGH:
>if (written_with_hiz) {
> --
> 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
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/5] nir: implement GLSL.std.450 NMax operation

[tournier.elie]

On 12 June 2017 at 17:33, Juan A. Suarez Romero  wrote:
> ---
>  src/compiler/spirv/vtn_glsl450.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/src/compiler/spirv/vtn_glsl450.c 
> b/src/compiler/spirv/vtn_glsl450.c
> index 5e75c3c..ce80360 100644
> --- a/src/compiler/spirv/vtn_glsl450.c
> +++ b/src/compiler/spirv/vtn_glsl450.c
> @@ -225,6 +225,25 @@ build_nmin(nir_builder *b, nir_ssa_def *x, nir_ssa_def 
> *y)
>  }
>
>  /**
> + * Returns
> + *  if (isNan(x))
> + *return y
> + *  else if (isNan(y))
> + *return x
> + *  else
> + *return min(x, y)
Little typo here. Should be max(x,y)

> + */
> +static nir_ssa_def *
> +build_nmax(nir_builder *b, nir_ssa_def *x, nir_ssa_def *y)
> +{
> +   return nir_bcsel(b, nir_fne(b, x, x),
> +y,
> +nir_bcsel(b, nir_fne(b, y, y),
> +  x,
> +  nir_fmax(b, x, y)));
> +}
> +
> +/**
>   * Approximate asin(x) by the formula:
>   *asin~(x) = sign(x) * (pi/2 - sqrt(1 - |x|) * (pi/2 + |x|(pi/4 - 1 + 
> |x|(p0 + |x|p1
>   *
> @@ -555,6 +574,10 @@ handle_glsl450_alu(struct vtn_builder *b, enum 
> GLSLstd450 entrypoint,
>val->ssa->def = build_nmin(nb, src[0], src[1]);
>return;
>
> +   case GLSLstd450NMax:
> +  val->ssa->def = build_nmax(nb, src[0], src[1]);
> +  return;
> +
> case GLSLstd450Log:
>val->ssa->def = build_log(nb, src[0]);
>return;
> --
> 2.9.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 0/5] Add new SPIR-V functions in NIR

[tournier.elie]

This series is:
Reviewed by: Elie Tournier 

On 12 June 2017 at 17:33, Juan A. Suarez Romero  wrote:
> This short series of 5 patches extend a couple of functions SPIR-V functions 
> to
> support 64-bit, as well as it adds new functions defined in GLSL.450.std.
>
> The first 2 commits add support for 64-bit float-point types in Step() and
> SmoothStep().
>
> The latest 3 commits implement GLSL.std.450 NMin(), NMax() and NClamp() SPIR-V
> instructions.
>
>
> Juan A. Suarez Romero (5):
>   nir: sge operation is defined for floating-point types
>   nir: add support for 64-bit in SmoothStep function
>   nir: implement GLSL.std.450 NMin operation
>   nir: implement GLSL.std.450 NMax operation
>   nir: implement GLSL.std.450 NClamp operation
>
>  src/compiler/nir/nir_opcodes.py  |  2 +-
>  src/compiler/spirv/vtn_glsl450.c | 58 
> +---
>  2 files changed, 56 insertions(+), 4 deletions(-)
>
> --
> 2.9.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] [RFC 00/10] WIP: NIR soft fp64 for ARB_gpu_shader_fp64 on gen6

[tournier.elie]

Hi list,

I'm still interested by a review or some comments/ideas to help me
land this series.
I'm trying to figure out why mul/div and add/sub fail the piglit test.
I already investigated about using "nir_ushr" instead of "nir_ishr". I
also checked if the "nir_bcsel" were done correctly. Without success.

Two sets of eyes and ears are better than one. ;)

Thx


On 12 April 2017 at 23:43, Elie Tournier  wrote:
> I've got this series on my laptop for too long so I send it even if it's 
> still in progress.
> The goal of this work is to enable ARB_gpu_shader_fp64 on gen6.
> Most of the algorithms come from "Berkeley SoftFloat" [1].
> You can find a branch on my github [2].
>
> So far we have:
> Patches 1-5 seems to do the job correctly.
> Patches 6-9 fail the Piglit tests but we handle zero, inf and NaN with 
> success.
> Some tests pass if I increase the tolerance.
>
> All comments and suggestions are very welcome.
>
> [1] http://www.jhauser.us/arithmetic/SoftFloat.html
> [2] https://github.com/Hopetech/mesa/tree/nir_arb_gpu_shader_fp64
>
> Elie Tournier (10):
>   nir/lower_double_ops: lower abs()
>   nir/lower_double_ops: lower neg()
>   nir/lower_double_ops: lower sign()
>   nir/lower_double_ops: lower eq()
>   nir/lower_double_ops: lower lt()
>   nir/lower_double_ops: lower mul()
>   nir/lower_double_ops: lower div()
>   nir/lower_double_ops: lower add()
>   nir/lower_double_ops: lower sub()
>   mesa: enable ARB_gpu_shader_fp64 on Gen6
>
>  src/compiler/nir/nir.h   |   11 +-
>  src/compiler/nir/nir_lower_double_ops.c  | 1713 
> ++
>  src/intel/compiler/brw_nir.c |   11 +-
>  src/mesa/drivers/dri/i965/intel_extensions.c |1 +
>  4 files changed, 1734 insertions(+), 2 deletions(-)
>
> --
> 2.11.0
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3 v2] r600g: get rid of dummy pixel shader

[tournier.elie]

Hello,

I'm not an r600g person but I will be pleased to have a look to this work.
I'm currently working on the fp64 for r600g. Hope to be able to send a
series in fews days.
The fp64 code is not HW specific, I can test it on my laptop with an
Intel card. I don't even own a r600g card.

Have a nice day.

On 25 April 2017 at 03:00, Dieter Nützel  wrote:
> Am 12.04.2017 22:06, schrieb Dave Airlie:
>>
>> On 13 April 2017 at 06:03, Markus Trippelsdorf 
>> wrote:
>>>
>>> On 2017.04.12 at 20:45 +0100, Emil Velikov wrote:

 On 12 April 2017 at 20:34, Constantine Kharlamov 
 wrote:

 >> I suspect this breaks because r600 more often fails to
 >> compile some shaders,
 >> and the hw requires a fragment shader and we use the empty one as a
 >> fallback in that case.
 >
 > Ok, that wasn't obvious, I running the system with the patchset on
 > HD5730, including
 > piglit testing — so far is fine.
 >
 If in doubt ask the bug reporter(s) to test a patch on their machines.
>>>
>>>
>>> Well, the question is why bother with this legacy code at all?
>>> I would expect a much more conservative approach. Except for essential
>>> patches to keep the hardware running, everything else should be
>>> rejected. Nobody is expecting new features for this ancient hardware
>>> anyway.
>>
>>
>> I do have 90% of GL4.3 for evergreen and newer done in a branch,
>>
>> It's just a lack of time to fix the last few hangs and motivate myself
>> to get it posted/reviewied.
>>
>> Then of course getting sb support.
>>
>> Dave.
>
>
> Hello Dave,
>
> can you please send the link to your latest work on this?
> So someone (we) can have a look and learn/maybe fix it.
> Maybe Elie step in and offer fp64 for r600g if he has some time left.
> My times on r600g come to an end...
> RX 580, 8 GB, Nitro+ is coming on Friday/Saturday, Yea ;-)
>
> Then I have to decide if I hold the Turks XT (6670) or to comp it.
>
> Greetings around the world!
>
> Dieter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3 v2] r600g: get rid of dummy pixel shader

[tournier.elie]

On 8 May 2017 at 00:25, Dieter Nützel  wrote:
> Am 26.04.2017 14:37, schrieb tournier.elie:
>>
>> Hello,
>>
>> I'm not an r600g person but I will be pleased to have a look to this work.
>
>
> Hello Elie,
>
> I know, read most of your posts about your 'former' fp64 lib which was
> indeed HW-agnostic.
>
>> I'm currently working on the fp64 for r600g. Hope to be able to send a
>> series in fews days.
>
>
> Do you have something handy for testing?
> My r600g (Turks XT / HD 6670) times run out... ;-)
> https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/950505-radeon-rx-550-amdgpu-pro-vs-drm-next-mesa-17-2-dev?p=950577#post950577
>

I can use LLVM pipe / softpipe to test the code.
Moreover, Andreas Boll helps me to test the code. He own a r600g card.

>> The fp64 code is not HW specific, I can test it on my laptop with an
>> Intel card. I don't even own a r600g card.
>
>
> Do you want my above card for testing r600g?

Thanks you for the offer but I don't have a tower here.

>
>> Have a nice day.
>
>
> Have a nice spring, late here in old (northern) Europe...
>

I'm not sure there are a spring or summer here in Cambridge, UK. ;-)

Elie

> Dieter
>
>
>> On 25 April 2017 at 03:00, Dieter Nützel  wrote:
>>>
>>> Am 12.04.2017 22:06, schrieb Dave Airlie:
>>>>
>>>>
>>>> On 13 April 2017 at 06:03, Markus Trippelsdorf 
>>>> wrote:
>>>>>
>>>>>
>>>>> On 2017.04.12 at 20:45 +0100, Emil Velikov wrote:
>>>>>>
>>>>>>
>>>>>> On 12 April 2017 at 20:34, Constantine Kharlamov 
>>>>>> wrote:
>>>>>>
>>>>>> >> I suspect this breaks because r600 more often fails to
>>>>>> >> compile some shaders,
>>>>>> >> and the hw requires a fragment shader and we use the empty one as a
>>>>>> >> fallback in that case.
>>>>>> >
>>>>>> > Ok, that wasn't obvious, I running the system with the patchset on
>>>>>> > HD5730, including
>>>>>> > piglit testing — so far is fine.
>>>>>> >
>>>>>> If in doubt ask the bug reporter(s) to test a patch on their machines.
>>>>>
>>>>>
>>>>>
>>>>> Well, the question is why bother with this legacy code at all?
>>>>> I would expect a much more conservative approach. Except for essential
>>>>> patches to keep the hardware running, everything else should be
>>>>> rejected. Nobody is expecting new features for this ancient hardware
>>>>> anyway.
>>>>
>>>>
>>>>
>>>> I do have 90% of GL4.3 for evergreen and newer done in a branch,
>>>>
>>>> It's just a lack of time to fix the last few hangs and motivate myself
>>>> to get it posted/reviewied.
>>>>
>>>> Then of course getting sb support.
>>>>
>>>> Dave.
>>>
>>>
>>>
>>> Hello Dave,
>>>
>>> can you please send the link to your latest work on this?
>>> So someone (we) can have a look and learn/maybe fix it.
>>> Maybe Elie step in and offer fp64 for r600g if he has some time left.
>>> My times on r600g come to an end...
>>> RX 580, 8 GB, Nitro+ is coming on Friday/Saturday, Yea ;-)
>>>
>>> Then I have to decide if I hold the Turks XT (6670) or to comp it.
>>>
>>> Greetings around the world!
>>>
>>> Dieter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: remove never used gl_shader_compiler_options::EmitNoFunctions

[tournier.elie]

On 8 May 2017 at 21:54, Samuel Pitoiset  wrote:
> Signed-off-by: Samuel Pitoiset 

Reviewed-by: Elie Tournier 
> ---
>  src/mesa/main/mtypes.h | 1 -
>  src/mesa/state_tracker/st_extensions.c | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 2500e5fee3..03b9baa95e 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3053,7 +3053,6 @@ struct gl_shader_compiler_options
>  {
> /** Driver-selectable options: */
> GLboolean EmitNoLoops;
> -   GLboolean EmitNoFunctions;
> GLboolean EmitNoCont;  /**< Emit CONT opcode? */
> GLboolean EmitNoMainReturn;/**< Emit CONT/RET opcodes? */
> GLboolean EmitNoPow;   /**< Emit POW opcodes? */
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index 440e071329..bda7ee1057 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -270,7 +270,6 @@ void st_init_limits(struct pipe_screen *screen,
>options->EmitNoLoops =
>   !screen->get_shader_param(screen, sh,
> PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH);
> -  options->EmitNoFunctions = true;
>options->EmitNoMainReturn =
>   !screen->get_shader_param(screen, sh, PIPE_SHADER_CAP_SUBROUTINES);
>
> --
> 2.12.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/4] mesa: fix indentation in _mesa_associate_uniform_storage()

[tournier.elie]

Hello Samuel,

With the small fix below, the series is:
Reviewed-by: Elie Tournier 


On 15 May 2017 at 11:55, Samuel Pitoiset  wrote:
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/mesa/program/ir_to_mesa.cpp | 101 
> +++-
>  1 file changed, 49 insertions(+), 52 deletions(-)
>
> diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
> index 05b042b4e9..0e8623c3f3 100644
> --- a/src/mesa/program/ir_to_mesa.cpp
> +++ b/src/mesa/program/ir_to_mesa.cpp
> @@ -2534,7 +2534,7 @@ _mesa_generate_parameters_list_for_uniforms(struct 
> gl_shader_program
>
>  void
>  _mesa_associate_uniform_storage(struct gl_context *ctx,
> -   struct gl_shader_program *shader_program,
> +struct gl_shader_program *shader_program,
>  struct gl_program_parameter_list *params,
>  bool propagate_to_storage)
>  {
> @@ -2545,15 +2545,15 @@ _mesa_associate_uniform_storage(struct gl_context 
> *ctx,
> unsigned last_location = unsigned(~0);
> for (unsigned i = 0; i < params->NumParameters; i++) {
>if (params->Parameters[i].Type != PROGRAM_UNIFORM)
> -continue;
> + continue;
>
>unsigned location;
>const bool found =
> -shader_program->UniformHash->get(location, 
> params->Parameters[i].Name);
> + shader_program->UniformHash->get(location, 
> params->Parameters[i].Name);
>assert(found);
>
>if (!found)
> -continue;
> + continue;
>
>struct gl_uniform_storage *storage =
>   &shader_program->data->UniformStorage[location];
> @@ -2563,48 +2563,47 @@ _mesa_associate_uniform_storage(struct gl_context 
> *ctx,
>   continue;
>
>if (location != last_location) {
> -enum gl_uniform_driver_format format = uniform_native;
> + enum gl_uniform_driver_format format = uniform_native;
> + unsigned columns = 0;
> + int dmul = 4 * sizeof(float);
>
> -unsigned columns = 0;
> -int dmul = 4 * sizeof(float);
> -switch (storage->type->base_type) {
> + switch (storage->type->base_type) {
>   case GLSL_TYPE_UINT64:
> -   if (storage->type->vector_elements > 2)
> +if (storage->type->vector_elements > 2)
> dmul *= 2;
> -   /* fallthrough */
> -case GLSL_TYPE_UINT:
> -   assert(ctx->Const.NativeIntegers);
> -   format = uniform_native;
> -   columns = 1;
> -   break;
> +/* fallthrough */
> + case GLSL_TYPE_UINT:
> +assert(ctx->Const.NativeIntegers);
> +format = uniform_native;
> +columns = 1;
> +break;
>   case GLSL_TYPE_INT64:
> -   if (storage->type->vector_elements > 2)
> +if (storage->type->vector_elements > 2)
> dmul *= 2;
> -   /* fallthrough */
> -case GLSL_TYPE_INT:
> -   format =
> -  (ctx->Const.NativeIntegers) ? uniform_native : 
> uniform_int_float;
> -   columns = 1;
> -   break;
> -
> -case GLSL_TYPE_DOUBLE:
> -   if (storage->type->vector_elements > 2)
> +/* fallthrough */
> + case GLSL_TYPE_INT:
> +format =
> +   (ctx->Const.NativeIntegers) ? uniform_native : 
> uniform_int_float;
> +columns = 1;
> +break;
> + case GLSL_TYPE_DOUBLE:
> +if (storage->type->vector_elements > 2)
> dmul *= 2;
> -   /* fallthrough */
> -case GLSL_TYPE_FLOAT:
> -   format = uniform_native;
> -   columns = storage->type->matrix_columns;
> -   break;
> -case GLSL_TYPE_BOOL:
> -   format = uniform_native;
> -   columns = 1;
> -   break;
> -case GLSL_TYPE_SAMPLER:
> -case GLSL_TYPE_IMAGE:
> +/* fallthrough */
> + case GLSL_TYPE_FLOAT:
> +format = uniform_native;
> +columns = storage->type->matrix_columns;
> +break;
> + case GLSL_TYPE_BOOL:
> +format = uniform_native;
> +columns = 1;
> +break;
> + case GLSL_TYPE_SAMPLER:
> + case GLSL_TYPE_IMAGE:
>   case GLSL_TYPE_SUBROUTINE:
> -   format = uniform_native;
> -   columns = 1;
> -   break;
> +format = uniform_native;
> +columns = 1;
> +break;
>   case GLSL_TYPE_ATOMIC_UINT:
>   case GLSL_TYPE_ARRAY:
>   case GLSL_TYPE_VOID:
> @@ -2612,27 +2611,25 @@ _mesa_associate_uniform_storage(struct gl_context 
> *ctx,
>   case GLSL_TYPE_ERROR:
>   case GLSL_TYPE_INTERFACE:
>   case GLSL_TYPE_FUNCTION:
> -   assert(!"Should not get here.");
> -   break;
> -}
> +as

Re: [Mesa-dev] [PATCH v2 3/3] nir: implement GLSL.std.450 NMax, NMIn and NClamp operations

[tournier.elie]

On 26 June 2017 at 11:15, Juan A. Suarez Romero  wrote:
> On Tue, 2017-06-13 at 11:14 +0200, Juan A. Suarez Romero wrote:
>> v2: NIR fmax/fmin already handles NaN (Connor).
>> ---
>
> Implemented the functions using fmax/fmin.
>
> Could you review it? Thank you!

Sorry, I missed this one.
Reviewed by: Elie Tournier 
>
>
> J.A.
>
>>  src/compiler/spirv/vtn_glsl450.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/src/compiler/spirv/vtn_glsl450.c 
>> b/src/compiler/spirv/vtn_glsl450.c
>> index 96e3407dee..1d7e2b8d95 100644
>> --- a/src/compiler/spirv/vtn_glsl450.c
>> +++ b/src/compiler/spirv/vtn_glsl450.c
>> @@ -433,9 +433,11 @@ vtn_nir_alu_op_for_spirv_glsl_opcode(enum GLSLstd450 
>> opcode)
>> case GLSLstd450Log2:  return nir_op_flog2;
>> case GLSLstd450Sqrt:  return nir_op_fsqrt;
>> case GLSLstd450InverseSqrt:   return nir_op_frsq;
>> +   case GLSLstd450NMin:  return nir_op_fmin;
>> case GLSLstd450FMin:  return nir_op_fmin;
>> case GLSLstd450UMin:  return nir_op_umin;
>> case GLSLstd450SMin:  return nir_op_imin;
>> +   case GLSLstd450NMax:  return nir_op_fmax;
>> case GLSLstd450FMax:  return nir_op_fmax;
>> case GLSLstd450UMax:  return nir_op_umax;
>> case GLSLstd450SMax:  return nir_op_imax;
>> @@ -537,6 +539,7 @@ handle_glsl450_alu(struct vtn_builder *b, enum 
>> GLSLstd450 entrypoint,
>>return;
>>
>> case GLSLstd450FClamp:
>> +   case GLSLstd450NClamp:
>>val->ssa->def = build_fclamp(nb, src[0], src[1], src[2]);
>>return;
>> case GLSLstd450UClamp:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: fix typo in isl

[tournier.elie]

On 12 October 2017 at 17:12, Dylan Baker  wrote:
> For list posterity, since my intel mail isn't subscribed to the list...
>
> Reviewed-by: Dylan Baker 

Ack.
Feel free to push this patch for me. (I don't have git access)
>
> Quoting Elie Tournier (2017-10-12 04:24:10)
>> Signed-off-by: Elie Tournier 
>> ---
>>  src/intel/isl/meson.build | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/intel/isl/meson.build b/src/intel/isl/meson.build
>> index 789175e256..54024b4d11 100644
>> --- a/src/intel/isl/meson.build
>> +++ b/src/intel/isl/meson.build
>> @@ -101,5 +101,5 @@ if with_tests
>>  build_by_default : false,
>>)
>>
>> -  test('isl_surf_get_imaage_offset', isl_surf_get_image_offset_test)
>> +  test('isl_surf_get_image_offset', isl_surf_get_image_offset_test)
>>  endif
>> --
>> 2.14.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] glsl: there is no need to check for < 0

[tournier.elie]

Reviewed-by: Elie Tournier 

2017-01-20 23:20 GMT+01:00 Christian Gmeiner :

> size_t is defined in the C Standard section 4.1.5 as an
> 'unsigned integral type'.
>
> Fixes the following clang compile warning:
>
> glsl/blob.c:110:15: warning: comparison of unsigned expression < 0 is
> always false [-Wtautological-compare]
>if (offset < 0 || blob->size - offset < to_write)
>~~ ^ ~
>
> Signed-off-by: Christian Gmeiner 
> ---
>  src/compiler/glsl/blob.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/glsl/blob.c b/src/compiler/glsl/blob.c
> index dd4341b..ef17255 100644
> --- a/src/compiler/glsl/blob.c
> +++ b/src/compiler/glsl/blob.c
> @@ -107,7 +107,7 @@ blob_overwrite_bytes(struct blob *blob,
>   size_t to_write)
>  {
> /* Detect an attempt to overwrite data out of bounds. */
> -   if (offset < 0 || blob->size - offset < to_write)
> +   if (blob->size - offset < to_write)
>return false;
>
> memcpy(blob->data + offset, bytes, to_write);
> --
> 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/8] nir/i965: add before ffma algebraic opts

[tournier.elie]

On 18 April 2017 at 06:52, Timothy Arceri  wrote:
> From: Timothy Arceri 
>
> This shuffles constants down in the reverse of what the previous
> patch does and applies some simpilifications that may be made
> possible from doing so.
>
> Shader-db results BDW:
>
> total instructions in shared programs: 12980814 -> 12977822 (-0.02%)
> instructions in affected programs: 281889 -> 278897 (-1.06%)
> helped: 1231
> HURT: 128
>
> total cycles in shared programs: 246562852 -> 246567288 (0.00%)
> cycles in affected programs: 11271524 -> 11275960 (0.04%)
> helped: 1630
> HURT: 1378
>
> V2: mark float opts as inexact

Patches 1-3 are:
Reviewed-by: Elie Tournier 

> ---
>  src/compiler/nir/nir.h|  1 +
>  src/compiler/nir/nir_opt_algebraic.py | 23 +++
>  src/intel/compiler/brw_nir.c  |  6 ++
>  3 files changed, 30 insertions(+)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index ce5b434..dbbf268 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2591,20 +2591,21 @@ void nir_convert_loop_to_lcssa(nir_loop *loop);
>  /* If phi_webs_only is true, only convert SSA values involved in phi nodes to
>   * registers.  If false, convert all values (even those not involved in a phi
>   * node) to registers.
>   */
>  bool nir_convert_from_ssa(nir_shader *shader, bool phi_webs_only);
>
>  bool nir_lower_phis_to_regs_block(nir_block *block);
>  bool nir_lower_ssa_defs_to_regs_block(nir_block *block);
>
>  bool nir_opt_algebraic(nir_shader *shader);
> +bool nir_opt_algebraic_before_ffma(nir_shader *shader);
>  bool nir_opt_algebraic_late(nir_shader *shader);
>  bool nir_opt_constant_folding(nir_shader *shader);
>
>  bool nir_opt_global_to_local(nir_shader *shader);
>
>  bool nir_copy_prop(nir_shader *shader);
>
>  bool nir_opt_copy_prop_vars(nir_shader *shader);
>
>  bool nir_opt_cse(nir_shader *shader);
> diff --git a/src/compiler/nir/nir_opt_algebraic.py 
> b/src/compiler/nir/nir_opt_algebraic.py
> index 974345a..fe6e33d 100644
> --- a/src/compiler/nir/nir_opt_algebraic.py
> +++ b/src/compiler/nir/nir_opt_algebraic.py
> @@ -523,20 +523,41 @@ for op in ['flt', 'fge', 'feq']:
>  # left with just the original variable "a".
>  for op in ['flt', 'fge', 'feq', 'fne',
> 'ilt', 'ige', 'ieq', 'ine', 'ult', 'uge']:
> optimizations += [
>((op, ('bcsel', 'a', '#b', '#c'), '#d'),
> ('bcsel', 'a', (op, 'b', 'd'), (op, 'c', 'd'))),
>((op, '#d', ('bcsel', a, '#b', '#c')),
> ('bcsel', 'a', (op, 'd', 'b'), (op, 'd', 'c'))),
> ]
>
> +# This section contains "late" optimizations that should be run before
> +# creating ffmas and calling regular optimizations for the final time.
> +# Optimizations should go here if they help code generation and conflict
> +# with the regular optimizations.
> +before_ffma_optimizations = [
> +   # Propagate constants down multiplication chains
> +   (('~fmul(is_used_once)', ('fmul(is_used_once)', 'a(is_not_const)', '#b'), 
> 'c(is_not_const)'), ('fmul', ('fmul', a, c), b)),
> +   (('imul(is_used_once)', ('imul(is_used_once)', 'a(is_not_const)', '#b'), 
> 'c(is_not_const)'), ('imul', ('imul', a, c), b)),
> +   (('~fadd(is_used_once)', ('fadd(is_used_once)', 'a(is_not_const)', '#b'), 
> 'c(is_not_const)'), ('fadd', ('fadd', a, c), b)),
> +   (('iadd(is_used_once)', ('iadd(is_used_once)', 'a(is_not_const)', '#b'), 
> 'c(is_not_const)'), ('iadd', ('iadd', a, c), b)),
> +
> +   (('~fadd', ('fmul', a, b), ('fmul', a, c)), ('fmul', a, ('fadd', b, c))),
> +   (('iadd', ('imul', a, b), ('imul', a, c)), ('imul', a, ('iadd', b, c))),
> +   (('~fadd', ('fneg', a), a), 0.0),
> +   (('iadd', ('ineg', a), a), 0),
> +   (('iadd', ('ineg', a), ('iadd', a, b)), b),
> +   (('iadd', a, ('iadd', ('ineg', a), b)), b),
> +   (('~fadd', ('fneg', a), ('fadd', a, b)), b),
> +   (('~fadd', a, ('fadd', ('fneg', a), b)), b),
> +]
> +
>  # This section contains "late" optimizations that should be run after the
>  # regular optimizations have finished.  Optimizations should go here if
>  # they help code generation but do not necessarily produce code that is
>  # more easily optimizable.
>  late_optimizations = [
> # Most of these optimizations aren't quite safe when you get infinity or
> # Nan involved but the first one should be fine.
> (('flt', ('fadd', a, b), 0.0), ('flt', a, ('fneg', b))),
> (('~fge', ('fadd', a, b), 0.0), ('fge', a, ('fneg', b))),
> (('~feq', ('fadd', a, b), 0.0), ('feq', a, ('fneg', b))),
> @@ -549,12 +570,14 @@ late_optimizations = [
>
> (('b2f(is_used_more_than_once)', ('inot', a)), ('bcsel', a, 0.0, 1.0)),
> (('fneg(is_used_more_than_once)', ('b2f', ('inot', a))), ('bcsel', a, 
> -0.0, -1.0)),
>
> # we do these late so that we don't get in the way of creating ffmas
> (('fmin', ('fadd(is_used_once)', '#c', a), ('fadd(is_used_once)', '#c', 
> b)), ('fadd', c, ('fmin', a, b))),
> (('fmax', ('fadd(is_used_once)', '#c', a), ('fadd(is_used_once)', 

Re: [Mesa-dev] [PATCH 8/8] i965: remove now unused GLSL IR optimisations

[tournier.elie]

On 18 April 2017 at 06:52, Timothy Arceri  wrote:
> These are no longer used since the previous commit.

Patches 4 - 8 are:
Acked-by: Elie Tournier 

> ---
>  src/mesa/drivers/dri/i965/Makefile.sources |   2 -
>  .../dri/i965/brw_fs_channel_expressions.cpp| 483 
> -
>  .../drivers/dri/i965/brw_fs_vector_splitting.cpp   | 400 -
>  src/mesa/drivers/dri/i965/brw_program.h|   3 -
>  4 files changed, 888 deletions(-)
>  delete mode 100644 src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp
>  delete mode 100644 src/mesa/drivers/dri/i965/brw_fs_vector_splitting.cpp
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index 02dbb55..aef1a7a 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -21,22 +21,20 @@ i965_FILES = \
> brw_cs.c \
> brw_cs.h \
> brw_curbe.c \
> brw_defines.h \
> brw_draw.c \
> brw_draw.h \
> brw_draw_upload.c \
> brw_ff_gs.c \
> brw_ff_gs_emit.c \
> brw_ff_gs.h \
> -   brw_fs_channel_expressions.cpp \
> -   brw_fs_vector_splitting.cpp \
> brw_formatquery.c \
> brw_gs.c \
> brw_gs.h \
> brw_gs_state.c \
> brw_gs_surface_state.c \
> brw_link.cpp \
> brw_meta_util.c \
> brw_meta_util.h \
> brw_misc_state.c \
> brw_multisample_state.h \
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp
> deleted file mode 100644
> index 58fa207..000
> --- a/src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp
> +++ /dev/null
> @@ -1,483 +0,0 @@
> -/*
> - * Copyright © 2010 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.
> - */
> -
> -/**
> - * \file brw_wm_channel_expressions.cpp
> - *
> - * Breaks vector operations down into operations on each component.
> - *
> - * The 965 fragment shader receives 8 or 16 pixels at a time, so each
> - * channel of a vector is laid out as 1 or 2 8-float registers.  Each
> - * ALU operation operates on one of those channel registers.  As a
> - * result, there is no value to the 965 fragment shader in tracking
> - * "vector" expressions in the sense of GLSL fragment shaders, when
> - * doing a channel at a time may help in constant folding, algebraic
> - * simplification, and reducing the liveness of channel registers.
> - *
> - * The exception to the desire to break everything down to floats is
> - * texturing.  The texture sampler returns a writemasked masked
> - * 4/8-register sequence containing the texture values.  We don't want
> - * to dispatch to the sampler separately for each channel we need, so
> - * we do retain the vector types in that case.
> - */
> -
> -#include "brw_program.h"
> -#include "compiler/glsl/ir.h"
> -#include "compiler/glsl/ir_expression_flattening.h"
> -#include "compiler/glsl_types.h"
> -
> -class ir_channel_expressions_visitor : public ir_hierarchical_visitor {
> -public:
> -   ir_channel_expressions_visitor()
> -   {
> -  this->progress = false;
> -  this->mem_ctx = NULL;
> -   }
> -
> -   ir_visitor_status visit_leave(ir_assignment *);
> -
> -   ir_rvalue *get_element(ir_variable *var, unsigned int element);
> -   void assign(ir_assignment *ir, int elem, ir_rvalue *val);
> -
> -   bool progress;
> -   void *mem_ctx;
> -};
> -
> -static bool
> -channel_expressions_predicate(ir_instruction *ir)
> -{
> -   ir_expression *expr = ir->as_expression();
> -   unsigned int i;
> -
> -   if (!expr)
> -  return false;
> -
> -   switch (expr->operation) {
> -  case ir_unop_pack_half_2x16:
> -  case ir_unop_pack_snorm_2x16:
> -  case ir_unop_pack_snorm_4x8:
> -  case ir_unop_pack

Re: [Mesa-dev] [RFC 02/11] glsl: Add "built-in" function to do neg(fp64)

[tournier.elie]

On 3 March 2017 at 16:29, Ilia Mirkin  wrote:
> On Fri, Mar 3, 2017 at 11:22 AM, Elie Tournier  
> wrote:
>> Signed-off-by: Elie Tournier 
>> ---
>>  src/compiler/glsl/builtin_float64.h | 19 +++
>>  src/compiler/glsl/builtin_functions.cpp |  4 
>>  src/compiler/glsl/builtin_functions.h   |  3 +++
>>  src/compiler/glsl/float64.glsl  | 10 ++
>>  4 files changed, 36 insertions(+)
>>
>> diff --git a/src/compiler/glsl/builtin_float64.h 
>> b/src/compiler/glsl/builtin_float64.h
>> index c1ec89d210..6df91e10f5 100644
>> --- a/src/compiler/glsl/builtin_float64.h
>> +++ b/src/compiler/glsl/builtin_float64.h
>> @@ -17,3 +17,22 @@ fabs64(void *mem_ctx, builtin_available_predicate avail)
>> sig->replace_parameters(&sig_parameters);
>> return sig;
>>  }
>> +ir_function_signature *
>> +fneg64(void *mem_ctx, builtin_available_predicate avail)
>> +{
>> +   ir_function_signature *const sig =
>> +  new(mem_ctx) ir_function_signature(glsl_type::uvec2_type, avail);
>> +   ir_factory body(&sig->body, mem_ctx);
>> +   sig->is_defined = true;
>> +
>> +   exec_list sig_parameters;
>> +
>> +   ir_variable *const r000C = new(mem_ctx) 
>> ir_variable(glsl_type::uvec2_type, "a", ir_var_function_in);
>> +   sig_parameters.push_tail(r000C);
>> +   body.emit(assign(r000C, bit_xor(swizzle_x(r000C), 
>> body.constant(2147483648u)), 0x01));
>> +
>> +   body.emit(ret(r000C));
>> +
>> +   sig->replace_parameters(&sig_parameters);
>> +   return sig;
>> +}
>> diff --git a/src/compiler/glsl/builtin_functions.cpp 
>> b/src/compiler/glsl/builtin_functions.cpp
>> index b0b1781725..a189b84190 100644
>> --- a/src/compiler/glsl/builtin_functions.cpp
>> +++ b/src/compiler/glsl/builtin_functions.cpp
>> @@ -3133,6 +3133,10 @@ builtin_builder::create_builtins()
>>  generate_ir::fabs64(mem_ctx, integer_functions_supported),
>>  NULL);
>>
>> +   add_function("__builtin_fneg64",
>> +generate_ir::fneg64(mem_ctx, integer_functions_supported),
>> +NULL);
>> +
>>  #undef F
>>  #undef FI
>>  #undef FIUD_VEC
>> diff --git a/src/compiler/glsl/builtin_functions.h 
>> b/src/compiler/glsl/builtin_functions.h
>> index abe02d97b6..37c6cc33c2 100644
>> --- a/src/compiler/glsl/builtin_functions.h
>> +++ b/src/compiler/glsl/builtin_functions.h
>> @@ -66,6 +66,9 @@ sign64(void *mem_ctx, builtin_available_predicate avail);
>>  ir_function_signature *
>>  fabs64(void *mem_ctx, builtin_available_predicate avail);
>>
>> +ir_function_signature *
>> +fneg64(void *mem_ctx, builtin_available_predicate avail);
>> +
>>  }
>>
>>  #endif /* BULITIN_FUNCTIONS_H */
>> diff --git a/src/compiler/glsl/float64.glsl b/src/compiler/glsl/float64.glsl
>> index b8f0c2e444..82875e9407 100644
>> --- a/src/compiler/glsl/float64.glsl
>> +++ b/src/compiler/glsl/float64.glsl
>> @@ -26,3 +26,13 @@ fabs64( uvec2 a )
>>  a.x &= 0x7FFFu;
>>  return a;
>>  }
>> +
>> +/* Negate value of a Float64 :
>> + * Toggle the sign bit
>> + */
>> +uvec2
>> +fneg64( uvec2 a )
>> +{
>> +a.x ^= (1u<<31);
>
> Is this right for NaN? Presumably neg(NaN) should == NaN.

The IEEE 754 standard say :

" 6.3 The sign bit

When either an input or result is NaN, this standard does not
interpret the sign of a NaN. Note, however,
that operations on bit strings copy, negate, abs, copySign specify the
sign bit of a NaN result,
sometimes based upon the sign bit of a NaN operand. The logical
predicate totalOrder is also affected by
the sign bit of a NaN operand. For all other operations, this standard
does not specify the sign bit of a NaN
result, even when there is only one input NaN, or when the NaN is
produced from an invalid operation. "

So neg(NaN) == NaN

>
>> +return a;
>> +}
>> --
>> 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
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 07/11] glsl: Add "built-in" functions to do mul(fp64, fp64)

[tournier.elie]

On 3 March 2017 at 17:46, Eric Engestrom  wrote:
> On Friday, 2017-03-03 16:23:03 +, Elie Tournier wrote:
>> Signed-off-by: Elie Tournier 
>> ---
>>  src/compiler/glsl/builtin_float64.h | 2558 
>> +++
>>  src/compiler/glsl/builtin_functions.cpp |4 +
>>  src/compiler/glsl/builtin_functions.h   |3 +
>>  src/compiler/glsl/float64.glsl  |  172 +++
>>  4 files changed, 2737 insertions(+)
>>
>> diff --git a/src/compiler/glsl/builtin_float64.h 
>> b/src/compiler/glsl/builtin_float64.h
>> index bf0953e5d6..0a363bd27a 100644
>> --- a/src/compiler/glsl/builtin_float64.h
>> +++ b/src/compiler/glsl/builtin_float64.h
> [snip]
>> +
>> +/* THEN INSTRUCTIONS */
>> +body.instructions = &f0EF9->then_instructions;
>> +
>> +ir_constant_data r0EFD_data;
>> +memset(&r0EFD_data, 0, sizeof(ir_constant_data));
>> +r0EFD_data.u[0] = 4294967295;
>> +r0EFD_data.u[1] = 4294967295;
>
> Looks like some debug/testing left-overs?

No. It's the IR representation of "return uvec2(0xu, 0xu);"
Multiply 0 by Inf (or Inf by 0) is an invalid operation.
So when we have this kind of operation,  we return a NaN.

IEEE 754:
" 7.2 Invalid operation

For operations producing results in floating-point format, the default
result of an operation that signals the
invalid operation exception shall be a quiet NaN that should provide
some diagnostic information. "


>
> [snip]
>> +
>> +   /* THEN INSTRUCTIONS */
>> +   body.instructions = &f0F22->then_instructions;
>> +
>> +   ir_constant_data r0F26_data;
>> +   memset(&r0F26_data, 0, sizeof(ir_constant_data));
>> +r0F26_data.u[0] = 4294967295;
>> +r0F26_data.u[1] = 4294967295;
>
> Ditto
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] nir: Improve induction variables detection

[tournier.elie]

Any comments, tips before I go to deep in the code?

On 24 February 2017 at 12:17, Elie Tournier  wrote:
> The actual code detect only basic induction variables (i = i +/- c).
> I'm working on improve the detection in order to reconize derived induction 
> varibles (j = c1 * i +/- c2).
> I obtain the code below.
>
> I'm not sure about the nir_derived_induction_var.
> Should I replace "nir_loop_variable *def_outside_loop" by 
> "nir_basic_indiction_var"?
>
> Comments are welcome.
>
> The goal is to implement a strength reduction algo.
>
> Signed-off-by: Elie Tournier 
> ---
>  src/compiler/nir/nir_loop_analyze.c | 46 
> -
>  1 file changed, 45 insertions(+), 1 deletion(-)
>
> diff --git a/src/compiler/nir/nir_loop_analyze.c 
> b/src/compiler/nir/nir_loop_analyze.c
> index 6afad9e603..587726914a 100644
> --- a/src/compiler/nir/nir_loop_analyze.c
> +++ b/src/compiler/nir/nir_loop_analyze.c
> @@ -29,10 +29,12 @@ typedef enum {
> undefined,
> invariant,
> not_invariant,
> -   basic_induction
> +   basic_induction,
> +   derived_induction
>  } nir_loop_variable_type;
>
>  struct nir_basic_induction_var;
> +struct nir_derived_induction_var;
>
>  typedef struct {
> /* A link for the work list */
> @@ -49,6 +51,9 @@ typedef struct {
> /* If this is of type basic_induction */
> struct nir_basic_induction_var *ind;
>
> +   /* If this is of type derived_induction */
> +   struct nir_derived_induction_var *derived_ind;
> +
> /* True if variable is in an if branch or a nested loop */
> bool in_control_flow;
>
> @@ -61,6 +66,14 @@ typedef struct nir_basic_induction_var {
> nir_loop_variable *def_outside_loop; /* The phi-src outside the loop 
> */
>  } nir_basic_induction_var;
>
> +typedef struct nir_derived_induction_var {
> +   nir_op alu_op;   /* The type of alu-operation
> */
> +   nir_loop_variable *alu_def;  /* The def of the alu-operation 
> */
> +   nir_loop_variable *invariant_0;  /* The invariant alu-operand
> */
> +   nir_loop_variable *invariant_1;  /* The invariant alu-operand
> */
> +   nir_loop_variable *def_outside_loop; /* The phi-src outside the loop 
> */
> +} nir_derived_induction_var;
> +
>  typedef struct {
> /* The loop we store information for */
> nir_loop *loop;
> @@ -227,6 +240,7 @@ compute_induction_information(loop_info_state *state)
>
>nir_phi_instr *phi = nir_instr_as_phi(var->def->parent_instr);
>nir_basic_induction_var *biv = rzalloc(state, nir_basic_induction_var);
> +  nir_derived_induction_var *div = rzalloc(state, 
> nir_derived_induction_var);
>
>nir_foreach_phi_src(src, phi) {
>   nir_loop_variable *src_var = get_loop_var(src->src.ssa, state);
> @@ -239,9 +253,11 @@ compute_induction_information(loop_info_state *state)
>
>   if (!src_var->in_loop) {
>  biv->def_outside_loop = src_var;
> +div->def_outside_loop = src_var;
>   } else if (is_var_alu(src_var)) {
>  nir_alu_instr *alu = 
> nir_instr_as_alu(src_var->def->parent_instr);
>
> +/* basic induction variable (i = i +/- c) */
>  if (nir_op_infos[alu->op].num_inputs == 2) {
> biv->alu_def = src_var;
> biv->alu_op = alu->op;
> @@ -253,6 +269,23 @@ compute_induction_information(loop_info_state *state)
>   biv->invariant = get_loop_var(alu->src[i].src.ssa, 
> state);
> }
>  }
> +/* derived induction variable (j = c1 * i +/- c2 ) */
> +if (nir_op_infos[alu->op].num_inputs == 3) {
> +   div->alu_def = src_var;
> +   div->alu_op = alu->op;
> +
> +   for (unsigned i = 0; i < 3; i++) {
> +  /* Is one of the operands const, an other the induction 
> var,
> +   * and the last an other const
> +   */
> +  if (alu->src[i].src.ssa->parent_instr->type == 
> nir_instr_type_load_const &&
> +  alu->src[1-i].src.ssa == &phi->dest.ssa &&
> +  alu->src[2-i].src.ssa->parent_instr->type == 
> nir_instr_type_load_const) {
> + div->invariant_0 = get_loop_var(alu->src[i].src.ssa, 
> state);
> + div->invariant_1 = get_loop_var(alu->src[2-i].src.ssa, 
> state);
> +  }
> +   }
> +}
>   }
>}
>
> @@ -265,8 +298,19 @@ compute_induction_information(loop_info_state *state)
>   var->ind = biv;
>
>   found_induction_var = true;
> +  } else if (div->alu_def && div->def_outside_loop && div->invariant_0 &&
> +  div->invariant_1 && is_var_constant(div->def_outside_loop)) {
> + assert(is_var_constant(div->invariant_0));
> + assert(is_var_constant(div->invariant_1));
> + div->alu_def->type = derived_induction;
> + div->al

Re: [Mesa-dev] [PATCH] glsl: Fix indent in dump code

[tournier.elie]

Right.
But did we generate lots of files w/ this method?
I only files I know are udivmod64.h and builtin_int64.h that you
generated for ARB_gpu_shader_int64. And these files are not impacted.

On 7 March 2017 at 20:23, Ian Romanick  wrote:
> Since this will affect generated code that is tracked in GIT, a second
> patch should regenerate all those files.  Otherwise the next patch that
> causes those files to be regenerated will include a bunch of spurious
> changes.
>
> This is one of the (very strong) arguments against this sort of
> architecture. :(
>
> On 03/06/2017 07:27 AM, Elie Tournier wrote:
>> From: Elie Tournier 
>>
>> Signed-off-by: Elie Tournier 
>> ---
>> On an other thread [1], we discovered than the GLSL compiler have some 
>> trouble to indent correctly the dump IR.
>>
>> I don't have git access, please push it for me.
>>
>> [1] https://lists.freedesktop.org/archives/mesa-dev/2017-March/146518.html
>> ---
>>  src/compiler/glsl/ir_builder_print_visitor.cpp | 14 +++---
>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/compiler/glsl/ir_builder_print_visitor.cpp 
>> b/src/compiler/glsl/ir_builder_print_visitor.cpp
>> index 825dbe148e..02f15e74ee 100644
>> --- a/src/compiler/glsl/ir_builder_print_visitor.cpp
>> +++ b/src/compiler/glsl/ir_builder_print_visitor.cpp
>> @@ -372,17 +372,17 @@ ir_builder_print_visitor::visit(ir_constant *ir)
>>   switch (ir->type->base_type) {
>>   case GLSL_TYPE_UINT:
>>  if (ir->value.u[i] != 0)
>> -   print_without_indent("r%04X_data.u[%u] = %u;\n",
>> +   print_with_indent("r%04X_data.u[%u] = %u;\n",
>>  my_index, i, ir->value.u[i]);
>>  break;
>>   case GLSL_TYPE_INT:
>>  if (ir->value.i[i] != 0)
>> -   print_without_indent("r%04X_data.i[%u] = %i;\n",
>> +   print_with_indent("r%04X_data.i[%u] = %i;\n",
>>  my_index, i, ir->value.i[i]);
>>  break;
>>   case GLSL_TYPE_FLOAT:
>>  if (ir->value.u[i] != 0)
>> -   print_without_indent("r%04X_data.u[%u] = 0x%08x; /* %f */\n",
>> +   print_with_indent("r%04X_data.u[%u] = 0x%08x; /* %f */\n",
>>  my_index,
>>  i,
>>  ir->value.u[i],
>> @@ -395,27 +395,27 @@ ir_builder_print_visitor::visit(ir_constant *ir)
>>
>>  memcpy(&v, &ir->value.d[i], sizeof(v));
>>  if (v != 0)
>> -   print_without_indent("r%04X_data.u64[%u] = 0x%016" PRIx64 "; 
>> /* %g */\n",
>> +   print_with_indent("r%04X_data.u64[%u] = 0x%016" PRIx64 "; /* 
>> %g */\n",
>>  my_index, i, v, ir->value.d[i]);
>>  break;
>>   }
>>   case GLSL_TYPE_UINT64:
>>  if (ir->value.u64[i] != 0)
>> -   print_without_indent("r%04X_data.u64[%u] = %" PRIu64 ";\n",
>> +   print_with_indent("r%04X_data.u64[%u] = %" PRIu64 ";\n",
>>  my_index,
>>  i,
>>  ir->value.u64[i]);
>>  break;
>>   case GLSL_TYPE_INT64:
>>  if (ir->value.i64[i] != 0)
>> -   print_without_indent("r%04X_data.i64[%u] = %" PRId64 ";\n",
>> +   print_with_indent("r%04X_data.i64[%u] = %" PRId64 ";\n",
>>  my_index,
>>  i,
>>  ir->value.i64[i]);
>>  break;
>>   case GLSL_TYPE_BOOL:
>>  if (ir->value.u[i] != 0)
>> -   print_without_indent("r%04X_data.u[%u] = 1;\n", my_index, i);
>> +   print_with_indent("r%04X_data.u[%u] = 1;\n", my_index, i);
>>  break;
>>   default:
>>  unreachable("Invalid constant type");
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 00/11] GL_ARB_gpu_shader_fp64

[tournier.elie]

I understand the concern about reviewing auto-generated files.
An other solution is to generate the builtin_float64.h during the
compilation time. So we just have to land the float64.glsl file.

Would anyone see merit in bootstrapping?

Elie

On 6 March 2017 at 18:13, Emil Velikov  wrote:
> On 6 March 2017 at 17:15, Jason Ekstrand  wrote:
>
>>>
>>> How about we allows drivers to opt-in for this ? There's already a
>>> bunch in gl_shader_compiler_options that we toggle.
>>> This will allow Elie's work to land and be [at least partially] useful
>>> in the interim.
>>
>>
>> That's entirely beside the issue.  I'm trying to avoid checking piles of
>> very hard-to-read autogenerated C++ code into the tree until we're sure that
>> it's actually a good solution.
>
> Your earlier reply read very close to "drop all this and do it in NIR.
> this is how you'll do it", seems like some of us got confused.
> AFAICT Ian saw some merits for having this in GLSL - perhaps you can
> poke him to take a look as well, as he's got some time of course.
>
> Thanks
> 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] [RFC 00/11] GL_ARB_gpu_shader_fp64

[tournier.elie]

To resume, using NIR resolve some troubles: fp64 can be use by Intel,
no autogen code, SPIR-V on OpenGL.
So if nobody opposes (too hard), i will start implement fp64 in NIR.

But NIR doesn't solve everything. How to handle drivers without NIR
support like r600? Should we land the GLSL IR version of fp64 for
that?
I know this imply code duplication but at least GL_ARB_gpu_shader_fp64
will be available for r600.

On 11 March 2017 at 18:51, Jason Ekstrand  wrote:
> On Sat, Mar 11, 2017 at 9:50 AM, Jason Ekstrand 
> wrote:
>>
>>
>> As I said at the top, I'm really not going for NIR or nothing.  I agree
>> that GLSL has advantages for chips like r600 which badly needs emulation and
>> isn't moving to NIR any time soon.  Also, fp64 isn't a requirement in Vulkan
>> and, given that Vulkan covers both desktop and mobile, likely won't be any
>> time soon.  (In fact, if someone wanted Vulkan FP64 on hardware that didn't
>> support it, I'd be tempted to tell them to pay someone to write a layer.)
>> However, *if* we decide that emulated fp64 is better on, for instance Ivy
>> Bridge, *and* we had customers that cared about it (I don't know of any),
>> then doing it in NIR could yield substantially better results (depending on
>> initial shader quality) due to being able to run nir_opt_algebraic first.
>> Those are a lot of ifs so maybe I'm suggesting we design for a non-use-case,
>> but I really don't want to paint ourselves into a corner that we have to
>> crawl out of 2 years from now.
>
>
> Chatting with people on IRC this morning, I realized there's a killer
> argument for why we *need* NIR support: SPIR-V on OpenGL.  As soon as you
> expose the GL_ARB_spirv extension on an OpenGL 4.0+ driver, you must support
> fp64.  If we ever need emulated fp64 in such a driver, the lowering has to
> be done in NIR because there is no GLSL IR in the path.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] spirv: Implement IsInf using an integer comparison

[tournier.elie]

Reviewed-by: Elie Tournier 

On 17 March 2017 at 04:18, Jason Ekstrand  wrote:
> Since we already do fabs on the one source, we're guaranteed to get
> positive infinity if we get any infinity at all.  Since +inf only has
> one IEEE 754 representation, we can use an integer comparison and avoid
> all of the ordered/unordered issues.
>
> Cc: 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 0738fe0..9e4beed 100644
> --- a/src/compiler/spirv/vtn_alu.c
> +++ b/src/compiler/spirv/vtn_alu.c
> @@ -447,7 +447,7 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
>break;
>
> case SpvOpIsInf:
> -  val->ssa->def = nir_feq(&b->nb, nir_fabs(&b->nb, src[0]),
> +  val->ssa->def = nir_ieq(&b->nb, nir_fabs(&b->nb, src[0]),
>nir_imm_float(&b->nb, INFINITY));
>break;
>
> --
> 2.5.0.400.gff86faf
>
> ___
> 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] glsl: don't leak memory when trying to count loop iterations

[tournier.elie]

You can probably add a "Suggested-by" in the message.

Reviewed-by: Elie Tournier 

On 17 March 2017 at 10:53, Timothy Arceri  wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99789
> ---
>  src/compiler/glsl/loop_controls.cpp | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/glsl/loop_controls.cpp 
> b/src/compiler/glsl/loop_controls.cpp
> index c717605..fa739af 100644
> --- a/src/compiler/glsl/loop_controls.cpp
> +++ b/src/compiler/glsl/loop_controls.cpp
> @@ -90,23 +90,24 @@ calculate_iterations(ir_rvalue *from, ir_rvalue *to, 
> ir_rvalue *increment,
>
> void *mem_ctx = ralloc_context(NULL);
>
> ir_expression *const sub =
>new(mem_ctx) ir_expression(ir_binop_sub, from->type, to, from);
>
> ir_expression *const div =
>new(mem_ctx) ir_expression(ir_binop_div, sub->type, sub, increment);
>
> ir_constant *iter = div->constant_expression_value();
> -
> -   if (iter == NULL)
> +   if (iter == NULL) {
> +  ralloc_free(mem_ctx);
>return -1;
> +   }
>
> if (!iter->type->is_integer()) {
>const ir_expression_operation op = iter->type->is_double()
>   ? ir_unop_d2i : ir_unop_f2i;
>ir_rvalue *cast =
>   new(mem_ctx) ir_expression(op, glsl_type::int_type, iter, NULL);
>
>iter = cast->constant_expression_value();
> }
>
> --
> 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] glsl: Fix indent in dump code

[tournier.elie]

On 8 March 2017 at 14:56, tournier.elie  wrote:
> Right.
> But did we generate lots of files w/ this method?
> I only files I know are udivmod64.h and builtin_int64.h that you
> generated for ARB_gpu_shader_int64. And these files are not impacted.

Ping.
Is anyone know the files generated by the standalone compiler?
If yes, is this patch impact these files?

>
> On 7 March 2017 at 20:23, Ian Romanick  wrote:
>> Since this will affect generated code that is tracked in GIT, a second
>> patch should regenerate all those files.  Otherwise the next patch that
>> causes those files to be regenerated will include a bunch of spurious
>> changes.
>>
>> This is one of the (very strong) arguments against this sort of
>> architecture. :(
>>
>> On 03/06/2017 07:27 AM, Elie Tournier wrote:
>>> From: Elie Tournier 
>>>
>>> Signed-off-by: Elie Tournier 
>>> ---
>>> On an other thread [1], we discovered than the GLSL compiler have some 
>>> trouble to indent correctly the dump IR.
>>>
>>> I don't have git access, please push it for me.
>>>
>>> [1] https://lists.freedesktop.org/archives/mesa-dev/2017-March/146518.html
>>> ---
>>>  src/compiler/glsl/ir_builder_print_visitor.cpp | 14 +++---
>>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/src/compiler/glsl/ir_builder_print_visitor.cpp 
>>> b/src/compiler/glsl/ir_builder_print_visitor.cpp
>>> index 825dbe148e..02f15e74ee 100644
>>> --- a/src/compiler/glsl/ir_builder_print_visitor.cpp
>>> +++ b/src/compiler/glsl/ir_builder_print_visitor.cpp
>>> @@ -372,17 +372,17 @@ ir_builder_print_visitor::visit(ir_constant *ir)
>>>   switch (ir->type->base_type) {
>>>   case GLSL_TYPE_UINT:
>>>  if (ir->value.u[i] != 0)
>>> -   print_without_indent("r%04X_data.u[%u] = %u;\n",
>>> +   print_with_indent("r%04X_data.u[%u] = %u;\n",
>>>  my_index, i, ir->value.u[i]);
>>>  break;
>>>   case GLSL_TYPE_INT:
>>>  if (ir->value.i[i] != 0)
>>> -   print_without_indent("r%04X_data.i[%u] = %i;\n",
>>> +   print_with_indent("r%04X_data.i[%u] = %i;\n",
>>>  my_index, i, ir->value.i[i]);
>>>  break;
>>>   case GLSL_TYPE_FLOAT:
>>>  if (ir->value.u[i] != 0)
>>> -   print_without_indent("r%04X_data.u[%u] = 0x%08x; /* %f 
>>> */\n",
>>> +   print_with_indent("r%04X_data.u[%u] = 0x%08x; /* %f */\n",
>>>  my_index,
>>>  i,
>>>  ir->value.u[i],
>>> @@ -395,27 +395,27 @@ ir_builder_print_visitor::visit(ir_constant *ir)
>>>
>>>  memcpy(&v, &ir->value.d[i], sizeof(v));
>>>  if (v != 0)
>>> -   print_without_indent("r%04X_data.u64[%u] = 0x%016" PRIx64 
>>> "; /* %g */\n",
>>> +   print_with_indent("r%04X_data.u64[%u] = 0x%016" PRIx64 "; 
>>> /* %g */\n",
>>>  my_index, i, v, ir->value.d[i]);
>>>  break;
>>>   }
>>>   case GLSL_TYPE_UINT64:
>>>  if (ir->value.u64[i] != 0)
>>> -   print_without_indent("r%04X_data.u64[%u] = %" PRIu64 ";\n",
>>> +   print_with_indent("r%04X_data.u64[%u] = %" PRIu64 ";\n",
>>>  my_index,
>>>  i,
>>>  ir->value.u64[i]);
>>>  break;
>>>   case GLSL_TYPE_INT64:
>>>  if (ir->value.i64[i] != 0)
>>> -   print_without_indent("r%04X_data.i64[%u] = %" PRId64 ";\n",
>>> +   print_with_indent("r%04X_data.i64[%u] = %" PRId64 ";\n",
>>>  my_index,
>>>  i,
>>>  ir->value.i64[i]);
>>>  break;
>>>   case GLSL_TYPE_BOOL:
>>>  if (ir->value.u[i] != 0)
>>> -   print_without_indent("r%04X_data.u[%u] = 1;\n", my_index, 
>>> i);
>>> +   print_with_indent("r%04X_data.u[%u] = 1;\n", my_index, i);
>>>  break;
>>>   default:
>>>  unreachable("Invalid constant type");
>>>
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 04/12] anv/nir: Delete the apply_dynamic_offsets prototype

[tournier.elie]

Reviewed-by: Elie Tournier 

On 23 March 2017 at 04:01, Jason Ekstrand  wrote:
> That pass hasn't existed since dd4db84640bbb694f180dd50850c3388f67228be
> but the prototype stuck around for no reason.
> ---
>  src/intel/vulkan/anv_nir.h | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_nir.h b/src/intel/vulkan/anv_nir.h
> index a929dd9..3f97701 100644
> --- a/src/intel/vulkan/anv_nir.h
> +++ b/src/intel/vulkan/anv_nir.h
> @@ -35,9 +35,6 @@ void anv_nir_lower_input_attachments(nir_shader *shader);
>
>  void anv_nir_lower_push_constants(nir_shader *shader);
>
> -void anv_nir_apply_dynamic_offsets(struct anv_pipeline *pipeline,
> -   nir_shader *shader,
> -   struct brw_stage_prog_data *prog_data);
>  void anv_nir_apply_pipeline_layout(struct anv_pipeline *pipeline,
> nir_shader *shader,
> struct brw_stage_prog_data *prog_data,
> --
> 2.5.0.400.gff86faf
>
> ___
> 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] [RFC 00/11] GL_ARB_gpu_shader_fp64

[tournier.elie]

Hello,

It's seems impossible to expose all the drivers to soft fp64 with one
piece of code.
So what do you think about landing this series (with some fix) for r600?

The other drivers will use the NIR version of soft fp64.
BTW, an "alpha RFC" series is coming on the ML soonish.

Elie

On 13 March 2017 at 17:00, tournier.elie  wrote:
> To resume, using NIR resolve some troubles: fp64 can be use by Intel,
> no autogen code, SPIR-V on OpenGL.
> So if nobody opposes (too hard), i will start implement fp64 in NIR.
>
> But NIR doesn't solve everything. How to handle drivers without NIR
> support like r600? Should we land the GLSL IR version of fp64 for
> that?
> I know this imply code duplication but at least GL_ARB_gpu_shader_fp64
> will be available for r600.
>
> On 11 March 2017 at 18:51, Jason Ekstrand  wrote:
>> On Sat, Mar 11, 2017 at 9:50 AM, Jason Ekstrand 
>> wrote:
>>>
>>>
>>> As I said at the top, I'm really not going for NIR or nothing.  I agree
>>> that GLSL has advantages for chips like r600 which badly needs emulation and
>>> isn't moving to NIR any time soon.  Also, fp64 isn't a requirement in Vulkan
>>> and, given that Vulkan covers both desktop and mobile, likely won't be any
>>> time soon.  (In fact, if someone wanted Vulkan FP64 on hardware that didn't
>>> support it, I'd be tempted to tell them to pay someone to write a layer.)
>>> However, *if* we decide that emulated fp64 is better on, for instance Ivy
>>> Bridge, *and* we had customers that cared about it (I don't know of any),
>>> then doing it in NIR could yield substantially better results (depending on
>>> initial shader quality) due to being able to run nir_opt_algebraic first.
>>> Those are a lot of ifs so maybe I'm suggesting we design for a non-use-case,
>>> but I really don't want to paint ourselves into a corner that we have to
>>> crawl out of 2 years from now.
>>
>>
>> Chatting with people on IRC this morning, I realized there's a killer
>> argument for why we *need* NIR support: SPIR-V on OpenGL.  As soon as you
>> expose the GL_ARB_spirv extension on an OpenGL 4.0+ driver, you must support
>> fp64.  If we ever need emulated fp64 in such a driver, the lowering has to
>> be done in NIR because there is no GLSL IR in the path.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/47] WIP: fp64 support for r600g

[tournier.elie]

On 24 August 2017 at 15:26, Marc Dietrich  wrote:
> Hi Elie,
>
> Am Mittwoch, 23. August 2017, 13:07:30 CEST schrieb Elie Tournier:
>> From: Elie Tournier 
>>
>> TL;DR
>> This series is a "status update" of my work done for adding fp64 support on
>> r600g. One of the biggest issue is due to a lake of accuracy on the rcp
>> implementation. Divide relay on rcp.
>>
>> A branch is available on
>> https://github.com/Hopetech/mesa/tree/glsl_arb_gpu_shader_fp64_v3 Comments
>> and reviews are welcome.
>
> what are the hardware requirements for testing this? R600g is a wide range ...

Hello Marc,

My code targets all the cards who doesn't support double but who
support GLSL 1.30:
https://github.com/Hopetech/mesa/blob/glsl_arb_gpu_shader_fp64_v3/src/mesa/state_tracker/st_glsl_to_tgsi.cpp#L7059

So iirc, all r600g cards.

>
> Marc
>
> ___
> 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 00/47] WIP: fp64 support for r600g

[tournier.elie]

Hi Gert,

On 24 August 2017 at 12:27, Gert Wollny  wrote:
> Hello Elie,
>
> thanks for you work on this. I'd thought I'd share my test results on
> BARTS:
>
> - your tree was build with debug enabled, so some of the crashes
>   relate to assertion failures (at least one in r600/sb which also
>   fails with R600_DEBUG=nosb).
>
> - piglit results
>* arb_gpu_shader_fp64 900/1311  passed
>* glsl-4.00 822/1225 passed
>* Crashes in total are 402 and 485 failures.
>
>   The complete summary is at
>   https://www.dropbox.com/s/qn283a9s0cd2uru/shaders-fp64-only.tgz?dl=0

Thanks a lot for sharing your results.
I will look at it.
>
>
> In  kern.log I got
>
> - lots of traps:
>   shader_runner[..] trap int3 ip:.. sp:.. error:0 in r600_dri.so ..
>
> - many segfaults in r600_dri.so
>
> - and some GPU lockups+reset, but no system crashes:

> radeon :01:00.0: ring 0 stalled for more than 10080msec
> radeon :01:00.0: GPU lockup (current fence id 0x00bb433c
>last fence id 0x00bb439d on ring 0)
> radeon :01:00.0: Saved 3095 dwords of commands on ring 0.
> radeon :01:00.0: GPU softreset: 0x0019
> ...
> <<<
>
> Best,
> Gert
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glsl: Silence unused parameter warnings

[tournier.elie]

On 13 September 2017 at 13:13, Alejandro Piñeiro  wrote:
> Series:
> Reviewed-by: Alejandro Piñeiro 

FWIW
Reviewed-by: Elie Tournier 
>
> On 12/09/17 18:41, Ian Romanick wrote:
>> From: Ian Romanick 
>>
>> glsl/ast_type.cpp: In function ‘void merge_bindless_qualifier(YYLTYPE*, 
>> _mesa_glsl_parse_state*, const ast_type_qualifier&, const 
>> ast_type_qualifier&)’:
>> glsl/ast_type.cpp:189:35: warning: unused parameter ‘loc’ 
>> [-Wunused-parameter]
>>  merge_bindless_qualifier(YYLTYPE *loc,
>>^~~
>> glsl/ast_type.cpp:191:52: warning: unused parameter ‘qualifier’ 
>> [-Wunused-parameter]
>>   const ast_type_qualifier &qualifier,
>> ^
>> glsl/ast_type.cpp:192:52: warning: unused parameter ‘new_qualifier’ 
>> [-Wunused-parameter]
>>   const ast_type_qualifier &new_qualifier)
>> ^
>>
>> glsl/ir_constant_expression.cpp: In member function ‘virtual ir_constant* 
>> ir_rvalue::constant_expression_value(void*, hash_table*)’:
>> glsl/ir_constant_expression.cpp:512:44: warning: unused parameter ‘mem_ctx’ 
>> [-Wunused-parameter]
>>  ir_rvalue::constant_expression_value(void *mem_ctx, struct hash_table *)
>> ^~~
>> glsl/ir_constant_expression.cpp: In member function ‘virtual ir_constant* 
>> ir_texture::constant_expression_value(void*, hash_table*)’:
>> glsl/ir_constant_expression.cpp:705:45: warning: unused parameter ‘mem_ctx’ 
>> [-Wunused-parameter]
>>  ir_texture::constant_expression_value(void *mem_ctx, struct hash_table *)
>>  ^~~
>> glsl/ir_constant_expression.cpp: In member function ‘virtual ir_constant* 
>> ir_assignment::constant_expression_value(void*, hash_table*)’:
>> glsl/ir_constant_expression.cpp:851:48: warning: unused parameter ‘mem_ctx’ 
>> [-Wunused-parameter]
>>  ir_assignment::constant_expression_value(void *mem_ctx, struct hash_table *)
>> ^~~
>> glsl/ir_constant_expression.cpp: In member function ‘virtual ir_constant* 
>> ir_constant::constant_expression_value(void*, hash_table*)’:
>> glsl/ir_constant_expression.cpp:859:46: warning: unused parameter ‘mem_ctx’ 
>> [-Wunused-parameter]
>>  ir_constant::constant_expression_value(void *mem_ctx, struct hash_table *)
>>   ^~~
>>
>> glsl/linker.cpp: In function ‘void 
>> link_xfb_stride_layout_qualifiers(gl_context*, gl_shader_program*, 
>> gl_linked_shader*, gl_shader**, unsigned int)’:
>> glsl/linker.cpp:1655:60: warning: unused parameter ‘linked_shader’ 
>> [-Wunused-parameter]
>>struct gl_linked_shader *linked_shader,
>> ^
>> glsl/linker.cpp: In function ‘void 
>> link_bindless_layout_qualifiers(gl_shader_program*, gl_program*, 
>> gl_shader**, unsigned int)’:
>> glsl/linker.cpp:1693:52: warning: unused parameter ‘gl_prog’ 
>> [-Wunused-parameter]
>>  struct gl_program *gl_prog,
>> ^~~
>>
>> glsl/lower_distance.cpp: In member function ‘virtual void 
>> {anonymous}::lower_distance_visitor_counter::handle_rvalue(ir_rvalue**)’:
>> glsl/lower_distance.cpp:652:59: warning: unused parameter ‘rv’ 
>> [-Wunused-parameter]
>>  lower_distance_visitor_counter::handle_rvalue(ir_rvalue **rv)
>>^~
>>
>> glsl/opt_array_splitting.cpp: In member function ‘virtual ir_visitor_status 
>> {anonymous}::ir_array_reference_visitor::visit_leave(ir_assignment*)’:
>> glsl/opt_array_splitting.cpp:198:56: warning: unused parameter ‘ir’ 
>> [-Wunused-parameter]
>>  ir_array_reference_visitor::visit_leave(ir_assignment *ir)
>> ^~
>>
>> glsl/glsl_parser_extras.cpp: In function ‘void 
>> assign_subroutine_indexes(gl_shader*, _mesa_glsl_parse_state*)’:
>> glsl/glsl_parser_extras.cpp:1869:45: warning: unused parameter ‘sh’ 
>> [-Wunused-parameter]
>>  assign_subroutine_indexes(struct gl_shader *sh,
>>  ^~
>>
>> Signed-off-by: Ian Romanick 
>> ---
>>  src/compiler/glsl/ast_type.cpp   | 7 ++-
>>  src/compiler/glsl/glsl_parser_extras.cpp | 5 ++---
>>  src/compiler/glsl/ir_constant_expression.cpp | 8 
>>  src/compiler/glsl/linker.cpp | 7 ++-
>>  src/compiler/glsl/lower_distance.cpp | 2 +-
>>  src/compiler/glsl/opt_array_splitting.cpp| 2 +-
>>  6 files changed, 12 insertions(+), 19 deletions(-)
>>
>> diff --git a/src/compiler/glsl/ast_type.cpp b/src/compiler/glsl/ast_type.cpp
>> index ee8697b..e9d60de 100644
>> --- a/src/compiler/glsl/ast_type.cpp
>> +++ b/src/compiler/glsl/ast_ty

Re: [Mesa-dev] [PATCH 1/3] glsl: don't drop intructions from unreachable terminators continue branch

[tournier.elie]

With the small nitpick from Eric, the series is:
Reviewed-by: Elie Tournier 

On 14 September 2017 at 05:47, Timothy Arceri  wrote:
> These instruction will be executed on every iteration of the loop
> we cannot drop them.
> ---
>  src/compiler/glsl/loop_analysis.h   |  7 +++
>  src/compiler/glsl/loop_controls.cpp | 15 +++
>  src/compiler/glsl/loop_unroll.cpp   |  7 ---
>  3 files changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/src/compiler/glsl/loop_analysis.h 
> b/src/compiler/glsl/loop_analysis.h
> index 2894c6359b..0e1bfd8142 100644
> --- a/src/compiler/glsl/loop_analysis.h
> +++ b/src/compiler/glsl/loop_analysis.h
> @@ -27,20 +27,27 @@
>
>  #include "ir.h"
>  #include "util/hash_table.h"
>
>  /**
>   * Analyze and classify all variables used in all loops in the instruction 
> list
>   */
>  extern class loop_state *
>  analyze_loop_variables(exec_list *instructions);
>
> +static inline bool
> +is_break(ir_instruction *ir)
> +{
> +   return ir != NULL && ir->ir_type == ir_type_loop_jump &&
> +  ((ir_loop_jump *) ir)->is_break();
> +}
> +
>
>  /**
>   * Fill in loop control fields
>   *
>   * Based on analysis of loop variables, this function tries to remove
>   * redundant sequences in the loop of the form
>   *
>   *  (if (expression bool ...) (break))
>   *
>   * For example, if it is provable that one loop exit condition will
> diff --git a/src/compiler/glsl/loop_controls.cpp 
> b/src/compiler/glsl/loop_controls.cpp
> index 895954fc2d..2dff26aec0 100644
> --- a/src/compiler/glsl/loop_controls.cpp
> +++ b/src/compiler/glsl/loop_controls.cpp
> @@ -215,21 +215,36 @@ loop_control_visitor::visit_leave(ir_loop *ir)
>  * that are associated with a fixed iteration count, except for the one
>  * associated with the limiting terminator--that one needs to stay, since
>  * it terminates the loop.  Exception: if the loop still has a normative
>  * bound, then that terminates the loop, so we don't even need the 
> limiting
>  * terminator.
>  */
> foreach_in_list(loop_terminator, t, &ls->terminators) {
>if (t->iterations < 0)
>   continue;
>
> +  exec_list *branch_instructions;
>if (t != ls->limiting_terminator) {
> + ir_instruction *ir_if_last = (ir_instruction *)
> +   t->ir->then_instructions.get_tail();
> + if (is_break(ir_if_last)) {
> +branch_instructions = &t->ir->else_instructions;
> + } else {
> +branch_instructions = &t->ir->then_instructions;
> +assert(is_break(ir_if_last));
> + }
> +
> + exec_list copy_list;
> + copy_list.make_empty();
> + clone_ir_list(ir, ©_list, branch_instructions);
> +
> + t->ir->insert_before(©_list);
>   t->ir->remove();
>
>   assert(ls->num_loop_jumps > 0);
>   ls->num_loop_jumps--;
>
>   this->progress = true;
>}
> }
>
> return visit_continue;
> diff --git a/src/compiler/glsl/loop_unroll.cpp 
> b/src/compiler/glsl/loop_unroll.cpp
> index dbb3fa2fa5..7f601295a1 100644
> --- a/src/compiler/glsl/loop_unroll.cpp
> +++ b/src/compiler/glsl/loop_unroll.cpp
> @@ -46,27 +46,20 @@ public:
> void splice_post_if_instructions(ir_if *ir_if, exec_list *splice_dest);
>
> loop_state *state;
>
> bool progress;
> const struct gl_shader_compiler_options *options;
>  };
>
>  } /* anonymous namespace */
>
> -static bool
> -is_break(ir_instruction *ir)
> -{
> -   return ir != NULL && ir->ir_type == ir_type_loop_jump
> -&& ((ir_loop_jump *) ir)->is_break();
> -}
> -
>  class loop_unroll_count : public ir_hierarchical_visitor {
>  public:
> int nodes;
> bool unsupported_variable_indexing;
> bool array_indexed_by_induction_var_with_exact_iterations;
> /* If there are nested loops, the node count will be inaccurate. */
> bool nested_loop;
>
> loop_unroll_count(exec_list *list, loop_variable_state *ls,
>   const struct gl_shader_compiler_options *options)
> --
> 2.13.5
>
> ___
> 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