[Mesa-dev] [PATCH] util: Don't block SIGSYS for new threads

[Drew Davenport]

SIGSYS is needed for programs using seccomp for sandboxing.
---
 src/util/u_thread.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/util/u_thread.h b/src/util/u_thread.h
index 7538d7d634b2..a46c18d3db20 100644
--- a/src/util/u_thread.h
+++ b/src/util/u_thread.h
@@ -44,7 +44,8 @@ static inline thrd_t u_thread_create(int (*routine)(void *), 
void *param)
int ret;
 
sigfillset(_set);
-   pthread_sigmask(SIG_SETMASK, _set, _set);
+   sigdelset(_set, SIGSYS);
+   pthread_sigmask(SIG_BLOCK, _set, _set);
ret = thrd_create( , routine, param );
pthread_sigmask(SIG_SETMASK, _set, NULL);
 #else
-- 
2.20.1

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

[Mesa-dev] [AppVeyor] mesa master #10151 completed

[AppVeyor]

Build mesa 10151 completed



Commit 4c160b6bd8 by Caio Marcelo de Oliveira Filho on 2/23/2019 6:38 AM:

nir: fix MSVC build\n\nZero initialize struct with {0} instead of {}.


Configure your notification preferences

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

[Mesa-dev] [AppVeyor] mesa master #10150 failed

[AppVeyor]

Build mesa 10150 failed


Commit eb13211997 by Caio Marcelo de Oliveira Filho on 1/14/2019 9:52 PM:

nir/copy_prop_vars: add tests for load/store elements of vectors\n\nTest using array deref on vectors in loads and stores.  These are\nmarked DISABLED_ as this optimization is currently not done.\n\nReviewed-by: Jason Ekstrand 


Configure your notification preferences

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

[Mesa-dev] [PATCH] nir/split_vars: Don't compact vectors unnecissarily

[Jason Ekstrand]

---
 src/compiler/nir/nir_split_vars.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/compiler/nir/nir_split_vars.c 
b/src/compiler/nir/nir_split_vars.c
index 244ffd6dcf0..96b6042e6d9 100644
--- a/src/compiler/nir/nir_split_vars.c
+++ b/src/compiler/nir/nir_split_vars.c
@@ -1423,6 +1423,12 @@ shrink_vec_var_access_impl(nir_function_impl *impl,
continue;
 }
 
+/* If we're not dropping any components, there's no need to
+ * compact vectors.
+ */
+if (usage->comps_kept == usage->all_comps)
+   continue;
+
 if (intrin->intrinsic == nir_intrinsic_load_deref) {
b.cursor = nir_after_instr(>instr);
 
-- 
2.20.1

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

[Mesa-dev] [Bug 109752] meson: more ensure that xmlpool_options.h is generated for targets that need it

[bugzilla-daemon]

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

Bug ID: 109752
   Summary: meson: more ensure that xmlpool_options.h is generated
for  targets that need it
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: NetBSD
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: davs...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 143443
  --> https://bugs.freedesktop.org/attachment.cgi?id=143443=edit
xmlpool_options.h patches

Extension of
2018-02-06 meson: ensure xmlpool/options.h is generated for libgallium
commit  9440599c8e030bddd7e04620bed22df5a8a097fd

Lack of these patches caused a meson build to fail on NetBSD NetBSD 8.99.34
(GENERIC) pkgsrc for
2019-02-02  wsi/display: add comment
commit 808bf59cac793bc6c7de04eee4e23e6921a8a7b5

Subject: [PATCH] meson: more ensure that xmlpool_options.h is generated for
 targets that need it

Extension of
2018-02-06 meson: ensure xmlpool/options.h is generated for libgallium
commit  9440599c8e030bddd7e04620bed22df5a8a097fd
---
 src/gallium/targets/omx/meson.build   | 2 +-
 src/gallium/targets/va/meson.build| 2 +-
 src/gallium/targets/vdpau/meson.build | 2 +-
 src/gallium/targets/xa/meson.build| 2 +-
 src/gallium/targets/xvmc/meson.build  | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/gallium/targets/omx/meson.build
b/src/gallium/targets/omx/meson.build
index 6811e6ff904..09925cb3c21 100644
--- a/src/gallium/targets/omx/meson.build
+++ b/src/gallium/targets/omx/meson.build
@@ -32,7 +32,7 @@ endif

 libomx_gallium = shared_library(
   'omx_mesa',
-  'target.c',
+  [files('target.c'), xmlpool_options_h],
   c_args : c_vis_args,
   cpp_args : cpp_vis_args,
   link_args : [omx_link_args, ld_args_gc_sections],
diff --git a/src/gallium/targets/va/meson.build
b/src/gallium/targets/va/meson.build
index ded689b464d..49e222cefb1 100644
--- a/src/gallium/targets/va/meson.build
+++ b/src/gallium/targets/va/meson.build
@@ -33,7 +33,7 @@ endif

 libva_gallium = shared_library(
   'gallium_drv_video',
-  'target.c',
+  [files('target.c'), xmlpool_options_h],
   c_args : c_vis_args,
   cpp_args : cpp_vis_args,
   link_args : [va_link_args, ld_args_gc_sections],
diff --git a/src/gallium/targets/vdpau/meson.build
b/src/gallium/targets/vdpau/meson.build
index 22e3f5ffdd8..4398d67cdf7 100644
--- a/src/gallium/targets/vdpau/meson.build
+++ b/src/gallium/targets/vdpau/meson.build
@@ -38,7 +38,7 @@ endif

 libvdpau_gallium = shared_library(
   'vdpau_gallium',
-  'target.c',
+  [files('target.c'), xmlpool_options_h],
   c_args : c_vis_args,
   cpp_args : cpp_vis_args,
   link_args : [vdpau_link_args, ld_args_gc_sections],
diff --git a/src/gallium/targets/xa/meson.build
b/src/gallium/targets/xa/meson.build
index 733ef54ff85..7bbefa63940 100644
--- a/src/gallium/targets/xa/meson.build
+++ b/src/gallium/targets/xa/meson.build
@@ -34,7 +34,7 @@ _xa_version = '.'.join(xa_version)

 libxatracker = shared_library(
   'xatracker',
-  'target.c',
+  [files('target.c'), xmlpool_options_h],
   c_args : c_vis_args,
   cpp_args : cpp_vis_args,
   link_args : [xa_link_args, ld_args_gc_sections],
diff --git a/src/gallium/targets/xvmc/meson.build
b/src/gallium/targets/xvmc/meson.build
index 0af5b6477ce..e1d748cde66 100644
--- a/src/gallium/targets/xvmc/meson.build
+++ b/src/gallium/targets/xvmc/meson.build
@@ -33,7 +33,7 @@ endif

 libxvmc_gallium = shared_library(
   'XvMCgallium',
-  'target.c',
+  [files('target.c'), xmlpool_options_h],
   c_args : c_vis_args,
   cpp_args : cpp_vis_args,
   link_args : [xvmc_link_args, ld_args_gc_sections],
-- 
2.20.1

-- 
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] nir/algebraic: Replace a-fract(a) with floor(a)

[Ian Romanick]

From: Ian Romanick 

I noticed this while looking at a shader that was affected by Tim's
"more loop unrolling" series.

All Gen6+ platforms had similar results. (Skylake shown)
total instructions in shared programs: 15437001 -> 15435259 (-0.01%)
instructions in affected programs: 213651 -> 211909 (-0.82%)
helped: 988
HURT: 0
helped stats (abs) min: 1 max: 27 x̄: 1.76 x̃: 1
helped stats (rel) min: 0.15% max: 11.54% x̄: 1.14% x̃: 0.59%
95% mean confidence interval for instructions value: -1.89 -1.63
95% mean confidence interval for instructions %-change: -1.23% -1.05%
Instructions are helped.

total cycles in shared programs: 383007378 -> 382997063 (<.01%)
cycles in affected programs: 1650825 -> 1640510 (-0.62%)
helped: 679
HURT: 302
helped stats (abs) min: 1 max: 348 x̄: 23.39 x̃: 14
helped stats (rel) min: 0.04% max: 28.77% x̄: 1.61% x̃: 0.98%
HURT stats (abs)   min: 1 max: 250 x̄: 18.43 x̃: 7
HURT stats (rel)   min: 0.04% max: 25.86% x̄: 1.41% x̃: 0.53%
95% mean confidence interval for cycles value: -13.05 -7.98
95% mean confidence interval for cycles %-change: -0.86% -0.50%
Cycles are helped.

Iron Lake and GM45 had similar results. (GM45 shown)
total instructions in shared programs: 5043616 -> 5043010 (-0.01%)
instructions in affected programs: 119691 -> 119085 (-0.51%)
helped: 432
HURT: 0
helped stats (abs) min: 1 max: 27 x̄: 1.40 x̃: 1
helped stats (rel) min: 0.10% max: 8.11% x̄: 0.66% x̃: 0.39%
95% mean confidence interval for instructions value: -1.58 -1.23
95% mean confidence interval for instructions %-change: -0.72% -0.59%
Instructions are helped.

total cycles in shared programs: 128139812 -> 128135762 (<.01%)
cycles in affected programs: 3829724 -> 3825674 (-0.11%)
helped: 602
HURT: 0
helped stats (abs) min: 2 max: 486 x̄: 6.73 x̃: 6
helped stats (rel) min: 0.02% max: 4.85% x̄: 0.19% x̃: 0.10%
95% mean confidence interval for cycles value: -8.40 -5.05
95% mean confidence interval for cycles %-change: -0.22% -0.16%
Cycles are helped.
---
 src/compiler/nir/nir_opt_algebraic.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/compiler/nir/nir_opt_algebraic.py 
b/src/compiler/nir/nir_opt_algebraic.py
index ba27d702b5d..c8fc938cc8f 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -127,6 +127,7 @@ optimizations = [
(('flrp@32', a, b, c), ('fadd', ('fmul', c, ('fsub', b, a)), a), 
'options->lower_flrp32'),
(('flrp@64', a, b, c), ('fadd', ('fmul', c, ('fsub', b, a)), a), 
'options->lower_flrp64'),
(('ffloor', a), ('fsub', a, ('ffract', a)), 'options->lower_ffloor'),
+   (('fadd', a, ('fneg', ('ffract', a))), ('ffloor', a), 
'!options->lower_ffloor'),
(('ffract', a), ('fsub', a, ('ffloor', a)), 'options->lower_ffract'),
(('fceil', a), ('fneg', ('ffloor', ('fneg', a))), 'options->lower_fceil'),
(('~fadd', ('fmul', a, ('fadd', 1.0, ('fneg', ('b2f', 'c@1', ('fmul', 
b, ('b2f', c))), ('bcsel', c, b, a), 'options->lower_flrp32'),
-- 
2.14.4

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

Re: [Mesa-dev] [PATCH] nir/builder: Don't emit no-op swizzles

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Sat, Feb 23, 2019 at 1:14 AM Ian Romanick  wrote:
>
> Reviewed-by: Ian Romanick 
>
> On 2/22/19 4:03 PM, Jason Ekstrand wrote:
> > The nir_swizzle helper is used some on it's own but it's also called by
> > nir_channel and nir_channels which are used everywhere.  It's pretty
> > quick to check while we're walking the swizzle anyway whether or not
> > it's an identity swizzle.  If it is, we now don't bother emitting the
> > instruction.  Sure, copy-prop will clean it up for us but there's no
> > sense making more work for the optimizer than we have to.
> > ---
> >  src/compiler/nir/nir_builder.h | 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
> > index c6e80e729a8..253ca5941cb 100644
> > --- a/src/compiler/nir/nir_builder.h
> > +++ b/src/compiler/nir/nir_builder.h
> > @@ -497,8 +497,16 @@ nir_swizzle(nir_builder *build, nir_ssa_def *src, 
> > const unsigned *swiz,
> > assert(num_components <= NIR_MAX_VEC_COMPONENTS);
> > nir_alu_src alu_src = { NIR_SRC_INIT };
> > alu_src.src = nir_src_for_ssa(src);
> > -   for (unsigned i = 0; i < num_components && i < NIR_MAX_VEC_COMPONENTS; 
> > i++)
> > +
> > +   bool is_identity_swizzle = true;
> > +   for (unsigned i = 0; i < num_components && i < NIR_MAX_VEC_COMPONENTS; 
> > i++) {
> > +  if (swiz[i] != i)
> > + is_identity_swizzle = false;
> >alu_src.swizzle[i] = swiz[i];
> > +   }
> > +
> > +   if (num_components == src->num_components && is_identity_swizzle)
> > +  return src;
> >
> > return use_fmov ? nir_fmov_alu(build, alu_src, num_components) :
> >   nir_imov_alu(build, alu_src, num_components);
> >
>
> ___
> 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 109532] ir_variable has maximum access out of bounds -- but it's not out of bounds

[bugzilla-daemon]

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

--- Comment #38 from Ilia Mirkin  ---
(In reply to asimiklit from comment #36)
> Ilia could you please share your thoughts about this solution?
> Do you agree with Ian suggestion as to disallow the elimination from the
> beginning of the array?
> I am asking about it to understand have we consensus as to a direction of
> the fix or not.

Sounds good to me... I think you can do something like

layout(binding=n) foo[6]

means that n..n+5 are all taken and assigned to the relevant items.

However if you just have "foo[6]", without the explicit binding, you can (and
should) eliminate any pre- and post- elements, i.e. before the first and after
the last. However if foo[1] and foo[5] are used, then they should be 4 binding
points away from one another.

Hope that makes sense.

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

[Mesa-dev] [Bug 109532] ir_variable has maximum access out of bounds -- but it's not out of bounds

[bugzilla-daemon]

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

Rob Clark  changed:

   What|Removed |Added

 CC||robcl...@freedesktop.org

--- Comment #37 from Rob Clark  ---
fwiw, after rebasing deqp, I started hitting the same thing (freedreno/a6xx)
with debug mesa builds vs
dEQP-GLES31.functional.ssbo.layout.random.all_per_block_buffers.18

So I guess the same issue.. I'll read more thru the rest of this bz tomorrow
since already getting late, but just thought I'd mention it (and add myself to
cc on this bz)

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

Re: [Mesa-dev] [PATCH] radeonsi: fix query buffer allocation

[Timothy Arceri]

On 23/2/19 11:31 am, Marek Olšák wrote:
Nicolai also has a change in si_query_buffer_reset. Is there a reason 
the change is not here?


duh ... no reason other than I forgot that bit.



Thanks,
Marek

On Thu, Feb 21, 2019 at 10:09 PM Timothy Arceri > wrote:


Fix the logic for buffer full check on alloc.

This patch just takes the fix Nicolai attached to the bug report
and updates it to work on master.

Fixes: e0f0d3675d4 ("radeonsi: factor si_query_buffer logic out of
si_query_hw")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109561
---
  src/gallium/drivers/radeonsi/si_query.c | 42 +
  src/gallium/drivers/radeonsi/si_query.h |  5 +--
  2 files changed, 25 insertions(+), 22 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_query.c
b/src/gallium/drivers/radeonsi/si_query.c
index 266b9d3ce84..04685b8bb3f 100644
--- a/src/gallium/drivers/radeonsi/si_query.c
+++ b/src/gallium/drivers/radeonsi/si_query.c
@@ -561,29 +561,31 @@ bool si_query_buffer_alloc(struct si_context
*sctx, struct si_query_buffer *buff
                            bool (*prepare_buffer)(struct si_context
*, struct si_query_buffer*),
                            unsigned size)
  {
-       if (buffer->buf && buffer->results_end + size >=
buffer->buf->b.b.width0)
-               return true;
+       bool unprepared = buffer->unprepared;
+       buffer->unprepared = false;
+
+       if (!buffer->buf || buffer->results_end + size >
buffer->buf->b.b.width0) {
+               if (buffer->buf) {
+                       struct si_query_buffer *qbuf =
MALLOC_STRUCT(si_query_buffer);
+                       memcpy(qbuf, buffer, sizeof(*qbuf));
+                       buffer->previous = qbuf;
+               }
+               buffer->results_end = 0;

-       if (buffer->buf) {
-               struct si_query_buffer *qbuf =
MALLOC_STRUCT(si_query_buffer);
-               memcpy(qbuf, buffer, sizeof(*qbuf));
-               buffer->previous = qbuf;
+               /* Queries are normally read by the CPU after
+                * being written by the gpu, hence staging is
probably a good
+                * usage pattern.
+                */
+               struct si_screen *screen = sctx->screen;
+               unsigned buf_size = MAX2(size,
screen->info.min_alloc_size);
+               buffer->buf = si_resource(
+                       pipe_buffer_create(>b, 0,
PIPE_USAGE_STAGING, buf_size));
+               if (unlikely(!buffer->buf))
+                       return false;
+               unprepared = true;
         }

-       buffer->results_end = 0;
-
-       /* Queries are normally read by the CPU after
-        * being written by the gpu, hence staging is probably a good
-        * usage pattern.
-        */
-       struct si_screen *screen = sctx->screen;
-       unsigned buf_size = MAX2(size, screen->info.min_alloc_size);
-       buffer->buf = si_resource(
-               pipe_buffer_create(>b, 0,
PIPE_USAGE_STAGING, buf_size));
-       if (unlikely(!buffer->buf))
-               return false;
-
-       if (prepare_buffer) {
+       if (unprepared && prepare_buffer) {
                 if (unlikely(!prepare_buffer(sctx, buffer))) {
                         si_resource_reference(>buf, NULL);
                         return false;
diff --git a/src/gallium/drivers/radeonsi/si_query.h
b/src/gallium/drivers/radeonsi/si_query.h
index aaf0bd03aca..c61af51d57c 100644
--- a/src/gallium/drivers/radeonsi/si_query.h
+++ b/src/gallium/drivers/radeonsi/si_query.h
@@ -177,12 +177,13 @@ struct si_query_hw_ops {
  struct si_query_buffer {
         /* The buffer where query results are stored. */
         struct si_resource              *buf;
-       /* Offset of the next free result after current query data */
-       unsigned                        results_end;
         /* If a query buffer is full, a new buffer is created and
the old one
          * is put in here. When we calculate the result, we sum up
the samples
          * from all buffers. */
         struct si_query_buffer  *previous;
+       /* Offset of the next free result after current query data */
+       unsigned                        results_end;
+       bool unprepared;
  };

  void si_query_buffer_destroy(struct si_screen *sctx, struct
si_query_buffer *buffer);
-- 
2.20.1


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

Re: [Mesa-dev] [PATCH] radeonsi: fix query buffer allocation

[Marek Olšák]

Nicolai also has a change in si_query_buffer_reset. Is there a reason the
change is not here?

Thanks,
Marek

On Thu, Feb 21, 2019 at 10:09 PM Timothy Arceri 
wrote:

> Fix the logic for buffer full check on alloc.
>
> This patch just takes the fix Nicolai attached to the bug report
> and updates it to work on master.
>
> Fixes: e0f0d3675d4 ("radeonsi: factor si_query_buffer logic out of
> si_query_hw")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109561
> ---
>  src/gallium/drivers/radeonsi/si_query.c | 42 +
>  src/gallium/drivers/radeonsi/si_query.h |  5 +--
>  2 files changed, 25 insertions(+), 22 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_query.c
> b/src/gallium/drivers/radeonsi/si_query.c
> index 266b9d3ce84..04685b8bb3f 100644
> --- a/src/gallium/drivers/radeonsi/si_query.c
> +++ b/src/gallium/drivers/radeonsi/si_query.c
> @@ -561,29 +561,31 @@ bool si_query_buffer_alloc(struct si_context *sctx,
> struct si_query_buffer *buff
>bool (*prepare_buffer)(struct si_context *,
> struct si_query_buffer*),
>unsigned size)
>  {
> -   if (buffer->buf && buffer->results_end + size >=
> buffer->buf->b.b.width0)
> -   return true;
> +   bool unprepared = buffer->unprepared;
> +   buffer->unprepared = false;
> +
> +   if (!buffer->buf || buffer->results_end + size >
> buffer->buf->b.b.width0) {
> +   if (buffer->buf) {
> +   struct si_query_buffer *qbuf =
> MALLOC_STRUCT(si_query_buffer);
> +   memcpy(qbuf, buffer, sizeof(*qbuf));
> +   buffer->previous = qbuf;
> +   }
> +   buffer->results_end = 0;
>
> -   if (buffer->buf) {
> -   struct si_query_buffer *qbuf =
> MALLOC_STRUCT(si_query_buffer);
> -   memcpy(qbuf, buffer, sizeof(*qbuf));
> -   buffer->previous = qbuf;
> +   /* Queries are normally read by the CPU after
> +* being written by the gpu, hence staging is probably a
> good
> +* usage pattern.
> +*/
> +   struct si_screen *screen = sctx->screen;
> +   unsigned buf_size = MAX2(size,
> screen->info.min_alloc_size);
> +   buffer->buf = si_resource(
> +   pipe_buffer_create(>b, 0,
> PIPE_USAGE_STAGING, buf_size));
> +   if (unlikely(!buffer->buf))
> +   return false;
> +   unprepared = true;
> }
>
> -   buffer->results_end = 0;
> -
> -   /* Queries are normally read by the CPU after
> -* being written by the gpu, hence staging is probably a good
> -* usage pattern.
> -*/
> -   struct si_screen *screen = sctx->screen;
> -   unsigned buf_size = MAX2(size, screen->info.min_alloc_size);
> -   buffer->buf = si_resource(
> -   pipe_buffer_create(>b, 0, PIPE_USAGE_STAGING,
> buf_size));
> -   if (unlikely(!buffer->buf))
> -   return false;
> -
> -   if (prepare_buffer) {
> +   if (unprepared && prepare_buffer) {
> if (unlikely(!prepare_buffer(sctx, buffer))) {
> si_resource_reference(>buf, NULL);
> return false;
> diff --git a/src/gallium/drivers/radeonsi/si_query.h
> b/src/gallium/drivers/radeonsi/si_query.h
> index aaf0bd03aca..c61af51d57c 100644
> --- a/src/gallium/drivers/radeonsi/si_query.h
> +++ b/src/gallium/drivers/radeonsi/si_query.h
> @@ -177,12 +177,13 @@ struct si_query_hw_ops {
>  struct si_query_buffer {
> /* The buffer where query results are stored. */
> struct si_resource  *buf;
> -   /* Offset of the next free result after current query data */
> -   unsignedresults_end;
> /* If a query buffer is full, a new buffer is created and the old
> one
>  * is put in here. When we calculate the result, we sum up the
> samples
>  * from all buffers. */
> struct si_query_buffer  *previous;
> +   /* Offset of the next free result after current query data */
> +   unsignedresults_end;
> +   bool unprepared;
>  };
>
>  void si_query_buffer_destroy(struct si_screen *sctx, struct
> si_query_buffer *buffer);
> --
> 2.20.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] nir/builder: Don't emit no-op swizzles

[Ian Romanick]

Reviewed-by: Ian Romanick 

On 2/22/19 4:03 PM, Jason Ekstrand wrote:
> The nir_swizzle helper is used some on it's own but it's also called by
> nir_channel and nir_channels which are used everywhere.  It's pretty
> quick to check while we're walking the swizzle anyway whether or not
> it's an identity swizzle.  If it is, we now don't bother emitting the
> instruction.  Sure, copy-prop will clean it up for us but there's no
> sense making more work for the optimizer than we have to.
> ---
>  src/compiler/nir/nir_builder.h | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
> index c6e80e729a8..253ca5941cb 100644
> --- a/src/compiler/nir/nir_builder.h
> +++ b/src/compiler/nir/nir_builder.h
> @@ -497,8 +497,16 @@ nir_swizzle(nir_builder *build, nir_ssa_def *src, const 
> unsigned *swiz,
> assert(num_components <= NIR_MAX_VEC_COMPONENTS);
> nir_alu_src alu_src = { NIR_SRC_INIT };
> alu_src.src = nir_src_for_ssa(src);
> -   for (unsigned i = 0; i < num_components && i < NIR_MAX_VEC_COMPONENTS; 
> i++)
> +
> +   bool is_identity_swizzle = true;
> +   for (unsigned i = 0; i < num_components && i < NIR_MAX_VEC_COMPONENTS; 
> i++) {
> +  if (swiz[i] != i)
> + is_identity_swizzle = false;
>alu_src.swizzle[i] = swiz[i];
> +   }
> +
> +   if (num_components == src->num_components && is_identity_swizzle)
> +  return src;
>  
> return use_fmov ? nir_fmov_alu(build, alu_src, num_components) :
>   nir_imov_alu(build, alu_src, num_components);
> 

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

[Mesa-dev] [PATCH] nir/builder: Don't emit no-op swizzles

[Jason Ekstrand]

The nir_swizzle helper is used some on it's own but it's also called by
nir_channel and nir_channels which are used everywhere.  It's pretty
quick to check while we're walking the swizzle anyway whether or not
it's an identity swizzle.  If it is, we now don't bother emitting the
instruction.  Sure, copy-prop will clean it up for us but there's no
sense making more work for the optimizer than we have to.
---
 src/compiler/nir/nir_builder.h | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
index c6e80e729a8..253ca5941cb 100644
--- a/src/compiler/nir/nir_builder.h
+++ b/src/compiler/nir/nir_builder.h
@@ -497,8 +497,16 @@ nir_swizzle(nir_builder *build, nir_ssa_def *src, const 
unsigned *swiz,
assert(num_components <= NIR_MAX_VEC_COMPONENTS);
nir_alu_src alu_src = { NIR_SRC_INIT };
alu_src.src = nir_src_for_ssa(src);
-   for (unsigned i = 0; i < num_components && i < NIR_MAX_VEC_COMPONENTS; i++)
+
+   bool is_identity_swizzle = true;
+   for (unsigned i = 0; i < num_components && i < NIR_MAX_VEC_COMPONENTS; i++) 
{
+  if (swiz[i] != i)
+ is_identity_swizzle = false;
   alu_src.swizzle[i] = swiz[i];
+   }
+
+   if (num_components == src->num_components && is_identity_swizzle)
+  return src;
 
return use_fmov ? nir_fmov_alu(build, alu_src, num_components) :
  nir_imov_alu(build, alu_src, num_components);
-- 
2.20.1

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

[Mesa-dev] [PATCH 3/4] panfrost/nondrm: Make COHERENT_LOCAL explicit

[Alyssa Rosenzweig]

This flag corresponds to what was MEM_COHERENT_LOCAL in the vendor
driver, which seems to influence the cache policy, necessary for the
varying temporary storage but nothing else.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c | 2 +-
 src/gallium/drivers/panfrost/pan_screen.h  | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 250eded932e..f2bb44d1342 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -2693,7 +2693,7 @@ panfrost_setup_hardware(struct panfrost_context *ctx)
 }
 
 screen->driver->allocate_slab(screen, >scratchpad, 64, false, 0, 
0, 0);
-screen->driver->allocate_slab(screen, >varying_mem, 16384, false, 
PAN_ALLOCATE_INVISIBLE, 0, 0);
+screen->driver->allocate_slab(screen, >varying_mem, 16384, false, 
PAN_ALLOCATE_INVISIBLE | PAN_ALLOCATE_COHERENT_LOCAL, 0, 0);
 screen->driver->allocate_slab(screen, >shaders, 4096, true, 
PAN_ALLOCATE_EXECUTE, 0, 0);
 screen->driver->allocate_slab(screen, >tiler_heap, 32768, false, 
PAN_ALLOCATE_INVISIBLE | PAN_ALLOCATE_GROWABLE, 1, 128);
 screen->driver->allocate_slab(screen, >misc_0, 128, false, 
PAN_ALLOCATE_INVISIBLE | PAN_ALLOCATE_GROWABLE, 1, 128);
diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
b/src/gallium/drivers/panfrost/pan_screen.h
index 3d7c1ad1562..1bf46dee6bb 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -47,6 +47,7 @@ struct panfrost_screen;
 #define PAN_ALLOCATE_EXECUTE (1 << 0)
 #define PAN_ALLOCATE_GROWABLE (1 << 1)
 #define PAN_ALLOCATE_INVISIBLE (1 << 2)
+#define PAN_ALLOCATE_COHERENT_LOCAL (1 << 3)
 
 struct panfrost_driver {
struct panfrost_bo * (*import_bo) (struct panfrost_screen *screen, 
struct winsys_handle *whandle);
-- 
2.20.1

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

[Mesa-dev] [PATCH 4/4] panfrost/nondrm: Split out dump_counters

[Alyssa Rosenzweig]

Previously, this function was implied a part of the job submit.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c | 2 ++
 src/gallium/drivers/panfrost/pan_screen.h  | 1 +
 2 files changed, 3 insertions(+)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index f2bb44d1342..3d610431f9e 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1537,6 +1537,8 @@ panfrost_submit_frame(struct panfrost_context *ctx, bool 
flush_immediate)
 screen->driver->force_flush_fragment(ctx);
 
 #ifdef DUMP_PERFORMANCE_COUNTERS
+screen->driver->dump_counters(screen);
+
 char filename[128];
 snprintf(filename, sizeof(filename), "/dev/shm/frame%d.mdgprf", 
++performance_counter_number);
 FILE *fp = fopen(filename, "wb");
diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
b/src/gallium/drivers/panfrost/pan_screen.h
index 1bf46dee6bb..ebca4d37dd1 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -66,6 +66,7 @@ struct panfrost_driver {
 void (*free_imported_bo) (struct panfrost_screen *screen,
  struct panfrost_bo *bo);
 void (*enable_counters) (struct panfrost_screen *screen);
+void (*dump_counters) (struct panfrost_screen *screen);
 };
 
 struct panfrost_screen {
-- 
2.20.1

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

[Mesa-dev] [PATCH 2/4] panfrost/nondrm: Flag CPU-invisible regions

[Alyssa Rosenzweig]

Potentially, the kernel could optimize these allocations, or perhaps we
can save on mapping costs.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c | 6 +++---
 src/gallium/drivers/panfrost/pan_screen.h  | 1 +
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 822b5a0dfef..250eded932e 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -2693,10 +2693,10 @@ panfrost_setup_hardware(struct panfrost_context *ctx)
 }
 
 screen->driver->allocate_slab(screen, >scratchpad, 64, false, 0, 
0, 0);
-screen->driver->allocate_slab(screen, >varying_mem, 16384, false, 
0, 0, 0);
+screen->driver->allocate_slab(screen, >varying_mem, 16384, false, 
PAN_ALLOCATE_INVISIBLE, 0, 0);
 screen->driver->allocate_slab(screen, >shaders, 4096, true, 
PAN_ALLOCATE_EXECUTE, 0, 0);
-screen->driver->allocate_slab(screen, >tiler_heap, 32768, false, 
PAN_ALLOCATE_GROWABLE, 1, 128);
-screen->driver->allocate_slab(screen, >misc_0, 128, false, 
PAN_ALLOCATE_GROWABLE, 1, 128);
+screen->driver->allocate_slab(screen, >tiler_heap, 32768, false, 
PAN_ALLOCATE_INVISIBLE | PAN_ALLOCATE_GROWABLE, 1, 128);
+screen->driver->allocate_slab(screen, >misc_0, 128, false, 
PAN_ALLOCATE_INVISIBLE | PAN_ALLOCATE_GROWABLE, 1, 128);
 
 }
 
diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
b/src/gallium/drivers/panfrost/pan_screen.h
index 4ff690de658..3d7c1ad1562 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -46,6 +46,7 @@ struct panfrost_screen;
 /* Flags for allocated memory */
 #define PAN_ALLOCATE_EXECUTE (1 << 0)
 #define PAN_ALLOCATE_GROWABLE (1 << 1)
+#define PAN_ALLOCATE_INVISIBLE (1 << 2)
 
 struct panfrost_driver {
struct panfrost_bo * (*import_bo) (struct panfrost_screen *screen, 
struct winsys_handle *whandle);
-- 
2.20.1

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

[Mesa-dev] [PATCH 0/4] panfrost: Improve non-DRM integration

[Alyssa Rosenzweig]

This contains a potpourrie of patches to improve the non-DRM glue layer.
Ideally, we'll be able to remove this glue entirely in the near future,
but for now, this at least removes some of the magic and should fix
cross-compilation with the glue.

Alyssa Rosenzweig (4):
  panfrost/meson: Remove subdir for nondrm
  panfrost/nondrm: Flag CPU-invisible regions
  panfrost/nondrm: Make COHERENT_LOCAL explicit
  panfrost/nondrm: Split out dump_counters

 src/gallium/drivers/panfrost/meson.build   | 1 -
 src/gallium/drivers/panfrost/pan_context.c | 8 +---
 src/gallium/drivers/panfrost/pan_screen.h  | 3 +++
 3 files changed, 8 insertions(+), 4 deletions(-)

-- 
2.20.1

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

[Mesa-dev] [PATCH 1/4] panfrost/meson: Remove subdir for nondrm

[Alyssa Rosenzweig]

This change fixes cross builds with the (temporary) non-DRM overlay.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/meson.build | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/gallium/drivers/panfrost/meson.build 
b/src/gallium/drivers/panfrost/meson.build
index 73fcca3e648..a03b95b08ca 100644
--- a/src/gallium/drivers/panfrost/meson.build
+++ b/src/gallium/drivers/panfrost/meson.build
@@ -65,7 +65,6 @@ has_nondrm_overlay = nondrm_overlay_check.returncode() == 0
 if has_nondrm_overlay
-  subdir('nondrm/include')
   files_panfrost += files('nondrm/pan_nondrm.c')
   inc_panfrost += include_directories('nondrm/include')
   compile_args_panfrost += '-DPAN_NONDRM_OVERLAY'
 endif
 
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH v3] nir: allow nir_lower_phis_to_scalar() on more src types

[Jason Ekstrand]

On Fri, Feb 22, 2019 at 5:21 PM Timothy Arceri 
wrote:

> Rather than only lowering if all srcs are scalarizable we instead
> check that at least one src is scalarizable.
>
> We remove undef type from the is_phi_src_scalarizable() as using
> this as a check just cause regressions when it is the only
> scalarizable src.
>
> total instructions in shared programs: 13219105 -> 13024547 (-1.47%)
> instructions in affected programs: 1153797 -> 959239 (-16.86%)
> helped: 581
> HURT: 74
>
> total cycles in shared programs: 333968972 -> 324807922 (-2.74%)
> cycles in affected programs: 129809402 -> 120648352 (-7.06%)
> helped: 571
> HURT: 131
>
> total spills in shared programs: 57947 -> 29130 (-49.73%)
> spills in affected programs: 53364 -> 24547 (-54.00%)
> helped: 351
> HURT: 0
>
> total fills in shared programs: 51310 -> 25468 (-50.36%)
> fills in affected programs: 44882 -> 19040 (-57.58%)
> helped: 351
> HURT: 0
> ---
>  src/compiler/nir/nir_lower_phis_to_scalar.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/src/compiler/nir/nir_lower_phis_to_scalar.c
> b/src/compiler/nir/nir_lower_phis_to_scalar.c
> index 16001f73685..b2ca89d3513 100644
> --- a/src/compiler/nir/nir_lower_phis_to_scalar.c
> +++ b/src/compiler/nir/nir_lower_phis_to_scalar.c
> @@ -75,7 +75,6 @@ is_phi_src_scalarizable(nir_phi_src *src,
>return should_lower_phi(nir_instr_as_phi(src_instr), state);
>
> case nir_instr_type_load_const:
> -   case nir_instr_type_ssa_undef:
>

Instead of removing it, would you mind handling it as

case nir_instr_type_ssa_undef:
/* The caller of this function is going to OR the results and we don't
want undefs to count so we return false. */
   return false;

With that,

Reviewed-by: Jason Ekstrand 


>/* These are trivially scalarizable */
>return true;
>
> @@ -150,11 +149,16 @@ should_lower_phi(nir_phi_instr *phi, struct
> lower_phis_to_scalar_state *state)
>  */
> entry = _mesa_hash_table_insert(state->phi_table, phi, (void
> *)(intptr_t)1);
>
> -   bool scalarizable = true;
> +   bool scalarizable = false;
>
> nir_foreach_phi_src(src, phi) {
> +  /* This loop ignores srcs that are not scalarizable because its
> likely
> +   * still worth copying to temps if another phi source is
> scalarizable.
> +   * This reduces register spilling by a huge amount in the i965
> driver for
> +   * Deus Ex: MD.
> +   */
>scalarizable = is_phi_src_scalarizable(src, state);
> -  if (!scalarizable)
> +  if (scalarizable)
>   break;
> }
>
> --
> 2.20.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109741] swr doesn't build on i386 - simdlib.hpp:594:37: error: static assertion failed: This path only meant for 64-bit code

[bugzilla-daemon]

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

Alok Hota  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Alok Hota  ---
This is unlikely to be fixed in the future. Our intended use case is
large-scale scientific visualization, which is rarely, if ever, run on 32-bit
machines today. At the moment we are targeting 64-bit platforms.

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

[Mesa-dev] [Bug 109741] swr doesn't build on i386 - simdlib.hpp:594:37: error: static assertion failed: This path only meant for 64-bit code

[bugzilla-daemon]

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

Alok Hota  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |alok.h...@intel.com
   |org |

-- 
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 v3] nir: allow nir_lower_phis_to_scalar() on more src types

[Timothy Arceri]

Rather than only lowering if all srcs are scalarizable we instead
check that at least one src is scalarizable.

We remove undef type from the is_phi_src_scalarizable() as using
this as a check just cause regressions when it is the only
scalarizable src.

total instructions in shared programs: 13219105 -> 13024547 (-1.47%)
instructions in affected programs: 1153797 -> 959239 (-16.86%)
helped: 581
HURT: 74

total cycles in shared programs: 333968972 -> 324807922 (-2.74%)
cycles in affected programs: 129809402 -> 120648352 (-7.06%)
helped: 571
HURT: 131

total spills in shared programs: 57947 -> 29130 (-49.73%)
spills in affected programs: 53364 -> 24547 (-54.00%)
helped: 351
HURT: 0

total fills in shared programs: 51310 -> 25468 (-50.36%)
fills in affected programs: 44882 -> 19040 (-57.58%)
helped: 351
HURT: 0
---
 src/compiler/nir/nir_lower_phis_to_scalar.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/compiler/nir/nir_lower_phis_to_scalar.c 
b/src/compiler/nir/nir_lower_phis_to_scalar.c
index 16001f73685..b2ca89d3513 100644
--- a/src/compiler/nir/nir_lower_phis_to_scalar.c
+++ b/src/compiler/nir/nir_lower_phis_to_scalar.c
@@ -75,7 +75,6 @@ is_phi_src_scalarizable(nir_phi_src *src,
   return should_lower_phi(nir_instr_as_phi(src_instr), state);
 
case nir_instr_type_load_const:
-   case nir_instr_type_ssa_undef:
   /* These are trivially scalarizable */
   return true;
 
@@ -150,11 +149,16 @@ should_lower_phi(nir_phi_instr *phi, struct 
lower_phis_to_scalar_state *state)
 */
entry = _mesa_hash_table_insert(state->phi_table, phi, (void *)(intptr_t)1);
 
-   bool scalarizable = true;
+   bool scalarizable = false;
 
nir_foreach_phi_src(src, phi) {
+  /* This loop ignores srcs that are not scalarizable because its likely
+   * still worth copying to temps if another phi source is scalarizable.
+   * This reduces register spilling by a huge amount in the i965 driver for
+   * Deus Ex: MD.
+   */
   scalarizable = is_phi_src_scalarizable(src, state);
-  if (!scalarizable)
+  if (scalarizable)
  break;
}
 
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] nir: add nir_instr_type_tex support to nir_lower_phis_to_scalar()

[Rob Clark]

On Fri, Feb 22, 2019 at 3:47 PM Timothy Arceri  wrote:
>
>
>
> On 23/2/19 6:31 am, Rob Clark wrote:
> > On Fri, Feb 22, 2019 at 12:39 PM Jason Ekstrand  
> > wrote:
> >>
> >> On Fri, Feb 22, 2019 at 9:51 AM Eric Anholt  wrote:
> >>>
> >>> Timothy Arceri  writes:
> >>>
>  shader-db results i965 (SKL):
> 
>  total instructions in shared programs: 13219105 -> 13024761 (-1.47%)
>  instructions in affected programs: 1169457 -> 975113 (-16.62%)
>  helped: 599
>  HURT: 154
> 
>  total cycles in shared programs: 333968972 -> 324822073 (-2.74%)
>  cycles in affected programs: 130032440 -> 120885541 (-7.03%)
>  helped: 590
>  HURT: 216
> 
>  total spills in shared programs: 57947 -> 29130 (-49.73%)
>  spills in affected programs: 53364 -> 24547 (-54.00%)
>  helped: 351
>  HURT: 0
> 
>  total fills in shared programs: 51310 -> 25468 (-50.36%)
>  fills in affected programs: 44882 -> 19040 (-57.58%)
>  helped: 351
>  HURT: 0
>  ---
>    src/compiler/nir/nir_lower_phis_to_scalar.c | 1 +
>    1 file changed, 1 insertion(+)
> 
>  diff --git a/src/compiler/nir/nir_lower_phis_to_scalar.c 
>  b/src/compiler/nir/nir_lower_phis_to_scalar.c
>  index 16001f73685..f6f702bca15 100644
>  --- a/src/compiler/nir/nir_lower_phis_to_scalar.c
>  +++ b/src/compiler/nir/nir_lower_phis_to_scalar.c
>  @@ -74,6 +74,7 @@ is_phi_src_scalarizable(nir_phi_src *src,
>  /* A phi is scalarizable if we're going to lower it */
>  return should_lower_phi(nir_instr_as_phi(src_instr), state);
> 
>  +   case nir_instr_type_tex:
>   case nir_instr_type_load_const:
>   case nir_instr_type_ssa_undef:
>  /* These are trivially scalarizable */
> >>>
> >>> Sounds promising, but I would definitely not describe instr_type_tex as
> >>> "trivially scalarizable" -- could you explain what's going on with this
> >>> patch?
>
> Basically it just turns:
>
> if ssa0 {
>...
>vec4 ssa1 = txf .
> } else {
> ...
> vec4 ssa2 = ...
> }
> vec4 ss3 = phi ssa1, ssa2
>
> Into
>
> if ssa0 {
>...
>vec4 ssa1 = txf .
>vec1 ssa2 = imov ssa1.x
>vec1 ssa3 = imov ssa1.y
>vec1 ssa4 = imov ssa1.z
>vec1 ssa5 = imov ssa1.w
> } else {
> ...
> vec4 ssa6 = ...
> vec1 ssa7 = imov ssa6.x
> vec1 ssa8 = imov ssa6.y
> vec1 ssa9 = imov ssa6.z
> vec1 ssa10 = imov ssa6.w
> }
> vec1 ss11 = phi ssa2, ssa7
> vec1 ss12 = phi ssa3, ssa8
> vec1 ss13 = phi ssa4, ssa9
> vec1 ss14 = phi ssa5, ssa10

ok, I didn't realize this is how the tex would get scalarized, I was
more concerned that it would get turned into something like:

  vec1 ssa1 = txf.x ...
  vec1 ssa2 = txf.y ...
  vec1 ssa3 = txf.z ...
  vec1 ssa4 = txf.w ...

(which might look good in shaderdb but really would be sub-optimal)

BR,
-R

>
>
> This allows a whole bunch more optimisation to take place as often not
> all of the phi channels are actually used. If some cases large chunks of
> logic can be remove from the if branch that doesn't contain the texture
> access.
>
> >>
> >>
> >> I think I can for Intel though I'm not sure how this affects other drivers.
> >>
> >> On Intel hardware, we almost always have to combine all the texture 
> >> sources into one big message.  Since having more than one source is very 
> >> common, this means that we have to make a temporary copy of the sources 
> >> anyway.  Because we're copying them, having them contiguous (a vector in 
> >> NIR terms) doesn't actually gain us anything.  We may as well let NIR 
> >> scalarize them and give more freedom to the register allocator and other 
> >> NIR passes which may need to clean things up.  We don't want to make the 
> >> same choice for destinations as they are required to be contiguous.
> >>
> >
> > hmm, but this is abut the phi src (ie. the tex dest), not the tex src, 
> > isn't it?
>
> Yeah, thats correct. Which is why I think its fine to be bunched with
> the "These are trivially scalarizable" types?
>
> >
> > BR,
> > -R
> >
> >> Feel free to copy+paste that somewhere.  I agree with Eric that they are 
> >> not "trivially scalarizable" but they are safe to scalarize.
> >>
> >> --Jason
> >> ___
> >> 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: add nir_instr_type_tex support to nir_lower_phis_to_scalar()

[Jason Ekstrand]

On Fri, Feb 22, 2019 at 4:05 PM Timothy Arceri 
wrote:

>
>
> On 23/2/19 8:54 am, Jason Ekstrand wrote:
> > On Fri, Feb 22, 2019 at 2:47 PM Timothy Arceri  > > wrote:
> >
> >
> >
> > On 23/2/19 6:31 am, Rob Clark wrote:
> >  > On Fri, Feb 22, 2019 at 12:39 PM Jason Ekstrand
> > mailto:ja...@jlekstrand.net>> wrote:
> >  >>
> >  >> On Fri, Feb 22, 2019 at 9:51 AM Eric Anholt  > > wrote:
> >  >>>
> >  >>> Timothy Arceri  > > writes:
> >  >>>
> >   shader-db results i965 (SKL):
> >  
> >   total instructions in shared programs: 13219105 -> 13024761
> > (-1.47%)
> >   instructions in affected programs: 1169457 -> 975113 (-16.62%)
> >   helped: 599
> >   HURT: 154
> >  
> >   total cycles in shared programs: 333968972 -> 324822073
> (-2.74%)
> >   cycles in affected programs: 130032440 -> 120885541 (-7.03%)
> >   helped: 590
> >   HURT: 216
> >  
> >   total spills in shared programs: 57947 -> 29130 (-49.73%)
> >   spills in affected programs: 53364 -> 24547 (-54.00%)
> >   helped: 351
> >   HURT: 0
> >  
> >   total fills in shared programs: 51310 -> 25468 (-50.36%)
> >   fills in affected programs: 44882 -> 19040 (-57.58%)
> >   helped: 351
> >   HURT: 0
> >   ---
> >     src/compiler/nir/nir_lower_phis_to_scalar.c | 1 +
> >     1 file changed, 1 insertion(+)
> >  
> >   diff --git a/src/compiler/nir/nir_lower_phis_to_scalar.c
> > b/src/compiler/nir/nir_lower_phis_to_scalar.c
> >   index 16001f73685..f6f702bca15 100644
> >   --- a/src/compiler/nir/nir_lower_phis_to_scalar.c
> >   +++ b/src/compiler/nir/nir_lower_phis_to_scalar.c
> >   @@ -74,6 +74,7 @@ is_phi_src_scalarizable(nir_phi_src *src,
> >   /* A phi is scalarizable if we're going to lower it */
> >   return should_lower_phi(nir_instr_as_phi(src_instr),
> > state);
> >  
> >   +   case nir_instr_type_tex:
> >    case nir_instr_type_load_const:
> >    case nir_instr_type_ssa_undef:
> >   /* These are trivially scalarizable */
> >  >>>
> >  >>> Sounds promising, but I would definitely not describe
> > instr_type_tex as
> >  >>> "trivially scalarizable" -- could you explain what's going on
> > with this
> >  >>> patch?
> >
> > Basically it just turns:
> >
> > if ssa0 {
> > ...
> > vec4 ssa1 = txf .
> > } else {
> >  ...
> >  vec4 ssa2 = ...
> > }
> > vec4 ss3 = phi ssa1, ssa2
> >
> > Into
> >
> > if ssa0 {
> > ...
> > vec4 ssa1 = txf .
> > vec1 ssa2 = imov ssa1.x
> > vec1 ssa3 = imov ssa1.y
> > vec1 ssa4 = imov ssa1.z
> > vec1 ssa5 = imov ssa1.w
> > } else {
> >  ...
> >  vec4 ssa6 = ...
> >  vec1 ssa7 = imov ssa6.x
> >  vec1 ssa8 = imov ssa6.y
> >  vec1 ssa9 = imov ssa6.z
> >  vec1 ssa10 = imov ssa6.w
> > }
> > vec1 ss11 = phi ssa2, ssa7
> > vec1 ss12 = phi ssa3, ssa8
> > vec1 ss13 = phi ssa4, ssa9
> > vec1 ss14 = phi ssa5, ssa10
> >
> >
> > This allows a whole bunch more optimisation to take place as often
> not
> > all of the phi channels are actually used. If some cases large
> > chunks of
> > logic can be remove from the if branch that doesn't contain the
> texture
> > access.
> >
> >  >>
> >  >>
> >  >> I think I can for Intel though I'm not sure how this affects
> > other drivers.
> >  >>
> >  >> On Intel hardware, we almost always have to combine all the
> > texture sources into one big message.  Since having more than one
> > source is very common, this means that we have to make a temporary
> > copy of the sources anyway.  Because we're copying them, having them
> > contiguous (a vector in NIR terms) doesn't actually gain us
> > anything.  We may as well let NIR scalarize them and give more
> > freedom to the register allocator and other NIR passes which may
> > need to clean things up.  We don't want to make the same choice for
> > destinations as they are required to be contiguous.
> >  >>
> >  >
> >  > hmm, but this is abut the phi src (ie. the tex dest), not the tex
> > src, isn't it?
> >
> >
> > Well, that's a pickle...  When I wrote this pass I did so to try and
> > explicitly keep from breaking up things that are known to be vectors in
> > the back-end such as textures.  The idea was to try and not break up
> > things like this:
> >
> >   if (...) {
> >  ssa_1 = tex()
> > } else {
> >  ssa_2 = tex()
> > }
> > ssa_3 = phi (ssa_1, ssa_2)
> >
> > in the hopes that it would turn 

Re: [Mesa-dev] [PATCH] nir: add nir_instr_type_tex support to nir_lower_phis_to_scalar()

[Timothy Arceri]

On 23/2/19 8:54 am, Jason Ekstrand wrote:
On Fri, Feb 22, 2019 at 2:47 PM Timothy Arceri > wrote:




On 23/2/19 6:31 am, Rob Clark wrote:
 > On Fri, Feb 22, 2019 at 12:39 PM Jason Ekstrand
mailto:ja...@jlekstrand.net>> wrote:
 >>
 >> On Fri, Feb 22, 2019 at 9:51 AM Eric Anholt mailto:e...@anholt.net>> wrote:
 >>>
 >>> Timothy Arceri mailto:tarc...@itsqueeze.com>> writes:
 >>>
  shader-db results i965 (SKL):
 
  total instructions in shared programs: 13219105 -> 13024761
(-1.47%)
  instructions in affected programs: 1169457 -> 975113 (-16.62%)
  helped: 599
  HURT: 154
 
  total cycles in shared programs: 333968972 -> 324822073 (-2.74%)
  cycles in affected programs: 130032440 -> 120885541 (-7.03%)
  helped: 590
  HURT: 216
 
  total spills in shared programs: 57947 -> 29130 (-49.73%)
  spills in affected programs: 53364 -> 24547 (-54.00%)
  helped: 351
  HURT: 0
 
  total fills in shared programs: 51310 -> 25468 (-50.36%)
  fills in affected programs: 44882 -> 19040 (-57.58%)
  helped: 351
  HURT: 0
  ---
    src/compiler/nir/nir_lower_phis_to_scalar.c | 1 +
    1 file changed, 1 insertion(+)
 
  diff --git a/src/compiler/nir/nir_lower_phis_to_scalar.c
b/src/compiler/nir/nir_lower_phis_to_scalar.c
  index 16001f73685..f6f702bca15 100644
  --- a/src/compiler/nir/nir_lower_phis_to_scalar.c
  +++ b/src/compiler/nir/nir_lower_phis_to_scalar.c
  @@ -74,6 +74,7 @@ is_phi_src_scalarizable(nir_phi_src *src,
          /* A phi is scalarizable if we're going to lower it */
          return should_lower_phi(nir_instr_as_phi(src_instr),
state);
 
  +   case nir_instr_type_tex:
       case nir_instr_type_load_const:
       case nir_instr_type_ssa_undef:
          /* These are trivially scalarizable */
 >>>
 >>> Sounds promising, but I would definitely not describe
instr_type_tex as
 >>> "trivially scalarizable" -- could you explain what's going on
with this
 >>> patch?

Basically it just turns:

if ssa0 {
    ...
    vec4 ssa1 = txf .
} else {
     ...
     vec4 ssa2 = ...
}
vec4 ss3 = phi ssa1, ssa2

Into

if ssa0 {
    ...
    vec4 ssa1 = txf .
    vec1 ssa2 = imov ssa1.x
    vec1 ssa3 = imov ssa1.y
    vec1 ssa4 = imov ssa1.z
    vec1 ssa5 = imov ssa1.w
} else {
     ...
     vec4 ssa6 = ...
     vec1 ssa7 = imov ssa6.x
     vec1 ssa8 = imov ssa6.y
     vec1 ssa9 = imov ssa6.z
     vec1 ssa10 = imov ssa6.w
}
vec1 ss11 = phi ssa2, ssa7
vec1 ss12 = phi ssa3, ssa8
vec1 ss13 = phi ssa4, ssa9
vec1 ss14 = phi ssa5, ssa10


This allows a whole bunch more optimisation to take place as often not
all of the phi channels are actually used. If some cases large
chunks of
logic can be remove from the if branch that doesn't contain the texture
access.

 >>
 >>
 >> I think I can for Intel though I'm not sure how this affects
other drivers.
 >>
 >> On Intel hardware, we almost always have to combine all the
texture sources into one big message.  Since having more than one
source is very common, this means that we have to make a temporary
copy of the sources anyway.  Because we're copying them, having them
contiguous (a vector in NIR terms) doesn't actually gain us
anything.  We may as well let NIR scalarize them and give more
freedom to the register allocator and other NIR passes which may
need to clean things up.  We don't want to make the same choice for
destinations as they are required to be contiguous.
 >>
 >
 > hmm, but this is abut the phi src (ie. the tex dest), not the tex
src, isn't it?


Well, that's a pickle...  When I wrote this pass I did so to try and 
explicitly keep from breaking up things that are known to be vectors in 
the back-end such as textures.  The idea was to try and not break up 
things like this:


  if (...) {
     ssa_1 = tex()
} else {
     ssa_2 = tex()
}
ssa_3 = phi (ssa_1, ssa_2)

in the hopes that it would turn into

if (...) {
     r1 = tex();
} else {
     r1 = tex();
}

Clearly, that notion was mis-placed.  At this point, I really wonder 
what the complexity is saving us.  Maybe it's not worth it at all?  
Maybe we need to be more agressive and require all sources to not be 
vectorizable or something?


Maybe checking if all components of the phi are used before converting 
to scalar would be useful? Not sure but I've sent a more conservative v2 
of this patch where a bunch of hurt is gone.


The remaining hurt is very small and comes from shaders like this:

 if (...) {
  r1 = tex();
 } 

[Mesa-dev] [PATCH v2] nir: add nir_instr_type_tex support to nir_lower_phis_to_scalar()

[Timothy Arceri]

total instructions in shared programs: 13219105 -> 13024613 (-1.47%)
instructions in affected programs: 1155045 -> 960553 (-16.84%)
helped: 581
HURT: 100

total cycles in shared programs: 333968972 -> 324813762 (-2.74%)
cycles in affected programs: 129831032 -> 120675822 (-7.05%)
helped: 571
HURT: 159

total spills in shared programs: 57947 -> 29130 (-49.73%)
spills in affected programs: 53364 -> 24547 (-54.00%)
helped: 351
HURT: 0

total fills in shared programs: 51310 -> 25468 (-50.36%)
fills in affected programs: 44882 -> 19040 (-57.58%)
helped: 351
HURT: 0
---
 src/compiler/nir/nir_lower_phis_to_scalar.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_lower_phis_to_scalar.c 
b/src/compiler/nir/nir_lower_phis_to_scalar.c
index 16001f73685..677ce505419 100644
--- a/src/compiler/nir/nir_lower_phis_to_scalar.c
+++ b/src/compiler/nir/nir_lower_phis_to_scalar.c
@@ -46,6 +46,16 @@ struct lower_phis_to_scalar_state {
 static bool
 should_lower_phi(nir_phi_instr *phi, struct lower_phis_to_scalar_state *state);
 
+static bool
+is_phi_src_a_texture(nir_phi_src *src)
+{
+   /* Don't know what to do with non-ssa sources */
+   assert(src->src.is_ssa);
+
+   nir_instr *src_instr = src->src.ssa->parent_instr;
+   return src_instr->type == nir_instr_type_tex;
+}
+
 static bool
 is_phi_src_scalarizable(nir_phi_src *src,
 struct lower_phis_to_scalar_state *state)
@@ -150,9 +160,16 @@ should_lower_phi(nir_phi_instr *phi, struct 
lower_phis_to_scalar_state *state)
 */
entry = _mesa_hash_table_insert(state->phi_table, phi, (void *)(intptr_t)1);
 
-   bool scalarizable = true;
+   bool scalarizable = false;
 
nir_foreach_phi_src(src, phi) {
+  /* A texture is not scalarizable but its likely still worth copying to
+   * temps if another phi source is scalarizable. This reduces register
+   * spilling by a huge amount in the i965 driver for Deus Ex: MD.
+   */
+  if (is_phi_src_a_texture(src))
+ continue;
+
   scalarizable = is_phi_src_scalarizable(src, state);
   if (!scalarizable)
  break;
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] nir: add nir_instr_type_tex support to nir_lower_phis_to_scalar()

[Jason Ekstrand]

On Fri, Feb 22, 2019 at 2:47 PM Timothy Arceri 
wrote:

>
>
> On 23/2/19 6:31 am, Rob Clark wrote:
> > On Fri, Feb 22, 2019 at 12:39 PM Jason Ekstrand 
> wrote:
> >>
> >> On Fri, Feb 22, 2019 at 9:51 AM Eric Anholt  wrote:
> >>>
> >>> Timothy Arceri  writes:
> >>>
>  shader-db results i965 (SKL):
> 
>  total instructions in shared programs: 13219105 -> 13024761 (-1.47%)
>  instructions in affected programs: 1169457 -> 975113 (-16.62%)
>  helped: 599
>  HURT: 154
> 
>  total cycles in shared programs: 333968972 -> 324822073 (-2.74%)
>  cycles in affected programs: 130032440 -> 120885541 (-7.03%)
>  helped: 590
>  HURT: 216
> 
>  total spills in shared programs: 57947 -> 29130 (-49.73%)
>  spills in affected programs: 53364 -> 24547 (-54.00%)
>  helped: 351
>  HURT: 0
> 
>  total fills in shared programs: 51310 -> 25468 (-50.36%)
>  fills in affected programs: 44882 -> 19040 (-57.58%)
>  helped: 351
>  HURT: 0
>  ---
>    src/compiler/nir/nir_lower_phis_to_scalar.c | 1 +
>    1 file changed, 1 insertion(+)
> 
>  diff --git a/src/compiler/nir/nir_lower_phis_to_scalar.c
> b/src/compiler/nir/nir_lower_phis_to_scalar.c
>  index 16001f73685..f6f702bca15 100644
>  --- a/src/compiler/nir/nir_lower_phis_to_scalar.c
>  +++ b/src/compiler/nir/nir_lower_phis_to_scalar.c
>  @@ -74,6 +74,7 @@ is_phi_src_scalarizable(nir_phi_src *src,
>  /* A phi is scalarizable if we're going to lower it */
>  return should_lower_phi(nir_instr_as_phi(src_instr), state);
> 
>  +   case nir_instr_type_tex:
>   case nir_instr_type_load_const:
>   case nir_instr_type_ssa_undef:
>  /* These are trivially scalarizable */
> >>>
> >>> Sounds promising, but I would definitely not describe instr_type_tex as
> >>> "trivially scalarizable" -- could you explain what's going on with this
> >>> patch?
>
> Basically it just turns:
>
> if ssa0 {
>...
>vec4 ssa1 = txf .
> } else {
> ...
> vec4 ssa2 = ...
> }
> vec4 ss3 = phi ssa1, ssa2
>
> Into
>
> if ssa0 {
>...
>vec4 ssa1 = txf .
>vec1 ssa2 = imov ssa1.x
>vec1 ssa3 = imov ssa1.y
>vec1 ssa4 = imov ssa1.z
>vec1 ssa5 = imov ssa1.w
> } else {
> ...
> vec4 ssa6 = ...
> vec1 ssa7 = imov ssa6.x
> vec1 ssa8 = imov ssa6.y
> vec1 ssa9 = imov ssa6.z
> vec1 ssa10 = imov ssa6.w
> }
> vec1 ss11 = phi ssa2, ssa7
> vec1 ss12 = phi ssa3, ssa8
> vec1 ss13 = phi ssa4, ssa9
> vec1 ss14 = phi ssa5, ssa10
>
>
> This allows a whole bunch more optimisation to take place as often not
> all of the phi channels are actually used. If some cases large chunks of
> logic can be remove from the if branch that doesn't contain the texture
> access.
>
> >>
> >>
> >> I think I can for Intel though I'm not sure how this affects other
> drivers.
> >>
> >> On Intel hardware, we almost always have to combine all the texture
> sources into one big message.  Since having more than one source is very
> common, this means that we have to make a temporary copy of the sources
> anyway.  Because we're copying them, having them contiguous (a vector in
> NIR terms) doesn't actually gain us anything.  We may as well let NIR
> scalarize them and give more freedom to the register allocator and other
> NIR passes which may need to clean things up.  We don't want to make the
> same choice for destinations as they are required to be contiguous.
> >>
> >
> > hmm, but this is abut the phi src (ie. the tex dest), not the tex src,
> isn't it?
>

Well, that's a pickle...  When I wrote this pass I did so to try and
explicitly keep from breaking up things that are known to be vectors in the
back-end such as textures.  The idea was to try and not break up things
like this:

 if (...) {
ssa_1 = tex()
} else {
ssa_2 = tex()
}
ssa_3 = phi (ssa_1, ssa_2)

in the hopes that it would turn into

if (...) {
r1 = tex();
} else {
r1 = tex();
}

Clearly, that notion was mis-placed.  At this point, I really wonder what
the complexity is saving us.  Maybe it's not worth it at all?  Maybe we
need to be more agressive and require all sources to not be vectorizable or
something?


> Yeah, thats correct. Which is why I think its fine to be bunched with
> the "These are trivially scalarizable" types?
>
> >
> > BR,
> > -R
> >
> >> Feel free to copy+paste that somewhere.  I agree with Eric that they
> are not "trivially scalarizable" but they are safe to scalarize.
> >>
> >> --Jason
> >> ___
> >> 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 v5] etnaviv: fix resource usage tracking across different pipe_context's

[Marek Vasut]

On 2/22/19 10:30 AM, Boris Brezillon wrote:
> On Thu, 21 Feb 2019 23:29:53 +0100
> Boris Brezillon  wrote:
> 
>> Christian, Marek,
>>
>> On Wed, 30 Jan 2019 05:28:14 +0100
>> Marek Vasut  wrote:
>>
>>> From: Christian Gmeiner 
>>>
>>> A pipe_resource can be shared by all the pipe_context's hanging off the
>>> same pipe_screen.  
>>
>> We seem to be impacted by the problem you're fixing here, but, while
>> this patch definitely make things much better, the problem does not
>> seem to be entirely fixed (at least in our case).
>>
>> A bit more context: we have Qt App using QtWebEngine to render html
>> content. When we call QtWebEngine::initialize(), which as for effect
>> to allow shared GL contexts, we sometimes notice that part of the web
>> page is mis-rendered. That does not happen when we omit the
>> QtWebEngine::initialize() call.
>> As said above, this patch make those rendering issues less likely to
>> happen, but we still have the problem from time to time. So I thought
>> I'd share my guesses about what could cause these issues before
>> debugging it further.
>>
>> First thing I noticed: I couldn't reproduce the problem with [1]
>> applied (+ a tiny change forcing CPU-based tiling no matter the size of
>> the region to tile/untile). So, my guess is that it's related to how we
>> handle GPU-based tiling/untiling.
>> Also noticed that we're testing the rsc->status here [2] without the
>> screen->lock held, and there might be a race with another thread calling
>> resource_used(). We might also lack a resource_read(ctx, >base)
>> here [3]. But even after fixing those problems, the rendering issues
>> are not gone.
> 
> I tested again with the following diff applied on top of your patch, and
> the remaining rendering issues we had seem to be gone (don't know what I
> messed up in my previous tests :-/).
> 
> --->8---
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index fc4f65dbeee1..b8c8b96a6f72 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -729,6 +729,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
>  
> etna_submit_rs_state(ctx, _to_screen);
> resource_written(ctx, >base);
> +   resource_read(ctx, >base);
> dst->seqno++;
> dst->levels[blit_info->dst.level].ts_valid = false;
> ctx->dirty |= ETNA_DIRTY_DERIVE_TS;
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index a3013e624ead..e4b2ac605e63 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -356,6 +356,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>  * transfers without a temporary resource.
>  */
> if (trans->rsc || !(usage & PIPE_TRANSFER_UNSYNCHRONIZED)) {
> +  struct etna_screen *screen = ctx->screen;
>uint32_t prep_flags = 0;
>  
>/*
> @@ -364,11 +365,13 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
> * current GPU usage (reads must wait for GPU writes, writes must have
> * exclusive access to the buffer).
> */
> +  mtx_lock(>lock);
>if ((trans->rsc && (etna_resource(trans->rsc)->status & 
> ETNA_PENDING_WRITE)) ||
>(!trans->rsc &&
> (((usage & PIPE_TRANSFER_READ) && (rsc->status & 
> ETNA_PENDING_WRITE)) ||
> ((usage & PIPE_TRANSFER_WRITE) && rsc->status
>   pctx->flush(pctx, NULL, 0);
> +  mtx_unlock(>lock);
>  
>if (usage & PIPE_TRANSFER_READ)
>   prep_flags |= DRM_ETNA_PREP_READ;
> 

On iMX6Q

Tested-by: Marek Vasut 

with multiple custom applications. I don't see any breakage.

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

[Mesa-dev] [PATCH v4] i965: fixed clamping in set_scissor_bits when the y is flipped

[Eleni Maria Stea]

Calculating the scissor rectangle fields with the y flipped (0 on top)
can generate negative values that will cause assertion failure later on
as the scissor fields are all unsigned. We must clamp the bbox values
again to make sure they don't exceed the fb_height. Also fixed a
calculation error.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108999
  https://bugs.freedesktop.org/show_bug.cgi?id=109594

v2:
   - I initially clamped the values inside the if (Y is flipped) case
   and I made a mistake in the calculation: the clamp of the bbox[2] should
   be a check if (bbox[2] >= fbheight) bbox[2] = fbheight - 1 instead and I
   shouldn't have changed the ScissorRectangleYMax calculation. As the
   fixed code is equivalent with using CLAMP instead of MAX2 at the top of
   the function when bbox[2] and bbox[3] are calculated, and the 2nd is more
   clear, I replaced it. (Nanley Chery)

v3:
   - Reversed the CLAMP change in bbox[3] as the API guarantees that the
   viewport height is positive. (Nanley Chery)

v4:
  - Added nomination for the mesa-stable branch and the link to the second
  bugzilla bug (Nanley Chery)

CC: 
Tested-by: Paul Chelombitko 
Reviewed-by: Nanley Chery 
---
 src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index 027dad1e089..73c983ce742 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -2446,7 +2446,7 @@ set_scissor_bits(const struct gl_context *ctx, int i,
 
bbox[0] = MAX2(ctx->ViewportArray[i].X, 0);
bbox[1] = MIN2(bbox[0] + ctx->ViewportArray[i].Width, fb_width);
-   bbox[2] = MAX2(ctx->ViewportArray[i].Y, 0);
+   bbox[2] = CLAMP(ctx->ViewportArray[i].Y, 0, fb_height);
bbox[3] = MIN2(bbox[2] + ctx->ViewportArray[i].Height, fb_height);
_mesa_intersect_scissor_bounding_box(ctx, i, bbox);
 
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] nir: add nir_instr_type_tex support to nir_lower_phis_to_scalar()

[Timothy Arceri]

On 23/2/19 6:31 am, Rob Clark wrote:

On Fri, Feb 22, 2019 at 12:39 PM Jason Ekstrand  wrote:


On Fri, Feb 22, 2019 at 9:51 AM Eric Anholt  wrote:


Timothy Arceri  writes:


shader-db results i965 (SKL):

total instructions in shared programs: 13219105 -> 13024761 (-1.47%)
instructions in affected programs: 1169457 -> 975113 (-16.62%)
helped: 599
HURT: 154

total cycles in shared programs: 333968972 -> 324822073 (-2.74%)
cycles in affected programs: 130032440 -> 120885541 (-7.03%)
helped: 590
HURT: 216

total spills in shared programs: 57947 -> 29130 (-49.73%)
spills in affected programs: 53364 -> 24547 (-54.00%)
helped: 351
HURT: 0

total fills in shared programs: 51310 -> 25468 (-50.36%)
fills in affected programs: 44882 -> 19040 (-57.58%)
helped: 351
HURT: 0
---
  src/compiler/nir/nir_lower_phis_to_scalar.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/compiler/nir/nir_lower_phis_to_scalar.c 
b/src/compiler/nir/nir_lower_phis_to_scalar.c
index 16001f73685..f6f702bca15 100644
--- a/src/compiler/nir/nir_lower_phis_to_scalar.c
+++ b/src/compiler/nir/nir_lower_phis_to_scalar.c
@@ -74,6 +74,7 @@ is_phi_src_scalarizable(nir_phi_src *src,
/* A phi is scalarizable if we're going to lower it */
return should_lower_phi(nir_instr_as_phi(src_instr), state);

+   case nir_instr_type_tex:
 case nir_instr_type_load_const:
 case nir_instr_type_ssa_undef:
/* These are trivially scalarizable */


Sounds promising, but I would definitely not describe instr_type_tex as
"trivially scalarizable" -- could you explain what's going on with this
patch?


Basically it just turns:

if ssa0 {
  ...
  vec4 ssa1 = txf .
} else {
   ...
   vec4 ssa2 = ...
}
vec4 ss3 = phi ssa1, ssa2

Into

if ssa0 {
  ...
  vec4 ssa1 = txf .
  vec1 ssa2 = imov ssa1.x
  vec1 ssa3 = imov ssa1.y
  vec1 ssa4 = imov ssa1.z
  vec1 ssa5 = imov ssa1.w
} else {
   ...
   vec4 ssa6 = ...
   vec1 ssa7 = imov ssa6.x
   vec1 ssa8 = imov ssa6.y
   vec1 ssa9 = imov ssa6.z
   vec1 ssa10 = imov ssa6.w
}
vec1 ss11 = phi ssa2, ssa7
vec1 ss12 = phi ssa3, ssa8
vec1 ss13 = phi ssa4, ssa9
vec1 ss14 = phi ssa5, ssa10


This allows a whole bunch more optimisation to take place as often not 
all of the phi channels are actually used. If some cases large chunks of 
logic can be remove from the if branch that doesn't contain the texture 
access.





I think I can for Intel though I'm not sure how this affects other drivers.

On Intel hardware, we almost always have to combine all the texture sources 
into one big message.  Since having more than one source is very common, this 
means that we have to make a temporary copy of the sources anyway.  Because 
we're copying them, having them contiguous (a vector in NIR terms) doesn't 
actually gain us anything.  We may as well let NIR scalarize them and give more 
freedom to the register allocator and other NIR passes which may need to clean 
things up.  We don't want to make the same choice for destinations as they are 
required to be contiguous.



hmm, but this is abut the phi src (ie. the tex dest), not the tex src, isn't it?


Yeah, thats correct. Which is why I think its fine to be bunched with 
the "These are trivially scalarizable" types?




BR,
-R


Feel free to copy+paste that somewhere.  I agree with Eric that they are not 
"trivially scalarizable" but they are safe to scalarize.

--Jason
___
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: add nir_instr_type_tex support to nir_lower_phis_to_scalar()

[Rob Clark]

On Fri, Feb 22, 2019 at 12:39 PM Jason Ekstrand  wrote:
>
> On Fri, Feb 22, 2019 at 9:51 AM Eric Anholt  wrote:
>>
>> Timothy Arceri  writes:
>>
>> > shader-db results i965 (SKL):
>> >
>> > total instructions in shared programs: 13219105 -> 13024761 (-1.47%)
>> > instructions in affected programs: 1169457 -> 975113 (-16.62%)
>> > helped: 599
>> > HURT: 154
>> >
>> > total cycles in shared programs: 333968972 -> 324822073 (-2.74%)
>> > cycles in affected programs: 130032440 -> 120885541 (-7.03%)
>> > helped: 590
>> > HURT: 216
>> >
>> > total spills in shared programs: 57947 -> 29130 (-49.73%)
>> > spills in affected programs: 53364 -> 24547 (-54.00%)
>> > helped: 351
>> > HURT: 0
>> >
>> > total fills in shared programs: 51310 -> 25468 (-50.36%)
>> > fills in affected programs: 44882 -> 19040 (-57.58%)
>> > helped: 351
>> > HURT: 0
>> > ---
>> >  src/compiler/nir/nir_lower_phis_to_scalar.c | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/src/compiler/nir/nir_lower_phis_to_scalar.c 
>> > b/src/compiler/nir/nir_lower_phis_to_scalar.c
>> > index 16001f73685..f6f702bca15 100644
>> > --- a/src/compiler/nir/nir_lower_phis_to_scalar.c
>> > +++ b/src/compiler/nir/nir_lower_phis_to_scalar.c
>> > @@ -74,6 +74,7 @@ is_phi_src_scalarizable(nir_phi_src *src,
>> >/* A phi is scalarizable if we're going to lower it */
>> >return should_lower_phi(nir_instr_as_phi(src_instr), state);
>> >
>> > +   case nir_instr_type_tex:
>> > case nir_instr_type_load_const:
>> > case nir_instr_type_ssa_undef:
>> >/* These are trivially scalarizable */
>>
>> Sounds promising, but I would definitely not describe instr_type_tex as
>> "trivially scalarizable" -- could you explain what's going on with this
>> patch?
>
>
> I think I can for Intel though I'm not sure how this affects other drivers.
>
> On Intel hardware, we almost always have to combine all the texture sources 
> into one big message.  Since having more than one source is very common, this 
> means that we have to make a temporary copy of the sources anyway.  Because 
> we're copying them, having them contiguous (a vector in NIR terms) doesn't 
> actually gain us anything.  We may as well let NIR scalarize them and give 
> more freedom to the register allocator and other NIR passes which may need to 
> clean things up.  We don't want to make the same choice for destinations as 
> they are required to be contiguous.
>

hmm, but this is abut the phi src (ie. the tex dest), not the tex src, isn't it?

BR,
-R

> Feel free to copy+paste that somewhere.  I agree with Eric that they are not 
> "trivially scalarizable" but they are safe to scalarize.
>
> --Jason
> ___
> 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 109748] follow not working

[bugzilla-daemon]

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

Mayank  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |indive...@gmail.com
   |org |
 QA Contact|mesa-dev@lists.freedesktop. |hrideshgupt...@gmail.com
   |org |

--- Comment #1 from Mayank  ---
please check this bug

-- 
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 109748] follow not working

[bugzilla-daemon]

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

Bug ID: 109748
   Summary: follow not working
   Product: Mesa
   Version: 7.4
  Hardware: Other
OS: Windows (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: GLU
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: memayank1...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

step 1: open site
step2: go to this url
http://xz.com/abc/mm

step3: scroll down to botton and you will see follow button of Mayank user

step 4: click on it.

It is breaking.

-- 
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 109747] Add framerate to vulkan-overlay-layer

[bugzilla-daemon]

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

--- Comment #1 from Shmerl  ---
Also, frametimes meter seems to be always on without any option to control it.
May be it should be behind an option as well.

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

[Mesa-dev] [Bug 109747] Add framerate to vulkan-overlay-layer

[bugzilla-daemon]

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

Bug ID: 109747
   Summary: Add framerate to vulkan-overlay-layer
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/Common
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: shtetl...@gmail.com
CC: airl...@freedesktop.org, chadvers...@chromium.org,
dan...@fooishbar.org, ja...@jlekstrand.net

Framerate can be very useful for benchmarks.

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

Re: [Mesa-dev] [PATCH 1/3] glsl: XFB TSC per-vertex output varyings match as not declared as arrays

[Chema Casanova]

V2 of this series that address the fix for
KHR-GL*.tessellation_shader.single.xfb_captures_data_from_correct_stage
regressions is available at Gitlab MR!300

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

On 21/11/18 19:45, Jose Maria Casanova Crespo wrote:
> Recent change on OpenGL CTS ("Use non-arrayed varying name for TCS blocks")
> on KHR-GL*.tessellation_shader.single.xfb_captures_data_from_correct_stage
> tests changed how to name per-vertex Tessellation Control Shader output
> varyings in transform feedback using interface block as "BLOCK_INOUT.value"
> rather than "BLOCK_INOUT[0].value"
> 
> So Tessellation control shader per-vertex output variables and blocks that
> are required to be declared as arrays, with each element representing output
> values for a single vertex of a multi-vertex primitive are expected to be
> named as they were not declared as arrays.
> 
> This patch adds a new is_xfb_per_vertex_output flag at ir_variable level so
> we mark when an ir_variable is an per-vertex TCS output varying. So we
> treat it in terms on XFB its naming as a non array variable.
> 
> As we don't support NV_gpu_shader5, so PATCHES mode is not accepted as
> primitiveMode parameter of BeginTransformFeedback the test expects a
> failure as we can use the XFB results.
> 
> This patch uncovers that we were passing the GLES version of the tests
> because candidates naming didn't match, not because on GLES the Tessellation
> Control stage varyings shouldn't be XFB candidates in any case. This
> is addressed in the following patch.
> 
> Fixes: 
> KHR-GL4*.tessellation_shader.single.xfb_captures_data_from_correct_stage
> 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/compiler/glsl/ir.cpp| 1 +
>  src/compiler/glsl/ir.h  | 6 ++
>  src/compiler/glsl/link_uniforms.cpp | 6 --
>  src/compiler/glsl/link_varyings.cpp | 8 +++-
>  4 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/src/compiler/glsl/ir.cpp b/src/compiler/glsl/ir.cpp
> index 1d1a56ae9a5..582111d71f5 100644
> --- a/src/compiler/glsl/ir.cpp
> +++ b/src/compiler/glsl/ir.cpp
> @@ -1750,6 +1750,7 @@ ir_variable::ir_variable(const struct glsl_type *type, 
> const char *name,
> this->data.fb_fetch_output = false;
> this->data.bindless = false;
> this->data.bound = false;
> +   this->data.is_xfb_per_vertex_output = false;
>  
> if (type != NULL) {
>if (type->is_interface())
> diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
> index f478b29a6b5..e09f053b77c 100644
> --- a/src/compiler/glsl/ir.h
> +++ b/src/compiler/glsl/ir.h
> @@ -766,6 +766,12 @@ public:
> */
>unsigned is_xfb_only:1;
>  
> +  /**
> +   * Is this varying a TSC per-vertex output candidate for transform
> +   * feedback?
> +   */
> +  unsigned is_xfb_per_vertex_output:1;
> +
>/**
> * Was a transfor feedback buffer set in the shader?
> */
> diff --git a/src/compiler/glsl/link_uniforms.cpp 
> b/src/compiler/glsl/link_uniforms.cpp
> index 63e688b19a7..547da68e216 100644
> --- a/src/compiler/glsl/link_uniforms.cpp
> +++ b/src/compiler/glsl/link_uniforms.cpp
> @@ -72,8 +72,10 @@ program_resource_visitor::process(ir_variable *var, bool 
> use_std430_as_default)
>   get_internal_ifc_packing(use_std430_as_default) :
>var->type->get_internal_ifc_packing(use_std430_as_default);
>  
> -   const glsl_type *t =
> -  var->data.from_named_ifc_block ? var->get_interface_type() : var->type;
> +   const glsl_type *t = var->data.from_named_ifc_block ?
> +  (var->data.is_xfb_per_vertex_output ?
> +   var->get_interface_type()->without_array() :
> +   var->get_interface_type()) : var->type;
> const glsl_type *t_without_array = t->without_array();
>  
> /* false is always passed for the row_major parameter to the other
> diff --git a/src/compiler/glsl/link_varyings.cpp 
> b/src/compiler/glsl/link_varyings.cpp
> index 52e493cb599..1964dcc0a22 100644
> --- a/src/compiler/glsl/link_varyings.cpp
> +++ b/src/compiler/glsl/link_varyings.cpp
> @@ -2150,7 +2150,10 @@ private:
>tfeedback_candidate *candidate
>   = rzalloc(this->mem_ctx, tfeedback_candidate);
>candidate->toplevel_var = this->toplevel_var;
> -  candidate->type = type;
> +  if (this->toplevel_var->data.is_xfb_per_vertex_output)
> + candidate->type = type->without_array();
> +  else
> + candidate->type = type;
>candidate->offset = this->varying_floats;
>_mesa_hash_table_insert(this->tfeedback_candidates,
>ralloc_strdup(this->mem_ctx, name),
> @@ -2499,6 +2502,9 @@ assign_varying_locations(struct gl_context *ctx,
>  
>   if (num_tfeedback_decls > 0) {
>  tfeedback_candidate_generator g(mem_ctx, tfeedback_candidates);
> +if (producer->Stage == MESA_SHADER_TESS_CTRL &&
> +!output_var->data.patch)
> +   

Re: [Mesa-dev] [PATCH] nir: add nir_instr_type_tex support to nir_lower_phis_to_scalar()

[Jason Ekstrand]

On Fri, Feb 22, 2019 at 9:51 AM Eric Anholt  wrote:

> Timothy Arceri  writes:
>
> > shader-db results i965 (SKL):
> >
> > total instructions in shared programs: 13219105 -> 13024761 (-1.47%)
> > instructions in affected programs: 1169457 -> 975113 (-16.62%)
> > helped: 599
> > HURT: 154
> >
> > total cycles in shared programs: 333968972 -> 324822073 (-2.74%)
> > cycles in affected programs: 130032440 -> 120885541 (-7.03%)
> > helped: 590
> > HURT: 216
> >
> > total spills in shared programs: 57947 -> 29130 (-49.73%)
> > spills in affected programs: 53364 -> 24547 (-54.00%)
> > helped: 351
> > HURT: 0
> >
> > total fills in shared programs: 51310 -> 25468 (-50.36%)
> > fills in affected programs: 44882 -> 19040 (-57.58%)
> > helped: 351
> > HURT: 0
> > ---
> >  src/compiler/nir/nir_lower_phis_to_scalar.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/src/compiler/nir/nir_lower_phis_to_scalar.c
> b/src/compiler/nir/nir_lower_phis_to_scalar.c
> > index 16001f73685..f6f702bca15 100644
> > --- a/src/compiler/nir/nir_lower_phis_to_scalar.c
> > +++ b/src/compiler/nir/nir_lower_phis_to_scalar.c
> > @@ -74,6 +74,7 @@ is_phi_src_scalarizable(nir_phi_src *src,
> >/* A phi is scalarizable if we're going to lower it */
> >return should_lower_phi(nir_instr_as_phi(src_instr), state);
> >
> > +   case nir_instr_type_tex:
> > case nir_instr_type_load_const:
> > case nir_instr_type_ssa_undef:
> >/* These are trivially scalarizable */
>
> Sounds promising, but I would definitely not describe instr_type_tex as
> "trivially scalarizable" -- could you explain what's going on with this
> patch?
>

I think I can for Intel though I'm not sure how this affects other drivers.

On Intel hardware, we almost always have to combine all the texture sources
into one big message.  Since having more than one source is very common,
this means that we have to make a temporary copy of the sources anyway.
Because we're copying them, having them contiguous (a vector in NIR terms)
doesn't actually gain us anything.  We may as well let NIR scalarize them
and give more freedom to the register allocator and other NIR passes which
may need to clean things up.  We don't want to make the same choice for
destinations as they are required to be contiguous.

Feel free to copy+paste that somewhere.  I agree with Eric that they are
not "trivially scalarizable" but they are safe to scalarize.

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

Re: [Mesa-dev] [PATCH v3 2/2] anv: advertise 8 subpixel precision bits

[Juan A. Suarez Romero]

On Fri, 2019-02-22 at 10:04 -0600, Jason Ekstrand wrote:
> On Fri, Feb 22, 2019 at 9:58 AM Jason Ekstrand  wrote:
> > On Fri, Feb 22, 2019 at 9:57 AM Lionel Landwerlin 
> >  wrote:
> > > On 22/02/2019 15:51, Juan A. Suarez Romero wrote:
> > > 
> > > > On one side, when emitting 3DSTATE_SF, VertexSubPixelPrecisionSelect is
> > > 
> > > > used to select between 8 bit subpixel precision (value 0) or 4 bit
> > > 
> > > > subpixel precision (value 1). As this value is not set, means it is
> > > 
> > > > taking the value 0, so 8 bit are used.
> > > 
> > > >
> > > 
> > > > On the other side, in the Vulkan CTS tests, if the reference rasterizer,
> > > 
> > > > which uses 8 bit precision, as it is used to check what should be the
> > > 
> > > > expected value for the tests, is changed to use 4 bit as ANV was
> > > 
> > > > advertising so far, some of the tests will fail.
> > > 
> > > >
> > > 
> > > > So it seems ANV is actually using 8 bits.
> > > 
> > > >
> > > 
> > > > v2: explicitly set 3DSTATE_SF::VertexSubPixelPrecisionSelect (Jason)
> > > 
> > > > v3: use _8Bit definition as value (Jason)
> > > 
> > > >
> > > 
> > > > CC: Jason Ekstrand 
> > > 
> > > > CC: Kenneth Graunke 
> > > 
> > > > Signed-off-by: Juan A. Suarez Romero 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Reviewed-by: Lionel Landwerlin 
> > 
> > Reviewed-by: Jason Ekstrand 
> > 
> 
> I just sent a patch which also sets the corresponding bit in 3DSTATE_CLIP on 
> gen8+.  Feel free to squash it into this one before merging.  The information 
> is redundant but we should be explicitly setting it both places.  I think the 
> one in 3DSTATE_CLIP is for the viewport clip test that got added on gen8.
> 
Squashed into this one, and CCed the series to @stable.
Thank you both!
J.A.
> --Jason
>  
> >  
> > > Cc: stable?
> > 
> > Not a bad idea.
> > --Jason
> >  
> > > 
> > > > ---
> > > 
> > > >   src/intel/vulkan/anv_device.c| 2 +-
> > > 
> > > >   src/intel/vulkan/genX_pipeline.c | 1 +
> > > 
> > > >   2 files changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > >
> > > 
> > > > diff --git a/src/intel/vulkan/anv_device.c 
> > > > b/src/intel/vulkan/anv_device.c
> > > 
> > > > index 3120865466a..95224407318 100644
> > > 
> > > > --- a/src/intel/vulkan/anv_device.c
> > > 
> > > > +++ b/src/intel/vulkan/anv_device.c
> > > 
> > > > @@ -1095,7 +1095,7 @@ void anv_GetPhysicalDeviceProperties(
> > > 
> > > >16 * devinfo->max_cs_threads,
> > > 
> > > >16 * devinfo->max_cs_threads,
> > > 
> > > > },
> > > 
> > > > -  .subPixelPrecisionBits= 4 /* FIXME */,
> > > 
> > > > +  .subPixelPrecisionBits= 8,
> > > 
> > > > .subTexelPrecisionBits= 4 /* FIXME */,
> > > 
> > > > .mipmapPrecisionBits  = 4 /* FIXME */,
> > > 
> > > > .maxDrawIndexedIndexValue = UINT32_MAX,
> > > 
> > > > diff --git a/src/intel/vulkan/genX_pipeline.c 
> > > > b/src/intel/vulkan/genX_pipeline.c
> > > 
> > > > index 6255e5d83c5..3d36bb773e1 100644
> > > 
> > > > --- a/src/intel/vulkan/genX_pipeline.c
> > > 
> > > > +++ b/src/intel/vulkan/genX_pipeline.c
> > > 
> > > > @@ -464,6 +464,7 @@ emit_rs_state(struct anv_pipeline *pipeline,
> > > 
> > > >  sf.TriangleStripListProvokingVertexSelect = 0;
> > > 
> > > >  sf.LineStripListProvokingVertexSelect = 0;
> > > 
> > > >  sf.TriangleFanProvokingVertexSelect = 1;
> > > 
> > > > +   sf.VertexSubPixelPrecisionSelect = _8Bit;
> > > 
> > > >   
> > > 
> > > >  const struct brw_vue_prog_data *last_vue_prog_data =
> > > 
> > > > anv_pipeline_get_last_vue_prog_data(pipeline);
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ___
> > > 
> > > 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 109735] [Regression] broken font with mesa_vulkan_overlay

[bugzilla-daemon]

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

Bas Nieuwenhuizen  changed:

   What|Removed |Added

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

--- Comment #4 from Bas Nieuwenhuizen  ---
Fixed with https://gitlab.freedesktop.org/mesa/mesa/merge_requests/294

-- 
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] anv: Explicitly set 3DSTATE_CLIP::VertexSubPixelPrecisionSelect

[Lionel Landwerlin]

On 22/02/2019 16:02, Jason Ekstrand wrote:

This field was added on gen8 even though there's an identically defined
one in 3DSTATE_SF.
---
  src/intel/vulkan/genX_pipeline.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 6255e5d83c5..192a121324d 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -1077,6 +1077,10 @@ emit_3dstate_clip(struct anv_pipeline *pipeline,
clip.APIMode  = APIMODE_D3D,
clip.ViewportXYClipTestEnable = true;
  
+#if GEN_GEN >= 8

+  clip.VertexSubPixelPrecisionSelect = _8Bit;
+#endif
+
clip.ClipMode = CLIPMODE_NORMAL;
  
clip.TriangleStripListProvokingVertexSelect = 0;



Well spotted.


Reviewed-by: Lionel Landwerlin 

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

Re: [Mesa-dev] [PATCH v3 1/2] genxml: add missing field values for 3DSTATE_SF

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Fri, Feb 22, 2019 at 9:56 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> On 22/02/2019 15:51, Juan A. Suarez Romero wrote:
> > Fill out "Vertex Sub Pixel Precision Select" possible values.
> >
> > Signed-off-by: Juan A. Suarez Romero 
>
>
> Reviewed-by: Lionel Landwerlin 
>
>
> > ---
> >   src/intel/genxml/gen10.xml | 5 -
> >   src/intel/genxml/gen11.xml | 5 -
> >   src/intel/genxml/gen7.xml  | 5 -
> >   src/intel/genxml/gen75.xml | 5 -
> >   src/intel/genxml/gen8.xml  | 5 -
> >   src/intel/genxml/gen9.xml  | 5 -
> >   6 files changed, 24 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
> > index 284633aedd4..4cb1f05ae25 100644
> > --- a/src/intel/genxml/gen10.xml
> > +++ b/src/intel/genxml/gen10.xml
> > @@ -2043,7 +2043,10 @@
> > 
> >   
> >type="bool"/>
> > - end="108" type="uint"/>
> > + end="108" type="uint">
> > +  
> > +  
> > +
> >   
> > 
> > 
> > diff --git a/src/intel/genxml/gen11.xml b/src/intel/genxml/gen11.xml
> > index 95a84a2f597..a7c06c5ab60 100644
> > --- a/src/intel/genxml/gen11.xml
> > +++ b/src/intel/genxml/gen11.xml
> > @@ -2063,7 +2063,10 @@
> > 
> >   
> >type="bool"/>
> > - end="108" type="uint"/>
> > + end="108" type="uint">
> > +  
> > +  
> > +
> >   
> > 
> > 
> > diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
> > index 363fd8664bf..1b2c7d996f9 100644
> > --- a/src/intel/genxml/gen7.xml
> > +++ b/src/intel/genxml/gen7.xml
> > @@ -1399,7 +1399,10 @@
> >type="uint">
> > 
> >   
> > - end="108" type="uint"/>
> > + end="108" type="uint">
> > +  
> > +  
> > +
> >   
> > 
> > 
> > diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
> > index a1da9cae041..95b306139eb 100644
> > --- a/src/intel/genxml/gen75.xml
> > +++ b/src/intel/genxml/gen75.xml
> > @@ -1713,7 +1713,10 @@
> >type="uint">
> > 
> >   
> > - end="108" type="uint"/>
> > + end="108" type="uint">
> > +  
> > +  
> > +
> >   
> > 
> > 
> > diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
> > index 4676d9bca9c..0226d7c0c66 100644
> > --- a/src/intel/genxml/gen8.xml
> > +++ b/src/intel/genxml/gen8.xml
> > @@ -1816,7 +1816,10 @@
> > 
> >   
> >type="bool"/>
> > - end="108" type="uint"/>
> > + end="108" type="uint">
> > +  
> > +  
> > +
> >   
> > 
> > 
> > diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
> > index 8afa986df55..88fc2da7885 100644
> > --- a/src/intel/genxml/gen9.xml
> > +++ b/src/intel/genxml/gen9.xml
> > @@ -1995,7 +1995,10 @@
> > 
> >   
> >type="bool"/>
> > - end="108" type="uint"/>
> > + end="108" type="uint">
> > +  
> > +  
> > +
> >   
> > 
> > 
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 2/2] anv: advertise 8 subpixel precision bits

[Jason Ekstrand]

On Fri, Feb 22, 2019 at 9:58 AM Jason Ekstrand  wrote:

> On Fri, Feb 22, 2019 at 9:57 AM Lionel Landwerlin <
> lionel.g.landwer...@intel.com> wrote:
>
>> On 22/02/2019 15:51, Juan A. Suarez Romero wrote:
>> > On one side, when emitting 3DSTATE_SF, VertexSubPixelPrecisionSelect is
>> > used to select between 8 bit subpixel precision (value 0) or 4 bit
>> > subpixel precision (value 1). As this value is not set, means it is
>> > taking the value 0, so 8 bit are used.
>> >
>> > On the other side, in the Vulkan CTS tests, if the reference rasterizer,
>> > which uses 8 bit precision, as it is used to check what should be the
>> > expected value for the tests, is changed to use 4 bit as ANV was
>> > advertising so far, some of the tests will fail.
>> >
>> > So it seems ANV is actually using 8 bits.
>> >
>> > v2: explicitly set 3DSTATE_SF::VertexSubPixelPrecisionSelect (Jason)
>> > v3: use _8Bit definition as value (Jason)
>> >
>> > CC: Jason Ekstrand 
>> > CC: Kenneth Graunke 
>> > Signed-off-by: Juan A. Suarez Romero 
>>
>>
>> Reviewed-by: Lionel Landwerlin 
>>
>
> Reviewed-by: Jason Ekstrand 
>

I just sent a patch which also sets the corresponding bit in 3DSTATE_CLIP
on gen8+.  Feel free to squash it into this one before merging.  The
information is redundant but we should be explicitly setting it both
places.  I think the one in 3DSTATE_CLIP is for the viewport clip test that
got added on gen8.

--Jason


>
>
>> Cc: stable?
>>
>
> Not a bad idea.
>
> --Jason
>
>
>>
>> > ---
>> >   src/intel/vulkan/anv_device.c| 2 +-
>> >   src/intel/vulkan/genX_pipeline.c | 1 +
>> >   2 files changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/src/intel/vulkan/anv_device.c
>> b/src/intel/vulkan/anv_device.c
>> > index 3120865466a..95224407318 100644
>> > --- a/src/intel/vulkan/anv_device.c
>> > +++ b/src/intel/vulkan/anv_device.c
>> > @@ -1095,7 +1095,7 @@ void anv_GetPhysicalDeviceProperties(
>> >16 * devinfo->max_cs_threads,
>> >16 * devinfo->max_cs_threads,
>> > },
>> > -  .subPixelPrecisionBits= 4 /* FIXME */,
>> > +  .subPixelPrecisionBits= 8,
>> > .subTexelPrecisionBits= 4 /* FIXME */,
>> > .mipmapPrecisionBits  = 4 /* FIXME */,
>> > .maxDrawIndexedIndexValue = UINT32_MAX,
>> > diff --git a/src/intel/vulkan/genX_pipeline.c
>> b/src/intel/vulkan/genX_pipeline.c
>> > index 6255e5d83c5..3d36bb773e1 100644
>> > --- a/src/intel/vulkan/genX_pipeline.c
>> > +++ b/src/intel/vulkan/genX_pipeline.c
>> > @@ -464,6 +464,7 @@ emit_rs_state(struct anv_pipeline *pipeline,
>> >  sf.TriangleStripListProvokingVertexSelect = 0;
>> >  sf.LineStripListProvokingVertexSelect = 0;
>> >  sf.TriangleFanProvokingVertexSelect = 1;
>> > +   sf.VertexSubPixelPrecisionSelect = _8Bit;
>> >
>> >  const struct brw_vue_prog_data *last_vue_prog_data =
>> > anv_pipeline_get_last_vue_prog_data(pipeline);
>>
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] anv: Explicitly set 3DSTATE_CLIP::VertexSubPixelPrecisionSelect

[Jason Ekstrand]

This field was added on gen8 even though there's an identically defined
one in 3DSTATE_SF.
---
 src/intel/vulkan/genX_pipeline.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 6255e5d83c5..192a121324d 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -1077,6 +1077,10 @@ emit_3dstate_clip(struct anv_pipeline *pipeline,
   clip.APIMode  = APIMODE_D3D,
   clip.ViewportXYClipTestEnable = true;
 
+#if GEN_GEN >= 8
+  clip.VertexSubPixelPrecisionSelect = _8Bit;
+#endif
+
   clip.ClipMode = CLIPMODE_NORMAL;
 
   clip.TriangleStripListProvokingVertexSelect = 0;
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH v3 2/2] anv: advertise 8 subpixel precision bits

[Jason Ekstrand]

On Fri, Feb 22, 2019 at 9:57 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> On 22/02/2019 15:51, Juan A. Suarez Romero wrote:
> > On one side, when emitting 3DSTATE_SF, VertexSubPixelPrecisionSelect is
> > used to select between 8 bit subpixel precision (value 0) or 4 bit
> > subpixel precision (value 1). As this value is not set, means it is
> > taking the value 0, so 8 bit are used.
> >
> > On the other side, in the Vulkan CTS tests, if the reference rasterizer,
> > which uses 8 bit precision, as it is used to check what should be the
> > expected value for the tests, is changed to use 4 bit as ANV was
> > advertising so far, some of the tests will fail.
> >
> > So it seems ANV is actually using 8 bits.
> >
> > v2: explicitly set 3DSTATE_SF::VertexSubPixelPrecisionSelect (Jason)
> > v3: use _8Bit definition as value (Jason)
> >
> > CC: Jason Ekstrand 
> > CC: Kenneth Graunke 
> > Signed-off-by: Juan A. Suarez Romero 
>
>
> Reviewed-by: Lionel Landwerlin 
>

Reviewed-by: Jason Ekstrand 


> Cc: stable?
>

Not a bad idea.

--Jason


>
> > ---
> >   src/intel/vulkan/anv_device.c| 2 +-
> >   src/intel/vulkan/genX_pipeline.c | 1 +
> >   2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/intel/vulkan/anv_device.c
> b/src/intel/vulkan/anv_device.c
> > index 3120865466a..95224407318 100644
> > --- a/src/intel/vulkan/anv_device.c
> > +++ b/src/intel/vulkan/anv_device.c
> > @@ -1095,7 +1095,7 @@ void anv_GetPhysicalDeviceProperties(
> >16 * devinfo->max_cs_threads,
> >16 * devinfo->max_cs_threads,
> > },
> > -  .subPixelPrecisionBits= 4 /* FIXME */,
> > +  .subPixelPrecisionBits= 8,
> > .subTexelPrecisionBits= 4 /* FIXME */,
> > .mipmapPrecisionBits  = 4 /* FIXME */,
> > .maxDrawIndexedIndexValue = UINT32_MAX,
> > diff --git a/src/intel/vulkan/genX_pipeline.c
> b/src/intel/vulkan/genX_pipeline.c
> > index 6255e5d83c5..3d36bb773e1 100644
> > --- a/src/intel/vulkan/genX_pipeline.c
> > +++ b/src/intel/vulkan/genX_pipeline.c
> > @@ -464,6 +464,7 @@ emit_rs_state(struct anv_pipeline *pipeline,
> >  sf.TriangleStripListProvokingVertexSelect = 0;
> >  sf.LineStripListProvokingVertexSelect = 0;
> >  sf.TriangleFanProvokingVertexSelect = 1;
> > +   sf.VertexSubPixelPrecisionSelect = _8Bit;
> >
> >  const struct brw_vue_prog_data *last_vue_prog_data =
> > anv_pipeline_get_last_vue_prog_data(pipeline);
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 2/2] anv: advertise 8 subpixel precision bits

[Lionel Landwerlin]

On 22/02/2019 15:51, Juan A. Suarez Romero wrote:

On one side, when emitting 3DSTATE_SF, VertexSubPixelPrecisionSelect is
used to select between 8 bit subpixel precision (value 0) or 4 bit
subpixel precision (value 1). As this value is not set, means it is
taking the value 0, so 8 bit are used.

On the other side, in the Vulkan CTS tests, if the reference rasterizer,
which uses 8 bit precision, as it is used to check what should be the
expected value for the tests, is changed to use 4 bit as ANV was
advertising so far, some of the tests will fail.

So it seems ANV is actually using 8 bits.

v2: explicitly set 3DSTATE_SF::VertexSubPixelPrecisionSelect (Jason)
v3: use _8Bit definition as value (Jason)

CC: Jason Ekstrand 
CC: Kenneth Graunke 
Signed-off-by: Juan A. Suarez Romero 



Reviewed-by: Lionel Landwerlin 


Cc: stable?



---
  src/intel/vulkan/anv_device.c| 2 +-
  src/intel/vulkan/genX_pipeline.c | 1 +
  2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 3120865466a..95224407318 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1095,7 +1095,7 @@ void anv_GetPhysicalDeviceProperties(
   16 * devinfo->max_cs_threads,
   16 * devinfo->max_cs_threads,
},
-  .subPixelPrecisionBits= 4 /* FIXME */,
+  .subPixelPrecisionBits= 8,
.subTexelPrecisionBits= 4 /* FIXME */,
.mipmapPrecisionBits  = 4 /* FIXME */,
.maxDrawIndexedIndexValue = UINT32_MAX,
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 6255e5d83c5..3d36bb773e1 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -464,6 +464,7 @@ emit_rs_state(struct anv_pipeline *pipeline,
 sf.TriangleStripListProvokingVertexSelect = 0;
 sf.LineStripListProvokingVertexSelect = 0;
 sf.TriangleFanProvokingVertexSelect = 1;
+   sf.VertexSubPixelPrecisionSelect = _8Bit;
  
 const struct brw_vue_prog_data *last_vue_prog_data =

anv_pipeline_get_last_vue_prog_data(pipeline);



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

Re: [Mesa-dev] [PATCH v3 1/2] genxml: add missing field values for 3DSTATE_SF

[Lionel Landwerlin]

On 22/02/2019 15:51, Juan A. Suarez Romero wrote:

Fill out "Vertex Sub Pixel Precision Select" possible values.

Signed-off-by: Juan A. Suarez Romero 



Reviewed-by: Lionel Landwerlin 



---
  src/intel/genxml/gen10.xml | 5 -
  src/intel/genxml/gen11.xml | 5 -
  src/intel/genxml/gen7.xml  | 5 -
  src/intel/genxml/gen75.xml | 5 -
  src/intel/genxml/gen8.xml  | 5 -
  src/intel/genxml/gen9.xml  | 5 -
  6 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
index 284633aedd4..4cb1f05ae25 100644
--- a/src/intel/genxml/gen10.xml
+++ b/src/intel/genxml/gen10.xml
@@ -2043,7 +2043,10 @@

  
  
-
+
+  
+  
+
  


diff --git a/src/intel/genxml/gen11.xml b/src/intel/genxml/gen11.xml
index 95a84a2f597..a7c06c5ab60 100644
--- a/src/intel/genxml/gen11.xml
+++ b/src/intel/genxml/gen11.xml
@@ -2063,7 +2063,10 @@

  
  
-
+
+  
+  
+
  


diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index 363fd8664bf..1b2c7d996f9 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -1399,7 +1399,10 @@
  

  
-
+
+  
+  
+
  


diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index a1da9cae041..95b306139eb 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -1713,7 +1713,10 @@
  

  
-
+
+  
+  
+
  


diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 4676d9bca9c..0226d7c0c66 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -1816,7 +1816,10 @@

  
  
-
+
+  
+  
+
  


diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index 8afa986df55..88fc2da7885 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -1995,7 +1995,10 @@

  
  
-
+
+  
+  
+
  





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

[Mesa-dev] [PATCH v3 1/2] genxml: add missing field values for 3DSTATE_SF

[Juan A. Suarez Romero]

Fill out "Vertex Sub Pixel Precision Select" possible values.

Signed-off-by: Juan A. Suarez Romero 
---
 src/intel/genxml/gen10.xml | 5 -
 src/intel/genxml/gen11.xml | 5 -
 src/intel/genxml/gen7.xml  | 5 -
 src/intel/genxml/gen75.xml | 5 -
 src/intel/genxml/gen8.xml  | 5 -
 src/intel/genxml/gen9.xml  | 5 -
 6 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
index 284633aedd4..4cb1f05ae25 100644
--- a/src/intel/genxml/gen10.xml
+++ b/src/intel/genxml/gen10.xml
@@ -2043,7 +2043,10 @@
   
 
 
-
+
+  
+  
+
 
   
   
diff --git a/src/intel/genxml/gen11.xml b/src/intel/genxml/gen11.xml
index 95a84a2f597..a7c06c5ab60 100644
--- a/src/intel/genxml/gen11.xml
+++ b/src/intel/genxml/gen11.xml
@@ -2063,7 +2063,10 @@
   
 
 
-
+
+  
+  
+
 
   
   
diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index 363fd8664bf..1b2c7d996f9 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -1399,7 +1399,10 @@
 
   
 
-
+
+  
+  
+
 
   
   
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index a1da9cae041..95b306139eb 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -1713,7 +1713,10 @@
 
   
 
-
+
+  
+  
+
 
   
   
diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 4676d9bca9c..0226d7c0c66 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -1816,7 +1816,10 @@
   
 
 
-
+
+  
+  
+
 
   
   
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index 8afa986df55..88fc2da7885 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -1995,7 +1995,10 @@
   
 
 
-
+
+  
+  
+
 
   
   
-- 
2.20.1

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

[Mesa-dev] [PATCH v3 2/2] anv: advertise 8 subpixel precision bits

[Juan A. Suarez Romero]

On one side, when emitting 3DSTATE_SF, VertexSubPixelPrecisionSelect is
used to select between 8 bit subpixel precision (value 0) or 4 bit
subpixel precision (value 1). As this value is not set, means it is
taking the value 0, so 8 bit are used.

On the other side, in the Vulkan CTS tests, if the reference rasterizer,
which uses 8 bit precision, as it is used to check what should be the
expected value for the tests, is changed to use 4 bit as ANV was
advertising so far, some of the tests will fail.

So it seems ANV is actually using 8 bits.

v2: explicitly set 3DSTATE_SF::VertexSubPixelPrecisionSelect (Jason)
v3: use _8Bit definition as value (Jason)

CC: Jason Ekstrand 
CC: Kenneth Graunke 
Signed-off-by: Juan A. Suarez Romero 
---
 src/intel/vulkan/anv_device.c| 2 +-
 src/intel/vulkan/genX_pipeline.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 3120865466a..95224407318 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1095,7 +1095,7 @@ void anv_GetPhysicalDeviceProperties(
  16 * devinfo->max_cs_threads,
  16 * devinfo->max_cs_threads,
   },
-  .subPixelPrecisionBits= 4 /* FIXME */,
+  .subPixelPrecisionBits= 8,
   .subTexelPrecisionBits= 4 /* FIXME */,
   .mipmapPrecisionBits  = 4 /* FIXME */,
   .maxDrawIndexedIndexValue = UINT32_MAX,
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 6255e5d83c5..3d36bb773e1 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -464,6 +464,7 @@ emit_rs_state(struct anv_pipeline *pipeline,
sf.TriangleStripListProvokingVertexSelect = 0;
sf.LineStripListProvokingVertexSelect = 0;
sf.TriangleFanProvokingVertexSelect = 1;
+   sf.VertexSubPixelPrecisionSelect = _8Bit;
 
const struct brw_vue_prog_data *last_vue_prog_data =
   anv_pipeline_get_last_vue_prog_data(pipeline);
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] nir: add nir_instr_type_tex support to nir_lower_phis_to_scalar()

[Eric Anholt]

Timothy Arceri  writes:

> shader-db results i965 (SKL):
>
> total instructions in shared programs: 13219105 -> 13024761 (-1.47%)
> instructions in affected programs: 1169457 -> 975113 (-16.62%)
> helped: 599
> HURT: 154
>
> total cycles in shared programs: 333968972 -> 324822073 (-2.74%)
> cycles in affected programs: 130032440 -> 120885541 (-7.03%)
> helped: 590
> HURT: 216
>
> total spills in shared programs: 57947 -> 29130 (-49.73%)
> spills in affected programs: 53364 -> 24547 (-54.00%)
> helped: 351
> HURT: 0
>
> total fills in shared programs: 51310 -> 25468 (-50.36%)
> fills in affected programs: 44882 -> 19040 (-57.58%)
> helped: 351
> HURT: 0
> ---
>  src/compiler/nir/nir_lower_phis_to_scalar.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/compiler/nir/nir_lower_phis_to_scalar.c 
> b/src/compiler/nir/nir_lower_phis_to_scalar.c
> index 16001f73685..f6f702bca15 100644
> --- a/src/compiler/nir/nir_lower_phis_to_scalar.c
> +++ b/src/compiler/nir/nir_lower_phis_to_scalar.c
> @@ -74,6 +74,7 @@ is_phi_src_scalarizable(nir_phi_src *src,
>/* A phi is scalarizable if we're going to lower it */
>return should_lower_phi(nir_instr_as_phi(src_instr), state);
>  
> +   case nir_instr_type_tex:
> case nir_instr_type_load_const:
> case nir_instr_type_ssa_undef:
>/* These are trivially scalarizable */

Sounds promising, but I would definitely not describe instr_type_tex as
"trivially scalarizable" -- could you explain what's going on with this
patch?


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 109739] Mesa build fails when vulkan-overlay-layer option is enabled

[bugzilla-daemon]

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

--- Comment #5 from Lionel Landwerlin  ---
Uploaded https://gitlab.freedesktop.org/mesa/mesa/merge_requests/293

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

Re: [Mesa-dev] [PATCH 3/4] i965: Use genxml for emitting PIPE_CONTROL.

[Pohjolainen, Topi]

On Thu, Nov 01, 2018 at 08:04:20PM -0700, Kenneth Graunke wrote:
> While this does add a bunch of boilerplate, it also protects us against
> the hardware moving bits, or changing their meaning.  For something as
> finnicky as PIPE_CONTROL, the extra safety seems worth it.
> 
> We turn PIPE_CONTROL_* into an bitfield of arbitrary flags, and then
> pack them appropriately.

This is clearly better than before in my opinion. Few suggestions below but
patches 1-3 are:

Reviewed-by: Topi Pohjolainen 

> ---
>  src/mesa/drivers/dri/i965/Makefile.sources|   9 +
>  src/mesa/drivers/dri/i965/brw_context.h   |   4 +
>  src/mesa/drivers/dri/i965/brw_pipe_control.c  | 240 +++--
>  src/mesa/drivers/dri/i965/brw_pipe_control.h  |  58 +++--
>  src/mesa/drivers/dri/i965/brw_state.h |  31 +++
>  src/mesa/drivers/dri/i965/genX_pipe_control.c | 243 ++
>  src/mesa/drivers/dri/i965/meson.build |   4 +-
>  7 files changed, 359 insertions(+), 230 deletions(-)
>  create mode 100644 src/mesa/drivers/dri/i965/genX_pipe_control.c
> 
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index 63fa7b886f2..e4eb0339e09 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -127,46 +127,55 @@ intel_tiled_memcpy_dep_FILES = \
>  i965_gen4_FILES = \
>   genX_blorp_exec.c \
>   genX_boilerplate.h \
> + genX_pipe_control.c \
>   genX_state_upload.c
>  
>  i965_gen45_FILES = \
>   genX_blorp_exec.c \
>   genX_boilerplate.h \
> + genX_pipe_control.c \
>   genX_state_upload.c
>  
>  i965_gen5_FILES = \
>   genX_blorp_exec.c \
>   genX_boilerplate.h \
> + genX_pipe_control.c \
>   genX_state_upload.c
>  
>  i965_gen6_FILES = \
>   genX_blorp_exec.c \
>   genX_boilerplate.h \
> + genX_pipe_control.c \
>   genX_state_upload.c
>  
>  i965_gen7_FILES = \
>   genX_blorp_exec.c \
>   genX_boilerplate.h \
> + genX_pipe_control.c \
>   genX_state_upload.c
>  
>  i965_gen75_FILES = \
>   genX_blorp_exec.c \
>   genX_boilerplate.h \
> + genX_pipe_control.c \
>   genX_state_upload.c
>  
>  i965_gen8_FILES = \
>   genX_blorp_exec.c \
>   genX_boilerplate.h \
> + genX_pipe_control.c \
>   genX_state_upload.c
>  
>  i965_gen9_FILES = \
>   genX_blorp_exec.c \
>   genX_boilerplate.h \
> + genX_pipe_control.c \
>   genX_state_upload.c
>  
>  i965_gen10_FILES = \
>   genX_blorp_exec.c \
>   genX_boilerplate.h \
> + genX_pipe_control.c \
>   genX_state_upload.c
>  
>  i965_gen11_FILES = \
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 7fd15669eb9..fe75425854c 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -752,6 +752,10 @@ struct brw_context
>  struct brw_bo *bo,
>  uint32_t offset_in_bytes,
>  uint32_t report_id);
> +
> +  void (*emit_raw_pipe_control)(struct brw_context *brw, uint32_t flags,
> +struct brw_bo *bo, uint32_t offset,
> +uint64_t imm);
> } vtbl;
>  
> struct brw_bufmgr *bufmgr;
> diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c 
> b/src/mesa/drivers/dri/i965/brw_pipe_control.c
> index 4d76e5dc9b7..cf9cc35875f 100644
> --- a/src/mesa/drivers/dri/i965/brw_pipe_control.c
> +++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
> @@ -23,200 +23,10 @@
>  
>  #include "brw_context.h"
>  #include "brw_defines.h"
> +#include "brw_state.h"
>  #include "intel_batchbuffer.h"
>  #include "intel_fbo.h"
>  
> -/**
> - * According to the latest documentation, any PIPE_CONTROL with the
> - * "Command Streamer Stall" bit set must also have another bit set,
> - * with five different options:
> - *
> - *  - Render Target Cache Flush
> - *  - Depth Cache Flush
> - *  - Stall at Pixel Scoreboard
> - *  - Post-Sync Operation
> - *  - Depth Stall
> - *  - DC Flush Enable
> - *
> - * I chose "Stall at Pixel Scoreboard" since we've used it effectively
> - * in the past, but the choice is fairly arbitrary.
> - */
> -static void
> -gen8_add_cs_stall_workaround_bits(uint32_t *flags)
> -{
> -   uint32_t wa_bits = PIPE_CONTROL_RENDER_TARGET_FLUSH |
> -  PIPE_CONTROL_DEPTH_CACHE_FLUSH |
> -  PIPE_CONTROL_WRITE_IMMEDIATE |
> -  PIPE_CONTROL_WRITE_DEPTH_COUNT |
> -  PIPE_CONTROL_WRITE_TIMESTAMP |
> -  PIPE_CONTROL_STALL_AT_SCOREBOARD |
> -  PIPE_CONTROL_DEPTH_STALL |
> -  PIPE_CONTROL_DATA_CACHE_FLUSH;
> -
> -   /* If we're doing a CS stall, and don't already have one of the
> -* workaround bits set, add "Stall 

[Mesa-dev] [Bug 109739] Mesa build fails when vulkan-overlay-layer option is enabled

[bugzilla-daemon]

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

--- Comment #4 from Lionel Landwerlin  ---
On the install : true, I was told to remove it. Not being a meson expert but I
can definitely put it back.

On the header files of the loader/validation-layers, I have the headers
installed in a different directory because of a compile option of the loader. I
should probably go with the same options as debian.

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

[Mesa-dev] [Bug 109739] Mesa build fails when vulkan-overlay-layer option is enabled

[bugzilla-daemon]

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

--- Comment #3 from Tapani Pälli  ---
It seems like meson.build should add 'inc_vulkan_validation' dev header
directory to include_directories or just append 'vulkan/' for each header used
from there.

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

Re: [Mesa-dev] [PATCH] panfrost: Backport driver to Mali T600/T700

[Emil Velikov]

On Tue, 19 Feb 2019 at 16:59, Connor Abbott  wrote:
>
> On Tue, Feb 19, 2019 at 5:33 PM Emil Velikov  wrote:
>>
>> On Fri, 15 Feb 2019 at 21:39, Alyssa Rosenzweig  wrote:
>> >
>> > > - about 1/5 of the patch seems to be white space changes
>> >
>> > ...Oops. Any tips for avoiding this type of diff churn in the future? I
>> > suppose it's not inherently harmful, but maybe it could make merging
>> > more difficult than strictly necessary.
>> >
>> Splitting/polishing patches can be fiddly - but IMHO pays in the long run.
>> IIRC not too long ago Dave mentioned that specific work took him more
>> time to polish+split than to write+debug the code.
>>
>> > > - doesn't seem like BIFROST is defined anywhere
>> >
>> > Indeed it's not; Bifrost is not yet supported, but at least this way we
>> > can share headers with the out-of-tree work on Bifrost (is anyone
>> > working on these parts right now..?)
>> >
>> > > - other drivers keep details like is_t6xx, require_sfbd, others in
>> > > driver/screen specific struct
>> >
>> > Aye, that'll be fixed next patch :)
>> >
>> > > - the __LP64__ checks seems suspicious, no other mesa driver has those
>> >
>> > Is there a better way to handle mixed bit-ness? We have shared memory
>> > (sort of -- separate MMUs, separate address spaces, but they're mapped
>> > together with shared physical RAM and we opt for SAME_VA where gpu_va ==
>> > user_cpu_va). As such, 32-bit Mali and 64-bit Mali behave differently,
>> > since pointers are larger and then some fields get rearranged to pack
>> > tighter/less-so depending on pointer sizes. There's no real benefit to
>> > support both modes in the same build of the driver; by far, having a
>> > 32-bit build for armhf with 32-bit Mali descriptors and a 64-bit build
>> > for aarch64 with 64-bit descriptors is the sane approach. Accordingly,
>> > I reasoned that __LP64__ is the cleanest way to check what type of
>> > system we're building for, and from there which descriptor flavour we
>> > should use. Is there something inherently problematic about this scheme?
>> >
>> I might not be the best person for this, but I think subtle
>> differences like these should not be exposed to userspace (be part of
>> the UABI).
>> In the x86 world running 64bit kernels with 32bit userspace is fairly
>> common, but from what I hear it's less so in Arm land.
>
>
> This isn't UABI, since it has absolutely nothing to do with the kernel. The 
> hardware supports two command stream formats, the 32-bit one where pointers 
> are expanded from 32-bit to 64-bit internally by the HW and the 64-bit one, 
> and userspace tells the hardware which one it wants to use by setting a bit 
> in the job header which is only interpreted by the hardware. Right now the 
> idea is to select which one based on what bitsize the userspace is compiled 
> for, hence uintptr_t for pointers, but this could change in the future 
> without having to notify the kernel. Nothing in the kernel is reading these 
> pointers at all besides some HW workarounds in the vendor kernel which read 
> the same "which bitsize am I" bit the HW does.
>
Thanks for the explanation Connor. Seems like I got carried away
thinking the kernel driver modifies or parses these before feeding
them to the hardware.

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

Re: [Mesa-dev] [PATCH v2 2/2] isl: the display engine requires 64B alignment for linear surfaces

[Lionel Landwerlin]

Pushed with the PRM quote, thanks!

On 22/02/2019 06:16, Samuel Iglesias Gonsálvez wrote:

Lionel, are you going to push it with this quote? I can add it
otherwise.

Sam

On Thu, 2019-02-21 at 13:41 +, Lionel Landwerlin wrote:

On 21/02/2019 13:30, Chris Wilson wrote:

Quoting Lionel Landwerlin (2019-02-21 12:57:09)

I did not find the PRM bit that says it must be 64b aligned, but
I can
see that's what i915 checks.

Chris: If you have a pointer to it, I could add the quote.

In amongst the register specs,
PLANE_STRIDE:
For Linear memory, this field specifies the stride in chunks of 64
bytes (1 cache line).
-Chris


Thanks a lot!




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

Re: [Mesa-dev] [PATCH] etnaviv: blt: mark used src resource as read from

[Boris Brezillon]

On Fri, 22 Feb 2019 11:10:29 +0100
Christian Gmeiner  wrote:

> Signed-off-by: Christian Gmeiner 

Reviewed-by: Boris Brezillon 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_blt.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_blt.c 
> b/src/gallium/drivers/etnaviv/etnaviv_blt.c
> index 52731a9c770..42190d75d4e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_blt.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_blt.c
> @@ -510,7 +510,9 @@ etna_try_blt_blit(struct pipe_context *pctx,
> etna_stall(ctx->stream, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_BLT);
> etna_set_state(ctx->stream, VIVS_GL_FLUSH_CACHE, 0x0c23);
>  
> +   resource_read(ctx, >base);
> resource_written(ctx, >base);
> +
> dst->seqno++;
> dst_lev->ts_valid = false;
>  

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

Re: [Mesa-dev] etnaviv: rs: mark used src resource as read from

[Boris Brezillon]

On Fri, 22 Feb 2019 11:02:34 +0100
Christian Gmeiner  wrote:

> Signed-off-by: Christian Gmeiner 

Reviewed-by: Boris Brezillon 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index fc4f65dbeee..a9d3872ad41 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -728,6 +728,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
> });
>  
> etna_submit_rs_state(ctx, _to_screen);
> +   resource_read(ctx, >base);
> resource_written(ctx, >base);
> dst->seqno++;
> dst->levels[blit_info->dst.level].ts_valid = false;

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

Re: [Mesa-dev] [PATCH v5] etnaviv: fix resource usage tracking across different pipe_context's

[Boris Brezillon]

On Thu, 21 Feb 2019 23:29:53 +0100
Boris Brezillon  wrote:

> Christian, Marek,
> 
> On Wed, 30 Jan 2019 05:28:14 +0100
> Marek Vasut  wrote:
> 
> > From: Christian Gmeiner 
> > 
> > A pipe_resource can be shared by all the pipe_context's hanging off the
> > same pipe_screen.  
> 
> We seem to be impacted by the problem you're fixing here, but, while
> this patch definitely make things much better, the problem does not
> seem to be entirely fixed (at least in our case).
> 
> A bit more context: we have Qt App using QtWebEngine to render html
> content. When we call QtWebEngine::initialize(), which as for effect
> to allow shared GL contexts, we sometimes notice that part of the web
> page is mis-rendered. That does not happen when we omit the
> QtWebEngine::initialize() call.
> As said above, this patch make those rendering issues less likely to
> happen, but we still have the problem from time to time. So I thought
> I'd share my guesses about what could cause these issues before
> debugging it further.
> 
> First thing I noticed: I couldn't reproduce the problem with [1]
> applied (+ a tiny change forcing CPU-based tiling no matter the size of
> the region to tile/untile). So, my guess is that it's related to how we
> handle GPU-based tiling/untiling.
> Also noticed that we're testing the rsc->status here [2] without the
> screen->lock held, and there might be a race with another thread calling
> resource_used(). We might also lack a resource_read(ctx, >base)
> here [3]. But even after fixing those problems, the rendering issues
> are not gone.

I tested again with the following diff applied on top of your patch, and
the remaining rendering issues we had seem to be gone (don't know what I
messed up in my previous tests :-/).

--->8---
diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
b/src/gallium/drivers/etnaviv/etnaviv_rs.c
index fc4f65dbeee1..b8c8b96a6f72 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
@@ -729,6 +729,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
 
etna_submit_rs_state(ctx, _to_screen);
resource_written(ctx, >base);
+   resource_read(ctx, >base);
dst->seqno++;
dst->levels[blit_info->dst.level].ts_valid = false;
ctx->dirty |= ETNA_DIRTY_DERIVE_TS;
diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
index a3013e624ead..e4b2ac605e63 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
@@ -356,6 +356,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
 * transfers without a temporary resource.
 */
if (trans->rsc || !(usage & PIPE_TRANSFER_UNSYNCHRONIZED)) {
+  struct etna_screen *screen = ctx->screen;
   uint32_t prep_flags = 0;
 
   /*
@@ -364,11 +365,13 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
* current GPU usage (reads must wait for GPU writes, writes must have
* exclusive access to the buffer).
*/
+  mtx_lock(>lock);
   if ((trans->rsc && (etna_resource(trans->rsc)->status & 
ETNA_PENDING_WRITE)) ||
   (!trans->rsc &&
(((usage & PIPE_TRANSFER_READ) && (rsc->status & 
ETNA_PENDING_WRITE)) ||
((usage & PIPE_TRANSFER_WRITE) && rsc->status
  pctx->flush(pctx, NULL, 0);
+  mtx_unlock(>lock);
 
   if (usage & PIPE_TRANSFER_READ)
  prep_flags |= DRM_ETNA_PREP_READ;



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

Re: [Mesa-dev] [PATCH] etnaviv: blt: mark used src resource as read from

[Lucas Stach]

Am Freitag, den 22.02.2019, 11:10 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_blt.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_blt.c
> b/src/gallium/drivers/etnaviv/etnaviv_blt.c
> index 52731a9c770..42190d75d4e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_blt.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_blt.c
> @@ -510,7 +510,9 @@ etna_try_blt_blit(struct pipe_context *pctx,
> etna_stall(ctx->stream, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_BLT);
> etna_set_state(ctx->stream, VIVS_GL_FLUSH_CACHE, 0x0c23);
>  
> +   resource_read(ctx, >base);
> resource_written(ctx, >base);
> +
> dst->seqno++;
> dst_lev->ts_valid = false;
>  

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

Re: [Mesa-dev] etnaviv: rs: mark used src resource as read from

[Lucas Stach]

Am Freitag, den 22.02.2019, 11:02 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index fc4f65dbeee..a9d3872ad41 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -728,6 +728,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
> });
>  
> etna_submit_rs_state(ctx, _to_screen);
> +   resource_read(ctx, >base);
> resource_written(ctx, >base);
> dst->seqno++;
> dst->levels[blit_info->dst.level].ts_valid = false;

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

[Mesa-dev] [Bug 109532] ir_variable has maximum access out of bounds -- but it's not out of bounds

[bugzilla-daemon]

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

--- Comment #36 from asimiklit  ---
(In reply to Ian Romanick from comment #33)
> (In reply to andrii simiklit from comment #32)
> > (In reply to andrii simiklit from comment #31)
> > > (In reply to Mark Janes from comment #30)
> > > > (In reply to Mark Janes from comment #28)
> > > > >   
> > > > > https://android-review.googlesource.com/c/platform/external/deqp/+/901894
> > > > 
> > > > Mesa still asserts with this fix.  I also tested Andrii's mesa patch 
> > > > with
> > > > the dEQP fix and the test fails.
> > > Do you mean the Chris's dEQP fix here, yes?
> > > But looks like the mentioned Chris's dEQP fix considers some GL 
> > > limitations
> > > and doesn't affect the expectations of binding points.
> > > 
> > > Also the assertion is a separate issue, I created the piglit test for 
> > > that:
> > > https://patchwork.freedesktop.org/patch/286287/
> > > But yes, we unable to fix the test fail without assertion because of crash
> > > :-)
> > > 
> > > > 
> > > > Since non-mesa drivers have found issues with the original dEQP change, 
> > > > I
> > > > suspect there are still deeper problems with the test.
> > > Possible they have the same issue with binding points mismatch after
> > > optimizations by glsl compiler. 
> > > They could try this fix/hack for deqp which is already helped us:
> > > https://github.com/asimiklit/deqp/commit/
> > > 91cff8150944213f6da533e281ee76d95ca00f21
> > > If it helps them we will know that it is a common issue and it could
> > > expedite this:
> > > https://github.com/KhronosGroup/OpenGL-API/issues/46
> > 
> > So we have an answer from Piers Daniell:
> >   "I believe all buffer binding points should be consumed, regardless
> > whether 
> >the array elements are used or not. This would be the behavior of least 
> >surprise to the developer. I didn't see any language that would indicate 
> >that unused elements should not be counted when assigning the element to 
> >the buffer binding point."
> 
> I think this basically agrees with my earlier sentiment that we shouldn't
> trim elements from the beginning of the array.  It's generally ok (and in
> some cases expected) to trim elements from the end.

Ilia could you please share your thoughts about this solution?
Do you agree with Ian suggestion as to disallow the elimination from the
beginning of the array?
I am asking about it to understand have we consensus as to a direction of the
fix or not.

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

[Mesa-dev] [Bug 109739] Mesa build fails when vulkan-overlay-layer option is enabled

[bugzilla-daemon]

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

--- Comment #2 from osch...@web.de ---
I had to add this to get the overlay .so deployed:

diff --git a/src/vulkan/overlay-layer/meson.build
b/src/vulkan/overlay-layer/meson.build
index 573983e0438..9d1bc97c131 100644
--- a/src/vulkan/overlay-layer/meson.build
+++ b/src/vulkan/overlay-layer/meson.build
@@ -48,6 +48,7 @@ vklayer_mesa_overlay = shared_library(
   link_args : cc.get_supported_link_arguments(['-Wl,-Bsymbolic-functions',
'-Wl,-z,relro']),
   link_with : [libmesa_util, libvulkan_util],
   install_dir : vklayer_install_dir,
+  install : true
 )

also currently the layer won't get build with 

-D vulkan-drivers=''

so you can't build it independently.

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

[Mesa-dev] [PATCH] etnaviv: blt: mark used src resource as read from

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 src/gallium/drivers/etnaviv/etnaviv_blt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_blt.c 
b/src/gallium/drivers/etnaviv/etnaviv_blt.c
index 52731a9c770..42190d75d4e 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_blt.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_blt.c
@@ -510,7 +510,9 @@ etna_try_blt_blit(struct pipe_context *pctx,
etna_stall(ctx->stream, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_BLT);
etna_set_state(ctx->stream, VIVS_GL_FLUSH_CACHE, 0x0c23);
 
+   resource_read(ctx, >base);
resource_written(ctx, >base);
+
dst->seqno++;
dst_lev->ts_valid = false;
 
-- 
2.20.1

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

[Mesa-dev] etnaviv: rs: mark used src resource as read from

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
b/src/gallium/drivers/etnaviv/etnaviv_rs.c
index fc4f65dbeee..a9d3872ad41 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
@@ -728,6 +728,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
});
 
etna_submit_rs_state(ctx, _to_screen);
+   resource_read(ctx, >base);
resource_written(ctx, >base);
dst->seqno++;
dst->levels[blit_info->dst.level].ts_valid = false;
-- 
2.20.1

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

[Mesa-dev] [Bug 109711] [DXVK] Skyrim Special edition hangs

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Michel Dänzer  ---


*** This bug has been marked as a duplicate of bug 106713 ***

-- 
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 v5] etnaviv: fix resource usage tracking across different pipe_context's

[Christian Gmeiner]

Hi Boris,

Am Fr., 22. Feb. 2019 um 10:30 Uhr schrieb Boris Brezillon
:
>
> On Thu, 21 Feb 2019 23:29:53 +0100
> Boris Brezillon  wrote:
>
> > Christian, Marek,
> >
> > On Wed, 30 Jan 2019 05:28:14 +0100
> > Marek Vasut  wrote:
> >
> > > From: Christian Gmeiner 
> > >
> > > A pipe_resource can be shared by all the pipe_context's hanging off the
> > > same pipe_screen.
> >
> > We seem to be impacted by the problem you're fixing here, but, while
> > this patch definitely make things much better, the problem does not
> > seem to be entirely fixed (at least in our case).
> >

I also got some (private) reports about problems with QtWebEngine but had no
time yet to look more deeply into the issue.

>
> --->8---
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index fc4f65dbeee1..b8c8b96a6f72 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -729,6 +729,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
>
> etna_submit_rs_state(ctx, _to_screen);
> resource_written(ctx, >base);
> +   resource_read(ctx, >base);
> dst->seqno++;
> dst->levels[blit_info->dst.level].ts_valid = false;
> ctx->dirty |= ETNA_DIRTY_DERIVE_TS;
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index a3013e624ead..e4b2ac605e63 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -356,6 +356,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>  * transfers without a temporary resource.
>  */
> if (trans->rsc || !(usage & PIPE_TRANSFER_UNSYNCHRONIZED)) {
> +  struct etna_screen *screen = ctx->screen;
>uint32_t prep_flags = 0;
>
>/*
> @@ -364,11 +365,13 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
> * current GPU usage (reads must wait for GPU writes, writes must have
> * exclusive access to the buffer).
> */
> +  mtx_lock(>lock);
>if ((trans->rsc && (etna_resource(trans->rsc)->status & 
> ETNA_PENDING_WRITE)) ||
>(!trans->rsc &&
> (((usage & PIPE_TRANSFER_READ) && (rsc->status & 
> ETNA_PENDING_WRITE)) ||
> ((usage & PIPE_TRANSFER_WRITE) && rsc->status
>   pctx->flush(pctx, NULL, 0);
> +  mtx_unlock(>lock);
>
>if (usage & PIPE_TRANSFER_READ)
>   prep_flags |= DRM_ETNA_PREP_READ;
>

Looks good to me - will prepare a v6 of this patch with your changes
incorporated.

Thanks a lot!

-- 
greets
--
Christian Gmeiner, MSc

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

Re: [Mesa-dev] [PATCH 3/4] etnaviv: hook-up etc2 patching

[Lucas Stach]

Am Freitag, den 22.02.2019, 10:18 +0100 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

AFAICS this is directly operating on the mapped buffer, right?

As ETC is stored as a linear, we won't get a temporary resource for the
transfer, but map the GPU resource directly. So this will fail in some
cases for read transfers, as both GPU and CPU are allowed to do reads
to the resource at the same time, but now your read transfer mutates
the GPU resource. If we don't want to have a full temporary resource to
operate on, at least the DRM_ETNA_PREP_WRITE needs to be set on
etna_bo_cpu_prep(), to avoid the GPU sampling from the resource that
gets mutated by the the transfer map.

Regards,
Lucas
 

> ---
>  .../drivers/etnaviv/etnaviv_resource.c|  3 ++
>  .../drivers/etnaviv/etnaviv_resource.h|  5 ++
>  .../drivers/etnaviv/etnaviv_transfer.c| 49 +++
>  3 files changed, 57 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index db5ead4d0ba..45d5f69169e 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -478,6 +478,9 @@ etna_resource_destroy(struct pipe_screen *pscreen, struct 
> pipe_resource *prsc)
> pipe_resource_reference(>texture, NULL);
> pipe_resource_reference(>external, NULL);
>  
> +   for (unsigned i = 0; i < ETNA_NUM_LOD; i++)
> +  FREE(rsc->levels[i].patch_offsets);
> +
> FREE(rsc);
>  }
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> index 75aa80b3d7a..c45ff7586d1 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
> @@ -33,6 +33,7 @@
>  #include "util/list.h"
>  
>  struct pipe_screen;
> +struct util_dynarray;
>  
>  struct etna_resource_level {
> unsigned width, padded_width; /* in pixels */
> @@ -47,6 +48,10 @@ struct etna_resource_level {
> uint32_t ts_size;
> uint32_t clear_value; /* clear value of resource level (mainly for TS) */
> bool ts_valid;
> +
> +   /* keep track if we have done some per block patching */
> +   bool patched;
> +   struct util_dynarray *patch_offsets;
>  };
>  
>  enum etna_resource_addressing_mode {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 01da393d211..119820d52b5 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -28,6 +28,7 @@
>  #include "etnaviv_clear_blit.h"
>  #include "etnaviv_context.h"
>  #include "etnaviv_debug.h"
> +#include "etnaviv_etc2.h"
>  #include "etnaviv_screen.h"
>  
>  #include "pipe/p_defines.h"
> @@ -57,6 +58,46 @@ etna_compute_offset(enum pipe_format format, const struct 
> pipe_box *box,
>   util_format_get_blocksize(format);
>  }
>  
> +static void etna_patch_data(void *buffer, const struct pipe_transfer *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = >levels[ptrans->level];
> +
> +   if (!etna_etc2_needs_patching(prsc))
> +  return;
> +
> +   if (level->patched)
> +  return;
> +
> +   /* do have the offsets of blocks to patch? */
> +   if (!level->patch_offsets) {
> +  level->patch_offsets = CALLOC_STRUCT(util_dynarray);
> +
> +  etna_etc2_calculate_blocks(buffer, ptrans->stride,
> + ptrans->box.width, 
> ptrans->box.height,
> + prsc->format, level->patch_offsets);
> +   }
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = true;
> +}
> +
> +static void etna_unpatch_data(void *buffer, const struct pipe_transfer 
> *ptrans)
> +{
> +   struct pipe_resource *prsc = ptrans->resource;
> +   struct etna_resource *rsc = etna_resource(prsc);
> +   struct etna_resource_level *level = >levels[ptrans->level];
> +
> +   if (!level->patched)
> +  return;
> +
> +   etna_etc2_patch(buffer, level->patch_offsets);
> +
> +   level->patched = false;
> +}
> +
>  static void
>  etna_transfer_unmap(struct pipe_context *pctx, struct pipe_transfer *ptrans)
>  {
> @@ -119,6 +160,10 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> pipe_transfer *ptrans)
>}
> }
>  
> +   /* We need to have the patched data ready for the GPU. */
> +   if (rsc->layout == ETNA_LAYOUT_LINEAR)
> +  etna_patch_data(trans->mapped, ptrans);
> +
> /*
>  * Transfers without a temporary are only pulled into the CPU domain if 
> they
>  * are not mapped unsynchronized. If they are, must push them back into 
> GPU
> @@ -340,6 +385,10 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>   etna_compute_offset(prsc->format, box, res_level->stride,
>  

Re: [Mesa-dev] [PATCH 2/4] etnaviv: keep track of mapped bo address

[Lucas Stach]

Am Freitag, den 22.02.2019, 10:18 +0100 schrieb Christian Gmeiner:
> Saves us from calling etna_bo_map(..) and saves us from doing the
> same offset calcs for map() and unmap() operations.
> 
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.h |  1 +
>  .../drivers/etnaviv/etnaviv_transfer.c| 19 ++-
>  2 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
> b/src/gallium/drivers/etnaviv/etnaviv_context.h
> index 6ad9f3431e1..45b3954c7cb 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
> @@ -70,6 +70,7 @@ struct etna_transfer {
> struct pipe_transfer base;
> struct pipe_resource *rsc;
> void *staging;
> +   void *mapped;
>  };
>  
>  struct etna_vertexbuf_state {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 0b7411b47ef..01da393d211 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -91,16 +91,15 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
> pipe_transfer *ptrans)
>} else if (trans->staging) {
>   /* map buffer object */
>   struct etna_resource_level *res_level = >levels[ptrans->level];
> - void *mapped = etna_bo_map(rsc->bo) + res_level->offset;
>  
>   if (rsc->layout == ETNA_LAYOUT_TILED) {
>  etna_texture_tile(
> -   mapped + ptrans->box.z * res_level->layer_stride,
> +   trans->mapped + ptrans->box.z * res_level->layer_stride,
> trans->staging, ptrans->box.x, ptrans->box.y,
> res_level->stride, ptrans->box.width, ptrans->box.height,
> ptrans->stride, util_format_get_blocksize(rsc->base.format));
>   } else if (rsc->layout == ETNA_LAYOUT_LINEAR) {
> -util_copy_box(mapped, rsc->base.format, res_level->stride,
> +util_copy_box(trans->mapped, rsc->base.format, res_level->stride,
>res_level->layer_stride, ptrans->box.x,
>ptrans->box.y, ptrans->box.z, ptrans->box.width,
>ptrans->box.height, ptrans->box.depth,
> @@ -327,8 +326,8 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
> }
>  
> /* map buffer object */
> -   void *mapped = etna_bo_map(rsc->bo);
> -   if (!mapped)
> +   trans->mapped = etna_bo_map(rsc->bo);
> +   if (!trans->mapped)
>goto fail;
>  
> *out_transfer = ptrans;
> @@ -337,9 +336,11 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>ptrans->stride = res_level->stride;
>ptrans->layer_stride = res_level->layer_stride;
>  
> -  return mapped + res_level->offset +
> +  trans->mapped += res_level->offset +
>   etna_compute_offset(prsc->format, box, res_level->stride,
>   res_level->layer_stride);
> +
> +  return trans->mapped;
> } else {
>unsigned divSizeX = util_format_get_blockwidth(format);
>unsigned divSizeY = util_format_get_blockheight(format);
> @@ -350,7 +351,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>if (usage & PIPE_TRANSFER_MAP_DIRECTLY)
>   goto fail;
>  
> -  mapped += res_level->offset;
> +  trans->mapped += res_level->offset;
>ptrans->stride = align(box->width, divSizeX) * 
> util_format_get_blocksize(format); /* row stride in bytes */
>ptrans->layer_stride = align(box->height, divSizeY) * ptrans->stride;
>size_t size = ptrans->layer_stride * box->depth;
> @@ -362,7 +363,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>if (usage & PIPE_TRANSFER_READ) {
>   if (rsc->layout == ETNA_LAYOUT_TILED) {
>  etna_texture_untile(trans->staging,
> -mapped + ptrans->box.z * 
> res_level->layer_stride,
> +trans->mapped + ptrans->box.z * 
> res_level->layer_stride,
>  ptrans->box.x, ptrans->box.y, 
> res_level->stride,
>  ptrans->box.width, ptrans->box.height, 
> ptrans->stride,
>  util_format_get_blocksize(rsc->base.format));
> @@ -370,7 +371,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
> pipe_resource *prsc,
>  util_copy_box(trans->staging, rsc->base.format, ptrans->stride,
>ptrans->layer_stride, 0, 0, 0, /* dst x,y,z */
>ptrans->box.width, ptrans->box.height,
> -  ptrans->box.depth, mapped, res_level->stride,
> +  ptrans->box.depth, trans->mapped, 
> res_level->stride,
>   

[Mesa-dev] [PATCH 1/4] etnaviv: implement ETC2 block patching for HALTI0

[Christian Gmeiner]

ETC2 is supported with HALTI0, however that implementation is buggy
in hardware. The blob driver does per-block patching to work around
this. We need to swap colors for t-mode etc2 blocks.

Signed-off-by: Christian Gmeiner 
---
 src/gallium/drivers/etnaviv/Makefile.sources |   2 +
 src/gallium/drivers/etnaviv/etnaviv_etc2.c   | 149 +++
 src/gallium/drivers/etnaviv/etnaviv_etc2.h   |  51 +++
 src/gallium/drivers/etnaviv/meson.build  |   2 +
 4 files changed, 204 insertions(+)
 create mode 100644 src/gallium/drivers/etnaviv/etnaviv_etc2.c
 create mode 100644 src/gallium/drivers/etnaviv/etnaviv_etc2.h

diff --git a/src/gallium/drivers/etnaviv/Makefile.sources 
b/src/gallium/drivers/etnaviv/Makefile.sources
index 0b208122999..01e7e49a38a 100644
--- a/src/gallium/drivers/etnaviv/Makefile.sources
+++ b/src/gallium/drivers/etnaviv/Makefile.sources
@@ -25,6 +25,8 @@ C_SOURCES :=  \
etnaviv_disasm.h \
etnaviv_emit.c \
etnaviv_emit.h \
+   etnaviv_etc2.c \
+   etnaviv_etc2.h \
etnaviv_fence.c \
etnaviv_fence.h \
etnaviv_format.c \
diff --git a/src/gallium/drivers/etnaviv/etnaviv_etc2.c 
b/src/gallium/drivers/etnaviv/etnaviv_etc2.c
new file mode 100644
index 000..64811c3038d
--- /dev/null
+++ b/src/gallium/drivers/etnaviv/etnaviv_etc2.c
@@ -0,0 +1,149 @@
+/*
+ * Copyright (c) 2019 Etnaviv Project
+ * Copyright (C) 2019 Zodiac Inflight Innovations
+ *
+ * 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, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. 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.
+ *
+ * Authors:
+ *Christian Gmeiner 
+ */
+
+#include "etnaviv_etc2.h"
+#include "etnaviv_resource.h"
+#include "etnaviv_screen.h"
+#include "hw/common.xml.h"
+#include "util/u_format.h"
+
+bool
+etna_etc2_needs_patching(const struct pipe_resource *prsc)
+{
+   const struct etna_screen *screen = etna_screen(prsc->screen);
+
+   if (!util_format_is_etc(prsc->format))
+  return false;
+
+   if (prsc->format == PIPE_FORMAT_ETC1_RGB8)
+  return false;
+
+   if (VIV_FEATURE(screen, chipMinorFeatures2, HALTI1))
+  return false;
+
+   switch (prsc->format) {
+   case PIPE_FORMAT_ETC2_RGB8:
+   case PIPE_FORMAT_ETC2_SRGB8:
+   case PIPE_FORMAT_ETC2_RGB8A1:
+   case PIPE_FORMAT_ETC2_SRGB8A1:
+   case PIPE_FORMAT_ETC2_RGBA8:
+   case PIPE_FORMAT_ETC2_SRGBA8:
+  return true;
+  break;
+
+   default:
+  return false;
+   }
+}
+
+static inline bool
+needs_patching(uint8_t *buffer, bool punchthrough_alpha)
+{
+   /* punchthrough_alpha or etc2 individual mode? */
+   if (!punchthrough_alpha && !(buffer[3] & 0x2))
+ return false;
+
+   /* etc2 t-mode? */
+   static const int lookup[8] = { 0, 1, 2, 3, -4, -3, -2, -1 };
+   const int R_plus_dR = (buffer[0] >> 3) + lookup[buffer[0] & 0x7];
+
+   if (R_plus_dR < 0 || R_plus_dR > 31)
+  return true;
+
+   return false;
+}
+
+void
+etna_etc2_calculate_blocks(uint8_t *buffer, unsigned stride,
+   unsigned width, unsigned height,
+   enum pipe_format format,
+   struct util_dynarray *offsets)
+{
+   const unsigned bw = util_format_get_blockwidth(format);
+   const unsigned bh = util_format_get_blockheight(format);
+   const unsigned bs = util_format_get_blocksize(format);
+   bool punchthrough_alpha = false;
+   unsigned offset = 0;
+   const uint8_t *base = buffer;
+
+   if (format == PIPE_FORMAT_ETC2_RGB8A1 ||
+   format == PIPE_FORMAT_ETC2_SRGB8A1)
+  punchthrough_alpha = true;
+
+   if (format == PIPE_FORMAT_ETC2_RGBA8 ||
+   format == PIPE_FORMAT_ETC2_SRGBA8 ||
+   format == PIPE_FORMAT_ETC2_SRGB8A1)
+  offset = 8;
+
+   for (unsigned y = 0; y < height; y += bh) {
+  uint8_t *src = buffer;
+
+  for (unsigned x = 0; x < width; x+= bw) {
+ if (needs_patching(src + offset, punchthrough_alpha))
+util_dynarray_append(offsets, unsigned, src + offset - base);
+
+ src += bs;
+  }
+
+  

[Mesa-dev] [PATCH 0/4] Add ETC2 block patching for HALTI0

[Christian Gmeiner]

HALTI0 GPUs have broken ETC2 support (for RGB and RGBA)
formats. The blob driver does per-block patching. The patching
is quite simple: color swaping.

This patch series adds support for the needed block patching
and enabled ETC2 support for HALTI0.

Passes all tested formats of the following piglit:
 spec/!opengl es 3.0/oes_compressed_etc2_texture-miptree_gles3

Christian Gmeiner (4):
  etnaviv: implement ETC2 block patching for HALTI0
  etnaviv: keep track of mapped bo address
  etnaviv: hook-up etc2 patching
  etnaviv: enable ETC2 texture compression support for HALTI0 GPUs

 src/gallium/drivers/etnaviv/Makefile.sources  |   2 +
 src/gallium/drivers/etnaviv/etnaviv_context.h |   1 +
 src/gallium/drivers/etnaviv/etnaviv_etc2.c| 149 ++
 src/gallium/drivers/etnaviv/etnaviv_etc2.h|  51 ++
 .../drivers/etnaviv/etnaviv_resource.c|   3 +
 .../drivers/etnaviv/etnaviv_resource.h|   5 +
 src/gallium/drivers/etnaviv/etnaviv_screen.c  |  12 +-
 .../drivers/etnaviv/etnaviv_transfer.c|  68 ++--
 src/gallium/drivers/etnaviv/meson.build   |   2 +
 9 files changed, 273 insertions(+), 20 deletions(-)
 create mode 100644 src/gallium/drivers/etnaviv/etnaviv_etc2.c
 create mode 100644 src/gallium/drivers/etnaviv/etnaviv_etc2.h

-- 
2.20.1

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

[Mesa-dev] [PATCH 3/4] etnaviv: hook-up etc2 patching

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 .../drivers/etnaviv/etnaviv_resource.c|  3 ++
 .../drivers/etnaviv/etnaviv_resource.h|  5 ++
 .../drivers/etnaviv/etnaviv_transfer.c| 49 +++
 3 files changed, 57 insertions(+)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index db5ead4d0ba..45d5f69169e 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
@@ -478,6 +478,9 @@ etna_resource_destroy(struct pipe_screen *pscreen, struct 
pipe_resource *prsc)
pipe_resource_reference(>texture, NULL);
pipe_resource_reference(>external, NULL);
 
+   for (unsigned i = 0; i < ETNA_NUM_LOD; i++)
+  FREE(rsc->levels[i].patch_offsets);
+
FREE(rsc);
 }
 
diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.h 
b/src/gallium/drivers/etnaviv/etnaviv_resource.h
index 75aa80b3d7a..c45ff7586d1 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_resource.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_resource.h
@@ -33,6 +33,7 @@
 #include "util/list.h"
 
 struct pipe_screen;
+struct util_dynarray;
 
 struct etna_resource_level {
unsigned width, padded_width; /* in pixels */
@@ -47,6 +48,10 @@ struct etna_resource_level {
uint32_t ts_size;
uint32_t clear_value; /* clear value of resource level (mainly for TS) */
bool ts_valid;
+
+   /* keep track if we have done some per block patching */
+   bool patched;
+   struct util_dynarray *patch_offsets;
 };
 
 enum etna_resource_addressing_mode {
diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
index 01da393d211..119820d52b5 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
@@ -28,6 +28,7 @@
 #include "etnaviv_clear_blit.h"
 #include "etnaviv_context.h"
 #include "etnaviv_debug.h"
+#include "etnaviv_etc2.h"
 #include "etnaviv_screen.h"
 
 #include "pipe/p_defines.h"
@@ -57,6 +58,46 @@ etna_compute_offset(enum pipe_format format, const struct 
pipe_box *box,
  util_format_get_blocksize(format);
 }
 
+static void etna_patch_data(void *buffer, const struct pipe_transfer *ptrans)
+{
+   struct pipe_resource *prsc = ptrans->resource;
+   struct etna_resource *rsc = etna_resource(prsc);
+   struct etna_resource_level *level = >levels[ptrans->level];
+
+   if (!etna_etc2_needs_patching(prsc))
+  return;
+
+   if (level->patched)
+  return;
+
+   /* do have the offsets of blocks to patch? */
+   if (!level->patch_offsets) {
+  level->patch_offsets = CALLOC_STRUCT(util_dynarray);
+
+  etna_etc2_calculate_blocks(buffer, ptrans->stride,
+ ptrans->box.width, ptrans->box.height,
+ prsc->format, level->patch_offsets);
+   }
+
+   etna_etc2_patch(buffer, level->patch_offsets);
+
+   level->patched = true;
+}
+
+static void etna_unpatch_data(void *buffer, const struct pipe_transfer *ptrans)
+{
+   struct pipe_resource *prsc = ptrans->resource;
+   struct etna_resource *rsc = etna_resource(prsc);
+   struct etna_resource_level *level = >levels[ptrans->level];
+
+   if (!level->patched)
+  return;
+
+   etna_etc2_patch(buffer, level->patch_offsets);
+
+   level->patched = false;
+}
+
 static void
 etna_transfer_unmap(struct pipe_context *pctx, struct pipe_transfer *ptrans)
 {
@@ -119,6 +160,10 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
pipe_transfer *ptrans)
   }
}
 
+   /* We need to have the patched data ready for the GPU. */
+   if (rsc->layout == ETNA_LAYOUT_LINEAR)
+  etna_patch_data(trans->mapped, ptrans);
+
/*
 * Transfers without a temporary are only pulled into the CPU domain if they
 * are not mapped unsynchronized. If they are, must push them back into GPU
@@ -340,6 +385,10 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
  etna_compute_offset(prsc->format, box, res_level->stride,
  res_level->layer_stride);
 
+  /* We need to have the unpatched data ready for the gfx stack. */
+  if (usage & PIPE_TRANSFER_READ)
+ etna_unpatch_data(trans->mapped, ptrans);
+
   return trans->mapped;
} else {
   unsigned divSizeX = util_format_get_blockwidth(format);
-- 
2.20.1

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

[Mesa-dev] [PATCH 4/4] etnaviv: enable ETC2 texture compression support for HALTI0 GPUs

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 src/gallium/drivers/etnaviv/etnaviv_screen.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index de822fc85ca..ee32a499fb5 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -518,19 +518,9 @@ gpu_supports_texure_format(struct etna_screen *screen, 
uint32_t fmt,
if (util_format_is_srgb(format))
   supported = VIV_FEATURE(screen, chipMinorFeatures1, HALTI0);
 
-   if (fmt & EXT_FORMAT) {
+   if (fmt & EXT_FORMAT)
   supported = VIV_FEATURE(screen, chipMinorFeatures1, HALTI0);
 
-  /* ETC1 is checked above, as it has its own feature bit. ETC2 is
-   * supported with HALTI0, however that implementation is buggy in 
hardware.
-   * The blob driver does per-block patching to work around this. As this
-   * is currently not implemented by etnaviv, enable it for HALTI1 (GC3000)
-   * only.
-   */
-  if (util_format_is_etc(format))
- supported = VIV_FEATURE(screen, chipMinorFeatures2, HALTI1);
-   }
-
if (fmt & ASTC_FORMAT) {
   supported = screen->specs.tex_astc;
}
-- 
2.20.1

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

[Mesa-dev] [PATCH 2/4] etnaviv: keep track of mapped bo address

[Christian Gmeiner]

Saves us from calling etna_bo_map(..) and saves us from doing the
same offset calcs for map() and unmap() operations.

Signed-off-by: Christian Gmeiner 
---
 src/gallium/drivers/etnaviv/etnaviv_context.h |  1 +
 .../drivers/etnaviv/etnaviv_transfer.c| 19 ++-
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
b/src/gallium/drivers/etnaviv/etnaviv_context.h
index 6ad9f3431e1..45b3954c7cb 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_context.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
@@ -70,6 +70,7 @@ struct etna_transfer {
struct pipe_transfer base;
struct pipe_resource *rsc;
void *staging;
+   void *mapped;
 };
 
 struct etna_vertexbuf_state {
diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
index 0b7411b47ef..01da393d211 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
@@ -91,16 +91,15 @@ etna_transfer_unmap(struct pipe_context *pctx, struct 
pipe_transfer *ptrans)
   } else if (trans->staging) {
  /* map buffer object */
  struct etna_resource_level *res_level = >levels[ptrans->level];
- void *mapped = etna_bo_map(rsc->bo) + res_level->offset;
 
  if (rsc->layout == ETNA_LAYOUT_TILED) {
 etna_texture_tile(
-   mapped + ptrans->box.z * res_level->layer_stride,
+   trans->mapped + ptrans->box.z * res_level->layer_stride,
trans->staging, ptrans->box.x, ptrans->box.y,
res_level->stride, ptrans->box.width, ptrans->box.height,
ptrans->stride, util_format_get_blocksize(rsc->base.format));
  } else if (rsc->layout == ETNA_LAYOUT_LINEAR) {
-util_copy_box(mapped, rsc->base.format, res_level->stride,
+util_copy_box(trans->mapped, rsc->base.format, res_level->stride,
   res_level->layer_stride, ptrans->box.x,
   ptrans->box.y, ptrans->box.z, ptrans->box.width,
   ptrans->box.height, ptrans->box.depth,
@@ -327,8 +326,8 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
}
 
/* map buffer object */
-   void *mapped = etna_bo_map(rsc->bo);
-   if (!mapped)
+   trans->mapped = etna_bo_map(rsc->bo);
+   if (!trans->mapped)
   goto fail;
 
*out_transfer = ptrans;
@@ -337,9 +336,11 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
   ptrans->stride = res_level->stride;
   ptrans->layer_stride = res_level->layer_stride;
 
-  return mapped + res_level->offset +
+  trans->mapped += res_level->offset +
  etna_compute_offset(prsc->format, box, res_level->stride,
  res_level->layer_stride);
+
+  return trans->mapped;
} else {
   unsigned divSizeX = util_format_get_blockwidth(format);
   unsigned divSizeY = util_format_get_blockheight(format);
@@ -350,7 +351,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
   if (usage & PIPE_TRANSFER_MAP_DIRECTLY)
  goto fail;
 
-  mapped += res_level->offset;
+  trans->mapped += res_level->offset;
   ptrans->stride = align(box->width, divSizeX) * 
util_format_get_blocksize(format); /* row stride in bytes */
   ptrans->layer_stride = align(box->height, divSizeY) * ptrans->stride;
   size_t size = ptrans->layer_stride * box->depth;
@@ -362,7 +363,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
   if (usage & PIPE_TRANSFER_READ) {
  if (rsc->layout == ETNA_LAYOUT_TILED) {
 etna_texture_untile(trans->staging,
-mapped + ptrans->box.z * 
res_level->layer_stride,
+trans->mapped + ptrans->box.z * 
res_level->layer_stride,
 ptrans->box.x, ptrans->box.y, 
res_level->stride,
 ptrans->box.width, ptrans->box.height, 
ptrans->stride,
 util_format_get_blocksize(rsc->base.format));
@@ -370,7 +371,7 @@ etna_transfer_map(struct pipe_context *pctx, struct 
pipe_resource *prsc,
 util_copy_box(trans->staging, rsc->base.format, ptrans->stride,
   ptrans->layer_stride, 0, 0, 0, /* dst x,y,z */
   ptrans->box.width, ptrans->box.height,
-  ptrans->box.depth, mapped, res_level->stride,
+  ptrans->box.depth, trans->mapped, res_level->stride,
   res_level->layer_stride, ptrans->box.x,
   ptrans->box.y, ptrans->box.z);
  } else {
-- 
2.20.1

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

[Mesa-dev] [Bug 109741] swr doesn't build on i386 - simdlib.hpp:594:37: error: static assertion failed: This path only meant for 64-bit code

[bugzilla-daemon]

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

Bug ID: 109741
   Summary: swr doesn't build on i386 - simdlib.hpp:594:37: error:
static assertion failed: This path only meant for
64-bit code
   Product: Mesa
   Version: git
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/swr
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: pedretti.fa...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Full build log:
https://launchpadlibrarian.net/412340387/buildlog_ubuntu-cosmic-i386.mesa_19.1~git1902220944.338dac~oibaf~c_BUILDING.txt.gz

Error:
In file included from
../src/gallium/drivers/swr/rasterizer/common/simdintrin.h:28,
 from
../src/gallium/drivers/swr/rasterizer/core/format_types.h:31,
 from
../src/gallium/drivers/swr/rasterizer/core/format_traits.h:32,
 from
../src/gallium/drivers/swr/rasterizer/core/multisample.h:30,
 from ../src/gallium/drivers/swr/rasterizer/core/backend.h:33,
 from
src/gallium/drivers/swr/rasterizer/core/backends/gen_BackendPixelRate0.cpp:47:
../src/gallium/drivers/swr/rasterizer/common/simdlib.hpp: In member function
‘uint32_t SIMDVecHash::operator()(Integer) const’:
../src/gallium/drivers/swr/rasterizer/common/simdlib.hpp:594:37: error: static
assertion failed: This path only meant for 64-bit code
 static_assert(sizeof(void*) == 8, "This path only meant for 64-bit
code");
   ~~^~~~
../src/gallium/drivers/swr/rasterizer/common/simdlib.hpp:603:21: error: there
are no arguments to ‘_mm_crc32_u64’ that depend on a template parameter, so a
declaration of ‘_mm_crc32_u64’ must be available [-fpermissive]
 crc32 = _mm_crc32_u64(crc32, pData[i]);
 ^

-- 
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 v5] etnaviv: fix resource usage tracking across different pipe_context's

[Boris Brezillon]

Christian, Marek,

On Wed, 30 Jan 2019 05:28:14 +0100
Marek Vasut  wrote:

> From: Christian Gmeiner 
> 
> A pipe_resource can be shared by all the pipe_context's hanging off the
> same pipe_screen.

We seem to be impacted by the problem you're fixing here, but, while
this patch definitely make things much better, the problem does not
seem to be entirely fixed (at least in our case).

A bit more context: we have Qt App using QtWebEngine to render html
content. When we call QtWebEngine::initialize(), which as for effect
to allow shared GL contexts, we sometimes notice that part of the web
page is mis-rendered. That does not happen when we omit the
QtWebEngine::initialize() call.
As said above, this patch make those rendering issues less likely to
happen, but we still have the problem from time to time. So I thought
I'd share my guesses about what could cause these issues before
debugging it further.

First thing I noticed: I couldn't reproduce the problem with [1]
applied (+ a tiny change forcing CPU-based tiling no matter the size of
the region to tile/untile). So, my guess is that it's related to how we
handle GPU-based tiling/untiling.
Also noticed that we're testing the rsc->status here [2] without the
screen->lock held, and there might be a race with another thread calling
resource_used(). We might also lack a resource_read(ctx, >base)
here [3]. But even after fixing those problems, the rendering issues
are not gone. So I'm wondering is the problem is not coming from the
GPU-based tiling/untiling logic we have in etnaviv_transfer.c.

Indeed, RS-based tiling require the surface we tile/untile to be
aligned on at least 16 pixels (and even more in case of multi/super
tiles). In order to handle those constraints when the region the user
wants to map/update is not properly aligned, etna_transfer_map() first
untiles an RS-aligned region into a temporary linear buffer which will
then be updated according to the caller's needs and tiled back to the
actual texture when etna_transfer_unmap() is called. But what happens
if, between the untile operation in etna_transfer_map() and the tile
operation in etna_transfer_unmap(), another rendering request is done
on region that overlaps the RS-aligned region we untiled in our
temporary buffer?
Can't we end up in a situation where some a the data we are about to
copy back to the actual texture are actually outdated?

I'm completely new to etnaviv and mesa, so I wouldn't be surprised if
my analysis of the problem was wrong, but I thought it was worth an
email before digging further.

Please let me know if you have other ideas or need more details about
our use case.

Thanks,

Boris

[1]https://lists.freedesktop.org/archives/mesa-dev/2019-February/215597.html
[2]https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/etnaviv/etnaviv_transfer.c#n316
[3]https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/etnaviv/etnaviv_rs.c#n731

> 
> Signed-off-by: Christian Gmeiner 
> Signed-off-by: Marek Vasut 
> To: mesa-dev@lists.freedesktop.org
> Cc: etna...@lists.freedesktop.org
> ---
> Changes from v1 -> v2:
>  - to remove the resource from the used_resources set when it is destroyed
> Changes from v2 -> v3:
>  - add locking with mtx_*() to resource and screen (Marek)
> Changes from v3 -> v4:
>  - drop rsc->lock, just use screen->lock for the entire serialization (Marek)
>  - simplify etna_resource_used() flush condition, which also prevents
>potentially flushing resources twice (Marek)
>  - don't remove resouces from screen->used_resources in
>etna_cmd_stream_reset_notify(), they may still be used in other
>contexts and may need flushing there later on (Marek)
> Changes from v4 -> v5:
>  - Fix coding style issues reported by Guido
> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.c | 26 +-
>  src/gallium/drivers/etnaviv/etnaviv_context.h |  3 --
>  .../drivers/etnaviv/etnaviv_resource.c| 52 +++
>  .../drivers/etnaviv/etnaviv_resource.h|  8 +--
>  src/gallium/drivers/etnaviv/etnaviv_screen.c  | 12 +
>  src/gallium/drivers/etnaviv/etnaviv_screen.h  |  6 +++
>  6 files changed, 78 insertions(+), 29 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
> b/src/gallium/drivers/etnaviv/etnaviv_context.c
> index 3038d21..2f8cae8 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> @@ -36,6 +36,7 @@
>  #include "etnaviv_query.h"
>  #include "etnaviv_query_hw.h"
>  #include "etnaviv_rasterizer.h"
> +#include "etnaviv_resource.h"
>  #include "etnaviv_screen.h"
>  #include "etnaviv_shader.h"
>  #include "etnaviv_state.h"
> @@ -329,7 +330,8 @@ static void
>  etna_cmd_stream_reset_notify(struct etna_cmd_stream *stream, void *priv)
>  {
> struct etna_context *ctx = priv;
> -   struct etna_resource *rsc, *rsc_tmp;
> +   struct etna_screen *screen = ctx->screen;
> +   struct set_entry *entry;
>  
> etna_set_state(stream, 

[Mesa-dev] [PATCH] nir: add nir_instr_type_tex support to nir_lower_phis_to_scalar()

[Timothy Arceri]

shader-db results i965 (SKL):

total instructions in shared programs: 13219105 -> 13024761 (-1.47%)
instructions in affected programs: 1169457 -> 975113 (-16.62%)
helped: 599
HURT: 154

total cycles in shared programs: 333968972 -> 324822073 (-2.74%)
cycles in affected programs: 130032440 -> 120885541 (-7.03%)
helped: 590
HURT: 216

total spills in shared programs: 57947 -> 29130 (-49.73%)
spills in affected programs: 53364 -> 24547 (-54.00%)
helped: 351
HURT: 0

total fills in shared programs: 51310 -> 25468 (-50.36%)
fills in affected programs: 44882 -> 19040 (-57.58%)
helped: 351
HURT: 0
---
 src/compiler/nir/nir_lower_phis_to_scalar.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/compiler/nir/nir_lower_phis_to_scalar.c 
b/src/compiler/nir/nir_lower_phis_to_scalar.c
index 16001f73685..f6f702bca15 100644
--- a/src/compiler/nir/nir_lower_phis_to_scalar.c
+++ b/src/compiler/nir/nir_lower_phis_to_scalar.c
@@ -74,6 +74,7 @@ is_phi_src_scalarizable(nir_phi_src *src,
   /* A phi is scalarizable if we're going to lower it */
   return should_lower_phi(nir_instr_as_phi(src_instr), state);
 
+   case nir_instr_type_tex:
case nir_instr_type_load_const:
case nir_instr_type_ssa_undef:
   /* These are trivially scalarizable */
-- 
2.20.1

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