[Mesa-dev] [Bug 109075] radv: New D3D boolean optimizations cause GPU hang in Witcher 3

[bugzilla-daemon]

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

Ian Romanick  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEEDINFO|RESOLVED

--- Comment #10 from Ian Romanick  ---
Fixed by:

commit 96c4b135e34d0804e41bfbc28fc1b5050c49d71e (HEAD -> bug-109075,
gitlab/bug-109075)
Author: Ian Romanick 
Date:   Tue Dec 18 13:28:22 2018 -0800

nir/algebraic: Don't put quotes around floating point literals

The quotation marks around 1.0 cause it to be treated as a string
instead of a floating point value.  The generator then treats it as an
arbitrary variable replacement, so any iand involving a ('ineg', ('b2i',
a)) matches.

v2: Remove misleading comment about sized literals (suggested by
Timothy).  Add assertion that the name of a varible is entierly
alphabetic (suggested by Jason).

Signed-off-by: Ian Romanick 
Reviewed-by: Jason Ekstrand 
Tested-by: Timothy Arceri  [v1]
Reviewed-by: Timothy Arceri  [v1]
Fixes: 6bcd2af0863 ("nir/algebraic: Add some optimizations for D3D-style
Booleans")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109075

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

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Matt Turner]

On Tue, Dec 18, 2018 at 6:53 PM Ilia Mirkin  wrote:
>
> On Tue, Dec 18, 2018 at 6:40 PM Gert Wollny  wrote:
> >
> > Hi Ilia,
> >
> > Am Sonntag, den 16.12.2018, 12:40 -0500 schrieb Ilia Mirkin:
> > > On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny 
> > > wrote:
> > > >
> > > > Since Meson will eventually be the only build system deprecate
> > > > autotools
> > > > now. It can still be used by invoking configure with the flag
> > > >   --enable-autotools
> > > >
> >
> > [...]
> > > If the concern is that there are 2 build systems and it's unclear
> > > which to use, I'd definitely err on the side of making meson the one
> > > requiring extra hoops to jump through.
> > >
> >
> > I think Jason already pointed out that this patch doesn't remove
> > anything. If you have followed the threads you've seen that I'm also
> > not exactly pushing for removing autotools, but I think since it is
> > going to happen anyway, it would be best to give everyone a little more
> > incentive to try out meson so that hopefully all the remaining issue
> > are brought up and can be fixed, before autotools is removed in a
> > stable release.
>
> Yeah, I totally see that you're not removing autotools with this
> patch. I do see that you're making it harder to use though (i.e.
> indicating to users that it's not the #1 way to do things). This
> should only be done when it's ready to be deprecated. The argument
> I've been making is that it's not. I've outlined some things that I
> think are important to fix in meson in another thread.

You've said Meson's not ready given X, Y, and Z use cases. I've noted
that some of those use cases were not reported earlier because the
users had not given Meson a try until we began discussing removing
autotools. This patch attempts to simply inform a larger group of
users that are not subscribed to mesa-dev@ that the intention is for
autotools to be removed.

Dylan is working to fix X, Y, and Z, but there's a reasonable chance
that a user who wasn't subscribed to mesa-dev@ might find problems A,
B, and C only after he's forced to switch to Meson. This patch is the
only thing that's been proposed so far to communicate with those
users. Without some required interaction on the users part we will
fail to communicate with some users and we'll be right back where we
are now.

WTF would you have us do?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] nir/algebraic: Generalize an optimization - RADV / DXVK 0.93+0.94 regression with LS2019

[Dieter Nützel]

Sorry guys,

but my son got a RADV + DXVK 0.93 and 0.94 (D3D11) regression running 
brand new LS2019 (https://www.farming-simulator.com/?lang=en=us) 
on our Polaris 20. All heaven textures are gone and some others are 
wrong.


git bisect bad 445867c80d
git bisect good e4f9a37ace

/opt/mesa> git bisect good
615cc26b97ad520b90a8d3b3f9bdaa49c78dfda5 is the first bad commit
commit 615cc26b97ad520b90a8d3b3f9bdaa49c78dfda5
Author: Jason Ekstrand 
Date:   Thu Dec 6 12:56:33 2018 -0600

nir/algebraic: Generalize an optimization

This just makes it nicely scale across bit sizes.

Reviewed-by: Eric Anholt 
Reviewed-by: Bas Nieuwenhuizen 
Tested-by: Bas Nieuwenhuizen 

:04 04 ced4299ecdd6d76755839c9a0af11417e5f4973a 
321e0c0e1c985c49c4e0b37f766c4a68c4ca145f M src


But git revert 615cc26b97 alone do NOT help.

Have to file a ticket after some sleep...;-)

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

[Mesa-dev] [Bug 109086] Crash software mesa with gl_select render mode

[bugzilla-daemon]

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

--- Comment #7 from Ilia Mirkin  ---
Patch available at: https://patchwork.freedesktop.org/patch/268721/

Makes this example work, and doesn't appear to regress existing piglit tests.

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

[Mesa-dev] [PATCH] st/mesa: allow glDrawElements to work with GL_SELECT feedback

[Ilia Mirkin]

Not sure if this ever worked, but the current logic for setting the
min/max index is definitely wrong for indexed draws. While we're at it,
bring in all the usual logic from the non-indirect drawing path.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109086
Signed-off-by: Ilia Mirkin 
---

This makes it more or less mirror st_draw_vbo. As the comment in the
code says, would be nice to refactor, but ... meh.

Note that I haven't tested any of the interactions with additional
features, like primitive restart or instancing or any of that. However I
don't think that this would make things *worse*.

 src/mesa/state_tracker/st_draw_feedback.c | 61 +++
 1 file changed, 39 insertions(+), 22 deletions(-)

diff --git a/src/mesa/state_tracker/st_draw_feedback.c 
b/src/mesa/state_tracker/st_draw_feedback.c
index 6ec6d5c16f4..49fdecf7e38 100644
--- a/src/mesa/state_tracker/st_draw_feedback.c
+++ b/src/mesa/state_tracker/st_draw_feedback.c
@@ -84,27 +84,6 @@ set_feedback_vertex_format(struct gl_context *ctx)
 }
 
 
-/**
- * Helper for drawing current vertex arrays.
- */
-static void
-draw_arrays(struct draw_context *draw, unsigned mode,
-unsigned start, unsigned count)
-{
-   struct pipe_draw_info info;
-
-   util_draw_init_info();
-
-   info.mode = mode;
-   info.start = start;
-   info.count = count;
-   info.min_index = start;
-   info.max_index = start + count - 1;
-
-   draw_vbo(draw, );
-}
-
-
 /**
  * Called by VBO to draw arrays when in selection or feedback mode and
  * to implement glRasterPos.
@@ -136,10 +115,18 @@ st_feedback_draw_vbo(struct gl_context *ctx,
struct pipe_transfer *ib_transfer = NULL;
GLuint i;
const void *mapped_indices = NULL;
+   struct pipe_draw_info info;
 
if (!draw)
   return;
 
+   /* Initialize pipe_draw_info. */
+   info.primitive_restart = false;
+   info.vertices_per_patch = ctx->TessCtrlProgram.patch_vertices;
+   info.indirect = NULL;
+   info.count_from_stream_output = NULL;
+   info.restart_index = 0;
+
st_flush_bitmap_cache(st);
st_invalidate_readpix_cache(st);
 
@@ -213,9 +200,23 @@ st_feedback_draw_vbo(struct gl_context *ctx,
  mapped_indices = ib->ptr;
   }
 
+  info.index_size = ib->index_size;
+  info.min_index = min_index;
+  info.max_index = max_index;
+  info.has_user_indices = true;
+  info.index.user = mapped_indices;
+
   draw_set_indexes(draw,
(ubyte *) mapped_indices,
index_size, ~0);
+
+  if (ctx->Array._PrimitiveRestart) {
+ info.primitive_restart = true;
+ info.restart_index = _mesa_primitive_restart_index(ctx, 
info.index_size);
+  }
+   } else {
+  info.index_size = 0;
+  info.has_user_indices = false;
}
 
/* set the constant buffer */
@@ -226,7 +227,23 @@ st_feedback_draw_vbo(struct gl_context *ctx,
 
/* draw here */
for (i = 0; i < nr_prims; i++) {
-  draw_arrays(draw, prims[i].mode, start + prims[i].start, prims[i].count);
+  info.count = prims[i].count;
+
+  if (!info.count)
+ continue;
+
+  info.mode = prims[i].mode;
+  info.start = start + prims[i].start;
+  info.start_instance = prims[i].base_instance;
+  info.instance_count = prims[i].num_instances;
+  info.index_bias = prims[i].basevertex;
+  info.drawid = prims[i].draw_id;
+  if (!ib) {
+ info.min_index = info.start;
+ info.max_index = info.start + info.count - 1;
+  }
+
+  draw_vbo(draw, );
}
 
 
-- 
2.18.1

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

[Mesa-dev] [Bug 109086] Crash software mesa with gl_select render mode

[bugzilla-daemon]

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

--- Comment #6 from Ilia Mirkin  ---
(In reply to Ilia Mirkin from comment #5)
> Note that the address is (very likely) bogus. It also dies with draw using
> llvm (same address), but ... harder to debug that. Will try to investigate
> further. Since this is a client-side buffer, could be the application doing
> something illegal.

Looks like we're not treating glDrawElements properly for GL_SELECT.
st_feedback_draw_vbo tries to set it all up, but then calls draw_vbo with a
min_index/max_index configured for arrays.

Will try to fix it up...

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

[Mesa-dev] [Bug 109086] Crash software mesa with gl_select render mode

[bugzilla-daemon]

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

--- Comment #5 from Ilia Mirkin  ---
With valgrind, forcing DRAW_USE_LLVM=0 to make our lives a little easier, it
dies in:

==12812== Process terminating with default action of signal 11 (SIGSEGV)
==12812==  Access not within mapped region at address 0x332000
==12812==at 0x9C8ADF0: util_format_r32g32b32_float_fetch_rgba_float (in
/usr/lib64/dri/nouveau_dri.so)
==12812==by 0x9D0D2C1: generic_run (in /usr/lib64/dri/nouveau_dri.so)
==12812==by 0xA26E99F: fetch_pipeline_generic.constprop.1 (in
/usr/lib64/dri/nouveau_dri.so)
==12812==by 0xA26EDEE: fetch_pipeline_linear_run (in
/usr/lib64/dri/nouveau_dri.so)
==12812==by 0xA27389C: vsplit_run_linear (in /usr/lib64/dri/nouveau_dri.so)
==12812==by 0xA26D117: draw_pt_arrays (in /usr/lib64/dri/nouveau_dri.so)
==12812==by 0xA26D564: draw_vbo (in /usr/lib64/dri/nouveau_dri.so)
==12812==by 0xA083D65: st_feedback_draw_vbo (in
/usr/lib64/dri/nouveau_dri.so)
==12812==by 0xA062B0A: _mesa_validated_drawrangeelements (in
/usr/lib64/dri/nouveau_dri.so)
==12812==by 0xA06384B: _mesa_exec_DrawElements (in
/usr/lib64/dri/nouveau_dri.so)
==12812==by 0x1092CB: draw (in /home/ilia/Downloads/mesacrash)
==12812==by 0x109427: displayCB (in /home/ilia/Downloads/mesacrash)

Note that the address is (very likely) bogus. It also dies with draw using llvm
(same address), but ... harder to debug that. Will try to investigate further.
Since this is a client-side buffer, could be the application doing something
illegal.

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

[Mesa-dev] [Bug 109086] Crash software mesa with gl_select render mode

[bugzilla-daemon]

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

--- Comment #4 from Daniel Stone  ---
The content of attachment 142850 has been deleted for the following reason:

spam

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

[Mesa-dev] [Bug 109086] Crash software mesa with gl_select render mode

[bugzilla-daemon]

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

--- Comment #3 from Daniel Stone  ---
The content of attachment 142849 has been deleted for the following reason:

spam

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

[Mesa-dev] [Bug 109086] Crash software mesa with gl_select render mode

[bugzilla-daemon]

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

--- Comment #2 from Vian  ---
Created attachment 142850
  --> https://bugs.freedesktop.org/attachment.cgi?id=142850=edit
hwhwhw

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

[Mesa-dev] [Bug 109086] Crash software mesa with gl_select render mode

[bugzilla-daemon]

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

--- Comment #1 from Vian  ---
Created attachment 142849
  --> https://bugs.freedesktop.org/attachment.cgi?id=142849=edit
bug

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

Re: [Mesa-dev] [PATCH] nir: create 32-bit bcsel for 32-bit conditions

[Jason Ekstrand]

On December 18, 2018 19:42:56 Rhys Perry  wrote:


The 32-bit condition was in one of radv's meta shaders and had it from
the start.

32-bit conditions seems to be valid after lowering booleans to 32-bit.
Are they supposed to be invalid before the lowering?


It's not invalid in the sense that the validator doesn't complain. However, 
most passes are only set up to handle one type of Boolean so it's far safer 
if everything is 1-bit prior to lowering. Otherwise you may find yourself 
fixing a lot of these.


--Jason



On Wed, 19 Dec 2018 at 00:59, Jason Ekstrand  wrote:


Seems reasonable though I'm a bit surprised your running peephole_select
after lowering booleans.

On December 18, 2018 18:16:46 Timothy Arceri  wrote:


Reviewed-by: Timothy Arceri 

On 18/12/18 3:16 am, Rhys Perry wrote:

Signed-off-by: Rhys Perry 
---
src/compiler/nir/nir_opt_peephole_select.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_opt_peephole_select.c
b/src/compiler/nir/nir_opt_peephole_select.c
index ad9d0abec0..241627ed99 100644
--- a/src/compiler/nir/nir_opt_peephole_select.c
+++ b/src/compiler/nir/nir_opt_peephole_select.c
@@ -205,7 +205,9 @@ nir_opt_peephole_select_block(nir_block *block,
nir_shader *shader,
 break;

  nir_phi_instr *phi = nir_instr_as_phi(instr);
-  nir_alu_instr *sel = nir_alu_instr_create(shader, nir_op_bcsel);
+  nir_op sel_op = nir_src_bit_size(if_stmt->condition) == 1 ?
+  nir_op_bcsel : nir_op_b32csel;
+  nir_alu_instr *sel = nir_alu_instr_create(shader, sel_op);
  nir_src_copy(>src[0].src, _stmt->condition, sel);
  /* Splat the condition to all channels */
  memset(sel->src[0].swizzle, 0, sizeof sel->src[0].swizzle);

___
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] nir: create 32-bit bcsel for 32-bit conditions

[Rhys Perry]

The 32-bit condition was in one of radv's meta shaders and had it from
the start.

32-bit conditions seems to be valid after lowering booleans to 32-bit.
Are they supposed to be invalid before the lowering?

On Wed, 19 Dec 2018 at 00:59, Jason Ekstrand  wrote:
>
> Seems reasonable though I'm a bit surprised your running peephole_select
> after lowering booleans.
>
> On December 18, 2018 18:16:46 Timothy Arceri  wrote:
>
> > Reviewed-by: Timothy Arceri 
> >
> > On 18/12/18 3:16 am, Rhys Perry wrote:
> >> Signed-off-by: Rhys Perry 
> >> ---
> >>   src/compiler/nir/nir_opt_peephole_select.c | 4 +++-
> >>   1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/compiler/nir/nir_opt_peephole_select.c
> >> b/src/compiler/nir/nir_opt_peephole_select.c
> >> index ad9d0abec0..241627ed99 100644
> >> --- a/src/compiler/nir/nir_opt_peephole_select.c
> >> +++ b/src/compiler/nir/nir_opt_peephole_select.c
> >> @@ -205,7 +205,9 @@ nir_opt_peephole_select_block(nir_block *block,
> >> nir_shader *shader,
> >>break;
> >>
> >> nir_phi_instr *phi = nir_instr_as_phi(instr);
> >> -  nir_alu_instr *sel = nir_alu_instr_create(shader, nir_op_bcsel);
> >> +  nir_op sel_op = nir_src_bit_size(if_stmt->condition) == 1 ?
> >> +  nir_op_bcsel : nir_op_b32csel;
> >> +  nir_alu_instr *sel = nir_alu_instr_create(shader, sel_op);
> >> nir_src_copy(>src[0].src, _stmt->condition, sel);
> >> /* Splat the condition to all channels */
> >> memset(sel->src[0].swizzle, 0, sizeof sel->src[0].swizzle);
> >>
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109075] radv: New D3D boolean optimizations cause GPU hang in Witcher 3

[bugzilla-daemon]

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

--- Comment #9 from Philip Rebohle  ---
The patch that Ian posted fixes both the Witcher 3 hang and the Overwatch
issue.

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

Re: [Mesa-dev] [PATCH] nir: create 32-bit bcsel for 32-bit conditions

[Jason Ekstrand]

Seems reasonable though I'm a bit surprised your running peephole_select 
after lowering booleans.


On December 18, 2018 18:16:46 Timothy Arceri  wrote:


Reviewed-by: Timothy Arceri 

On 18/12/18 3:16 am, Rhys Perry wrote:

Signed-off-by: Rhys Perry 
---
  src/compiler/nir/nir_opt_peephole_select.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

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

index ad9d0abec0..241627ed99 100644
--- a/src/compiler/nir/nir_opt_peephole_select.c
+++ b/src/compiler/nir/nir_opt_peephole_select.c
@@ -205,7 +205,9 @@ nir_opt_peephole_select_block(nir_block *block, 
nir_shader *shader,

   break;

nir_phi_instr *phi = nir_instr_as_phi(instr);
-  nir_alu_instr *sel = nir_alu_instr_create(shader, nir_op_bcsel);
+  nir_op sel_op = nir_src_bit_size(if_stmt->condition) == 1 ?
+  nir_op_bcsel : nir_op_b32csel;
+  nir_alu_instr *sel = nir_alu_instr_create(shader, sel_op);
nir_src_copy(>src[0].src, _stmt->condition, sel);
/* Splat the condition to all channels */
memset(sel->src[0].swizzle, 0, sizeof sel->src[0].swizzle);


___
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] nir: create 32-bit bcsel for 32-bit conditions

[Timothy Arceri]

Reviewed-by: Timothy Arceri 

On 18/12/18 3:16 am, Rhys Perry wrote:

Signed-off-by: Rhys Perry 
---
  src/compiler/nir/nir_opt_peephole_select.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_opt_peephole_select.c 
b/src/compiler/nir/nir_opt_peephole_select.c
index ad9d0abec0..241627ed99 100644
--- a/src/compiler/nir/nir_opt_peephole_select.c
+++ b/src/compiler/nir/nir_opt_peephole_select.c
@@ -205,7 +205,9 @@ nir_opt_peephole_select_block(nir_block *block, nir_shader 
*shader,
   break;
  
nir_phi_instr *phi = nir_instr_as_phi(instr);

-  nir_alu_instr *sel = nir_alu_instr_create(shader, nir_op_bcsel);
+  nir_op sel_op = nir_src_bit_size(if_stmt->condition) == 1 ?
+  nir_op_bcsel : nir_op_b32csel;
+  nir_alu_instr *sel = nir_alu_instr_create(shader, sel_op);
nir_src_copy(>src[0].src, _stmt->condition, sel);
/* Splat the condition to all channels */
memset(sel->src[0].swizzle, 0, sizeof sel->src[0].swizzle);


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

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Ilia Mirkin]

On Tue, Dec 18, 2018 at 6:40 PM Gert Wollny  wrote:
>
> Hi Ilia,
>
> Am Sonntag, den 16.12.2018, 12:40 -0500 schrieb Ilia Mirkin:
> > On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny 
> > wrote:
> > >
> > > Since Meson will eventually be the only build system deprecate
> > > autotools
> > > now. It can still be used by invoking configure with the flag
> > >   --enable-autotools
> > >
>
> [...]
> > If the concern is that there are 2 build systems and it's unclear
> > which to use, I'd definitely err on the side of making meson the one
> > requiring extra hoops to jump through.
> >
>
> I think Jason already pointed out that this patch doesn't remove
> anything. If you have followed the threads you've seen that I'm also
> not exactly pushing for removing autotools, but I think since it is
> going to happen anyway, it would be best to give everyone a little more
> incentive to try out meson so that hopefully all the remaining issue
> are brought up and can be fixed, before autotools is removed in a
> stable release.

Yeah, I totally see that you're not removing autotools with this
patch. I do see that you're making it harder to use though (i.e.
indicating to users that it's not the #1 way to do things). This
should only be done when it's ready to be deprecated. The argument
I've been making is that it's not. I've outlined some things that I
think are important to fix in meson in another thread.

Cheers,

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

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Gert Wollny]

Hi Ilia, 

Am Sonntag, den 16.12.2018, 12:40 -0500 schrieb Ilia Mirkin:
> On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny 
> wrote:
> > 
> > Since Meson will eventually be the only build system deprecate
> > autotools
> > now. It can still be used by invoking configure with the flag
> >   --enable-autotools
> > 

[...]
> If the concern is that there are 2 build systems and it's unclear
> which to use, I'd definitely err on the side of making meson the one
> requiring extra hoops to jump through.
> 

I think Jason already pointed out that this patch doesn't remove
anything. If you have followed the threads you've seen that I'm also
not exactly pushing for removing autotools, but I think since it is
going to happen anyway, it would be best to give everyone a little more
incentive to try out meson so that hopefully all the remaining issue
are brought up and can be fixed, before autotools is removed in a
stable release. 

In any case, I wouldn't want to push this patch before [1] is fixed so
that one can indeed upgrade meson without having to manually redo the
configuration. 

Best, 
Gert 

[1] https://bugs.freedesktop.org/show_bug.cgi?id=109071

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

[Mesa-dev] [PATCH] autotools: Remove tegra vdpau driver

[Dylan Baker]

This has never functioned and probably wont ever function, due to the
way gallium media state trackers are architected and the tegra video
decoder is architected.

Cc: Thierry Reding 
Fixes: 1755f608f5201e0a23f00cc3ea1b01edd07eb6ef
   ("tegra: Initial support")
---
 src/gallium/targets/vdpau/Makefile.am | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/gallium/targets/vdpau/Makefile.am 
b/src/gallium/targets/vdpau/Makefile.am
index cd05a024451..2742c7acd44 100644
--- a/src/gallium/targets/vdpau/Makefile.am
+++ b/src/gallium/targets/vdpau/Makefile.am
@@ -57,8 +57,6 @@ include $(top_srcdir)/src/gallium/drivers/r300/Automake.inc
 include $(top_srcdir)/src/gallium/drivers/r600/Automake.inc
 include $(top_srcdir)/src/gallium/drivers/radeonsi/Automake.inc
 
-include $(top_srcdir)/src/gallium/drivers/tegra/Automake.inc
-
 if HAVE_GALLIUM_STATIC_TARGETS
 
 libvdpau_gallium_la_SOURCES += target.c
-- 
2.20.0

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

Re: [Mesa-dev] [PATCH mesa] meson: add missing tegra vdpau driver

[Dylan Baker]

Quoting Thierry Reding (2018-12-18 14:19:32)
> On Tue, Dec 18, 2018 at 11:34:31AM -0800, Dylan Baker wrote:
> > Quoting Eric Engestrom (2018-12-18 09:43:18)
> > > 
> > > 
> > > On December 18, 2018 5:36:19 PM UTC, Dylan Baker  
> > > wrote:
> > > > Quoting Ilia Mirkin (2018-12-06 09:39:25)
> > > > > On Thu, Dec 6, 2018 at 12:17 PM Eric Engestrom
> > > >  wrote:
> > > > > >
> > > > > > On Thursday, 2018-12-06 12:07:06 -0500, Ilia Mirkin wrote:
> > > > > > > Under what circumstances would tegra have a vdpau
> > > > implementation?
> > > > > >
> > > > > > I don't know about that, but this patch brings meson on par with
> > > > > > autotools. Are you saying autotools was wrong and it should be
> > > > removed
> > > > > > there instead?
> > > > > >
> > > > > > FtR, src/gallium/targets/vdpau/Makefile.am includes
> > > > > > src/gallium/drivers/tegra/Automake.inc which adds tegra to the
> > > > > > TARGET_DRIVERS, which in turn produces libvdpau_tegra.so
> > > > > >
> > > > > > If this was wrong, then that include on line 60 of
> > > > > > src/gallium/targets/vdpau/Makefile.am should be removed.
> > > > > >
> > > > > > This line was added by Thierry Reding (cc'ed) when he first
> > > > introduced
> > > > > > tegra support in 1755f608f5201e0a23f00 "tegra: Initial support".
> > > > > 
> > > > > I'd like to hear tagr opine on this, but AFAIK tegra is a
> > > > > renderonly-style driver, which uses nouveau as its actual rendering
> > > > > backend. While nouveau does support VDPAU, the decoding engines are
> > > > > not available as part of the GPU device on Tegra platforms. They
> > > > still
> > > > > have decoders, they're just separate platform devices (which I
> > > > suspect
> > > > > operate very similarly to their desktop GPU counterparts, but that's
> > > > a
> > > > > separate matter).
> > > > > 
> > > > >   -ilia
> > > > 
> > > > Ping?
> > > 
> > > I suggest we land this patch to bring meson on par with autotools, and if 
> > > we decide later
> > > that autotools was wrong, we can just remove it from both places at once; 
> > > ack?
> > 
> > I'd vote lets at least give Thierry till tomorrow to respond, and we can 
> > merge
> > it tomorrow around this time if he hasn't, with the remove fallback if tegra
> > shouldn't have a vdpau module? Does that sound reasonable to everyone?
> 
> Sorry, I completely missed this. Ilia is right, Tegra doesn't have any
> decoding engines in the GPU. Ilia is also correct that the engines are
> separate devices and similar to their desktop GPU counterparts. While
> it'd technically be possible to somehow enable video decoding in the
> Tegra gallium driver (I had done some prototyping on this a while ago),
> it doesn't look like the best option at this point. The problem is that
> gallium makes a bunch of assumptions that just don't apply to Tegra.
> 
> At this point, it seems more likely that video decoding will be
> implemented as V4L2 memory-to-memory drivers.
> 
> So I think we should just remove the vdpau support for Tegra from the
> autotools build. It's completely non-functional and there are no plans
> to make it work.
> 
> Thierry

Perfect, Thanks Thierry!

Dylan


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

[Mesa-dev] [Bug 109075] radv: New D3D boolean optimizations cause GPU hang in Witcher 3

[bugzilla-daemon]

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

--- Comment #8 from Timothy Arceri  ---
(In reply to Ian Romanick from comment #5)
> The problem is the quotation marks around 1.0 cause it to be treated as a
> string instead of a floating point value.  The generator then treats it as
> an arbitrary variable replacement, so any iand involving a ('ineg', ('b2i',
> a)) matches.
> 

Yes but as per my comment in the merge request that is meant to be supported.

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

Re: [Mesa-dev] [PATCH mesa] meson: add missing tegra vdpau driver

[Thierry Reding]

On Tue, Dec 18, 2018 at 11:34:31AM -0800, Dylan Baker wrote:
> Quoting Eric Engestrom (2018-12-18 09:43:18)
> > 
> > 
> > On December 18, 2018 5:36:19 PM UTC, Dylan Baker  
> > wrote:
> > > Quoting Ilia Mirkin (2018-12-06 09:39:25)
> > > > On Thu, Dec 6, 2018 at 12:17 PM Eric Engestrom
> > >  wrote:
> > > > >
> > > > > On Thursday, 2018-12-06 12:07:06 -0500, Ilia Mirkin wrote:
> > > > > > Under what circumstances would tegra have a vdpau
> > > implementation?
> > > > >
> > > > > I don't know about that, but this patch brings meson on par with
> > > > > autotools. Are you saying autotools was wrong and it should be
> > > removed
> > > > > there instead?
> > > > >
> > > > > FtR, src/gallium/targets/vdpau/Makefile.am includes
> > > > > src/gallium/drivers/tegra/Automake.inc which adds tegra to the
> > > > > TARGET_DRIVERS, which in turn produces libvdpau_tegra.so
> > > > >
> > > > > If this was wrong, then that include on line 60 of
> > > > > src/gallium/targets/vdpau/Makefile.am should be removed.
> > > > >
> > > > > This line was added by Thierry Reding (cc'ed) when he first
> > > introduced
> > > > > tegra support in 1755f608f5201e0a23f00 "tegra: Initial support".
> > > > 
> > > > I'd like to hear tagr opine on this, but AFAIK tegra is a
> > > > renderonly-style driver, which uses nouveau as its actual rendering
> > > > backend. While nouveau does support VDPAU, the decoding engines are
> > > > not available as part of the GPU device on Tegra platforms. They
> > > still
> > > > have decoders, they're just separate platform devices (which I
> > > suspect
> > > > operate very similarly to their desktop GPU counterparts, but that's
> > > a
> > > > separate matter).
> > > > 
> > > >   -ilia
> > > 
> > > Ping?
> > 
> > I suggest we land this patch to bring meson on par with autotools, and if 
> > we decide later
> > that autotools was wrong, we can just remove it from both places at once; 
> > ack?
> 
> I'd vote lets at least give Thierry till tomorrow to respond, and we can merge
> it tomorrow around this time if he hasn't, with the remove fallback if tegra
> shouldn't have a vdpau module? Does that sound reasonable to everyone?

Sorry, I completely missed this. Ilia is right, Tegra doesn't have any
decoding engines in the GPU. Ilia is also correct that the engines are
separate devices and similar to their desktop GPU counterparts. While
it'd technically be possible to somehow enable video decoding in the
Tegra gallium driver (I had done some prototyping on this a while ago),
it doesn't look like the best option at this point. The problem is that
gallium makes a bunch of assumptions that just don't apply to Tegra.

At this point, it seems more likely that video decoding will be
implemented as V4L2 memory-to-memory drivers.

So I think we should just remove the vdpau support for Tegra from the
autotools build. It's completely non-functional and there are no plans
to make it work.

Thierry


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

[Mesa-dev] [Bug 109075] radv: New D3D boolean optimizations cause GPU hang in Witcher 3

[bugzilla-daemon]

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

--- Comment #7 from Ian Romanick  ---
Test case sent to the piglit list:
https://patchwork.freedesktop.org/patch/268702/

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

Re: [Mesa-dev] [PATCH] WIP: meson: allow building DRI loaders without a DRI driver

[Dylan Baker]

Quoting Emil Velikov (2018-12-18 03:09:55)
> On Mon, 17 Dec 2018 at 22:27, Matt Turner  wrote:
> >
> > On Mon, Dec 17, 2018 at 2:12 PM Emil Velikov  
> > wrote:
> > > Additionally, distributions build latest loader and use it with DRI1
> > > era drivers.
> >
> > I'm curious if there are distributions that still ships the DRI1
> > drivers. Do you know which, if any, do?
> 
> Archlinux comes off the top of my head. We had a few others but I've
> not looked in 6+ months.
> 
> -Emil

pacman says arch still does, but I'm not sure why considering they only support
x86_64 now and half of those GPUs only came with x86 cpus.

Dylan


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

Re: [Mesa-dev] [PATCH 03/18] glx: meson: build src/glx only with -Dglx=dri

[Dylan Baker]

Quoting Emil Velikov (2018-12-18 02:33:56)
> On Mon, 17 Dec 2018 at 19:44, Dylan Baker  wrote:
> >
> > Quoting Emil Velikov (2018-12-17 10:58:11)
> > > On Fri, 14 Dec 2018 at 17:13, Dylan Baker  wrote:
> > > >
> > > > Quoting Emil Velikov (2018-12-13 08:05:52)
> > > > > From: Emil Velikov 
> > > > >
> > > > > The library is the dri capable one, push the check src/meson.build,
> > > > > instead of the current partial handling in src/glx/meson.build.
> > > > >
> > > > > Fixes: a47c525f328 ("meson: build glx")
> > > >
> > > > This is just a refactor, the Fixes: is unnecessary. More on that below
> > > >
> > > If I'm reading things correctly, building with -Dglx=xlib/gallium-xlib
> > > -Dshared-glapi -Denable-tests - will attempt to build the tests in
> > > src/glx/tests/.
> > > Which is something that shouldn't happen IMHO.
> >
> > Wait, why shouldn't they run? The tests pass (at least with the gallium-xlib
> > glx), and running tests seems useful.
> >
> Fully agree running tests is useful and welcome.
> 
> The tests flex the -Dglx=dri code in src/glx/. As-is it's rather
> confusing, misleading even, to request one thing then run tests for
> something that looks the same but isn't.
> Silly analogy - running ANV tests, when -Dvulkan-drivers=amd is used.
> 
> Hope this is clear - not sure if the coffee has kicked in ;-)
> -Emil

Sorry, I meant to respond yesterday. Ian explained why these tests are only
useful if building DRI based GLX.

Maybe make the commit message something like:
"meson: Ensure tests for dri based glx are only built when dri based glx is 
enabled"
or something like that? I'll leave it up to you what you think is best. As long
as you note that the real functional change is not building tests when we don't
want/need them.

Reviewed-by: Dylan Baker 


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

Re: [Mesa-dev] [PATCH] meson: Fix libsensors detection.

[Dylan Baker]

Quoting Vinson Lee (2018-12-18 13:01:43)
> On Tue, Dec 18, 2018 at 11:42 AM Dylan Baker  wrote:
> >
> > Quoting Vinson Lee (2018-12-18 09:52:08)
> > > Fixes: 5e71efef44b9 ("meson: Add lmsensors support")
> > > Signed-off-by: Vinson Lee 
> > > ---
> > >  meson.build | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meson.build b/meson.build
> > > index 57dd8b59cb..d591ca377b 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -1395,7 +1395,7 @@ endif
> > >
> > >  _sensors = get_option('lmsensors')
> > >  if _sensors != 'false'
> > > -  dep_lmsensors = cc.find_library('libsensors', required : _sensors == 
> > > 'true')
> > > +  dep_lmsensors = cc.find_library('sensors', required : _sensors == 
> > > 'true')
> > >if dep_lmsensors.found()
> > >  pre_args += '-DHAVE_LIBSENSORS=1'
> > >endif
> > > --
> > > 2.19.1
> > >
> >
> > Does this actually fix anything for you, and if so on what OS? On Arch both
> > libsensors and sensors work fine and find the same library.
> >
> > Dylan
> 
> This patch fixes libsensors detection for me on Ubuntu 18.10 with meson 
> 0.47.2.

okay then,
Reviewed-by: Dylan Baker 


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

[Mesa-dev] [Bug 109075] radv: New D3D boolean optimizations cause GPU hang in Witcher 3

[bugzilla-daemon]

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

Ian Romanick  changed:

   What|Removed |Added

 Status|ASSIGNED|NEEDINFO

--- Comment #6 from Ian Romanick  ---
Can you try https://gitlab.freedesktop.org/mesa/mesa/merge_requests/30 to see
if that fixes the problem?

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

[Mesa-dev] MR: nir/algebraic: Don't put quotes around floating point literals

[Ian Romanick]

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/30

NOTE: This is still running through our CI, and I'm trying to come up
with a piglit test case that will reproduce it.

The quotation marks around 1.0 cause it to be treated as a string
instead of a floating point value. The generator then treats it as an
arbitrary variable replacement, so any iand involving a ('ineg', ('b2i',
a)) matches.

Signed-off-by: Ian Romanick 
Fixes: 6bcd2af0863 ("nir/algebraic: Add some optimizations for D3D-style
Booleans")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109075
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109075] radv: New D3D boolean optimizations cause GPU hang in Witcher 3

[bugzilla-daemon]

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

Ian Romanick  changed:

   What|Removed |Added

 CC||ja...@jlekstrand.net,
   ||t_arc...@yahoo.com.au
 Status|NEW |ASSIGNED
   Assignee|mesa-dev@lists.freedesktop. |i...@freedesktop.org
   |org |

--- Comment #5 from Ian Romanick  ---
The problem is the quotation marks around 1.0 cause it to be treated as a
string instead of a floating point value.  The generator then treats it as an
arbitrary variable replacement, so any iand involving a ('ineg', ('b2i', a))
matches.

I have a fix, and I'll submit an MR in a couple minutes.

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

Re: [Mesa-dev] [PATCH] meson: Fix libsensors detection.

[Vinson Lee]

On Tue, Dec 18, 2018 at 11:42 AM Dylan Baker  wrote:
>
> Quoting Vinson Lee (2018-12-18 09:52:08)
> > Fixes: 5e71efef44b9 ("meson: Add lmsensors support")
> > Signed-off-by: Vinson Lee 
> > ---
> >  meson.build | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meson.build b/meson.build
> > index 57dd8b59cb..d591ca377b 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1395,7 +1395,7 @@ endif
> >
> >  _sensors = get_option('lmsensors')
> >  if _sensors != 'false'
> > -  dep_lmsensors = cc.find_library('libsensors', required : _sensors == 
> > 'true')
> > +  dep_lmsensors = cc.find_library('sensors', required : _sensors == 'true')
> >if dep_lmsensors.found()
> >  pre_args += '-DHAVE_LIBSENSORS=1'
> >endif
> > --
> > 2.19.1
> >
>
> Does this actually fix anything for you, and if so on what OS? On Arch both
> libsensors and sensors work fine and find the same library.
>
> Dylan

This patch fixes libsensors detection for me on Ubuntu 18.10 with meson 0.47.2.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/5] radv: add support for FMASK expand

[Samuel Pitoiset]

Original patch by Dave Airlie.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/Makefile.sources |   1 +
 src/amd/vulkan/meson.build  |   1 +
 src/amd/vulkan/radv_cmd_buffer.c|   7 +
 src/amd/vulkan/radv_meta.c  |   8 +
 src/amd/vulkan/radv_meta.h  |   6 +
 src/amd/vulkan/radv_meta_fmask_expand.c | 306 
 src/amd/vulkan/radv_private.h   |   6 +
 7 files changed, 335 insertions(+)
 create mode 100644 src/amd/vulkan/radv_meta_fmask_expand.c

diff --git a/src/amd/vulkan/Makefile.sources b/src/amd/vulkan/Makefile.sources
index 53a638362b8..f6327563ee9 100644
--- a/src/amd/vulkan/Makefile.sources
+++ b/src/amd/vulkan/Makefile.sources
@@ -50,6 +50,7 @@ VULKAN_FILES := \
radv_meta_copy.c \
radv_meta_decompress.c \
radv_meta_fast_clear.c \
+   radv_meta_fmask_expand.c \
radv_meta_resolve.c \
radv_meta_resolve_cs.c \
radv_meta_resolve_fs.c \
diff --git a/src/amd/vulkan/meson.build b/src/amd/vulkan/meson.build
index cc2aa7fd17a..06c33ca45dc 100644
--- a/src/amd/vulkan/meson.build
+++ b/src/amd/vulkan/meson.build
@@ -78,6 +78,7 @@ libradv_files = files(
   'radv_meta_copy.c',
   'radv_meta_decompress.c',
   'radv_meta_fast_clear.c',
+  'radv_meta_fmask_expand.c',
   'radv_meta_resolve.c',
   'radv_meta_resolve_cs.c',
   'radv_meta_resolve_fs.c',
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index d79dd00758e..a18bfc4f85c 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4455,6 +4455,13 @@ static void radv_handle_color_image_transition(struct 
radv_cmd_buffer *cmd_buffe
!radv_layout_can_fast_clear(image, dst_layout, 
dst_queue_mask)) {
radv_fast_clear_flush_image_inplace(cmd_buffer, image, 
range);
}
+
+   if (radv_image_has_fmask(image)) {
+   if (src_layout != VK_IMAGE_LAYOUT_GENERAL &&
+   dst_layout == VK_IMAGE_LAYOUT_GENERAL) {
+   radv_expand_fmask_image_inplace(cmd_buffer, 
image, range);
+   }
+   }
}
 }
 
diff --git a/src/amd/vulkan/radv_meta.c b/src/amd/vulkan/radv_meta.c
index 1ec8896afa2..ec4fc4a6d4b 100644
--- a/src/amd/vulkan/radv_meta.c
+++ b/src/amd/vulkan/radv_meta.c
@@ -389,8 +389,15 @@ radv_device_init_meta(struct radv_device *device)
result = radv_device_init_meta_resolve_fragment_state(device, 
on_demand);
if (result != VK_SUCCESS)
goto fail_resolve_fragment;
+
+   result = radv_device_init_meta_fmask_expand_state(device);
+   if (result != VK_SUCCESS)
+   goto fail_fmask_expand;
+
return VK_SUCCESS;
 
+fail_fmask_expand:
+   radv_device_finish_meta_resolve_fragment_state(device);
 fail_resolve_fragment:
radv_device_finish_meta_resolve_compute_state(device);
 fail_resolve_compute:
@@ -431,6 +438,7 @@ radv_device_finish_meta(struct radv_device *device)
radv_device_finish_meta_fast_clear_flush_state(device);
radv_device_finish_meta_resolve_compute_state(device);
radv_device_finish_meta_resolve_fragment_state(device);
+   radv_device_finish_meta_fmask_expand_state(device);
 
radv_store_meta_pipeline(device);
radv_pipeline_cache_finish(>meta_state.cache);
diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
index 22f7ae7490a..5e0afd11a00 100644
--- a/src/amd/vulkan/radv_meta.h
+++ b/src/amd/vulkan/radv_meta.h
@@ -88,6 +88,9 @@ void radv_device_finish_meta_resolve_compute_state(struct 
radv_device *device);
 VkResult radv_device_init_meta_resolve_fragment_state(struct radv_device 
*device, bool on_demand);
 void radv_device_finish_meta_resolve_fragment_state(struct radv_device 
*device);
 
+VkResult radv_device_init_meta_fmask_expand_state(struct radv_device *device);
+void radv_device_finish_meta_fmask_expand_state(struct radv_device *device);
+
 void radv_meta_save(struct radv_meta_saved_state *saved_state,
struct radv_cmd_buffer *cmd_buffer, uint32_t flags);
 
@@ -174,6 +177,9 @@ void radv_fast_clear_flush_image_inplace(struct 
radv_cmd_buffer *cmd_buffer,
 void radv_decompress_dcc(struct radv_cmd_buffer *cmd_buffer,
struct radv_image *image,
 const VkImageSubresourceRange *subresourceRange);
+void radv_expand_fmask_image_inplace(struct radv_cmd_buffer *cmd_buffer,
+struct radv_image *image,
+const VkImageSubresourceRange 
*subresourceRange);
 
 void radv_meta_resolve_compute_image(struct radv_cmd_buffer *cmd_buffer,
 struct radv_image *src_image,
diff --git a/src/amd/vulkan/radv_meta_fmask_expand.c 
b/src/amd/vulkan/radv_meta_fmask_expand.c
new file mode 100644
index 000..f4b55328929
--- /dev/null

[Mesa-dev] [PATCH 5/5] radv: enable shaderStorageImageMultisample feature on GFX8+

[Samuel Pitoiset]

Untested on older chips.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_device.c  | 4 ++--
 src/amd/vulkan/radv_formats.c | 3 +--
 src/amd/vulkan/radv_shader.c  | 1 +
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index cb51ee44e58..53aed1a15db 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -736,7 +736,7 @@ void radv_GetPhysicalDeviceFeatures(
.shaderTessellationAndGeometryPointSize   = true,
.shaderImageGatherExtended= true,
.shaderStorageImageExtendedFormats= true,
-   .shaderStorageImageMultisample= false,
+   .shaderStorageImageMultisample= 
pdevice->rad_info.chip_class >= VI,
.shaderUniformBufferArrayDynamicIndexing  = true,
.shaderSampledImageArrayDynamicIndexing   = true,
.shaderStorageBufferArrayDynamicIndexing  = true,
@@ -975,7 +975,7 @@ void radv_GetPhysicalDeviceProperties(
.sampledImageIntegerSampleCounts  = 
VK_SAMPLE_COUNT_1_BIT,
.sampledImageDepthSampleCounts= sample_counts,
.sampledImageStencilSampleCounts  = sample_counts,
-   .storageImageSampleCounts = 
VK_SAMPLE_COUNT_1_BIT,
+   .storageImageSampleCounts = 
pdevice->rad_info.chip_class >= VI ? sample_counts : VK_SAMPLE_COUNT_1_BIT,
.maxSampleMaskWords   = 1,
.timestampComputeAndGraphics  = true,
.timestampPeriod  = 100.0 / 
pdevice->rad_info.clock_crystal_freq,
diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
index 59bc46d2fc8..c2d0c942a12 100644
--- a/src/amd/vulkan/radv_formats.c
+++ b/src/amd/vulkan/radv_formats.c
@@ -1093,8 +1093,7 @@ static VkResult radv_get_image_format_properties(struct 
radv_physical_device *ph
info->type == VK_IMAGE_TYPE_2D &&
(format_feature_flags & (VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT |
 
VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT)) &&
-   !(info->flags & VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT) &&
-   !(info->usage & VK_IMAGE_USAGE_STORAGE_BIT)) {
+   !(info->flags & VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT)) {
sampleCounts |= VK_SAMPLE_COUNT_2_BIT | VK_SAMPLE_COUNT_4_BIT | 
VK_SAMPLE_COUNT_8_BIT;
}
 
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 2eb5164ac97..e23cdfaaf5f 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -245,6 +245,7 @@ radv_shader_compile_to_nir(struct radv_device *device,
.storage_16bit = true,
.geometry_streams = true,
.transform_feedback = true,
+   .storage_image_ms = true,
},
};
entry_point = spirv_to_nir(spirv, module->size / 4,
-- 
2.20.1

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

[Mesa-dev] [PATCH 3/5] radv: initialize FMASK for images in fully expanded mode

[Samuel Pitoiset]

The value depends on the number of samples.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 25 +
 src/amd/vulkan/radv_meta.h   |  2 ++
 src/amd/vulkan/radv_meta_clear.c |  9 +
 src/amd/vulkan/radv_private.h|  3 +++
 4 files changed, 39 insertions(+)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index aebf93b447f..d79dd00758e 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4340,6 +4340,27 @@ static void radv_initialise_cmask(struct radv_cmd_buffer 
*cmd_buffer,
state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
 }
 
+void radv_initialize_fmask(struct radv_cmd_buffer *cmd_buffer,
+  struct radv_image *image)
+{
+   struct radv_cmd_state *state = _buffer->state;
+   static const uint32_t fmask_clear_values[4] = {
+   0x,
+   0x02020202,
+   0xE4E4E4E4,
+   0x76543210
+   };
+   uint32_t log2_samples = util_logbase2(image->info.samples);
+   uint32_t value = fmask_clear_values[log2_samples];
+
+   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
+RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
+
+   state->flush_bits |= radv_clear_fmask(cmd_buffer, image, value);
+
+   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
+}
+
 void radv_initialize_dcc(struct radv_cmd_buffer *cmd_buffer,
 struct radv_image *image, uint32_t value)
 {
@@ -4375,6 +4396,10 @@ static void radv_init_color_image_metadata(struct 
radv_cmd_buffer *cmd_buffer,
radv_initialise_cmask(cmd_buffer, image, value);
}
 
+   if (radv_image_has_fmask(image)) {
+   radv_initialize_fmask(cmd_buffer, image);
+   }
+
if (radv_image_has_dcc(image)) {
uint32_t value = 0xu; /* Fully expanded mode. */
bool need_decompress_pass = false;
diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
index f8d48f4d791..22f7ae7490a 100644
--- a/src/amd/vulkan/radv_meta.h
+++ b/src/amd/vulkan/radv_meta.h
@@ -201,6 +201,8 @@ void radv_decompress_resolve_src(struct radv_cmd_buffer 
*cmd_buffer,
 
 uint32_t radv_clear_cmask(struct radv_cmd_buffer *cmd_buffer,
  struct radv_image *image, uint32_t value);
+uint32_t radv_clear_fmask(struct radv_cmd_buffer *cmd_buffer,
+ struct radv_image *image, uint32_t value);
 uint32_t radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
struct radv_image *image, uint32_t value);
 
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index 7a364ec684a..cd6a90e6349 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -1295,6 +1295,15 @@ radv_clear_cmask(struct radv_cmd_buffer *cmd_buffer,
image->cmask.size, value);
 }
 
+uint32_t
+radv_clear_fmask(struct radv_cmd_buffer *cmd_buffer,
+struct radv_image *image, uint32_t value)
+{
+   return radv_fill_buffer(cmd_buffer, image->bo,
+   image->offset + image->fmask.offset,
+   image->fmask.size, value);
+}
+
 uint32_t
 radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
   struct radv_image *image, uint32_t value)
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 9a9cd5ff935..5204e8761d9 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1895,6 +1895,9 @@ void radv_meta_push_descriptor_set(struct radv_cmd_buffer 
*cmd_buffer,
 void radv_initialize_dcc(struct radv_cmd_buffer *cmd_buffer,
 struct radv_image *image, uint32_t value);
 
+void radv_initialize_fmask(struct radv_cmd_buffer *cmd_buffer,
+  struct radv_image *image);
+
 struct radv_fence {
struct radeon_winsys_fence *fence;
struct wsi_fence *fence_wsi;
-- 
2.20.1

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

[Mesa-dev] [PATCH 2/5] ac/nir: restrict fmask lookup to image load intrinsics

[Samuel Pitoiset]

We don't ever want to do the fmask lookup on a atomic or
store, the fmask should have been decompressed if the
surface has been moved to IMAGE_LAYOUT.

Original patch by Dave Airlie.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_nir_to_llvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 225c930d896..0f57dc7eeb4 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2243,7 +2243,7 @@ static void get_image_coords(struct ac_nir_context *ctx,
bool gfx9_1d = ctx->ac.chip_class >= GFX9 && dim == GLSL_SAMPLER_DIM_1D;
count = image_type_to_components_count(dim, is_array);
 
-   if (is_ms) {
+   if (is_ms && instr->intrinsic == nir_intrinsic_image_deref_load) {
LLVMValueRef fmask_load_address[3];
int chan;
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 1/5] spirv: add support for SpvCapabilityStorageImageMultisample

[Samuel Pitoiset]

Signed-off-by: Samuel Pitoiset 
---
 src/compiler/shader_info.h| 1 +
 src/compiler/spirv/spirv_to_nir.c | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index b21db3e60f0..05f37c8d197 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -64,6 +64,7 @@ struct spirv_supported_capabilities {
bool transform_feedback;
bool geometry_streams;
bool int64_atomics;
+   bool storage_image_ms;
 };
 
 typedef struct shader_info {
diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 7dc6bc914d6..2433d8638cc 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3432,7 +3432,6 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
   case SpvCapabilityVector16:
   case SpvCapabilityFloat16Buffer:
   case SpvCapabilityFloat16:
-  case SpvCapabilityStorageImageMultisample:
   case SpvCapabilityInt8:
   case SpvCapabilitySparseResidency:
  vtn_warn("Unsupported SPIR-V capability: %s",
@@ -3469,6 +3468,10 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
  spv_check_supported(int64_atomics, cap);
  break;
 
+  case SpvCapabilityStorageImageMultisample:
+ spv_check_supported(storage_image_ms, cap);
+ break;
+
   case SpvCapabilityAddresses:
   case SpvCapabilityKernel:
   case SpvCapabilityImageBasic:
-- 
2.20.1

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

[Mesa-dev] [PATCH 0/5] radv: add support for shaderStorageImageMultisample feature

[Samuel Pitoiset]

Hi,

This small series enables shaderStorageImageMultisample on GFX8+.

This series is originally based on Dave Airlie's work, but I made
some changes to make it work.

Please review,
Thanks!

Samuel Pitoiset (5):
  spirv: add support for SpvCapabilityStorageImageMultisample
  ac/nir: restrict fmask lookup to image load intrinsics
  radv: initialize FMASK for images in fully expanded mode
  radv: add support for FMASK expand
  radv: enable shaderStorageImageMultisample feature on GFX8+

 src/amd/common/ac_nir_to_llvm.c |   2 +-
 src/amd/vulkan/Makefile.sources |   1 +
 src/amd/vulkan/meson.build  |   1 +
 src/amd/vulkan/radv_cmd_buffer.c|  32 +++
 src/amd/vulkan/radv_device.c|   4 +-
 src/amd/vulkan/radv_formats.c   |   3 +-
 src/amd/vulkan/radv_meta.c  |   8 +
 src/amd/vulkan/radv_meta.h  |   8 +
 src/amd/vulkan/radv_meta_clear.c|   9 +
 src/amd/vulkan/radv_meta_fmask_expand.c | 306 
 src/amd/vulkan/radv_private.h   |   9 +
 src/amd/vulkan/radv_shader.c|   1 +
 src/compiler/shader_info.h  |   1 +
 src/compiler/spirv/spirv_to_nir.c   |   5 +-
 14 files changed, 384 insertions(+), 6 deletions(-)
 create mode 100644 src/amd/vulkan/radv_meta_fmask_expand.c

-- 
2.20.1

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

[Mesa-dev] [Bug 105207] The Talos Principle freezes system using radv

[bugzilla-daemon]

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

pritzl3...@gmail.com changed:

   What|Removed |Added

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

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

[Mesa-dev] [Bug 105207] The Talos Principle freezes system using radv

[bugzilla-daemon]

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

--- Comment #13 from pritzl3...@gmail.com ---
I just played a little bit and there was a spot it always hung for me but now
it works fine.

I havent tried the game since I last updated the bug I think until today.

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

Re: [Mesa-dev] [PATCH mesa] meson: add missing tegra vdpau driver

[Dylan Baker]

Quoting Eric Engestrom (2018-12-18 09:43:18)
> 
> 
> On December 18, 2018 5:36:19 PM UTC, Dylan Baker  wrote:
> > Quoting Ilia Mirkin (2018-12-06 09:39:25)
> > > On Thu, Dec 6, 2018 at 12:17 PM Eric Engestrom
> >  wrote:
> > > >
> > > > On Thursday, 2018-12-06 12:07:06 -0500, Ilia Mirkin wrote:
> > > > > Under what circumstances would tegra have a vdpau
> > implementation?
> > > >
> > > > I don't know about that, but this patch brings meson on par with
> > > > autotools. Are you saying autotools was wrong and it should be
> > removed
> > > > there instead?
> > > >
> > > > FtR, src/gallium/targets/vdpau/Makefile.am includes
> > > > src/gallium/drivers/tegra/Automake.inc which adds tegra to the
> > > > TARGET_DRIVERS, which in turn produces libvdpau_tegra.so
> > > >
> > > > If this was wrong, then that include on line 60 of
> > > > src/gallium/targets/vdpau/Makefile.am should be removed.
> > > >
> > > > This line was added by Thierry Reding (cc'ed) when he first
> > introduced
> > > > tegra support in 1755f608f5201e0a23f00 "tegra: Initial support".
> > > 
> > > I'd like to hear tagr opine on this, but AFAIK tegra is a
> > > renderonly-style driver, which uses nouveau as its actual rendering
> > > backend. While nouveau does support VDPAU, the decoding engines are
> > > not available as part of the GPU device on Tegra platforms. They
> > still
> > > have decoders, they're just separate platform devices (which I
> > suspect
> > > operate very similarly to their desktop GPU counterparts, but that's
> > a
> > > separate matter).
> > > 
> > >   -ilia
> > 
> > Ping?
> 
> I suggest we land this patch to bring meson on par with autotools, and if we 
> decide later
> that autotools was wrong, we can just remove it from both places at once; ack?

I'd vote lets at least give Thierry till tomorrow to respond, and we can merge
it tomorrow around this time if he hasn't, with the remove fallback if tegra
shouldn't have a vdpau module? Does that sound reasonable to everyone?

Dylan


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

Re: [Mesa-dev] [PATCH] meson: Fix libsensors detection.

[Dylan Baker]

Quoting Vinson Lee (2018-12-18 09:52:08)
> Fixes: 5e71efef44b9 ("meson: Add lmsensors support")
> Signed-off-by: Vinson Lee 
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 57dd8b59cb..d591ca377b 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1395,7 +1395,7 @@ endif
>  
>  _sensors = get_option('lmsensors')
>  if _sensors != 'false'
> -  dep_lmsensors = cc.find_library('libsensors', required : _sensors == 
> 'true')
> +  dep_lmsensors = cc.find_library('sensors', required : _sensors == 'true')
>if dep_lmsensors.found()
>  pre_args += '-DHAVE_LIBSENSORS=1'
>endif
> -- 
> 2.19.1
> 

Does this actually fix anything for you, and if so on what OS? On Arch both
libsensors and sensors work fine and find the same library.

Dylan


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

Re: [Mesa-dev] [PATCH v3] freedreno/ir3: Make imageStore use num components from image format

[Rob Clark]

On Tue, Dec 18, 2018 at 9:46 AM Ilia Mirkin  wrote:
>
> On Tue, Dec 18, 2018 at 9:42 AM Eduardo Lima Mitev  wrote:
> >
> > emit_intrinsic_store_image() is always using 4 components when
> > collecting registers for the value. When image has less than
> > 4 components (e.g, r32f, r32i, r32ui) this results in extra mov
> > instructions.
> >
> > This patch uses the actual number of components from the image format.
> >
> > For example, in a shader like:
> >
> > layout (r32f, binding=0) writeonly uniform imageBuffer u_image;
> > ...
> > void main(void) {
> >...
> >imageStore (u_image, some_offset, vec4(1.0));
> >...
> > }
> >
> > instruction count is reduced in at least 3 instructions (note image
> > format is r32f, 1 component only).
> >
> > This obviously reduces register pressure as well.
> >
> > v2: - Added support for image formats from NV_image_format extension
> > (Ilia Mirkin).
> > - Return 4 components by default instead of asserting. (Rob Clark).
> >
> > v3: Added more missing formats (Ilia Mirkin).
> > ---
> >  src/freedreno/ir3/ir3_compiler_nir.c | 69 +++-
> >  1 file changed, 67 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/freedreno/ir3/ir3_compiler_nir.c 
> > b/src/freedreno/ir3/ir3_compiler_nir.c
> > index 85f14f354d2..80f6f70475d 100644
> > --- a/src/freedreno/ir3/ir3_compiler_nir.c
> > +++ b/src/freedreno/ir3/ir3_compiler_nir.c
> > @@ -1251,6 +1251,70 @@ emit_intrinsic_load_image(struct ir3_context *ctx, 
> > nir_intrinsic_instr *intr,
> > ir3_split_dest(b, dst, sam, 0, 4);
> >  }
> >
> > +/* Returns the number of components for the different image formats
> > + * supported by the GLES 3.1 spec, plus those added by the
> > + * GL_NV_image_formats extension.
> > + */
> > +static unsigned
> > +get_num_components_for_glformat(GLuint format)
> > +{
> > +   switch (format) {
> > +   case GL_R32F:
> > +   case GL_R32I:
> > +   case GL_R32UI:
> > +   case GL_R16F:
> > +   case GL_R16I:
> > +   case GL_R16UI:
> > +   case GL_R16:
> > +   case GL_R16_SNORM:
> > +   case GL_R8I:
> > +   case GL_R8UI:
> > +   case GL_R8:
> > +   case GL_R8_SNORM:
> > +   return 1;
> > +
> > +   case GL_RG32F:
> > +   case GL_RG32I:
> > +   case GL_RG32UI:
> > +   case GL_RG16F:
> > +   case GL_RG16I:
> > +   case GL_RG16UI:
> > +   case GL_RG16:
> > +   case GL_RG16_SNORM:
> > +   case GL_RG8I:
> > +   case GL_RG8UI:
> > +   case GL_RG8:
> > +   case GL_RG8_SNORM:
> > +   return 2;
> > +
> > +   case GL_R11F_G11F_B10F:
> > +   return 3;
> > +
> > +   case GL_RGBA32F:
> > +   case GL_RGBA32I:
> > +   case GL_RGBA32UI:
> > +   case GL_RGBA16F:
> > +   case GL_RGBA16I:
> > +   case GL_RGBA16UI:
> > +   case GL_RGBA16:
> > +   case GL_RGBA16_SNORM:
> > +   case GL_RGBA8:
>
> You don't have to resend for this, but all the others go
>
> F (if exists)
> I
> UI
> (UNORM)
> SNORM
>
> While here you have the UNORM first. So please move it down right above SNORM.
>
> > +   case GL_RGBA8I:
> > +   case GL_RGBA8UI:
> > +   case GL_RGBA8_SNORM:
> > +   case GL_RGB10_A2UI:
> > +   case GL_RGB10_A2:
> > +   return 4;
> > +
> > +   default:

also, if we drop the assert, then maybe at least a debug_printf() so
that we know we are seeing an unknown format with debug builds?

With that and Ilia's suggestion, r-b

BR,
-R

> > +   /* Return 4 components also for all other formats we don't 
> > know
> > +* about. This is always safe. Also, the format should have 
> > been
> > +* validated already by the higher level API.
> > +*/
> > +   return 4;
> > +   }
> > +}
> > +
> >  /* src[] = { deref, coord, sample_index, value }. const_index[] = {} */
> >  static void
> >  emit_intrinsic_store_image(struct ir3_context *ctx, nir_intrinsic_instr 
> > *intr)
> > @@ -1262,6 +1326,7 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
> > nir_intrinsic_instr *intr)
> > struct ir3_instruction * const *coords = ir3_get_src(ctx, 
> > >src[1]);
> > unsigned ncoords = get_image_coords(var, NULL);
> > unsigned tex_idx = get_image_slot(ctx, 
> > nir_src_as_deref(intr->src[0]));
> > +   unsigned ncomp = 
> > get_num_components_for_glformat(var->data.image.format);
> >
> > /* src0 is value
> >  * src1 is coords
> > @@ -1276,10 +1341,10 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
> > nir_intrinsic_instr *intr)
> >  */
> >
> > stib = ir3_STIB(b, create_immed(b, tex_idx), 0,
> > -   ir3_create_collect(ctx, value, 4), 0,
> > +   ir3_create_collect(ctx, value, ncomp), 0,
> > ir3_create_collect(ctx, coords, ncoords), 0,
> > offset, 0);
> > -   stib->cat6.iim_val 

[Mesa-dev] [PATCH] etnaviv: implement check_resource_capability

[Lucas Stach]

We try to avoid sharing all resources with KMS side of renderonly, as this
adds some overhead that isn't really needed for most resources. If
someone tries to validate a resource for scanout, this is a good indication
that the sharing with the KMS side is actually needed.

Signed-off-by: Lucas Stach 
---
 .../drivers/etnaviv/etnaviv_resource.c| 22 +++
 1 file changed, 22 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index c00912880309..cd846e3ae36e 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -624,6 +624,27 @@ etna_resource_get_handle(struct pipe_screen *pscreen,
}
 }
 
+static bool
+etna_check_resource_capability(struct pipe_screen *pscreen,
+   struct pipe_resource *prsc,
+   unsigned bind)
+{
+   struct etna_screen *screen = etna_screen(pscreen);
+   struct etna_resource *rsc = etna_resource(prsc);
+
+   if ((bind & PIPE_BIND_LINEAR) && rsc->layout != ETNA_LAYOUT_LINEAR)
+  return false;
+
+   if ((bind & PIPE_BIND_SCANOUT) && !rsc->scanout) {
+  rsc->scanout = renderonly_create_gpu_import_for_resource(prsc, 
screen->ro,
+   NULL);
+  if (!rsc->scanout)
+ return false;
+   }
+
+   return true;
+}
+
 void
 etna_resource_used(struct etna_context *ctx, struct pipe_resource *prsc,
enum etna_resource_status status)
@@ -667,4 +688,5 @@ etna_resource_screen_init(struct pipe_screen *pscreen)
pscreen->resource_get_handle = etna_resource_get_handle;
pscreen->resource_changed = etna_resource_changed;
pscreen->resource_destroy = etna_resource_destroy;
+   pscreen->check_resource_capability = etna_check_resource_capability;
 }
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH] egl/wayland: break double/tripple buffering feedback loops

[Lucas Stach]

Am Dienstag, den 18.12.2018, 17:43 + schrieb Emil Velikov:
> > On Tue, 18 Dec 2018 at 11:16, Lucas Stach  wrote:
> > 
> > Currently we dispose any unneeded color buffers immediately if we detect 
> > that
> > there are more unlocked buffers than we need. This can lead to feedback 
> > loops
> > between the compositor and the application causing rapid toggling between
> > double and tripple buffering. Scenario: 2 buffers already qeued to the
> > compositor, egl/wayland allocates a new back buffer to avoid trottling,
> > slowing down the frame, this allows the compositor to catch up and unlock
> > both buffers, then EGL detects that there are more buffers than currently
> > need, freeing the buffer, restartig the loop shortly after.
> > 
> > To avoid wasting CPU time on rapidly freeing and reallocating color buffers
> > break those feedback loops by letting the unneeded buffers sit around for a
> > short while before disposing them.
> > 
> > > > Signed-off-by: Lucas Stach 
> > ---
> >  src/egl/drivers/dri2/platform_wayland.c | 13 +
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/egl/drivers/dri2/platform_wayland.c 
> > b/src/egl/drivers/dri2/platform_wayland.c
> > index 34e09d7ec167..3fa08c1639d1 100644
> > --- a/src/egl/drivers/dri2/platform_wayland.c
> > +++ b/src/egl/drivers/dri2/platform_wayland.c
> > @@ -474,15 +474,17 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
> > wl_display_dispatch_queue_pending(dri2_dpy->wl_dpy, 
> > dri2_surf->wl_queue);
> > 
> > while (dri2_surf->back == NULL) {
> > +  int age = 0;
> >    for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
> >   /* Get an unlocked buffer, preferably one with a dri_buffer
> >    * already allocated. */
> > - if (dri2_surf->color_buffers[i].locked)
> > + if (dri2_surf->color_buffers[i].locked || 
> > dri2_surf->color_buffers[i].age < age)
> >  continue;
> >   if (dri2_surf->back == NULL)
> >  dri2_surf->back = _surf->color_buffers[i];
> > - else if (dri2_surf->back->dri_image == NULL)
> > + else if (dri2_surf->back->dri_image == NULL && 
> > dri2_surf->color_buffers[i].dri_image)
> >  dri2_surf->back = _surf->color_buffers[i];
> > + age = dri2_surf->back->age;
> >    }
> > 
> 
> AFAICT this is the wayland equivalent of
> 4f1d27a406478d405eac6f9894ccc46a80034adb
> Where the exact same logic/commit message applies.

No it isn't. It's exactly what it says in the commit log. It's keeping
the tripple buffer around for a bit, even if we don't strictly need it
when the client is currently doing double buffering.

When things are on the edge between double buffering being enough and
sometimes a third buffer being needed to avoid stalling we would
otherwise bounce rapidly between allocating and disposing the third
buffer.

The DRM platform has no such optimization and just keeps the third
buffer around forever. This patch keeps the optimization in the Wayland
platform, but adds a bit of hysteresis before disposing the buffer when
going from tripple to double buffering to see if things are settling on
double buffering.

> Can you please split that up? I'd imagine this isn't enough to for the
> usecase you had in mind?
> 
> >    if (dri2_surf->back)
> > @@ -615,10 +617,13 @@ update_buffers(struct dri2_egl_surface *dri2_surf)
> > 
> > /* If we have an extra unlocked buffer at this point, we had to do 
> > triple
> >  * buffering for a while, but now can go back to just double buffering.
> > -* That means we can free any unlocked buffer now. */
> > +* That means we can free any unlocked buffer now. To avoid toggling 
> > between
> > +* going back to double buffering and needing to allocate third buffer 
> > too
> > +* fast we let the unneeded buffer sit around for a short while. */
> > for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
> >    if (!dri2_surf->color_buffers[i].locked &&
> > -  dri2_surf->color_buffers[i].wl_buffer) {
> > +  dri2_surf->color_buffers[i].wl_buffer &&
> > +  dri2_surf->color_buffers[i].age > 18) {
> 
> The age check here seems strange - both number used and it's relation
> to double/triple buffering.
> Have you considered tracking/checking how many buffers we have?

A hysteresis value of 18 is just something that worked well in
practice. It didn't appear to defer the buffer destruction for too long
 while keeping the feedback loop well under control.

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

Re: [Mesa-dev] [PATCH] radv: Work around non-renderable 128bpp compressed 3d textures on GFX9.

[Haehnle, Nicolai]

On 18.12.18 00:02, Bas Nieuwenhuizen wrote:
> Exactly what title says, the new addrlib does not allow the above with
> certain dimensions that the CTS seems to hit. Work around it by not
> allowing the app to render to it via compat with  other 128bpp formats
> and do not render to it ourselves during copies.
> 
> Fixes: 776b9113656 "amd/addrlib: update Mesa's copy of addrlib"
> ---
>   src/amd/common/ac_surface.c | 12 
>   src/amd/common/ac_surface.h |  1 +
>   src/amd/vulkan/radv_formats.c   | 12 
>   src/amd/vulkan/radv_image.c |  6 ++
>   src/amd/vulkan/radv_meta_copy.c | 24 ++--
>   5 files changed, 45 insertions(+), 10 deletions(-)
> 
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index d8d927ee1c5..80f5d642771 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -709,7 +709,9 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
>   else
>   AddrSurfInfoIn.tileType = ADDR_NON_DISPLAYABLE;
>   
> - AddrSurfInfoIn.flags.color = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
> + bool is_color_surface = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
> + AddrSurfInfoIn.flags.color = is_color_surface &&
> +  !(surf->flags & 
> RADEON_SURF_NO_RENDER_TARGET);
>   AddrSurfInfoIn.flags.depth = (surf->flags & RADEON_SURF_ZBUFFER) != 0;
>   AddrSurfInfoIn.flags.cube = config->is_cube;
>   AddrSurfInfoIn.flags.display = get_display_flag(config, surf);
> @@ -923,7 +925,7 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
>   }
>   
>   /* Compute FMASK. */
> - if (config->info.samples >= 2 && AddrSurfInfoIn.flags.color) {
> + if (config->info.samples >= 2 && is_color_surface) {
>   ADDR_COMPUTE_FMASK_INFO_INPUT fin = {0};
>   ADDR_COMPUTE_FMASK_INFO_OUTPUT fout = {0};
>   ADDR_TILEINFO fmask_tile_info = {};

I'm not sure the gfx6 part is really applicable. At least we're not 
setting the texture bit here which makes me a bit uneasy.

The gfx9 part is

Reviewed-by: Nicolai Hähnle 

It makes some sense to have the extra flag there, it might result in 
better swizzling choices in some cases.

Cheers,
Nicolai


> @@ -1412,11 +1414,13 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,
>   AddrSurfInfoIn.bpp = surf->bpe * 8;
>   }
>   
> - AddrSurfInfoIn.flags.color = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
> + bool is_color_surface = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
> + AddrSurfInfoIn.flags.color = is_color_surface &&
> +  !(surf->flags & 
> RADEON_SURF_NO_RENDER_TARGET);
>   AddrSurfInfoIn.flags.depth = (surf->flags & RADEON_SURF_ZBUFFER) != 0;
>   AddrSurfInfoIn.flags.display = get_display_flag(config, surf);
>   /* flags.texture currently refers to TC-compatible HTILE */
> - AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color ||
> + AddrSurfInfoIn.flags.texture = is_color_surface ||
>  surf->flags & 
> RADEON_SURF_TC_COMPATIBLE_HTILE;
>   AddrSurfInfoIn.flags.opt4space = 1;
>   
> diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
> index 8ba964e64ec..7ae166c70a3 100644
> --- a/src/amd/common/ac_surface.h
> +++ b/src/amd/common/ac_surface.h
> @@ -68,6 +68,7 @@ enum radeon_micro_mode {
>   #define RADEON_SURF_IMPORTED(1 << 24)
>   #define RADEON_SURF_OPTIMIZE_FOR_SPACE  (1 << 25)
>   #define RADEON_SURF_SHAREABLE   (1 << 26)
> +#define RADEON_SURF_NO_RENDER_TARGET(1 << 27)
>   
>   struct legacy_surf_level {
>   uint64_toffset;
> diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
> index 59bc46d2fc8..48727817d32 100644
> --- a/src/amd/vulkan/radv_formats.c
> +++ b/src/amd/vulkan/radv_formats.c
> @@ -1112,6 +1112,18 @@ static VkResult 
> radv_get_image_format_properties(struct radv_physical_device *ph
>   maxMipLevels = 1;
>   }
>   
> +
> + /* We can't create 3d compressed 128bpp images that can be rendered to 
> on GFX9 */
> + if (physical_device->rad_info.chip_class >= GFX9 &&
> + info->type == VK_IMAGE_TYPE_3D &&
> + vk_format_get_blocksizebits(info->format) == 128 &&
> + vk_format_is_compressed(info->format) &&
> + (info->flags & VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT) &&
> + ((info->flags &  VK_IMAGE_CREATE_EXTENDED_USAGE_BIT) ||
> +  (info->usage & VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT))) {
> + goto unsupported;
> + }
> +
>   if (info->usage & VK_IMAGE_USAGE_SAMPLED_BIT) {
>   if (!(format_feature_flags & 
> VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT)) {
>   goto unsupported;
> diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
> index 2bd74e202fe..69bbcdcf645 

[Mesa-dev] [PATCH] meson: Fix libsensors detection.

[Vinson Lee]

Fixes: 5e71efef44b9 ("meson: Add lmsensors support")
Signed-off-by: Vinson Lee 
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 57dd8b59cb..d591ca377b 100644
--- a/meson.build
+++ b/meson.build
@@ -1395,7 +1395,7 @@ endif
 
 _sensors = get_option('lmsensors')
 if _sensors != 'false'
-  dep_lmsensors = cc.find_library('libsensors', required : _sensors == 'true')
+  dep_lmsensors = cc.find_library('sensors', required : _sensors == 'true')
   if dep_lmsensors.found()
 pre_args += '-DHAVE_LIBSENSORS=1'
   endif
-- 
2.19.1

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

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

[bugzilla-daemon]

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

--- Comment #10 from Dylan Baker  ---
Relevant to this change proposal though, lets say we have:

/usr/lib/libdrm*.2.4.75; /usr/local/lib/libdrm*.2.4.95
and
PKG_CONFIG_PATH=/usr/lib/pkg-config:/usr/local/lib/pkg-config

if our dependencies are:
libdrm_intel = 2.4.75
libdrm_radeonsi = 2.4.95

And we configure i915 and radeonsi, under your proposal wouldn't we end up with
both -L/usr/lib -ldrm -ldrm_intel and -L/usr/local/lib -ldrm -ldrm_amdgpu in
the link args of any target that requires both libdrm_intel and libdrm_amdgpu
since pkg-config will come along and say, "libdrm in /usr/lib is good enough
for intel", but then get to radeonsi and go, "nope we need the one in
/usr/local/lib for amdgpu"?

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

Re: [Mesa-dev] [PATCH] amd/surface: fix setting of ADDR2_SURFACE_FLAGS::color

[Haehnle, Nicolai]

On 18.12.18 18:36, Bas Nieuwenhuizen wrote:
> Hi Nicolai,
> 
> I happened to be writing something similar which also fixes up radv to
> never render to those surfaces as r32g32b32a32:
> https://patchwork.freedesktop.org/series/54172/ I can split out the
> radv specific stuff and this one is r-b after than.

Oh, I missed that, sorry. I don't particularly care about which approach 
to this is taken.

Cheers,
Nicolai



> 
> Thanks,
> Bas
> 
> On Tue, Dec 18, 2018 at 5:37 PM Nicolai Hähnle  wrote:
>>
>> From: Nicolai Hähnle 
>>
>> In the gfx9 addrlib, this bit has been clarified as meaning that
>> the surface can be used as a color buffer (render target).
>>
>> Setting this for compressed surfaces triggers a workaround that
>> is only required for surfaces that can be render targets, and ends
>> up breaking the 16-byte-per-block case.
>>
>> Fixes 
>> dEQP-VK.pipeline.image.suballocation.sampling_type.combined.view_type.3d.format.etc2_r8g8b8a8_srgb_block.count_1.size.11x11x11
>>  and others
>>
>> Note that there are other related bits which we don't set as intended
>> by the interface, notably the 'unordered' bit, which is meant to
>> indicate use as a shader image. It may be worth cleaning that up at some
>> point after proper testing.
>>
>> Reported-by: Samuel Pitoiset 
>> Fixes: 776b9113656 ("amd/addrlib: update Mesa's copy of addrlib")
>> ---
>>   src/amd/common/ac_surface.c | 5 ++---
>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
>> index d8d927ee1c5..d647bd523f9 100644
>> --- a/src/amd/common/ac_surface.c
>> +++ b/src/amd/common/ac_surface.c
>> @@ -1405,25 +1405,24 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,
>>  case 16:
>>  assert(!(surf->flags & RADEON_SURF_Z_OR_SBUFFER));
>>  AddrSurfInfoIn.format = ADDR_FMT_32_32_32_32;
>>  break;
>>  default:
>>  assert(0);
>>  }
>>  AddrSurfInfoIn.bpp = surf->bpe * 8;
>>  }
>>
>> -   AddrSurfInfoIn.flags.color = !(surf->flags & 
>> RADEON_SURF_Z_OR_SBUFFER);
>> +   AddrSurfInfoIn.flags.color = !compressed && !(surf->flags & 
>> RADEON_SURF_Z_OR_SBUFFER);
>>  AddrSurfInfoIn.flags.depth = (surf->flags & RADEON_SURF_ZBUFFER) != 
>> 0;
>>  AddrSurfInfoIn.flags.display = get_display_flag(config, surf);
>> -   /* flags.texture currently refers to TC-compatible HTILE */
>> -   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color ||
>> +   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color || 
>> compressed ||
>> surf->flags & 
>> RADEON_SURF_TC_COMPATIBLE_HTILE;
>>  AddrSurfInfoIn.flags.opt4space = 1;
>>
>>  AddrSurfInfoIn.numMipLevels = config->info.levels;
>>  AddrSurfInfoIn.numSamples = MAX2(1, config->info.samples);
>>  AddrSurfInfoIn.numFrags = AddrSurfInfoIn.numSamples;
>>
>>  if (!(surf->flags & RADEON_SURF_Z_OR_SBUFFER))
>>  AddrSurfInfoIn.numFrags = MAX2(1, 
>> config->info.storage_samples);
>>
>> --
>> 2.19.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

[bugzilla-daemon]

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

--- Comment #9 from Dylan Baker  ---
tl;dr: that only works if you can *always know* that you wont need a fallback
and that the only way to discover all of the dependencies is via pkg-config and
not via cmake or a *-config tool.

imagine you have something like this:

dep1 = dependency('foo', version : ['>= 1.0', '< 2.0'], fallback : ['foo',
'dep_foo'])
dep2 = dependency('bar', version : '> 2.1', fallback : ['bar', 'dep_bar'])
deps = [dep1, dep2]

Which says, find foo and bar, and if you can't find them (and fallbacks aren't
disabled) build subproject foo and get the declare_dependency object dep_foo
and return that, and do the same for bar.

Now, we could probably write this as:
deps = dependency(['foo', 'bar'], version : [['>= 1.0', '< 2.0'], '> 2.1'], 
fallback : [['foo', 'dep_foo'], ['bar', 'dep_bar']])

but that's a pretty confusing syntax, and if pkg-config fails then we still
have to either re-run it once for each dependency and put all of that together,
or parse the human readable output and try to figure out which dependencies
were missing, and rerun with on the the ones that were found and then fallback
to the rest.

The imagine that bar only provides a BarConfig.CMake file, or that bar provides
both cmake and pkg-config, or that it only provides a bar-config script.

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

Re: [Mesa-dev] [PATCH] egl/wayland: break double/tripple buffering feedback loops

[Emil Velikov]

On Tue, 18 Dec 2018 at 11:16, Lucas Stach  wrote:
>
> Currently we dispose any unneeded color buffers immediately if we detect that
> there are more unlocked buffers than we need. This can lead to feedback loops
> between the compositor and the application causing rapid toggling between
> double and tripple buffering. Scenario: 2 buffers already qeued to the
> compositor, egl/wayland allocates a new back buffer to avoid trottling,
> slowing down the frame, this allows the compositor to catch up and unlock
> both buffers, then EGL detects that there are more buffers than currently
> need, freeing the buffer, restartig the loop shortly after.
>
> To avoid wasting CPU time on rapidly freeing and reallocating color buffers
> break those feedback loops by letting the unneeded buffers sit around for a
> short while before disposing them.
>
> Signed-off-by: Lucas Stach 
> ---
>  src/egl/drivers/dri2/platform_wayland.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_wayland.c 
> b/src/egl/drivers/dri2/platform_wayland.c
> index 34e09d7ec167..3fa08c1639d1 100644
> --- a/src/egl/drivers/dri2/platform_wayland.c
> +++ b/src/egl/drivers/dri2/platform_wayland.c
> @@ -474,15 +474,17 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
> wl_display_dispatch_queue_pending(dri2_dpy->wl_dpy, dri2_surf->wl_queue);
>
> while (dri2_surf->back == NULL) {
> +  int age = 0;
>for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
>   /* Get an unlocked buffer, preferably one with a dri_buffer
>* already allocated. */
> - if (dri2_surf->color_buffers[i].locked)
> + if (dri2_surf->color_buffers[i].locked || 
> dri2_surf->color_buffers[i].age < age)
>  continue;
>   if (dri2_surf->back == NULL)
>  dri2_surf->back = _surf->color_buffers[i];
> - else if (dri2_surf->back->dri_image == NULL)
> + else if (dri2_surf->back->dri_image == NULL && 
> dri2_surf->color_buffers[i].dri_image)
>  dri2_surf->back = _surf->color_buffers[i];
> + age = dri2_surf->back->age;
>}
>
AFAICT this is the wayland equivalent of
4f1d27a406478d405eac6f9894ccc46a80034adb
Where the exact same logic/commit message applies.

Can you please split that up? I'd imagine this isn't enough to for the
usecase you had in mind?

>if (dri2_surf->back)
> @@ -615,10 +617,13 @@ update_buffers(struct dri2_egl_surface *dri2_surf)
>
> /* If we have an extra unlocked buffer at this point, we had to do triple
>  * buffering for a while, but now can go back to just double buffering.
> -* That means we can free any unlocked buffer now. */
> +* That means we can free any unlocked buffer now. To avoid toggling 
> between
> +* going back to double buffering and needing to allocate third buffer too
> +* fast we let the unneeded buffer sit around for a short while. */
> for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
>if (!dri2_surf->color_buffers[i].locked &&
> -  dri2_surf->color_buffers[i].wl_buffer) {
> +  dri2_surf->color_buffers[i].wl_buffer &&
> +  dri2_surf->color_buffers[i].age > 18) {

The age check here seems strange - both number used and it's relation
to double/triple buffering.
Have you considered tracking/checking how many buffers we have?

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

Re: [Mesa-dev] [PATCH mesa] meson: add missing tegra vdpau driver

[Eric Engestrom]

On December 18, 2018 5:36:19 PM UTC, Dylan Baker  wrote:
> Quoting Ilia Mirkin (2018-12-06 09:39:25)
> > On Thu, Dec 6, 2018 at 12:17 PM Eric Engestrom
>  wrote:
> > >
> > > On Thursday, 2018-12-06 12:07:06 -0500, Ilia Mirkin wrote:
> > > > Under what circumstances would tegra have a vdpau
> implementation?
> > >
> > > I don't know about that, but this patch brings meson on par with
> > > autotools. Are you saying autotools was wrong and it should be
> removed
> > > there instead?
> > >
> > > FtR, src/gallium/targets/vdpau/Makefile.am includes
> > > src/gallium/drivers/tegra/Automake.inc which adds tegra to the
> > > TARGET_DRIVERS, which in turn produces libvdpau_tegra.so
> > >
> > > If this was wrong, then that include on line 60 of
> > > src/gallium/targets/vdpau/Makefile.am should be removed.
> > >
> > > This line was added by Thierry Reding (cc'ed) when he first
> introduced
> > > tegra support in 1755f608f5201e0a23f00 "tegra: Initial support".
> > 
> > I'd like to hear tagr opine on this, but AFAIK tegra is a
> > renderonly-style driver, which uses nouveau as its actual rendering
> > backend. While nouveau does support VDPAU, the decoding engines are
> > not available as part of the GPU device on Tegra platforms. They
> still
> > have decoders, they're just separate platform devices (which I
> suspect
> > operate very similarly to their desktop GPU counterparts, but that's
> a
> > separate matter).
> > 
> >   -ilia
> 
> Ping?

I suggest we land this patch to bring meson on par with autotools, and if we 
decide later
that autotools was wrong, we can just remove it from both places at once; ack?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Nicolai Hähnle]

On 17.12.18 23:46, Dylan Baker wrote:

Quoting Marek Olšák (2018-12-17 12:25:29)

On Mon, Dec 17, 2018 at 1:18 PM Eric Anholt  wrote:

 Eero Tamminen  writes:

 > Hi,
 >
 > On 17.12.2018 8.08, Marek Olšák wrote:
 > [...]
 >> I think one of the serious usability issues is that environment
 >> variables such as CFLAGS, CXXFLAGS, LDFLAGS, and PKG_CONFIG_PATH are not
 >> saved by meson for future reconfigures.
 >
 > I don't know what Meson is supposed to do, but to me that would be
 > a bug in a build tool.
 >
 > Re-configure is supposed to adapt SW to the changes in the build
 > environment, and environment variables are part of that (along with
 > command line options and SW installed to to the system).  Build
 > configure tool deciding to "remember" some of those things instead
 > of checking the new situation, seems like a great opportunity for
 > confusion.

 A user-triggered reconfigure, sure.  Recapture env vars then.  But "git
 pull; ninja -C build" losing track of the configuration state is broken.
 We don't have to specify all of your meson -Doption=state configuration
 on every build, why should you need to specify your PKG_CONFIG_PATH
 configure options on every build?


Thanks, Eric.

Yes, meson behaves such that users have to set all environment variables for
every "ninja" command that might reconfigure.

I see 2 solutions:
1) meson needs to remember the relevant env vars
2) meson should FAIL to configure if any of the env vars are set (if it wants
to ignore them)

Marek


Meson does remember the *_FLAGS variables. Those are translated on configure
into meson's internal ${lang}_args and ${lang}_link args. It does look like
those aren't remembered when --wipe is called though, I filed a bug for that:
https://github.com/mesonbuild/meson/issues/4650


I ran into this same problem and noticed that Meson is already able to 
*warn* about such changes.


It should either ignore the changes, or better yet, fail.

(Or even better: ignore environment variables entirely; IMO sourcing the 
environment implicitly in a build system with an explicit configure is 
just a broken design that was unfortunately inherited from plain make 
without really considering the UI implications.)


Cheers,
Nicolai




Dylan


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



--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] amd/surface: fix setting of ADDR2_SURFACE_FLAGS::color

[Bas Nieuwenhuizen]

Hi Nicolai,

I happened to be writing something similar which also fixes up radv to
never render to those surfaces as r32g32b32a32:
https://patchwork.freedesktop.org/series/54172/ I can split out the
radv specific stuff and this one is r-b after than.

Thanks,
Bas

On Tue, Dec 18, 2018 at 5:37 PM Nicolai Hähnle  wrote:
>
> From: Nicolai Hähnle 
>
> In the gfx9 addrlib, this bit has been clarified as meaning that
> the surface can be used as a color buffer (render target).
>
> Setting this for compressed surfaces triggers a workaround that
> is only required for surfaces that can be render targets, and ends
> up breaking the 16-byte-per-block case.
>
> Fixes 
> dEQP-VK.pipeline.image.suballocation.sampling_type.combined.view_type.3d.format.etc2_r8g8b8a8_srgb_block.count_1.size.11x11x11
>  and others
>
> Note that there are other related bits which we don't set as intended
> by the interface, notably the 'unordered' bit, which is meant to
> indicate use as a shader image. It may be worth cleaning that up at some
> point after proper testing.
>
> Reported-by: Samuel Pitoiset 
> Fixes: 776b9113656 ("amd/addrlib: update Mesa's copy of addrlib")
> ---
>  src/amd/common/ac_surface.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index d8d927ee1c5..d647bd523f9 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -1405,25 +1405,24 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,
> case 16:
> assert(!(surf->flags & RADEON_SURF_Z_OR_SBUFFER));
> AddrSurfInfoIn.format = ADDR_FMT_32_32_32_32;
> break;
> default:
> assert(0);
> }
> AddrSurfInfoIn.bpp = surf->bpe * 8;
> }
>
> -   AddrSurfInfoIn.flags.color = !(surf->flags & 
> RADEON_SURF_Z_OR_SBUFFER);
> +   AddrSurfInfoIn.flags.color = !compressed && !(surf->flags & 
> RADEON_SURF_Z_OR_SBUFFER);
> AddrSurfInfoIn.flags.depth = (surf->flags & RADEON_SURF_ZBUFFER) != 0;
> AddrSurfInfoIn.flags.display = get_display_flag(config, surf);
> -   /* flags.texture currently refers to TC-compatible HTILE */
> -   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color ||
> +   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color || 
> compressed ||
>surf->flags & 
> RADEON_SURF_TC_COMPATIBLE_HTILE;
> AddrSurfInfoIn.flags.opt4space = 1;
>
> AddrSurfInfoIn.numMipLevels = config->info.levels;
> AddrSurfInfoIn.numSamples = MAX2(1, config->info.samples);
> AddrSurfInfoIn.numFrags = AddrSurfInfoIn.numSamples;
>
> if (!(surf->flags & RADEON_SURF_Z_OR_SBUFFER))
> AddrSurfInfoIn.numFrags = MAX2(1, 
> config->info.storage_samples);
>
> --
> 2.19.1
>
> ___
> 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 mesa] meson: add missing tegra vdpau driver

[Dylan Baker]

Quoting Ilia Mirkin (2018-12-06 09:39:25)
> On Thu, Dec 6, 2018 at 12:17 PM Eric Engestrom  
> wrote:
> >
> > On Thursday, 2018-12-06 12:07:06 -0500, Ilia Mirkin wrote:
> > > Under what circumstances would tegra have a vdpau implementation?
> >
> > I don't know about that, but this patch brings meson on par with
> > autotools. Are you saying autotools was wrong and it should be removed
> > there instead?
> >
> > FtR, src/gallium/targets/vdpau/Makefile.am includes
> > src/gallium/drivers/tegra/Automake.inc which adds tegra to the
> > TARGET_DRIVERS, which in turn produces libvdpau_tegra.so
> >
> > If this was wrong, then that include on line 60 of
> > src/gallium/targets/vdpau/Makefile.am should be removed.
> >
> > This line was added by Thierry Reding (cc'ed) when he first introduced
> > tegra support in 1755f608f5201e0a23f00 "tegra: Initial support".
> 
> I'd like to hear tagr opine on this, but AFAIK tegra is a
> renderonly-style driver, which uses nouveau as its actual rendering
> backend. While nouveau does support VDPAU, the decoding engines are
> not available as part of the GPU device on Tegra platforms. They still
> have decoders, they're just separate platform devices (which I suspect
> operate very similarly to their desktop GPU counterparts, but that's a
> separate matter).
> 
>   -ilia

Ping?


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

[Mesa-dev] [PATCH] amd/surface: fix setting of ADDR2_SURFACE_FLAGS::color

[Nicolai Hähnle]

From: Nicolai Hähnle 

In the gfx9 addrlib, this bit has been clarified as meaning that
the surface can be used as a color buffer (render target).

Setting this for compressed surfaces triggers a workaround that
is only required for surfaces that can be render targets, and ends
up breaking the 16-byte-per-block case.

Fixes 
dEQP-VK.pipeline.image.suballocation.sampling_type.combined.view_type.3d.format.etc2_r8g8b8a8_srgb_block.count_1.size.11x11x11
 and others

Note that there are other related bits which we don't set as intended
by the interface, notably the 'unordered' bit, which is meant to
indicate use as a shader image. It may be worth cleaning that up at some
point after proper testing.

Reported-by: Samuel Pitoiset 
Fixes: 776b9113656 ("amd/addrlib: update Mesa's copy of addrlib")
---
 src/amd/common/ac_surface.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index d8d927ee1c5..d647bd523f9 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -1405,25 +1405,24 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,
case 16:
assert(!(surf->flags & RADEON_SURF_Z_OR_SBUFFER));
AddrSurfInfoIn.format = ADDR_FMT_32_32_32_32;
break;
default:
assert(0);
}
AddrSurfInfoIn.bpp = surf->bpe * 8;
}
 
-   AddrSurfInfoIn.flags.color = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
+   AddrSurfInfoIn.flags.color = !compressed && !(surf->flags & 
RADEON_SURF_Z_OR_SBUFFER);
AddrSurfInfoIn.flags.depth = (surf->flags & RADEON_SURF_ZBUFFER) != 0;
AddrSurfInfoIn.flags.display = get_display_flag(config, surf);
-   /* flags.texture currently refers to TC-compatible HTILE */
-   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color ||
+   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color || compressed 
||
   surf->flags & 
RADEON_SURF_TC_COMPATIBLE_HTILE;
AddrSurfInfoIn.flags.opt4space = 1;
 
AddrSurfInfoIn.numMipLevels = config->info.levels;
AddrSurfInfoIn.numSamples = MAX2(1, config->info.samples);
AddrSurfInfoIn.numFrags = AddrSurfInfoIn.numSamples;
 
if (!(surf->flags & RADEON_SURF_Z_OR_SBUFFER))
AddrSurfInfoIn.numFrags = MAX2(1, config->info.storage_samples);
 
-- 
2.19.1

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

[Mesa-dev] [Bug 108720] System crash vulkan cemu

[bugzilla-daemon]

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

--- Comment #1 from Samuel Pitoiset  ---
Are you still able to reproduce? If yes, can you give more info like dmesg and
eventually a renderdoc or apitrace capture, please?

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

[Mesa-dev] [Bug 105049] Invalid usage of vulkan pipeline barriers can cause amdgpu to deadlock

[bugzilla-daemon]

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

--- Comment #7 from Samuel Pitoiset  ---
Well, the validation layers report a bunch of errors with your app, like:

Validation layer: (F8)  [ VUID-vkCmdEndRenderPass-commandBuffer-cmdpool ]
Object: 0x5638b8e4f6b0 (Type = 6) | Cannot call vkCmdEndRenderPass() on a
command buffer allocated from a pool without VK_QUEUE_GRAPHICS_BIT
capabilities.. The Vulkan spec states: The VkCommandPool that commandBuffer was
allocated from must support graphics operations
(https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkCmdEndRenderPass-commandBuffer-cmdpool)

Validation layer: (F8)  [
UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object: 0x5638b8279a80
(Type = 6) | Submitted command buffer expects image 0x3 (subresource:
aspectMask 0x1 array layer 0, mip level 0) to be in layout
VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL--instead, image 0x3's current layout
is VK_IMAGE_LAYOUT_UNDEFINED.

Validation layer: (F8)  [ VUID-vkCmdBeginRenderPass-commandBuffer-cmdpool ]
Object: 0x5638b8e5a3f0 (Type = 6) | Cannot call vkCmdBeginRenderPass() on a
command buffer allocated from a pool without VK_QUEUE_GRAPHICS_BIT
capabilities.. The Vulkan spec states: The VkCommandPool that commandBuffer was
allocated from must support graphics operations
(https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkCmdBeginRenderPass-commandBuffer-cmdpool)

As Vulkan is a low-level API, it's not surprising that the GPU hangs if you do
something bad. The first step is to *always* enable the validation layers in
order to make sure your application is correct. If after fixing all errors the
GPU still hangs with RADV, it might be a problem in the driver.

Feel free to re-open if the problem still happens after making sure you use the
API the right way.

Thanks!

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

[Mesa-dev] [Bug 105049] Invalid usage of vulkan pipeline barriers can cause amdgpu to deadlock

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

 Resolution|FIXED   |NOTOURBUG

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

[Mesa-dev] [Bug 105049] Invalid usage of vulkan pipeline barriers can cause amdgpu to deadlock

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

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

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

Re: [Mesa-dev] [PATCH 1/2] bin/get-pick-list.sh: rework handing of sha nominations

[Andres Gomez]

On Tue, 2018-12-18 at 10:47 +, Emil Velikov wrote:
> On Mon, 17 Dec 2018 at 22:35, Andres Gomez  wrote:
> > 
> > On Mon, 2018-12-17 at 18:36 +, Emil Velikov wrote:
> > > On Mon, 17 Dec 2018 at 18:14, Andres Gomez  wrote:
> > > > 
> > > > On Mon, 2018-12-17 at 16:43 +, Emil Velikov wrote:
> > > > > Currently our is_sha_nomination does:
> > > > >  - folds any whitespace, attempting to extract sha-like information
> > > > >  - checks that at least one of the shas has landed
> > > > > 
> > > > > Split it in two and do sha-like validation first.
> > > > > 
> > > > > This way, commits with mesa-stable and sha nominations will feature 
> > > > > the
> > > > > fixes/revert/etc instead of stable (a) or will be omitted if not
> > > > > applicable for the respective branch (b).
> > > > > 
> > > > > Misc examples from 18.3
> > > > > 
> > > > > (a)
> > > > > -[   stable ] 5bc509363b6 glx: make xf86vidmode mandatory for direct 
> > > > > rendering
> > > > > +[fixes ] 5bc509363b6 glx: make xf86vidmode mandatory for direct 
> > > > > rendering
> > > > > 
> > > > > (b)
> > > > > -[   stable ] 9a7b3199037 anv/query: flush render target before 
> > > > > copying results
> > > > > 
> > > > > CC: Andres Gomez 
> > > > > CC: Juan A. Suarez 
> > > > > CC: Dylan Baker 
> > > > > CC: mesa-sta...@lists.freedesktop.org
> > > > > Signed-off-by: Emil Velikov 
> > > > > ---
> > > > > Juan I've noticed that you've been experiencing the above annoyance 
> > > > > for
> > > > > a while. Having less false-positives should ease things up a bit :-)
> > > > > ---
> > > > >  bin/get-pick-list.sh | 46 
> > > > > +---
> > > > >  1 file changed, 30 insertions(+), 16 deletions(-)
> > > > > 
> > > > > diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
> > > > > index 9f9cbc44026..08a783f35a8 100755
> > > > > --- a/bin/get-pick-list.sh
> > > > > +++ b/bin/get-pick-list.sh
> > > > > @@ -21,32 +21,36 @@ is_typod_nomination()
> > > > >   git show --summary "$1" | grep -q -i -o "CC:.*mesa-dev"
> > > > >  }
> > > > > 
> > > > > +fixes=
> > > > > +
> > > > 
> > > > Splitting in 2 functions for which we need now a global variable is not
> > > > very nice. Anyway, let's not make this more complicated than needed.
> > > > 
> > > 
> > > Wasn't too happy about it either. As you said - I've decided to go
> > > with the simpler solution.
> > > 
> > > > >  # Helper to handle various mistypos of the fixes tag.
> > > > >  # The tag string itself is passed as argument and normalised within.
> > > > > +#
> > > > > +# Resulting string in the global variable "fixes" and contains 
> > > > > entries
> > > > > +# in the form "fixes:$sha"
> > > > >  is_sha_nomination()
> > > > >  {
> > > > >   fixes=`git show --pretty=medium -s $1 | tr -d "\n" | \
> > > > >   sed -e 's/'"$2"'/\nfixes:/Ig' | \
> > > > >   grep -Eo 'fixes:[a-f0-9]{8,40}'`
> > > > > 
> > > > > - fixes_count=`echo "$fixes" | wc -l`
> > > > > + fixes_count=`echo "$fixes" | grep "fixes:" | wc -l`
> > > > 
> > > > Why is the extra "grep" needed here?
> > > > 
> > > 
> > > Commits that include "fixes $some_test" will result in fixes="".
> > > Thus wc -l will return 1
> > 
> > Argh!
> > 
> > Well, this is more a consequence of wc counting newline characters and
> > echo adding a new one at the end, even when not printing anything.
> > Let's grep again, then ☹
> > 
> > > > >   if test $fixes_count -eq 0; then
> > > > > - return 0
> > > > > + return 1
> > > > 
> > > > Ugh! Right.
> > > > 
> > > > >   fi
> > > > > + return 0
> > > > > +}
> > > > > +
> > > > > +# Checks if at least one of offending commits, listed in the global
> > > > > +# "fixes", is in branch.
> > > > > +sha_in_range()
> > > > > +{
> > > > > + fixes_count=`echo "$fixes" | grep "fixes:" | wc -l`
> > > > 
> > > > Ditto.
> > > > 
> > > > >   while test $fixes_count -gt 0; do
> > > > >   # Treat only the current line
> > > > >   id=`echo "$fixes" | tail -n $fixes_count | head -n 1 | 
> > > > > cut -d : -f 2`
> > > > >   fixes_count=$(($fixes_count-1))
> > > > > 
> > > > > - # Bail out if we cannot find suitable id.
> > > > > - # Any specific validation the $id is valid and not some 
> > > > > junk, is
> > > > > - # implied with the follow up code
> > > > > - if test "x$id" = x; then
> > > > > - continue
> > > > > - fi
> > > > > -
> > > > > - #Check if the offending commit is in branch.
> > > > > -
> > > > 
> > > > Was this never needed in the first place? Feels right to remove it
> > > > since $fixes should have some content by now, but I wonder how this got
> > > > here in the first place.
> > > > 
> > > 
> > > Left-over from the old standalone script. Copied a bit too much :-(
> > > 
> > > > >   # Be that cherry-picked ...
> > > > >   # ... or landed before 

[Mesa-dev] [Bug 105207] The Talos Principle freezes system using radv

[bugzilla-daemon]

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

--- Comment #12 from Samuel Pitoiset  ---
Are you still able to reproduce this? FWIW, I launch Talos with different
settings almost every week and I never got any GPU hangs.

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

Re: [Mesa-dev] [PATCH v3] freedreno/ir3: Make imageStore use num components from image format

[Ilia Mirkin]

On Tue, Dec 18, 2018 at 9:42 AM Eduardo Lima Mitev  wrote:
>
> emit_intrinsic_store_image() is always using 4 components when
> collecting registers for the value. When image has less than
> 4 components (e.g, r32f, r32i, r32ui) this results in extra mov
> instructions.
>
> This patch uses the actual number of components from the image format.
>
> For example, in a shader like:
>
> layout (r32f, binding=0) writeonly uniform imageBuffer u_image;
> ...
> void main(void) {
>...
>imageStore (u_image, some_offset, vec4(1.0));
>...
> }
>
> instruction count is reduced in at least 3 instructions (note image
> format is r32f, 1 component only).
>
> This obviously reduces register pressure as well.
>
> v2: - Added support for image formats from NV_image_format extension
> (Ilia Mirkin).
> - Return 4 components by default instead of asserting. (Rob Clark).
>
> v3: Added more missing formats (Ilia Mirkin).
> ---
>  src/freedreno/ir3/ir3_compiler_nir.c | 69 +++-
>  1 file changed, 67 insertions(+), 2 deletions(-)
>
> diff --git a/src/freedreno/ir3/ir3_compiler_nir.c 
> b/src/freedreno/ir3/ir3_compiler_nir.c
> index 85f14f354d2..80f6f70475d 100644
> --- a/src/freedreno/ir3/ir3_compiler_nir.c
> +++ b/src/freedreno/ir3/ir3_compiler_nir.c
> @@ -1251,6 +1251,70 @@ emit_intrinsic_load_image(struct ir3_context *ctx, 
> nir_intrinsic_instr *intr,
> ir3_split_dest(b, dst, sam, 0, 4);
>  }
>
> +/* Returns the number of components for the different image formats
> + * supported by the GLES 3.1 spec, plus those added by the
> + * GL_NV_image_formats extension.
> + */
> +static unsigned
> +get_num_components_for_glformat(GLuint format)
> +{
> +   switch (format) {
> +   case GL_R32F:
> +   case GL_R32I:
> +   case GL_R32UI:
> +   case GL_R16F:
> +   case GL_R16I:
> +   case GL_R16UI:
> +   case GL_R16:
> +   case GL_R16_SNORM:
> +   case GL_R8I:
> +   case GL_R8UI:
> +   case GL_R8:
> +   case GL_R8_SNORM:
> +   return 1;
> +
> +   case GL_RG32F:
> +   case GL_RG32I:
> +   case GL_RG32UI:
> +   case GL_RG16F:
> +   case GL_RG16I:
> +   case GL_RG16UI:
> +   case GL_RG16:
> +   case GL_RG16_SNORM:
> +   case GL_RG8I:
> +   case GL_RG8UI:
> +   case GL_RG8:
> +   case GL_RG8_SNORM:
> +   return 2;
> +
> +   case GL_R11F_G11F_B10F:
> +   return 3;
> +
> +   case GL_RGBA32F:
> +   case GL_RGBA32I:
> +   case GL_RGBA32UI:
> +   case GL_RGBA16F:
> +   case GL_RGBA16I:
> +   case GL_RGBA16UI:
> +   case GL_RGBA16:
> +   case GL_RGBA16_SNORM:
> +   case GL_RGBA8:

You don't have to resend for this, but all the others go

F (if exists)
I
UI
(UNORM)
SNORM

While here you have the UNORM first. So please move it down right above SNORM.

> +   case GL_RGBA8I:
> +   case GL_RGBA8UI:
> +   case GL_RGBA8_SNORM:
> +   case GL_RGB10_A2UI:
> +   case GL_RGB10_A2:
> +   return 4;
> +
> +   default:
> +   /* Return 4 components also for all other formats we don't 
> know
> +* about. This is always safe. Also, the format should have 
> been
> +* validated already by the higher level API.
> +*/
> +   return 4;
> +   }
> +}
> +
>  /* src[] = { deref, coord, sample_index, value }. const_index[] = {} */
>  static void
>  emit_intrinsic_store_image(struct ir3_context *ctx, nir_intrinsic_instr 
> *intr)
> @@ -1262,6 +1326,7 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
> nir_intrinsic_instr *intr)
> struct ir3_instruction * const *coords = ir3_get_src(ctx, 
> >src[1]);
> unsigned ncoords = get_image_coords(var, NULL);
> unsigned tex_idx = get_image_slot(ctx, 
> nir_src_as_deref(intr->src[0]));
> +   unsigned ncomp = 
> get_num_components_for_glformat(var->data.image.format);
>
> /* src0 is value
>  * src1 is coords
> @@ -1276,10 +1341,10 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
> nir_intrinsic_instr *intr)
>  */
>
> stib = ir3_STIB(b, create_immed(b, tex_idx), 0,
> -   ir3_create_collect(ctx, value, 4), 0,
> +   ir3_create_collect(ctx, value, ncomp), 0,
> ir3_create_collect(ctx, coords, ncoords), 0,
> offset, 0);
> -   stib->cat6.iim_val = 4;
> +   stib->cat6.iim_val = ncomp;
> stib->cat6.d = ncoords;
> stib->cat6.type = get_image_type(var);
> stib->cat6.typed = true;

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

[Mesa-dev] [PATCH v3] freedreno/ir3: Make imageStore use num components from image format

[Eduardo Lima Mitev]

emit_intrinsic_store_image() is always using 4 components when
collecting registers for the value. When image has less than
4 components (e.g, r32f, r32i, r32ui) this results in extra mov
instructions.

This patch uses the actual number of components from the image format.

For example, in a shader like:

layout (r32f, binding=0) writeonly uniform imageBuffer u_image;
...
void main(void) {
   ...
   imageStore (u_image, some_offset, vec4(1.0));
   ...
}

instruction count is reduced in at least 3 instructions (note image
format is r32f, 1 component only).

This obviously reduces register pressure as well.

v2: - Added support for image formats from NV_image_format extension
(Ilia Mirkin).
- Return 4 components by default instead of asserting. (Rob Clark).

v3: Added more missing formats (Ilia Mirkin).
---
 src/freedreno/ir3/ir3_compiler_nir.c | 69 +++-
 1 file changed, 67 insertions(+), 2 deletions(-)

diff --git a/src/freedreno/ir3/ir3_compiler_nir.c 
b/src/freedreno/ir3/ir3_compiler_nir.c
index 85f14f354d2..80f6f70475d 100644
--- a/src/freedreno/ir3/ir3_compiler_nir.c
+++ b/src/freedreno/ir3/ir3_compiler_nir.c
@@ -1251,6 +1251,70 @@ emit_intrinsic_load_image(struct ir3_context *ctx, 
nir_intrinsic_instr *intr,
ir3_split_dest(b, dst, sam, 0, 4);
 }
 
+/* Returns the number of components for the different image formats
+ * supported by the GLES 3.1 spec, plus those added by the
+ * GL_NV_image_formats extension.
+ */
+static unsigned
+get_num_components_for_glformat(GLuint format)
+{
+   switch (format) {
+   case GL_R32F:
+   case GL_R32I:
+   case GL_R32UI:
+   case GL_R16F:
+   case GL_R16I:
+   case GL_R16UI:
+   case GL_R16:
+   case GL_R16_SNORM:
+   case GL_R8I:
+   case GL_R8UI:
+   case GL_R8:
+   case GL_R8_SNORM:
+   return 1;
+
+   case GL_RG32F:
+   case GL_RG32I:
+   case GL_RG32UI:
+   case GL_RG16F:
+   case GL_RG16I:
+   case GL_RG16UI:
+   case GL_RG16:
+   case GL_RG16_SNORM:
+   case GL_RG8I:
+   case GL_RG8UI:
+   case GL_RG8:
+   case GL_RG8_SNORM:
+   return 2;
+
+   case GL_R11F_G11F_B10F:
+   return 3;
+
+   case GL_RGBA32F:
+   case GL_RGBA32I:
+   case GL_RGBA32UI:
+   case GL_RGBA16F:
+   case GL_RGBA16I:
+   case GL_RGBA16UI:
+   case GL_RGBA16:
+   case GL_RGBA16_SNORM:
+   case GL_RGBA8:
+   case GL_RGBA8I:
+   case GL_RGBA8UI:
+   case GL_RGBA8_SNORM:
+   case GL_RGB10_A2UI:
+   case GL_RGB10_A2:
+   return 4;
+
+   default:
+   /* Return 4 components also for all other formats we don't know
+* about. This is always safe. Also, the format should have been
+* validated already by the higher level API.
+*/
+   return 4;
+   }
+}
+
 /* src[] = { deref, coord, sample_index, value }. const_index[] = {} */
 static void
 emit_intrinsic_store_image(struct ir3_context *ctx, nir_intrinsic_instr *intr)
@@ -1262,6 +1326,7 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
nir_intrinsic_instr *intr)
struct ir3_instruction * const *coords = ir3_get_src(ctx, 
>src[1]);
unsigned ncoords = get_image_coords(var, NULL);
unsigned tex_idx = get_image_slot(ctx, nir_src_as_deref(intr->src[0]));
+   unsigned ncomp = 
get_num_components_for_glformat(var->data.image.format);
 
/* src0 is value
 * src1 is coords
@@ -1276,10 +1341,10 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
nir_intrinsic_instr *intr)
 */
 
stib = ir3_STIB(b, create_immed(b, tex_idx), 0,
-   ir3_create_collect(ctx, value, 4), 0,
+   ir3_create_collect(ctx, value, ncomp), 0,
ir3_create_collect(ctx, coords, ncoords), 0,
offset, 0);
-   stib->cat6.iim_val = 4;
+   stib->cat6.iim_val = ncomp;
stib->cat6.d = ncoords;
stib->cat6.type = get_image_type(var);
stib->cat6.typed = true;
-- 
2.19.2

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

Re: [Mesa-dev] [PATCH v2 13/24] mapi/new: don't print info we don't need for ES1/ES2

[Kyle Brenneman]

On 12/14/2018 07:04 AM, Emil Velikov wrote:

There is no need for the noop functions, the public_stubs and
public_entries table or table size defines. Remove those.

Pretty much all of this is applicable to GLVND, although it
requires preparatory work.

v2:
  - python style fixes (Dylan)
  - use "gldispatch" instead of not "glesv1" "glesv2"
  - remove the public_entries table/array (Erik)

Signed-off-by: Emil Velikov 
---
  src/mapi/new/gen_gldispatch_mapi.py | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/mapi/new/gen_gldispatch_mapi.py 
b/src/mapi/new/gen_gldispatch_mapi.py
index 959d8798f5c..cc0e286e221 100755
--- a/src/mapi/new/gen_gldispatch_mapi.py
+++ b/src/mapi/new/gen_gldispatch_mapi.py
@@ -63,11 +63,13 @@ typedef void (APIENTRY  *GLDEBUGPROCKHR)(GLenum 
source,GLenum type,GLuint id,GLe
  """.lstrip("\n"))
  
  print(generate_defines(functions))

-print(generate_table(functions, allFunctions))
-print(generate_noop_array(functions))
-print(generate_public_stubs(functions))
+if target in "gldispatch":
This should be an "==", not "in". The in operator would do a substring 
search.

+print(generate_table(functions, allFunctions))
+print(generate_noop_array(functions))
+print(generate_public_stubs(functions))
  print(generate_public_entries(functions))
-print(generate_public_entries_table(functions))
+if target in "gldispatch":
+print(generate_public_entries_table(functions))
  print(generate_undef_public_entries())
  print(generate_stub_asm_gcc(functions))
  


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

Re: [Mesa-dev] [PATCH v2] freedreno/ir3: Make imageStore use num components from image format

[Ilia Mirkin]

Looks like you missed the R*16_SNORM's (and UNORM's now that I look closer.)
On Tue, Dec 18, 2018 at 9:16 AM Eduardo Lima Mitev  wrote:
>
> emit_intrinsic_store_image() is always using 4 components when
> collecting registers for the value. When image has less than
> 4 components (e.g, r32f, r32i, r32ui) this results in extra mov
> instructions.
>
> This patch uses the actual number of components from the image format.
>
> For example, in a shader like:
>
> layout (r32f, binding=0) writeonly uniform imageBuffer u_image;
> ...
> void main(void) {
>...
>imageStore (u_image, some_offset, vec4(1.0));
>...
> }
>
> instruction count is reduced in at least 3 instructions (note image
> format is r32f, 1 component only).
>
> This obviously reduces register pressure as well.
>
> v2: - Added support for image formats from NV_image_format extension
> (Ilia Mirkin).
> - Return 4 components by default instead of asserting. (Rob Clark).
> ---
>  src/freedreno/ir3/ir3_compiler_nir.c | 63 +++-
>  1 file changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/src/freedreno/ir3/ir3_compiler_nir.c 
> b/src/freedreno/ir3/ir3_compiler_nir.c
> index 85f14f354d2..e33d2b8fd46 100644
> --- a/src/freedreno/ir3/ir3_compiler_nir.c
> +++ b/src/freedreno/ir3/ir3_compiler_nir.c
> @@ -1251,6 +1251,64 @@ emit_intrinsic_load_image(struct ir3_context *ctx, 
> nir_intrinsic_instr *intr,
> ir3_split_dest(b, dst, sam, 0, 4);
>  }
>
> +/* Returns the number of components for the different image formats
> + * supported by the GLES 3.1 spec, plus those added by the
> + * GL_NV_image_formats extension.
> + */
> +static unsigned
> +get_num_components_for_glformat(GLuint format)
> +{
> +   switch (format) {
> +   case GL_R32F:
> +   case GL_R16F:
> +   case GL_R32I:
> +   case GL_R32UI:
> +   case GL_R16I:
> +   case GL_R16UI:
> +   case GL_R8I:
> +   case GL_R8UI:
> +   case GL_R8:
> +   case GL_R8_SNORM:
> +   return 1;
> +
> +   case GL_RG32F:
> +   case GL_RG16F:
> +   case GL_RG32I:
> +   case GL_RG32UI:
> +   case GL_RG16I:
> +   case GL_RG16UI:
> +   case GL_RG8I:
> +   case GL_RG8UI:
> +   case GL_RG8:
> +   case GL_RG8_SNORM:
> +   return 2;
> +
> +   case GL_R11F_G11F_B10F:
> +   return 3;
> +
> +   case GL_RGBA32F:
> +   case GL_RGBA16F:
> +   case GL_RGBA8:
> +   case GL_RGBA8_SNORM:
> +   case GL_RGBA32I:
> +   case GL_RGBA16I:
> +   case GL_RGBA8I:
> +   case GL_RGBA32UI:
> +   case GL_RGBA16UI:
> +   case GL_RGBA8UI:
> +   case GL_RGB10_A2UI:
> +   case GL_RGB10_A2:
> +   return 4;
> +
> +   default:
> +   /* Return 4 components also for all other formats we don't 
> know
> +* about. This is always safe. Also, the format should have 
> been
> +* validated already by the higher level API.
> +*/
> +   return 4;
> +   }
> +}
> +
>  /* src[] = { deref, coord, sample_index, value }. const_index[] = {} */
>  static void
>  emit_intrinsic_store_image(struct ir3_context *ctx, nir_intrinsic_instr 
> *intr)
> @@ -1262,6 +1320,7 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
> nir_intrinsic_instr *intr)
> struct ir3_instruction * const *coords = ir3_get_src(ctx, 
> >src[1]);
> unsigned ncoords = get_image_coords(var, NULL);
> unsigned tex_idx = get_image_slot(ctx, 
> nir_src_as_deref(intr->src[0]));
> +   unsigned ncomp = 
> get_num_components_for_glformat(var->data.image.format);
>
> /* src0 is value
>  * src1 is coords
> @@ -1276,10 +1335,10 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
> nir_intrinsic_instr *intr)
>  */
>
> stib = ir3_STIB(b, create_immed(b, tex_idx), 0,
> -   ir3_create_collect(ctx, value, 4), 0,
> +   ir3_create_collect(ctx, value, ncomp), 0,
> ir3_create_collect(ctx, coords, ncoords), 0,
> offset, 0);
> -   stib->cat6.iim_val = 4;
> +   stib->cat6.iim_val = ncomp;
> stib->cat6.d = ncoords;
> stib->cat6.type = get_image_type(var);
> stib->cat6.typed = true;
> --
> 2.19.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] freedreno/ir3: Make imageStore use num components from image format

[Eduardo Lima Mitev]

emit_intrinsic_store_image() is always using 4 components when
collecting registers for the value. When image has less than
4 components (e.g, r32f, r32i, r32ui) this results in extra mov
instructions.

This patch uses the actual number of components from the image format.

For example, in a shader like:

layout (r32f, binding=0) writeonly uniform imageBuffer u_image;
...
void main(void) {
   ...
   imageStore (u_image, some_offset, vec4(1.0));
   ...
}

instruction count is reduced in at least 3 instructions (note image
format is r32f, 1 component only).

This obviously reduces register pressure as well.

v2: - Added support for image formats from NV_image_format extension
(Ilia Mirkin).
- Return 4 components by default instead of asserting. (Rob Clark).
---
 src/freedreno/ir3/ir3_compiler_nir.c | 63 +++-
 1 file changed, 61 insertions(+), 2 deletions(-)

diff --git a/src/freedreno/ir3/ir3_compiler_nir.c 
b/src/freedreno/ir3/ir3_compiler_nir.c
index 85f14f354d2..e33d2b8fd46 100644
--- a/src/freedreno/ir3/ir3_compiler_nir.c
+++ b/src/freedreno/ir3/ir3_compiler_nir.c
@@ -1251,6 +1251,64 @@ emit_intrinsic_load_image(struct ir3_context *ctx, 
nir_intrinsic_instr *intr,
ir3_split_dest(b, dst, sam, 0, 4);
 }
 
+/* Returns the number of components for the different image formats
+ * supported by the GLES 3.1 spec, plus those added by the
+ * GL_NV_image_formats extension.
+ */
+static unsigned
+get_num_components_for_glformat(GLuint format)
+{
+   switch (format) {
+   case GL_R32F:
+   case GL_R16F:
+   case GL_R32I:
+   case GL_R32UI:
+   case GL_R16I:
+   case GL_R16UI:
+   case GL_R8I:
+   case GL_R8UI:
+   case GL_R8:
+   case GL_R8_SNORM:
+   return 1;
+
+   case GL_RG32F:
+   case GL_RG16F:
+   case GL_RG32I:
+   case GL_RG32UI:
+   case GL_RG16I:
+   case GL_RG16UI:
+   case GL_RG8I:
+   case GL_RG8UI:
+   case GL_RG8:
+   case GL_RG8_SNORM:
+   return 2;
+
+   case GL_R11F_G11F_B10F:
+   return 3;
+
+   case GL_RGBA32F:
+   case GL_RGBA16F:
+   case GL_RGBA8:
+   case GL_RGBA8_SNORM:
+   case GL_RGBA32I:
+   case GL_RGBA16I:
+   case GL_RGBA8I:
+   case GL_RGBA32UI:
+   case GL_RGBA16UI:
+   case GL_RGBA8UI:
+   case GL_RGB10_A2UI:
+   case GL_RGB10_A2:
+   return 4;
+
+   default:
+   /* Return 4 components also for all other formats we don't know
+* about. This is always safe. Also, the format should have been
+* validated already by the higher level API.
+*/
+   return 4;
+   }
+}
+
 /* src[] = { deref, coord, sample_index, value }. const_index[] = {} */
 static void
 emit_intrinsic_store_image(struct ir3_context *ctx, nir_intrinsic_instr *intr)
@@ -1262,6 +1320,7 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
nir_intrinsic_instr *intr)
struct ir3_instruction * const *coords = ir3_get_src(ctx, 
>src[1]);
unsigned ncoords = get_image_coords(var, NULL);
unsigned tex_idx = get_image_slot(ctx, nir_src_as_deref(intr->src[0]));
+   unsigned ncomp = 
get_num_components_for_glformat(var->data.image.format);
 
/* src0 is value
 * src1 is coords
@@ -1276,10 +1335,10 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
nir_intrinsic_instr *intr)
 */
 
stib = ir3_STIB(b, create_immed(b, tex_idx), 0,
-   ir3_create_collect(ctx, value, 4), 0,
+   ir3_create_collect(ctx, value, ncomp), 0,
ir3_create_collect(ctx, coords, ncoords), 0,
offset, 0);
-   stib->cat6.iim_val = 4;
+   stib->cat6.iim_val = ncomp;
stib->cat6.d = ncoords;
stib->cat6.type = get_image_type(var);
stib->cat6.typed = true;
-- 
2.19.2

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

Re: [Mesa-dev] [Freedreno] [PATCH] freedreno/ir3: Make imageStore use num components from image format

[Eduardo Lima Mitev]

On 12/18/18 2:31 PM, Rob Clark wrote:
> On Mon, Dec 17, 2018 at 3:41 PM Eduardo Lima Mitev  wrote:
>>
>> emit_intrinsic_store_image() is always using 4 components when
>> collecting registers for the value. When image has less than
>> 4 components (e.g, r32f, r32i, r32ui) this results in extra mov
>> instructions.
>>
>> This patch uses the actual number of components from the image format.
>>
>> For example, in a shader like:
>>
>> layout (r32f, binding=0) writeonly uniform imageBuffer u_image;
>> ...
>> void main(void) {
>>...
>>imageStore (u_image, some_offset, vec4(1.0));
>>...
>> }
>>
>> instruction count is reduced in at least 3 instructions (note image
>> format is r32f, 1 component only).
>>
>> This obviously reduces register pressure as well.
>> ---
>>  src/freedreno/ir3/ir3_compiler_nir.c | 34 ++--
>>  1 file changed, 32 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/freedreno/ir3/ir3_compiler_nir.c 
>> b/src/freedreno/ir3/ir3_compiler_nir.c
>> index 85f14f354d2..cc00602c249 100644
>> --- a/src/freedreno/ir3/ir3_compiler_nir.c
>> +++ b/src/freedreno/ir3/ir3_compiler_nir.c
>> @@ -1251,6 +1251,35 @@ emit_intrinsic_load_image(struct ir3_context *ctx, 
>> nir_intrinsic_instr *intr,
>> ir3_split_dest(b, dst, sam, 0, 4);
>>  }
>>
>> +/* Get the number of components of the different image formats supported
>> + * by the GLES 3.1 spec.
>> + */
>> +static unsigned
>> +get_num_components_for_glformat(GLuint format)
>> +{
>> +   switch (format) {
>> +   case GL_R32F:
>> +   case GL_R32I:
>> +   case GL_R32UI:
>> +   return 1;
>> +
>> +   case GL_RGBA32F:
>> +   case GL_RGBA16F:
>> +   case GL_RGBA8:
>> +   case GL_RGBA8_SNORM:
>> +   case GL_RGBA32I:
>> +   case GL_RGBA16I:
>> +   case GL_RGBA8I:
>> +   case GL_RGBA32UI:
>> +   case GL_RGBA16UI:
>> +   case GL_RGBA8UI:
>> +   return 4;
>> +
>> +   default:
>> +   assert(!"Unsupported GL format for image");
> 
> One thought, default could still return 4, at least for release
> builds.. that should always be a safe fallback.  But I suppose
> addition of new formats maybe doesn't happen so much.
>

All things considered I think is better to make 4 components the
default. After all, we should not be in the business of validating
internal state at this point. And the worse case is we emit a few
unnecessary instructions.

>
> (There is no glsl_types helper for this?)
> 

I couldn't find any helper :(. There is glsl_get_components() but it
expects a glsl_type, and we have a GLformat enum. Also, this is only a
subset of GL formats that can be image textures.

> If we do have an assert, compile_assert() or ir3_context_error() would
> be nice, since (at least for debug builds) should print out the nir
> annotated w/ location of error, which I find convenient for debugging.
> 

Doesn't apply now that I've chosen to remove the assert, but I have
taken note!

Thanks,

Eduardo

> BR,
> -R
> 
> 
>> +   }
>> +}
>> +
>>  /* src[] = { deref, coord, sample_index, value }. const_index[] = {} */
>>  static void
>>  emit_intrinsic_store_image(struct ir3_context *ctx, nir_intrinsic_instr 
>> *intr)
>> @@ -1262,6 +1291,7 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
>> nir_intrinsic_instr *intr)
>> struct ir3_instruction * const *coords = ir3_get_src(ctx, 
>> >src[1]);
>> unsigned ncoords = get_image_coords(var, NULL);
>> unsigned tex_idx = get_image_slot(ctx, 
>> nir_src_as_deref(intr->src[0]));
>> +   unsigned ncomp = 
>> get_num_components_for_glformat(var->data.image.format);
>>
>> /* src0 is value
>>  * src1 is coords
>> @@ -1276,10 +1306,10 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
>> nir_intrinsic_instr *intr)
>>  */
>>
>> stib = ir3_STIB(b, create_immed(b, tex_idx), 0,
>> -   ir3_create_collect(ctx, value, 4), 0,
>> +   ir3_create_collect(ctx, value, ncomp), 0,
>> ir3_create_collect(ctx, coords, ncoords), 0,
>> offset, 0);
>> -   stib->cat6.iim_val = 4;
>> +   stib->cat6.iim_val = ncomp;
>> stib->cat6.d = ncoords;
>> stib->cat6.type = get_image_type(var);
>> stib->cat6.typed = true;
>> --
>> 2.19.2
>>
>> ___
>> Freedreno mailing list
>> freedr...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/freedreno
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Freedreno] [PATCH] freedreno/ir3: Make imageStore use num components from image format

[Rob Clark]

On Mon, Dec 17, 2018 at 3:41 PM Eduardo Lima Mitev  wrote:
>
> emit_intrinsic_store_image() is always using 4 components when
> collecting registers for the value. When image has less than
> 4 components (e.g, r32f, r32i, r32ui) this results in extra mov
> instructions.
>
> This patch uses the actual number of components from the image format.
>
> For example, in a shader like:
>
> layout (r32f, binding=0) writeonly uniform imageBuffer u_image;
> ...
> void main(void) {
>...
>imageStore (u_image, some_offset, vec4(1.0));
>...
> }
>
> instruction count is reduced in at least 3 instructions (note image
> format is r32f, 1 component only).
>
> This obviously reduces register pressure as well.
> ---
>  src/freedreno/ir3/ir3_compiler_nir.c | 34 ++--
>  1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/src/freedreno/ir3/ir3_compiler_nir.c 
> b/src/freedreno/ir3/ir3_compiler_nir.c
> index 85f14f354d2..cc00602c249 100644
> --- a/src/freedreno/ir3/ir3_compiler_nir.c
> +++ b/src/freedreno/ir3/ir3_compiler_nir.c
> @@ -1251,6 +1251,35 @@ emit_intrinsic_load_image(struct ir3_context *ctx, 
> nir_intrinsic_instr *intr,
> ir3_split_dest(b, dst, sam, 0, 4);
>  }
>
> +/* Get the number of components of the different image formats supported
> + * by the GLES 3.1 spec.
> + */
> +static unsigned
> +get_num_components_for_glformat(GLuint format)
> +{
> +   switch (format) {
> +   case GL_R32F:
> +   case GL_R32I:
> +   case GL_R32UI:
> +   return 1;
> +
> +   case GL_RGBA32F:
> +   case GL_RGBA16F:
> +   case GL_RGBA8:
> +   case GL_RGBA8_SNORM:
> +   case GL_RGBA32I:
> +   case GL_RGBA16I:
> +   case GL_RGBA8I:
> +   case GL_RGBA32UI:
> +   case GL_RGBA16UI:
> +   case GL_RGBA8UI:
> +   return 4;
> +
> +   default:
> +   assert(!"Unsupported GL format for image");

One thought, default could still return 4, at least for release
builds.. that should always be a safe fallback.  But I suppose
addition of new formats maybe doesn't happen so much.  (There is no
glsl_types helper for this?)

If we do have an assert, compile_assert() or ir3_context_error() would
be nice, since (at least for debug builds) should print out the nir
annotated w/ location of error, which I find convenient for debugging.

BR,
-R


> +   }
> +}
> +
>  /* src[] = { deref, coord, sample_index, value }. const_index[] = {} */
>  static void
>  emit_intrinsic_store_image(struct ir3_context *ctx, nir_intrinsic_instr 
> *intr)
> @@ -1262,6 +1291,7 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
> nir_intrinsic_instr *intr)
> struct ir3_instruction * const *coords = ir3_get_src(ctx, 
> >src[1]);
> unsigned ncoords = get_image_coords(var, NULL);
> unsigned tex_idx = get_image_slot(ctx, 
> nir_src_as_deref(intr->src[0]));
> +   unsigned ncomp = 
> get_num_components_for_glformat(var->data.image.format);
>
> /* src0 is value
>  * src1 is coords
> @@ -1276,10 +1306,10 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
> nir_intrinsic_instr *intr)
>  */
>
> stib = ir3_STIB(b, create_immed(b, tex_idx), 0,
> -   ir3_create_collect(ctx, value, 4), 0,
> +   ir3_create_collect(ctx, value, ncomp), 0,
> ir3_create_collect(ctx, coords, ncoords), 0,
> offset, 0);
> -   stib->cat6.iim_val = 4;
> +   stib->cat6.iim_val = ncomp;
> stib->cat6.d = ncoords;
> stib->cat6.type = get_image_type(var);
> stib->cat6.typed = true;
> --
> 2.19.2
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109086] Crash software mesa with gl_select render mode

[bugzilla-daemon]

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

Bug ID: 109086
   Summary: Crash software mesa with gl_select render mode
   Product: Mesa
   Version: 18.3
  Hardware: Other
OS: Windows (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/softpipe
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: fagot2...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 142847
  --> https://bugs.freedesktop.org/attachment.cgi?id=142847=edit
example application with crash source code

Drawing elements with glRenderMode(GL_SELECT) crashes Windows applications.

Steps to reproduce:
1) build example application from souce code in attachment:
cl -Zi -IF:\mesa-18.3.0\include -IF:\freeglut\include mesacrash.c -link /DEBUG
/LIBPATH:F:\freeglut\lib\x64
/LIBPATH:F:\build\mesa-18.3.0\build\windows-x86_64-debug\gallium\targets\libgl-gdi
2) run mesacrash.exe application.

Application crash with follow error message
  Problem event name:   APPCRASH
  Application name: mesacrash.exe
  Application version:  0.0.0.0
  Application timestamp:5c18c2cb
  Name of module with error:OPENGL32.dll
  Version of module with error: 0.0.0.0
  Timestamp of module with error:   5c10fa47
  Exception code:   c005
  Exception offset: 0058f49a
  OS version:   6.1.7601.2.1.0.256.48
  Language code:1049
  Additional information 1: 0e8c
  Additional information 2: 0e8cbb272bc4decc2d93e964b4efe7e3
  Additional information 3: ca58
  Additional information 4: ca586625bbe3e94cfe8752da92509f27

Expected results:
Application should draw dummy without crash.

Stacktrace:
opengl32.dll!util_format_r32g32b32_float_fetch_rgba_float(float * dst, const
unsigned char * src, unsigned int i, unsigned int j) Line 10081C
opengl32.dll!generic_run_one(translate_generic * tg, unsigned int elt, unsigned
int start_instance, unsigned int instance_id, void * vert) Line 631 C
opengl32.dll!generic_run(translate * translate, unsigned int start, unsigned
int count, unsigned int start_instance, unsigned int instance_id, void *
output_buffer) Line 724   C
opengl32.dll!draw_pt_fetch_run_linear(pt_fetch * fetch, unsigned int start,
unsigned int count, char * verts) Line 200  C
opengl32.dll!fetch(pt_fetch * fetch, const draw_fetch_info * fetch_info, char *
output) Line 165C
opengl32.dll!fetch_pipeline_generic(draw_pt_middle_end * middle, const
draw_fetch_info * fetch_info, const draw_prim_info * in_prim_info) Line 272
 C
opengl32.dll!fetch_pipeline_linear_run(draw_pt_middle_end * middle, unsigned
int start, unsigned int count, unsigned int prim_flags) Line 437   C
opengl32.dll!vsplit_segment_simple_linear(vsplit_frontend * vsplit, unsigned
int flags, unsigned int istart, unsigned int icount) Line 227  C
opengl32.dll!vsplit_run_linear(draw_pt_front_end * frontend, unsigned int
start, unsigned int count) Line 103   C
opengl32.dll!draw_pt_arrays(draw_context * draw, unsigned int prim, unsigned
int start, unsigned int count) Line 151C
opengl32.dll!draw_vbo(draw_context * draw, const pipe_draw_info * info) Line
566C
opengl32.dll!draw_arrays(draw_context * draw, unsigned int mode, unsigned int
start, unsigned int count) Line 105   C
opengl32.dll!st_feedback_draw_vbo(gl_context * ctx, const _mesa_prim * prims,
unsigned int nr_prims, const _mesa_index_buffer * ib, unsigned char
index_bounds_valid, unsigned int min_index, unsigned int max_index,
gl_transform_feedback_object * tfb_vertcount, unsigned int stream,
gl_buffer_object * indirect) Line 261  C
opengl32.dll!_mesa_validated_drawrangeelements(gl_context * ctx, unsigned int
mode, unsigned char index_bounds_valid, unsigned int start, unsigned int end,
int count, unsigned int type, const void * indices, int basevertex, unsigned
int numInstances, unsigned int baseInstance) Line 853  C
opengl32.dll!_mesa_exec_DrawElements(unsigned int mode, int count, unsigned int
type, const void * indices) Line 1006   C
mesacrash.exe!draw() Line 13637 C
mesacrash.exe!displayCB() Line 13680C
freeglut.dll!07feeec2e3d8() Unknown
freeglut.dll!07feeec2e580() Unknown
freeglut.dll!07feeec2ee51() Unknown
mesacrash.exe!main(int argc, char * * argv) Line 13712  C
[External Code] 

System specification:
* Operation system is Windows 7 x64 (installed on Virtual Box machine)
* Mesa version is 18.3.0 builded from sources with Visual Studio 2015 (build
command: scons build=debug machine=x86_64)
* freeglut prebuild binaries
* 2D and 3D acceleration is enabled in Virtual Vox machine, VBGuest drivers are
installed.

Additional Builds and Platforms:
Crash is reproduced with x86 and x64 mesa builds. Also reproduced with Windows
10 x64.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the 

[Mesa-dev] [PATCH] egl/wayland: break double/tripple buffering feedback loops

[Lucas Stach]

Currently we dispose any unneeded color buffers immediately if we detect that
there are more unlocked buffers than we need. This can lead to feedback loops
between the compositor and the application causing rapid toggling between
double and tripple buffering. Scenario: 2 buffers already qeued to the
compositor, egl/wayland allocates a new back buffer to avoid trottling,
slowing down the frame, this allows the compositor to catch up and unlock
both buffers, then EGL detects that there are more buffers than currently
need, freeing the buffer, restartig the loop shortly after.

To avoid wasting CPU time on rapidly freeing and reallocating color buffers
break those feedback loops by letting the unneeded buffers sit around for a
short while before disposing them.

Signed-off-by: Lucas Stach 
---
 src/egl/drivers/dri2/platform_wayland.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 34e09d7ec167..3fa08c1639d1 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -474,15 +474,17 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
wl_display_dispatch_queue_pending(dri2_dpy->wl_dpy, dri2_surf->wl_queue);
 
while (dri2_surf->back == NULL) {
+  int age = 0;
   for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
  /* Get an unlocked buffer, preferably one with a dri_buffer
   * already allocated. */
- if (dri2_surf->color_buffers[i].locked)
+ if (dri2_surf->color_buffers[i].locked || 
dri2_surf->color_buffers[i].age < age)
 continue;
  if (dri2_surf->back == NULL)
 dri2_surf->back = _surf->color_buffers[i];
- else if (dri2_surf->back->dri_image == NULL)
+ else if (dri2_surf->back->dri_image == NULL && 
dri2_surf->color_buffers[i].dri_image)
 dri2_surf->back = _surf->color_buffers[i];
+ age = dri2_surf->back->age;
   }
 
   if (dri2_surf->back)
@@ -615,10 +617,13 @@ update_buffers(struct dri2_egl_surface *dri2_surf)
 
/* If we have an extra unlocked buffer at this point, we had to do triple
 * buffering for a while, but now can go back to just double buffering.
-* That means we can free any unlocked buffer now. */
+* That means we can free any unlocked buffer now. To avoid toggling between
+* going back to double buffering and needing to allocate third buffer too
+* fast we let the unneeded buffer sit around for a short while. */
for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
   if (!dri2_surf->color_buffers[i].locked &&
-  dri2_surf->color_buffers[i].wl_buffer) {
+  dri2_surf->color_buffers[i].wl_buffer &&
+  dri2_surf->color_buffers[i].age > 18) {
  wl_buffer_destroy(dri2_surf->color_buffers[i].wl_buffer);
  dri2_dpy->image->destroyImage(dri2_surf->color_buffers[i].dri_image);
  if (dri2_dpy->is_different_gpu)
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH] WIP: meson: allow building DRI loaders without a DRI driver

[Emil Velikov]

On Mon, 17 Dec 2018 at 22:27, Matt Turner  wrote:
>
> On Mon, Dec 17, 2018 at 2:12 PM Emil Velikov  wrote:
> > Additionally, distributions build latest loader and use it with DRI1
> > era drivers.
>
> I'm curious if there are distributions that still ships the DRI1
> drivers. Do you know which, if any, do?

Archlinux comes off the top of my head. We had a few others but I've
not looked in 6+ months.

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

Re: [Mesa-dev] [PATCH] WIP: meson: allow building DRI loaders without a DRI driver

[Emil Velikov]

On Mon, 17 Dec 2018 at 22:17, Dylan Baker  wrote:
>
> Quoting Tobias Klausmann (2018-12-17 14:05:13)
> >
> > On 17.12.18 20:33, Dylan Baker wrote:
> > > Quoting Emil Velikov (2018-12-17 11:10:00)
> > >> On Fri, 14 Dec 2018 at 17:57, Dylan Baker  wrote:
> > >>> Quoting Emil Velikov (2018-12-13 08:15:57)
> >  From: Emil Velikov 
> > 
> >  Reasonably often people will want to build the loader w/o any drivers.
> >  Be that debugging an issue in the former, distribution bundle or other.
> > 
> >  Currently there is an artificial restriction preventing people to build
> >  a config like the following:
> > 
> >    meson build/ -Dglx=dri -Ddri-drivers= -Dvulkan-drivers= 
> >  -Dgallium-drivers=
> > 
> >  Cc: Dylan Baker 
> >  Signed-off-by: Emil Velikov 
> >  ---
> >  This is a WIP, since it's obviously incomplete/wrong. Input or fix
> >  would be appreciated.
> > 
> >  Thanks
> >  Emil
> >  ---
> >    meson.build | 12 +---
> >    1 file changed, 1 insertion(+), 11 deletions(-)
> > 
> >  diff --git a/meson.build b/meson.build
> >  index 2aa2794f971..e1d6561c1a3 100644
> >  --- a/meson.build
> >  +++ b/meson.build
> >  @@ -285,14 +285,6 @@ if with_glx == 'dri'
> >   endif
> >    endif
> > 
> >  -if not (with_dri or with_gallium or with_glx == 'xlib' or with_glx == 
> >  'gallium-xlib')
> >  -  with_gles1 = false
> >  -  with_gles2 = false
> >  -  with_opengl = false
> >  -  with_any_opengl = false
> >  -  with_shared_glapi = false
> >  -endif
> >  -
> >    _gbm = get_option('gbm')
> >    if _gbm == 'auto'
> >  with_gbm = system_has_kms_drm and with_dri
> >  @@ -352,9 +344,7 @@ if with_glx != 'disabled'
> >  error('xlib conflicts with any dri driver')
> >    endif
> >  elif with_glx == 'dri'
> >  -if not with_dri
> >  -  error('dri based GLX requires at least one DRI driver')
> >  -elif not with_shared_glapi
> >  +if not with_shared_glapi
> >  error('dri based GLX requires shared-glapi')
> >    endif
> >  endif
> >  --
> >  2.19.2
> > 
> > >>> I'll have to think about this some more, I'm still not exactly sure why 
> > >>> you'd
> > >>> want to build the loader without a driver (although I could see why you 
> > >>> might
> > >>> want the driver without the loader).
> > >>>
> > Building both separate breaks away the dependency for llvm/clang while
> > building the loader package (mesa), thus eliminating the bottleneck, the
> > long build time of llvm/clang, in a complete build cycle of a whole
> > distribution rebuild for the packages "waiting" on mesa to complete. The
> > mesa-drivers package can wait for llvm/clang in the meantime. Right now
> > i have solved this by building the classic swrast with mesa and
> > instantly throwing it away after the build is finished.
> >
> > Btw: Building the drivers without a windowing system would be nice as
> > well, this applies to the above use case where the -drivers package does
> > not need a windowing system, as it is contained in the other package.
> >
> > Greetings
> >
> > Tobias
>
> This sounds like asking mesa to carry a lot of complexity so that distros can
> build mesa as three separate packages. I'm really not thrilled about adding
> such a feature unless someone wants to step up and be the maintainer of that
> build mode and ensure it works. All of this complexity is technical debt that
> the project is assuming, it makes the build definitions harder to read and
> modify, and unless there's someone who actually uses such a mode (ie, not a 
> core
> developer, since no one has asked for this), it's just going to get broken. We
> already have the most complicated build system I have ever seen (excluding 
> Linux
> and the core OS of FreeBSD) with more knobs and switches for micro tuning, let
> alone all of the different combinations of drivers, platforms, window systems,
> and APIs.
>
Testing is already covered in the Travis configs that I've sent out ;-)
Fwiw autotools has allowed such flexible building for a while, so it
will be great if we had an equivalent.

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

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

[bugzilla-daemon]

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

--- Comment #8 from Emil Velikov  ---
time for i in `seq 1 100`; do
  pkg-config --libs "libdrm_nouveau >= 2.4.20" &>/dev/null;
  pkg-config --libs "libdrm >= 2.4.20" &>/dev/null;
done

real0m0.738s
user0m0.476s
sys 0m0.270s


time for i in `seq 1 100`; do
  pkg-config --libs "libdrm >= 2.4.20" "libdrm_nouveau >= 2.4.20" &>/dev/null;
done

real0m0.418s
user0m0.298s
sys 0m0.123s


That said, I think meson should be extended and check 2+ packages via
pkg-config.
Adding workarounds in every project that uses meson doesn't scale :-(

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

Re: [Mesa-dev] [PATCH] meson: Fix typo.

[Emil Velikov]

On Tue, 18 Dec 2018 at 02:32, Vinson Lee  wrote:
>
> Fixes: 6b4c7047d571 ("meson: build gallium nine state_tracker")
> Signed-off-by: Vinson Lee 
> ---
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH] freedreno/ir3: Make imageStore use num components from image format

[Eduardo Lima Mitev]

On 12/18/18 11:18 AM, Ilia Mirkin wrote:
> Nv_image_formats adds all the core formats to gles.
> 
> It's pretty easy to add them all in, so I don't see why not.
> 

Ok, I didn't know about that extension, thanks for the pointer.

It then makes sense to support all these formats, yes. I will submit an
v2 including them.

Thanks, Ilia.

> On Tue, Dec 18, 2018, 03:17 Eduardo Lima Mitev   wrote:
> 
> 
> 
> On 12/18/18 9:05 AM, Eduardo Lima Mitev wrote:
> > On 12/17/18 10:02 PM, Ilia Mirkin wrote:
> >> Note that the format may not be known. I suspect that falls into your
> >> "default" case.
> >>
> >
> > Hi Ilia,
> >
> > while on GLES profiles the format qualifier must be declared for all
> > image variables, it is true that core profiles allow to omit it for
> > writeonly-qualified images.
> >
> > I guess we can add a special case for GL_NONE to the switch, that also
> > returns 4 components, to at least not break current behavior if image
> > format is not known. What do you think?
> >
> 
> Thinking a bit more about this, if we care about core profile then there
> are more GL formats to consider apart from those supported by GLES 3.1.
> 
> However, since image format layout qualifiers were introduced in core
> 4.20, I don't think we should care for now. So I would leave the patch
> as-is and fail the assert on unknown formats.
> 
> Eduardo
> 
> > Eduardo
> >
> >> On Mon, Dec 17, 2018 at 3:41 PM Eduardo Lima Mitev
> mailto:el...@igalia.com>> wrote:
> >>>
> >>> emit_intrinsic_store_image() is always using 4 components when
> >>> collecting registers for the value. When image has less than
> >>> 4 components (e.g, r32f, r32i, r32ui) this results in extra mov
> >>> instructions.
> >>>
> >>> This patch uses the actual number of components from the image
> format.
> >>>
> >>> For example, in a shader like:
> >>>
> >>> layout (r32f, binding=0) writeonly uniform imageBuffer u_image;
> >>> ...
> >>> void main(void) {
> >>>    ...
> >>>    imageStore (u_image, some_offset, vec4(1.0));
> >>>    ...
> >>> }
> >>>
> >>> instruction count is reduced in at least 3 instructions (note image
> >>> format is r32f, 1 component only).
> >>>
> >>> This obviously reduces register pressure as well.
> >>> ---
> >>>  src/freedreno/ir3/ir3_compiler_nir.c | 34
> ++--
> >>>  1 file changed, 32 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/src/freedreno/ir3/ir3_compiler_nir.c
> b/src/freedreno/ir3/ir3_compiler_nir.c
> >>> index 85f14f354d2..cc00602c249 100644
> >>> --- a/src/freedreno/ir3/ir3_compiler_nir.c
> >>> +++ b/src/freedreno/ir3/ir3_compiler_nir.c
> >>> @@ -1251,6 +1251,35 @@ emit_intrinsic_load_image(struct
> ir3_context *ctx, nir_intrinsic_instr *intr,
> >>>         ir3_split_dest(b, dst, sam, 0, 4);
> >>>  }
> >>>
> >>> +/* Get the number of components of the different image formats
> supported
> >>> + * by the GLES 3.1 spec.
> >>> + */
> >>> +static unsigned
> >>> +get_num_components_for_glformat(GLuint format)
> >>> +{
> >>> +       switch (format) {
> >>> +       case GL_R32F:
> >>> +       case GL_R32I:
> >>> +       case GL_R32UI:
> >>> +               return 1;
> >>> +
> >>> +       case GL_RGBA32F:
> >>> +       case GL_RGBA16F:
> >>> +       case GL_RGBA8:
> >>> +       case GL_RGBA8_SNORM:
> >>> +       case GL_RGBA32I:
> >>> +       case GL_RGBA16I:
> >>> +       case GL_RGBA8I:
> >>> +       case GL_RGBA32UI:
> >>> +       case GL_RGBA16UI:
> >>> +       case GL_RGBA8UI:
> >>> +               return 4;
> >>> +
> >>> +       default:
> >>> +               assert(!"Unsupported GL format for image");
> >>> +       }
> >>> +}
> >>> +
> >>>  /* src[] = { deref, coord, sample_index, value }. const_index[]
> = {} */
> >>>  static void
> >>>  emit_intrinsic_store_image(struct ir3_context *ctx,
> nir_intrinsic_instr *intr)
> >>> @@ -1262,6 +1291,7 @@ emit_intrinsic_store_image(struct
> ir3_context *ctx, nir_intrinsic_instr *intr)
> >>>         struct ir3_instruction * const *coords =
> ir3_get_src(ctx, >src[1]);
> >>>         unsigned ncoords = get_image_coords(var, NULL);
> >>>         unsigned tex_idx = get_image_slot(ctx,
> nir_src_as_deref(intr->src[0]));
> >>> +       unsigned ncomp =
> get_num_components_for_glformat(var->data.image.format);
> >>>
> >>>         /* src0 is value
> >>>          * src1 is coords
> >>> @@ -1276,10 +1306,10 @@ emit_intrinsic_store_image(struct
> ir3_context *ctx, nir_intrinsic_instr *intr)
> >>>          */
> >>>
> >>>         stib = ir3_STIB(b, create_immed(b, tex_idx), 0,
>

Re: [Mesa-dev] [PATCH 1/2] bin/get-pick-list.sh: rework handing of sha nominations

[Emil Velikov]

On Mon, 17 Dec 2018 at 22:35, Andres Gomez  wrote:
>
> On Mon, 2018-12-17 at 18:36 +, Emil Velikov wrote:
> > On Mon, 17 Dec 2018 at 18:14, Andres Gomez  wrote:
> > >
> > > On Mon, 2018-12-17 at 16:43 +, Emil Velikov wrote:
> > > > Currently our is_sha_nomination does:
> > > >  - folds any whitespace, attempting to extract sha-like information
> > > >  - checks that at least one of the shas has landed
> > > >
> > > > Split it in two and do sha-like validation first.
> > > >
> > > > This way, commits with mesa-stable and sha nominations will feature the
> > > > fixes/revert/etc instead of stable (a) or will be omitted if not
> > > > applicable for the respective branch (b).
> > > >
> > > > Misc examples from 18.3
> > > >
> > > > (a)
> > > > -[   stable ] 5bc509363b6 glx: make xf86vidmode mandatory for direct 
> > > > rendering
> > > > +[fixes ] 5bc509363b6 glx: make xf86vidmode mandatory for direct 
> > > > rendering
> > > >
> > > > (b)
> > > > -[   stable ] 9a7b3199037 anv/query: flush render target before copying 
> > > > results
> > > >
> > > > CC: Andres Gomez 
> > > > CC: Juan A. Suarez 
> > > > CC: Dylan Baker 
> > > > CC: mesa-sta...@lists.freedesktop.org
> > > > Signed-off-by: Emil Velikov 
> > > > ---
> > > > Juan I've noticed that you've been experiencing the above annoyance for
> > > > a while. Having less false-positives should ease things up a bit :-)
> > > > ---
> > > >  bin/get-pick-list.sh | 46 +---
> > > >  1 file changed, 30 insertions(+), 16 deletions(-)
> > > >
> > > > diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
> > > > index 9f9cbc44026..08a783f35a8 100755
> > > > --- a/bin/get-pick-list.sh
> > > > +++ b/bin/get-pick-list.sh
> > > > @@ -21,32 +21,36 @@ is_typod_nomination()
> > > >   git show --summary "$1" | grep -q -i -o "CC:.*mesa-dev"
> > > >  }
> > > >
> > > > +fixes=
> > > > +
> > >
> > > Splitting in 2 functions for which we need now a global variable is not
> > > very nice. Anyway, let's not make this more complicated than needed.
> > >
> >
> > Wasn't too happy about it either. As you said - I've decided to go
> > with the simpler solution.
> >
> > > >  # Helper to handle various mistypos of the fixes tag.
> > > >  # The tag string itself is passed as argument and normalised within.
> > > > +#
> > > > +# Resulting string in the global variable "fixes" and contains entries
> > > > +# in the form "fixes:$sha"
> > > >  is_sha_nomination()
> > > >  {
> > > >   fixes=`git show --pretty=medium -s $1 | tr -d "\n" | \
> > > >   sed -e 's/'"$2"'/\nfixes:/Ig' | \
> > > >   grep -Eo 'fixes:[a-f0-9]{8,40}'`
> > > >
> > > > - fixes_count=`echo "$fixes" | wc -l`
> > > > + fixes_count=`echo "$fixes" | grep "fixes:" | wc -l`
> > >
> > > Why is the extra "grep" needed here?
> > >
> >
> > Commits that include "fixes $some_test" will result in fixes="".
> > Thus wc -l will return 1
>
> Argh!
>
> Well, this is more a consequence of wc counting newline characters and
> echo adding a new one at the end, even when not printing anything.
> Let's grep again, then ☹
>
> > > >   if test $fixes_count -eq 0; then
> > > > - return 0
> > > > + return 1
> > >
> > > Ugh! Right.
> > >
> > > >   fi
> > > > + return 0
> > > > +}
> > > > +
> > > > +# Checks if at least one of offending commits, listed in the global
> > > > +# "fixes", is in branch.
> > > > +sha_in_range()
> > > > +{
> > > > + fixes_count=`echo "$fixes" | grep "fixes:" | wc -l`
> > >
> > > Ditto.
> > >
> > > >   while test $fixes_count -gt 0; do
> > > >   # Treat only the current line
> > > >   id=`echo "$fixes" | tail -n $fixes_count | head -n 1 | 
> > > > cut -d : -f 2`
> > > >   fixes_count=$(($fixes_count-1))
> > > >
> > > > - # Bail out if we cannot find suitable id.
> > > > - # Any specific validation the $id is valid and not some 
> > > > junk, is
> > > > - # implied with the follow up code
> > > > - if test "x$id" = x; then
> > > > - continue
> > > > - fi
> > > > -
> > > > - #Check if the offending commit is in branch.
> > > > -
> > >
> > > Was this never needed in the first place? Feels right to remove it
> > > since $fixes should have some content by now, but I wonder how this got
> > > here in the first place.
> > >
> >
> > Left-over from the old standalone script. Copied a bit too much :-(
> >
> > > >   # Be that cherry-picked ...
> > > >   # ... or landed before the branchpoint.
> > > >   if grep -q ^$id already_picked ||
> > > > @@ -103,20 +107,30 @@ do
> > > >   continue
> > > >   fi
> > > >
> > > > - if is_stable_nomination "$sha"; then
> > > > - tag=stable
> > > > - elif is_typod_nomination "$sha"; then
> > > > - tag=typod
> > > > - elif is_fixes_nomination "$sha"; then
> > 

Re: [Mesa-dev] [PATCH 03/18] glx: meson: build src/glx only with -Dglx=dri

[Emil Velikov]

On Mon, 17 Dec 2018 at 19:44, Dylan Baker  wrote:
>
> Quoting Emil Velikov (2018-12-17 10:58:11)
> > On Fri, 14 Dec 2018 at 17:13, Dylan Baker  wrote:
> > >
> > > Quoting Emil Velikov (2018-12-13 08:05:52)
> > > > From: Emil Velikov 
> > > >
> > > > The library is the dri capable one, push the check src/meson.build,
> > > > instead of the current partial handling in src/glx/meson.build.
> > > >
> > > > Fixes: a47c525f328 ("meson: build glx")
> > >
> > > This is just a refactor, the Fixes: is unnecessary. More on that below
> > >
> > If I'm reading things correctly, building with -Dglx=xlib/gallium-xlib
> > -Dshared-glapi -Denable-tests - will attempt to build the tests in
> > src/glx/tests/.
> > Which is something that shouldn't happen IMHO.
>
> Wait, why shouldn't they run? The tests pass (at least with the gallium-xlib
> glx), and running tests seems useful.
>
Fully agree running tests is useful and welcome.

The tests flex the -Dglx=dri code in src/glx/. As-is it's rather
confusing, misleading even, to request one thing then run tests for
something that looks the same but isn't.
Silly analogy - running ANV tests, when -Dvulkan-drivers=amd is used.

Hope this is clear - not sure if the coffee has kicked in ;-)
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 20/29] i965/fs/nir: add nir_op_unpack_half_2x16_split_*_flush_to_zero

[Samuel Iglesias Gonsálvez]

The denorm mode is set in the control register, no need to do something else.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/compiler/brw_fs_nir.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index 11afd4b5f3b..d9376e92220 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -1453,10 +1453,12 @@ fs_visitor::nir_emit_alu(const fs_builder , 
nir_alu_instr *instr)
   unreachable("not reached: should be handled by lower_packing_builtins");
 
case nir_op_unpack_half_2x16_split_x:
+   case nir_op_unpack_half_2x16_split_x_flush_to_zero:
   inst = bld.emit(FS_OPCODE_UNPACK_HALF_2x16_SPLIT_X, result, op[0]);
   inst->saturate = instr->dest.saturate;
   break;
case nir_op_unpack_half_2x16_split_y:
+   case nir_op_unpack_half_2x16_split_y_flush_to_zero:
   inst = bld.emit(FS_OPCODE_UNPACK_HALF_2x16_SPLIT_Y, result, op[0]);
   inst->saturate = instr->dest.saturate;
   break;
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 27/29] anv: add support for VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/vulkan/anv_device.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 67ea86c4b66..1b57e7b56f5 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1245,6 +1245,37 @@ void anv_GetPhysicalDeviceProperties2(
  properties->quadOperationsInAllStages = VK_TRUE;
  break;
   }
+  case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR : {
+ VkPhysicalDeviceFloatControlsPropertiesKHR *properties = (void *)ext;
+ properties->separateDenormSettings = true;
+ properties->separateRoundingModeSettings = false;
+
+ /* Broadwell does not support HF denorms and there are restrictions
+  * other gens. According to Kabylake's PRM:
+  *
+  * "math - Extended Math Function
+  * [...]
+  * Restriction : Half-float denorms are always retained."
+  */
+ properties->shaderDenormFlushToZeroFloat16 = false;
+ properties->shaderDenormPreserveFloat16 = pdevice->info.gen > 8;
+ properties->shaderRoundingModeRTEFloat16 = true;
+ properties->shaderRoundingModeRTZFloat16 = true;
+ properties->shaderSignedZeroInfNanPreserveFloat16 = true;
+
+ properties->shaderDenormFlushToZeroFloat32 = true;
+ properties->shaderDenormPreserveFloat32 = true;
+ properties->shaderRoundingModeRTEFloat32 = true;
+ properties->shaderRoundingModeRTZFloat32 = true;
+ properties->shaderSignedZeroInfNanPreserveFloat32 = true;
+
+ properties->shaderDenormFlushToZeroFloat64 = true;
+ properties->shaderDenormPreserveFloat64 = true;
+ properties->shaderRoundingModeRTEFloat64 = true;
+ properties->shaderRoundingModeRTZFloat64 = true;
+ properties->shaderSignedZeroInfNanPreserveFloat64 = true;
+ break;
+  }
 
   case 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT: {
  VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT *props =
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 22/29] i965/fs: define emit_shader_float_controls_execution_mode() and aux functions

[Samuel Iglesias Gonsálvez]

We need this function to emit code that setups the control register later with
the defined execution mode for the shader.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/compiler/brw_fs.h   |  1 +
 src/intel/compiler/brw_fs_visitor.cpp | 52 +++
 2 files changed, 53 insertions(+)

diff --git a/src/intel/compiler/brw_fs.h b/src/intel/compiler/brw_fs.h
index f79f8554fb9..3f38faf94bb 100644
--- a/src/intel/compiler/brw_fs.h
+++ b/src/intel/compiler/brw_fs.h
@@ -187,6 +187,7 @@ public:
void emit_gen6_gather_wa(uint8_t wa, fs_reg dst);
fs_reg resolve_source_modifiers(const fs_reg );
void emit_discard_jump();
+   void emit_shader_float_controls_execution_mode();
bool opt_peephole_sel();
bool opt_peephole_csel();
bool opt_peephole_predicated_break();
diff --git a/src/intel/compiler/brw_fs_visitor.cpp 
b/src/intel/compiler/brw_fs_visitor.cpp
index 51a0ca2374a..2da06cf78d0 100644
--- a/src/intel/compiler/brw_fs_visitor.cpp
+++ b/src/intel/compiler/brw_fs_visitor.cpp
@@ -198,6 +198,58 @@ fs_visitor::emit_interpolation_setup_gen4()
abld.emit(SHADER_OPCODE_RCP, this->pixel_w, wpos_w);
 }
 
+static unsigned
+brw_rnd_mode_from_nir(unsigned mode, unsigned *mask)
+{
+   unsigned brw_mode = 0;
+   *mask = 0;
+
+   if (mode & SHADER_ROUNDING_MODE_RTZ) {
+  brw_mode |= BRW_RND_MODE_RTZ << BRW_CR0_RND_MODE_SHIFT;
+  *mask |= BRW_CR0_RND_MODE_MASK;
+   }
+   if (mode & SHADER_ROUNDING_MODE_RTE) {
+  brw_mode |= BRW_RND_MODE_RTNE << BRW_CR0_RND_MODE_SHIFT;
+  *mask |= BRW_CR0_RND_MODE_MASK;
+   }
+   if (mode & SHADER_DENORM_PRESERVE_FP16) {
+  brw_mode |= BRW_CR0_FP16_DENORM_PRESERVE;
+  *mask |= BRW_CR0_FP16_DENORM_PRESERVE;
+   }
+   if (mode & SHADER_DENORM_PRESERVE_FP32) {
+  brw_mode |= BRW_CR0_FP32_DENORM_PRESERVE;
+  *mask |= BRW_CR0_FP32_DENORM_PRESERVE;
+   }
+   if (mode & SHADER_DENORM_PRESERVE_FP64) {
+  brw_mode |= BRW_CR0_FP64_DENORM_PRESERVE;
+  *mask |= BRW_CR0_FP64_DENORM_PRESERVE;
+   }
+   if (mode & SHADER_DENORM_FLUSH_TO_ZERO_FP16)
+  *mask |= BRW_CR0_FP16_DENORM_PRESERVE;
+   if (mode & SHADER_DENORM_FLUSH_TO_ZERO_FP32)
+  *mask |= BRW_CR0_FP32_DENORM_PRESERVE;
+   if (mode & SHADER_DENORM_FLUSH_TO_ZERO_FP64)
+  *mask |= BRW_CR0_FP64_DENORM_PRESERVE;
+   if (mode == SHADER_DEFAULT_FLOAT_CONTROL_MODE)
+  *mask |= BRW_CR0_RND_MODE_MASK;
+
+   return brw_mode;
+}
+
+void
+fs_visitor::emit_shader_float_controls_execution_mode()
+{
+   unsigned execution_mode = 
this->nir->info.shader_float_controls_execution_mode;
+   if (execution_mode == SHADER_DEFAULT_FLOAT_CONTROL_MODE)
+  return;
+
+   fs_builder abld = bld.annotate("shader floats control execution mode");
+   unsigned mask = 0;
+   unsigned mode = brw_rnd_mode_from_nir(execution_mode, );
+   abld.emit(SHADER_OPCODE_FLOAT_CONTROL_MODE, bld.null_reg_ud(),
+ brw_imm_d(mode), brw_imm_d(mask));
+}
+
 /** Emits the interpolation for the varying inputs. */
 void
 fs_visitor::emit_interpolation_setup_gen6()
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 19/29] i965/fs: add nir_op_f2f*_{rtne,rtz}

[Samuel Iglesias Gonsálvez]

This way, we can implement its support later if SPIR-V supports it.
Right now, the RTZ, RTNE support in SPIR-V in FPRoundingMode only
applies to f2f16 conversions.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/compiler/brw_fs_nir.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index d957d248fbd..11afd4b5f3b 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -789,6 +789,8 @@ fs_visitor::nir_emit_alu(const fs_builder , 
nir_alu_instr *instr)
   inst->saturate = instr->dest.saturate;
   break;
 
+   case nir_op_f2f64_rtne:
+   case nir_op_f2f64_rtz:
case nir_op_f2f64:
case nir_op_f2i64:
case nir_op_f2u64:
@@ -908,6 +910,8 @@ fs_visitor::nir_emit_alu(const fs_builder , 
nir_alu_instr *instr)
   }
   /* Fallthrough */
 
+   case nir_op_f2f32_rtne:
+   case nir_op_f2f32_rtz:
case nir_op_f2f32:
case nir_op_f2i32:
case nir_op_f2u32:
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 28/29] anv: enable support for SPV_KHR_shader_float_controls capabilities

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/vulkan/anv_pipeline.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index c303ba321c3..2781b8f0ee0 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -145,6 +145,7 @@ anv_shader_compile_to_nir(struct anv_pipeline *pipeline,
  .min_lod = true,
  .multiview = true,
  .variable_pointers = true,
+ .shader_float_controls = device->instance->physicalDevice.info.gen >= 
8,
  .storage_16bit = device->instance->physicalDevice.info.gen >= 8,
  .int16 = device->instance->physicalDevice.info.gen >= 8,
  .float16 = device->instance->physicalDevice.info.gen >= 8,
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 21/29] i965/fs/generator: add support to set floating points modes in control register

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/compiler/brw_eu.h |  4 
 src/intel/compiler/brw_eu_defines.h | 10 ++
 src/intel/compiler/brw_eu_emit.c| 26 +
 src/intel/compiler/brw_fs_generator.cpp |  8 +++-
 src/intel/compiler/brw_shader.cpp   |  3 +++
 5 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
index 9f1ca769bd3..2309d3b10d8 100644
--- a/src/intel/compiler/brw_eu.h
+++ b/src/intel/compiler/brw_eu.h
@@ -677,6 +677,10 @@ void
 brw_rounding_mode(struct brw_codegen *p,
   enum brw_rnd_mode mode);
 
+void
+brw_float_controls_mode(struct brw_codegen *p,
+unsigned mode, unsigned mask);
+
 /***
  * brw_eu_util.c:
  */
diff --git a/src/intel/compiler/brw_eu_defines.h 
b/src/intel/compiler/brw_eu_defines.h
index affe977835b..3b5c4fbb220 100644
--- a/src/intel/compiler/brw_eu_defines.h
+++ b/src/intel/compiler/brw_eu_defines.h
@@ -412,6 +412,7 @@ enum opcode {
SHADER_OPCODE_TYPED_SURFACE_WRITE_LOGICAL,
 
SHADER_OPCODE_RND_MODE,
+   SHADER_OPCODE_FLOAT_CONTROL_MODE,
 
/**
 * Byte scattered write/read opcodes.
@@ -1314,6 +1315,15 @@ enum PACKED brw_rnd_mode {
BRW_RND_MODE_UNSPECIFIED,  /* Unspecified rounding mode */
 };
 
+#define BRW_CR0_FP64_DENORM_PRESERVE (1 << 6)
+#define BRW_CR0_FP32_DENORM_PRESERVE (1 << 7)
+#define BRW_CR0_FP16_DENORM_PRESERVE (1 << 10)
+
+#define BRW_CR0_FP_MODE_MASK (BRW_CR0_FP64_DENORM_PRESERVE | \
+  BRW_CR0_FP32_DENORM_PRESERVE | \
+  BRW_CR0_FP16_DENORM_PRESERVE | \
+  BRW_CR0_RND_MODE_MASK << BRW_CR0_RND_MODE_SHIFT)
+
 /* MDC_DS - Data Size Message Descriptor Control Field
  * Skylake PRM, Volume 2d, page 129
  *
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 81474ae24f2..c3d53bc1f2a 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -3696,3 +3696,29 @@ brw_rounding_mode(struct brw_codegen *p,
   brw_inst_set_thread_control(p->devinfo, inst, BRW_THREAD_SWITCH);
}
 }
+
+/* TODO: Refactor brw_rounding_mode() to use this. */
+void
+brw_float_controls_mode(struct brw_codegen *p,
+unsigned mode, unsigned mask)
+{
+   brw_inst *inst = brw_AND(p, brw_cr0_reg(0), brw_cr0_reg(0),
+brw_imm_ud(~mask));
+   brw_inst_set_exec_size(p->devinfo, inst, BRW_EXECUTE_1);
+
+   /* From the Skylake PRM, Volume 7, page 760:
+*  "Implementation Restriction on Register Access: When the control
+*   register is used as an explicit source and/or destination, hardware
+*   does not ensure execution pipeline coherency. Software must set the
+*   thread control field to ‘switch’ for an instruction that uses
+*   control register as an explicit operand."
+*/
+   brw_inst_set_thread_control(p->devinfo, inst, BRW_THREAD_SWITCH);
+
+   if (mode) {
+  brw_inst *inst_or = brw_OR(p, brw_cr0_reg(0), brw_cr0_reg(0),
+ brw_imm_ud(mode));
+  brw_inst_set_exec_size(p->devinfo, inst_or, BRW_EXECUTE_1);
+  brw_inst_set_thread_control(p->devinfo, inst_or, BRW_THREAD_SWITCH);
+   }
+}
diff --git a/src/intel/compiler/brw_fs_generator.cpp 
b/src/intel/compiler/brw_fs_generator.cpp
index a5f93f20938..675baa3db52 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -2422,7 +2422,13 @@ fs_generator::generate_code(const cfg_t *cfg, int 
dispatch_width)
 
   case SHADER_OPCODE_RND_MODE:
  assert(src[0].file == BRW_IMMEDIATE_VALUE);
- brw_rounding_mode(p, (brw_rnd_mode) src[0].d);
+ brw_rounding_mode(p, (enum brw_rnd_mode) src[0].d);
+ break;
+
+  case SHADER_OPCODE_FLOAT_CONTROL_MODE:
+ assert(src[0].file == BRW_IMMEDIATE_VALUE);
+ assert(src[1].file == BRW_IMMEDIATE_VALUE);
+ brw_float_controls_mode(p, src[0].d, src[1].d);
  break;
 
   default:
diff --git a/src/intel/compiler/brw_shader.cpp 
b/src/intel/compiler/brw_shader.cpp
index d6ff6b92627..aa4eb3ae6c2 100644
--- a/src/intel/compiler/brw_shader.cpp
+++ b/src/intel/compiler/brw_shader.cpp
@@ -509,6 +509,8 @@ brw_instruction_name(const struct gen_device_info *devinfo, 
enum opcode op)
 
case SHADER_OPCODE_RND_MODE:
   return "rnd_mode";
+   case SHADER_OPCODE_FLOAT_CONTROL_MODE:
+  return "float_control_mode";
}
 
unreachable("not reached");
@@ -1053,6 +1055,7 @@ backend_instruction::has_side_effects() const
case TCS_OPCODE_URB_WRITE:
case TCS_OPCODE_RELEASE_INPUT:
case SHADER_OPCODE_RND_MODE:
+   case SHADER_OPCODE_FLOAT_CONTROL_MODE:
   return true;
default:
   return eot;
-- 
2.19.1

___
mesa-dev mailing 

[Mesa-dev] [PATCH v2 18/29] intel/nir: call nir_opt_constant_folding before brw_nir_apply_trig_workarounds

[Samuel Iglesias Gonsálvez]

If we have fsin or fcos trigonometric operations with constant values as inputs,
we will multiply the result by 0.7 in brw_nir_apply_trig_workarounds,
making the result wrong. Running nir_opt_constant_folding before, we will
calculate correctly the result for these trignometric ops.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/compiler/brw_nir.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 3b4d25213f5..2debce72db2 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -665,8 +665,10 @@ brw_preprocess_nir(const struct brw_compiler *compiler, 
nir_shader *nir)
 
/* See also brw_nir_trig_workarounds.py */
if (compiler->precise_trig &&
-   !(devinfo->gen >= 10 || devinfo->is_kabylake))
+   !(devinfo->gen >= 10 || devinfo->is_kabylake)) {
+  OPT(nir_opt_constant_folding);
   OPT(brw_nir_apply_trig_workarounds);
+   }
 
static const nir_lower_tex_options tex_options = {
   .lower_txp = ~0,
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 26/29] i965/fs: add support for shader float control to remove_extra_rounding_modes()

[Samuel Iglesias Gonsálvez]

The remove_extra_rounding_modes() optimization will remove duplicated
rounding mode changes.

v2:
- Fix bug in the rounding mode change (Alejandro)

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/compiler/brw_fs.cpp | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 0ccff00dd4c..69a4a8debfe 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -3457,9 +3457,16 @@ bool
 fs_visitor::remove_extra_rounding_modes()
 {
bool progress = false;
+   unsigned execution_mode = 
this->nir->info.shader_float_controls_execution_mode;
+
+   brw_rnd_mode base_mode = BRW_RND_MODE_UNSPECIFIED;
+   if (execution_mode & SHADER_ROUNDING_MODE_RTE)
+  base_mode = BRW_RND_MODE_RTNE;
+   if (execution_mode & SHADER_ROUNDING_MODE_RTZ)
+  base_mode = BRW_RND_MODE_RTZ;
 
foreach_block (block, cfg) {
-  brw_rnd_mode prev_mode = BRW_RND_MODE_UNSPECIFIED;
+  brw_rnd_mode prev_mode = base_mode;
 
   foreach_inst_in_block_safe (fs_inst, inst, block) {
  if (inst->opcode == SHADER_OPCODE_RND_MODE) {
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 24/29] i965/fs: set rounding mode when emitting affected conversion instructions

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/compiler/brw_fs_nir.cpp | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index d9376e92220..be197b5f745 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -653,10 +653,15 @@ emit_find_msb_using_lzd(const fs_builder ,
 }
 
 static brw_rnd_mode
-brw_rnd_mode_from_nir_op (const nir_op op) {
+brw_rnd_mode_from_nir_op (const nir_op op)
+{
switch (op) {
+   case nir_op_f2f64_rtz:
+   case nir_op_f2f32_rtz:
case nir_op_f2f16_rtz:
   return BRW_RND_MODE_RTZ;
+   case nir_op_f2f64_rtne:
+   case nir_op_f2f32_rtne:
case nir_op_f2f16_rtne:
   return BRW_RND_MODE_RTNE;
default:
@@ -791,6 +796,9 @@ fs_visitor::nir_emit_alu(const fs_builder , 
nir_alu_instr *instr)
 
case nir_op_f2f64_rtne:
case nir_op_f2f64_rtz:
+  bld.emit(SHADER_OPCODE_RND_MODE, bld.null_reg_ud(),
+   brw_imm_d(brw_rnd_mode_from_nir_op(instr->op)));
+  /* fallthrough */
case nir_op_f2f64:
case nir_op_f2i64:
case nir_op_f2u64:
@@ -908,10 +916,16 @@ fs_visitor::nir_emit_alu(const fs_builder , 
nir_alu_instr *instr)
  bld.MOV(tmp, op[0]);
  op[0] = tmp;
   }
-  /* Fallthrough */
+  inst = bld.MOV(result, op[0]);
+  inst->saturate = instr->dest.saturate;
+  break;
 
case nir_op_f2f32_rtne:
case nir_op_f2f32_rtz:
+  bld.emit(SHADER_OPCODE_RND_MODE, bld.null_reg_ud(),
+   brw_imm_d(brw_rnd_mode_from_nir_op(instr->op)));
+  /* Fallthrough */
+
case nir_op_f2f32:
case nir_op_f2i32:
case nir_op_f2u32:
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 29/29] anv: enable VK_KHR_shader_float_controls extension

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/vulkan/anv_extensions.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index e481c45d5d5..2e29e941bfa 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -105,6 +105,7 @@ EXTENSIONS = [
 Extension('VK_KHR_sampler_ycbcr_conversion',  1, True),
 Extension('VK_KHR_shader_draw_parameters',1, True),
 Extension('VK_KHR_shader_float16_int8',   1, 'device->info.gen 
>= 8'),
+Extension('VK_KHR_shader_float_controls', 1, 'device->info.gen 
>= 8'),
 Extension('VK_KHR_storage_buffer_storage_class',  1, True),
 Extension('VK_KHR_surface',  25, 
'ANV_HAS_SURFACE'),
 Extension('VK_KHR_swapchain',68, 
'ANV_HAS_SURFACE'),
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 25/29] i965/fs: remove brw_rounding_mode() and use brw_float_controls_mode() instead

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/compiler/brw_eu.h |  4 ---
 src/intel/compiler/brw_eu_emit.c| 36 -
 src/intel/compiler/brw_fs_generator.cpp | 13 +++--
 3 files changed, 11 insertions(+), 42 deletions(-)

diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
index 2309d3b10d8..ae068964936 100644
--- a/src/intel/compiler/brw_eu.h
+++ b/src/intel/compiler/brw_eu.h
@@ -673,10 +673,6 @@ brw_broadcast(struct brw_codegen *p,
   struct brw_reg src,
   struct brw_reg idx);
 
-void
-brw_rounding_mode(struct brw_codegen *p,
-  enum brw_rnd_mode mode);
-
 void
 brw_float_controls_mode(struct brw_codegen *p,
 unsigned mode, unsigned mask);
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index c3d53bc1f2a..e4549699b38 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -3662,42 +3662,6 @@ brw_WAIT(struct brw_codegen *p)
brw_inst_set_mask_control(devinfo, insn, BRW_MASK_DISABLE);
 }
 
-/**
- * Changes the floating point rounding mode updating the control register
- * field defined at cr0.0[5-6] bits. This function supports the changes to
- * RTNE (00), RU (01), RD (10) and RTZ (11) rounding using bitwise operations.
- * Only RTNE and RTZ rounding are enabled at nir.
- */
-void
-brw_rounding_mode(struct brw_codegen *p,
-  enum brw_rnd_mode mode)
-{
-   const unsigned bits = mode << BRW_CR0_RND_MODE_SHIFT;
-
-   if (bits != BRW_CR0_RND_MODE_MASK) {
-  brw_inst *inst = brw_AND(p, brw_cr0_reg(0), brw_cr0_reg(0),
-   brw_imm_ud(~BRW_CR0_RND_MODE_MASK));
-  brw_inst_set_exec_size(p->devinfo, inst, BRW_EXECUTE_1);
-
-  /* From the Skylake PRM, Volume 7, page 760:
-   *  "Implementation Restriction on Register Access: When the control
-   *   register is used as an explicit source and/or destination, hardware
-   *   does not ensure execution pipeline coherency. Software must set the
-   *   thread control field to ‘switch’ for an instruction that uses
-   *   control register as an explicit operand."
-   */
-  brw_inst_set_thread_control(p->devinfo, inst, BRW_THREAD_SWITCH);
-}
-
-   if (bits) {
-  brw_inst *inst = brw_OR(p, brw_cr0_reg(0), brw_cr0_reg(0),
-  brw_imm_ud(bits));
-  brw_inst_set_exec_size(p->devinfo, inst, BRW_EXECUTE_1);
-  brw_inst_set_thread_control(p->devinfo, inst, BRW_THREAD_SWITCH);
-   }
-}
-
-/* TODO: Refactor brw_rounding_mode() to use this. */
 void
 brw_float_controls_mode(struct brw_codegen *p,
 unsigned mode, unsigned mask)
diff --git a/src/intel/compiler/brw_fs_generator.cpp 
b/src/intel/compiler/brw_fs_generator.cpp
index 675baa3db52..11a5da69f0c 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -2420,9 +2420,18 @@ fs_generator::generate_code(const cfg_t *cfg, int 
dispatch_width)
  brw_DIM(p, dst, retype(src[0], BRW_REGISTER_TYPE_F));
  break;
 
-  case SHADER_OPCODE_RND_MODE:
+  case SHADER_OPCODE_RND_MODE: {
  assert(src[0].file == BRW_IMMEDIATE_VALUE);
- brw_rounding_mode(p, (enum brw_rnd_mode) src[0].d);
+ /*
+  * Changes the floating point rounding mode updating the control 
register
+  * field defined at cr0.0[5-6] bits. This function supports the 
changes to
+  * RTNE (00), RU (01), RD (10) and RTZ (11) rounding using bitwise 
operations.
+  * Only RTNE and RTZ rounding are enabled at nir.
+  */
+ enum brw_rnd_mode mode =
+(enum brw_rnd_mode) (src[0].d << BRW_CR0_RND_MODE_SHIFT);
+ brw_float_controls_mode(p, mode, BRW_CR0_RND_MODE_MASK);
+  }
  break;
 
   case SHADER_OPCODE_FLOAT_CONTROL_MODE:
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 23/29] i965/fs: emit shader float controls execution modes as first instruction of shaders

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/compiler/brw_fs.cpp | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 12971eeb549..0ccff00dd4c 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -6691,6 +6691,8 @@ fs_visitor::run_vs()
if (shader_time_index >= 0)
   emit_shader_time_begin();
 
+   emit_shader_float_controls_execution_mode();
+
emit_nir_code();
 
if (failed)
@@ -6761,6 +6763,7 @@ fs_visitor::run_tcs_single_patch()
   brw_imm_ud(nir->info.tess.tcs_vertices_out), BRW_CONDITIONAL_L);
   bld.IF(BRW_PREDICATE_NORMAL);
}
+   emit_shader_float_controls_execution_mode();
 
emit_nir_code();
 
@@ -6813,6 +6816,8 @@ fs_visitor::run_tes()
if (shader_time_index >= 0)
   emit_shader_time_begin();
 
+   emit_shader_float_controls_execution_mode();
+
emit_nir_code();
 
if (failed)
@@ -6863,6 +6868,8 @@ fs_visitor::run_gs()
if (shader_time_index >= 0)
   emit_shader_time_begin();
 
+   emit_shader_float_controls_execution_mode();
+
emit_nir_code();
 
emit_gs_thread_end();
@@ -6954,6 +6961,8 @@ fs_visitor::run_fs(bool allow_spilling, bool do_rep_send)
  retype(dispatch_mask, BRW_REGISTER_TYPE_UW));
   }
 
+  emit_shader_float_controls_execution_mode();
+
   emit_nir_code();
 
   if (failed)
@@ -7010,6 +7019,8 @@ fs_visitor::run_cs(unsigned min_dispatch_width)
suboffset(retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UW), 1));
}
 
+   emit_shader_float_controls_execution_mode();
+
emit_nir_code();
 
if (failed)
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 16/29] nir: fix denorm flush-to-zero in sqrt's lowering at nir_lower_double_ops

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/nir/nir_lower_double_ops.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_lower_double_ops.c 
b/src/compiler/nir/nir_lower_double_ops.c
index b3543bc6963..c27e2d384a5 100644
--- a/src/compiler/nir/nir_lower_double_ops.c
+++ b/src/compiler/nir/nir_lower_double_ops.c
@@ -289,9 +289,14 @@ lower_sqrt_rsq(nir_builder *b, nir_ssa_def *src, bool sqrt)
* 0 -> 0 and
* +inf -> +inf
*/
-  res = nir_bcsel(b, nir_ior(b, nir_feq(b, src, nir_imm_double(b, 0.0)),
+  nir_ssa_def *src_flushed = nir_bcsel(b,
+   nir_flt(b, nir_fabs(b, src),
+   nir_imm_double(b, 
2.22507385850720138309023271733e-308)),
+   nir_imm_double(b, 0.0),
+   src);
+  res = nir_bcsel(b, nir_ior(b, nir_feq(b, src_flushed, nir_imm_double(b, 
0.0)),
  nir_feq(b, src, nir_imm_double(b, INFINITY))),
- src, res);
+ src_flushed, res);
} else {
   res = fix_inv_result(b, res, src, new_exp);
}
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 15/29] nir: fix denorms in unpack_half_1x16()

[Samuel Iglesias Gonsálvez]

According to VK_KHR_shader_float_controls:

"Denormalized values obtained via unpacking an integer into a vector
 of values with smaller bit width and interpreting those values as
 floating-point numbers must: be flushed to zero, unless the entry point
 is declared with the code:DenormPreserve execution mode."

v2:
- Add nir_op_unpack_half_2x16_flush_to_zero opcode (Connor)

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/nir/nir_constant_expressions.py | 13 +
 src/compiler/nir/nir_lower_alu_to_scalar.c   | 11 +--
 src/compiler/nir/nir_opcodes.py  | 11 ++-
 src/compiler/spirv/vtn_glsl450.c | 15 +++
 4 files changed, 43 insertions(+), 7 deletions(-)

diff --git a/src/compiler/nir/nir_constant_expressions.py 
b/src/compiler/nir/nir_constant_expressions.py
index 84cf819e921..83837457b63 100644
--- a/src/compiler/nir/nir_constant_expressions.py
+++ b/src/compiler/nir/nir_constant_expressions.py
@@ -261,6 +261,19 @@ pack_half_1x16(float x)
return _mesa_float_to_half(x);
 }
 
+/**
+ * Evaluate one component of unpackHalf2x16.
+ */
+static float
+unpack_half_1x16_flush_to_zero(uint16_t u)
+{
+   if (u < 0x0400)
+  u = 0;
+   if (u & 0x8000 && !(u & 0x7c00))
+  u = 0x8000;
+   return _mesa_half_to_float(u);
+}
+
 /**
  * Evaluate one component of unpackHalf2x16.
  */
diff --git a/src/compiler/nir/nir_lower_alu_to_scalar.c 
b/src/compiler/nir/nir_lower_alu_to_scalar.c
index 9b175878c15..e0b650014a4 100644
--- a/src/compiler/nir/nir_lower_alu_to_scalar.c
+++ b/src/compiler/nir/nir_lower_alu_to_scalar.c
@@ -126,6 +126,7 @@ lower_alu_instr_scalar(nir_alu_instr *instr, nir_builder *b)
*/
   return false;
 
+   case nir_op_unpack_half_2x16_flush_to_zero:
case nir_op_unpack_half_2x16: {
   if (!b->shader->options->lower_unpack_half_2x16)
  return false;
@@ -133,8 +134,14 @@ lower_alu_instr_scalar(nir_alu_instr *instr, nir_builder 
*b)
   nir_ssa_def *packed = nir_ssa_for_alu_src(b, instr, 0);
 
   nir_ssa_def *comps[2];
-  comps[0] = nir_unpack_half_2x16_split_x(b, packed);
-  comps[1] = nir_unpack_half_2x16_split_y(b, packed);
+
+  if (instr->op == nir_op_unpack_half_2x16_flush_to_zero) {
+ comps[0] = nir_unpack_half_2x16_split_x_flush_to_zero(b, packed);
+ comps[1] = nir_unpack_half_2x16_split_y_flush_to_zero(b, packed);
+  } else {
+ comps[0] = nir_unpack_half_2x16_split_x(b, packed);
+ comps[1] = nir_unpack_half_2x16_split_y(b, packed);
+  }
   nir_ssa_def *vec = nir_vec(b, comps, 2);
 
   nir_ssa_def_rewrite_uses(>dest.dest.ssa, nir_src_for_ssa(vec));
diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index 21a3847d2ce..de10fd4d510 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -330,14 +330,23 @@ unop_horiz("unpack_64_4x16", 4, tuint16, 1, tuint64,
 unop_horiz("unpack_32_2x16", 2, tuint16, 1, tuint32,
"dst.x = src0.x; dst.y = src0.x >> 16;")
 
-# Lowered floating point unpacking operations.
+unop_horiz("unpack_half_2x16_flush_to_zero", 2, tfloat32, 1, tuint32, """
+dst.x = unpack_half_1x16_flush_to_zero((uint16_t)(src0.x & 0x));
+dst.y = unpack_half_1x16_flush_to_zero((uint16_t)(src0.x << 16));
+""")
 
+# Lowered floating point unpacking operations.
 
 unop_convert("unpack_half_2x16_split_x", tfloat32, tuint32,
  "unpack_half_1x16((uint16_t)(src0 & 0x))", "")
 unop_convert("unpack_half_2x16_split_y", tfloat32, tuint32,
  "unpack_half_1x16((uint16_t)(src0 >> 16))", "")
 
+unop_convert("unpack_half_2x16_split_x_flush_to_zero", tfloat32, tuint32,
+ "unpack_half_1x16_flush_to_zero((uint16_t)(src0 & 0x))", "")
+unop_convert("unpack_half_2x16_split_y_flush_to_zero", tfloat32, tuint32,
+ "unpack_half_1x16_flush_to_zero((uint16_t)(src0 >> 16))", "")
+
 unop_convert("unpack_32_2x16_split_x", tuint16, tuint32, "src0", "")
 unop_convert("unpack_32_2x16_split_y", tuint16, tuint32, "src0 >> 16", "")
 
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index c40594290a3..38ecafae21f 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -513,7 +513,8 @@ build_frexp64(nir_builder *b, nir_ssa_def *x, nir_ssa_def 
**exponent)
 
 static nir_op
 vtn_nir_alu_op_for_spirv_glsl_opcode(struct vtn_builder *b,
- enum GLSLstd450 opcode)
+ enum GLSLstd450 opcode,
+ nir_rounding_mode rounding_mode)
 {
switch (opcode) {
case GLSLstd450Round: return nir_op_fround_even;
@@ -559,7 +560,11 @@ vtn_nir_alu_op_for_spirv_glsl_opcode(struct vtn_builder *b,
case GLSLstd450UnpackUnorm4x8:   return nir_op_unpack_unorm_4x8;
case GLSLstd450UnpackSnorm2x16:  return nir_op_unpack_snorm_2x16;
case GLSLstd450UnpackUnorm2x16:  return 

[Mesa-dev] [PATCH v2 17/29] nir: fix fmin/fmax support for doubles

[Samuel Iglesias Gonsálvez]

Until now, it was using the floating point version of fmin, instead
of the double version.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/nir/nir_opcodes.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index de10fd4d510..c3fc2974fdf 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -661,10 +661,10 @@ opcode("fdph", 1, tfloat, [3, 4], [tfloat, tfloat], "",
 opcode("fdph_replicated", 4, tfloat, [3, 4], [tfloat, tfloat], "",
"src0.x * src1.x + src0.y * src1.y + src0.z * src1.z + src1.w", "")
 
-binop("fmin", tfloat, "", "fminf(src0, src1)")
+binop("fmin", tfloat, "", "fmin(src0, src1)")
 binop("imin", tint, commutative + associative, "src1 > src0 ? src0 : src1")
 binop("umin", tuint, commutative + associative, "src1 > src0 ? src0 : src1")
-binop("fmax", tfloat, "", "fmaxf(src0, src1)")
+binop("fmax", tfloat, "", "fmax(src0, src1)")
 binop("imax", tint, commutative + associative, "src1 > src0 ? src1 : src0")
 binop("umax", tuint, commutative + associative, "src1 > src0 ? src1 : src0")
 
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 02/29] spirv: check support for SPV_KHR_shader_float_controls capabilities

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/shader_info.h| 1 +
 src/compiler/spirv/spirv_to_nir.c | 7 +++
 2 files changed, 8 insertions(+)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index b4bc95912a5..53a89a38244 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -48,6 +48,7 @@ struct spirv_supported_capabilities {
bool int16;
bool float16;
bool int8;
+   bool shader_float_controls;
bool shader_viewport_index_layer;
bool subgroup_arithmetic;
bool subgroup_ballot;
diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index dbfd800c945..60c94806cd2 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3581,6 +3581,13 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
 
   case SpvCapabilitySampleMaskPostDepthCoverage:
  spv_check_supported(post_depth_coverage, cap);
+
+  case SpvCapabilityDenormFlushToZero:
+  case SpvCapabilityDenormPreserve:
+  case SpvCapabilitySignedZeroInfNanPreserve:
+  case SpvCapabilityRoundingModeRTE:
+  case SpvCapabilityRoundingModeRTZ:
+ spv_check_supported(shader_float_controls, cap);
  break;
 
   default:
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 07/29] spirv/glsl450: fix reflect(denorm, denorm) FTZ = 0.0 case

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/spirv/vtn_glsl450.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index 82cc7dc909c..c40594290a3 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -671,13 +671,18 @@ handle_glsl450_alu(struct vtn_builder *b, enum GLSLstd450 
entrypoint,
src[0], nir_fneg(nb, src[0]));
   return;
 
-   case GLSLstd450Reflect:
+   case GLSLstd450Reflect: {
   /* I - 2 * dot(N, I) * N */
-  val->ssa->def =
+  nir_ssa_def *reflect =
  nir_fsub(nb, src[0], nir_fmul(nb, NIR_IMM_FP(nb, 2.0),
-  nir_fmul(nb, nir_fdot(nb, src[0], src[1]),
-   src[1])));
+   nir_fmul(nb, nir_fdot(nb, src[0], 
src[1]),
+src[1])));
+  nir_ssa_def *zero = NIR_IMM_FP(nb, 0.0);
+  val->ssa->def = nir_bcsel(nb, nir_iand(nb,
+nir_feq(nb, src[0], zero),
+nir_feq(nb, src[1], zero)), zero, 
reflect);
   return;
+   }
 
case GLSLstd450Refract: {
   nir_ssa_def *I = src[0];
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 14/29] nir: fix constant expressions for rounding mode conversions

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/nir/nir_constant_expressions.py | 46 +---
 1 file changed, 41 insertions(+), 5 deletions(-)

diff --git a/src/compiler/nir/nir_constant_expressions.py 
b/src/compiler/nir/nir_constant_expressions.py
index dc2132df0d0..84cf819e921 100644
--- a/src/compiler/nir/nir_constant_expressions.py
+++ b/src/compiler/nir/nir_constant_expressions.py
@@ -64,6 +64,7 @@ template = """\
 #include "util/rounding.h" /* for _mesa_roundeven */
 #include "util/half_float.h"
 #include "util/bigmath.h"
+#include "util/double.h"
 #include "nir_constant_expressions.h"
 
 /**
@@ -324,7 +325,15 @@ struct ${type}${width}_vec {
  % elif input_types[j] == "float16":
 _mesa_half_to_float(_src[${j}].u16[${k}]),
  % else:
-_src[${j}].${get_const_field(input_types[j])}[${k}],
+% if ("rtne" in op.rounding_mode) and ("float" in input_types[j]) 
and ("int" in output_type):
+   % if "float32" in input_types[j]:
+  
_mesa_roundevenf(_src[${j}].${get_const_field(input_types[j])}[${k}]),
+   % else:
+  
_mesa_roundeven(_src[${j}].${get_const_field(input_types[j])}[${k}]),
+   % endif
+% else:
+   _src[${j}].${get_const_field(input_types[j])}[${k}],
+% endif
  % endif
   % endfor
   % for k in range(op.input_sizes[j], 4):
@@ -353,8 +362,27 @@ struct ${type}${width}_vec {
const float src${j} =
   _mesa_half_to_float(_src[${j}].u16[_i]);
 % else:
-   const ${input_types[j]}_t src${j} =
-  _src[${j}].${get_const_field(input_types[j])}[_i];
+   % if ("rtne" in op.rounding_mode) and ("float" in 
input_types[j]) and ("int" in output_type):
+  % if "float32" in input_types[j]:
+ const ${input_types[j]}_t src${j} =
+
_mesa_roundevenf(_src[${j}].${get_const_field(input_types[j])}[_i]);
+  % else:
+ const ${input_types[j]}_t src${j} =
+
_mesa_roundeven(_src[${j}].${get_const_field(input_types[j])}[_i]);
+
+  % endif
+   % elif ("float64" in input_types[j]) and ("float32" in 
output_type):
+  % if ("rtz" in op.rounding_mode):
+ const ${input_types[j]}_t src${j} =
+
_mesa_double_to_float_rtz(_src[${j}].${get_const_field(input_types[j])}[_i]);
+  % else:
+ const ${input_types[j]}_t src${j} =
+
_mesa_double_to_float_rtne(_src[${j}].${get_const_field(input_types[j])}[_i]);
+  % endif
+   % else:
+  const ${input_types[j]}_t src${j} =
+ _src[${j}].${get_const_field(input_types[j])}[_i];
+   % endif
 % endif
  % endfor
 
@@ -378,7 +406,11 @@ struct ${type}${width}_vec {
 ## Sanitize the C value to a proper NIR 0/-1 bool
 _dst_val.${get_const_field(output_type)}[_i] = -(int)dst;
  % elif output_type == "float16":
-_dst_val.u16[_i] = _mesa_float_to_half(dst);
+% if "rtz" in op.rounding_mode:
+   _dst_val.u16[_i] = _mesa_float_to_float16_rtz(dst);
+% else:
+   _dst_val.u16[_i] = _mesa_float_to_float16_rtne(dst);
+% endif
  % else:
 _dst_val.${get_const_field(output_type)}[_i] = dst;
  % endif
@@ -416,7 +448,11 @@ struct ${type}${width}_vec {
 ## Sanitize the C value to a proper NIR 0/-1 bool
 _dst_val.${get_const_field(output_type)}[${k}] = 
-(int)dst.${"xyzw"[k]};
  % elif output_type == "float16":
-_dst_val.u16[${k}] = _mesa_float_to_half(dst.${"xyzw"[k]});
+% if "rtz" in op.rounding_mode:
+   _dst_val.u16[${k}] = 
_mesa_float_to_float16_rtz(dst.${"xyzw"[k]});
+% else:
+   _dst_val.u16[${k}] = 
_mesa_float_to_float16_rtne(dst.${"xyzw"[k]});
+% endif
  % else:
 _dst_val.${get_const_field(output_type)}[${k}] = dst.${"xyzw"[k]};
  % endif
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 12/29] nir: add new rounding mode conversions

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/nir/nir.h|  2 +
 src/compiler/nir/nir_opcodes.py   | 87 ---
 src/compiler/nir/nir_opcodes_c.py |  4 +-
 3 files changed, 50 insertions(+), 43 deletions(-)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 2f9df3dfe83..05c87290858 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -924,6 +924,8 @@ typedef struct {
nir_alu_type input_types[NIR_MAX_VEC_COMPONENTS];
 
nir_op_algebraic_property algebraic_properties;
+
+   nir_rounding_mode rounding_mode;
 } nir_op_info;
 
 extern const nir_op_info nir_op_infos[nir_num_opcodes];
diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index 1274d29a04e..21a3847d2ce 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -33,7 +33,8 @@ class Opcode(object):
NOTE: this must be kept in sync with nir_op_info
"""
def __init__(self, name, output_size, output_type, input_sizes,
-input_types, algebraic_properties, const_expr):
+input_types, algebraic_properties, const_expr,
+rounding_mode):
   """Parameters:
 
   - name is the name of the opcode (prepend nir_op_ for the enum name)
@@ -72,6 +73,7 @@ class Opcode(object):
   assert isinstance(input_types[0], str)
   assert isinstance(algebraic_properties, str)
   assert isinstance(const_expr, str)
+  assert isinstance(rounding_mode, str)
   assert len(input_sizes) == len(input_types)
   assert 0 <= output_size <= 4
   for size in input_sizes:
@@ -85,6 +87,7 @@ class Opcode(object):
   self.input_sizes = input_sizes
   self.input_types = input_types
   self.algebraic_properties = algebraic_properties
+  self.rounding_mode = rounding_mode
   self.const_expr = const_expr
 
 # helper variables for strings
@@ -138,21 +141,22 @@ associative = "associative "
 opcodes = {}
 
 def opcode(name, output_size, output_type, input_sizes, input_types,
-   algebraic_properties, const_expr):
+   algebraic_properties, const_expr, rounding_mode):
assert name not in opcodes
opcodes[name] = Opcode(name, output_size, output_type, input_sizes,
-  input_types, algebraic_properties, const_expr)
+  input_types, algebraic_properties, const_expr,
+  rounding_mode)
 
-def unop_convert(name, out_type, in_type, const_expr):
-   opcode(name, 0, out_type, [0], [in_type], "", const_expr)
+def unop_convert(name, out_type, in_type, const_expr, rounding_mode):
+   opcode(name, 0, out_type, [0], [in_type], "", const_expr, rounding_mode)
 
 def unop(name, ty, const_expr):
-   opcode(name, 0, ty, [0], [ty], "", const_expr)
+   opcode(name, 0, ty, [0], [ty], "", const_expr, "")
 
 def unop_horiz(name, output_size, output_type, input_size, input_type,
const_expr):
opcode(name, output_size, output_type, [input_size], [input_type], "",
-  const_expr)
+  const_expr, "")
 
 def unop_reduce(name, output_size, output_type, input_type, prereduce_expr,
 reduce_expr, final_expr):
@@ -217,12 +221,11 @@ for src_t in [tint, tuint, tfloat, tbool]:
   for rnd_mode in rnd_modes:
   unop_convert("{0}2{1}{2}{3}".format(src_t[0], dst_t[0],
bit_size, rnd_mode),
-   dst_t + str(bit_size), src_t, "src0")
+   dst_t + str(bit_size), src_t, "src0", rnd_mode)
   else:
   conv_expr = "src0 != 0" if dst_t == tbool else "src0"
   unop_convert("{0}2{1}{2}".format(src_t[0], dst_t[0], bit_size),
-   dst_t + str(bit_size), src_t, conv_expr)
-
+   dst_t + str(bit_size), src_t, conv_expr, "")
 
 # Unary floating-point rounding operations.
 
@@ -242,8 +245,8 @@ unop("fsin", tfloat, "bit_size == 64 ? sin(src0) : 
sinf(src0)")
 unop("fcos", tfloat, "bit_size == 64 ? cos(src0) : cosf(src0)")
 
 # dfrexp
-unop_convert("frexp_exp", tint32, tfloat64, "frexp(src0, );")
-unop_convert("frexp_sig", tfloat64, tfloat64, "int n; dst = frexp(src0, );")
+unop_convert("frexp_exp", tint32, tfloat64, "frexp(src0, );", "")
+unop_convert("frexp_sig", tfloat64, tfloat64, "int n; dst = frexp(src0, );", 
"")
 
 # Partial derivatives.
 
@@ -331,15 +334,15 @@ unop_horiz("unpack_32_2x16", 2, tuint16, 1, tuint32,
 
 
 unop_convert("unpack_half_2x16_split_x", tfloat32, tuint32,
- "unpack_half_1x16((uint16_t)(src0 & 0x))")
+ "unpack_half_1x16((uint16_t)(src0 & 0x))", "")
 unop_convert("unpack_half_2x16_split_y", tfloat32, tuint32,
- "unpack_half_1x16((uint16_t)(src0 >> 16))")
+ "unpack_half_1x16((uint16_t)(src0 >> 16))", "")
 
-unop_convert("unpack_32_2x16_split_x", tuint16, tuint32, "src0")

[Mesa-dev] [PATCH v2 01/29] spirv: Update SPIR-V json and headers to Khronos master

[Samuel Iglesias Gonsálvez]

This corresponds to commit 17da9f8231f78cf519b4958c2229463a63ead9e2 on GitHub.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/spirv/spirv.core.grammar.json | 316 +++--
 src/compiler/spirv/spirv.h |  84 +++---
 2 files changed, 281 insertions(+), 119 deletions(-)

diff --git a/src/compiler/spirv/spirv.core.grammar.json 
b/src/compiler/spirv/spirv.core.grammar.json
index 034e3ab4446..cd178596594 100644
--- a/src/compiler/spirv/spirv.core.grammar.json
+++ b/src/compiler/spirv/spirv.core.grammar.json
@@ -3825,7 +3825,7 @@
   "version" : "None"
 },
 {
-  "opname" : "OpReportIntersectionNVX",
+  "opname" : "OpReportIntersectionNV",
   "opcode" : 5334,
   "operands" : [
 { "kind" : "IdResultType" },
@@ -3833,25 +3833,25 @@
 { "kind" : "IdRef", "name" : "'Hit'" },
 { "kind" : "IdRef", "name" : "'HitKind'" }
   ],
-  "capabilities" : [ "RaytracingNVX" ],
-  "extensions" : [ "SPV_NVX_raytracing" ]
+  "capabilities" : [ "RayTracingNV" ],
+  "extensions" : [ "SPV_NV_ray_tracing" ]
 },
 {
-  "opname" : "OpIgnoreIntersectionNVX",
+  "opname" : "OpIgnoreIntersectionNV",
   "opcode" : 5335,
 
-  "capabilities" : [ "RaytracingNVX" ],
-  "extensions" : [ "SPV_NVX_raytracing" ]
+  "capabilities" : [ "RayTracingNV" ],
+  "extensions" : [ "SPV_NV_ray_tracing" ]
 },
 {
-  "opname" : "OpTerminateRayNVX",
+  "opname" : "OpTerminateRayNV",
   "opcode" : 5336,
 
-  "capabilities" : [ "RaytracingNVX" ],
-  "extensions" : [ "SPV_NVX_raytracing" ]
+  "capabilities" : [ "RayTracingNV" ],
+  "extensions" : [ "SPV_NV_ray_tracing" ]
 },
 {
-  "opname" : "OpTraceNVX",
+  "opname" : "OpTraceNV",
   "opcode" : 5337,
   "operands" : [
 
@@ -3867,17 +3867,28 @@
 { "kind" : "IdRef", "name" : "'Ray Tmax'" },
 { "kind" : "IdRef", "name" : "'PayloadId'" }
   ],
-  "capabilities" : [ "RaytracingNVX" ],
-  "extensions" : [ "SPV_NVX_raytracing" ]
+  "capabilities" : [ "RayTracingNV" ],
+  "extensions" : [ "SPV_NV_ray_tracing" ]
 },
 {
-  "opname" : "OpTypeAccelerationStructureNVX",
+  "opname" : "OpTypeAccelerationStructureNV",
   "opcode" : 5341,
   "operands" : [
 { "kind" : "IdResult" }
   ],
-  "capabilities" : [ "RaytracingNVX" ],
-  "extensions" : [ "SPV_NVX_raytracing" ]
+  "capabilities" : [ "RayTracingNV" ],
+  "extensions" : [ "SPV_NV_ray_tracing" ]
+},
+{
+  "opname" : "OpExecuteCallableNV",
+  "opcode" : 5344,
+  "operands" : [
+
+{ "kind" : "IdRef", "name" : "'SBT Index'" },
+{ "kind" : "IdRef", "name" : "'Callable DataId'" }
+  ],
+  "capabilities" : [ "RayTracingNV" ],
+  "extensions" : [ "SPV_NV_ray_tracing" ]
 },
 {
   "opname" : "OpSubgroupShuffleINTEL",
@@ -4443,34 +4454,34 @@
   "capabilities" : [ "MeshShadingNV" ]
 },
 {
-  "enumerant" : "RayGenerationNVX",
+  "enumerant" : "RayGenerationNV",
   "value" : 5313,
-  "capabilities" : [ "RaytracingNVX" ]
+  "capabilities" : [ "RayTracingNV" ]
 },
 {
-  "enumerant" : "IntersectionNVX",
+  "enumerant" : "IntersectionNV",
   "value" : 5314,
-  "capabilities" : [ "RaytracingNVX" ]
+  "capabilities" : [ "RayTracingNV" ]
 },
 {
-  "enumerant" : "AnyHitNVX",
+  "enumerant" : "AnyHitNV",
   "value" : 5315,
-  "capabilities" : [ "RaytracingNVX" ]
+  "capabilities" : [ "RayTracingNV" ]
 },
 {
-  "enumerant" : "ClosestHitNVX",
+  "enumerant" : "ClosestHitNV",
   "value" : 5316,
-  "capabilities" : [ "RaytracingNVX" ]
+  "capabilities" : [ "RayTracingNV" ]
 },
 {
-  "enumerant" : "MissNVX",
+  "enumerant" : "MissNV",
   "value" : 5317,
-  "capabilities" : [ "RaytracingNVX" ]
+  "capabilities" : [ "RayTracingNV" ]
 },
 {
-  "enumerant" : "CallableNVX",
+  "enumerant" : "CallableNV",
   "value" : 5318,
-  "capabilities" : [ "RaytracingNVX" ]
+  "capabilities" : [ "RayTracingNV" ]
 }
   ]
 },
@@ -4762,6 +4773,56 @@
   "extensions" : [ "SPV_KHR_post_depth_coverage" ],
   "version" : "None"
 },
+{
+  "enumerant" : "DenormPreserve",
+  "value" : 4459,
+  "capabilities" : [ "DenormPreserve"],
+  "extensions" : [ "SPV_KHR_float_controls" ],
+  "parameters" : [
+{ "kind" : "LiteralInteger", "name" : "'Target Width'" }
+  ],
+  "version" : "None"
+},
+{
+  "enumerant" : "DenormFlushToZero",
+  "value" : 4460,
+  "capabilities" : [ "DenormFlushToZero"],
+  

[Mesa-dev] [PATCH v2 03/29] spirv/nir: keep track of SPV_KHR_shader_float_controls execution modes

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/shader_enums.h   | 14 ++
 src/compiler/shader_info.h|  3 +++
 src/compiler/spirv/spirv_to_nir.c | 26 ++
 3 files changed, 43 insertions(+)

diff --git a/src/compiler/shader_enums.h b/src/compiler/shader_enums.h
index f023b48cbb3..15caf753efb 100644
--- a/src/compiler/shader_enums.h
+++ b/src/compiler/shader_enums.h
@@ -750,6 +750,20 @@ enum compare_func
COMPARE_FUNC_ALWAYS,
 };
 
+enum shader_float_controls
+{
+   SHADER_DEFAULT_FLOAT_CONTROL_MODE  = 0x,
+   SHADER_DENORM_PRESERVE_FP16= 0x0001,
+   SHADER_DENORM_PRESERVE_FP32= 0x0002,
+   SHADER_DENORM_PRESERVE_FP64= 0x0004,
+   SHADER_DENORM_FLUSH_TO_ZERO_FP16   = 0x0008,
+   SHADER_DENORM_FLUSH_TO_ZERO_FP32   = 0x0010,
+   SHADER_DENORM_FLUSH_TO_ZERO_FP64   = 0x0020,
+   SHADER_SIGNED_ZERO_INF_NAN_PRESERVE= 0x0040,
+   SHADER_ROUNDING_MODE_RTE   = 0x0080,
+   SHADER_ROUNDING_MODE_RTZ   = 0x0100,
+};
+
 #ifdef __cplusplus
 } /* extern "C" */
 #endif
diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 53a89a38244..cc157036f75 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -135,6 +135,9 @@ typedef struct shader_info {
/** Was this shader linked with any transform feedback varyings? */
bool has_transform_feedback_varyings;
 
+   /* SPV_KHR_shader_float_controls: execution mode for floating point ops */
+   unsigned shader_float_controls_execution_mode;
+
union {
   struct {
  /* Which inputs are doubles */
diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 60c94806cd2..96d4d80970f 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3780,6 +3780,32 @@ vtn_handle_execution_mode(struct vtn_builder *b, struct 
vtn_value *entry_point,
   vtn_assert(b->shader->info.stage == MESA_SHADER_FRAGMENT);
   break;
 
+   case SpvExecutionModeDenormPreserve:
+  switch (mode->literals[0]) {
+  case 16: b->shader->info.shader_float_controls_execution_mode |= 
SHADER_DENORM_PRESERVE_FP16; break;
+  case 32: b->shader->info.shader_float_controls_execution_mode |= 
SHADER_DENORM_PRESERVE_FP32; break;
+  case 64: b->shader->info.shader_float_controls_execution_mode |= 
SHADER_DENORM_PRESERVE_FP64; break;
+  default: vtn_fail("Floating point type not supported");
+  }
+  break;
+   case SpvExecutionModeDenormFlushToZero:
+  switch (mode->literals[0]) {
+  case 16: b->shader->info.shader_float_controls_execution_mode |= 
SHADER_DENORM_FLUSH_TO_ZERO_FP16; break;
+  case 32: b->shader->info.shader_float_controls_execution_mode |= 
SHADER_DENORM_FLUSH_TO_ZERO_FP32; break;
+  case 64: b->shader->info.shader_float_controls_execution_mode |= 
SHADER_DENORM_FLUSH_TO_ZERO_FP64; break;
+  default: vtn_fail("Floating point type not supported");
+  }
+   break;
+   case SpvExecutionModeSignedZeroInfNanPreserve:
+  b->shader->info.shader_float_controls_execution_mode |= 
SHADER_SIGNED_ZERO_INF_NAN_PRESERVE;
+  break;
+   case SpvExecutionModeRoundingModeRTE:
+  b->shader->info.shader_float_controls_execution_mode |= 
SHADER_ROUNDING_MODE_RTE;
+  break;
+   case SpvExecutionModeRoundingModeRTZ:
+  b->shader->info.shader_float_controls_execution_mode |= 
SHADER_ROUNDING_MODE_RTZ;
+  break;
+
default:
   vtn_fail("Unhandled execution mode");
}
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 05/29] spirv/glsl450: fix atan2(0, 0) lowering

[Samuel Iglesias Gonsálvez]

We were returning 3*pi/4 when we should return 0.0 according to IEEE 754.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/spirv/vtn_glsl450.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index 0a641077513..db4e3287b3c 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -381,8 +381,12 @@ build_atan2(nir_builder *b, nir_ssa_def *y, nir_ssa_def *x)
 * continuous along the whole positive y = 0 half-line, so it won't affect
 * the result significantly.
 */
-   return nir_bcsel(b, nir_flt(b, nir_fmin(b, y, rcp_scaled_t), zero),
-nir_fneg(b, arc), arc);
+   nir_ssa_def *result = nir_bcsel(b, nir_flt(b, nir_fmin(b, y, rcp_scaled_t), 
zero),
+   nir_fneg(b, arc), arc);
+   nir_ssa_def *is_xy_zero = nir_iand(b,
+ nir_feq(b, x, zero),
+ nir_feq(b, y, zero));
+   return nir_bcsel(b, is_xy_zero, zero, result);
 }
 
 static nir_ssa_def *
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 11/29] util: add fp64 -> fp32 conversion support for RTNE and RTZ rounding modes

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/util/Makefile.sources |   2 +
 src/util/double.c | 197 ++
 src/util/double.h |  46 +
 src/util/meson.build  |   2 +
 4 files changed, 247 insertions(+)
 create mode 100644 src/util/double.c
 create mode 100644 src/util/double.h

diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
index f09b89b3be5..1b998bf26c4 100644
--- a/src/util/Makefile.sources
+++ b/src/util/Makefile.sources
@@ -11,6 +11,8 @@ MESA_UTIL_FILES := \
debug.h \
disk_cache.c \
disk_cache.h \
+   double.c \
+   double.h \
fast_idiv_by_const.c \
fast_idiv_by_const.h \
format_r11g11b10f.h \
diff --git a/src/util/double.c b/src/util/double.c
new file mode 100644
index 000..61f23e3b57b
--- /dev/null
+++ b/src/util/double.c
@@ -0,0 +1,197 @@
+/*
+ * Mesa 3-D graphics library
+ *
+ * Copyright (C) 2018 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 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "rounding.h"
+#include "double.h"
+
+
+
+
+typedef union { double f; int64_t i; uint64_t u; } fi_type;
+
+/**
+ * Convert a 8-byte double to a 4-byte float.
+ *
+ * Not all float64 values can be represented exactly as a float32 value. We
+ * round such intermediate float64 values to the nearest float32. When the
+ * float64 lies exactly between two float32 values, we round to the one with
+ * an even mantissa.
+ */
+
+float
+_mesa_double_to_float(double val)
+{
+   const fi_type fi = {val};
+   const int64_t flt_m = fi.i & 0x0f;
+   const int64_t flt_e = (fi.i >> 52) & 0x7ff;
+   const int64_t flt_s = (fi.i >> 63) & 0x1;
+   int s, e, m = 0;
+   float result;
+
+   /* sign bit */
+   s = flt_s;
+
+   /* handle special cases */
+   if ((flt_e == 0) && (flt_m == 0)) {
+  /* zero */
+  /* m = 0; - already set */
+  e = 0;
+   }
+   else if ((flt_e == 0) && (flt_m != 0)) {
+  /* denorm -- denorm float64 maps to 0 */
+  /* m = 0; - already set */
+  e = 0;
+   }
+   else if ((flt_e == 0x7ff) && (flt_m == 0)) {
+  /* infinity */
+  /* m = 0; - already set */
+  e = 255;
+   }
+   else if ((flt_e == 0x7ff) && (flt_m != 0)) {
+  /* NaN */
+  m = 1;
+  e = 255;
+   }
+   else {
+  /* regular number */
+  const int new_exp = flt_e - 1023;
+  if (new_exp < -126) {
+ /* The float64 lies in the range (0.0, min_normal32) and is rounded
+  * to a nearby float32 value. The result will be either zero, 
subnormal,
+  * or normal.
+  */
+ e = 0;
+ m = _mesa_lroundeven(((double)((uint64_t)1 << 54)) * fabs(fi.f));
+  }
+  else if (new_exp > 127) {
+ /* map this value to infinity */
+ /* m = 0; - already set */
+ e = 255;
+  }
+  else {
+ /* The float64 lies in the range
+  *   [min_normal32, max_normal32 + max_step32)
+  * and is rounded to a nearby float32 value. The result will be
+  * either normal or infinite.
+  */
+ e = new_exp + 127;
+ m = _mesa_lroundeven((double)flt_m / (double) (1 << 29));
+  }
+   }
+
+   assert(0 <= m && m <= (1 << 23));
+   if (m == (1 << 23)) {
+  /* The float64 was rounded upwards into the range of the next exponent,
+   * so bump the exponent. This correctly handles the case where f64
+   * should be rounded up to float32 infinity.
+   */
+  ++e;
+  m = 0;
+   }
+
+   unsigned result_int = (s << 31) | (e << 23) | m;
+   memcpy(, _int, sizeof(float));
+   return result;
+}
+
+float
+_mesa_double_to_float_rtz(double val)
+{
+   const fi_type fi = {val};
+   const int64_t flt_m = fi.i & 0x0f;
+   const int64_t flt_e = (fi.i >> 52) & 0x7ff;
+   const int64_t flt_s = (fi.i >> 63) & 0x1;
+   int s, e, m = 0;
+   float result;
+
+   /* sign bit */
+  

[Mesa-dev] [PATCH v2 09/29] nir: create new conversion opcodes with floating point rounding modes

[Samuel Iglesias Gonsálvez]

It adds round-towards-zero and round-to-nearest-even opcodes for
floating point conversions.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/nir/nir_opcodes.py   | 2 +-
 src/compiler/nir/nir_opcodes_c.py | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index d32005846a6..1274d29a04e 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -212,7 +212,7 @@ for src_t in [tint, tuint, tfloat, tbool]:
 
for dst_t in dst_types:
   for bit_size in type_sizes(dst_t):
-  if bit_size == 16 and dst_t == tfloat and src_t == tfloat:
+  if src_t == tfloat and dst_t == tfloat:
   rnd_modes = ['_rtne', '_rtz', '']
   for rnd_mode in rnd_modes:
   unop_convert("{0}2{1}{2}{3}".format(src_t[0], dst_t[0],
diff --git a/src/compiler/nir/nir_opcodes_c.py 
b/src/compiler/nir/nir_opcodes_c.py
index 017c8b7ea9a..e3548bd6e21 100644
--- a/src/compiler/nir/nir_opcodes_c.py
+++ b/src/compiler/nir/nir_opcodes_c.py
@@ -76,7 +76,7 @@ nir_type_conversion_op(nir_alu_type src, nir_alu_type dst, 
nir_rounding_mode rnd
switch (dst_bit_size) {
 % for dst_bits in type_sizes(dst_t):
   case ${dst_bits}:
-%if src_t == 'float' and dst_t == 'float' and dst_bits == 
16:
+%if src_t == 'float' and dst_t == 'float':
  switch(rnd) {
 %   for rnd_t in [('rtne', '_rtne'), ('rtz', '_rtz'), 
('undef', '')]:
 case nir_rounding_mode_${rnd_t[0]}:
@@ -84,7 +84,7 @@ nir_type_conversion_op(nir_alu_type src, nir_alu_type dst, 
nir_rounding_mode rnd
dst_bits, 
rnd_t[1])};
 %   endfor
 default:
-   unreachable("Invalid 16-bit nir rounding mode");
+   unreachable("Invalid ${dst_bits}-bit nir rounding 
mode");
  }
 %else:
  assert(rnd == nir_rounding_mode_undef);
-- 
2.19.1

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