Re: [Mesa-dev] [PATCH 01/11] intel/compiler: lower 16-bit integer extended math instructions

[Iago Toral]

On Tue, 2018-04-24 at 23:11 -0400, Jason Ekstrand wrote:
> On April 24, 2018 18:38:33 Rob Clark  wrote:
> 
> On Tue, Apr 24, 2018 at 5:45 PM, Jason Ekstrand  > wrote:
> On Tue, Apr 24, 2018 at 7:38 AM, Rob Clark 
> wrote:
> 
> side-note, not sure if it really effects what you are doing here, but
> karol ran into some cases, like 8bit signed imax, which needs to be
> "lowered" to 16b (or 32b) and converted back for hw that doesn't
> support smaller than 16b (or 32b).  I think I have the same case with
> ir3, which also has 16b but no 8b, (but he is a bit further along cl
> cts than I am)..
> 
> I think there will be more of this sort of thing coming for more
> instructions and for more than just 16b vs 32b.  So not sure if
> writing rules for each in nir_opt_algebraic.py will be so fun..
> 
> 
> Yeah, it may be that what we want is a generic "lower this to
> something with
> more bits" pass.  If this is a problem for the CL people, maybe we
> just want
> some way to make it configurable and put it in core NIR.  I don't
> really
> have a huge preference.  I'm just trying to make sure we explore the
> solution space.
> 
> something generic/configurable in core nir seems more sane..
> 
> ofc, do what you need to do in the short term, I just mentioned this
> to point out that more of this sort of "handle fewer bits in more
> bits" stuff is coming down the pipe as we start seeing more 8b
> stuff..
> if needed we can refactor..
> 
> Yeah, maybe the best thing to do then would be to just leave this as
> is and 
> plan to pull it into core NIR and generalize it when the time
> comes.  One 
> idea for generalizing would be to have a callback that returns the
> bit size 
> to lower to or zero for "leave it alone".
> 
> I suspect we'll need more stuff like this for 8-bit integers and 16-
> bit 
> floats.  I'll review the original for real in the morning.

Yes, I confirm that. I have another pass that does the same for some
16-bt floating point operations, and in that case, some of the ops that
need to be lowered might depend on the hw gen.

Iago

> --Jason
> 
> 
> BR,
> -R
> 
> --Jason
> 
> 
> BR,
> -R
> 
> On Tue, Apr 24, 2018 at 9:56 AM, Jason Ekstrand  >
> wrote:
> It may be useful to just use nir_algebraic for this.  We already do
> for
> trig
> workarounds.  It's more painful from a build-system perspective but,
> in
> general, the fewer hand-rolled algebraic lowering passes we have, the
> better.
> 
> On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga  om>
> wrote:
> 
> The hardware doesn't support 16-bit integer types, so we need to
> implement
> these using 32-bit integer instructions and then convert the result
> back
> to 16-bit.
> ---
> src/intel/Makefile.sources|   1 +
> src/intel/compiler/brw_nir.c  |   2 +
> src/intel/compiler/brw_nir.h  |   2 +
> src/intel/compiler/brw_nir_lower_16bit_int_math.c | 108
> ++
> src/intel/compiler/meson.build|   1 +
> 5 files changed, 114 insertions(+)
> create mode 100644 src/intel/compiler/brw_nir_lower_16bit_int_math.c
> 
> diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
> index 91c71a8dfaf..2cd76961ea4 100644
> --- a/src/intel/Makefile.sources
> +++ b/src/intel/Makefile.sources
> @@ -79,6 +79,7 @@ COMPILER_FILES = \
> compiler/brw_nir_analyze_boolean_resolves.c \
> compiler/brw_nir_analyze_ubo_ranges.c \
> compiler/brw_nir_attribute_workarounds.c \
> +   compiler/brw_nir_lower_16bit_int_math.c \
> compiler/brw_nir_lower_cs_intrinsics.c \
> compiler/brw_nir_opt_peephole_ffma.c \
> compiler/brw_nir_tcs_workarounds.c \
> diff --git a/src/intel/compiler/brw_nir.c
> b/src/intel/compiler/brw_nir.c
> index 69ab162f888..2e5754076ed 100644
> --- a/src/intel/compiler/brw_nir.c
> +++ b/src/intel/compiler/brw_nir.c
> @@ -638,6 +638,8 @@ brw_preprocess_nir(const struct brw_compiler
> *compiler, nir_shader *nir)
> nir_lower_isign64 |
> nir_lower_divmod64);
> 
> +   brw_nir_lower_16bit_int_math(nir);
> +
> nir = brw_nir_optimize(nir, compiler, is_scalar);
> 
> if (is_scalar) {
> diff --git a/src/intel/compiler/brw_nir.h
> b/src/intel/compiler/brw_nir.h
> index 03f52da08e5..6ba1a8bc654 100644
> --- a/src/intel/compiler/brw_nir.h
> +++ b/src/intel/compiler/brw_nir.h
> @@ -152,6 +152,8 @@ void brw_nir_analyze_ubo_ranges(const struct
> brw_compiler *compiler,
> 
> bool brw_nir_opt_peephole_ffma(nir_shader *shader);
> 
> +bool brw_nir_lower_16bit_int_math(nir_shader *shader);
> +
> nir_shader *brw_nir_optimize(nir_shader *nir,
> const struct brw_compiler *compiler,
> bool is_scalar);
> diff --git a/src/intel/compiler/brw_nir_lower_16bit_int_math.c
> b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
> new file mode 100644
> index 000..6876309a822
> --- /dev/null
> +++ b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
> @@ -0,0 +1,108 @@
> +/*
> 

Re: [Mesa-dev] [PATCH] meson: Fix with_intel_vk and with_amd_vk variables

[Jordan Justen]

On 2018-04-24 22:31:23, Bas Nieuwenhuizen wrote:
> On Wed, Apr 25, 2018 at 6:38 AM, Jordan Justen
>  wrote:
> > On 2018-04-24 18:49:10, Mike Lothian wrote:
> >> Can you also add radeon to the amd one? That works on autotools
> >
> > There is already a with_gallium_radeonsi flag. Is that what you mean?
> 
> I'm guessing that he means that we currently use -Dvulkan-drivers=amd
> with meson while we use --with-vulkan-drivers=radeon on autotools.

Ah. Yeah, that does seem like a reasonable request.

> I think if we're going to change that that it should be in its own
> commit though, and not related to this fix.

I agree. It does seem like something that might require more
discussion than a bug fix.

Thanks,

-Jordan

> >
> > This is just a patch to fix the vulkan variables after 5608d0a2cee.
> > Without this change, setting -Dvulkan-drivers=intel doesn't work.
> >
> > -Jordan
> >
> >> On Wed, 25 Apr 2018 at 02:16 Jordan Justen 
> >> wrote:
> >>
> >> > Fixes: 5608d0a2cee "meson: use array type options"
> >> > Cc: Dylan Baker 
> >> > Signed-off-by: Jordan Justen 
> >> > ---
> >> >  meson.build | 4 ++--
> >> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/meson.build b/meson.build
> >> > index 52a1075823f..c0e5c94d794 100644
> >> > --- a/meson.build
> >> > +++ b/meson.build
> >> > @@ -213,8 +213,8 @@ if _vulkan_drivers.contains('auto')
> >> >endif
> >> >  endif
> >> >  if _vulkan_drivers != ['']
> >> > -  with_intel_vk = _drivers.contains('intel')
> >> > -  with_amd_vk = _drivers.contains('amd')
> >> > +  with_intel_vk = _vulkan_drivers.contains('intel')
> >> > +  with_amd_vk = _vulkan_drivers.contains('amd')
> >> >with_any_vk = true
> >> >  endif
> >> >
> >> > --
> >> > 2.16.2
> >> >
> >> > ___
> >> > mesa-dev mailing list
> >> > mesa-dev@lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Fix with_intel_vk and with_amd_vk variables

[Bas Nieuwenhuizen]

On Wed, Apr 25, 2018 at 6:38 AM, Jordan Justen
 wrote:
> On 2018-04-24 18:49:10, Mike Lothian wrote:
>> Can you also add radeon to the amd one? That works on autotools
>
> There is already a with_gallium_radeonsi flag. Is that what you mean?

I'm guessing that he means that we currently use -Dvulkan-drivers=amd
with meson while we use --with-vulkan-drivers=radeon on autotools.

I think if we're going to change that that it should be in its own
commit though, and not related to this fix.

>
> This is just a patch to fix the vulkan variables after 5608d0a2cee.
> Without this change, setting -Dvulkan-drivers=intel doesn't work.
>
> -Jordan
>
>> On Wed, 25 Apr 2018 at 02:16 Jordan Justen 
>> wrote:
>>
>> > Fixes: 5608d0a2cee "meson: use array type options"
>> > Cc: Dylan Baker 
>> > Signed-off-by: Jordan Justen 
>> > ---
>> >  meson.build | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/meson.build b/meson.build
>> > index 52a1075823f..c0e5c94d794 100644
>> > --- a/meson.build
>> > +++ b/meson.build
>> > @@ -213,8 +213,8 @@ if _vulkan_drivers.contains('auto')
>> >endif
>> >  endif
>> >  if _vulkan_drivers != ['']
>> > -  with_intel_vk = _drivers.contains('intel')
>> > -  with_amd_vk = _drivers.contains('amd')
>> > +  with_intel_vk = _vulkan_drivers.contains('intel')
>> > +  with_amd_vk = _vulkan_drivers.contains('amd')
>> >with_any_vk = true
>> >  endif
>> >
>> > --
>> > 2.16.2
>> >
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> >
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Fix with_intel_vk and with_amd_vk variables

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

On 25.04.2018 04:16, Jordan Justen wrote:

Fixes: 5608d0a2cee "meson: use array type options"
Cc: Dylan Baker 
Signed-off-by: Jordan Justen 
---
  meson.build | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meson.build b/meson.build
index 52a1075823f..c0e5c94d794 100644
--- a/meson.build
+++ b/meson.build
@@ -213,8 +213,8 @@ if _vulkan_drivers.contains('auto')
endif
  endif
  if _vulkan_drivers != ['']
-  with_intel_vk = _drivers.contains('intel')
-  with_amd_vk = _drivers.contains('amd')
+  with_intel_vk = _vulkan_drivers.contains('intel')
+  with_amd_vk = _vulkan_drivers.contains('amd')
with_any_vk = true
  endif
  


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

[Mesa-dev] [Bug 22973] Mesa3D does not support multimonitor setups correctly

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #3 from Timothy Arceri  ---
Mesa isn't where this type of thing is handled. You were probably having an
issue in X somewhere. Given the age of this bug I'm just going to close it
rather than reassigning.

-- 
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] meson: Fix with_intel_vk and with_amd_vk variables

[Jordan Justen]

On 2018-04-24 18:49:10, Mike Lothian wrote:
> Can you also add radeon to the amd one? That works on autotools

There is already a with_gallium_radeonsi flag. Is that what you mean?

This is just a patch to fix the vulkan variables after 5608d0a2cee.
Without this change, setting -Dvulkan-drivers=intel doesn't work.

-Jordan

> On Wed, 25 Apr 2018 at 02:16 Jordan Justen 
> wrote:
> 
> > Fixes: 5608d0a2cee "meson: use array type options"
> > Cc: Dylan Baker 
> > Signed-off-by: Jordan Justen 
> > ---
> >  meson.build | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/meson.build b/meson.build
> > index 52a1075823f..c0e5c94d794 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -213,8 +213,8 @@ if _vulkan_drivers.contains('auto')
> >endif
> >  endif
> >  if _vulkan_drivers != ['']
> > -  with_intel_vk = _drivers.contains('intel')
> > -  with_amd_vk = _drivers.contains('amd')
> > +  with_intel_vk = _vulkan_drivers.contains('intel')
> > +  with_amd_vk = _vulkan_drivers.contains('amd')
> >with_any_vk = true
> >  endif
> >
> > --
> > 2.16.2
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4] mesa: GL_EXT_texture_norm16 extension plumbing

[Kenneth Graunke]

On Monday, April 23, 2018 2:52:44 AM PDT Tapani Pälli wrote:
> Patch enables use of short and unsigned short data for texture uploads,
> rendering and reading of framebuffers within the restrictions specified
> in GL_EXT_texture_norm16 spec.
> 
> Patch also enables those 16bit format layout qualifiers listed in
> GL_NV_image_formats that depend on EXT_texture_norm16.
> 
> v2: expose extension with dummy_true
> fix layout qualifier map changes (Ilia Mirkin)
> 
> v3: use _mesa_has_EXT_texture_norm16, other fixes
> and cleanup (Ilia Mirkin)
> 
> v4: fix rest of the issues found
> 
> Signed-off-by: Tapani Pälli 
> Acked-by: Ilia Mirkin 

Reviewed-by: Kenneth Graunke 


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

[Mesa-dev] [Bug 104490] [radeonsi/290x] Dota2 fails to start (can't create opengl context)

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #13 from Timothy Arceri  ---
The original issue is fixed so closing.

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

Re: [Mesa-dev] [PATCH 01/11] intel/compiler: lower 16-bit integer extended math instructions

[Jason Ekstrand]

On April 24, 2018 18:38:33 Rob Clark  wrote:

On Tue, Apr 24, 2018 at 5:45 PM, Jason Ekstrand  wrote:
On Tue, Apr 24, 2018 at 7:38 AM, Rob Clark  wrote:

side-note, not sure if it really effects what you are doing here, but
karol ran into some cases, like 8bit signed imax, which needs to be
"lowered" to 16b (or 32b) and converted back for hw that doesn't
support smaller than 16b (or 32b).  I think I have the same case with
ir3, which also has 16b but no 8b, (but he is a bit further along cl
cts than I am)..

I think there will be more of this sort of thing coming for more
instructions and for more than just 16b vs 32b.  So not sure if
writing rules for each in nir_opt_algebraic.py will be so fun..


Yeah, it may be that what we want is a generic "lower this to something with
more bits" pass.  If this is a problem for the CL people, maybe we just want
some way to make it configurable and put it in core NIR.  I don't really
have a huge preference.  I'm just trying to make sure we explore the
solution space.

something generic/configurable in core nir seems more sane..

ofc, do what you need to do in the short term, I just mentioned this
to point out that more of this sort of "handle fewer bits in more
bits" stuff is coming down the pipe as we start seeing more 8b stuff..
if needed we can refactor..

Yeah, maybe the best thing to do then would be to just leave this as is and 
plan to pull it into core NIR and generalize it when the time comes.  One 
idea for generalizing would be to have a callback that returns the bit size 
to lower to or zero for "leave it alone".


I suspect we'll need more stuff like this for 8-bit integers and 16-bit 
floats.  I'll review the original for real in the morning.


--Jason


BR,
-R

--Jason


BR,
-R

On Tue, Apr 24, 2018 at 9:56 AM, Jason Ekstrand 
wrote:
It may be useful to just use nir_algebraic for this.  We already do for
trig
workarounds.  It's more painful from a build-system perspective but, in
general, the fewer hand-rolled algebraic lowering passes we have, the
better.

On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga 
wrote:

The hardware doesn't support 16-bit integer types, so we need to
implement
these using 32-bit integer instructions and then convert the result
back
to 16-bit.
---
src/intel/Makefile.sources|   1 +
src/intel/compiler/brw_nir.c  |   2 +
src/intel/compiler/brw_nir.h  |   2 +
src/intel/compiler/brw_nir_lower_16bit_int_math.c | 108
++
src/intel/compiler/meson.build|   1 +
5 files changed, 114 insertions(+)
create mode 100644 src/intel/compiler/brw_nir_lower_16bit_int_math.c

diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
index 91c71a8dfaf..2cd76961ea4 100644
--- a/src/intel/Makefile.sources
+++ b/src/intel/Makefile.sources
@@ -79,6 +79,7 @@ COMPILER_FILES = \
compiler/brw_nir_analyze_boolean_resolves.c \
compiler/brw_nir_analyze_ubo_ranges.c \
compiler/brw_nir_attribute_workarounds.c \
+   compiler/brw_nir_lower_16bit_int_math.c \
compiler/brw_nir_lower_cs_intrinsics.c \
compiler/brw_nir_opt_peephole_ffma.c \
compiler/brw_nir_tcs_workarounds.c \
diff --git a/src/intel/compiler/brw_nir.c
b/src/intel/compiler/brw_nir.c
index 69ab162f888..2e5754076ed 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -638,6 +638,8 @@ brw_preprocess_nir(const struct brw_compiler
*compiler, nir_shader *nir)
nir_lower_isign64 |
nir_lower_divmod64);

+   brw_nir_lower_16bit_int_math(nir);
+
nir = brw_nir_optimize(nir, compiler, is_scalar);

if (is_scalar) {
diff --git a/src/intel/compiler/brw_nir.h
b/src/intel/compiler/brw_nir.h
index 03f52da08e5..6ba1a8bc654 100644
--- a/src/intel/compiler/brw_nir.h
+++ b/src/intel/compiler/brw_nir.h
@@ -152,6 +152,8 @@ void brw_nir_analyze_ubo_ranges(const struct
brw_compiler *compiler,

bool brw_nir_opt_peephole_ffma(nir_shader *shader);

+bool brw_nir_lower_16bit_int_math(nir_shader *shader);
+
nir_shader *brw_nir_optimize(nir_shader *nir,
const struct brw_compiler *compiler,
bool is_scalar);
diff --git a/src/intel/compiler/brw_nir_lower_16bit_int_math.c
b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
new file mode 100644
index 000..6876309a822
--- /dev/null
+++ b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
@@ -0,0 +1,108 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person
obtaining
a
+ * copy of this software and associated documentation files (the
"Software"),
+ * to deal in the Software without restriction, including without
limitation
+ * the rights to use, copy, modify, merge, publish, distribute,
sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom
the
+ * Software is furnished to do so, subject to the following
conditions:
+ *
+ * The above copyright 

Re: [Mesa-dev] [PATCH] meson: Fix with_intel_vk and with_amd_vk variables

[Mike Lothian]

Can you also add radeon to the amd one? That works on autotools

On Wed, 25 Apr 2018 at 02:16 Jordan Justen 
wrote:

> Fixes: 5608d0a2cee "meson: use array type options"
> Cc: Dylan Baker 
> Signed-off-by: Jordan Justen 
> ---
>  meson.build | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 52a1075823f..c0e5c94d794 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -213,8 +213,8 @@ if _vulkan_drivers.contains('auto')
>endif
>  endif
>  if _vulkan_drivers != ['']
> -  with_intel_vk = _drivers.contains('intel')
> -  with_amd_vk = _drivers.contains('amd')
> +  with_intel_vk = _vulkan_drivers.contains('intel')
> +  with_amd_vk = _vulkan_drivers.contains('amd')
>with_any_vk = true
>  endif
>
> --
> 2.16.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106209] [opencl] [llvm-svn] build failure undefined reference to `clang::FrontendTimesIsEnabled'

[bugzilla-daemon]

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

--- Comment #3 from Jan Vesely  ---
Looks like we don't link to libclangFrontend, which is required since r330571.
This should, however, be handled by llvm/clang when listing libraries required
for components.

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

[Mesa-dev] [PATCH] meson: Fix with_intel_vk and with_amd_vk variables

[Jordan Justen]

Fixes: 5608d0a2cee "meson: use array type options"
Cc: Dylan Baker 
Signed-off-by: Jordan Justen 
---
 meson.build | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meson.build b/meson.build
index 52a1075823f..c0e5c94d794 100644
--- a/meson.build
+++ b/meson.build
@@ -213,8 +213,8 @@ if _vulkan_drivers.contains('auto')
   endif
 endif
 if _vulkan_drivers != ['']
-  with_intel_vk = _drivers.contains('intel')
-  with_amd_vk = _drivers.contains('amd')
+  with_intel_vk = _vulkan_drivers.contains('intel')
+  with_amd_vk = _vulkan_drivers.contains('amd')
   with_any_vk = true
 endif
 
-- 
2.16.2

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

Re: [Mesa-dev] [PATCH] st/va: Fix potential buffer overread

[Leo Liu]

On 2018-04-24 07:01 PM, Drew Davenport wrote:

VASurfaceAttribExternalBuffers.pitches is indexed by
plane. Current implementation only supports single plane layout.

Reviewed-by: Leo Liu 


---
  src/gallium/state_trackers/va/surface.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index 8604136944..6fe21b89e5 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -574,7 +574,7 @@ suface_from_external_memory(VADriverContextP ctx, 
vlVaSurface *surface,
 memset(, 0, sizeof(struct winsys_handle));
 whandle.type = DRM_API_HANDLE_TYPE_FD;
 whandle.handle = memory_attibute->buffers[index];
-   whandle.stride = memory_attibute->pitches[index];
+   whandle.stride = memory_attibute->pitches[0];
  
 resource = pscreen->resource_from_handle(pscreen, _templ, ,

  PIPE_HANDLE_USAGE_READ_WRITE);


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

[Mesa-dev] [PATCH v2 5/5] i965/clear: Drop a stale comment in fast_clear_depth

[Nanley Chery]

This comment made more sense when it was above the calls to
intel_miptree_slice_set_needs_depth_resolve(). We stopped using these
functions at commit 554f7d6d02931ea45653c8872565d21c1678a6da
("i965: Move depth to the new resolve functions").
---
 src/mesa/drivers/dri/i965/brw_clear.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index e372d28926e..fda53326228 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -240,13 +240,9 @@ brw_fast_clear_depth(struct gl_context *ctx)
   }
}
 
-   /* Now, the HiZ buffer contains data that needs to be resolved to the depth
-* buffer.
-*/
intel_miptree_set_aux_state(brw, mt, depth_irb->mt_level,
depth_irb->mt_layer, num_layers,
ISL_AUX_STATE_CLEAR);
-
return true;
 }
 
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 2/5] i965/blorp: Also skip the fast clear if the clear color differs

[Nanley Chery]

If the aux state is CLEAR and clear color value has changed, only the
surface state must be updated. The bit-pattern in the aux buffer is
exactly the same.

v2: Handle the indirect color on gen10+.

Reviewed-by: Rafael Antognolli 
Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index ba14136edc6..690427421cb 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1230,11 +1230,14 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
   bool same_clear_color =
  !intel_miptree_set_clear_color(brw, irb->mt, >Color.ClearColor);
 
-  /* If the buffer is already in INTEL_FAST_CLEAR_STATE_CLEAR, the clear
+  /* If the buffer is already in ISL_AUX_STATE_CLEAR, the clear
* is redundant and can be skipped.
*/
-  if (aux_state == ISL_AUX_STATE_CLEAR && same_clear_color)
+  if (aux_state == ISL_AUX_STATE_CLEAR) {
+ if (!same_clear_color)
+intel_miptree_update_indirect_color(brw, irb->mt);
  return;
+  }
 
   DBG("%s (fast) to mt %p level %d layers %d+%d\n", __FUNCTION__,
   irb->mt, irb->mt_level, irb->mt_layer, num_layers);
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 4/5] i965/clear: Simplify updating the indirect depth value

[Nanley Chery]

Determine the predicate for updating the indirect depth value in the
loop which inspects whether or not we need to resolve any slices.
---
 src/mesa/drivers/dri/i965/brw_clear.c | 43 +--
 1 file changed, 16 insertions(+), 27 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 6521141d7f6..e372d28926e 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -108,7 +108,6 @@ brw_fast_clear_depth(struct gl_context *ctx)
struct intel_mipmap_tree *mt = depth_irb->mt;
struct gl_renderbuffer_attachment *depth_att = 
>Attachment[BUFFER_DEPTH];
const struct gen_device_info *devinfo = >screen->devinfo;
-   bool same_clear_value = true;
 
if (devinfo->gen < 6)
   return false;
@@ -174,9 +173,16 @@ brw_fast_clear_depth(struct gl_context *ctx)
const uint32_t num_layers = depth_att->Layered ? depth_irb->layer_count : 1;
 
/* If we're clearing to a new clear value, then we need to resolve any clear
-* flags out of the HiZ buffer into the real depth buffer.
+* flags out of the HiZ buffer into the real depth buffer and update the
+* miptree's clear value.
 */
if (mt->fast_clear_color.f32[0] != clear_value) {
+  /* BLORP updates the indirect clear color buffer when we do fast clears.
+   * If we won't do a fast clear, we'll have to update it ourselves. Start
+   * off assuming we won't perform a fast clear.
+   */
+  bool blorp_will_update_indirect_color = false;
+
   for (uint32_t level = mt->first_level; level <= mt->last_level; level++) 
{
  if (!intel_miptree_level_has_hiz(mt, level))
 continue;
@@ -184,16 +190,20 @@ brw_fast_clear_depth(struct gl_context *ctx)
  const unsigned level_layers = brw_get_num_logical_layers(mt, level);
 
  for (uint32_t layer = 0; layer < level_layers; layer++) {
+const enum isl_aux_state aux_state =
+   intel_miptree_get_aux_state(mt, level, layer);
+
 if (level == depth_irb->mt_level &&
 layer >= depth_irb->mt_layer &&
 layer < depth_irb->mt_layer + num_layers) {
+
+   if (aux_state != ISL_AUX_STATE_CLEAR)
+  blorp_will_update_indirect_color = true;
+
/* We're going to clear this layer anyway.  Leave it alone. */
continue;
 }
 
-enum isl_aux_state aux_state =
-   intel_miptree_get_aux_state(mt, level, layer);
-
 if (aux_state != ISL_AUX_STATE_CLEAR &&
 aux_state != ISL_AUX_STATE_COMPRESSED_CLEAR) {
/* This slice doesn't have any fast-cleared bits. */
@@ -214,29 +224,8 @@ brw_fast_clear_depth(struct gl_context *ctx)
   }
 
   intel_miptree_set_depth_clear_value(brw, mt, clear_value);
-  same_clear_value = false;
-   }
-
-   bool need_clear = false;
-   for (unsigned a = 0; a < num_layers; a++) {
-  enum isl_aux_state aux_state =
- intel_miptree_get_aux_state(mt, depth_irb->mt_level,
- depth_irb->mt_layer + a);
-
-  if (aux_state != ISL_AUX_STATE_CLEAR) {
- need_clear = true;
- break;
-  }
-   }
-
-   if (!need_clear) {
-  if (!same_clear_value) {
- /* BLORP updates the indirect clear color buffer when performing a
-  * fast clear. Since we are skipping the fast clear here, we need to
-  * do the update ourselves.
-  */
+  if (!blorp_will_update_indirect_color)
  intel_miptree_update_indirect_color(brw, mt);
-  }
}
 
for (unsigned a = 0; a < num_layers; a++) {
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 1/5] i965: Add and use a helper to update the indirect miptree color

[Nanley Chery]

Split out this functionality to enable a fast-clear optimization for
color miptrees in the next commit.

v2: Avoid the additional refactor (Jason).
---
 src/mesa/drivers/dri/i965/brw_clear.c | 23 +--
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 22 ++
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  7 +++
 3 files changed, 34 insertions(+), 18 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 3d540d6d905..fdc31cd9b68 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -234,25 +234,12 @@ brw_fast_clear_depth(struct gl_context *ctx)
* state then simply updating the miptree fast clear value is sufficient
* to change their clear value.
*/
-  if (devinfo->gen >= 10 && !same_clear_value) {
- /* Before gen10, it was enough to just update the clear value in the
-  * miptree. But on gen10+, we let blorp update the clear value state
-  * buffer when doing a fast clear. Since we are skipping the fast
-  * clear here, we need to update the clear color ourselves.
+  if (!same_clear_value) {
+ /* BLORP updates the indirect clear color buffer when performing a
+  * fast clear. Since we are skipping the fast clear here, we need to
+  * do the update ourselves.
   */
- uint32_t clear_offset = mt->aux_buf->clear_color_offset;
- union isl_color_value clear_color = { .f32 = { clear_value, } };
-
- /* We can't update the clear color while the hardware is still using
-  * the previous one for a resolve or sampling from it. So make sure
-  * that there's no pending commands at this point.
-  */
- brw_emit_pipe_control_flush(brw, PIPE_CONTROL_CS_STALL);
- for (int i = 0; i < 4; i++) {
-brw_store_data_imm32(brw, mt->aux_buf->clear_color_bo,
- clear_offset + i * 4, clear_color.u32[i]);
- }
- brw_emit_pipe_control_flush(brw, PIPE_CONTROL_STATE_CACHE_INVALIDATE);
+ intel_miptree_update_indirect_color(brw, mt);
   }
   return true;
}
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 93a91fd8081..1006635c0d7 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -3837,3 +3837,25 @@ intel_miptree_get_clear_color(const struct 
gen_device_info *devinfo,
   return mt->fast_clear_color;
}
 }
+
+void
+intel_miptree_update_indirect_color(struct brw_context *brw,
+struct intel_mipmap_tree *mt)
+{
+   assert(mt->aux_buf);
+
+   if (mt->aux_buf->clear_color_bo == NULL)
+  return;
+
+   /* We can't update the clear color while the hardware is still using the
+* previous one for a resolve or sampling from it. Make sure that there are
+* no pending commands at this point.
+*/
+   brw_emit_pipe_control_flush(brw, PIPE_CONTROL_CS_STALL);
+   for (int i = 0; i < 4; i++) {
+  brw_store_data_imm32(brw, mt->aux_buf->clear_color_bo,
+   mt->aux_buf->clear_color_offset + i * 4,
+   mt->fast_clear_color.u32[i]);
+   }
+   brw_emit_pipe_control_flush(brw, PIPE_CONTROL_STATE_CACHE_INVALIDATE);
+}
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index e99ea44b809..1c2361c1cb0 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -749,6 +749,13 @@ intel_miptree_set_depth_clear_value(struct brw_context 
*brw,
 struct intel_mipmap_tree *mt,
 float clear_value);
 
+/* If this miptree has an indirect clear color, update it with the value stored
+ * in the miptree object.
+ */
+void
+intel_miptree_update_indirect_color(struct brw_context *brw,
+struct intel_mipmap_tree *mt);
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 3/5] i965/clear: Remove an early return in fast_clear_depth

[Nanley Chery]

Reduce complexity and allow the next patch to delete some code. With
this change, clear operations will still be skipped and setting the
aux_state will cause no side-effects.

Remove the associated comment which implies an early return.
---
 src/mesa/drivers/dri/i965/brw_clear.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index fdc31cd9b68..6521141d7f6 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -230,10 +230,6 @@ brw_fast_clear_depth(struct gl_context *ctx)
}
 
if (!need_clear) {
-  /* If all of the layers we intend to clear are already in the clear
-   * state then simply updating the miptree fast clear value is sufficient
-   * to change their clear value.
-   */
   if (!same_clear_value) {
  /* BLORP updates the indirect clear color buffer when performing a
   * fast clear. Since we are skipping the fast clear here, we need to
@@ -241,7 +237,6 @@ brw_fast_clear_depth(struct gl_context *ctx)
   */
  intel_miptree_update_indirect_color(brw, mt);
   }
-  return true;
}
 
for (unsigned a = 0; a < num_layers; a++) {
-- 
2.16.2

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

Re: [Mesa-dev] [PATCH] Intel: Add a Kaby Lake PCI ID

[Rafael Antognolli]

On Mon, Apr 23, 2018 at 03:05:27PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> Signed-off-by: Matt Atwood 
> ---
>  include/pci_ids/i965_pci_ids.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
> index c740a50..6cbc32e 100644
> --- a/include/pci_ids/i965_pci_ids.h
> +++ b/include/pci_ids/i965_pci_ids.h
> @@ -156,6 +156,7 @@ CHIPSET(0x5912, kbl_gt2, "Intel(R) HD Graphics 630 (Kaby 
> Lake GT2)")
>  CHIPSET(0x5916, kbl_gt2, "Intel(R) HD Graphics 620 (Kaby Lake GT2)")
>  CHIPSET(0x591A, kbl_gt2, "Intel(R) HD Graphics P630 (Kaby Lake GT2)")
>  CHIPSET(0x591B, kbl_gt2, "Intel(R) HD Graphics 630 (Kaby Lake GT2)")
> +CHIPSET(0x591C, kbl_gt2, "Intel(R) HD Graphics (Kaby Lake GT2)")

The PCI ID matches the one in the kernel and docs.

However, since we don't have the brand strings yet, maybe we should just
call it:

"Intel(R) KabyLake GT2"

like the other ones that also don't have it? Hopefully with that, it
will be easier to spot it when we need to update the name.

>  CHIPSET(0x591D, kbl_gt2, "Intel(R) HD Graphics P630 (Kaby Lake GT2)")
>  CHIPSET(0x591E, kbl_gt2, "Intel(R) HD Graphics 615 (Kaby Lake GT2)")
>  CHIPSET(0x5921, kbl_gt2, "Intel(R) Kabylake GT2F")
> -- 
> 2.7.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 99116] Wine DirectDraw programs showing only a blackscreen when using Mesa Gallium drivers

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #19 from Timothy Arceri  ---
Should be fixed by:

commit 6695f9d5c5c94df080efc720ed532217618a28c3
Author: Boyan Ding 
Date:   Sat Apr 14 14:45:23 2018 +1000

mesa: call DrawBufferAllocate driver hook in update_framebuffer for
windows-system FB

When draw buffers are changed on a bound framebuffer, DrawBufferAllocate()
hook should be called. However, it is missing in update_framebuffer with
window-system framebuffer, in which FB's draw buffer state should match
context state, potentially resulting in a change.

Note: This is needed because gallium delays creating the front buffer,
  i965 works fine without this change.

V2 (Timothy Arceri):
 - Rebased on merged/simplified DrawBuffer driver function
 - Move DrawBuffer call outside fb->ColorDrawBuffer[0] !=
   ctx->Color.DrawBuffer[0] check to make piglit pass.

v3 (Timothy Arceri):
 - Call new DrawBuffaerAllocate() driver function.

Tested-by: Dieter Nützel  (v2)
Reviewed-by: Brian Paul  (v2)
Reviewed-by: Marek Olšák 
Reviewed-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99116

-- 
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] st/va: Fix potential buffer overread

[Kristian Høgsberg]

On Tue, Apr 24, 2018 at 4:02 PM Drew Davenport 
wrote:

> VASurfaceAttribExternalBuffers.pitches is indexed by
> plane. Current implementation only supports single plane layout.

Reviewed-by: Kristian H. Kristensen 

> ---
>   src/gallium/state_trackers/va/surface.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/surface.c
> index 8604136944..6fe21b89e5 100644
> --- a/src/gallium/state_trackers/va/surface.c
> +++ b/src/gallium/state_trackers/va/surface.c
> @@ -574,7 +574,7 @@ suface_from_external_memory(VADriverContextP ctx,
vlVaSurface *surface,
>  memset(, 0, sizeof(struct winsys_handle));
>  whandle.type = DRM_API_HANDLE_TYPE_FD;
>  whandle.handle = memory_attibute->buffers[index];
> -   whandle.stride = memory_attibute->pitches[index];
> +   whandle.stride = memory_attibute->pitches[0];

>  resource = pscreen->resource_from_handle(pscreen, _templ,
,

  PIPE_HANDLE_USAGE_READ_WRITE);
> --
> 2.17.0.441.gb46fe60e1d-goog

> ___
> 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] st/va: Fix potential buffer overread

[Drew Davenport]

VASurfaceAttribExternalBuffers.pitches is indexed by
plane. Current implementation only supports single plane layout.
---
 src/gallium/state_trackers/va/surface.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index 8604136944..6fe21b89e5 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -574,7 +574,7 @@ suface_from_external_memory(VADriverContextP ctx, 
vlVaSurface *surface,
memset(, 0, sizeof(struct winsys_handle));
whandle.type = DRM_API_HANDLE_TYPE_FD;
whandle.handle = memory_attibute->buffers[index];
-   whandle.stride = memory_attibute->pitches[index];
+   whandle.stride = memory_attibute->pitches[0];
 
resource = pscreen->resource_from_handle(pscreen, _templ, ,
 PIPE_HANDLE_USAGE_READ_WRITE);
-- 
2.17.0.441.gb46fe60e1d-goog

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

Re: [Mesa-dev] [PATCH 1/3] mesa: merge the driver functions DrawBuffers and DrawBuffer

[Timothy Arceri]

On 25/04/18 07:34, Ian Romanick wrote:

On 04/24/2018 09:28 AM, Ian Romanick wrote:

On 04/23/2018 08:23 PM, Timothy Arceri wrote:

On 24/04/18 10:13, Dieter Nützel wrote:

Hello Timo,

what about 2 and 3, #1 landed.


It turns out the old radeon classic drivers do make use of the param
dropped in patch 2 so I've decided to drop that patch, although the use
of that param might be a bug as the intel drivers changed their behavior
to fix a bug (however it's not a simple change).


This sounds familiar, and I might have a patch for that.  Let me root
around in my git branches to see if I can find it...  I'm definitely in
favor of cleaning up a bunch of the dd interfaces.


I sent these to the list in September 2015:

https://patchwork.freedesktop.org/patch/60786/
https://patchwork.freedesktop.org/patch/60794/


For those two patches:

Acked-by: Timothy Arceri 



I don't recall what testing I did exactly, and I didn't put anything
useful in the commit message. :(


I'd still like to push patch 3 but it's tripping up some old hardware in
Intels CI system. I'm not sure whats going on yet.


Dieter

___
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] radeon/vcn: fix mpeg4 msg buffer settings

[Leo Liu]

Reviewed-by: Leo Liu 

And Cc Mesa-stable as well.


On 2018-04-24 04:49 PM, boyuan.zh...@amd.com wrote:

From: Boyuan Zhang 

Previous bit-fields assignments are incorrect and will result certain mpeg4
decode failed due to wrong flag values. This patch fixes these assignments.

Signed-off-by: Boyuan Zhang 
---
  src/gallium/drivers/radeon/radeon_vcn_dec.c | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c 
b/src/gallium/drivers/radeon/radeon_vcn_dec.c
index f83e9e5..4bc922d 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_dec.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_dec.c
@@ -554,15 +554,15 @@ static rvcn_dec_message_mpeg4_asp_vld_t 
get_mpeg4_msg(struct radeon_decoder *dec
  
  	result.vop_time_increment_resolution = pic->vop_time_increment_resolution;
  
-	result.short_video_header |= pic->short_video_header << 0;

-   result.interlaced |= pic->interlaced << 2;
-result.load_intra_quant_mat |= 1 << 3;
-   result.load_nonintra_quant_mat |= 1 << 4;
-   result.quarter_sample |= pic->quarter_sample << 5;
-   result.complexity_estimation_disable |= 1 << 6;
-   result.resync_marker_disable |= pic->resync_marker_disable << 7;
-   result.newpred_enable |= 0 << 10; //
-   result.reduced_resolution_vop_enable |= 0 << 11;
+   result.short_video_header = pic->short_video_header;
+   result.interlaced = pic->interlaced;
+   result.load_intra_quant_mat = 1;
+   result.load_nonintra_quant_mat = 1;
+   result.quarter_sample = pic->quarter_sample;
+   result.complexity_estimation_disable = 1;
+   result.resync_marker_disable = pic->resync_marker_disable;
+   result.newpred_enable = 0;
+   result.reduced_resolution_vop_enable = 0;
  
  	result.quant_type = pic->quant_type;
  


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

Re: [Mesa-dev] [PATCH 01/11] intel/compiler: lower 16-bit integer extended math instructions

[Rob Clark]

On Tue, Apr 24, 2018 at 5:45 PM, Jason Ekstrand  wrote:
> On Tue, Apr 24, 2018 at 7:38 AM, Rob Clark  wrote:
>>
>> side-note, not sure if it really effects what you are doing here, but
>> karol ran into some cases, like 8bit signed imax, which needs to be
>> "lowered" to 16b (or 32b) and converted back for hw that doesn't
>> support smaller than 16b (or 32b).  I think I have the same case with
>> ir3, which also has 16b but no 8b, (but he is a bit further along cl
>> cts than I am)..
>>
>> I think there will be more of this sort of thing coming for more
>> instructions and for more than just 16b vs 32b.  So not sure if
>> writing rules for each in nir_opt_algebraic.py will be so fun..
>
>
> Yeah, it may be that what we want is a generic "lower this to something with
> more bits" pass.  If this is a problem for the CL people, maybe we just want
> some way to make it configurable and put it in core NIR.  I don't really
> have a huge preference.  I'm just trying to make sure we explore the
> solution space.
>

something generic/configurable in core nir seems more sane..

ofc, do what you need to do in the short term, I just mentioned this
to point out that more of this sort of "handle fewer bits in more
bits" stuff is coming down the pipe as we start seeing more 8b stuff..
if needed we can refactor..

BR,
-R

> --Jason
>
>
>> BR,
>> -R
>>
>> On Tue, Apr 24, 2018 at 9:56 AM, Jason Ekstrand 
>> wrote:
>> > It may be useful to just use nir_algebraic for this.  We already do for
>> > trig
>> > workarounds.  It's more painful from a build-system perspective but, in
>> > general, the fewer hand-rolled algebraic lowering passes we have, the
>> > better.
>> >
>> > On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga 
>> > wrote:
>> >>
>> >> The hardware doesn't support 16-bit integer types, so we need to
>> >> implement
>> >> these using 32-bit integer instructions and then convert the result
>> >> back
>> >> to 16-bit.
>> >> ---
>> >>  src/intel/Makefile.sources|   1 +
>> >>  src/intel/compiler/brw_nir.c  |   2 +
>> >>  src/intel/compiler/brw_nir.h  |   2 +
>> >>  src/intel/compiler/brw_nir_lower_16bit_int_math.c | 108
>> >> ++
>> >>  src/intel/compiler/meson.build|   1 +
>> >>  5 files changed, 114 insertions(+)
>> >>  create mode 100644 src/intel/compiler/brw_nir_lower_16bit_int_math.c
>> >>
>> >> diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
>> >> index 91c71a8dfaf..2cd76961ea4 100644
>> >> --- a/src/intel/Makefile.sources
>> >> +++ b/src/intel/Makefile.sources
>> >> @@ -79,6 +79,7 @@ COMPILER_FILES = \
>> >> compiler/brw_nir_analyze_boolean_resolves.c \
>> >> compiler/brw_nir_analyze_ubo_ranges.c \
>> >> compiler/brw_nir_attribute_workarounds.c \
>> >> +   compiler/brw_nir_lower_16bit_int_math.c \
>> >> compiler/brw_nir_lower_cs_intrinsics.c \
>> >> compiler/brw_nir_opt_peephole_ffma.c \
>> >> compiler/brw_nir_tcs_workarounds.c \
>> >> diff --git a/src/intel/compiler/brw_nir.c
>> >> b/src/intel/compiler/brw_nir.c
>> >> index 69ab162f888..2e5754076ed 100644
>> >> --- a/src/intel/compiler/brw_nir.c
>> >> +++ b/src/intel/compiler/brw_nir.c
>> >> @@ -638,6 +638,8 @@ brw_preprocess_nir(const struct brw_compiler
>> >> *compiler, nir_shader *nir)
>> >>  nir_lower_isign64 |
>> >>  nir_lower_divmod64);
>> >>
>> >> +   brw_nir_lower_16bit_int_math(nir);
>> >> +
>> >> nir = brw_nir_optimize(nir, compiler, is_scalar);
>> >>
>> >> if (is_scalar) {
>> >> diff --git a/src/intel/compiler/brw_nir.h
>> >> b/src/intel/compiler/brw_nir.h
>> >> index 03f52da08e5..6ba1a8bc654 100644
>> >> --- a/src/intel/compiler/brw_nir.h
>> >> +++ b/src/intel/compiler/brw_nir.h
>> >> @@ -152,6 +152,8 @@ void brw_nir_analyze_ubo_ranges(const struct
>> >> brw_compiler *compiler,
>> >>
>> >>  bool brw_nir_opt_peephole_ffma(nir_shader *shader);
>> >>
>> >> +bool brw_nir_lower_16bit_int_math(nir_shader *shader);
>> >> +
>> >>  nir_shader *brw_nir_optimize(nir_shader *nir,
>> >>   const struct brw_compiler *compiler,
>> >>   bool is_scalar);
>> >> diff --git a/src/intel/compiler/brw_nir_lower_16bit_int_math.c
>> >> b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
>> >> new file mode 100644
>> >> index 000..6876309a822
>> >> --- /dev/null
>> >> +++ b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
>> >> @@ -0,0 +1,108 @@
>> >> +/*
>> >> + * Copyright © 2018 Intel Corporation
>> >> + *
>> >> + * Permission is hereby granted, free of charge, to any person
>> >> obtaining
>> >> a
>> >> + * copy of this software and associated documentation files (the
>> >> "Software"),
>> >> + * to deal in the Software without restriction, including without
>> >> limitation
>> >> + * the 

Re: [Mesa-dev] [PATCH 3/3] mesa: call DrawBufferAllocate driver hook in update_framebuffer for windows-system FB

[Marek Olšák]

For the series:

Reviewed-by: Marek Olšák 

Marek

On Tue, Apr 24, 2018 at 12:54 AM, Timothy Arceri 
wrote:

> From: Boyan Ding 
>
> When draw buffers are changed on a bound framebuffer, DrawBufferAllocate()
> hook should be called. However, it is missing in update_framebuffer with
> window-system framebuffer, in which FB's draw buffer state should match
> context state, potentially resulting in a change.
>
> Note: This is needed because gallium delays creating the front buffer,
>   i965 works fine without this change.
>
> V2 (Timothy Arceri):
>  - Rebased on merged/simplified DrawBuffer driver function
>  - Move DrawBuffer call outside fb->ColorDrawBuffer[0] !=
>ctx->Color.DrawBuffer[0] check to make piglit pass.
>
> v3 (Timothy Arceri):
>  - Call new DrawBuffaerAllocate() driver function.
>
> Tested-by: Dieter Nützel  (v2)
> Reviewed-by: Brian Paul  (v2)
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99116
> ---
>  src/mesa/main/framebuffer.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
> index 211e97c33bd..4ea18f6858e 100644
> --- a/src/mesa/main/framebuffer.c
> +++ b/src/mesa/main/framebuffer.c
> @@ -617,6 +617,12 @@ update_framebuffer(struct gl_context *ctx, struct
> gl_framebuffer *fb)
>   _mesa_drawbuffers(ctx, fb, ctx->Const.MaxDrawBuffers,
> ctx->Color.DrawBuffer, NULL);
>}
> +
> +  /* Call device driver function if fb is the bound draw buffer. */
> +  if (fb == ctx->DrawBuffer) {
> + if (ctx->Driver.DrawBufferAllocate)
> +ctx->Driver.DrawBufferAllocate(ctx);
> +  }
> }
> else {
>/* This is a user-created framebuffer.
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/dri: constify dri_fill_st_visual's screen

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Tue, Apr 24, 2018 at 1:48 PM, Emil Velikov 
wrote:

> From: Emil Velikov 
>
> As the function says - only the visual is changed.
>
> Signed-off-by: Emil Velikov 
> ---
>  src/gallium/state_trackers/dri/dri_screen.c | 3 ++-
>  src/gallium/state_trackers/dri/dri_screen.h | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/dri/dri_screen.c
> b/src/gallium/state_trackers/dri/dri_screen.c
> index aaee987077..374efbdf61 100644
> --- a/src/gallium/state_trackers/dri/dri_screen.c
> +++ b/src/gallium/state_trackers/dri/dri_screen.c
> @@ -298,7 +298,8 @@ dri_fill_in_modes(struct dri_screen *screen)
>   * Roughly the converse of dri_fill_in_modes.
>   */
>  void
> -dri_fill_st_visual(struct st_visual *stvis, struct dri_screen *screen,
> +dri_fill_st_visual(struct st_visual *stvis,
> +   const struct dri_screen *screen,
> const struct gl_config *mode)
>  {
> memset(stvis, 0, sizeof(*stvis));
> diff --git a/src/gallium/state_trackers/dri/dri_screen.h
> b/src/gallium/state_trackers/dri/dri_screen.h
> index 677e945e03..e410aa9c2f 100644
> --- a/src/gallium/state_trackers/dri/dri_screen.h
> +++ b/src/gallium/state_trackers/dri/dri_screen.h
> @@ -127,7 +127,8 @@ dri_with_format(__DRIscreen * sPriv)
>  }
>
>  void
> -dri_fill_st_visual(struct st_visual *stvis, struct dri_screen *screen,
> +dri_fill_st_visual(struct st_visual *stvis,
> +   const struct dri_screen *screen,
> const struct gl_config *mode);
>
>  void
> --
> 2.16.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Fix no-rtti in llvm detection

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Tue, Apr 24, 2018 at 5:16 PM, Dylan Baker  wrote:

> Because I clearly wasn't thinking and clearly didn't do a good job
> testing. Sigh
>
> Fixes: c5a97d658ec19cc02719d7f86c1b0715e3d9ffc4
>("meson: fix builds against LLVM built without rtti")
> Signed-off-by: Dylan Baker 
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index 590ac40a781..52a1075823f 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1149,7 +1149,7 @@ if with_llvm
># programs, so we need to build all C++ code in mesa without rtti as
> well to
># ensure that linking works.
>if dep_llvm.get_configtool_variable('has-rtti') == 'NO'
> -cpp_args('-fno-rtti')
> +cpp_args += '-fno-rtti'
>endif
>  elif with_amd_vk or with_gallium_radeonsi or with_gallium_swr
>error('The following drivers require LLVM: Radv, RadeonSI, SWR. One of
> these is enabled, but LLVM is disabled.')
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 0/6] broadcom/vc4: Native fence fd support

[Stefan Schake]

On Wed, Apr 25, 2018 at 12:00 AM, Stefan Schake  wrote:
> v2 drops the submit flags, directly moves in fence handling to the
> job submit function and queries for the syncobj cap instead of using
> a separate support parameter.
>
> This series adds support for the native fence fd extension to vc4.
> The implementation relies on a newly introduced kernel interface that
> allows submitting syncobjs for in/out fences during job submission.
>
> Since syncobjs are relatively new, patches 1 and 3 have build changes
> for automake and meson to require a recent libdrm version.
>
> There is some scope here to replace the previous sequence number based
> implementation with only syncobjs, but given that we need to continue
> supporting older kernels I felt it would have only added complexity.
>
> This has been tested with piglit and kmscube -A(tomic). In particular,
> I checked that the fd numbers weren't increasing during the kmscube run.
>
> Should not be merged until the kernel side lands. In particular, patch 2
> is purely provisional.
>
> Stefan Schake (6):
>   broadcom/vc4: Drop libdrm_vc4 requirement
>   drm-uapi: Update vc4 header with syncobj submit support
>   broadcom/vc4: Bump libdrm requirement
>   broadcom/vc4: Detect syncobj support
>   broadcom/vc4: Store job fence in syncobj
>   broadcom/vc4: Native fence fd support
>
>  configure.ac  |  3 +-
>  include/drm-uapi/vc4_drm.h| 13 +--
>  meson.build   |  2 +
>  src/gallium/drivers/vc4/vc4_context.c | 29 +--
>  src/gallium/drivers/vc4/vc4_context.h | 10 -
>  src/gallium/drivers/vc4/vc4_fence.c   | 70 
> +--
>  src/gallium/drivers/vc4/vc4_job.c | 34 -
>  src/gallium/drivers/vc4/vc4_screen.c  | 12 +-
>  src/gallium/drivers/vc4/vc4_screen.h  |  5 ++-
>  9 files changed, 160 insertions(+), 18 deletions(-)
>
> --
> 2.7.4
>

Kernel v2 is here:

https://patchwork.freedesktop.org/series/42082/

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

[Mesa-dev] [PATCH v2 3/6] broadcom/vc4: Bump libdrm requirement

[Stefan Schake]

Require a version of libdrm with syncobj support. In the meson build,
this currently introduces a requirement on libdrm_vc4 which we technically
no longer need for vc4.

Signed-off-by: Stefan Schake 
---
 configure.ac | 2 ++
 meson.build  | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/configure.ac b/configure.ac
index 9a38471..9658bc0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -80,6 +80,7 @@ LIBDRM_NVVIEUX_REQUIRED=2.4.66
 LIBDRM_NOUVEAU_REQUIRED=2.4.66
 LIBDRM_FREEDRENO_REQUIRED=2.4.91
 LIBDRM_ETNAVIV_REQUIRED=2.4.89
+LIBDRM_VC4_REQUIRED=2.4.89
 
 dnl Versions for external dependencies
 DRI2PROTO_REQUIRED=2.8
@@ -2714,6 +2715,7 @@ if test -n "$with_gallium_drivers"; then
 ;;
 xvc4)
 HAVE_GALLIUM_VC4=yes
+PKG_CHECK_MODULES([VC4], [libdrm >= $LIBDRM_VC4_REQUIRED])
 
 PKG_CHECK_MODULES([SIMPENROSE], [simpenrose],
   [USE_VC4_SIMULATOR=yes;
diff --git a/meson.build b/meson.build
index 9dc6843..2f3046e 100644
--- a/meson.build
+++ b/meson.build
@@ -1040,6 +1040,7 @@ _drm_nouveau_ver = '2.4.66'
 _drm_etnaviv_ver = '2.4.89'
 _drm_freedreno_ver = '2.4.91'
 _drm_intel_ver = '2.4.75'
+_drm_vc4_ver = '2.4.89'
 _drm_ver = '2.4.75'
 
 _libdrm_checks = [
@@ -1050,6 +1051,7 @@ _libdrm_checks = [
   ['nouveau', (with_gallium_nouveau or with_dri_nouveau)],
   ['etnaviv', with_gallium_etnaviv],
   ['freedreno', with_gallium_freedreno],
+  ['vc4', with_gallium_vc4]
 ]
 
 # Loop over the enables versions and get the highest libdrm requirement for all
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 5/6] broadcom/vc4: Store job fence in syncobj

[Stefan Schake]

This gives us access to the fence created for the render job.

v2: Drop flag (Eric)

Signed-off-by: Stefan Schake 
---
 src/gallium/drivers/vc4/vc4_context.c | 10 --
 src/gallium/drivers/vc4/vc4_context.h |  5 -
 src/gallium/drivers/vc4/vc4_job.c | 24 +++-
 3 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/vc4/vc4_context.c 
b/src/gallium/drivers/vc4/vc4_context.c
index c1e041d..0deb3ef 100644
--- a/src/gallium/drivers/vc4/vc4_context.c
+++ b/src/gallium/drivers/vc4/vc4_context.c
@@ -124,6 +124,9 @@ vc4_context_destroy(struct pipe_context *pctx)
 
 vc4_program_fini(pctx);
 
+if (vc4->screen->has_syncobj)
+drmSyncobjDestroy(vc4->fd, vc4->job_syncobj);
+
 ralloc_free(vc4);
 }
 
@@ -132,6 +135,7 @@ vc4_context_create(struct pipe_screen *pscreen, void *priv, 
unsigned flags)
 {
 struct vc4_screen *screen = vc4_screen(pscreen);
 struct vc4_context *vc4;
+int err;
 
 /* Prevent dumping of the shaders built during context setup. */
 uint32_t saved_shaderdb_flag = vc4_debug & VC4_DEBUG_SHADERDB;
@@ -157,10 +161,12 @@ vc4_context_create(struct pipe_screen *pscreen, void 
*priv, unsigned flags)
 vc4_query_init(pctx);
 vc4_resource_context_init(pctx);
 
-vc4_job_init(vc4);
-
 vc4->fd = screen->fd;
 
+err = vc4_job_init(vc4);
+if (err)
+goto fail;
+
 slab_create_child(>transfer_pool, >transfer_pool);
 
vc4->uploader = u_upload_create_default(>base);
diff --git a/src/gallium/drivers/vc4/vc4_context.h 
b/src/gallium/drivers/vc4/vc4_context.h
index 16bebee..d094957 100644
--- a/src/gallium/drivers/vc4/vc4_context.h
+++ b/src/gallium/drivers/vc4/vc4_context.h
@@ -408,6 +408,9 @@ struct vc4_context {
 
 struct vc4_hwperfmon *perfmon;
 /** @} */
+
+/** Handle of syncobj containing the last submitted job fence. */
+uint32_t job_syncobj;
 };
 
 struct vc4_rasterizer_state {
@@ -502,7 +505,7 @@ void vc4_write_uniforms(struct vc4_context *vc4,
 struct vc4_texture_stateobj *texstate);
 
 void vc4_flush(struct pipe_context *pctx);
-void vc4_job_init(struct vc4_context *vc4);
+int vc4_job_init(struct vc4_context *vc4);
 struct vc4_job *vc4_get_job(struct vc4_context *vc4,
 struct pipe_surface *cbuf,
 struct pipe_surface *zsbuf);
diff --git a/src/gallium/drivers/vc4/vc4_job.c 
b/src/gallium/drivers/vc4/vc4_job.c
index 41c274c..3b0ba8b 100644
--- a/src/gallium/drivers/vc4/vc4_job.c
+++ b/src/gallium/drivers/vc4/vc4_job.c
@@ -477,6 +477,9 @@ vc4_job_submit(struct vc4_context *vc4, struct vc4_job *job)
 }
 submit.flags |= job->flags;
 
+if (vc4->screen->has_syncobj)
+submit.out_sync = vc4->job_syncobj;
+
 if (!(vc4_debug & VC4_DEBUG_NORAST)) {
 int ret;
 
@@ -530,7 +533,7 @@ vc4_job_hash(const void *key)
 return _mesa_hash_data(key, sizeof(struct vc4_job_key));
 }
 
-void
+int
 vc4_job_init(struct vc4_context *vc4)
 {
 vc4->jobs = _mesa_hash_table_create(vc4,
@@ -539,5 +542,24 @@ vc4_job_init(struct vc4_context *vc4)
 vc4->write_jobs = _mesa_hash_table_create(vc4,
   _mesa_hash_pointer,
   _mesa_key_pointer_equal);
+
+if (vc4->screen->has_syncobj) {
+/* Create the syncobj as signaled since with no job executed
+ * there is nothing to wait on.
+ */
+int ret = drmSyncobjCreate(vc4->fd,
+   DRM_SYNCOBJ_CREATE_SIGNALED,
+   >job_syncobj);
+if (ret) {
+/* If the screen indicated syncobj support, we should
+ * be able to create a signaled syncobj.
+ * At this point it is too late to pretend the screen
+ * has no syncobj support.
+ */
+return ret;
+}
+}
+
+return 0;
 }
 
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 4/6] broadcom/vc4: Detect syncobj support

[Stefan Schake]

We need to know if the kernel supports syncobj submission since otherwise
all the DRM syncobj calls fail.

v2: Use drmGetCap to detect syncobj support (Eric)

Signed-off-by: Stefan Schake 
---
 src/gallium/drivers/vc4/vc4_screen.c | 6 ++
 src/gallium/drivers/vc4/vc4_screen.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/src/gallium/drivers/vc4/vc4_screen.c 
b/src/gallium/drivers/vc4/vc4_screen.c
index cead71b..45cbae9 100644
--- a/src/gallium/drivers/vc4/vc4_screen.c
+++ b/src/gallium/drivers/vc4/vc4_screen.c
@@ -648,7 +648,9 @@ struct pipe_screen *
 vc4_screen_create(int fd, struct renderonly *ro)
 {
 struct vc4_screen *screen = rzalloc(NULL, struct vc4_screen);
+uint64_t syncobj_cap = 0;
 struct pipe_screen *pscreen;
+int err;
 
 pscreen = >base;
 
@@ -684,6 +686,10 @@ vc4_screen_create(int fd, struct renderonly *ro)
 screen->has_perfmon_ioctl =
 vc4_has_feature(screen, DRM_VC4_PARAM_SUPPORTS_PERFMON);
 
+err = drmGetCap(fd, DRM_CAP_SYNCOBJ, _cap);
+if (err == 0 && syncobj_cap)
+screen->has_syncobj = true;
+
 if (!vc4_get_chip_info(screen))
 goto fail;
 
diff --git a/src/gallium/drivers/vc4/vc4_screen.h 
b/src/gallium/drivers/vc4/vc4_screen.h
index 0b88442..438e90a 100644
--- a/src/gallium/drivers/vc4/vc4_screen.h
+++ b/src/gallium/drivers/vc4/vc4_screen.h
@@ -98,6 +98,7 @@ struct vc4_screen {
 bool has_madvise;
 bool has_tiling_ioctl;
 bool has_perfmon_ioctl;
+bool has_syncobj;
 
 struct vc4_simulator_file *sim_file;
 };
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 6/6] broadcom/vc4: Native fence fd support

[Stefan Schake]

With the syncobj support in place, lets use it to implement the
EGL_ANDROID_native_fence_sync extension. This mostly follows previous
implementations in freedreno and etnaviv.

v2: Drop the flags (Eric)
Handle in_fence_fd already in job_submit (Eric)
Drop extra vc4_fence_context_init (Eric)
Dup fds with CLOEXEC (Eric)
Mention exact extension name (Eric)

Signed-off-by: Stefan Schake 
---
 src/gallium/drivers/vc4/vc4_context.c | 21 ++-
 src/gallium/drivers/vc4/vc4_context.h |  5 +++
 src/gallium/drivers/vc4/vc4_fence.c   | 70 +--
 src/gallium/drivers/vc4/vc4_job.c | 12 +-
 src/gallium/drivers/vc4/vc4_screen.c  |  6 ++-
 src/gallium/drivers/vc4/vc4_screen.h  |  4 +-
 6 files changed, 107 insertions(+), 11 deletions(-)

diff --git a/src/gallium/drivers/vc4/vc4_context.c 
b/src/gallium/drivers/vc4/vc4_context.c
index 0deb3ef..9ff39c2 100644
--- a/src/gallium/drivers/vc4/vc4_context.c
+++ b/src/gallium/drivers/vc4/vc4_context.c
@@ -59,8 +59,17 @@ vc4_pipe_flush(struct pipe_context *pctx, struct 
pipe_fence_handle **fence,
 
 if (fence) {
 struct pipe_screen *screen = pctx->screen;
+int fd = -1;
+
+if (flags & PIPE_FLUSH_FENCE_FD) {
+/* The vc4_fence takes ownership of the returned fd. */
+drmSyncobjExportSyncFile(vc4->fd, vc4->job_syncobj,
+ );
+}
+
 struct vc4_fence *f = vc4_fence_create(vc4->screen,
-   vc4->last_emit_seqno);
+   vc4->last_emit_seqno,
+   fd);
 screen->fence_reference(screen, fence, NULL);
 *fence = (struct pipe_fence_handle *)f;
 }
@@ -124,8 +133,12 @@ vc4_context_destroy(struct pipe_context *pctx)
 
 vc4_program_fini(pctx);
 
-if (vc4->screen->has_syncobj)
+if (vc4->screen->has_syncobj) {
 drmSyncobjDestroy(vc4->fd, vc4->job_syncobj);
+drmSyncobjDestroy(vc4->fd, vc4->in_syncobj);
+}
+if (vc4->in_fence_fd >= 0)
+close(vc4->in_fence_fd);
 
 ralloc_free(vc4);
 }
@@ -167,6 +180,10 @@ vc4_context_create(struct pipe_screen *pscreen, void 
*priv, unsigned flags)
 if (err)
 goto fail;
 
+err = vc4_fence_context_init(vc4);
+if (err)
+goto fail;
+
 slab_create_child(>transfer_pool, >transfer_pool);
 
vc4->uploader = u_upload_create_default(>base);
diff --git a/src/gallium/drivers/vc4/vc4_context.h 
b/src/gallium/drivers/vc4/vc4_context.h
index d094957..ce8bcff 100644
--- a/src/gallium/drivers/vc4/vc4_context.h
+++ b/src/gallium/drivers/vc4/vc4_context.h
@@ -411,6 +411,10 @@ struct vc4_context {
 
 /** Handle of syncobj containing the last submitted job fence. */
 uint32_t job_syncobj;
+
+int in_fence_fd;
+/** Handle of the syncobj that holds in_fence_fd for submission. */
+uint32_t in_syncobj;
 };
 
 struct vc4_rasterizer_state {
@@ -506,6 +510,7 @@ void vc4_write_uniforms(struct vc4_context *vc4,
 
 void vc4_flush(struct pipe_context *pctx);
 int vc4_job_init(struct vc4_context *vc4);
+int vc4_fence_context_init(struct vc4_context *vc4);
 struct vc4_job *vc4_get_job(struct vc4_context *vc4,
 struct pipe_surface *cbuf,
 struct pipe_surface *zsbuf);
diff --git a/src/gallium/drivers/vc4/vc4_fence.c 
b/src/gallium/drivers/vc4/vc4_fence.c
index f61e7c6..7071425 100644
--- a/src/gallium/drivers/vc4/vc4_fence.c
+++ b/src/gallium/drivers/vc4/vc4_fence.c
@@ -34,26 +34,39 @@
  * fired off as our fence marker.
  */
 
+#include 
+#include 
+
 #include "util/u_inlines.h"
 
 #include "vc4_screen.h"
+#include "vc4_context.h"
 #include "vc4_bufmgr.h"
 
 struct vc4_fence {
 struct pipe_reference reference;
 uint64_t seqno;
+int fd;
 };
 
+static inline struct vc4_fence *
+vc4_fence(struct pipe_fence_handle *pfence)
+{
+return (struct vc4_fence *)pfence;
+}
+
 static void
 vc4_fence_reference(struct pipe_screen *pscreen,
 struct pipe_fence_handle **pp,
 struct pipe_fence_handle *pf)
 {
 struct vc4_fence **p = (struct vc4_fence **)pp;
-struct vc4_fence *f = (struct vc4_fence *)pf;
+struct vc4_fence *f = vc4_fence(pf);
 struct vc4_fence *old = *p;
 
 if (pipe_reference(&(*p)->reference, >reference)) {
+if (old->fd >= 0)
+close(old->fd);
 free(old);
 }
 *p = f;
@@ -66,13 +79,16 @@ vc4_fence_finish(struct pipe_screen *pscreen,
  uint64_t timeout_ns)
 {
 struct vc4_screen *screen = vc4_screen(pscreen);

[Mesa-dev] [PATCH v2 0/6] broadcom/vc4: Native fence fd support

[Stefan Schake]

v2 drops the submit flags, directly moves in fence handling to the
job submit function and queries for the syncobj cap instead of using
a separate support parameter.

This series adds support for the native fence fd extension to vc4.
The implementation relies on a newly introduced kernel interface that
allows submitting syncobjs for in/out fences during job submission.

Since syncobjs are relatively new, patches 1 and 3 have build changes
for automake and meson to require a recent libdrm version.

There is some scope here to replace the previous sequence number based
implementation with only syncobjs, but given that we need to continue
supporting older kernels I felt it would have only added complexity.

This has been tested with piglit and kmscube -A(tomic). In particular,
I checked that the fd numbers weren't increasing during the kmscube run.

Should not be merged until the kernel side lands. In particular, patch 2
is purely provisional.

Stefan Schake (6):
  broadcom/vc4: Drop libdrm_vc4 requirement
  drm-uapi: Update vc4 header with syncobj submit support
  broadcom/vc4: Bump libdrm requirement
  broadcom/vc4: Detect syncobj support
  broadcom/vc4: Store job fence in syncobj
  broadcom/vc4: Native fence fd support

 configure.ac  |  3 +-
 include/drm-uapi/vc4_drm.h| 13 +--
 meson.build   |  2 +
 src/gallium/drivers/vc4/vc4_context.c | 29 +--
 src/gallium/drivers/vc4/vc4_context.h | 10 -
 src/gallium/drivers/vc4/vc4_fence.c   | 70 +--
 src/gallium/drivers/vc4/vc4_job.c | 34 -
 src/gallium/drivers/vc4/vc4_screen.c  | 12 +-
 src/gallium/drivers/vc4/vc4_screen.h  |  5 ++-
 9 files changed, 160 insertions(+), 18 deletions(-)

-- 
2.7.4

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

[Mesa-dev] [PATCH v2 2/6] drm-uapi: Update vc4 header with syncobj submit support

[Stefan Schake]

v2: Synchronized with kernel v2

Signed-off-by: Stefan Schake 
---
 include/drm-uapi/vc4_drm.h | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/include/drm-uapi/vc4_drm.h b/include/drm-uapi/vc4_drm.h
index 4117117..bc2d3ed 100644
--- a/include/drm-uapi/vc4_drm.h
+++ b/include/drm-uapi/vc4_drm.h
@@ -183,11 +183,16 @@ struct drm_vc4_submit_cl {
/* ID of the perfmon to attach to this job. 0 means no perfmon. */
__u32 perfmonid;
 
-   /* Unused field to align this struct on 64 bits. Must be set to 0.
-* If one ever needs to add an u32 field to this struct, this field
-* can be used.
+   /* Syncobj handle to wait on. If set, processing of this render job
+* will not start until the syncobj is signaled. 0 means ignore.
 */
-   __u32 pad2;
+   __u32 in_sync;
+
+   /* Syncobj handle to export fence to. If set, the fence in the syncobj
+* will be replaced with a fence that signals upon completion of this
+* render job. 0 means ignore.
+*/
+   __u32 out_sync;
 };
 
 /**
-- 
2.7.4

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

[Mesa-dev] [PATCH v2 1/6] broadcom/vc4: Drop libdrm_vc4 requirement

[Stefan Schake]

This was missed in the move back to the local uapi copy.
libdrm_vc4 only seems to consist of headers that also exist in the
Mesa tree.

Signed-off-by: Stefan Schake 
---
 configure.ac | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 33c8d08..9a38471 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2714,7 +2714,6 @@ if test -n "$with_gallium_drivers"; then
 ;;
 xvc4)
 HAVE_GALLIUM_VC4=yes
-require_libdrm "vc4"
 
 PKG_CHECK_MODULES([SIMPENROSE], [simpenrose],
   [USE_VC4_SIMULATOR=yes;
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 11/11] anv/device: expose shaderInt16 support in gen8+

[Jason Ekstrand]

9-11 are

Reviewed-by: Jason Ekstrand 

On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga 
wrote:

> ---
>  src/intel/vulkan/anv_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 7522b7865c2..306d5beff7d 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -759,7 +759,7 @@ void anv_GetPhysicalDeviceFeatures(
>.shaderCullDistance   = true,
>.shaderFloat64= pdevice->info.gen >= 8,
>.shaderInt64  = pdevice->info.gen >= 8,
> -  .shaderInt16  = false,
> +  .shaderInt16  = pdevice->info.gen >= 8,
>.shaderResourceMinLod = false,
>.variableMultisampleRate  = false,
>.inheritedQueries = true,
> --
> 2.14.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 08/11] intel/compiler: fix brw_negate_immediate for 16-bit types

[Jason Ekstrand]

On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga 
wrote:

> From: Jose Maria Casanova Crespo 
>
> 16-bit immediates are replicated in each word of a 32-bit value
> so we need to negate both.
> ---
>  src/intel/compiler/brw_shader.cpp | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/intel/compiler/brw_shader.cpp b/src/intel/compiler/brw_
> shader.cpp
> index 9cdf9fcb23d..c7edc60b63d 100644
> --- a/src/intel/compiler/brw_shader.cpp
> +++ b/src/intel/compiler/brw_shader.cpp
> @@ -581,7 +581,8 @@ brw_negate_immediate(enum brw_reg_type type, struct
> brw_reg *reg)
>return true;
> case BRW_REGISTER_TYPE_W:
> case BRW_REGISTER_TYPE_UW:
> -  reg->d = -(int16_t)reg->ud;
> +   case BRW_REGISTER_TYPE_HF:
> +  reg->ud ^= 0x80008000;
>

This is not correct for integers.  We need to keep two separate cases.


>return true;
> case BRW_REGISTER_TYPE_F:
>reg->f = -reg->f;
> @@ -602,8 +603,6 @@ brw_negate_immediate(enum brw_reg_type type, struct
> brw_reg *reg)
> case BRW_REGISTER_TYPE_UV:
> case BRW_REGISTER_TYPE_V:
>assert(!"unimplemented: negate UV/V immediate");
> -   case BRW_REGISTER_TYPE_HF:
> -  assert(!"unimplemented: negate HF immediate");
> case BRW_REGISTER_TYPE_NF:
>unreachable("no NF immediates");
> }
> --
> 2.14.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 07/11] intel/compiler: implement nir_instr_type_load_const for 16-bit constants

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga 
wrote:

> From: Jose Maria Casanova Crespo 
>
> ---
>  src/intel/compiler/brw_fs_nir.cpp | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index ad31f7c82dc..822a1ac4227 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -1509,6 +1509,11 @@ fs_visitor::nir_emit_load_const(const fs_builder
> ,
> fs_reg reg = bld.vgrf(reg_type, instr->def.num_components);
>
> switch (instr->def.bit_size) {
> +   case 16:
> +  for (unsigned i = 0; i < instr->def.num_components; i++)
> + bld.MOV(offset(reg, bld, i), brw_imm_w(instr->value.i16[i]));
> +  break;
> +
> case 32:
>for (unsigned i = 0; i < instr->def.num_components; i++)
>   bld.MOV(offset(reg, bld, i), brw_imm_d(instr->value.i32[i]));
> --
> 2.14.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 06/11] nir/constant_folding: support 16-bit constants

[Jason Ekstrand]

On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga 
wrote:

> From: Jose Maria Casanova Crespo 
>
> ---
>  src/compiler/nir/nir_opt_constant_folding.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/compiler/nir/nir_opt_constant_folding.c
> b/src/compiler/nir/nir_opt_constant_folding.c
> index d6be807b3dc..b63660ea4da 100644
> --- a/src/compiler/nir/nir_opt_constant_folding.c
> +++ b/src/compiler/nir/nir_opt_constant_folding.c
> @@ -78,6 +78,8 @@ constant_fold_alu_instr(nir_alu_instr *instr, void
> *mem_ctx)
> j++) {
>   if (load_const->def.bit_size == 64)
>  src[i].u64[j] = load_const->value.u64[instr->
> src[i].swizzle[j]];
> + else if (load_const->def.bit_size == 16)
> +src[i].u16[j] = load_const->value.u16[instr->
> src[i].swizzle[j]];
>   else
>  src[i].u32[j] = load_const->value.u32[instr->
> src[i].swizzle[j]];
>

Let's make this a switch and support 8 while we're at it.


>}
> --
> 2.14.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 05/11] intel/compiler: implement conversions from 16-bit int/float to bool

[Jason Ekstrand]

On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga 
wrote:

> ---
>  src/intel/compiler/brw_fs_nir.cpp | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index 5c414e45b61..ad31f7c82dc 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -1162,8 +1162,9 @@ fs_visitor::nir_emit_alu(const fs_builder ,
> nir_alu_instr *instr)
>break;
>
> case nir_op_i2b:
> -   case nir_op_f2b:
> -  if (nir_src_bit_size(instr->src[0].src) == 64) {
> +   case nir_op_f2b: {
> +  uint32_t bit_size = nir_src_bit_size(instr->src[0].src);
> +  if (bit_size == 64) {
>   /* two-argument instructions can't take 64-bit immediates */
>   fs_reg zero;
>   fs_reg tmp;
> @@ -1185,13 +1186,18 @@ fs_visitor::nir_emit_alu(const fs_builder ,
> nir_alu_instr *instr)
>   bld.CMP(tmp, op[0], zero, BRW_CONDITIONAL_NZ);
>   bld.MOV(result, subscript(tmp, BRW_REGISTER_TYPE_UD, 0));
>} else {
> - if (instr->op == nir_op_f2b) {
> -bld.CMP(result, op[0], brw_imm_f(0.0f), BRW_CONDITIONAL_NZ);
> + fs_reg zero;
> + if (bit_size == 32) {
> +zero = instr->op == nir_op_f2b ? brw_imm_f(0.0f) :
> brw_imm_d(0);
>   } else {
> -bld.CMP(result, op[0], brw_imm_d(0), BRW_CONDITIONAL_NZ);
> +assert(bit_size == 16);
> +zero = instr->op == nir_op_f2b ?
> +   retype(brw_imm_w(0), BRW_REGISTER_TYPE_HF) : brw_imm_w(0);
>

I really wish there were some better way of building immediates. Oh, well,
we can fix that later.

Reviewed-by: Jason Ekstrand 


>   }
> + bld.CMP(result, op[0], zero, BRW_CONDITIONAL_NZ);
>}
>break;
> +   }
>
> case nir_op_ftrunc:
>inst = bld.RNDZ(result, op[0]);
> --
> 2.14.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 04/11] intel/compiler: implement conversion between float/int 16-bit types

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga 
wrote:

> ---
>  src/intel/compiler/brw_fs_nir.cpp | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index 5e0dd37eefd..5c414e45b61 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -791,10 +791,14 @@ fs_visitor::nir_emit_alu(const fs_builder ,
> nir_alu_instr *instr)
> case nir_op_f2f32:
> case nir_op_f2i32:
> case nir_op_f2u32:
> +   case nir_op_f2i16:
> +   case nir_op_f2u16:
> case nir_op_i2i32:
> case nir_op_u2u32:
> case nir_op_i2i16:
> case nir_op_u2u16:
> +   case nir_op_i2f16:
> +   case nir_op_u2f16:
>inst = bld.MOV(result, op[0]);
>inst->saturate = instr->dest.saturate;
>break;
> --
> 2.14.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 01/11] intel/compiler: lower 16-bit integer extended math instructions

[Jason Ekstrand]

On Tue, Apr 24, 2018 at 7:38 AM, Rob Clark  wrote:

> side-note, not sure if it really effects what you are doing here, but
> karol ran into some cases, like 8bit signed imax, which needs to be
> "lowered" to 16b (or 32b) and converted back for hw that doesn't
> support smaller than 16b (or 32b).  I think I have the same case with
> ir3, which also has 16b but no 8b, (but he is a bit further along cl
> cts than I am)..
>
> I think there will be more of this sort of thing coming for more
> instructions and for more than just 16b vs 32b.  So not sure if
> writing rules for each in nir_opt_algebraic.py will be so fun..
>

Yeah, it may be that what we want is a generic "lower this to something
with more bits" pass.  If this is a problem for the CL people, maybe we
just want some way to make it configurable and put it in core NIR.  I don't
really have a huge preference.  I'm just trying to make sure we explore the
solution space.

--Jason


BR,
> -R
>
> On Tue, Apr 24, 2018 at 9:56 AM, Jason Ekstrand 
> wrote:
> > It may be useful to just use nir_algebraic for this.  We already do for
> trig
> > workarounds.  It's more painful from a build-system perspective but, in
> > general, the fewer hand-rolled algebraic lowering passes we have, the
> > better.
> >
> > On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga 
> > wrote:
> >>
> >> The hardware doesn't support 16-bit integer types, so we need to
> implement
> >> these using 32-bit integer instructions and then convert the result back
> >> to 16-bit.
> >> ---
> >>  src/intel/Makefile.sources|   1 +
> >>  src/intel/compiler/brw_nir.c  |   2 +
> >>  src/intel/compiler/brw_nir.h  |   2 +
> >>  src/intel/compiler/brw_nir_lower_16bit_int_math.c | 108
> >> ++
> >>  src/intel/compiler/meson.build|   1 +
> >>  5 files changed, 114 insertions(+)
> >>  create mode 100644 src/intel/compiler/brw_nir_lower_16bit_int_math.c
> >>
> >> diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
> >> index 91c71a8dfaf..2cd76961ea4 100644
> >> --- a/src/intel/Makefile.sources
> >> +++ b/src/intel/Makefile.sources
> >> @@ -79,6 +79,7 @@ COMPILER_FILES = \
> >> compiler/brw_nir_analyze_boolean_resolves.c \
> >> compiler/brw_nir_analyze_ubo_ranges.c \
> >> compiler/brw_nir_attribute_workarounds.c \
> >> +   compiler/brw_nir_lower_16bit_int_math.c \
> >> compiler/brw_nir_lower_cs_intrinsics.c \
> >> compiler/brw_nir_opt_peephole_ffma.c \
> >> compiler/brw_nir_tcs_workarounds.c \
> >> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> >> index 69ab162f888..2e5754076ed 100644
> >> --- a/src/intel/compiler/brw_nir.c
> >> +++ b/src/intel/compiler/brw_nir.c
> >> @@ -638,6 +638,8 @@ brw_preprocess_nir(const struct brw_compiler
> >> *compiler, nir_shader *nir)
> >>  nir_lower_isign64 |
> >>  nir_lower_divmod64);
> >>
> >> +   brw_nir_lower_16bit_int_math(nir);
> >> +
> >> nir = brw_nir_optimize(nir, compiler, is_scalar);
> >>
> >> if (is_scalar) {
> >> diff --git a/src/intel/compiler/brw_nir.h b/src/intel/compiler/brw_nir.h
> >> index 03f52da08e5..6ba1a8bc654 100644
> >> --- a/src/intel/compiler/brw_nir.h
> >> +++ b/src/intel/compiler/brw_nir.h
> >> @@ -152,6 +152,8 @@ void brw_nir_analyze_ubo_ranges(const struct
> >> brw_compiler *compiler,
> >>
> >>  bool brw_nir_opt_peephole_ffma(nir_shader *shader);
> >>
> >> +bool brw_nir_lower_16bit_int_math(nir_shader *shader);
> >> +
> >>  nir_shader *brw_nir_optimize(nir_shader *nir,
> >>   const struct brw_compiler *compiler,
> >>   bool is_scalar);
> >> diff --git a/src/intel/compiler/brw_nir_lower_16bit_int_math.c
> >> b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
> >> new file mode 100644
> >> index 000..6876309a822
> >> --- /dev/null
> >> +++ b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
> >> @@ -0,0 +1,108 @@
> >> +/*
> >> + * Copyright © 2018 Intel Corporation
> >> + *
> >> + * Permission is hereby granted, free of charge, to any person
> obtaining
> >> a
> >> + * copy of this software and associated documentation files (the
> >> "Software"),
> >> + * to deal in the Software without restriction, including without
> >> limitation
> >> + * the rights to use, copy, modify, merge, publish, distribute,
> >> sublicense,
> >> + * and/or sell copies of the Software, and to permit persons to whom
> the
> >> + * Software is furnished to do so, subject to the following conditions:
> >> + *
> >> + * The above copyright notice and this permission notice (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 

Re: [Mesa-dev] [PATCH 1/3] mesa: merge the driver functions DrawBuffers and DrawBuffer

[Ian Romanick]

On 04/24/2018 09:28 AM, Ian Romanick wrote:
> On 04/23/2018 08:23 PM, Timothy Arceri wrote:
>> On 24/04/18 10:13, Dieter Nützel wrote:
>>> Hello Timo,
>>>
>>> what about 2 and 3, #1 landed.
>>
>> It turns out the old radeon classic drivers do make use of the param
>> dropped in patch 2 so I've decided to drop that patch, although the use
>> of that param might be a bug as the intel drivers changed their behavior
>> to fix a bug (however it's not a simple change).
> 
> This sounds familiar, and I might have a patch for that.  Let me root
> around in my git branches to see if I can find it...  I'm definitely in
> favor of cleaning up a bunch of the dd interfaces.

I sent these to the list in September 2015:

https://patchwork.freedesktop.org/patch/60786/
https://patchwork.freedesktop.org/patch/60794/

I don't recall what testing I did exactly, and I didn't put anything
useful in the commit message. :(

>> I'd still like to push patch 3 but it's tripping up some old hardware in
>> Intels CI system. I'm not sure whats going on yet.
>>
>>> Dieter
> ___
> 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] meson: Fix no-rtti in llvm detection

[Dylan Baker]

Because I clearly wasn't thinking and clearly didn't do a good job
testing. Sigh

Fixes: c5a97d658ec19cc02719d7f86c1b0715e3d9ffc4
   ("meson: fix builds against LLVM built without rtti")
Signed-off-by: Dylan Baker 
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 590ac40a781..52a1075823f 100644
--- a/meson.build
+++ b/meson.build
@@ -1149,7 +1149,7 @@ if with_llvm
   # programs, so we need to build all C++ code in mesa without rtti as well to
   # ensure that linking works.
   if dep_llvm.get_configtool_variable('has-rtti') == 'NO'
-cpp_args('-fno-rtti')
+cpp_args += '-fno-rtti'
   endif
 elif with_amd_vk or with_gallium_radeonsi or with_gallium_swr
   error('The following drivers require LLVM: Radv, RadeonSI, SWR. One of these 
is enabled, but LLVM is disabled.')
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

[Sean Paul]

On Fri, Apr 13, 2018 at 6:01 AM Daniel Vetter 
wrote:

> This tries to align with the X.org communities's long-standing
> tradition of trying to be an inclusive community and handing out
> commit rights fairly freely.

> We also tend to not revoke commit rights for people no longer
> regularly active in a given project, as long as they're still part of
> the larger community.

> Finally make sure that commit rights, like anything happening on fd.o
> infrastructre, is subject to the fd.o's Code of Conduct.

> v2: Point at MAINTAINERS for contact info (Daniel S.)

> v3:
> - Make it clear that commit rights are voluntary and that committers
>need to acknowledge positively when they're nominated by someone
>else (Keith).
> - Encourage committers to drop their commit rights when they're no
>longer active, and make it clear they'll get readded (Keith).
> - Add a line that maintainers and committers should actively nominate
>new committers (me).

> v4: Typo (Petri).

> v5: Typo (Sean).

I don't remember this, but good for me!

Current revision looks good, and I am supportive of applying it to drm-misc.

Acked-by: Sean Paul 


> v6: Wording clarifications and spelling (Jani).

> v7: Require an explicit commitment to the documented merge criteria
> and rules, instead of just the implied one through the Code of Conduct
> threat (Jani).

> Acked-by: Alex Deucher 
> Acked-by: Arkadiusz Hiler 
> Acked-by: Daniel Stone 
> Acked-by: Eric Anholt 
> Acked-by: Gustavo Padovan 
> Acked-by: Petri Latvala 
> Cc: Alex Deucher 
> Cc: Arkadiusz Hiler 
> Cc: Ben Widawsky 
> Cc: Daniel Stone 
> Cc: Dave Airlie 
> Cc: Eric Anholt 
> Cc: Gustavo Padovan 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Keith Packard 
> Cc: Kenneth Graunke 
> Cc: Kristian H. Kristensen 
> Cc: Maarten Lankhorst 
> Cc: Petri Latvala 
> Cc: Rodrigo Vivi 
> Cc: Sean Paul 
> Reviewed-by: Keith Packard 
> Signed-off-by: Daniel Vetter 
> ---
> If you wonder about the wide distribution list for an igt patch: I'd
> like to start a discussions about x.org community norms around commit
> rights at large, at least for all the shared repos. I plan to propose
> the same text for drm-misc and libdrm too, and hopefully others like
> mesa/xserver/wayland would follow.

> fd.o admins also plan to discuss this (and a pile of other topics and
> hosting and code of conduct) with all projects, ideally this here
> would end up as the starting point for establishing some community
> norms.
> -Daniel
> ---
>   CONTRIBUTING | 48 
>   1 file changed, 48 insertions(+)

> diff --git a/CONTRIBUTING b/CONTRIBUTING
> index 0180641be3aa..8a118134275c 100644
> --- a/CONTRIBUTING
> +++ b/CONTRIBUTING
> @@ -51,4 +51,52 @@ A short list of contribution guidelines:
>   - Changes to the testcases are automatically tested. Take the results
into
> account before merging.

> +Commit rights
> +-
> +
> +Commit rights will be granted to anyone who requests them and fulfills
the
> +below criteria:
> +
> +- Submitted a few (5-10 as a rule of thumb) non-trivial (not just simple
> +  spelling fixes and whitespace adjustment) patches that have been merged
> +  already.
> +
> +- Are actively participating on discussions about their work (on the
mailing
> +  list or IRC). This should not be interpreted as a requirement to
review other
> +  peoples patches but just make sure that patch submission isn't one-way
> +  communication. Cross-review is still highly encouraged.
> +
> +- Will be regularly contributing further patches. This includes regular
> +  contributors to other parts of the open source graphics stack who only
> +  do the oddball rare patch within igt itself.
> +
> +- Agrees to use their commit rights in accordance with the documented
merge
> +  criteria, tools, and processes.
> +
> +Apply for an account (and any other account change requests) through
> +
> +https://www.freedesktop.org/wiki/AccountRequests/
> +
> +and please ping the maintainers if your request is stuck.
> +
> +Committers are encouraged to request their commit rights get removed
when they
> +no longer contribute to the project. Commit rights will be reinstated
when they
> +come back to the project.
> +
> +Maintainers and committers should encourage contributors to request
commit
> +rights, especially junior contributors tend to underestimate their

Re: [Mesa-dev] [PATCH 8/9] Revert "radeonsi: fix potential use-after-free of debug callbacks"

[Marek Olšák]

I just sent a patch that fixes the deadlock.

Marek

On Tue, Apr 24, 2018 at 4:40 PM, Marek Olšák  wrote:

> On Wed, Apr 18, 2018 at 6:11 AM, Nicolai Hähnle 
> wrote:
>
>> How can this possibly deadlock? Is this during process exit, like in the
>> case where we got a deadlock when LLVM called abort()?
>>
>
> No. It deadlocks at the start. All threads are waiting on the barrier. The
> barrier should unblock all threads, but it doesn't.
>
> Marek
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] util/u_queue: fix a deadlock in util_queue_finish

[Marek Olšák]

From: Marek Olšák 

Cc: 18.0 18.1 
---
 src/util/u_queue.c | 9 +
 src/util/u_queue.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/src/util/u_queue.c b/src/util/u_queue.c
index dba23f96456..da513fd9cc5 100644
--- a/src/util/u_queue.c
+++ b/src/util/u_queue.c
@@ -304,20 +304,21 @@ util_queue_init(struct util_queue *queue,
queue->flags = flags;
queue->num_threads = num_threads;
queue->max_jobs = max_jobs;
 
queue->jobs = (struct util_queue_job*)
  calloc(max_jobs, sizeof(struct util_queue_job));
if (!queue->jobs)
   goto fail;
 
(void) mtx_init(>lock, mtx_plain);
+   (void) mtx_init(>finish_lock, mtx_plain);
 
queue->num_queued = 0;
cnd_init(>has_queued_cond);
cnd_init(>has_space_cond);
 
queue->threads = (thrd_t*) calloc(num_threads, sizeof(thrd_t));
if (!queue->threads)
   goto fail;
 
/* start threads */
@@ -391,20 +392,21 @@ util_queue_killall_and_wait(struct util_queue *queue)
 }
 
 void
 util_queue_destroy(struct util_queue *queue)
 {
util_queue_killall_and_wait(queue);
remove_from_atexit_list(queue);
 
cnd_destroy(>has_space_cond);
cnd_destroy(>has_queued_cond);
+   mtx_destroy(>finish_lock);
mtx_destroy(>lock);
free(queue->jobs);
free(queue->threads);
 }
 
 void
 util_queue_add_job(struct util_queue *queue,
void *job,
struct util_queue_fence *fence,
util_queue_execute_func execute,
@@ -522,29 +524,36 @@ util_queue_finish_execute(void *data, int num_thread)
  * Wait until all previously added jobs have completed.
  */
 void
 util_queue_finish(struct util_queue *queue)
 {
util_barrier barrier;
struct util_queue_fence *fences = malloc(queue->num_threads * 
sizeof(*fences));
 
util_barrier_init(, queue->num_threads);
 
+   /* If 2 threads were adding jobs for 2 different barries at the same time,
+* a deadlock would happen, because 1 barrier requires that all threads
+* wait for it exclusively.
+*/
+   mtx_lock(>finish_lock);
+
for (unsigned i = 0; i < queue->num_threads; ++i) {
   util_queue_fence_init([i]);
   util_queue_add_job(queue, , [i], 
util_queue_finish_execute, NULL);
}
 
for (unsigned i = 0; i < queue->num_threads; ++i) {
   util_queue_fence_wait([i]);
   util_queue_fence_destroy([i]);
}
+   mtx_unlock(>finish_lock);
 
util_barrier_destroy();
 
free(fences);
 }
 
 int64_t
 util_queue_get_thread_time_nano(struct util_queue *queue, unsigned 
thread_index)
 {
/* Allow some flexibility by not raising an error. */
diff --git a/src/util/u_queue.h b/src/util/u_queue.h
index d49f713e6ad..d702c4bce8d 100644
--- a/src/util/u_queue.h
+++ b/src/util/u_queue.h
@@ -193,20 +193,21 @@ typedef void (*util_queue_execute_func)(void *job, int 
thread_index);
 struct util_queue_job {
void *job;
struct util_queue_fence *fence;
util_queue_execute_func execute;
util_queue_execute_func cleanup;
 };
 
 /* Put this into your context. */
 struct util_queue {
const char *name;
+   mtx_t finish_lock; /* only for util_queue_finish */
mtx_t lock;
cnd_t has_queued_cond;
cnd_t has_space_cond;
thrd_t *threads;
unsigned flags;
int num_queued;
unsigned num_threads;
int kill_threads;
int max_jobs;
int write_idx, read_idx; /* ring buffer pointers */
-- 
2.17.0

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

[Mesa-dev] [PATCH] radeon/vcn: fix mpeg4 msg buffer settings

[boyuan.zhang]

From: Boyuan Zhang 

Previous bit-fields assignments are incorrect and will result certain mpeg4
decode failed due to wrong flag values. This patch fixes these assignments.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/drivers/radeon/radeon_vcn_dec.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c 
b/src/gallium/drivers/radeon/radeon_vcn_dec.c
index f83e9e5..4bc922d 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_dec.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_dec.c
@@ -554,15 +554,15 @@ static rvcn_dec_message_mpeg4_asp_vld_t 
get_mpeg4_msg(struct radeon_decoder *dec
 
result.vop_time_increment_resolution = 
pic->vop_time_increment_resolution;
 
-   result.short_video_header |= pic->short_video_header << 0;
-   result.interlaced |= pic->interlaced << 2;
-result.load_intra_quant_mat |= 1 << 3;
-   result.load_nonintra_quant_mat |= 1 << 4;
-   result.quarter_sample |= pic->quarter_sample << 5;
-   result.complexity_estimation_disable |= 1 << 6;
-   result.resync_marker_disable |= pic->resync_marker_disable << 7;
-   result.newpred_enable |= 0 << 10; //
-   result.reduced_resolution_vop_enable |= 0 << 11;
+   result.short_video_header = pic->short_video_header;
+   result.interlaced = pic->interlaced;
+   result.load_intra_quant_mat = 1;
+   result.load_nonintra_quant_mat = 1;
+   result.quarter_sample = pic->quarter_sample;
+   result.complexity_estimation_disable = 1;
+   result.resync_marker_disable = pic->resync_marker_disable;
+   result.newpred_enable = 0;
+   result.reduced_resolution_vop_enable = 0;
 
result.quant_type = pic->quant_type;
 
-- 
2.7.4

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

[Mesa-dev] [Bug 106157] [Tracker] Mesa 18.1 release tracker

[bugzilla-daemon]

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

Mark Janes  changed:

   What|Removed |Added

 Depends on||105938


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=105938
[Bug 105938] Incorrect colors since "i965: Use blorp instead of meta for PBO
texture downloads"
-- 
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 8/9] Revert "radeonsi: fix potential use-after-free of debug callbacks"

[Marek Olšák]

On Wed, Apr 18, 2018 at 6:11 AM, Nicolai Hähnle  wrote:

> How can this possibly deadlock? Is this during process exit, like in the
> case where we got a deadlock when LLVM called abort()?
>

No. It deadlocks at the start. All threads are waiting on the barrier. The
barrier should unblock all threads, but it doesn't.

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

Re: [Mesa-dev] [PATCH 2/2] draw: fix different sign logic when clipping

[Jose Fonseca]

On 24/04/18 17:27, srol...@vmware.com wrote:

From: Roland Scheidegger 

The logic was flawed, since mul(x,y) will be <= 0 (exactly 0) when
the sign is the same but both numbers are sufficiently small
(if the product is smaller than 2^-128).
This could apparently lead to emitting a sufficient amount of
additional bogus vertices to overflow the allocated array for them,
hitting an assertion (still safe with release builds since we just
aborted clipping after the assertion in this case - I'm however unsure
if this is now really no longer possible, so that code stays).
Not sure if the additional vertices could cause other grief, I didn't
see anything wrong even when hitting the assertion.

Essentially, both +-0 are treated as positive (the vertex is considered
to be inside the clip volume for this plane), so integrate the logic
determining different sign into the branch there.
---
  src/gallium/auxiliary/draw/draw_pipe_clip.c | 13 ++---
  1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c 
b/src/gallium/auxiliary/draw/draw_pipe_clip.c
index b7a1b5c..6af5c09 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_clip.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_clip.c
@@ -47,11 +47,6 @@
  /** Set to 1 to enable printing of coords before/after clipping */
  #define DEBUG_CLIP 0
  
-

-#ifndef DIFFERENT_SIGNS
-#define DIFFERENT_SIGNS(x, y) ((x) * (y) <= 0.0F && (x) - (y) != 0.0F)
-#endif
-
  #define MAX_CLIPPED_VERTICES ((2 * (6 + PIPE_MAX_CLIP_PLANES))+1)
  
  
@@ -479,6 +474,7 @@ do_clip_tri(struct draw_stage *stage,

for (i = 1; i <= n; i++) {
   struct vertex_header *vert = inlist[i];
   boolean *edge = [i];
+ boolean different_sign;
  
   float dp = getclipdist(clipper, vert, plane_idx);
  
@@ -491,9 +487,12 @@ do_clip_tri(struct draw_stage *stage,

 return;
  outEdges[outcount] = *edge_prev;
  outlist[outcount++] = vert_prev;
+different_sign = dp < 0.0f;
+ } else {
+different_sign = !(dp < 0.0f);
   }
  
- if (DIFFERENT_SIGNS(dp, dp_prev)) {

+ if (different_sign) {
  struct vertex_header *new_vert;
  boolean *new_edge;
  
@@ -511,7 +510,7 @@ do_clip_tri(struct draw_stage *stage,
  
  if (dp < 0.0f) {

 /* Going out of bounds.  Avoid division by zero as we
-* know dp != dp_prev from DIFFERENT_SIGNS, above.
+* know dp != dp_prev from different_sign, above.
  */
 float t = dp / (dp - dp_prev);
 interp( clipper, new_vert, t, vert, vert_prev, viewport_index 
);



Series looks good to me.

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

[Mesa-dev] [PATCH 1/7] ac/surface: handle DCC subresource fast clear restriction on VI

[Marek Olšák]

From: Marek Olšák 

v2: require the previous level to be clearable for determining whether
the last unaligned level is clearable
---
 src/amd/common/ac_surface.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index a23952717e3..487f6c6431b 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -336,36 +336,52 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
surf->u.legacy.tiling_index[level] = AddrSurfInfoOut->tileIndex;
 
surf->surf_size = surf_level->offset + AddrSurfInfoOut->surfSize;
 
/* Clear DCC fields at the beginning. */
surf_level->dcc_offset = 0;
 
/* The previous level's flag tells us if we can use DCC for this level. 
*/
if (AddrSurfInfoIn->flags.dccCompatible &&
(level == 0 || AddrDccOut->subLvlCompressible)) {
+   bool prev_level_clearable = level == 0 ||
+   AddrDccOut->dccRamSizeAligned;
+
AddrDccIn->colorSurfSize = AddrSurfInfoOut->surfSize;
AddrDccIn->tileMode = AddrSurfInfoOut->tileMode;
AddrDccIn->tileInfo = *AddrSurfInfoOut->pTileInfo;
AddrDccIn->tileIndex = AddrSurfInfoOut->tileIndex;
AddrDccIn->macroModeIndex = AddrSurfInfoOut->macroModeIndex;
 
ret = AddrComputeDccInfo(addrlib,
 AddrDccIn,
 AddrDccOut);
 
if (ret == ADDR_OK) {
surf_level->dcc_offset = surf->dcc_size;
-   surf_level->dcc_fast_clear_size = 
AddrDccOut->dccFastClearSize;
surf->num_dcc_levels = level + 1;
surf->dcc_size = surf_level->dcc_offset + 
AddrDccOut->dccRamSize;
surf->dcc_alignment = MAX2(surf->dcc_alignment, 
AddrDccOut->dccRamBaseAlign);
+
+   /* If the DCC size of a subresource (1 mip level or 1 
slice)
+* is not aligned, the DCC memory layout is not 
contiguous for
+* that subresource, which means we can't use fast 
clear.
+*
+* We only do fast clears for whole mipmap levels. If 
we did
+* per-slice fast clears, the same restriction would 
apply.
+* (i.e. only compute the slice size and see if it's 
aligned)
+*/
+   if (AddrDccOut->dccRamSizeAligned ||
+   (prev_level_clearable && level == 
config->info.levels - 1))
+   surf_level->dcc_fast_clear_size = 
AddrDccOut->dccFastClearSize;
+   else
+   surf_level->dcc_fast_clear_size = 0;
}
}
 
/* TC-compatible HTILE. */
if (!is_stencil &&
AddrSurfInfoIn->flags.depth &&
surf_level->mode == RADEON_SURF_MODE_2D &&
level == 0) {
AddrHtileIn->flags.tcCompatible = 
AddrSurfInfoIn->flags.tcCompatible;
AddrHtileIn->pitch = AddrSurfInfoOut->pitch;
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH] gm107/ir/lib: fix sched in div u32 builtin

[Samuel Pitoiset]

Correct.

Reviewed-by: Samuel Pitoiset 

On 04/24/2018 12:39 PM, Karol Herbst wrote:

Imad needs to set a read barrier.

With significant big work groups I was getting wrong results for div u32. Turns
out the issue was with the sched opcodes.

CC: Samuel Pitoiset 
Signed-off-by: Karol Herbst 
---
  src/gallium/drivers/nouveau/codegen/lib/gm107.asm   | 4 ++--
  src/gallium/drivers/nouveau/codegen/lib/gm107.asm.h | 4 ++--
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/lib/gm107.asm 
b/src/gallium/drivers/nouveau/codegen/lib/gm107.asm
index 90741b6c59f..7ee5f8fc65b 100644
--- a/src/gallium/drivers/nouveau/codegen/lib/gm107.asm
+++ b/src/gallium/drivers/nouveau/codegen/lib/gm107.asm
@@ -27,11 +27,11 @@ gm107_div_u32:
 imul u32 u32 $r3 $r1 $r2
 imad u32 u32 hi $r2 $r2 $r3 $r2
 imul u32 u32 $r3 $r1 $r2
-   sched (st 0x6 wr 0x0 wt 0x1) (st 0x6 wr 0x0 wt 0x1) (st 0x6 wr 0x0 wt 0x1)
+   sched (st 0x6 wr 0x0 wt 0x1) (st 0x6 wr 0x0 wt 0x1) (st 0x6 wr 0x0 rd 0x1 
wt 0x1)
 imad u32 u32 hi $r2 $r2 $r3 $r2
 imul u32 u32 $r3 $r1 $r2
 imad u32 u32 hi $r2 $r2 $r3 $r2
-   sched (st 0x6) (st 0x6 wr 0x0 rd 0x1 wt 0x1) (st 0xf wr 0x0 rd 0x1 wt 0x2)
+   sched (st 0x6 wt 0x2) (st 0x6 wr 0x0 rd 0x1 wt 0x1) (st 0xf wr 0x0 rd 0x1 
wt 0x2)
 mov $r3 $r0 0xf
 imul u32 u32 hi $r0 $r0 $r2
 i2i u32 u32 $r2 neg $r1
diff --git a/src/gallium/drivers/nouveau/codegen/lib/gm107.asm.h 
b/src/gallium/drivers/nouveau/codegen/lib/gm107.asm.h
index 8708a94b0a6..65c93f7ae89 100644
--- a/src/gallium/drivers/nouveau/codegen/lib/gm107.asm.h
+++ b/src/gallium/drivers/nouveau/codegen/lib/gm107.asm.h
@@ -16,11 +16,11 @@ uint64_t gm107_builtin_code[] = {
0x5c3800270103,
0x5a4001370202,
0x5c3800270103,
-   0x003c1801e0c00f06,
+   0x00241801e0c00f06,
0x5a4001370202,
0x5c3800270103,
0x5a4001370202,
-   0x00443c0120c007e6,
+   0x00443c0120c017e6,
0x5c9807870003,
0x5c3800800027,
0x5ce020170a02,


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

Re: [Mesa-dev] [PATCH 1/2] radv: only disable out-of-order rast for perfect occlusion queries

[Samuel Pitoiset]

On 04/24/2018 07:21 PM, Bas Nieuwenhuizen wrote:

On Tue, Apr 24, 2018 at 8:06 AM, Samuel Pitoiset
 wrote:

Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_cmd_buffer.c | 18 ++
  src/amd/vulkan/radv_query.c  |  4 ++--
  2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index baab8db617..baa28d408b 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1334,6 +1334,7 @@ radv_emit_index_buffer(struct radv_cmd_buffer *cmd_buffer)

  void radv_set_db_count_control(struct radv_cmd_buffer *cmd_buffer)
  {
+   bool has_perfect_queries = 
cmd_buffer->state.perfect_occlusion_queries_enabled;
 struct radv_pipeline *pipeline = cmd_buffer->state.pipeline;
 uint32_t pa_sc_mode_cntl_1 =
 pipeline ? pipeline->graphics.ms.pa_sc_mode_cntl_1 : 0;
@@ -1342,11 +1343,12 @@ void radv_set_db_count_control(struct radv_cmd_buffer 
*cmd_buffer)
 if(!cmd_buffer->state.active_occlusion_queries) {
 if (cmd_buffer->device->physical_device->rad_info.chip_class 
>= CIK) {
 if (G_028A4C_OUT_OF_ORDER_PRIMITIVE_ENABLE(pa_sc_mode_cntl_1) 
&&
-   
pipeline->graphics.disable_out_of_order_rast_for_occlusion) {
+   pipeline->graphics.disable_out_of_order_rast_for_occlusion 
&&
+   has_perfect_queries) {
 /* Re-enable out-of-order rasterization if the
  * bound pipeline supports it and if it's has
-* been disabled before starting occlusion
-* queries.
+* been disabled before starting any perfect
+* occlusion queries.
  */
 radeon_set_context_reg(cmd_buffer->cs,

R_028A4C_PA_SC_MODE_CNTL_1,
@@ -1359,22 +1361,22 @@ void radv_set_db_count_control(struct radv_cmd_buffer 
*cmd_buffer)
 } else {
 const struct radv_subpass *subpass = cmd_buffer->state.subpass;
 uint32_t sample_rate = subpass ? 
util_logbase2(subpass->max_sample_count) : 0;
-   bool perfect = 
cmd_buffer->state.perfect_occlusion_queries_enabled;

 if (cmd_buffer->device->physical_device->rad_info.chip_class 
>= CIK) {
 db_count_control =
-   S_028004_PERFECT_ZPASS_COUNTS(perfect) |
+   
S_028004_PERFECT_ZPASS_COUNTS(has_perfect_queries) |
 S_028004_SAMPLE_RATE(sample_rate) |
 S_028004_ZPASS_ENABLE(1) |
 S_028004_SLICE_EVEN_ENABLE(1) |
 S_028004_SLICE_ODD_ENABLE(1);

 if (G_028A4C_OUT_OF_ORDER_PRIMITIVE_ENABLE(pa_sc_mode_cntl_1) 
&&
-   
pipeline->graphics.disable_out_of_order_rast_for_occlusion) {
+   pipeline->graphics.disable_out_of_order_rast_for_occlusion 
&&
+   has_perfect_queries) {
 /* If the bound pipeline has enabled
  * out-of-order rasterization, we should
-* disable it before starting occlusion
-* queries.
+* disable it before starting any perfect
+* occlusion queries.
  */
 pa_sc_mode_cntl_1 &= 
C_028A4C_OUT_OF_ORDER_PRIMITIVE_ENABLE;

diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 859a4a1d68..2b2e80f4e5 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1140,12 +1140,12 @@ static void emit_end_query(struct radv_cmd_buffer 
*cmd_buffer,

 cmd_buffer->state.active_occlusion_queries--;
 if (cmd_buffer->state.active_occlusion_queries == 0) {
+   radv_set_db_count_control(cmd_buffer);
+


Why move this forward?


Because perfect_occlusion_queries_enabled will always be false in 
radv_set_db_count_control(), so we won't re-enable out-of-order 
rasterization if it has been disabled in begin_query().



 /* Reset the perfect occlusion queries hint now that no
  * queries are active.
  */
 cmd_buffer->state.perfect_occlusion_queries_enabled = 
false;
-
-   radv_set_db_count_control(cmd_buffer);
 }

 radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 2, 0));
--

Re: [Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

[Daniel Vetter]

On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov  wrote:
> On 13 April 2018 at 11:00, Daniel Vetter  wrote:
>> This tries to align with the X.org communities's long-standing
>> tradition of trying to be an inclusive community and handing out
>> commit rights fairly freely.
>>
>> We also tend to not revoke commit rights for people no longer
>> regularly active in a given project, as long as they're still part of
>> the larger community.
>>
>> Finally make sure that commit rights, like anything happening on fd.o
>> infrastructre, is subject to the fd.o's Code of Conduct.
>>
>> v2: Point at MAINTAINERS for contact info (Daniel S.)
>>
>> v3:
>> - Make it clear that commit rights are voluntary and that committers
>>   need to acknowledge positively when they're nominated by someone
>>   else (Keith).
>> - Encourage committers to drop their commit rights when they're no
>>   longer active, and make it clear they'll get readded (Keith).
>> - Add a line that maintainers and committers should actively nominate
>>   new committers (me).
>>
>> v4: Typo (Petri).
>>
>> v5: Typo (Sean).
>>
>> v6: Wording clarifications and spelling (Jani).
>>
>> v7: Require an explicit commitment to the documented merge criteria
>> and rules, instead of just the implied one through the Code of Conduct
>> threat (Jani).
>>
>> Acked-by: Alex Deucher 
>> Acked-by: Arkadiusz Hiler 
>> Acked-by: Daniel Stone 
>> Acked-by: Eric Anholt 
>> Acked-by: Gustavo Padovan 
>> Acked-by: Petri Latvala 
>> Cc: Alex Deucher 
>> Cc: Arkadiusz Hiler 
>> Cc: Ben Widawsky 
>> Cc: Daniel Stone 
>> Cc: Dave Airlie 
>> Cc: Eric Anholt 
>> Cc: Gustavo Padovan 
>> Cc: Jani Nikula 
>> Cc: Joonas Lahtinen 
>> Cc: Keith Packard 
>> Cc: Kenneth Graunke 
>> Cc: Kristian H. Kristensen 
>> Cc: Maarten Lankhorst 
>> Cc: Petri Latvala 
>> Cc: Rodrigo Vivi 
>> Cc: Sean Paul 
>> Reviewed-by: Keith Packard 
>> Signed-off-by: Daniel Vetter 
>> ---
>> If you wonder about the wide distribution list for an igt patch: I'd
>> like to start a discussions about x.org community norms around commit
>> rights at large, at least for all the shared repos. I plan to propose
>> the same text for drm-misc and libdrm too, and hopefully others like
>> mesa/xserver/wayland would follow.
>>
> I think the idea is pretty good, simply highlighting some bits.
>
> What you've outlined in this patch has been in practise for many years:
>  a) undocumented, applicable to most xorg projects [1]
>  b) documented, mesa

Hm, I chatted with a few mesa devs about this, and I wasn't aware
there's explicit documentation for mesa. Where is it? I'd very much
want to align as much as we can.

> IMHO having this explicitly documented and others
> (wayland/weston/wayland-protocols and xserver repos) following suite
> is a big plus.

Yeah, that's the idea. Hence plenty of Cc: for this igt patch.
-Daniel

>
> HTH
> Emil
>
> [1] As in all of https://cgit.freedesktop.org/xorg but xserver



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/2] gallium/util: Android backtrace support

[Stefan Schake]

On Tue, Apr 24, 2018 at 8:10 PM, Rob Herring  wrote:
> On Sun, Apr 15, 2018 at 5:45 PM, Stefan Schake  wrote:
>> We can't use any of the existing implementations in u_debug_stack.
>> Android technically has libunwind, but it's been modified to the point
>> where it no longer compiles with the Mesa usage. The library is also
>> not meant to be referenced by vendor libraries. The officially sanctioned
>> way of obtaining backtraces is through the Android own libbacktrace, a
>> C++ library. Access it through a separate C++ source file on Android only.
>
> I know this is committed already, but it was pointed out to me that
> libbacktrace is not a visible library in Treble-ized builds. It is in
> the vndk-sp-indirect list.
>

Hrm. I used this presentation for reference:

https://source.android.com/devices/architecture/images/vndk_design_android_o.pdf

And it seems to say SP-HAL may depend on VNDK-SP which
includes libbacktrace. Though looking into it I found this:

https://android.googlesource.com/platform/system/core/+/b7d92c4b96cebae6a60f5256c9173e46f325e860

Which does indeed seem to say not available to vendor. And instead
suggests yet another method of obtaining a call stack.

If this is runtime breaking for anyone, I'd suggest we simply revert the
series for now and I'll look into making it use the
now-really-vendor-available android::CallStack from libutils.

Sorry for the trouble,
Stefan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] glsl/tests/glcpp: reinstate "error out if no tests found"

[Dylan Baker]

Quoting Emil Velikov (2018-04-24 10:49:22)
> From: Emil Velikov 
> 
> With the recent rework of converting the shell script to a python one
> the check for actual tests was dropped.
> 
> Bring that back, since it was explicitly added considering we had a ~2
> year period, during which the tests were not run.
> 
> Fixes: db8cd8e36771 ("glcpp/tests: Convert shell scripts to a python
> script")
> Cc: Dylan Baker 
> Signed-off-by: Emil Velikov 
> ---
> One might be interested in folding some of the duplication/boilerplate
> at a later stage. I'm trying to bring back the normal behaviour for now
> ;-)
> ---
>  src/compiler/glsl/glcpp/tests/glcpp_test.py | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/src/compiler/glsl/glcpp/tests/glcpp_test.py 
> b/src/compiler/glsl/glcpp/tests/glcpp_test.py
> index 751bd40028..cb0f16f4e7 100644
> --- a/src/compiler/glsl/glcpp/tests/glcpp_test.py
> +++ b/src/compiler/glsl/glcpp/tests/glcpp_test.py
> @@ -118,6 +118,10 @@ def test_unix(args):
>  for l in diff:
>  print(l, file=sys.stderr)
>  
> +if not total:
> +print ('Could not find any tests.')
> +return False
> +

We don't use spaces between the functions and braces.

Just raise an exception here, not finding any tests is just catastrophic
failure.

raise Exception('Could not find any tests.')

Dylan

>  print('{}/{}'.format(passed, total), 'tests returned correct results')
>  return total == passed
>  
> @@ -154,6 +158,10 @@ def _replace_test(args, replace):
>  for l in diff:
>  print(l, file=sys.stderr)
>  
> +if not total:
> +print ('Could not find any tests.')
> +return False
> +
>  print('{}/{}'.format(passed, total), 'tests returned correct results')
>  return total == passed
>  
> @@ -196,6 +204,10 @@ def test_valgrind(args):
>  print('FAIL')
>  print(log, file=sys.stderr)
>  
> +if not total:
> +print ('Could not find any tests.')
> +return False
> +
>  print('{}/{}'.format(passed, total), 'tests returned correct results')
>  return total == passed
>  
> -- 
> 2.16.0
> 


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

Re: [Mesa-dev] [PATCH 2/4] glsl: fold glcpp-test-cr-lf.sh into glcpp-test.sh

[Dylan Baker]

If you want to do these all at once that's fine, in meson we execute each mode
individually, that's also pretty easy in meson, and would require more work for
autotools, so this seems fine:
Reviewed-by: Dylan Baker 

Quoting Emil Velikov (2018-04-24 10:49:20)
> From: Emil Velikov 
> 
> As of recently both of these have been reworked so they invoke a python
> script. At the same time the latter can be executed with the combined
> arguments of both scripts.
> 
> AKA we no longer need to have them separate.
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/compiler/Makefile.glsl.am | 1 -
>  src/compiler/glsl/glcpp/tests/glcpp-test-cr-lf.sh | 3 ---
>  src/compiler/glsl/glcpp/tests/glcpp-test.sh   | 2 +-
>  3 files changed, 1 insertion(+), 5 deletions(-)
>  delete mode 100755 src/compiler/glsl/glcpp/tests/glcpp-test-cr-lf.sh
> 
> diff --git a/src/compiler/Makefile.glsl.am b/src/compiler/Makefile.glsl.am
> index ad19b14e44..02a7f43215 100644
> --- a/src/compiler/Makefile.glsl.am
> +++ b/src/compiler/Makefile.glsl.am
> @@ -31,7 +31,6 @@ EXTRA_DIST += glsl/tests glsl/glcpp/tests glsl/README \
> SConscript.glsl
>  
>  TESTS += glsl/glcpp/tests/glcpp-test.sh\
> -   glsl/glcpp/tests/glcpp-test-cr-lf.sh\
> glsl/tests/blob-test\
> glsl/tests/cache-test   \
> glsl/tests/general-ir-test  \
> diff --git a/src/compiler/glsl/glcpp/tests/glcpp-test-cr-lf.sh 
> b/src/compiler/glsl/glcpp/tests/glcpp-test-cr-lf.sh
> deleted file mode 100755
> index c41ee9f93f..00
> --- a/src/compiler/glsl/glcpp/tests/glcpp-test-cr-lf.sh
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -#!/bin/sh
> -
> -$PYTHON2 $srcdir/glsl/glcpp/tests/glcpp_test.py 
> $abs_builddir/glsl/glcpp/glcpp $srcdir/glsl/glcpp/tests --windows --oldmac 
> --bizarro
> diff --git a/src/compiler/glsl/glcpp/tests/glcpp-test.sh 
> b/src/compiler/glsl/glcpp/tests/glcpp-test.sh
> index 3925c4ab8c..7ca8aa26a8 100755
> --- a/src/compiler/glsl/glcpp/tests/glcpp-test.sh
> +++ b/src/compiler/glsl/glcpp/tests/glcpp-test.sh
> @@ -1,3 +1,3 @@
>  #!/bin/sh
>  
> -$PYTHON2 $srcdir/glsl/glcpp/tests/glcpp_test.py 
> $abs_builddir/glsl/glcpp/glcpp $srcdir/glsl/glcpp/tests --unix
> +$PYTHON2 $srcdir/glsl/glcpp/tests/glcpp_test.py 
> $abs_builddir/glsl/glcpp/glcpp $srcdir/glsl/glcpp/tests --unix --windows 
> --oldmac --bizarro
> -- 
> 2.16.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 3/4] glsl/glcpp/tests: reinstate srcdir/abs_builddir blurb

[Dylan Baker]

Sure,
Reviewed-by: Dylan Baker 

Quoting Emil Velikov (2018-04-24 10:49:21)
> From: Emil Velikov 
> 
> Bring back the "detection" of the said variables, to allow
> standalone execution.
> 
> Fixes: db8cd8e36771 ("glcpp/tests: Convert shell scripts to a python
> script")
> Cc: Dylan Baker 
> Signed-off-by: Emil Velikov 
> ---
>  src/compiler/glsl/glcpp/tests/glcpp-test.sh | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/src/compiler/glsl/glcpp/tests/glcpp-test.sh 
> b/src/compiler/glsl/glcpp/tests/glcpp-test.sh
> index 7ca8aa26a8..b8397ec890 100755
> --- a/src/compiler/glsl/glcpp/tests/glcpp-test.sh
> +++ b/src/compiler/glsl/glcpp/tests/glcpp-test.sh
> @@ -1,3 +1,16 @@
>  #!/bin/sh
>  
> +if [ -z "$srcdir" -o -z "$abs_builddir" ]; then
> +echo ""
> +echo "Warning: you're invoking the script manually and things may fail."
> +echo "Attempting to determine/set srcdir and abs_builddir variables."
> +echo ""
> +
> +# Should point to `dirname Makefile.glsl.am`
> +srcdir=./../../../
> +cd `dirname "$0"`
> +# Should point to `dirname Makefile` equivalent to the above.
> +abs_builddir=`pwd`/../../../
> +fi
> +
>  $PYTHON2 $srcdir/glsl/glcpp/tests/glcpp_test.py 
> $abs_builddir/glsl/glcpp/glcpp $srcdir/glsl/glcpp/tests --unix --windows 
> --oldmac --bizarro
> -- 
> 2.16.0
> 


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

Re: [Mesa-dev] [PATCH 1/4] glsl: remove execute bit/shebang from glcpp_test.py

[Dylan Baker]

Quoting Emil Velikov (2018-04-24 10:49:19)
> From: Emil Velikov 
> 
> Mesa explicitly manages the invocation of all python scripts.
> Do so here, by removing the shebang line alongside the execute bit of
> the newly introduced script.
> 
> Fixes: db8cd8e36771 ("glcpp/tests: Convert shell scripts to a python
> script")
> Cc: Dylan Baker 
> Signed-off-by: Emil Velikov 
> ---
> Suspecting that meson should be updated to use prog_python2, just not
> too sure how to handle that. Is using a custom_target() a wise move for
> tests?

You can't use custom_target() for tests, they have to be called via test().

> ---
>  src/compiler/glsl/glcpp/tests/glcpp_test.py | 1 -
>  1 file changed, 1 deletion(-)
>  mode change 100755 => 100644 src/compiler/glsl/glcpp/tests/glcpp_test.py
> 
> diff --git a/src/compiler/glsl/glcpp/tests/glcpp_test.py 
> b/src/compiler/glsl/glcpp/tests/glcpp_test.py
> old mode 100755
> new mode 100644
> index cdc63b3ac2..751bd40028
> --- a/src/compiler/glsl/glcpp/tests/glcpp_test.py
> +++ b/src/compiler/glsl/glcpp/tests/glcpp_test.py
> @@ -1,4 +1,3 @@
> -#!/usr/bin/env python2

No, this is how meson determines what program to use to run the exectuable. This
needs to be left alone. You'll either need to add a bunch of messy code to
meson to run this, or just leave this alone. It's really not hurting anything.

For build scripts I agree with your logic 100%, no one needs to be calling
those manually. For tests though it makes sense to me for a developer to be able
to call the offending test themselves, in case they want too look at one test at
a time, for example.

When I developed these I developed them by calling them manually, not by
invoking ninja test.

Dylan

>  # encoding=utf-8
>  # Copyright © 2018 Intel Corporation
>  
> -- 
> 2.16.0
> 


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

Re: [Mesa-dev] [PATCH v2 2/2] gallium/util: Android backtrace support

[Rob Herring]

On Sun, Apr 15, 2018 at 5:45 PM, Stefan Schake  wrote:
> We can't use any of the existing implementations in u_debug_stack.
> Android technically has libunwind, but it's been modified to the point
> where it no longer compiles with the Mesa usage. The library is also
> not meant to be referenced by vendor libraries. The officially sanctioned
> way of obtaining backtraces is through the Android own libbacktrace, a
> C++ library. Access it through a separate C++ source file on Android only.

I know this is committed already, but it was pointed out to me that
libbacktrace is not a visible library in Treble-ized builds. It is in
the vndk-sp-indirect list.

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

[Mesa-dev] [PATCH 3/4] glsl/glcpp/tests: reinstate srcdir/abs_builddir blurb

[Emil Velikov]

From: Emil Velikov 

Bring back the "detection" of the said variables, to allow
standalone execution.

Fixes: db8cd8e36771 ("glcpp/tests: Convert shell scripts to a python
script")
Cc: Dylan Baker 
Signed-off-by: Emil Velikov 
---
 src/compiler/glsl/glcpp/tests/glcpp-test.sh | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/compiler/glsl/glcpp/tests/glcpp-test.sh 
b/src/compiler/glsl/glcpp/tests/glcpp-test.sh
index 7ca8aa26a8..b8397ec890 100755
--- a/src/compiler/glsl/glcpp/tests/glcpp-test.sh
+++ b/src/compiler/glsl/glcpp/tests/glcpp-test.sh
@@ -1,3 +1,16 @@
 #!/bin/sh
 
+if [ -z "$srcdir" -o -z "$abs_builddir" ]; then
+echo ""
+echo "Warning: you're invoking the script manually and things may fail."
+echo "Attempting to determine/set srcdir and abs_builddir variables."
+echo ""
+
+# Should point to `dirname Makefile.glsl.am`
+srcdir=./../../../
+cd `dirname "$0"`
+# Should point to `dirname Makefile` equivalent to the above.
+abs_builddir=`pwd`/../../../
+fi
+
 $PYTHON2 $srcdir/glsl/glcpp/tests/glcpp_test.py $abs_builddir/glsl/glcpp/glcpp 
$srcdir/glsl/glcpp/tests --unix --windows --oldmac --bizarro
-- 
2.16.0

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

[Mesa-dev] [PATCH 4/4] glsl/tests/glcpp: reinstate "error out if no tests found"

[Emil Velikov]

From: Emil Velikov 

With the recent rework of converting the shell script to a python one
the check for actual tests was dropped.

Bring that back, since it was explicitly added considering we had a ~2
year period, during which the tests were not run.

Fixes: db8cd8e36771 ("glcpp/tests: Convert shell scripts to a python
script")
Cc: Dylan Baker 
Signed-off-by: Emil Velikov 
---
One might be interested in folding some of the duplication/boilerplate
at a later stage. I'm trying to bring back the normal behaviour for now
;-)
---
 src/compiler/glsl/glcpp/tests/glcpp_test.py | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/compiler/glsl/glcpp/tests/glcpp_test.py 
b/src/compiler/glsl/glcpp/tests/glcpp_test.py
index 751bd40028..cb0f16f4e7 100644
--- a/src/compiler/glsl/glcpp/tests/glcpp_test.py
+++ b/src/compiler/glsl/glcpp/tests/glcpp_test.py
@@ -118,6 +118,10 @@ def test_unix(args):
 for l in diff:
 print(l, file=sys.stderr)
 
+if not total:
+print ('Could not find any tests.')
+return False
+
 print('{}/{}'.format(passed, total), 'tests returned correct results')
 return total == passed
 
@@ -154,6 +158,10 @@ def _replace_test(args, replace):
 for l in diff:
 print(l, file=sys.stderr)
 
+if not total:
+print ('Could not find any tests.')
+return False
+
 print('{}/{}'.format(passed, total), 'tests returned correct results')
 return total == passed
 
@@ -196,6 +204,10 @@ def test_valgrind(args):
 print('FAIL')
 print(log, file=sys.stderr)
 
+if not total:
+print ('Could not find any tests.')
+return False
+
 print('{}/{}'.format(passed, total), 'tests returned correct results')
 return total == passed
 
-- 
2.16.0

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

[Mesa-dev] [PATCH 1/4] glsl: remove execute bit/shebang from glcpp_test.py

[Emil Velikov]

From: Emil Velikov 

Mesa explicitly manages the invocation of all python scripts.
Do so here, by removing the shebang line alongside the execute bit of
the newly introduced script.

Fixes: db8cd8e36771 ("glcpp/tests: Convert shell scripts to a python
script")
Cc: Dylan Baker 
Signed-off-by: Emil Velikov 
---
Suspecting that meson should be updated to use prog_python2, just not
too sure how to handle that. Is using a custom_target() a wise move for
tests?
---
 src/compiler/glsl/glcpp/tests/glcpp_test.py | 1 -
 1 file changed, 1 deletion(-)
 mode change 100755 => 100644 src/compiler/glsl/glcpp/tests/glcpp_test.py

diff --git a/src/compiler/glsl/glcpp/tests/glcpp_test.py 
b/src/compiler/glsl/glcpp/tests/glcpp_test.py
old mode 100755
new mode 100644
index cdc63b3ac2..751bd40028
--- a/src/compiler/glsl/glcpp/tests/glcpp_test.py
+++ b/src/compiler/glsl/glcpp/tests/glcpp_test.py
@@ -1,4 +1,3 @@
-#!/usr/bin/env python2
 # encoding=utf-8
 # Copyright © 2018 Intel Corporation
 
-- 
2.16.0

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

[Mesa-dev] [PATCH 2/4] glsl: fold glcpp-test-cr-lf.sh into glcpp-test.sh

[Emil Velikov]

From: Emil Velikov 

As of recently both of these have been reworked so they invoke a python
script. At the same time the latter can be executed with the combined
arguments of both scripts.

AKA we no longer need to have them separate.

Signed-off-by: Emil Velikov 
---
 src/compiler/Makefile.glsl.am | 1 -
 src/compiler/glsl/glcpp/tests/glcpp-test-cr-lf.sh | 3 ---
 src/compiler/glsl/glcpp/tests/glcpp-test.sh   | 2 +-
 3 files changed, 1 insertion(+), 5 deletions(-)
 delete mode 100755 src/compiler/glsl/glcpp/tests/glcpp-test-cr-lf.sh

diff --git a/src/compiler/Makefile.glsl.am b/src/compiler/Makefile.glsl.am
index ad19b14e44..02a7f43215 100644
--- a/src/compiler/Makefile.glsl.am
+++ b/src/compiler/Makefile.glsl.am
@@ -31,7 +31,6 @@ EXTRA_DIST += glsl/tests glsl/glcpp/tests glsl/README \
SConscript.glsl
 
 TESTS += glsl/glcpp/tests/glcpp-test.sh\
-   glsl/glcpp/tests/glcpp-test-cr-lf.sh\
glsl/tests/blob-test\
glsl/tests/cache-test   \
glsl/tests/general-ir-test  \
diff --git a/src/compiler/glsl/glcpp/tests/glcpp-test-cr-lf.sh 
b/src/compiler/glsl/glcpp/tests/glcpp-test-cr-lf.sh
deleted file mode 100755
index c41ee9f93f..00
--- a/src/compiler/glsl/glcpp/tests/glcpp-test-cr-lf.sh
+++ /dev/null
@@ -1,3 +0,0 @@
-#!/bin/sh
-
-$PYTHON2 $srcdir/glsl/glcpp/tests/glcpp_test.py $abs_builddir/glsl/glcpp/glcpp 
$srcdir/glsl/glcpp/tests --windows --oldmac --bizarro
diff --git a/src/compiler/glsl/glcpp/tests/glcpp-test.sh 
b/src/compiler/glsl/glcpp/tests/glcpp-test.sh
index 3925c4ab8c..7ca8aa26a8 100755
--- a/src/compiler/glsl/glcpp/tests/glcpp-test.sh
+++ b/src/compiler/glsl/glcpp/tests/glcpp-test.sh
@@ -1,3 +1,3 @@
 #!/bin/sh
 
-$PYTHON2 $srcdir/glsl/glcpp/tests/glcpp_test.py $abs_builddir/glsl/glcpp/glcpp 
$srcdir/glsl/glcpp/tests --unix
+$PYTHON2 $srcdir/glsl/glcpp/tests/glcpp_test.py $abs_builddir/glsl/glcpp/glcpp 
$srcdir/glsl/glcpp/tests --unix --windows --oldmac --bizarro
-- 
2.16.0

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

Re: [Mesa-dev] [PATCH] foo

[Emil Velikov]

Sent out the wrong patch, please ignore.

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

[Mesa-dev] [PATCH] st/dri: constify dri_fill_st_visual's screen

[Emil Velikov]

From: Emil Velikov 

As the function says - only the visual is changed.

Signed-off-by: Emil Velikov 
---
 src/gallium/state_trackers/dri/dri_screen.c | 3 ++-
 src/gallium/state_trackers/dri/dri_screen.h | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
b/src/gallium/state_trackers/dri/dri_screen.c
index aaee987077..374efbdf61 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -298,7 +298,8 @@ dri_fill_in_modes(struct dri_screen *screen)
  * Roughly the converse of dri_fill_in_modes.
  */
 void
-dri_fill_st_visual(struct st_visual *stvis, struct dri_screen *screen,
+dri_fill_st_visual(struct st_visual *stvis,
+   const struct dri_screen *screen,
const struct gl_config *mode)
 {
memset(stvis, 0, sizeof(*stvis));
diff --git a/src/gallium/state_trackers/dri/dri_screen.h 
b/src/gallium/state_trackers/dri/dri_screen.h
index 677e945e03..e410aa9c2f 100644
--- a/src/gallium/state_trackers/dri/dri_screen.h
+++ b/src/gallium/state_trackers/dri/dri_screen.h
@@ -127,7 +127,8 @@ dri_with_format(__DRIscreen * sPriv)
 }
 
 void
-dri_fill_st_visual(struct st_visual *stvis, struct dri_screen *screen,
+dri_fill_st_visual(struct st_visual *stvis,
+   const struct dri_screen *screen,
const struct gl_config *mode);
 
 void
-- 
2.16.0

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

[Mesa-dev] [PATCH] foo

[Emil Velikov]

Signed-off-by: Emil Velikov 
---
 meson_options.txt|  2 +-
 src/gallium/state_trackers/dri/dri_context.c | 13 ++---
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/meson_options.txt b/meson_options.txt
index a573290b77..d2fd440b37 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -238,7 +238,7 @@ option(
 option(
   'lmsensors',
   type : 'combo',
-  value : 'auto',
+  value : 'false',
   choices : ['auto', 'true', 'false'],
   description : 'Enable HUD lmsensors support.'
 )
diff --git a/src/gallium/state_trackers/dri/dri_context.c 
b/src/gallium/state_trackers/dri/dri_context.c
index fb307337a9..116372f7df 100644
--- a/src/gallium/state_trackers/dri/dri_context.c
+++ b/src/gallium/state_trackers/dri/dri_context.c
@@ -278,9 +278,16 @@ dri_make_current(__DRIcontext * cPriv,
 
++ctx->bind_count;
 
-   if (!draw && !read)
-  return ctx->stapi->make_current(ctx->stapi, ctx->st, NULL, NULL);
-   else if (!draw || !read)
+   if (!draw && !read) {
+  if (!ctx->stapi->make_current(ctx->stapi, ctx->st, NULL, NULL))
+ return GL_FALSE;
+
+  ctx->dPriv = NULL;
+  ctx->rPriv = NULL;
+  return GL_TRUE;
+   }
+
+   if (!draw || !read)
   return GL_FALSE;
 
if (ctx->dPriv != driDrawPriv) {
-- 
2.16.0

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

Re: [Mesa-dev] [PATCH] st/dri: Fix dangling pointer to a destroyed dri_drawable

[Marek Olšák]

On Tue, Apr 24, 2018 at 3:13 AM, Johan Helsing  wrote:

> Emil: Your alternative patch won't work because dri_make_current is not
> necessarily called with NULL after a buffer has been destroyed.
>
>
> The problematic sequence is a pattern we use in QtWayland:
>
>
> //create temporary context
>
> surface1 = eglCreateWindowSurface() <-- dri_drawable pointer is malloced
>
> eglMakeCurrent(surface1) <-- ctx->dPriv is set
>
>
> // ... (Get some information about available GL extensions etc)
>
>
> eglDestroySurface(surface1) <-- pointer is freed, ctx->dPriv is now
> dangling
>
> surface2 = eglCreateWindowSurface() <-- Creating a new surface. Sometimes
> it's address will be the same as the free'd pointer.
>
> eglMakeCurrent(surface2) <-- In dri_make_current, ctx->dPriv ==
> driReadPriv may return true because the pointers may be equal
>
>   => The drawable info is not updated. Width and height for the
> drawable is not set from the wl_egl_window on the first frame.
>
>
> Marek: How exactly does it crash? Are you sure firefox didn't previously
> access free'd memory through the dangling pointer and that it was just
> exposed now that the pointer is NULL?
>

ctx was a dangling pointer, which means ctx had been destroyed, and reading
ctx->dPriv crashed.

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

Re: [Mesa-dev] [PATCH] nir: Look into uniform structs for samplers when counting num_textures.

[Eric Anholt]

Eric Anholt  writes:

> mesa/st decides whether to update samplers after a program change based on
> whether num_textures is nonzero.  By not counting samplers in a uniform
> struct, we would segfault in
> KHR-GLES3.shaders.struct.uniform.sampler_vertex if it was run in the same
> context after a non-vertex-shader-uniform testcase (as is the case during
> a full conformance run).
>
> v2: Implement using two separate pure functions instead of updating
> pointers.

Jason, did you like this version?


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

Re: [Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

[Emil Velikov]

On 13 April 2018 at 11:00, Daniel Vetter  wrote:
> This tries to align with the X.org communities's long-standing
> tradition of trying to be an inclusive community and handing out
> commit rights fairly freely.
>
> We also tend to not revoke commit rights for people no longer
> regularly active in a given project, as long as they're still part of
> the larger community.
>
> Finally make sure that commit rights, like anything happening on fd.o
> infrastructre, is subject to the fd.o's Code of Conduct.
>
> v2: Point at MAINTAINERS for contact info (Daniel S.)
>
> v3:
> - Make it clear that commit rights are voluntary and that committers
>   need to acknowledge positively when they're nominated by someone
>   else (Keith).
> - Encourage committers to drop their commit rights when they're no
>   longer active, and make it clear they'll get readded (Keith).
> - Add a line that maintainers and committers should actively nominate
>   new committers (me).
>
> v4: Typo (Petri).
>
> v5: Typo (Sean).
>
> v6: Wording clarifications and spelling (Jani).
>
> v7: Require an explicit commitment to the documented merge criteria
> and rules, instead of just the implied one through the Code of Conduct
> threat (Jani).
>
> Acked-by: Alex Deucher 
> Acked-by: Arkadiusz Hiler 
> Acked-by: Daniel Stone 
> Acked-by: Eric Anholt 
> Acked-by: Gustavo Padovan 
> Acked-by: Petri Latvala 
> Cc: Alex Deucher 
> Cc: Arkadiusz Hiler 
> Cc: Ben Widawsky 
> Cc: Daniel Stone 
> Cc: Dave Airlie 
> Cc: Eric Anholt 
> Cc: Gustavo Padovan 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Keith Packard 
> Cc: Kenneth Graunke 
> Cc: Kristian H. Kristensen 
> Cc: Maarten Lankhorst 
> Cc: Petri Latvala 
> Cc: Rodrigo Vivi 
> Cc: Sean Paul 
> Reviewed-by: Keith Packard 
> Signed-off-by: Daniel Vetter 
> ---
> If you wonder about the wide distribution list for an igt patch: I'd
> like to start a discussions about x.org community norms around commit
> rights at large, at least for all the shared repos. I plan to propose
> the same text for drm-misc and libdrm too, and hopefully others like
> mesa/xserver/wayland would follow.
>
I think the idea is pretty good, simply highlighting some bits.

What you've outlined in this patch has been in practise for many years:
 a) undocumented, applicable to most xorg projects [1]
 b) documented, mesa

IMHO having this explicitly documented and others
(wayland/weston/wayland-protocols and xserver repos) following suite
is a big plus.

HTH
Emil

[1] As in all of https://cgit.freedesktop.org/xorg but xserver
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] spirv: Don’t check for NaN for most OpFOrd* comparisons

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Tue, Apr 24, 2018 at 7:55 AM, Neil Roberts  wrote:
> For all of the OpFOrd* comparisons except OpFOrdNotEqual the hardware
> should probably already return false if one of the operands is NaN so
> we don’t need to have an explicit check for it. This seems to at least
> work on Intel hardware. This should reduce the number of instructions
> generated for the most common comparisons.
>
> For what it’s worth, the original code to handle this was added in
> e062eb6415de3a. The commit message for that says that it was to fix
> some CTS tests for OpFUnord* opcodes. Even if the hardware doesn’t
> handle NaNs this patch shouldn’t affect those tests. At any rate they
> have since been moved out of the mustpass list. Incidentally those
> tests fail on the nvidia proprietary driver so it doesn’t seem like
> handling NaNs correctly is a priority.
> ---
>
> I made a VkRunner test case for all of the OpFOrd* and OpFUnord*
> opcodes with and without NaNs on the test branch. It can be run like
> this:
>
> git clone -b tests https://github.com/Igalia/vkrunner.git
> cd vkrunner
> ./autogen.sh && make -j8
> ./src/vkrunner examples/unordered-comparison.shader_test
>
>  src/compiler/spirv/vtn_alu.c | 17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
> index 71e743cdd1e..3134849ba90 100644
> --- a/src/compiler/spirv/vtn_alu.c
> +++ b/src/compiler/spirv/vtn_alu.c
> @@ -597,23 +597,18 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
>break;
> }
>
> -   case SpvOpFOrdEqual:
> -   case SpvOpFOrdNotEqual:
> -   case SpvOpFOrdLessThan:
> -   case SpvOpFOrdGreaterThan:
> -   case SpvOpFOrdLessThanEqual:
> -   case SpvOpFOrdGreaterThanEqual: {
> +   case SpvOpFOrdNotEqual: {
> +  /* For all the SpvOpFOrd* comparisons apart from NotEqual, the value
> +   * from the ALU will probably already be false if the operands are not
> +   * ordered so we don’t need to handle it specially.
> +   */
>bool swap;
>unsigned src_bit_size = glsl_get_bit_size(vtn_src[0]->type);
>unsigned dst_bit_size = glsl_get_bit_size(type);
>nir_op op = vtn_nir_alu_op_for_spirv_opcode(b, opcode, ,
>src_bit_size, 
> dst_bit_size);
>
> -  if (swap) {
> - nir_ssa_def *tmp = src[0];
> - src[0] = src[1];
> - src[1] = tmp;
> -  }
> +  assert(!swap);
>
>val->ssa->def =
>   nir_iand(>nb,
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] radv: only disable out-of-order rast for perfect occlusion queries

[Bas Nieuwenhuizen]

On Tue, Apr 24, 2018 at 8:06 AM, Samuel Pitoiset
 wrote:
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 18 ++
>  src/amd/vulkan/radv_query.c  |  4 ++--
>  2 files changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index baab8db617..baa28d408b 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -1334,6 +1334,7 @@ radv_emit_index_buffer(struct radv_cmd_buffer 
> *cmd_buffer)
>
>  void radv_set_db_count_control(struct radv_cmd_buffer *cmd_buffer)
>  {
> +   bool has_perfect_queries = 
> cmd_buffer->state.perfect_occlusion_queries_enabled;
> struct radv_pipeline *pipeline = cmd_buffer->state.pipeline;
> uint32_t pa_sc_mode_cntl_1 =
> pipeline ? pipeline->graphics.ms.pa_sc_mode_cntl_1 : 0;
> @@ -1342,11 +1343,12 @@ void radv_set_db_count_control(struct radv_cmd_buffer 
> *cmd_buffer)
> if(!cmd_buffer->state.active_occlusion_queries) {
> if (cmd_buffer->device->physical_device->rad_info.chip_class 
> >= CIK) {
> if 
> (G_028A4C_OUT_OF_ORDER_PRIMITIVE_ENABLE(pa_sc_mode_cntl_1) &&
> -   
> pipeline->graphics.disable_out_of_order_rast_for_occlusion) {
> +   
> pipeline->graphics.disable_out_of_order_rast_for_occlusion &&
> +   has_perfect_queries) {
> /* Re-enable out-of-order rasterization if the
>  * bound pipeline supports it and if it's has
> -* been disabled before starting occlusion
> -* queries.
> +* been disabled before starting any perfect
> +* occlusion queries.
>  */
> radeon_set_context_reg(cmd_buffer->cs,
>
> R_028A4C_PA_SC_MODE_CNTL_1,
> @@ -1359,22 +1361,22 @@ void radv_set_db_count_control(struct radv_cmd_buffer 
> *cmd_buffer)
> } else {
> const struct radv_subpass *subpass = 
> cmd_buffer->state.subpass;
> uint32_t sample_rate = subpass ? 
> util_logbase2(subpass->max_sample_count) : 0;
> -   bool perfect = 
> cmd_buffer->state.perfect_occlusion_queries_enabled;
>
> if (cmd_buffer->device->physical_device->rad_info.chip_class 
> >= CIK) {
> db_count_control =
> -   S_028004_PERFECT_ZPASS_COUNTS(perfect) |
> +   
> S_028004_PERFECT_ZPASS_COUNTS(has_perfect_queries) |
> S_028004_SAMPLE_RATE(sample_rate) |
> S_028004_ZPASS_ENABLE(1) |
> S_028004_SLICE_EVEN_ENABLE(1) |
> S_028004_SLICE_ODD_ENABLE(1);
>
> if 
> (G_028A4C_OUT_OF_ORDER_PRIMITIVE_ENABLE(pa_sc_mode_cntl_1) &&
> -   
> pipeline->graphics.disable_out_of_order_rast_for_occlusion) {
> +   
> pipeline->graphics.disable_out_of_order_rast_for_occlusion &&
> +   has_perfect_queries) {
> /* If the bound pipeline has enabled
>  * out-of-order rasterization, we should
> -* disable it before starting occlusion
> -* queries.
> +* disable it before starting any perfect
> +* occlusion queries.
>  */
> pa_sc_mode_cntl_1 &= 
> C_028A4C_OUT_OF_ORDER_PRIMITIVE_ENABLE;
>
> diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
> index 859a4a1d68..2b2e80f4e5 100644
> --- a/src/amd/vulkan/radv_query.c
> +++ b/src/amd/vulkan/radv_query.c
> @@ -1140,12 +1140,12 @@ static void emit_end_query(struct radv_cmd_buffer 
> *cmd_buffer,
>
> cmd_buffer->state.active_occlusion_queries--;
> if (cmd_buffer->state.active_occlusion_queries == 0) {
> +   radv_set_db_count_control(cmd_buffer);
> +

Why move this forward?
> /* Reset the perfect occlusion queries hint now that 
> no
>  * queries are active.
>  */
> cmd_buffer->state.perfect_occlusion_queries_enabled = 
> false;
> -
> -   radv_set_db_count_control(cmd_buffer);
> }
>
> radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 2, 0));
> --
> 2.17.0
>
> ___
> mesa-dev mailing list

[Mesa-dev] [Bug 106197] plasma wayland cant create platform surface with mesa 18.1.0 rc1

[bugzilla-daemon]

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

--- Comment #2 from farmboy0+freedesk...@googlemail.com ---
Created attachment 139066
  --> https://bugs.freedesktop.org/attachment.cgi?id=139066=edit
build log

As far as I can see GBM is enabled.

-- 
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 106209] [opencl] [llvm-svn] build failure undefined reference to `clang::FrontendTimesIsEnabled'

[bugzilla-daemon]

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

Aaron Watry  changed:

   What|Removed |Added

 Blocks||99553


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99553
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] meson: don't build classic mesa tests without dri_drivers

[Eric Anholt]

Dylan Baker  writes:

> Since mesa_classic is not build-on-demand the tests will create a demand
> and add a bunch of extra compilation.

s/not //?

Other than that, the series is

Reviewed-by: Eric Anholt 


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

Re: [Mesa-dev] NIR issue with SPIRV ops that have operands with different bit-size

[Neil Roberts]

Rob Clark  writes:

> Karol hit the same thing (with for example, shift instructions) with
> the work for spv compute/kernel support.  I *think* the number of
> special cases isn't too high, so probably vtn should just insert the
> appropriate conversion instruction (ie. u2u32, etc) so that if the src
> bitsize is incorrect it will be converted.

For what it’s worth, I also added a conversion instruction like this for
the Refract GLSL extension opcode because its eta argument can have a
different size:

https://github.com/Igalia/mesa/commit/608d70bc02a968ee2b21a5db0f54

Regards,
- Neil


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

[Mesa-dev] [PATCH 2/2] draw: fix different sign logic when clipping

[sroland]

From: Roland Scheidegger 

The logic was flawed, since mul(x,y) will be <= 0 (exactly 0) when
the sign is the same but both numbers are sufficiently small
(if the product is smaller than 2^-128).
This could apparently lead to emitting a sufficient amount of
additional bogus vertices to overflow the allocated array for them,
hitting an assertion (still safe with release builds since we just
aborted clipping after the assertion in this case - I'm however unsure
if this is now really no longer possible, so that code stays).
Not sure if the additional vertices could cause other grief, I didn't
see anything wrong even when hitting the assertion.

Essentially, both +-0 are treated as positive (the vertex is considered
to be inside the clip volume for this plane), so integrate the logic
determining different sign into the branch there.
---
 src/gallium/auxiliary/draw/draw_pipe_clip.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c 
b/src/gallium/auxiliary/draw/draw_pipe_clip.c
index b7a1b5c..6af5c09 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_clip.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_clip.c
@@ -47,11 +47,6 @@
 /** Set to 1 to enable printing of coords before/after clipping */
 #define DEBUG_CLIP 0
 
-
-#ifndef DIFFERENT_SIGNS
-#define DIFFERENT_SIGNS(x, y) ((x) * (y) <= 0.0F && (x) - (y) != 0.0F)
-#endif
-
 #define MAX_CLIPPED_VERTICES ((2 * (6 + PIPE_MAX_CLIP_PLANES))+1)
 
 
@@ -479,6 +474,7 @@ do_clip_tri(struct draw_stage *stage,
   for (i = 1; i <= n; i++) {
  struct vertex_header *vert = inlist[i];
  boolean *edge = [i];
+ boolean different_sign;
 
  float dp = getclipdist(clipper, vert, plane_idx);
 
@@ -491,9 +487,12 @@ do_clip_tri(struct draw_stage *stage,
return;
 outEdges[outcount] = *edge_prev;
 outlist[outcount++] = vert_prev;
+different_sign = dp < 0.0f;
+ } else {
+different_sign = !(dp < 0.0f);
  }
 
- if (DIFFERENT_SIGNS(dp, dp_prev)) {
+ if (different_sign) {
 struct vertex_header *new_vert;
 boolean *new_edge;
 
@@ -511,7 +510,7 @@ do_clip_tri(struct draw_stage *stage,
 
 if (dp < 0.0f) {
/* Going out of bounds.  Avoid division by zero as we
-* know dp != dp_prev from DIFFERENT_SIGNS, above.
+* know dp != dp_prev from different_sign, above.
 */
float t = dp / (dp - dp_prev);
interp( clipper, new_vert, t, vert, vert_prev, viewport_index );
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/2] draw: simplify clip null tri logic

[sroland]

From: Roland Scheidegger 

Simplifies the logic when to emit null tris (albeit the reasons why we
have to do this remain unclear).
This is strictly just logic simplification, the behavior doesn't change
at all.
---
 src/gallium/auxiliary/draw/draw_pipe_clip.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c 
b/src/gallium/auxiliary/draw/draw_pipe_clip.c
index 4cfa54b..b7a1b5c 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_clip.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_clip.c
@@ -253,7 +253,7 @@ static void emit_poly(struct draw_stage *stage,
unsigned i;
ushort edge_first, edge_middle, edge_last;
boolean last_tri_was_null = FALSE;
-   boolean tri_was_not_null = FALSE;
+   boolean tri_emitted = FALSE;
 
if (stage->draw->rasterizer->flatshade_first) {
   edge_first  = DRAW_PIPE_EDGE_FLAG_0;
@@ -289,17 +289,16 @@ static void emit_poly(struct draw_stage *stage,
   }
 
   tri_null = is_tri_null(clipper, );
-  /* If we generated a triangle with an area, aka. non-null triangle,
-   * or if the previous triangle was also null then skip all subsequent
-   * null triangles */
-  if ((tri_was_not_null && tri_null) || (last_tri_was_null && tri_null)) {
- last_tri_was_null = tri_null;
+  /*
+   * If we ever generated a tri (regardless if it had area or not),
+   * skip all subsequent null tris.
+   * FIXME: it is unclear why we always have to emit at least one
+   * tri. Maybe this is hiding bugs elsewhere.
+   */
+  if (tri_null && tri_emitted) {
  continue;
   }
-  last_tri_was_null = tri_null;
-  if (!tri_null) {
- tri_was_not_null = TRUE;
-  }
+  tri_emitted = TRUE;
 
   if (!edgeflags[i-1]) {
  header.flags &= ~edge_middle;
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH v2 06/12] glcpp/tests: Convert shell scripts to a python script

[Dylan Baker]

Quoting Juan A. Suarez Romero (2018-04-24 01:59:26)
> On Fri, 2018-04-20 at 10:23 -0700, Dylan Baker wrote:
> > Quoting Juan A. Suarez Romero (2018-04-20 10:18:03)
> > > On Thu, 2018-04-05 at 14:51 -0700, Dylan Baker wrote:
> > > > This ports glcpp-test.sh and glcpp-test-cr-lf.sh to a python script that
> > > > accepts arguments for each line ending type. This should allow for
> > > > better reporting to users.
> > > > 
> > > > Signed-off-by: Dylan Baker 
> > > 
> > > Hi!
> > > 
> > > 
> > > I think this patch is causing failing tests in "macOs Make"
> > > 
> > > https://travis-ci.org/Igalia/release-mesa/builds/369006234
> > > 
> > > 
> > > J.A.
> > > 
> > 
> > Indeed it is. Vinson noticed it the other day and I just sent a patch to 
> > fix it
> > a few minutes ago :)
> > 
> 
> BTW, I think this failing is happening also on 18.1 branch, so probably you
> would like to nominate the fix for 18.1 stable release.
> 
> 
> J.A.
> 
> > Dylan

I pushed the fix yesterday, and it has a Fixes tag. Assuming that I did it
correctly this time and didn't use the parent tree instead of the parent
commit...

Dylan


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

[Mesa-dev] [PATCH 1/2] radv: only disable out-of-order rast for perfect occlusion queries

[Samuel Pitoiset]

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 18 ++
 src/amd/vulkan/radv_query.c  |  4 ++--
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index baab8db617..baa28d408b 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1334,6 +1334,7 @@ radv_emit_index_buffer(struct radv_cmd_buffer *cmd_buffer)
 
 void radv_set_db_count_control(struct radv_cmd_buffer *cmd_buffer)
 {
+   bool has_perfect_queries = 
cmd_buffer->state.perfect_occlusion_queries_enabled;
struct radv_pipeline *pipeline = cmd_buffer->state.pipeline;
uint32_t pa_sc_mode_cntl_1 =
pipeline ? pipeline->graphics.ms.pa_sc_mode_cntl_1 : 0;
@@ -1342,11 +1343,12 @@ void radv_set_db_count_control(struct radv_cmd_buffer 
*cmd_buffer)
if(!cmd_buffer->state.active_occlusion_queries) {
if (cmd_buffer->device->physical_device->rad_info.chip_class >= 
CIK) {
if 
(G_028A4C_OUT_OF_ORDER_PRIMITIVE_ENABLE(pa_sc_mode_cntl_1) &&
-   
pipeline->graphics.disable_out_of_order_rast_for_occlusion) {
+   
pipeline->graphics.disable_out_of_order_rast_for_occlusion &&
+   has_perfect_queries) {
/* Re-enable out-of-order rasterization if the
 * bound pipeline supports it and if it's has
-* been disabled before starting occlusion
-* queries.
+* been disabled before starting any perfect
+* occlusion queries.
 */
radeon_set_context_reg(cmd_buffer->cs,
   
R_028A4C_PA_SC_MODE_CNTL_1,
@@ -1359,22 +1361,22 @@ void radv_set_db_count_control(struct radv_cmd_buffer 
*cmd_buffer)
} else {
const struct radv_subpass *subpass = cmd_buffer->state.subpass;
uint32_t sample_rate = subpass ? 
util_logbase2(subpass->max_sample_count) : 0;
-   bool perfect = 
cmd_buffer->state.perfect_occlusion_queries_enabled;
 
if (cmd_buffer->device->physical_device->rad_info.chip_class >= 
CIK) {
db_count_control =
-   S_028004_PERFECT_ZPASS_COUNTS(perfect) |
+   
S_028004_PERFECT_ZPASS_COUNTS(has_perfect_queries) |
S_028004_SAMPLE_RATE(sample_rate) |
S_028004_ZPASS_ENABLE(1) |
S_028004_SLICE_EVEN_ENABLE(1) |
S_028004_SLICE_ODD_ENABLE(1);
 
if 
(G_028A4C_OUT_OF_ORDER_PRIMITIVE_ENABLE(pa_sc_mode_cntl_1) &&
-   
pipeline->graphics.disable_out_of_order_rast_for_occlusion) {
+   
pipeline->graphics.disable_out_of_order_rast_for_occlusion &&
+   has_perfect_queries) {
/* If the bound pipeline has enabled
 * out-of-order rasterization, we should
-* disable it before starting occlusion
-* queries.
+* disable it before starting any perfect
+* occlusion queries.
 */
pa_sc_mode_cntl_1 &= 
C_028A4C_OUT_OF_ORDER_PRIMITIVE_ENABLE;
 
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 859a4a1d68..2b2e80f4e5 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1140,12 +1140,12 @@ static void emit_end_query(struct radv_cmd_buffer 
*cmd_buffer,
 
cmd_buffer->state.active_occlusion_queries--;
if (cmd_buffer->state.active_occlusion_queries == 0) {
+   radv_set_db_count_control(cmd_buffer);
+
/* Reset the perfect occlusion queries hint now that no
 * queries are active.
 */
cmd_buffer->state.perfect_occlusion_queries_enabled = 
false;
-
-   radv_set_db_count_control(cmd_buffer);
}
 
radeon_emit(cs, PKT3(PKT3_EVENT_WRITE, 2, 0));
-- 
2.17.0

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

[Mesa-dev] [PATCH 2/2] radv: enable out-of-order rasterization by default

[Samuel Pitoiset]

As the implementation is conservative, we can now enable it
by default. It can be disabled with RADV_DEBUG=nooutoforder.

Don't expect much more than 1% of improvements, but the gain
seems consistent.

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

diff --git a/src/amd/vulkan/radv_debug.h b/src/amd/vulkan/radv_debug.h
index 03f218fcda..9dda9b6b0c 100644
--- a/src/amd/vulkan/radv_debug.h
+++ b/src/amd/vulkan/radv_debug.h
@@ -44,6 +44,7 @@ enum {
RADV_DEBUG_NO_SISCHED= 0x4000,
RADV_DEBUG_PREOPTIR  = 0x8000,
RADV_DEBUG_NO_DYNAMIC_BOUNDS = 0x1,
+   RADV_DEBUG_NO_OUT_OF_ORDER   = 0x2,
 };
 
 enum {
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 25c0d47da8..a7d1b8ee37 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -315,7 +315,7 @@ radv_physical_device_init(struct radv_physical_device 
*device,
device->has_out_of_order_rast = device->rad_info.chip_class >= VI &&
device->rad_info.max_se >= 2;
device->out_of_order_rast_allowed = device->has_out_of_order_rast &&
-   (device->instance->perftest_flags & 
RADV_PERFTEST_OUT_OF_ORDER);
+   !(device->instance->debug_flags & 
RADV_DEBUG_NO_OUT_OF_ORDER);
 
device->dcc_msaa_allowed = device->rad_info.chip_class == VI &&
   (device->instance->perftest_flags & 
RADV_PERFTEST_DCC_MSAA);
@@ -390,6 +390,7 @@ static const struct debug_control radv_debug_options[] = {
{"nosisched", RADV_DEBUG_NO_SISCHED},
{"preoptir", RADV_DEBUG_PREOPTIR},
{"nodynamicbounds", RADV_DEBUG_NO_DYNAMIC_BOUNDS},
+   {"nooutoforder", RADV_DEBUG_NO_OUT_OF_ORDER},
{NULL, 0}
 };
 
@@ -405,7 +406,6 @@ static const struct debug_control radv_perftest_options[] = 
{
{"sisched", RADV_PERFTEST_SISCHED},
{"localbos", RADV_PERFTEST_LOCAL_BOS},
{"binning", RADV_PERFTEST_BINNING},
-   {"outoforderrast", RADV_PERFTEST_OUT_OF_ORDER},
{"dccmsaa", RADV_PERFTEST_DCC_MSAA},
{NULL, 0}
 };
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH 03/11] i965/compiler: handle conversion to smaller type in the lowering pass for that

[Jason Ekstrand]

On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga 
wrote:

> The lowering pass was specialized to act on 64-bit to 32-bit conversions
> only,
> but the implementation is valid for other cases.
> ---
>  src/intel/compiler/brw_fs_lower_conversions.cpp |  5 -
>  src/intel/compiler/brw_fs_nir.cpp   | 14 +++---
>  2 files changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_lower_conversions.cpp
> b/src/intel/compiler/brw_fs_lower_conversions.cpp
> index 663c9674c49..f95b39d3e86 100644
> --- a/src/intel/compiler/brw_fs_lower_conversions.cpp
> +++ b/src/intel/compiler/brw_fs_lower_conversions.cpp
> @@ -54,7 +54,7 @@ fs_visitor::lower_conversions()
>bool saturate = inst->saturate;
>
>if (supports_type_conversion(inst)) {
> - if (get_exec_type_size(inst) == 8 && type_sz(inst->dst.type) <
> 8) {
> + if (type_sz(inst->dst.type) < get_exec_type_size(inst)) {
>  /* From the Broadwell PRM, 3D Media GPGPU, "Double Precision
> Float to
>   * Single Precision Float":
>   *
> @@ -64,6 +64,9 @@ fs_visitor::lower_conversions()
>   * So we need to allocate a temporary that's two registers,
> and then do
>   * a strided MOV to get the lower DWord of every Qword that
> has the
>   * result.
> + *
> + * This restriction applies, in general, whenever we convert
> to
> + * a type with a smaller bit-size.
>   */
>  fs_reg temp = ibld.vgrf(get_exec_type(inst));
>  fs_reg strided_temp = subscript(temp, dst.type, 0);
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index f40a3540e31..5e0dd37eefd 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -753,19 +753,9 @@ fs_visitor::nir_emit_alu(const fs_builder ,
> nir_alu_instr *instr)
> */
>
> case nir_op_f2f16_undef:
> -   case nir_op_i2i16:
> -   case nir_op_u2u16: {
> -  /* TODO: Fixing aligment rules for conversions from 32-bits to
> -   * 16-bit types should be moved to lower_conversions
> -   */
> -  fs_reg tmp = bld.vgrf(op[0].type, 1);
> -  tmp = subscript(tmp, result.type, 0);
> -  inst = bld.MOV(tmp, op[0]);
> -  inst->saturate = instr->dest.saturate;
> -  inst = bld.MOV(result, tmp);
> +  inst = bld.MOV(result, op[0]);
>inst->saturate = instr->dest.saturate;
>break;
>

It appears to me that we can move f2f16_undef to the block below as well.
Without or without that,

Reviewed-by: Jason Ekstrand 


> -   }
>
> case nir_op_f2f64:
> case nir_op_f2i64:
> @@ -803,6 +793,8 @@ fs_visitor::nir_emit_alu(const fs_builder ,
> nir_alu_instr *instr)
> case nir_op_f2u32:
> case nir_op_i2i32:
> case nir_op_u2u32:
> +   case nir_op_i2i16:
> +   case nir_op_u2u16:
>inst = bld.MOV(result, op[0]);
>inst->saturate = instr->dest.saturate;
>break;
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] spirv: Don’t check for NaN for most OpFOrd* comparisons

[Neil Roberts]

For all of the OpFOrd* comparisons except OpFOrdNotEqual the hardware
should probably already return false if one of the operands is NaN so
we don’t need to have an explicit check for it. This seems to at least
work on Intel hardware. This should reduce the number of instructions
generated for the most common comparisons.

For what it’s worth, the original code to handle this was added in
e062eb6415de3a. The commit message for that says that it was to fix
some CTS tests for OpFUnord* opcodes. Even if the hardware doesn’t
handle NaNs this patch shouldn’t affect those tests. At any rate they
have since been moved out of the mustpass list. Incidentally those
tests fail on the nvidia proprietary driver so it doesn’t seem like
handling NaNs correctly is a priority.
---

I made a VkRunner test case for all of the OpFOrd* and OpFUnord*
opcodes with and without NaNs on the test branch. It can be run like
this:

git clone -b tests https://github.com/Igalia/vkrunner.git
cd vkrunner
./autogen.sh && make -j8
./src/vkrunner examples/unordered-comparison.shader_test

 src/compiler/spirv/vtn_alu.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index 71e743cdd1e..3134849ba90 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -597,23 +597,18 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
   break;
}
 
-   case SpvOpFOrdEqual:
-   case SpvOpFOrdNotEqual:
-   case SpvOpFOrdLessThan:
-   case SpvOpFOrdGreaterThan:
-   case SpvOpFOrdLessThanEqual:
-   case SpvOpFOrdGreaterThanEqual: {
+   case SpvOpFOrdNotEqual: {
+  /* For all the SpvOpFOrd* comparisons apart from NotEqual, the value
+   * from the ALU will probably already be false if the operands are not
+   * ordered so we don’t need to handle it specially.
+   */
   bool swap;
   unsigned src_bit_size = glsl_get_bit_size(vtn_src[0]->type);
   unsigned dst_bit_size = glsl_get_bit_size(type);
   nir_op op = vtn_nir_alu_op_for_spirv_opcode(b, opcode, ,
   src_bit_size, dst_bit_size);
 
-  if (swap) {
- nir_ssa_def *tmp = src[0];
- src[0] = src[1];
- src[1] = tmp;
-  }
+  assert(!swap);
 
   val->ssa->def =
  nir_iand(>nb,
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH 02/11] intel/compiler: fix isign for 16-bit integers

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga 
wrote:

> We need to use 16-bit constants with 16-bit instructions,
> otherwise we get the following validation error:
>
> "Destination stride must be equal to the ratio of the sizes of
>  the execution data type to the destination type"
>
> Because the execution data type is 4B due to the 32-bit integer
> constant.
> ---
>  src/intel/compiler/brw_fs_nir.cpp | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index 6c4bcd1c113..f40a3540e31 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -863,17 +863,24 @@ fs_visitor::nir_emit_alu(const fs_builder ,
> nir_alu_instr *instr)
>break;
> }
>
> -   case nir_op_isign:
> +   case nir_op_isign: {
>/*  ASR(val, 31) -> negative val generates 0x (signed -1).
> *   -> non-negative val generates 0x.
> *  Predicated OR sets 1 if val is positive.
> */
> -  assert(nir_dest_bit_size(instr->dest.dest) < 64);
> -  bld.CMP(bld.null_reg_d(), op[0], brw_imm_d(0), BRW_CONDITIONAL_G);
> -  bld.ASR(result, op[0], brw_imm_d(31));
> -  inst = bld.OR(result, result, brw_imm_d(1));
> +  uint32_t bit_size = nir_dest_bit_size(instr->dest.dest);
> +  assert(bit_size == 32 || bit_size == 16);
> +
> +  fs_reg zero = bit_size == 32 ? brw_imm_d(0) : brw_imm_w(0);
> +  fs_reg one = bit_size == 32 ? brw_imm_d(1) : brw_imm_w(1);
> +  fs_reg shift = bit_size == 32 ? brw_imm_d(31) : brw_imm_w(15);
> +
> +  bld.CMP(bld.null_reg_d(), op[0], zero, BRW_CONDITIONAL_G);
> +  bld.ASR(result, op[0], shift);
> +  inst = bld.OR(result, result, one);
>inst->predicate = BRW_PREDICATE_NORMAL;
>break;
> +   }
>
> case nir_op_frcp:
>inst = bld.emit(SHADER_OPCODE_RCP, result, op[0]);
> --
> 2.14.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 01/11] intel/compiler: lower 16-bit integer extended math instructions

[Rob Clark]

side-note, not sure if it really effects what you are doing here, but
karol ran into some cases, like 8bit signed imax, which needs to be
"lowered" to 16b (or 32b) and converted back for hw that doesn't
support smaller than 16b (or 32b).  I think I have the same case with
ir3, which also has 16b but no 8b, (but he is a bit further along cl
cts than I am)..

I think there will be more of this sort of thing coming for more
instructions and for more than just 16b vs 32b.  So not sure if
writing rules for each in nir_opt_algebraic.py will be so fun..

BR,
-R

On Tue, Apr 24, 2018 at 9:56 AM, Jason Ekstrand  wrote:
> It may be useful to just use nir_algebraic for this.  We already do for trig
> workarounds.  It's more painful from a build-system perspective but, in
> general, the fewer hand-rolled algebraic lowering passes we have, the
> better.
>
> On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga 
> wrote:
>>
>> The hardware doesn't support 16-bit integer types, so we need to implement
>> these using 32-bit integer instructions and then convert the result back
>> to 16-bit.
>> ---
>>  src/intel/Makefile.sources|   1 +
>>  src/intel/compiler/brw_nir.c  |   2 +
>>  src/intel/compiler/brw_nir.h  |   2 +
>>  src/intel/compiler/brw_nir_lower_16bit_int_math.c | 108
>> ++
>>  src/intel/compiler/meson.build|   1 +
>>  5 files changed, 114 insertions(+)
>>  create mode 100644 src/intel/compiler/brw_nir_lower_16bit_int_math.c
>>
>> diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
>> index 91c71a8dfaf..2cd76961ea4 100644
>> --- a/src/intel/Makefile.sources
>> +++ b/src/intel/Makefile.sources
>> @@ -79,6 +79,7 @@ COMPILER_FILES = \
>> compiler/brw_nir_analyze_boolean_resolves.c \
>> compiler/brw_nir_analyze_ubo_ranges.c \
>> compiler/brw_nir_attribute_workarounds.c \
>> +   compiler/brw_nir_lower_16bit_int_math.c \
>> compiler/brw_nir_lower_cs_intrinsics.c \
>> compiler/brw_nir_opt_peephole_ffma.c \
>> compiler/brw_nir_tcs_workarounds.c \
>> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
>> index 69ab162f888..2e5754076ed 100644
>> --- a/src/intel/compiler/brw_nir.c
>> +++ b/src/intel/compiler/brw_nir.c
>> @@ -638,6 +638,8 @@ brw_preprocess_nir(const struct brw_compiler
>> *compiler, nir_shader *nir)
>>  nir_lower_isign64 |
>>  nir_lower_divmod64);
>>
>> +   brw_nir_lower_16bit_int_math(nir);
>> +
>> nir = brw_nir_optimize(nir, compiler, is_scalar);
>>
>> if (is_scalar) {
>> diff --git a/src/intel/compiler/brw_nir.h b/src/intel/compiler/brw_nir.h
>> index 03f52da08e5..6ba1a8bc654 100644
>> --- a/src/intel/compiler/brw_nir.h
>> +++ b/src/intel/compiler/brw_nir.h
>> @@ -152,6 +152,8 @@ void brw_nir_analyze_ubo_ranges(const struct
>> brw_compiler *compiler,
>>
>>  bool brw_nir_opt_peephole_ffma(nir_shader *shader);
>>
>> +bool brw_nir_lower_16bit_int_math(nir_shader *shader);
>> +
>>  nir_shader *brw_nir_optimize(nir_shader *nir,
>>   const struct brw_compiler *compiler,
>>   bool is_scalar);
>> diff --git a/src/intel/compiler/brw_nir_lower_16bit_int_math.c
>> b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
>> new file mode 100644
>> index 000..6876309a822
>> --- /dev/null
>> +++ b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
>> @@ -0,0 +1,108 @@
>> +/*
>> + * Copyright © 2018 Intel Corporation
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining
>> a
>> + * copy of this software and associated documentation files (the
>> "Software"),
>> + * to deal in the Software without restriction, including without
>> limitation
>> + * the rights to use, copy, modify, merge, publish, distribute,
>> sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the
>> next
>> + * paragraph) shall be included in all copies or substantial portions of
>> the
>> + * Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> EXPRESS OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
>> SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
>> OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> DEALINGS
>> + * IN THE SOFTWARE.
>> + */
>> +
>> +#include "brw_nir.h"
>> +#include "nir_builder.h"
>> +
>> +/**
>> + * Intel hardware doesn't support 16-bit integer Math instructions so
>> this
>> + 

Re: [Mesa-dev] [PATCH 4/4] intel/compiler: Add scheduler deps for instructions that implicitly read g0

[Mark Janes]

Ian Romanick  writes:

> On 04/23/2018 09:19 AM, Mark Janes wrote:
>> I enabled these tests, and could not make them fail in CI.
>
> Can I consider that a Tested-by?

Sorry, I should have been more explicit.  Yes, tested-by.

>> This bug may also be related:
>> 
>> https://bugs.freedesktop.org/show_bug.cgi?id=95009
>
> If none of these tests fail with this patch, I'm included to close them
> with a note to re-open if the failures return.
>
> I also plan to nominate this for stable.  I forgot to do that when I
> sent the patch originally.
>
>> Ian Romanick  writes:
>> 
>>> From: Ian Romanick 
>>>
>>> Otherwise the scheduler can move the writes after the reads.
>>>
>>> Signed-off-by: Ian Romanick 
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95012
>>> Cc: Mark Janes 
>>> Cc: Clayton A Craft 
>>> ---
>>> I'd really like to have this run on the CI with the tests from bugzill
>>> #95012 re-enabled.  I don't know how to do this on my own.  This series
>>> is also available at:
>>>
>>> https://cgit.freedesktop.org/~idr/mesa/log/?h=bug-95012.
>>>
>>>  src/intel/compiler/brw_ir_vec4.h | 25 
>>> 
>>>  src/intel/compiler/brw_schedule_instructions.cpp |  3 +++
>>>  2 files changed, 28 insertions(+)
>>>
>>> diff --git a/src/intel/compiler/brw_ir_vec4.h 
>>> b/src/intel/compiler/brw_ir_vec4.h
>>> index 95c5119c6c0..e401d8b4d16 100644
>>> --- a/src/intel/compiler/brw_ir_vec4.h
>>> +++ b/src/intel/compiler/brw_ir_vec4.h
>>> @@ -334,6 +334,31 @@ public:
>>>opcode != BRW_OPCODE_IF &&
>>>opcode != BRW_OPCODE_WHILE));
>>> }
>>> +
>>> +   bool reads_g0_implicitly() const
>>> +   {
>>> +  switch (opcode) {
>>> +  case SHADER_OPCODE_TEX:
>>> +  case SHADER_OPCODE_TXL:
>>> +  case SHADER_OPCODE_TXD:
>>> +  case SHADER_OPCODE_TXF:
>>> +  case SHADER_OPCODE_TXF_CMS_W:
>>> +  case SHADER_OPCODE_TXF_CMS:
>>> +  case SHADER_OPCODE_TXF_MCS:
>>> +  case SHADER_OPCODE_TXS:
>>> +  case SHADER_OPCODE_TG4:
>>> +  case SHADER_OPCODE_TG4_OFFSET:
>>> +  case SHADER_OPCODE_SAMPLEINFO:
>>> +  case VS_OPCODE_PULL_CONSTANT_LOAD:
>>> +  case GS_OPCODE_SET_PRIMITIVE_ID:
>>> +  case GS_OPCODE_GET_INSTANCE_ID:
>>> +  case SHADER_OPCODE_GEN4_SCRATCH_READ:
>>> +  case SHADER_OPCODE_GEN4_SCRATCH_WRITE:
>>> + return true;
>>> +  default:
>>> + return false;
>>> +  }
>>> +   }
>>>  };
>>>  
>>>  /**
>>> diff --git a/src/intel/compiler/brw_schedule_instructions.cpp 
>>> b/src/intel/compiler/brw_schedule_instructions.cpp
>>> index fa85045de74..f817142a8b5 100644
>>> --- a/src/intel/compiler/brw_schedule_instructions.cpp
>>> +++ b/src/intel/compiler/brw_schedule_instructions.cpp
>>> @@ -1267,6 +1267,9 @@ vec4_instruction_scheduler::calculate_deps()
>>>   }
>>>}
>>>  
>>> +  if (inst->reads_g0_implicitly())
>>> + add_dep(last_fixed_grf_write, n);
>>> +
>>>if (!inst->is_send_from_grf()) {
>>>   for (int i = 0; i < inst->mlen; i++) {
>>>  /* It looks like the MRF regs are released in the send
>>> -- 
>>> 2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/11] intel/compiler: lower 16-bit integer extended math instructions

[Jason Ekstrand]

It may be useful to just use nir_algebraic for this.  We already do for
trig workarounds.  It's more painful from a build-system perspective but,
in general, the fewer hand-rolled algebraic lowering passes we have, the
better.

On Wed, Apr 11, 2018 at 12:20 AM, Iago Toral Quiroga 
wrote:

> The hardware doesn't support 16-bit integer types, so we need to implement
> these using 32-bit integer instructions and then convert the result back
> to 16-bit.
> ---
>  src/intel/Makefile.sources|   1 +
>  src/intel/compiler/brw_nir.c  |   2 +
>  src/intel/compiler/brw_nir.h  |   2 +
>  src/intel/compiler/brw_nir_lower_16bit_int_math.c | 108
> ++
>  src/intel/compiler/meson.build|   1 +
>  5 files changed, 114 insertions(+)
>  create mode 100644 src/intel/compiler/brw_nir_lower_16bit_int_math.c
>
> diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
> index 91c71a8dfaf..2cd76961ea4 100644
> --- a/src/intel/Makefile.sources
> +++ b/src/intel/Makefile.sources
> @@ -79,6 +79,7 @@ COMPILER_FILES = \
> compiler/brw_nir_analyze_boolean_resolves.c \
> compiler/brw_nir_analyze_ubo_ranges.c \
> compiler/brw_nir_attribute_workarounds.c \
> +   compiler/brw_nir_lower_16bit_int_math.c \
> compiler/brw_nir_lower_cs_intrinsics.c \
> compiler/brw_nir_opt_peephole_ffma.c \
> compiler/brw_nir_tcs_workarounds.c \
> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> index 69ab162f888..2e5754076ed 100644
> --- a/src/intel/compiler/brw_nir.c
> +++ b/src/intel/compiler/brw_nir.c
> @@ -638,6 +638,8 @@ brw_preprocess_nir(const struct brw_compiler
> *compiler, nir_shader *nir)
>  nir_lower_isign64 |
>  nir_lower_divmod64);
>
> +   brw_nir_lower_16bit_int_math(nir);
> +
> nir = brw_nir_optimize(nir, compiler, is_scalar);
>
> if (is_scalar) {
> diff --git a/src/intel/compiler/brw_nir.h b/src/intel/compiler/brw_nir.h
> index 03f52da08e5..6ba1a8bc654 100644
> --- a/src/intel/compiler/brw_nir.h
> +++ b/src/intel/compiler/brw_nir.h
> @@ -152,6 +152,8 @@ void brw_nir_analyze_ubo_ranges(const struct
> brw_compiler *compiler,
>
>  bool brw_nir_opt_peephole_ffma(nir_shader *shader);
>
> +bool brw_nir_lower_16bit_int_math(nir_shader *shader);
> +
>  nir_shader *brw_nir_optimize(nir_shader *nir,
>   const struct brw_compiler *compiler,
>   bool is_scalar);
> diff --git a/src/intel/compiler/brw_nir_lower_16bit_int_math.c
> b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
> new file mode 100644
> index 000..6876309a822
> --- /dev/null
> +++ b/src/intel/compiler/brw_nir_lower_16bit_int_math.c
> @@ -0,0 +1,108 @@
> +/*
> + * Copyright © 2018 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> next
> + * paragraph) shall be included in all copies or substantial portions of
> the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include "brw_nir.h"
> +#include "nir_builder.h"
> +
> +/**
> + * Intel hardware doesn't support 16-bit integer Math instructions so this
> + * pass implements them in 32-bit and then converts the result back to
> 16-bit.
> + */
> +static void
> +lower_math_instr(nir_builder *bld, nir_alu_instr *alu, bool is_signed)
> +{
> +   const nir_op op = alu->op;
> +
> +   bld->cursor = nir_before_instr(>instr);
> +
> +   nir_ssa_def *srcs_32[4] = { NULL, NULL, NULL, NULL };
> +   const uint32_t num_inputs = nir_op_infos[op].num_inputs;
> +   for (uint32_t i = 0; i < num_inputs; i++) {
> +  nir_ssa_def *src = nir_ssa_for_alu_src(bld, alu, i);
> +  srcs_32[i] = is_signed ? nir_i2i32(bld, src) : nir_u2u32(bld, src);
> +   }
> +
> +   nir_ssa_def *dst_32 =
> +  nir_build_alu(bld, op, srcs_32[0], srcs_32[1], srcs_32[2],
> srcs_32[3]);
> +
> +   nir_ssa_def *dst_16 =
> +  is_signed ? 

[Mesa-dev] [Bug 106209] [opencl] [llvm-svn] build failure undefined reference to `clang::FrontendTimesIsEnabled'

[bugzilla-daemon]

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

--- Comment #2 from LoneVVolf  ---
Created attachment 139056
  --> https://bugs.freedesktop.org/attachment.cgi?id=139056=edit
configure / make output

-- 
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 106209] [opencl] [llvm-svn] build failure undefined reference to `clang::FrontendTimesIsEnabled'

[bugzilla-daemon]

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

--- Comment #1 from LoneVVolf  ---
Created attachment 139055
  --> https://bugs.freedesktop.org/attachment.cgi?id=139055=edit
autoreconf output

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

[Mesa-dev] [Bug 106209] [opencl] [llvm-svn] build failure undefined reference to `clang::FrontendTimesIsEnabled'

[bugzilla-daemon]

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

Bug ID: 106209
   Summary: [opencl] [llvm-svn] build failure   undefined
reference to `clang::FrontendTimesIsEnabled'
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: lonew...@xs4all.nl
QA Contact: mesa-dev@lists.freedesktop.org

mesa-git rev c2e159d050
llvm-svn rev r330683

using autotools,

  ./configure \
--prefix=/usr \
--sysconfdir=/etc \
--with-gallium-drivers=r300,r600,radeonsi,nouveau,svga,swrast,virgl \
--with-dri-drivers=i915,i965,r200,radeon,nouveau \
--with-platforms=x11,drm,surfaceless \
--with-vulkan-drivers=intel,radeon \
--enable-texture-float \
--enable-gallium-osmesa \
--enable-xa \
--enable-nine \
--disable-xvmc \
--enable-vdpau \
--enable-omx-bellagio \
--enable-opencl \
--enable-opencl-icd \
--enable-glx-tls \
--enable-libglvnd


omitting --enable-opencl and --enable-opencl-icd allows build to succeed .

-- 
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] NIR issue with SPIRV ops that have operands with different bit-size

[Jason Ekstrand]

On Tue, Apr 24, 2018 at 6:42 AM, Ian Romanick  wrote:

> On 04/24/2018 05:44 AM, Rob Clark wrote:
> > On Tue, Apr 24, 2018 at 4:24 AM, Samuel Iglesias Gonsálvez
> >  wrote:
> >> Hello,
> >>
> >> Recently, we have found problems between some SPIRV opcodes and NIR.
> >>
> >> SPIR-V allows opcodes to mix different bit-sizes for their operands,
> such as for some bitfield operations and other ops like bitwise shifts.
> >>
> >> In NIR, when the ALU opcode doesn't have specified bitsizes for their
> operands, it is expected to have both the same bitsize (see the assert in
> nir_build_alu() at nir_builder.h). I suppose this assumption comes from the
> time that NIR were only fed with GLSL IR but now with SPIR-V that assert is
> wrong.
> >>
> >> Instead of adding new variants for the opcodes (such as nir_op_ishl16,
> or so) to workaround the issue, I think it is needed to fix this by
> removing this assumption from NIR and its validator. I send this email to
> ask for ideas and to find the best way to handle this.
> >>
> >
> > Karol hit the same thing (with for example, shift instructions) with
> > the work for spv compute/kernel support.  I *think* the number of
> > special cases isn't too high, so probably vtn should just insert the
> > appropriate conversion instruction (ie. u2u32, etc) so that if the src
> > bitsize is incorrect it will be converted.
>
> That's what I was going to suggest.  I guess it's possible that some HW
> might benefit from using the smaller bit-size, but the code generator
> should be able to see through the conversions to get the smaller data.
>

Agreed.  I think most of these case should have no difference between the
theoretical new opcode and original + conversion.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] mesa: some C99 tidy ups for framebuffer.c

[Ian Romanick]

Patches 1 and 3 are

Reviewed-by: Ian Romanick 

On 04/24/2018 12:54 AM, Timothy Arceri wrote:
> ---
>  src/mesa/main/framebuffer.c | 18 +-
>  1 file changed, 5 insertions(+), 13 deletions(-)
> 
> diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
> index 249e775f8cb..211e97c33bd 100644
> --- a/src/mesa/main/framebuffer.c
> +++ b/src/mesa/main/framebuffer.c
> @@ -210,14 +210,12 @@ _mesa_destroy_framebuffer(struct gl_framebuffer *fb)
>  void
>  _mesa_free_framebuffer_data(struct gl_framebuffer *fb)
>  {
> -   GLuint i;
> -
> assert(fb);
> assert(fb->RefCount == 0);
>  
> simple_mtx_destroy(>Mutex);
>  
> -   for (i = 0; i < BUFFER_COUNT; i++) {
> +   for (unsigned i = 0; i < BUFFER_COUNT; i++) {
>struct gl_renderbuffer_attachment *att = >Attachment[i];
>if (att->Renderbuffer) {
>   _mesa_reference_renderbuffer(>Renderbuffer, NULL);
> @@ -280,8 +278,6 @@ void
>  _mesa_resize_framebuffer(struct gl_context *ctx, struct gl_framebuffer *fb,
>   GLuint width, GLuint height)
>  {
> -   GLuint i;
> -
> /* XXX I think we could check if the size is not changing
>  * and return early.
>  */
> @@ -289,7 +285,7 @@ _mesa_resize_framebuffer(struct gl_context *ctx, struct 
> gl_framebuffer *fb,
> /* Can only resize win-sys framebuffer objects */
> assert(_mesa_is_winsys_fbo(fb));
>  
> -   for (i = 0; i < BUFFER_COUNT; i++) {
> +   for (unsigned i = 0; i < BUFFER_COUNT; i++) {
>struct gl_renderbuffer_attachment *att = >Attachment[i];
>if (att->Type == GL_RENDERBUFFER_EXT && att->Renderbuffer) {
>   struct gl_renderbuffer *rb = att->Renderbuffer;
> @@ -427,13 +423,11 @@ void
>  _mesa_update_framebuffer_visual(struct gl_context *ctx,
>   struct gl_framebuffer *fb)
>  {
> -   GLuint i;
> -
> memset(>Visual, 0, sizeof(fb->Visual));
> fb->Visual.rgbMode = GL_TRUE; /* assume this */
>  
> /* find first RGB renderbuffer */
> -   for (i = 0; i < BUFFER_COUNT; i++) {
> +   for (unsigned i = 0; i < BUFFER_COUNT; i++) {
>if (fb->Attachment[i].Renderbuffer) {
>   const struct gl_renderbuffer *rb = fb->Attachment[i].Renderbuffer;
>   const GLenum baseFormat = _mesa_get_format_base_format(rb->Format);
> @@ -461,7 +455,7 @@ _mesa_update_framebuffer_visual(struct gl_context *ctx,
> }
>  
> fb->Visual.floatMode = GL_FALSE;
> -   for (i = 0; i < BUFFER_COUNT; i++) {
> +   for (unsigned i = 0; i < BUFFER_COUNT; i++) {
>if (fb->Attachment[i].Renderbuffer) {
>   const struct gl_renderbuffer *rb = fb->Attachment[i].Renderbuffer;
>   const mesa_format fmt = rb->Format;
> @@ -936,14 +930,12 @@ _mesa_get_read_renderbuffer_for_format(const struct 
> gl_context *ctx,
>  void
>  _mesa_print_framebuffer(const struct gl_framebuffer *fb)
>  {
> -   GLuint i;
> -
> fprintf(stderr, "Mesa Framebuffer %u at %p\n", fb->Name, (void *) fb);
> fprintf(stderr, "  Size: %u x %u  Status: %s\n", fb->Width, fb->Height,
> _mesa_enum_to_string(fb->_Status));
> fprintf(stderr, "  Attachments:\n");
>  
> -   for (i = 0; i < BUFFER_COUNT; i++) {
> +   for (unsigned i = 0; i < BUFFER_COUNT; i++) {
>const struct gl_renderbuffer_attachment *att = >Attachment[i];
>if (att->Type == GL_TEXTURE) {
>   const struct gl_texture_image *texImage = 
> att->Renderbuffer->TexImage;
> 

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

Re: [Mesa-dev] NIR issue with SPIRV ops that have operands with different bit-size

[Ian Romanick]

On 04/24/2018 05:44 AM, Rob Clark wrote:
> On Tue, Apr 24, 2018 at 4:24 AM, Samuel Iglesias Gonsálvez
>  wrote:
>> Hello,
>>
>> Recently, we have found problems between some SPIRV opcodes and NIR.
>>
>> SPIR-V allows opcodes to mix different bit-sizes for their operands, such as 
>> for some bitfield operations and other ops like bitwise shifts.
>>
>> In NIR, when the ALU opcode doesn't have specified bitsizes for their 
>> operands, it is expected to have both the same bitsize (see the assert in 
>> nir_build_alu() at nir_builder.h). I suppose this assumption comes from the 
>> time that NIR were only fed with GLSL IR but now with SPIR-V that assert is 
>> wrong.
>>
>> Instead of adding new variants for the opcodes (such as nir_op_ishl16, or 
>> so) to workaround the issue, I think it is needed to fix this by removing 
>> this assumption from NIR and its validator. I send this email to ask for 
>> ideas and to find the best way to handle this.
>>
> 
> Karol hit the same thing (with for example, shift instructions) with
> the work for spv compute/kernel support.  I *think* the number of
> special cases isn't too high, so probably vtn should just insert the
> appropriate conversion instruction (ie. u2u32, etc) so that if the src
> bitsize is incorrect it will be converted.

That's what I was going to suggest.  I guess it's possible that some HW
might benefit from using the smaller bit-size, but the code generator
should be able to see through the conversions to get the smaller data.

> BR,
> -R
> 
>> What do you think?
>>
>> Sam
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] mesa: merge the driver functions DrawBuffers and DrawBuffer

[Ian Romanick]

On 04/23/2018 08:23 PM, Timothy Arceri wrote:
> On 24/04/18 10:13, Dieter Nützel wrote:
>> Hello Timo,
>>
>> what about 2 and 3, #1 landed.
> 
> It turns out the old radeon classic drivers do make use of the param
> dropped in patch 2 so I've decided to drop that patch, although the use
> of that param might be a bug as the intel drivers changed their behavior
> to fix a bug (however it's not a simple change).

This sounds familiar, and I might have a patch for that.  Let me root
around in my git branches to see if I can find it...  I'm definitely in
favor of cleaning up a bunch of the dd interfaces.

> I'd still like to push patch 3 but it's tripping up some old hardware in
> Intels CI system. I'm not sure whats going on yet.
> 
>> Dieter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] intel/compiler: Add scheduler deps for instructions that implicitly read g0

[Ian Romanick]

On 04/23/2018 09:19 AM, Mark Janes wrote:
> I enabled these tests, and could not make them fail in CI.

Can I consider that a Tested-by?

> This bug may also be related:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=95009

If none of these tests fail with this patch, I'm included to close them
with a note to re-open if the failures return.

I also plan to nominate this for stable.  I forgot to do that when I
sent the patch originally.

> Ian Romanick  writes:
> 
>> From: Ian Romanick 
>>
>> Otherwise the scheduler can move the writes after the reads.
>>
>> Signed-off-by: Ian Romanick 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95012
>> Cc: Mark Janes 
>> Cc: Clayton A Craft 
>> ---
>> I'd really like to have this run on the CI with the tests from bugzill
>> #95012 re-enabled.  I don't know how to do this on my own.  This series
>> is also available at:
>>
>> https://cgit.freedesktop.org/~idr/mesa/log/?h=bug-95012.
>>
>>  src/intel/compiler/brw_ir_vec4.h | 25 
>> 
>>  src/intel/compiler/brw_schedule_instructions.cpp |  3 +++
>>  2 files changed, 28 insertions(+)
>>
>> diff --git a/src/intel/compiler/brw_ir_vec4.h 
>> b/src/intel/compiler/brw_ir_vec4.h
>> index 95c5119c6c0..e401d8b4d16 100644
>> --- a/src/intel/compiler/brw_ir_vec4.h
>> +++ b/src/intel/compiler/brw_ir_vec4.h
>> @@ -334,6 +334,31 @@ public:
>>opcode != BRW_OPCODE_IF &&
>>opcode != BRW_OPCODE_WHILE));
>> }
>> +
>> +   bool reads_g0_implicitly() const
>> +   {
>> +  switch (opcode) {
>> +  case SHADER_OPCODE_TEX:
>> +  case SHADER_OPCODE_TXL:
>> +  case SHADER_OPCODE_TXD:
>> +  case SHADER_OPCODE_TXF:
>> +  case SHADER_OPCODE_TXF_CMS_W:
>> +  case SHADER_OPCODE_TXF_CMS:
>> +  case SHADER_OPCODE_TXF_MCS:
>> +  case SHADER_OPCODE_TXS:
>> +  case SHADER_OPCODE_TG4:
>> +  case SHADER_OPCODE_TG4_OFFSET:
>> +  case SHADER_OPCODE_SAMPLEINFO:
>> +  case VS_OPCODE_PULL_CONSTANT_LOAD:
>> +  case GS_OPCODE_SET_PRIMITIVE_ID:
>> +  case GS_OPCODE_GET_INSTANCE_ID:
>> +  case SHADER_OPCODE_GEN4_SCRATCH_READ:
>> +  case SHADER_OPCODE_GEN4_SCRATCH_WRITE:
>> + return true;
>> +  default:
>> + return false;
>> +  }
>> +   }
>>  };
>>  
>>  /**
>> diff --git a/src/intel/compiler/brw_schedule_instructions.cpp 
>> b/src/intel/compiler/brw_schedule_instructions.cpp
>> index fa85045de74..f817142a8b5 100644
>> --- a/src/intel/compiler/brw_schedule_instructions.cpp
>> +++ b/src/intel/compiler/brw_schedule_instructions.cpp
>> @@ -1267,6 +1267,9 @@ vec4_instruction_scheduler::calculate_deps()
>>   }
>>}
>>  
>> +  if (inst->reads_g0_implicitly())
>> + add_dep(last_fixed_grf_write, n);
>> +
>>if (!inst->is_send_from_grf()) {
>>   for (int i = 0; i < inst->mlen; i++) {
>>  /* It looks like the MRF regs are released in the send
>> -- 
>> 2.14.3

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

[Mesa-dev] [Bug 106157] [Tracker] Mesa 18.1 release tracker

[bugzilla-daemon]

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

Darek  changed:

   What|Removed |Added

 CC||dz1125.bug.trac...@gmail.co
   ||m

--- Comment #3 from Darek  ---
Tested: 
mesa 18.1.0rc1
xorg-server 1.19.99.904 +
xserver-dri3-Fix-DRI3.2-support-for-drivers-other-than-modesetting-ddx.patch

Everything works as it should. Thank you!

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

[Mesa-dev] [Bug 106157] [Tracker] Mesa 18.1 release tracker

[bugzilla-daemon]

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

Daniel Stone  changed:

   What|Removed |Added

  Component|Other   |Drivers/X11

--- Comment #2 from Daniel Stone  ---
See https://lists.freedesktop.org/archives/xorg-devel/2018-April/056760.html
and replies.

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

[Mesa-dev] [Bug 106157] [Tracker] Mesa 18.1 release tracker

[bugzilla-daemon]

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

--- Comment #1 from Darek  ---
Description:
Some apps crash on startup (chromium, thunderbird, glxgears, eglgears_x11)

Additional info:
* package version(s)
mesa-18.1.0rc1 (tested also with mesa-git-18.2.0_devel.101822.4559aefb5c)-meson
build
xorg-server 1.19.99.904
xf86-video-nouveau-git 1.0.15.r5.gac8f7b9

* config and/or log files etc.
$ glxgears
X Error of failed request:  BadImplementation (server does not implement
operation)
  Major opcode of failed request:  149 ()
  Minor opcode of failed request:  7
  Serial number of failed request:  41
  Current serial number in output stream:  42
X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  149 ()
  Minor opcode of failed request:  4
  Resource id in failed request:  0xc6
  Serial number of failed request:  42
  Current serial number in output stream:  42

Downgrading to mesa-18.0.1 works as workaround.

-- 
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