Re: [Mesa-dev] [PATCH 1/2] mesa: add glRenderbufferStorage support for EXT_texture_norm16 formats

2018-07-24 Thread Tapani Pälli



On 07/24/2018 10:31 PM, Eric Anholt wrote:

Tapani Pälli  writes:


These bits were missing, found when extending the Piglit test.

Fixes: 7f467d4f73 "mesa: GL_EXT_texture_norm16 extension plumbing"
Signed-off-by: Tapani Pälli 


Aren't you missing the RGB16 and R/RG/RGB/RGBA16_SNORM cases here?  They
aren't required for rendering, but if the implementation supports them
we should answer correctly.



If I've understood correctly, SNORM ones are supported only with 
EXT_render_snorm so those ones I was planning to add separately. For 
RGB16 I guess we would need to query the driver. Not sure what would be 
the best way to achieve this, it seems that at least i965 relies on 
_mesa_query_internal_format_default which just says to support anything 
(is broken).


Thanks;

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


Re: [Mesa-dev] [PATCH 1/2] mesa: add glRenderbufferStorage support for EXT_texture_norm16 formats

2018-07-24 Thread Tapani Pälli



On 07/25/2018 12:45 AM, Nanley Chery wrote:

On Tue, Jul 24, 2018 at 08:58:20AM +0300, Tapani Pälli wrote:

These bits were missing, found when extending the Piglit test.

Fixes: 7f467d4f73 "mesa: GL_EXT_texture_norm16 extension plumbing"
Signed-off-by: Tapani Pälli 
---
  src/mesa/main/fbobject.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)



Shouldn't we also update is_format_color_renderable?


No need since these formats are not rejected by 
is_format_color_renderable. They were added previously to 
_mesa_is_es3_color_renderable.



Nonetheless, this series is an improvement and is
Reviewed-by: Nanley Chery 


Thanks!


diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index fa7a9361df..679e206c71 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1927,8 +1927,10 @@ _mesa_base_fbo_format(const struct gl_context *ctx, 
GLenum internalFormat)
 case GL_RGBA:
 case GL_RGBA2:
 case GL_RGBA12:
-   case GL_RGBA16:
return _mesa_is_desktop_gl(ctx) ? GL_RGBA : 0;
+   case GL_RGBA16:
+  return _mesa_is_desktop_gl(ctx) || _mesa_has_EXT_texture_norm16(ctx)
+ ? GL_RGBA : 0;
 case GL_RGB10_A2:
 case GL_SRGB8_ALPHA8_EXT:
return _mesa_is_desktop_gl(ctx) || _mesa_is_gles3(ctx) ? GL_RGBA : 0;
@@ -1963,15 +1965,17 @@ _mesa_base_fbo_format(const struct gl_context *ctx, 
GLenum internalFormat)
   ctx->Extensions.ARB_depth_buffer_float)
   ? GL_DEPTH_STENCIL : 0;
 case GL_RED:
+  return _mesa_has_ARB_texture_rg(ctx) ? GL_RED : 0;
 case GL_R16:
-  return _mesa_is_desktop_gl(ctx) && ctx->Extensions.ARB_texture_rg
+  return _mesa_has_ARB_texture_rg(ctx) || _mesa_has_EXT_texture_norm16(ctx)
   ? GL_RED : 0;
 case GL_R8:
return ctx->API != API_OPENGLES && ctx->Extensions.ARB_texture_rg
   ? GL_RED : 0;
 case GL_RG:
+  return _mesa_has_ARB_texture_rg(ctx) ? GL_RG : 0;
 case GL_RG16:
-  return _mesa_is_desktop_gl(ctx) && ctx->Extensions.ARB_texture_rg
+  return _mesa_has_ARB_texture_rg(ctx) || _mesa_has_EXT_texture_norm16(ctx)
   ? GL_RG : 0;
 case GL_RG8:
return ctx->API != API_OPENGLES && ctx->Extensions.ARB_texture_rg
--
2.14.4


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


Re: [Mesa-dev] [PATCH] r600: Scale integer valued texture border colors to float (v2)

2018-07-24 Thread Roland Scheidegger
Am 24.07.2018 um 21:27 schrieb Gert Wollny:
> It seems the hardware always expects floating point border color values
> [0,1] for unsigned, and [-1,1] for signed texture component, regardless
> of pixel type, but the border colors are passed according to texture
> component type. Hence, before submitting the border color, convert and
> scale it these ranges accordingly.
> 
> This doesn't seem to work for textures with 32 bit integer components
> though, here, it seems that the border color is always set to zero,
> regardless of the BORDER_COLOR_TYPE state set in Q_TEX_SAMPLER_WORD0_0.
> 
> v2: Simplyfy logic as suggested by Roland Schneidegger
> 
> Fixes:
>   dEQP-GLES31.functional.texture.border_clamp.formats.compressed*
>   dEQP-GLES31.functional.texture.border_clamp.formats.r* (non 32 bit integer)
>   dEQP-GLES31.functional.texture.border_clamp.per_axis_wrap_mode.texture_2d*
>  and a number of piglits out of 
>   piglit run gpu -t texture -t gather -t formats 
> 
> Signed-off-by: Gert Wollny 
> ---
>  src/gallium/drivers/r600/evergreen_state.c | 45 
> +-
>  1 file changed, 44 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/r600/evergreen_state.c 
> b/src/gallium/drivers/r600/evergreen_state.c
> index d100cfab1d..e7207a500b 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -2402,6 +2402,37 @@ static void evergreen_emit_cs_sampler_views(struct 
> r600_context *rctx, struct r6
>EG_FETCH_CONSTANTS_OFFSET_CS + 
> R600_MAX_CONST_BUFFERS, RADEON_CP_PACKET3_COMPUTE_MODE);
>  }
>  
> +static void evergreen_convert_border_color(union pipe_color_union *in,
> +   union pipe_color_union *out,
> +   enum pipe_format format)
> +{
> + if (util_format_is_pure_integer(format) &&
> +  !util_format_is_depth_or_stencil(format)) {
> + const struct util_format_description *d = 
> util_format_description(format);
> +
> + for (int i = 0; i < d->nr_channels; ++i) {
> + int cs = d->channel[i].size;
> + if (d->channel[i].type == UTIL_FORMAT_TYPE_SIGNED)
> + out->f[i] = (double)(in->i[i]) / ((1ul << (cs - 
> 1)) - 1 );
> + else if (d->channel[i].type == 
> UTIL_FORMAT_TYPE_UNSIGNED)
> + out->f[i] = (double)(in->ui[i]) / ((1ul << cs) 
> - 1 );
> + else
> + out->f[i] = 0;
> + }
> +
> + } else {
> + switch (format) {
> +  case PIPE_FORMAT_X24S8_UINT:
> +  case PIPE_FORMAT_X32_S8X24_UINT:
whitespace.

Looks alright to me (though as mentioned, I consider trying to fix up
border color a futile attempt on eg :-)).
btw I suppose it would apply to pre-eg chips as well? Not that I'd
suggest you fix it up there too ;-).

Reviewed-by: Roland Scheidegger 

> + out->f[0] = (double)(in->ui[0]) / 255.0;
> + out->f[1] = out->f[2] = out->f[3] = 0.0f;
> + break;
> + default:
> + memcpy(out->f, in->f, 4 * sizeof(float));
> + }
> + }
> +}
> +
>  static void evergreen_emit_sampler_states(struct r600_context *rctx,
>   struct r600_textures_info *texinfo,
>   unsigned resource_id_base,
> @@ -2410,6 +2441,8 @@ static void evergreen_emit_sampler_states(struct 
> r600_context *rctx,
>  {
>   struct radeon_cmdbuf *cs = rctx->b.gfx.cs;
>   uint32_t dirty_mask = texinfo->states.dirty_mask;
> + union pipe_color_union border_color = {{0,0,0,1}};
> + union pipe_color_union *border_color_ptr = _color;
>  
>   while (dirty_mask) {
>   struct r600_pipe_sampler_state *rstate;
> @@ -2418,6 +2451,16 @@ static void evergreen_emit_sampler_states(struct 
> r600_context *rctx,
>   rstate = texinfo->states.states[i];
>   assert(rstate);
>  
> + if (rstate->border_color_use) {
> + struct r600_pipe_sampler_view   *rview = 
> texinfo->views.views[i];
> + if (rview) {
> + 
> evergreen_convert_border_color(>border_color,
> +_color, 
> rview->base.format);
> + } else {
> + border_color_ptr = >border_color;
> + }
> + }
> +
>   radeon_emit(cs, PKT3(PKT3_SET_SAMPLER, 3, 0) | pkt_flags);
>   radeon_emit(cs, (resource_id_base + i) * 3);
>   radeon_emit_array(cs, rstate->tex_sampler_words, 3);
> @@ -2425,7 +2468,7 @@ static void evergreen_emit_sampler_states(struct 
> r600_context *rctx,
>   if (rstate->border_color_use) {
>   

Re: [Mesa-dev] [PATCH] nir: Add a couple of iand/ior optimizations

2018-07-24 Thread Jason Ekstrand
On Tue, Jul 24, 2018 at 5:41 PM Timothy Arceri 
wrote:

> On 24/07/18 00:10, Jason Ekstrand wrote:
> > On Mon, Jul 23, 2018 at 1:08 AM Timothy Arceri  > > wrote:
> >
> > Ian and I have been looking at these type of things recently. Ian has
> > started work on a pass to cover this stuff without having to add
> dozens
> > of these types of opts.
> >
> >
> https://lists.freedesktop.org/archives/mesa-dev/2018-July/200583.html
> >
> >
> > Does said pass work only on logical operations with booleans or also
> > regular bitwise operations?  This patch is for bitwise operations though
> > it naturally works with booleans.
>
> Good point. I replied to this too quickly without thinking too hard. In
> that case we should probably also add these similar opt which I have
> also come across:
>
> (('ior', ('ior', a, b), a), ('ior', a, b)),
> (('iand', ('iand', a, b), a), ('iand', a, b)),
>

Done.


> With those added:
>
> Reviewed-by: Timothy Arceri 
>

Thanks!


> >
> > --Jason
> >
> > On 23/07/18 17:36, Jason Ekstrand wrote:
> >  > Spotted in a shader in Batman: Arkham City.
> >  > ---
> >  >   src/compiler/nir/nir_opt_algebraic.py | 2 ++
> >  >   1 file changed, 2 insertions(+)
> >  >
> >  > diff --git a/src/compiler/nir/nir_opt_algebraic.py
> > b/src/compiler/nir/nir_opt_algebraic.py
> >  > index ba277fdfd0e..f2007852b21 100644
> >  > --- a/src/compiler/nir/nir_opt_algebraic.py
> >  > +++ b/src/compiler/nir/nir_opt_algebraic.py
> >  > @@ -377,6 +377,8 @@ optimizations = [
> >  >  (('ixor', a, a), 0),
> >  >  (('ixor', a, 0), a),
> >  >  (('inot', ('inot', a)), a),
> >  > +   (('ior', ('iand', a, b), b), b),
> >  > +   (('iand', ('ior', a, b), b), b),
> >  >  # DeMorgan's Laws
> >  >  (('iand', ('inot', a), ('inot', b)), ('inot', ('ior',  a,
> b))),
> >  >  (('ior',  ('inot', a), ('inot', b)), ('inot', ('iand', a,
> b))),
> >  >
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v2] clover: Reduce wait_count in abort path.

2018-07-24 Thread Jan Vesely
Trigger waiter condition variable.
Passes 'events' CTS on carrizo and turks.
v2: reduce to 0

Signed-off-by: Jan Vesely 
---
 src/gallium/state_trackers/clover/core/event.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/core/event.cpp 
b/src/gallium/state_trackers/clover/core/event.cpp
index b7eb33dbfc..3d313ce896 100644
--- a/src/gallium/state_trackers/clover/core/event.cpp
+++ b/src/gallium/state_trackers/clover/core/event.cpp
@@ -41,7 +41,7 @@ event::trigger_self() {
std::lock_guard lock(mutex);
std::vector> evs;
 
-   if (!--_wait_count)
+   if (_wait_count && !--_wait_count)
   std::swap(_chain, evs);
 
cv.notify_all();
@@ -65,8 +65,10 @@ event::abort_self(cl_int status) {
std::vector> evs;
 
_status = status;
+   _wait_count = 0;
std::swap(_chain, evs);
 
+   cv.notify_all();
return evs;
 }
 
-- 
2.17.1

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


[Mesa-dev] [PATCH] r600: reduce num compute threads to 1024.

2018-07-24 Thread Dave Airlie
From: Dave Airlie 

I copied this value from radeonsi, but it was wrong, 1024
seems to be correct answer from looking at gpuinfo.

This should fix a few compute shader related hangs. (at least in CTS)

Cc: 
---
 src/gallium/drivers/r600/r600_pipe_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/r600/r600_pipe_common.c 
b/src/gallium/drivers/r600/r600_pipe_common.c
index a8ea9c4485..f7cfd0d46a 100644
--- a/src/gallium/drivers/r600/r600_pipe_common.c
+++ b/src/gallium/drivers/r600/r600_pipe_common.c
@@ -998,7 +998,7 @@ static unsigned get_max_threads_per_block(struct 
r600_common_screen *screen,
if (ir_type != PIPE_SHADER_IR_TGSI)
return 256;
if (screen->chip_class >= EVERGREEN)
-   return 2048;
+   return 1024;
return 256;
 }
 
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH] clover: Reduce wait_count in abort path.

2018-07-24 Thread Francisco Jerez
Jan Vesely  writes:

> Trigger waiter condition variable.
> Passes 'events' CTS on turks and carrizo.
> Signed-off-by: Jan Vesely 
> ---
>  src/gallium/state_trackers/clover/core/event.cpp | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/core/event.cpp 
> b/src/gallium/state_trackers/clover/core/event.cpp
> index b7eb33dbfc..0de4e2b984 100644
> --- a/src/gallium/state_trackers/clover/core/event.cpp
> +++ b/src/gallium/state_trackers/clover/core/event.cpp
> @@ -65,8 +65,10 @@ event::abort_self(cl_int status) {
> std::vector> evs;
>  
> _status = status;
> -   std::swap(_chain, evs);
> +   if (!--_wait_count)

This doesn't look correct to me.  The event is being aborted immediately
regardless of its previous _wait_count.  You probably just want to set
_wait_count to zero here.  The line below should be unconditional for
dependent events to be aborted recursively.

> +  std::swap(_chain, evs);
>  
> +   cv.notify_all();
> return evs;
>  }
>  
> -- 
> 2.17.1


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] gallium/auxiliary: Fix Autotools on Android (v2)

2018-07-24 Thread Tomasz Figa
Hi Chad,

On Wed, Jul 25, 2018 at 10:11 AM Chad Versace  wrote:
>
> Problem 1: u_debug_stack_android.cpp transitively included
> "pipe/p_compiler.h", but src/gallium/include was missing from the C++
> include path.
>
> Problem 2: Add -std=c++11 to AM_CXXFLAGS. Android's libbacktrace headers
> require C++11, but the Android toolchain (at least in the Chrome OS SDK)
> does not enable C++11 by default.
>
> v2: Add -std=c++11.
>
> Cc: Gurchetan Singh 
> Cc: Eric Engestrom 
> ---
>  src/gallium/auxiliary/Makefile.am | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/Makefile.am 
> b/src/gallium/auxiliary/Makefile.am
> index 03908198772..4bfa7648389 100644
> --- a/src/gallium/auxiliary/Makefile.am
> +++ b/src/gallium/auxiliary/Makefile.am
> @@ -13,6 +13,7 @@ AM_CFLAGS = \
> $(MSVC2013_COMPAT_CFLAGS)
>
>  AM_CXXFLAGS = \
> +   $(GALLIUM_CFLAGS) \
> $(VISIBILITY_CXXFLAGS) \
> $(MSVC2013_COMPAT_CXXFLAGS)
>
> @@ -22,6 +23,10 @@ libgallium_la_SOURCES = \
> $(GENERATED_SOURCES)
>
>  if HAVE_PLATFORM_ANDROID
> +# Android's libbacktrace headers required C++11, but the Android toolchain 
> (at
> +# least in the Chrome OS SDK) does not enable C++11 by default.
> +AM_CXXFLAGS += $(CXX11_CXXFLAGS)
> +

This is something that would normally be handled by the .pc file for
given library. Package build system shouldn't be polluted with such
system-specific low level dependencies.

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


[Mesa-dev] [PATCH] clover: Reduce wait_count in abort path.

2018-07-24 Thread Jan Vesely
Trigger waiter condition variable.
Passes 'events' CTS on turks and carrizo.
Signed-off-by: Jan Vesely 
---
 src/gallium/state_trackers/clover/core/event.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/core/event.cpp 
b/src/gallium/state_trackers/clover/core/event.cpp
index b7eb33dbfc..0de4e2b984 100644
--- a/src/gallium/state_trackers/clover/core/event.cpp
+++ b/src/gallium/state_trackers/clover/core/event.cpp
@@ -65,8 +65,10 @@ event::abort_self(cl_int status) {
std::vector> evs;
 
_status = status;
-   std::swap(_chain, evs);
+   if (!--_wait_count)
+  std::swap(_chain, evs);
 
+   cv.notify_all();
return evs;
 }
 
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH] gallium/auxiliary: Fix Autotools on Android (v2)

2018-07-24 Thread Gurchetan Singh
Reviewed-by: Gurchetan Singh 
On Tue, Jul 24, 2018 at 6:11 PM Chad Versace  wrote:
>
> Problem 1: u_debug_stack_android.cpp transitively included
> "pipe/p_compiler.h", but src/gallium/include was missing from the C++
> include path.
>
> Problem 2: Add -std=c++11 to AM_CXXFLAGS. Android's libbacktrace headers
> require C++11, but the Android toolchain (at least in the Chrome OS SDK)
> does not enable C++11 by default.
>
> v2: Add -std=c++11.
>
> Cc: Gurchetan Singh 
> Cc: Eric Engestrom 
> ---
>  src/gallium/auxiliary/Makefile.am | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/Makefile.am 
> b/src/gallium/auxiliary/Makefile.am
> index 03908198772..4bfa7648389 100644
> --- a/src/gallium/auxiliary/Makefile.am
> +++ b/src/gallium/auxiliary/Makefile.am
> @@ -13,6 +13,7 @@ AM_CFLAGS = \
> $(MSVC2013_COMPAT_CFLAGS)
>
>  AM_CXXFLAGS = \
> +   $(GALLIUM_CFLAGS) \
> $(VISIBILITY_CXXFLAGS) \
> $(MSVC2013_COMPAT_CXXFLAGS)
>
> @@ -22,6 +23,10 @@ libgallium_la_SOURCES = \
> $(GENERATED_SOURCES)
>
>  if HAVE_PLATFORM_ANDROID
> +# Android's libbacktrace headers required C++11, but the Android toolchain 
> (at
> +# least in the Chrome OS SDK) does not enable C++11 by default.
> +AM_CXXFLAGS += $(CXX11_CXXFLAGS)
> +
>  libgallium_la_SOURCES += util/u_debug_stack_android.cpp
>  endif
>
> @@ -41,7 +46,6 @@ AM_CFLAGS += \
> $(LLVM_CFLAGS)
>
>  AM_CXXFLAGS += \
> -   $(GALLIUM_CFLAGS) \
> $(LLVM_CXXFLAGS)
>
>  libgallium_la_SOURCES += \
> --
> 2.18.0.233.g985f88cf7e-goog
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] gallium/auxiliary: Fix Autotools on Android (v2)

2018-07-24 Thread Chad Versace
Problem 1: u_debug_stack_android.cpp transitively included
"pipe/p_compiler.h", but src/gallium/include was missing from the C++
include path.

Problem 2: Add -std=c++11 to AM_CXXFLAGS. Android's libbacktrace headers
require C++11, but the Android toolchain (at least in the Chrome OS SDK)
does not enable C++11 by default.

v2: Add -std=c++11.

Cc: Gurchetan Singh 
Cc: Eric Engestrom 
---
 src/gallium/auxiliary/Makefile.am | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/Makefile.am 
b/src/gallium/auxiliary/Makefile.am
index 03908198772..4bfa7648389 100644
--- a/src/gallium/auxiliary/Makefile.am
+++ b/src/gallium/auxiliary/Makefile.am
@@ -13,6 +13,7 @@ AM_CFLAGS = \
$(MSVC2013_COMPAT_CFLAGS)
 
 AM_CXXFLAGS = \
+   $(GALLIUM_CFLAGS) \
$(VISIBILITY_CXXFLAGS) \
$(MSVC2013_COMPAT_CXXFLAGS)
 
@@ -22,6 +23,10 @@ libgallium_la_SOURCES = \
$(GENERATED_SOURCES)
 
 if HAVE_PLATFORM_ANDROID
+# Android's libbacktrace headers required C++11, but the Android toolchain (at
+# least in the Chrome OS SDK) does not enable C++11 by default.
+AM_CXXFLAGS += $(CXX11_CXXFLAGS)
+
 libgallium_la_SOURCES += util/u_debug_stack_android.cpp
 endif
 
@@ -41,7 +46,6 @@ AM_CFLAGS += \
$(LLVM_CFLAGS)
 
 AM_CXXFLAGS += \
-   $(GALLIUM_CFLAGS) \
$(LLVM_CXXFLAGS)
 
 libgallium_la_SOURCES += \
-- 
2.18.0.233.g985f88cf7e-goog

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


[Mesa-dev] [PATCH v3 1/3] glsl: teach copy_propagation_elements to deal with whole variables

2018-07-24 Thread Caio Marcelo de Oliveira Filho
Keep information in acp_entry whether the entry is full or not, and
use the ACP in more nodes when visiting the instructions:

- add_copy: write whole variables to the ACP state (regardless the
  type).

- visit(ir_dereference_variable *): perform the propagation here if we have a
  full candidate. Element-wise here doesn't apply because the mask
  isn't available at this point.

- visit_leave(ir_assignment *): process beyond scalar and vector, as
  the full variables might have other types.

Also import an improvement from opt_copy_propagation.cpp: if ir_call
is an intrinsic, we know the variables affected, so keep going.

v2: (all from Eric Anholt)
Describe how acp_entry attributes are used.
Don't do book-keeping to avoid adding repeated element to
the dsts in write_elements().

Reviewed-by: Eric Anholt 
---
 .../glsl/opt_copy_propagation_elements.cpp| 147 ++
 1 file changed, 118 insertions(+), 29 deletions(-)

diff --git a/src/compiler/glsl/opt_copy_propagation_elements.cpp 
b/src/compiler/glsl/opt_copy_propagation_elements.cpp
index 4c6ca790394..cae6d3c0707 100644
--- a/src/compiler/glsl/opt_copy_propagation_elements.cpp
+++ b/src/compiler/glsl/opt_copy_propagation_elements.cpp
@@ -27,18 +27,9 @@
  * Replaces usage of recently-copied components of variables with the
  * previous copy of the variable.
  *
- * This pass can be compared with opt_copy_propagation, which operands
- * on arbitrary whole-variable copies.  However, in order to handle
- * the copy propagation of swizzled variables or writemasked writes,
- * we want to track things on a channel-wise basis.  I found that
- * trying to mix the swizzled/writemasked support here with the
- * whole-variable stuff in opt_copy_propagation.cpp just made a mess,
- * so this is separate despite the ACP handling being somewhat
- * similar.
- *
  * This should reduce the number of MOV instructions in the generated
- * programs unless copy propagation is also done on the LIR, and may
- * help anyway by triggering other optimizations that live in the HIR.
+ * programs and help triggering other optimizations that live in GLSL
+ * level.
  */
 
 #include "ir.h"
@@ -58,9 +49,22 @@ class acp_entry
 public:
DECLARE_LINEAR_ZALLOC_CXX_OPERATORS(acp_entry)
 
+   /* If set, rhs_full indicates that this ACP entry represents a
+* whole-variable copy.  The rhs_element[] array will still be filled,
+* to allow the swizzling from its components in case the variable
+* was a vector (and to simplify some of the erase() and write_vector()
+* logic).
+*/
+
+   ir_variable *rhs_full;
ir_variable *rhs_element[4];
unsigned rhs_channel[4];
 
+   /* Set of variables that use the variable associated with this acp_entry as
+* RHS.  This has the "reverse references" of rhs_full/rhs_element.  It is
+* used to speed up invalidating those references when the acp_entry
+* changes.
+*/
set *dsts;
 };
 
@@ -91,6 +95,7 @@ public:
void erase(ir_variable *var, unsigned write_mask)
{
   acp_entry *entry = pull_acp(var);
+  entry->rhs_full = NULL;
 
   for (int i = 0; i < 4; i++) {
  if (!entry->rhs_element[i])
@@ -114,6 +119,8 @@ public:
 if (dst_entry->rhs_element[i] == var)
dst_entry->rhs_element[i] = NULL;
  }
+ if (dst_entry->rhs_full == var)
+dst_entry->rhs_full = NULL;
  _mesa_set_remove(entry->dsts, set_entry);
   }
}
@@ -128,9 +135,10 @@ public:
   return NULL;
}
 
-   void write(ir_variable *lhs, ir_variable *rhs, unsigned write_mask, int 
swizzle[4])
+   void write_elements(ir_variable *lhs, ir_variable *rhs, unsigned 
write_mask, int swizzle[4])
{
   acp_entry *lhs_entry = pull_acp(lhs);
+  lhs_entry->rhs_full = NULL;
 
   for (int i = 0; i < 4; i++) {
  if ((write_mask & (1 << i)) == 0)
@@ -146,6 +154,33 @@ public:
   _mesa_set_add(rhs_entry->dsts, lhs);
}
 
+   void write_full(ir_variable *lhs, ir_variable *rhs)
+   {
+  acp_entry *lhs_entry = pull_acp(lhs);
+  if (lhs_entry->rhs_full == rhs)
+ return;
+
+  if (lhs_entry->rhs_full) {
+ remove_from_dsts(lhs_entry->rhs_full, lhs);
+  } else if (lhs->type->is_vector()) {
+ for (int i = 0; i < 4; i++) {
+if (lhs_entry->rhs_element[i])
+   remove_from_dsts(lhs_entry->rhs_element[i], lhs);
+ }
+  }
+
+  lhs_entry->rhs_full = rhs;
+  acp_entry *rhs_entry = pull_acp(rhs);
+  _mesa_set_add(rhs_entry->dsts, lhs);
+
+  if (lhs->type->is_vector()) {
+ for (int i = 0; i < 4; i++) {
+lhs_entry->rhs_element[i] = rhs;
+lhs_entry->rhs_channel[i] = i;
+ }
+  }
+   }
+
void remove_unused_var_from_dsts(acp_entry *lhs_entry, ir_variable *lhs, 
ir_variable *var)
{
   if (!var)
@@ -204,6 +239,14 @@ private:
   return entry;
}
 
+   void
+   remove_from_dsts(ir_variable *var, 

[Mesa-dev] [PATCH v3 2/3] glsl: use only copy_propagation_elements

2018-07-24 Thread Caio Marcelo de Oliveira Filho
Now that the elements version handles both cases, remove the
non-elements version.

Reviewed-by: Eric Anholt 
---
 src/compiler/Makefile.sources  |   1 -
 src/compiler/glsl/glsl_parser_extras.cpp   |   1 -
 src/compiler/glsl/ir_optimization.h|   1 -
 src/compiler/glsl/meson.build  |   1 -
 src/compiler/glsl/opt_copy_propagation.cpp | 369 -
 src/compiler/glsl/test_optpass.cpp |   2 -
 6 files changed, 375 deletions(-)
 delete mode 100644 src/compiler/glsl/opt_copy_propagation.cpp

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index cc147218c4e..908508adffb 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -129,7 +129,6 @@ LIBGLSL_FILES = \
glsl/opt_constant_folding.cpp \
glsl/opt_constant_propagation.cpp \
glsl/opt_constant_variable.cpp \
-   glsl/opt_copy_propagation.cpp \
glsl/opt_copy_propagation_elements.cpp \
glsl/opt_dead_builtin_variables.cpp \
glsl/opt_dead_builtin_varyings.cpp \
diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
b/src/compiler/glsl/glsl_parser_extras.cpp
index 04eba980e0e..6d92f24ea22 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -2214,7 +2214,6 @@ do_common_optimization(exec_list *ir, bool linked,
OPT(do_if_simplification, ir);
OPT(opt_flatten_nested_if_blocks, ir);
OPT(opt_conditional_discard, ir);
-   OPT(do_copy_propagation, ir);
OPT(do_copy_propagation_elements, ir);
 
if (options->OptimizeForAOS && !linked)
diff --git a/src/compiler/glsl/ir_optimization.h 
b/src/compiler/glsl/ir_optimization.h
index b0e84608c58..ef68b93c09e 100644
--- a/src/compiler/glsl/ir_optimization.h
+++ b/src/compiler/glsl/ir_optimization.h
@@ -103,7 +103,6 @@ bool opt_conditional_discard(exec_list *instructions);
 bool do_constant_folding(exec_list *instructions);
 bool do_constant_variable(exec_list *instructions);
 bool do_constant_variable_unlinked(exec_list *instructions);
-bool do_copy_propagation(exec_list *instructions);
 bool do_copy_propagation_elements(exec_list *instructions);
 bool do_constant_propagation(exec_list *instructions);
 void do_dead_builtin_varyings(struct gl_context *ctx,
diff --git a/src/compiler/glsl/meson.build b/src/compiler/glsl/meson.build
index 96536b80168..09662b20775 100644
--- a/src/compiler/glsl/meson.build
+++ b/src/compiler/glsl/meson.build
@@ -170,7 +170,6 @@ files_libglsl = files(
   'opt_constant_folding.cpp',
   'opt_constant_propagation.cpp',
   'opt_constant_variable.cpp',
-  'opt_copy_propagation.cpp',
   'opt_copy_propagation_elements.cpp',
   'opt_dead_builtin_variables.cpp',
   'opt_dead_builtin_varyings.cpp',
diff --git a/src/compiler/glsl/opt_copy_propagation.cpp 
b/src/compiler/glsl/opt_copy_propagation.cpp
deleted file mode 100644
index 206dffe4f1c..000
--- a/src/compiler/glsl/opt_copy_propagation.cpp
+++ /dev/null
@@ -1,369 +0,0 @@
-/*
- * Copyright © 2010 Intel Corporation
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
- */
-
-/**
- * \file opt_copy_propagation.cpp
- *
- * Moves usage of recently-copied variables to the previous copy of
- * the variable.
- *
- * This should reduce the number of MOV instructions in the generated
- * programs unless copy propagation is also done on the LIR, and may
- * help anyway by triggering other optimizations that live in the HIR.
- */
-
-#include "ir.h"
-#include "ir_visitor.h"
-#include "ir_basic_block.h"
-#include "ir_optimization.h"
-#include "compiler/glsl_types.h"
-#include "util/hash_table.h"
-#include "util/set.h"
-
-namespace {
-
-class ir_copy_propagation_visitor : public ir_hierarchical_visitor {
-public:
-   ir_copy_propagation_visitor()
-   {
-  progress = false;
-  mem_ctx = ralloc_context(0);
-  lin_ctx = linear_alloc_parent(mem_ctx, 0);
-  acp = 

[Mesa-dev] [PATCH v3 3/3] glsl: propagate full variables eagerly

2018-07-24 Thread Caio Marcelo de Oliveira Filho
When creating a new acp_entry after an assignment "c = b", check if b
itself has an acp_entry with a full variable associated and use
that. This reduces the number of passes the algorithm needs to
propagate a value in a chain of assignments.

I've tried to make a similar change to the write_partial, but it
caused noise in the final output (hurting instruction count). The
reason is for partials, a propagation might imply a swizzle
operation.

We could later investigate if it is worth to restrict the cases we are
eager to avoid getting things worse because of swizzling.
---
 .../glsl/opt_copy_propagation_elements.cpp| 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/opt_copy_propagation_elements.cpp 
b/src/compiler/glsl/opt_copy_propagation_elements.cpp
index cae6d3c0707..c44f7c56f11 100644
--- a/src/compiler/glsl/opt_copy_propagation_elements.cpp
+++ b/src/compiler/glsl/opt_copy_propagation_elements.cpp
@@ -169,8 +169,29 @@ public:
  }
   }
 
+  /* If the rhs has an acp_entry pointing to another full variable, use
+   * that. This allows propagation to happen all in one pass, instead of
+   * having the value walking slowly. E.g.
+   *
+   * b = a
+   * c = b
+   * d = c
+   * use(d)
+   *
+   * will need one pass to propagate to
+   *
+   * b = a
+   * c = a// Because of b acp_entry.
+   * d = a// Because of c acp_entry that uses 'a' directly.
+   * use(a)   // Because of d acp_entry that uses 'a' directly.
+   */
+  acp_entry *rhs_entry = read(rhs);
+  if (rhs_entry && rhs_entry->rhs_full != NULL) {
+ rhs = rhs_entry->rhs_full;
+  }
+  rhs_entry = pull_acp(rhs);
+
   lhs_entry->rhs_full = rhs;
-  acp_entry *rhs_entry = pull_acp(rhs);
   _mesa_set_add(rhs_entry->dsts, lhs);
 
   if (lhs->type->is_vector()) {
-- 
2.18.0

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


[Mesa-dev] [PATCH v3 0/3] GLSL Copy Propagation

2018-07-24 Thread Caio Marcelo de Oliveira Filho
I've landed most of the patches in the original series. What remains
is consolidating the two passes in a single one.

Since opt_copy_propagation.cpp would be gone in the end of the series,
I've dropped the patch that changes it to handle both paths in an
if-statement.

Patches 1 and 2 are already reviewed by Eric Anholt, I'm sending them
as a context for the patch 3. That last patch doesn't change the
results (instructions / cycles) but makes up for the performance time
we lost to process both paths of if-statement.

I've tried other optimization tricks without much significant results.

Caio Marcelo de Oliveira Filho (3):
  glsl: teach copy_propagation_elements to deal with whole variables
  glsl: use only copy_propagation_elements
  glsl: propagate full variables eagerly

 src/compiler/Makefile.sources |   1 -
 src/compiler/glsl/glsl_parser_extras.cpp  |   1 -
 src/compiler/glsl/ir_optimization.h   |   1 -
 src/compiler/glsl/meson.build |   1 -
 src/compiler/glsl/opt_copy_propagation.cpp| 369 --
 .../glsl/opt_copy_propagation_elements.cpp| 168 ++--
 src/compiler/glsl/test_optpass.cpp|   2 -
 7 files changed, 139 insertions(+), 404 deletions(-)
 delete mode 100644 src/compiler/glsl/opt_copy_propagation.cpp

-- 
2.18.0

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


Re: [Mesa-dev] [PATCH] drisw: Fix build on Android Nougat

2018-07-24 Thread David Airlie
On Thu, Jul 19, 2018 at 10:43 AM, Chad Versace 
wrote:

> In commit cf54bd5e8, dri_sw_winsys.c began using  to support
> the new functions putImageShm, getImageShm in DRI_SWRastLoader. But
> Android began supporting System V shared memory only in Oreo. Nougat has
> no shm headers.
>
> Fix the build by ifdef'ing out the shm code on Nougat.
>

No that's horrible. At least make a HAVE_IPC define or something so
the if android horror can be hidden a bit out of the way at the top of the
file
or the build system.

Dave.


> Fixes: cf54bd5e8 "drisw: use shared memory when possible"
> Cc: Marc-André Lureau  Cc: Dave Airlie 
> ---
>  src/gallium/winsys/sw/dri/dri_sw_winsys.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
> b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
> index 40007200a5d..147e0f7c430 100644
> --- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
> +++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
> @@ -26,8 +26,10 @@
>   *
>   
> **/
>
> +#if !defined(ANDROID) || ANDROID_API_LEVEL >= 26
>  #include 
>  #include 
> +#endif
>
>  #include "pipe/p_compiler.h"
>  #include "pipe/p_format.h"
> @@ -83,6 +85,7 @@ dri_sw_is_displaytarget_format_supported( struct
> sw_winsys *ws,
> return TRUE;
>  }
>
> +#if !defined(ANDROID) || ANDROID_API_LEVEL >= 26
>  static char *
>  alloc_shm(struct dri_sw_displaytarget *dri_sw_dt, unsigned size)
>  {
> @@ -101,6 +104,7 @@ alloc_shm(struct dri_sw_displaytarget *dri_sw_dt,
> unsigned size)
>
> return addr;
>  }
> +#endif
>
>  static struct sw_displaytarget *
>  dri_sw_displaytarget_create(struct sw_winsys *winsys,
> @@ -131,8 +135,11 @@ dri_sw_displaytarget_create(struct sw_winsys *winsys,
> size = dri_sw_dt->stride * nblocksy;
>
> dri_sw_dt->shmid = -1;
> +
> +#if !defined(ANDROID) || ANDROID_API_LEVEL >= 26
> if (ws->lf->put_image_shm)
>dri_sw_dt->data = alloc_shm(dri_sw_dt, size);
> +#endif
>
> if(!dri_sw_dt->data)
>dri_sw_dt->data = align_malloc(size, alignment);
> @@ -156,8 +163,10 @@ dri_sw_displaytarget_destroy(struct sw_winsys *ws,
> struct dri_sw_displaytarget *dri_sw_dt = dri_sw_displaytarget(dt);
>
> if (dri_sw_dt->shmid >= 0) {
> +#if !defined(ANDROID) || ANDROID_API_LEVEL >= 26
>shmdt(dri_sw_dt->data);
>shmctl(dri_sw_dt->shmid, IPC_RMID, 0);
> +#endif
> } else {
>align_free(dri_sw_dt->data);
> }
> --
> 2.18.0.233.g985f88cf7e-goog
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] gallium/auxiliary: Fix Autotools on Android

2018-07-24 Thread Chad Versace
u_debug_stack_android.cpp transitively included "pipe/p_compiler.h", but
src/gallium/include was missing from the C++ include path.

Cc: Gurchetan Singh 
Cc: Eric Engestrom 
---
 src/gallium/auxiliary/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/Makefile.am 
b/src/gallium/auxiliary/Makefile.am
index 03908198772..81dfc331df1 100644
--- a/src/gallium/auxiliary/Makefile.am
+++ b/src/gallium/auxiliary/Makefile.am
@@ -13,6 +13,7 @@ AM_CFLAGS = \
$(MSVC2013_COMPAT_CFLAGS)
 
 AM_CXXFLAGS = \
+   $(GALLIUM_CFLAGS) \
$(VISIBILITY_CXXFLAGS) \
$(MSVC2013_COMPAT_CXXFLAGS)
 
@@ -41,7 +42,6 @@ AM_CFLAGS += \
$(LLVM_CFLAGS)
 
 AM_CXXFLAGS += \
-   $(GALLIUM_CFLAGS) \
$(LLVM_CXXFLAGS)
 
 libgallium_la_SOURCES += \
-- 
2.18.0.233.g985f88cf7e-goog

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


Re: [Mesa-dev] [PATCH] drisw: Fix build on Android Nougat

2018-07-24 Thread Chad Versace
ping for review

On Wed 18 Jul 2018, Chad Versace wrote:
> In commit cf54bd5e8, dri_sw_winsys.c began using  to support
> the new functions putImageShm, getImageShm in DRI_SWRastLoader. But
> Android began supporting System V shared memory only in Oreo. Nougat has
> no shm headers.
> 
> Fix the build by ifdef'ing out the shm code on Nougat.
> 
> Fixes: cf54bd5e8 "drisw: use shared memory when possible"
> Cc: Marc-André Lureau  Cc: Dave Airlie 
> ---
>  src/gallium/winsys/sw/dri/dri_sw_winsys.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c 
> b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
> index 40007200a5d..147e0f7c430 100644
> --- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
> +++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
> @@ -26,8 +26,10 @@
>   *
>   **/
>  
> +#if !defined(ANDROID) || ANDROID_API_LEVEL >= 26
>  #include 
>  #include 
> +#endif
>  
>  #include "pipe/p_compiler.h"
>  #include "pipe/p_format.h"
> @@ -83,6 +85,7 @@ dri_sw_is_displaytarget_format_supported( struct sw_winsys 
> *ws,
> return TRUE;
>  }
>  
> +#if !defined(ANDROID) || ANDROID_API_LEVEL >= 26
>  static char *
>  alloc_shm(struct dri_sw_displaytarget *dri_sw_dt, unsigned size)
>  {
> @@ -101,6 +104,7 @@ alloc_shm(struct dri_sw_displaytarget *dri_sw_dt, 
> unsigned size)
>  
> return addr;
>  }
> +#endif
>  
>  static struct sw_displaytarget *
>  dri_sw_displaytarget_create(struct sw_winsys *winsys,
> @@ -131,8 +135,11 @@ dri_sw_displaytarget_create(struct sw_winsys *winsys,
> size = dri_sw_dt->stride * nblocksy;
>  
> dri_sw_dt->shmid = -1;
> +
> +#if !defined(ANDROID) || ANDROID_API_LEVEL >= 26
> if (ws->lf->put_image_shm)
>dri_sw_dt->data = alloc_shm(dri_sw_dt, size);
> +#endif
>  
> if(!dri_sw_dt->data)
>dri_sw_dt->data = align_malloc(size, alignment);
> @@ -156,8 +163,10 @@ dri_sw_displaytarget_destroy(struct sw_winsys *ws,
> struct dri_sw_displaytarget *dri_sw_dt = dri_sw_displaytarget(dt);
>  
> if (dri_sw_dt->shmid >= 0) {
> +#if !defined(ANDROID) || ANDROID_API_LEVEL >= 26
>shmdt(dri_sw_dt->data);
>shmctl(dri_sw_dt->shmid, IPC_RMID, 0);
> +#endif
> } else {
>align_free(dri_sw_dt->data);
> }
> -- 
> 2.18.0.233.g985f88cf7e-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


Re: [Mesa-dev] [PATCH] nir: Add a couple of iand/ior optimizations

2018-07-24 Thread Timothy Arceri

On 24/07/18 00:10, Jason Ekstrand wrote:
On Mon, Jul 23, 2018 at 1:08 AM Timothy Arceri > wrote:


Ian and I have been looking at these type of things recently. Ian has
started work on a pass to cover this stuff without having to add dozens
of these types of opts.

https://lists.freedesktop.org/archives/mesa-dev/2018-July/200583.html


Does said pass work only on logical operations with booleans or also 
regular bitwise operations?  This patch is for bitwise operations though 
it naturally works with booleans.


Good point. I replied to this too quickly without thinking too hard. In 
that case we should probably also add these similar opt which I have 
also come across:


   (('ior', ('ior', a, b), a), ('ior', a, b)),
   (('iand', ('iand', a, b), a), ('iand', a, b)),

With those added:

Reviewed-by: Timothy Arceri 



--Jason

On 23/07/18 17:36, Jason Ekstrand wrote:
 > Spotted in a shader in Batman: Arkham City.
 > ---
 >   src/compiler/nir/nir_opt_algebraic.py | 2 ++
 >   1 file changed, 2 insertions(+)
 >
 > diff --git a/src/compiler/nir/nir_opt_algebraic.py
b/src/compiler/nir/nir_opt_algebraic.py
 > index ba277fdfd0e..f2007852b21 100644
 > --- a/src/compiler/nir/nir_opt_algebraic.py
 > +++ b/src/compiler/nir/nir_opt_algebraic.py
 > @@ -377,6 +377,8 @@ optimizations = [
 >      (('ixor', a, a), 0),
 >      (('ixor', a, 0), a),
 >      (('inot', ('inot', a)), a),
 > +   (('ior', ('iand', a, b), b), b),
 > +   (('iand', ('ior', a, b), b), b),
 >      # DeMorgan's Laws
 >      (('iand', ('inot', a), ('inot', b)), ('inot', ('ior',  a, b))),
 >      (('ior',  ('inot', a), ('inot', b)), ('inot', ('iand', a, b))),
 >


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


[Mesa-dev] [PATCH] clover: Don't extend illegal integer types.

2018-07-24 Thread Jan Vesely
It's OK to pass them in memory, which is what kernel invocation needs.
Fixes AMDGCN regressions since llvm r337535 ("Reapply "AMDGPU: Fix handling of 
alignment padding in DAG argument lowering"):
scalar-arithmetic-char
scalar-arithmetic-uchar
scalar-arithemtic-short
scalar-arithmetic-ushort
scalar-comparison-char
scalar-comparison-uchar
scalar-comparison-short
scalar-comparison-ushort

Signed-off-by: Jan Vesely 
---
 src/gallium/state_trackers/clover/llvm/codegen/common.cpp |  3 +--
 src/gallium/state_trackers/clover/llvm/compat.hpp | 12 
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp 
b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
index ddf2083f37..ca5f78940d 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
@@ -85,8 +85,7 @@ namespace {
  const unsigned arg_store_size = dl.getTypeStoreSize(arg_type);
  const unsigned arg_api_size = dl.getTypeAllocSize(arg_type);
 
- const auto target_type = !arg_type->isIntegerTy() ? arg_type :
-dl.getSmallestLegalIntType(mod.getContext(), arg_store_size * 8);
+ const auto target_type = compat::get_abi_type(arg_type, mod);
  const unsigned target_size = dl.getTypeStoreSize(target_type);
  const unsigned target_align = dl.getABITypeAlignment(target_type);
 
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 60270d1529..975012cbda 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -153,6 +153,18 @@ namespace clover {
return tm.addPassesToEmitFile(pm, os, nullptr, ft);
 #else
return tm.addPassesToEmitFile(pm, os, ft);
+#endif
+   }
+
+   template
+   T get_abi_type(const T _type, const M ) {
+#if HAVE_LLVM >= 0x0700
+  return arg_type;
+#else
+  ::llvm::DataLayout dl();
+  const unsigned arg_store_size = dl.getTypeStoreSize(arg_type);
+  return !arg_type->isIntegerTy() ? arg_type :
+dl.getSmallestLegalIntType(mod.getContext(), arg_store_size * 8);
 #endif
}
   }
-- 
2.16.4

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


Re: [Mesa-dev] [Mesa-stable] [PATCH] intel/compiler: Account for built-in uniforms in analyze_ubo_ranges

2018-07-24 Thread Jason Ekstrand

On July 24, 2018 09:05:05 Dylan Baker  wrote:


Quoting Jason Ekstrand (2018-07-23 10:46:31)

The original pass only looked for load_uniform intrinsics but there are
a number of other places that could end up loading a push constant.  One
obvious omission was images which always implicitly use a push constant.
Legacy VS clip planes also get pushed into the shader.

Cc: mesa-sta...@lists.freedesktop.org
Cc: Kenneth Graunke 
---
src/intel/compiler/brw_nir.h  |  1 +
.../compiler/brw_nir_analyze_ubo_ranges.c | 41 +--
src/intel/vulkan/anv_pipeline.c   |  2 +-
src/mesa/drivers/dri/i965/brw_gs.c|  2 +-
src/mesa/drivers/dri/i965/brw_tcs.c   |  2 +-
src/mesa/drivers/dri/i965/brw_tes.c   |  2 +-
src/mesa/drivers/dri/i965/brw_vs.c|  2 +-
src/mesa/drivers/dri/i965/brw_wm.c|  2 +-
8 files changed, 45 insertions(+), 9 deletions(-)

diff --git a/src/intel/compiler/brw_nir.h b/src/intel/compiler/brw_nir.h
index 19442b47eae..7d82edafe46 100644
--- a/src/intel/compiler/brw_nir.h
+++ b/src/intel/compiler/brw_nir.h
@@ -148,6 +148,7 @@ void 
brw_nir_lower_patch_vertices_in_to_uniform(nir_shader *nir);


void brw_nir_analyze_ubo_ranges(const struct brw_compiler *compiler,
nir_shader *nir,
+const struct brw_vs_prog_key *vs_key,
struct brw_ubo_range out_ranges[4]);

bool brw_nir_opt_peephole_ffma(nir_shader *shader);
diff --git a/src/intel/compiler/brw_nir_analyze_ubo_ranges.c 
b/src/intel/compiler/brw_nir_analyze_ubo_ranges.c

index cd5137da06e..cfa531675fc 100644
--- a/src/intel/compiler/brw_nir_analyze_ubo_ranges.c
+++ b/src/intel/compiler/brw_nir_analyze_ubo_ranges.c
@@ -124,12 +124,29 @@ analyze_ubos_block(struct ubo_analysis_state *state, 
nir_block *block)

 continue;

nir_intrinsic_instr *intrin = nir_instr_as_intrinsic(instr);
-  if (intrin->intrinsic == nir_intrinsic_load_uniform)
+  switch (intrin->intrinsic) {
+  case nir_intrinsic_load_uniform:
+  case nir_intrinsic_image_deref_load:
+  case nir_intrinsic_image_deref_store:
+  case nir_intrinsic_image_deref_atomic_add:
+  case nir_intrinsic_image_deref_atomic_min:
+  case nir_intrinsic_image_deref_atomic_max:
+  case nir_intrinsic_image_deref_atomic_and:
+  case nir_intrinsic_image_deref_atomic_or:
+  case nir_intrinsic_image_deref_atomic_xor:
+  case nir_intrinsic_image_deref_atomic_exchange:
+  case nir_intrinsic_image_deref_atomic_comp_swap:
+  case nir_intrinsic_image_deref_size:
 state->uses_regular_uniforms = true;
-
-  if (intrin->intrinsic != nir_intrinsic_load_ubo)
 continue;

+  case nir_intrinsic_load_ubo:
+ break; /* Fall through to the analysis below */
+
+  default:
+ continue; /* Not a uniform or UBO intrinsic */
+  }
+
nir_const_value *block_const = nir_src_as_const_value(intrin->src[0]);
nir_const_value *offset_const = nir_src_as_const_value(intrin->src[1]);

@@ -179,6 +196,7 @@ print_ubo_entry(FILE *file,
void
brw_nir_analyze_ubo_ranges(const struct brw_compiler *compiler,
   nir_shader *nir,
+   const struct brw_vs_prog_key *vs_key,
   struct brw_ubo_range out_ranges[4])
{
const struct gen_device_info *devinfo = compiler->devinfo;
@@ -197,6 +215,23 @@ brw_nir_analyze_ubo_ranges(const struct brw_compiler 
*compiler,

 _mesa_hash_table_create(mem_ctx, NULL, _mesa_key_pointer_equal),
};

+   switch (nir->info.stage) {
+   case MESA_SHADER_VERTEX:
+  if (vs_key && vs_key->nr_userclip_plane_consts > 0)
+ state.uses_regular_uniforms = true;
+  break;
+
+   case MESA_SHADER_COMPUTE:
+  /* Compute shaders use push constants to get the subgroup ID so it's
+   * best to just assume some system values are pushed.
+   */
+  state.uses_regular_uniforms = true;
+  break;
+
+   default:
+  break;
+   }
+
/* Walk the IR, recording how many times each UBO block/offset is used. */
nir_foreach_function(function, nir) {
if (function->impl) {
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 211cee788b8..1e6bd12b87d 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -472,7 +472,7 @@ anv_pipeline_compile(struct anv_pipeline *pipeline,
anv_nir_apply_pipeline_layout(pipeline, layout, nir, prog_data, map);

if (stage != MESA_SHADER_COMPUTE)
-  brw_nir_analyze_ubo_ranges(compiler, nir, prog_data->ubo_ranges);
+  brw_nir_analyze_ubo_ranges(compiler, nir, NULL, prog_data->ubo_ranges);

assert(nir->num_uniforms == prog_data->nr_params * 4);

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

index 9acb0337e20..7263f6351e9 100644
--- a/src/mesa/drivers/dri/i965/brw_gs.c
+++ b/src/mesa/drivers/dri/i965/brw_gs.c
@@ -94,7 +94,7 @@ brw_codegen_gs_prog(struct brw_context *brw,

[Mesa-dev] [RFC][PATCH 5/5] Android.mk: Fix checkbuild on Mac builders.

2018-07-24 Thread John Stultz
From: Alistair Strachan 

This is a forward port of a patch in the AOSP/master tree:
https://android.googlesource.com/platform/external/mesa3d/+/d7f894a7d39e66ca5a832c19edaf175400041aff%5E%21/

The libmesa_dri_common target depends on xgettext unconditionally, but
this is not a documented dependency of AOSP and is not installed on the
Mac builders, so we must not build any part of mesa3d on these
platforms.

Cc: Rob Herring 
Cc: Alistair Strachan 
Cc: Marissa Wall 
Cc: Sumit Semwal 
Cc: Emil Velikov 
Cc: Rob Clark 
Signed-off-by: Alistair Strachan 
Signed-off-by: John Stultz 
---
 Android.mk | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Android.mk b/Android.mk
index 494b4b9..128db4d 100644
--- a/Android.mk
+++ b/Android.mk
@@ -30,6 +30,8 @@
 # module will also be built.  DRI modules will be loaded by libGLES_mesa.
 
 ifneq ($(BOARD_USE_CUSTOMIZED_MESA), true)
+ifneq ($(BOARD_GPU_DRIVERS),)
+
 MESA_TOP := $(call my-dir)
 
 MESA_ANDROID_MAJOR_VERSION := $(word 1, $(subst ., , $(PLATFORM_VERSION)))
@@ -127,4 +129,5 @@ INC_DIRS := $(call all-named-subdir-makefiles,$(SUBDIRS))
 INC_DIRS += $(call all-named-subdir-makefiles,src/gallium)
 include $(INC_DIRS)
 
-endif
+endif # BOARD_GPU_DRIVERS != ""
+endif # BOARD_USE_CUSTOMIZED_MESA != true
-- 
2.7.4

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


[Mesa-dev] [RFC][PATCH 1/5] util: Android.mk: Convert implicit rules to static pattern rules

2018-07-24 Thread John Stultz
From: Dan Willemsen 

This is a partial cherry-pick from AOSP's mesa3d tree:
 
https://android.googlesource.com/platform/external/mesa3d/+/a88dcf769eb00a4ffc7183a0396d881a28b5a29b%5E%21/

"We're deprecating make implicit rules, preferring static pattern
rules, or just regular rules."

Without this patch, the freedesktop/master branch won't build in
the AOSP environment, and this patch corrects that, as tested
on the Dragonboard 820c.

The i965 portion of the patch this is based on collided badly,
and I'm not sure how to best forward port it. However, so far
we don't see build issues without that portion.

Comments or feedback would be appreciated!

Cc: Rob Herring 
Cc: Alistair Strachan 
Cc: Marissa Wall 
Cc: Sumit Semwal 
Cc: Emil Velikov 
Cc: Rob Clark 
Signed-off-by: John Stultz 
---
 src/util/Android.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/util/Android.mk b/src/util/Android.mk
index 9b61442..e463b63 100644
--- a/src/util/Android.mk
+++ b/src/util/Android.mk
@@ -71,7 +71,7 @@ $(POT): $(LOCAL_PATH)/xmlpool/t_options.h
@mkdir -p $(dir $@)
xgettext -L C --from-code utf-8 -o $@ $<
 
-$(intermediates)/xmlpool/%.po: $(LOCAL_PATH)/xmlpool/%.po $(POT)
+$(MESA_DRI_OPTIONS_LANGS:%=$(intermediates)/xmlpool/%.po): 
$(intermediates)/xmlpool/%.po: $(LOCAL_PATH)/xmlpool/%.po $(POT)
lang=$(basename $(notdir $@)); \
mkdir -p $(dir $@); \
if [ -f $< ]; then \
-- 
2.7.4

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


[Mesa-dev] [RFC][PATCH 3/5] CleanSpec.mk: Remove HOST_OUT_release

2018-07-24 Thread John Stultz
From: Dan Willemsen 

This is a forward port of a patch from the AOSP/master tree:
https://android.googlesource.com/platform/external/mesa3d/+/bd633f11de0c6ac1ed333a28344c74fd9898df9e%5E%21/

Which replaces HOST_OUT_release with HOST_OUT

Cc: Rob Herring 
Cc: Alistair Strachan 
Cc: Marissa Wall 
Cc: Sumit Semwal 
Cc: Emil Velikov 
Cc: Rob Clark 
Signed-off-by: John Stultz 
---
 CleanSpec.mk | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/CleanSpec.mk b/CleanSpec.mk
index d08b0de..e5030ce 100644
--- a/CleanSpec.mk
+++ b/CleanSpec.mk
@@ -10,7 +10,7 @@ $(call add-clean-step, rm -rf 
$(PRODUCT_OUT)/*/STATIC_LIBRARIES/libmesa_*_interm
 $(call add-clean-step, rm -rf 
$(PRODUCT_OUT)/*/SHARED_LIBRARIES/i9?5_dri_intermediates)
 $(call add-clean-step, rm -rf 
$(PRODUCT_OUT)/*/SHARED_LIBRARIES/libglapi_intermediates)
 $(call add-clean-step, rm -rf 
$(PRODUCT_OUT)/*/SHARED_LIBRARIES/libGLES_mesa_intermediates)
-$(call add-clean-step, rm -rf 
$(HOST_OUT_release)/*/EXECUTABLES/mesa_*_intermediates)
-$(call add-clean-step, rm -rf 
$(HOST_OUT_release)/*/EXECUTABLES/glsl_compiler_intermediates)
-$(call add-clean-step, rm -rf 
$(HOST_OUT_release)/*/STATIC_LIBRARIES/libmesa_*_intermediates)
+$(call add-clean-step, rm -rf $(HOST_OUT)/*/EXECUTABLES/mesa_*_intermediates)
+$(call add-clean-step, rm -rf 
$(HOST_OUT)/*/EXECUTABLES/glsl_compiler_intermediates)
+$(call add-clean-step, rm -rf 
$(HOST_OUT)/*/STATIC_LIBRARIES/libmesa_*_intermediates)
 $(call add-clean-step, rm -rf 
$(PRODUCT_OUT)/*/SHARED_LIBRARIES/*_dri_intermediates)
-- 
2.7.4

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


[Mesa-dev] [RFC][PATCH 2/5] Android.common.mk: define HAVE_TIMESPEC_GET

2018-07-24 Thread John Stultz
From: Sumit Semwal 

This is a forward port of a patch from the AOSP/master tree:
https://android.googlesource.com/platform/external/mesa3d/+/bd30b663f55f8af73a0be4446349c5a2d4c641b0%5E%21/

Since https://android-review.googlesource.com/c/718518 added
timespec_get() to bionic, mesa3d doesn't build due to redefinition
of timespec_get().

Avoid redefinition by defining HAVE_TIMESPEC_GET flag.

Test: build and boot tested db820c to UI.

Cc: Rob Herring 
Cc: Alistair Strachan 
Cc: Marissa Wall 
Cc: Sumit Semwal 
Cc: Emil Velikov 
Cc: Rob Clark 
Signed-off-by: Sumit Semwal 
Signed-off-by: John Stultz 
---
 Android.common.mk | 4 
 1 file changed, 4 insertions(+)

diff --git a/Android.common.mk b/Android.common.mk
index 397dc03..e7828af 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -89,6 +89,10 @@ LOCAL_CPPFLAGS += \
 LOCAL_CONLYFLAGS += \
-std=c99
 
+# c11 timespec_get is part of bionic as well
+# https://android-review.googlesource.com/c/718518
+LOCAL_CFLAGS += -DHAVE_TIMESPEC_GET
+
 ifeq ($(strip $(MESA_ENABLE_ASM)),true)
 ifeq ($(TARGET_ARCH),x86)
 LOCAL_CFLAGS += \
-- 
2.7.4

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


[Mesa-dev] [RFC][PATCH 4/5] Android.mk: Add option to use vendor version of mesa

2018-07-24 Thread John Stultz
From: Yong Yao 

This is a forward port of a patch from the AOSP/master branch:
https://android.googlesource.com/platform/external/mesa3d/+/b1e5fad1db4c1d51c7ae3a033b100a8429ae5415%5E%21/

Which allows boards to provide their own custom copy of mesa.

Cc: Rob Herring 
Cc: Alistair Strachan 
Cc: Marissa Wall 
Cc: Sumit Semwal 
Cc: Emil Velikov 
Cc: Rob Clark 
Signed-off-by: Harish Krupo 
Signed-off-by: Yong Yao 
Signed-off-by: John Stultz 
---
 Android.mk | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Android.mk b/Android.mk
index 914854c..494b4b9 100644
--- a/Android.mk
+++ b/Android.mk
@@ -29,6 +29,7 @@
 # The main target is libGLES_mesa.  For each classic driver enabled, a DRI
 # module will also be built.  DRI modules will be loaded by libGLES_mesa.
 
+ifneq ($(BOARD_USE_CUSTOMIZED_MESA), true)
 MESA_TOP := $(call my-dir)
 
 MESA_ANDROID_MAJOR_VERSION := $(word 1, $(subst ., , $(PLATFORM_VERSION)))
@@ -125,3 +126,5 @@ SUBDIRS := \
 INC_DIRS := $(call all-named-subdir-makefiles,$(SUBDIRS))
 INC_DIRS += $(call all-named-subdir-makefiles,src/gallium)
 include $(INC_DIRS)
+
+endif
-- 
2.7.4

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


[Mesa-dev] [RFC][PATCH 0/5] Trying to align mesa upstream w/ AOSP/master

2018-07-24 Thread John Stultz
In trying to keep the upstream mesa aligned with AOSP, I wanted
to submit a few changes that seemed reasonable to upstream.

The first two are build fixes that are required to get mesa master
building with AOSP. The last three are less critical, but seemed
like things we might as well try to sync between the trees.

Feedback and comments would be greatly appreciated!

thanks
-john

Cc: Rob Herring 
Cc: Alistair Strachan 
Cc: Marissa Wall 
Cc: Sumit Semwal 
Cc: Emil Velikov 
Cc: Rob Clark 

Alistair Strachan (1):
  Android.mk: Fix checkbuild on Mac builders.

Dan Willemsen (2):
  util: Android.mk: Convert implicit rules to static pattern rules
  CleanSpec.mk: Remove HOST_OUT_release

Sumit Semwal (1):
  Android.common.mk: define HAVE_TIMESPEC_GET

Yong Yao (1):
  Android.mk: Add option to use vendor version of mesa

 Android.common.mk   | 4 
 Android.mk  | 6 ++
 CleanSpec.mk| 6 +++---
 src/util/Android.mk | 2 +-
 4 files changed, 14 insertions(+), 4 deletions(-)

-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] st/nir: Fix st_nir_opts() prototype.

2018-07-24 Thread Timothy Arceri

Reviewed-by: Timothy Arceri 

On 25/07/18 07:55, Kenneth Graunke wrote:

This wasn't updated for the new scalar ISA parameter.  It worked anyway
because all the function's callers live in the same file, so it found
the correct function.  Tim made this external for the new st prog_to_nir
translator, which got reverted, but which I'd like to land eventually.

So, fix the prototype.
---
  src/mesa/state_tracker/st_nir.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_nir.h b/src/mesa/state_tracker/st_nir.h
index 15f1ce93e5a..aa6e32758e8 100644
--- a/src/mesa/state_tracker/st_nir.h
+++ b/src/mesa/state_tracker/st_nir.h
@@ -42,7 +42,7 @@ void st_finalize_nir(struct st_context *st, struct gl_program 
*prog,
   struct gl_shader_program *shader_program,
   struct nir_shader *nir);
  
-void st_nir_opts(struct nir_shader *nir);

+void st_nir_opts(struct nir_shader *nir, bool is_scalar);
  
  bool

  st_link_nir(struct gl_context *ctx,


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


Re: [Mesa-dev] [PATCH v2 10/26] python: Use explicit integer divisions

2018-07-24 Thread Dylan Baker
Quoting Eric Engestrom (2018-07-24 09:42:57)
> On Wednesday, 2018-07-11 19:52:31 +0200, Mathieu Bridon wrote:
> > In Python 2, divisions return an integer:
  ^ of integers

Since 32 / 4.0 returns 8.0

> > 
> > >>> 32 / 4
> > 8
> > 
> > In Python 3 though, they return floats:
> > 
> > >>> 32 / 4
> > 8.0
> > 
> > However, Python 3 has an explicit integer division operator:
> > 
> > >>> 32 // 4
> > 8
> > 
> > That operator exists on Python >= 2.2, so let's use it everywhere to
> > make the scripts compatible with both Python 2 and 3.
> > 
> > In addition, using __future__.division tells Python 2 to behave the same
> > way as Python 3, which helps ensure the scripts produce the same output
> > in both versions of Python.
> > 
> > Signed-off-by: Mathieu Bridon 
> 
> Reviewed-by: Eric Engestrom 
> 
> > ---
> >  src/gallium/auxiliary/util/u_format_pack.py  | 4 ++--
> >  src/gallium/auxiliary/util/u_format_parse.py | 7 +--
> >  src/mapi/glapi/gen/glX_proto_send.py | 4 ++--
> >  src/mesa/main/format_info.py | 4 ++--
> >  src/mesa/main/format_pack.py | 8 
> >  src/mesa/main/format_unpack.py   | 8 
> >  6 files changed, 19 insertions(+), 16 deletions(-)
> > 
> > diff --git a/src/gallium/auxiliary/util/u_format_pack.py 
> > b/src/gallium/auxiliary/util/u_format_pack.py
> > index 7a952a48b3..ad2e49281f 100644
> > --- a/src/gallium/auxiliary/util/u_format_pack.py
> > +++ b/src/gallium/auxiliary/util/u_format_pack.py
> > @@ -36,7 +36,7 @@
> >  '''
> >  
> >  
> > -from __future__ import print_function
> > +from __future__ import division, print_function
> >  
> >  from u_format_parse import *
> >  
> > @@ -240,7 +240,7 @@ def value_to_native(type, value):
> >  return truncate_mantissa(value, 23)
> >  return value
> >  if type.type == FIXED:
> > -return int(value * (1 << (type.size/2)))
> > +return int(value * (1 << (type.size // 2)))
> >  if not type.norm:
> >  return int(value)
> >  if type.type == UNSIGNED:
> > diff --git a/src/gallium/auxiliary/util/u_format_parse.py 
> > b/src/gallium/auxiliary/util/u_format_parse.py
> > index c0456f6d15..d3874cd895 100644
> > --- a/src/gallium/auxiliary/util/u_format_parse.py
> > +++ b/src/gallium/auxiliary/util/u_format_parse.py
> > @@ -29,6 +29,9 @@
> >  '''
> >  
> >  
> > +from __future__ import division
> > +
> > +
> >  VOID, UNSIGNED, SIGNED, FIXED, FLOAT = range(5)
> >  
> >  SWIZZLE_X, SWIZZLE_Y, SWIZZLE_Z, SWIZZLE_W, SWIZZLE_0, SWIZZLE_1, 
> > SWIZZLE_NONE, = range(7)
> > @@ -76,7 +79,7 @@ class Channel:
> >  if self.type == FLOAT:
> >  return VERY_LARGE
> >  if self.type == FIXED:
> > -return (1 << (self.size/2)) - 1
> > +return (1 << (self.size // 2)) - 1
> >  if self.norm:
> >  return 1
> >  if self.type == UNSIGNED:
> > @@ -90,7 +93,7 @@ class Channel:
> >  if self.type == FLOAT:
> >  return -VERY_LARGE
> >  if self.type == FIXED:
> > -return -(1 << (self.size/2))
> > +return -(1 << (self.size // 2))
> >  if self.type == UNSIGNED:
> >  return 0
> >  if self.norm:
> > diff --git a/src/mapi/glapi/gen/glX_proto_send.py 
> > b/src/mapi/glapi/gen/glX_proto_send.py
> > index a920ecc012..03067d8a3c 100644
> > --- a/src/mapi/glapi/gen/glX_proto_send.py
> > +++ b/src/mapi/glapi/gen/glX_proto_send.py
> > @@ -26,7 +26,7 @@
> >  #Ian Romanick 
> >  #Jeremy Kolb 
> >  
> > -from __future__ import print_function
> > +from __future__ import division, print_function
> >  
> >  import argparse
> >  
> > @@ -809,7 +809,7 @@ generic_%u_byte( GLint rop, const void * ptr )
> >  # Dividing by the array size (1 for
> >  # non-arrays) gives us this.
> >  
> > -s = p.size() / p.get_element_count()
> > +s = p.size() // p.get_element_count()
> >  print("   %s __glXReadReply(dpy, %s, %s, %s);" % 
> > (return_str, s, p.name, aa))
> >  got_reply = 1
> >  
> > diff --git a/src/mesa/main/format_info.py b/src/mesa/main/format_info.py
> > index bbecaa2451..00e27b3fba 100644
> > --- a/src/mesa/main/format_info.py
> > +++ b/src/mesa/main/format_info.py
> > @@ -21,7 +21,7 @@
> >  # TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> >  # SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> >  
> > -from __future__ import print_function
> > +from __future__ import division, print_function
> >  
> >  import format_parser as parser
> >  import sys
> > @@ -198,7 +198,7 @@ for fmat in formats:
> >chan = fmat.array_element()
> >norm = chan.norm or chan.type == parser.FLOAT
> >print('  .ArrayFormat = MESA_ARRAY_FORMAT({0}),'.format(', 
> > '.join([
> > - str(chan.size / 8),
> > + 

Re: [Mesa-dev] [PATCH 09/26] python: Use range() instead of xrange()

2018-07-24 Thread Dylan Baker
I merged these, but I accidentally pulled the wrong versions. If anyone ever
wonders why some of the review comment wasn't addressed, it was I just applied
v1 instead of v2 :/

Dylan

Quoting Dylan Baker (2018-07-11 10:13:55)
> I've sent 4-9 to our CI, and assuming that it comes back green I'll go ahead 
> and
> merge those patches today.
> 
> Quoting Mathieu Bridon (2018-07-05 06:17:40)
> > Python 2 has a range() function which returns a list, and an xrange()
> > one which returns an iterator.
> > 
> > Python 3 lost the function returning a list, and renamed the function
> > returning an iterator as range().
> > 
> > As a result, using range() makes the scripts compatible with both Python
> > versions 2 and 3.
> > 
> > Signed-off-by: Mathieu Bridon 
> > ---
> >  src/amd/vulkan/radv_entrypoints_gen.py   | 2 +-
> >  src/broadcom/cle/gen_pack_header.py  | 2 +-
> >  src/compiler/glsl/ir_expression_operation.py | 2 +-
> >  src/compiler/nir/nir_opcodes.py  | 4 ++--
> >  src/intel/vulkan/anv_entrypoints_gen.py  | 2 +-
> >  src/mapi/glapi/gen/glX_proto_send.py | 2 +-
> >  src/mapi/glapi/gen/gl_XML.py | 2 +-
> >  src/mapi/glapi/gen/gl_gentable.py| 4 ++--
> >  src/mapi/mapi_abi.py | 2 +-
> >  src/mesa/main/format_parser.py   | 4 ++--
> >  10 files changed, 13 insertions(+), 13 deletions(-)
> > 
> > diff --git a/src/amd/vulkan/radv_entrypoints_gen.py 
> > b/src/amd/vulkan/radv_entrypoints_gen.py
> > index 9c4dfd02a0..ca022bcbb0 100644
> > --- a/src/amd/vulkan/radv_entrypoints_gen.py
> > +++ b/src/amd/vulkan/radv_entrypoints_gen.py
> > @@ -136,7 +136,7 @@ static const struct string_map_entry 
> > string_map_entries[] = {
> >  /* Hash table stats:
> >   * size ${len(strmap.sorted_strings)} entries
> >   * collisions entries:
> > -% for i in xrange(10):
> > +% for i in range(10):
> >   * ${i}${'+' if i == 9 else ' '} ${strmap.collisions[i]}
> >  % endfor
> >   */
> > diff --git a/src/broadcom/cle/gen_pack_header.py 
> > b/src/broadcom/cle/gen_pack_header.py
> > index c6e1c564e6..8ad54464cb 100644
> > --- a/src/broadcom/cle/gen_pack_header.py
> > +++ b/src/broadcom/cle/gen_pack_header.py
> > @@ -216,7 +216,7 @@ class Group(object):
> >  first_byte = field.start // 8
> >  last_byte = field.end // 8
> >  
> > -for b in xrange(first_byte, last_byte + 1):
> > +for b in range(first_byte, last_byte + 1):
> >  if not b in bytes:
> >  bytes[b] = self.Byte()
> >  
> > diff --git a/src/compiler/glsl/ir_expression_operation.py 
> > b/src/compiler/glsl/ir_expression_operation.py
> > index b3dac3da3f..16b98690a6 100644
> > --- a/src/compiler/glsl/ir_expression_operation.py
> > +++ b/src/compiler/glsl/ir_expression_operation.py
> > @@ -116,7 +116,7 @@ constant_template_common = mako.template.Template("""\
> >  constant_template_vector_scalar = mako.template.Template("""\
> > case ${op.get_enum_name()}:
> >  % if "mixed" in op.flags:
> > -% for i in xrange(op.num_operands):
> > +% for i in range(op.num_operands):
> >assert(op[${i}]->type->base_type == ${op.source_types[0].glsl_type} 
> > ||
> >  % for src_type in op.source_types[1:-1]:
> >   op[${i}]->type->base_type == ${src_type.glsl_type} ||
> > diff --git a/src/compiler/nir/nir_opcodes.py 
> > b/src/compiler/nir/nir_opcodes.py
> > index 3c3316dcaa..b03c5da2ea 100644
> > --- a/src/compiler/nir/nir_opcodes.py
> > +++ b/src/compiler/nir/nir_opcodes.py
> > @@ -367,8 +367,8 @@ for (unsigned bit = 0; bit < bit_size; bit++) {
> >  """)
> >  
> >  
> > -for i in xrange(1, 5):
> > -   for j in xrange(1, 5):
> > +for i in range(1, 5):
> > +   for j in range(1, 5):
> >unop_horiz("fnoise{0}_{1}".format(i, j), i, tfloat, j, tfloat, 
> > "0.0f")
> >  
> >  
> > diff --git a/src/intel/vulkan/anv_entrypoints_gen.py 
> > b/src/intel/vulkan/anv_entrypoints_gen.py
> > index 8a37336496..5e2cd0740a 100644
> > --- a/src/intel/vulkan/anv_entrypoints_gen.py
> > +++ b/src/intel/vulkan/anv_entrypoints_gen.py
> > @@ -145,7 +145,7 @@ static const struct string_map_entry 
> > string_map_entries[] = {
> >  /* Hash table stats:
> >   * size ${len(strmap.sorted_strings)} entries
> >   * collisions entries:
> > -% for i in xrange(10):
> > +% for i in range(10):
> >   * ${i}${'+' if i == 9 else ' '} ${strmap.collisions[i]}
> >  % endfor
> >   */
> > diff --git a/src/mapi/glapi/gen/glX_proto_send.py 
> > b/src/mapi/glapi/gen/glX_proto_send.py
> > index fba2f0cc1e..a920ecc012 100644
> > --- a/src/mapi/glapi/gen/glX_proto_send.py
> > +++ b/src/mapi/glapi/gen/glX_proto_send.py
> > @@ -392,7 +392,7 @@ static const struct proc_pair
> > _glapi_proc proc;
> >  } proc_pairs[%d] = {""" % len(procs))
> >  names = sorted(procs.keys())
> > -for i in xrange(len(names)):
> > +for i in range(len(names)):
> >  comma = ',' if i < 

[Mesa-dev] [PATCH v2] intel: Make the decoder handle STATE_BASE_ADDRESS not being a buffer.

2018-07-24 Thread Kenneth Graunke
Normally, i965 programs STATE_BASE_ADDRESS every batch, and puts all
state for a given base in a single buffer.

I'm working on a prototype which emits STATE_BASE_ADDRESS only once at
startup, where each base address is a fixed 4GB region of the PPGTT.
State may live in many buffers in that 4GB region, even if there isn't
a buffer located at the actual base address itself.

To handle this, we need to save the STATE_BASE_ADDRESS values across
multiple batches, rather than assuming we'll see the command each time.
Then, each time we see a pointer, we need to ask the driver for the BO
map for that data.  (We can't just use the map for the base address, as
state may be in multiple buffers, and there may not even be a buffer
at the base address to map.)

v2: Fix things caught in review by Lionel:
 - Drop bogus bind_bo.size check.
 - Drop "get the BOs again" code - we just get the BOs as needed
 - Add a message about interface descriptor data being unavailable
---
 src/intel/common/gen_batch_decoder.c | 75 +++-
 src/intel/common/gen_decoder.h   |  9 +++-
 2 files changed, 46 insertions(+), 38 deletions(-)

diff --git a/src/intel/common/gen_batch_decoder.c 
b/src/intel/common/gen_batch_decoder.c
index 727cbb80cfb..c6967ebc053 100644
--- a/src/intel/common/gen_batch_decoder.c
+++ b/src/intel/common/gen_batch_decoder.c
@@ -128,13 +128,13 @@ static void
 ctx_disassemble_program(struct gen_batch_decode_ctx *ctx,
 uint32_t ksp, const char *type)
 {
-   if (!ctx->instruction_base.map)
+   uint64_t addr = ctx->instruction_base.addr + ksp;
+   struct gen_batch_decode_bo bo = ctx_get_bo(ctx, addr);
+   if (!bo.map)
   return;
 
-   printf("\nReferenced %s:\n", type);
-   gen_disasm_disassemble(ctx->disasm,
-  (void *)ctx->instruction_base.map, ksp,
-  ctx->fp);
+   fprintf(ctx->fp, "\nReferenced %s:\n", type);
+   gen_disasm_disassemble(ctx->disasm, bo.map, 0, ctx->fp);
 }
 
 /* Heuristic to determine whether a uint32_t is probably actually a float
@@ -225,35 +225,30 @@ dump_binding_table(struct gen_batch_decode_ctx *ctx, 
uint32_t offset, int count)
if (count < 0)
   count = update_count(ctx, offset, 1, 8);
 
-   if (ctx->surface_base.map == NULL) {
-  fprintf(ctx->fp, "  binding table unavailable\n");
+   if (offset % 32 != 0 || offset >= UINT16_MAX) {
+  fprintf(ctx->fp, "  invalid binding table pointer\n");
   return;
}
 
-   if (offset % 32 != 0 || offset >= UINT16_MAX ||
-   offset >= ctx->surface_base.size) {
-  fprintf(ctx->fp, "  invalid binding table pointer\n");
+   struct gen_batch_decode_bo bind_bo =
+  ctx_get_bo(ctx, ctx->surface_base.addr + offset);
+
+   if (bind_bo.map == NULL) {
+  fprintf(ctx->fp, "  binding table unavailable\n");
   return;
}
 
-   struct gen_batch_decode_bo bo = ctx->surface_base;
-   const uint32_t *pointers = ctx->surface_base.map + offset;
+   const uint32_t *pointers = bind_bo.map;
for (int i = 0; i < count; i++) {
   if (pointers[i] == 0)
  continue;
 
-  if (pointers[i] % 32 != 0) {
- fprintf(ctx->fp, "pointer %u: %08x \n", i, pointers[i]);
- continue;
-  }
-
   uint64_t addr = ctx->surface_base.addr + pointers[i];
+  struct gen_batch_decode_bo bo = ctx_get_bo(ctx, addr);
   uint32_t size = strct->dw_length * 4;
 
-  if (addr < bo.addr || addr + size >= bo.addr + bo.size)
- bo = ctx->get_bo(ctx->user_data, addr);
-
-  if (addr < bo.addr || addr + size >= bo.addr + bo.size) {
+  if (pointers[i] % 32 != 0 ||
+  addr < bo.addr || addr + size >= bo.addr + bo.size) {
  fprintf(ctx->fp, "pointer %u: %08x \n", i, pointers[i]);
  continue;
   }
@@ -271,18 +266,20 @@ dump_samplers(struct gen_batch_decode_ctx *ctx, uint32_t 
offset, int count)
if (count < 0)
   count = update_count(ctx, offset, strct->dw_length, 4);
 
-   if (ctx->dynamic_base.map == NULL) {
+   uint64_t state_addr = ctx->dynamic_base.addr + offset;
+   struct gen_batch_decode_bo bo = ctx_get_bo(ctx, state_addr);
+   const void *state_map = bo.map;
+
+   if (state_map == NULL) {
   fprintf(ctx->fp, "  samplers unavailable\n");
   return;
}
 
-   if (offset % 32 != 0 || offset >= ctx->dynamic_base.size) {
+   if (offset % 32 != 0 || state_addr - bo.addr >= bo.size) {
   fprintf(ctx->fp, "  invalid sampler state pointer\n");
   return;
}
 
-   uint64_t state_addr = ctx->dynamic_base.addr + offset;
-   const void *state_map = ctx->dynamic_base.map + offset;
for (int i = 0; i < count; i++) {
   fprintf(ctx->fp, "sampler state %d\n", i);
   ctx_print_group(ctx, strct, state_addr, state_map);
@@ -295,9 +292,6 @@ static void
 handle_media_interface_descriptor_load(struct gen_batch_decode_ctx *ctx,
const uint32_t *p)
 {
-   if (ctx->dynamic_base.map == NULL)
-  return;
-
struct gen_group 

[Mesa-dev] [PATCH] st/nir: Fix st_nir_opts() prototype.

2018-07-24 Thread Kenneth Graunke
This wasn't updated for the new scalar ISA parameter.  It worked anyway
because all the function's callers live in the same file, so it found
the correct function.  Tim made this external for the new st prog_to_nir
translator, which got reverted, but which I'd like to land eventually.

So, fix the prototype.
---
 src/mesa/state_tracker/st_nir.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_nir.h b/src/mesa/state_tracker/st_nir.h
index 15f1ce93e5a..aa6e32758e8 100644
--- a/src/mesa/state_tracker/st_nir.h
+++ b/src/mesa/state_tracker/st_nir.h
@@ -42,7 +42,7 @@ void st_finalize_nir(struct st_context *st, struct gl_program 
*prog,
  struct gl_shader_program *shader_program,
  struct nir_shader *nir);
 
-void st_nir_opts(struct nir_shader *nir);
+void st_nir_opts(struct nir_shader *nir, bool is_scalar);
 
 bool
 st_link_nir(struct gl_context *ctx,
-- 
2.18.0

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


Re: [Mesa-dev] [PATCH 2/2] intel: Make the decoder handle STATE_BASE_ADDRESS not being a buffer.

2018-07-24 Thread Kenneth Graunke
On Tuesday, July 17, 2018 9:40:29 AM PDT Lionel Landwerlin wrote:
> On 11/07/18 19:25, Kenneth Graunke wrote:
> > Normally, i965 programs STATE_BASE_ADDRESS every batch, and puts all
> > state for a given base in a single buffer.
> >
> > I'm working on a prototype which emits STATE_BASE_ADDRESS only once at
> > startup, where each base address is a fixed 4GB region of the PPGTT.
> > State may live in many buffers in that 4GB region, even if there isn't
> > a buffer located at the actual base address itself.
> >
> > To handle this, we need to save the STATE_BASE_ADDRESS values across
> > multiple batches, rather than assuming we'll see the command each time.
> > Then, each time we see a pointer, we need to ask the driver for the BO
> > map for that data.  (We can't just use the map for the base address, as
> > state may be in multiple buffers, and there may not even be a buffer
> > at the base address to map.)
> > ---
> >   src/intel/common/gen_batch_decoder.c | 83 
> >   src/intel/common/gen_decoder.h   |  9 ++-
> >   2 files changed, 56 insertions(+), 36 deletions(-)
> >
> > diff --git a/src/intel/common/gen_batch_decoder.c 
> > b/src/intel/common/gen_batch_decoder.c
> > index fe7536da9ec..6cb66bcb257 100644
> > --- a/src/intel/common/gen_batch_decoder.c
> > +++ b/src/intel/common/gen_batch_decoder.c
> > @@ -128,13 +128,13 @@ static void
> >   ctx_disassemble_program(struct gen_batch_decode_ctx *ctx,
> >   uint32_t ksp, const char *type)
> >   {
> > -   if (!ctx->instruction_base.map)
> > +   uint64_t addr = ctx->instruction_base.addr + ksp;
> > +   struct gen_batch_decode_bo bo = ctx_get_bo(ctx, addr);
> > +   if (!bo.map)
> > return;
> >   
> > -   printf("\nReferenced %s:\n", type);
> > -   gen_disasm_disassemble(ctx->disasm,
> > -  (void *)ctx->instruction_base.map, ksp,
> > -  ctx->fp);
> > +   fprintf(ctx->fp, "\nReferenced %s:\n", type);
> > +   gen_disasm_disassemble(ctx->disasm, bo.map, 0, ctx->fp);
> >   }
> >   
> >   /* Heuristic to determine whether a uint32_t is probably actually a float
> > @@ -225,35 +225,30 @@ dump_binding_table(struct gen_batch_decode_ctx *ctx, 
> > uint32_t offset, int count)
> >  if (count < 0)
> > count = update_count(ctx, offset, 1, 8);
> >   
> > -   if (ctx->surface_base.map == NULL) {
> > +   struct gen_batch_decode_bo bind_bo =
> > +  ctx_get_bo(ctx, ctx->surface_base.addr + offset);
> > +
> > +   if (bind_bo.map == NULL) {
> > fprintf(ctx->fp, "  binding table unavailable\n");
> > return;
> >  }
> >   
> > -   if (offset % 32 != 0 || offset >= UINT16_MAX ||
> > -   offset >= ctx->surface_base.size) {
> > +   if (offset % 32 != 0 || offset >= UINT16_MAX || offset >= bind_bo.size) 
> > {
> 
> I wonder if this
> 
> offset >= bind_bo.size
> 
> is right. That's assuming bind_bo.addr == ctx->surface_base.addr, but in 
> your prototype it probably won't be, right?
> 
> 
> I would check (ctx->surface_base.addr + offset) >= (bind_bo.addr + 
> bind_bo.size)

Yeah, I agree, this is wrong.  I think we should just drop the
offset >= bind_bo.size check.  We're already doing ctx_get_bo()
at surface_base.addr + offset...and since we've checked bind_bo.map
isn't NULL...we know the start of the binding table is in the BO.

I'll also move these checks above the ctx_get_bo() call, so we validate
the alignment and maximum amount restrictions from the packet before
using it to look up anything.

> > fprintf(ctx->fp, "  invalid binding table pointer\n");
> > return;
> >  }
> >   
> > -   struct gen_batch_decode_bo bo = ctx->surface_base;
> > -   const uint32_t *pointers = ctx->surface_base.map + offset;
> > +   const uint32_t *pointers = bind_bo.map;
> >  for (int i = 0; i < count; i++) {
> > if (pointers[i] == 0)
> >continue;
> >   
> > -  if (pointers[i] % 32 != 0) {
> > - fprintf(ctx->fp, "pointer %u: %08x \n", i, 
> > pointers[i]);
> > - continue;
> > -  }
> > -
> > uint64_t addr = ctx->surface_base.addr + pointers[i];
> > +  struct gen_batch_decode_bo bo = ctx_get_bo(ctx, addr);
> > uint32_t size = strct->dw_length * 4;
> >   
> > -  if (addr < bo.addr || addr + size >= bo.addr + bo.size)
> > - bo = ctx->get_bo(ctx->user_data, addr);
> > -
> > -  if (addr < bo.addr || addr + size >= bo.addr + bo.size) {
> > +  if (pointers[i] % 32 != 0 ||
> > +  addr < bo.addr || addr + size >= bo.addr + bo.size) {
> >fprintf(ctx->fp, "pointer %u: %08x \n", i, 
> > pointers[i]);
> >continue;
> > }
> > @@ -271,18 +266,20 @@ dump_samplers(struct gen_batch_decode_ctx *ctx, 
> > uint32_t offset, int count)
> >  if (count < 0)
> > count = update_count(ctx, offset, strct->dw_length, 4);
> >   
> > -   if (ctx->dynamic_base.map == NULL) {
> > +   uint64_t state_addr = ctx->dynamic_base.addr + 

Re: [Mesa-dev] [PATCH 1/2] mesa: add glRenderbufferStorage support for EXT_texture_norm16 formats

2018-07-24 Thread Nanley Chery
On Tue, Jul 24, 2018 at 08:58:20AM +0300, Tapani Pälli wrote:
> These bits were missing, found when extending the Piglit test.
> 
> Fixes: 7f467d4f73 "mesa: GL_EXT_texture_norm16 extension plumbing"
> Signed-off-by: Tapani Pälli 
> ---
>  src/mesa/main/fbobject.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 

Shouldn't we also update is_format_color_renderable?

Nonetheless, this series is an improvement and is
Reviewed-by: Nanley Chery 

> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index fa7a9361df..679e206c71 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -1927,8 +1927,10 @@ _mesa_base_fbo_format(const struct gl_context *ctx, 
> GLenum internalFormat)
> case GL_RGBA:
> case GL_RGBA2:
> case GL_RGBA12:
> -   case GL_RGBA16:
>return _mesa_is_desktop_gl(ctx) ? GL_RGBA : 0;
> +   case GL_RGBA16:
> +  return _mesa_is_desktop_gl(ctx) || _mesa_has_EXT_texture_norm16(ctx)
> + ? GL_RGBA : 0;
> case GL_RGB10_A2:
> case GL_SRGB8_ALPHA8_EXT:
>return _mesa_is_desktop_gl(ctx) || _mesa_is_gles3(ctx) ? GL_RGBA : 0;
> @@ -1963,15 +1965,17 @@ _mesa_base_fbo_format(const struct gl_context *ctx, 
> GLenum internalFormat)
>   ctx->Extensions.ARB_depth_buffer_float)
>   ? GL_DEPTH_STENCIL : 0;
> case GL_RED:
> +  return _mesa_has_ARB_texture_rg(ctx) ? GL_RED : 0;
> case GL_R16:
> -  return _mesa_is_desktop_gl(ctx) && ctx->Extensions.ARB_texture_rg
> +  return _mesa_has_ARB_texture_rg(ctx) || 
> _mesa_has_EXT_texture_norm16(ctx)
>   ? GL_RED : 0;
> case GL_R8:
>return ctx->API != API_OPENGLES && ctx->Extensions.ARB_texture_rg
>   ? GL_RED : 0;
> case GL_RG:
> +  return _mesa_has_ARB_texture_rg(ctx) ? GL_RG : 0;
> case GL_RG16:
> -  return _mesa_is_desktop_gl(ctx) && ctx->Extensions.ARB_texture_rg
> +  return _mesa_has_ARB_texture_rg(ctx) || 
> _mesa_has_EXT_texture_norm16(ctx)
>   ? GL_RG : 0;
> case GL_RG8:
>return ctx->API != API_OPENGLES && ctx->Extensions.ARB_texture_rg
> -- 
> 2.14.4
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 106644] [llvmpipe] Mesa 18.1.2 fails lp_test_format, lp_test_arit, lp_test_blend, lp_test_printf, lp_test_conv tests

2018-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106644

--- Comment #41 from Roland Scheidegger  ---
(In reply to Ben Crocker from comment #40)
> 'make check'/lp_test_arit fails in exactly the same way when I run it
> on a ppc64le machine.

That is sort of expected I guess. We only use "arch rounding" with either sse41
or altivec. sse2 has a special path too (as it can do float->int conversion
with nearest rounding).
All other architectures will do round via float->int conversion (by doing float
add with +-0.5 depending on sign first) - look at lp_build_round. This will do
nearest rounding, but not nearest even, which the test expects.
I think this should not be a problem in practice. If your chip does have native
rounding instructions, you could try forcing the same path as what we use with
sse41 - which is using llvm.nearbyint (in theory I suppose it should work with
architectures which don't support this natively, but if you're unlucky it will
just try to call into some math lib which is definitely no good and will just
crash, and even if it would work you don't want to do that). If it's natively
supported, not only should this be more correct, but also be much faster.

-- 
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 106644] [llvmpipe] Mesa 18.1.2 fails lp_test_format, lp_test_arit, lp_test_blend, lp_test_printf, lp_test_conv tests

2018-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106644

--- Comment #40 from Ben Crocker  ---
'make check'/lp_test_arit fails in exactly the same way when I run it
on a ppc64le machine.

-- 
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] intel: tools: dump: only store device id on success

2018-07-24 Thread Lionel Landwerlin
We might fail on master node drm fd because we won't have the right
permissions.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/tools/intel_dump_gpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/intel/tools/intel_dump_gpu.c b/src/intel/tools/intel_dump_gpu.c
index 1abe54147cf..a71103f1889 100644
--- a/src/intel/tools/intel_dump_gpu.c
+++ b/src/intel/tools/intel_dump_gpu.c
@@ -111,7 +111,7 @@ align_u32(uint32_t v, uint32_t a)
 }
 
 static struct gen_device_info devinfo = {0};
-static uint32_t device;
+static uint32_t device = 0;
 static struct aub_file aub_file;
 
 static void *
@@ -419,7 +419,7 @@ ioctl(int fd, unsigned long request, ...)
   * (they typically do), we'll piggy-back on
   * their ioctl and store the id for later
   * use. */
- if (getparam->param == I915_PARAM_CHIPSET_ID)
+ if (ret == 0 && getparam->param == I915_PARAM_CHIPSET_ID)
 device = *getparam->value;
 
  return ret;
-- 
2.18.0

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


Re: [Mesa-dev] [PATCH] r600: Scale integer valued texture border colors to float (v2)

2018-07-24 Thread Gert Wollny
whitespace errors were fixed locally

best, 
Gert 

Am Dienstag, den 24.07.2018, 21:27 +0200 schrieb Gert Wollny:
> It seems the hardware always expects floating point border color
> values
> [0,1] for unsigned, and [-1,1] for signed texture component,
> regardless
> of pixel type, but the border colors are passed according to texture
> component type. Hence, before submitting the border color, convert
> and
> scale it these ranges accordingly.
> 
> This doesn't seem to work for textures with 32 bit integer components
> though, here, it seems that the border color is always set to zero,
> regardless of the BORDER_COLOR_TYPE state set in
> Q_TEX_SAMPLER_WORD0_0.
> 
> v2: Simplyfy logic as suggested by Roland Schneidegger
> 
> Fixes:
>   dEQP-GLES31.functional.texture.border_clamp.formats.compressed*
>   dEQP-GLES31.functional.texture.border_clamp.formats.r* (non 32 bit
> integer)
>   dEQP-
> GLES31.functional.texture.border_clamp.per_axis_wrap_mode.texture_2d*
>  and a number of piglits out of 
>   piglit run gpu -t texture -t gather -t formats 
> 
> Signed-off-by: Gert Wollny 
> ---
>  src/gallium/drivers/r600/evergreen_state.c | 45
> +-
>  1 file changed, 44 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/r600/evergreen_state.c
> b/src/gallium/drivers/r600/evergreen_state.c
> index d100cfab1d..e7207a500b 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -2402,6 +2402,37 @@ static void
> evergreen_emit_cs_sampler_views(struct r600_context *rctx, struct r6
>EG_FETCH_CONSTANTS_OFFSET_CS +
> R600_MAX_CONST_BUFFERS, RADEON_CP_PACKET3_COMPUTE_MODE);
>  }
>  
> +static void evergreen_convert_border_color(union pipe_color_union
> *in,
> +   union pipe_color_union
> *out,
> +   enum pipe_format format)
> +{
> + if (util_format_is_pure_integer(format) &&
> +  !util_format_is_depth_or_stencil(format)) {
> + const struct util_format_description *d =
> util_format_description(format);
> +
> + for (int i = 0; i < d->nr_channels; ++i) {
> + int cs = d->channel[i].size;
> + if (d->channel[i].type ==
> UTIL_FORMAT_TYPE_SIGNED)
> + out->f[i] = (double)(in->i[i]) /
> ((1ul << (cs - 1)) - 1 );
> + else if (d->channel[i].type ==
> UTIL_FORMAT_TYPE_UNSIGNED)
> + out->f[i] = (double)(in->ui[i]) /
> ((1ul << cs) - 1 );
> + else
> + out->f[i] = 0;
> + }
> +
> + } else {
> + switch (format) {
> +  case PIPE_FORMAT_X24S8_UINT:
> +  case PIPE_FORMAT_X32_S8X24_UINT:
Whitespace error fixed locally. 

> + out->f[0] = (double)(in->ui[0]) / 255.0;
> + out->f[1] = out->f[2] = out->f[3] = 0.0f;
> + break;
> + default:
> + memcpy(out->f, in->f, 4 * sizeof(float));
> + }
> + }
> +}
> +
>  static void evergreen_emit_sampler_states(struct r600_context *rctx,
>   struct r600_textures_info *texinfo,
>   unsigned resource_id_base,
> @@ -2410,6 +2441,8 @@ static void
> evergreen_emit_sampler_states(struct r600_context *rctx,
>  {
>   struct radeon_cmdbuf *cs = rctx->b.gfx.cs;
>   uint32_t dirty_mask = texinfo->states.dirty_mask;
> + union pipe_color_union border_color = {{0,0,0,1}};
> + union pipe_color_union *border_color_ptr = _color;
>  
>   while (dirty_mask) {
>   struct r600_pipe_sampler_state *rstate;
> @@ -2418,6 +2451,16 @@ static void
> evergreen_emit_sampler_states(struct r600_context *rctx,
>   rstate = texinfo->states.states[i];
>   assert(rstate);
>  
> + if (rstate->border_color_use) {
> + struct r600_pipe_sampler_view   *rview
> = texinfo->views.views[i];
> + if (rview) {
> + evergreen_convert_border_color(
> te->border_color,
> +
> er_color, rview->base.format);
> + } else {
> + border_color_ptr = 
> >border_color;
> + }
> + }
> +
>   radeon_emit(cs, PKT3(PKT3_SET_SAMPLER, 3, 0) |
> pkt_flags);
>   radeon_emit(cs, (resource_id_base + i) * 3);
>   radeon_emit_array(cs, rstate->tex_sampler_words, 3);
> @@ -2425,7 +2468,7 @@ static void
> evergreen_emit_sampler_states(struct r600_context *rctx,
>   if (rstate->border_color_use) {
>   radeon_set_config_reg_seq(cs,
> border_index_reg, 5);
>   radeon_emit(cs, i);
> - radeon_emit_array(cs, 

Re: [Mesa-dev] [PATCH] mesa: allow indirect draws with the default VAO and compatibility profile

2018-07-24 Thread Eric Anholt
Marek Olšák  writes:

> From: Marek Olšák 

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] [PATCH 1/2] mesa: add glRenderbufferStorage support for EXT_texture_norm16 formats

2018-07-24 Thread Eric Anholt
Tapani Pälli  writes:

> These bits were missing, found when extending the Piglit test.
>
> Fixes: 7f467d4f73 "mesa: GL_EXT_texture_norm16 extension plumbing"
> Signed-off-by: Tapani Pälli 

Aren't you missing the RGB16 and R/RG/RGB/RGBA16_SNORM cases here?  They
aren't required for rendering, but if the implementation supports them
we should answer correctly.


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] r600: Scale integer valued texture border colors to float (v2)

2018-07-24 Thread Gert Wollny
It seems the hardware always expects floating point border color values
[0,1] for unsigned, and [-1,1] for signed texture component, regardless
of pixel type, but the border colors are passed according to texture
component type. Hence, before submitting the border color, convert and
scale it these ranges accordingly.

This doesn't seem to work for textures with 32 bit integer components
though, here, it seems that the border color is always set to zero,
regardless of the BORDER_COLOR_TYPE state set in Q_TEX_SAMPLER_WORD0_0.

v2: Simplyfy logic as suggested by Roland Schneidegger

Fixes:
  dEQP-GLES31.functional.texture.border_clamp.formats.compressed*
  dEQP-GLES31.functional.texture.border_clamp.formats.r* (non 32 bit integer)
  dEQP-GLES31.functional.texture.border_clamp.per_axis_wrap_mode.texture_2d*
 and a number of piglits out of 
  piglit run gpu -t texture -t gather -t formats 

Signed-off-by: Gert Wollny 
---
 src/gallium/drivers/r600/evergreen_state.c | 45 +-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index d100cfab1d..e7207a500b 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -2402,6 +2402,37 @@ static void evergreen_emit_cs_sampler_views(struct 
r600_context *rctx, struct r6
 EG_FETCH_CONSTANTS_OFFSET_CS + 
R600_MAX_CONST_BUFFERS, RADEON_CP_PACKET3_COMPUTE_MODE);
 }
 
+static void evergreen_convert_border_color(union pipe_color_union *in,
+   union pipe_color_union *out,
+   enum pipe_format format)
+{
+   if (util_format_is_pure_integer(format) &&
+!util_format_is_depth_or_stencil(format)) {
+   const struct util_format_description *d = 
util_format_description(format);
+
+   for (int i = 0; i < d->nr_channels; ++i) {
+   int cs = d->channel[i].size;
+   if (d->channel[i].type == UTIL_FORMAT_TYPE_SIGNED)
+   out->f[i] = (double)(in->i[i]) / ((1ul << (cs - 
1)) - 1 );
+   else if (d->channel[i].type == 
UTIL_FORMAT_TYPE_UNSIGNED)
+   out->f[i] = (double)(in->ui[i]) / ((1ul << cs) 
- 1 );
+   else
+   out->f[i] = 0;
+   }
+
+   } else {
+   switch (format) {
+  case PIPE_FORMAT_X24S8_UINT:
+  case PIPE_FORMAT_X32_S8X24_UINT:
+   out->f[0] = (double)(in->ui[0]) / 255.0;
+   out->f[1] = out->f[2] = out->f[3] = 0.0f;
+   break;
+   default:
+   memcpy(out->f, in->f, 4 * sizeof(float));
+   }
+   }
+}
+
 static void evergreen_emit_sampler_states(struct r600_context *rctx,
struct r600_textures_info *texinfo,
unsigned resource_id_base,
@@ -2410,6 +2441,8 @@ static void evergreen_emit_sampler_states(struct 
r600_context *rctx,
 {
struct radeon_cmdbuf *cs = rctx->b.gfx.cs;
uint32_t dirty_mask = texinfo->states.dirty_mask;
+   union pipe_color_union border_color = {{0,0,0,1}};
+   union pipe_color_union *border_color_ptr = _color;
 
while (dirty_mask) {
struct r600_pipe_sampler_state *rstate;
@@ -2418,6 +2451,16 @@ static void evergreen_emit_sampler_states(struct 
r600_context *rctx,
rstate = texinfo->states.states[i];
assert(rstate);
 
+   if (rstate->border_color_use) {
+   struct r600_pipe_sampler_view   *rview = 
texinfo->views.views[i];
+   if (rview) {
+   
evergreen_convert_border_color(>border_color,
+  _color, 
rview->base.format);
+   } else {
+   border_color_ptr = >border_color;
+   }
+   }
+
radeon_emit(cs, PKT3(PKT3_SET_SAMPLER, 3, 0) | pkt_flags);
radeon_emit(cs, (resource_id_base + i) * 3);
radeon_emit_array(cs, rstate->tex_sampler_words, 3);
@@ -2425,7 +2468,7 @@ static void evergreen_emit_sampler_states(struct 
r600_context *rctx,
if (rstate->border_color_use) {
radeon_set_config_reg_seq(cs, border_index_reg, 5);
radeon_emit(cs, i);
-   radeon_emit_array(cs, rstate->border_color.ui, 4);
+   radeon_emit_array(cs, border_color_ptr->ui, 4);
}
}
texinfo->states.dirty_mask = 0;
-- 
2.16.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

[Mesa-dev] [Bug 106644] [llvmpipe] Mesa 18.1.2 fails lp_test_format, lp_test_arit, lp_test_blend, lp_test_printf, lp_test_conv tests

2018-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106644

--- Comment #39 from Ben Crocker  ---
Note that all the lp_test_format failures seem to have to do with
packing/unpacking of "exotic: formats, while the lp_test_arit failures
have to do with rounding.

FAIL: lp_test_format

PIPE_FORMAT_B5G5R5A1_UNORM (float)
PIPE_FORMAT_B5G5R5A1_UNORM (unorm8)
PIPE_FORMAT_B4G4R4A4_UNORM (float)
PIPE_FORMAT_B4G4R4A4_UNORM (unorm8)
PIPE_FORMAT_B5G6R5_UNORM (float)
PIPE_FORMAT_B5G6R5_UNORM (unorm8)
PIPE_FORMAT_R10G10B10A2_UNORM (float)
PIPE_FORMAT_R10G10B10A2_UNORM (unorm8)
PIPE_FORMAT_R32_FLOAT (float)
PIPE_FORMAT_R32_FLOAT (unorm8)
PIPE_FORMAT_R32G32_FLOAT (float)
PIPE_FORMAT_R32G32_FLOAT (unorm8)
PIPE_FORMAT_R32G32B32_FLOAT (float)
PIPE_FORMAT_R32G32B32_FLOAT (unorm8)
PIPE_FORMAT_R32G32B32A32_FLOAT (float)
PIPE_FORMAT_R32G32B32A32_FLOAT (unorm8)
PIPE_FORMAT_R32_USCALED (float)
PIPE_FORMAT_R32G32_USCALED (float)
PIPE_FORMAT_R32G32B32_USCALED (float)
PIPE_FORMAT_R32G32B32A32_USCALED (float
PIPE_FORMAT_R32_SNORM (float)
PIPE_FORMAT_R32_SNORM (unorm8)
PIPE_FORMAT_R32G32_SNORM (float)
PIPE_FORMAT_R32G32_SNORM (unorm8)
PIPE_FORMAT_R32G32B32_SNORM (float)
PIPE_FORMAT_R32G32B32_SNORM (unorm8)
PIPE_FORMAT_R32G32B32A32_SNORM (float)
PIPE_FORMAT_R32G32B32A32_SNORM (unorm8)
PIPE_FORMAT_R32_SSCALED (float)
PIPE_FORMAT_R32_SSCALED (unorm8)
PIPE_FORMAT_R32G32_SSCALED (float)
PIPE_FORMAT_R32G32_SSCALED (unorm8)
PIPE_FORMAT_R32G32B32_SSCALED (float)
PIPE_FORMAT_R32G32B32_SSCALED (unorm8)
PIPE_FORMAT_R32G32B32A32_SSCALED (float)
PIPE_FORMAT_R32G32B32A32_SSCALED (unorm8)
PIPE_FORMAT_R16_SNORM (float)
PIPE_FORMAT_R16_SNORM (unorm8)
PIPE_FORMAT_R16G16_SNORM (float)
PIPE_FORMAT_R16G16_SNORM (unorm8)
PIPE_FORMAT_R16G16B16_SNORM (float)
PIPE_FORMAT_R16G16B16_SNORM (unorm8)
PIPE_FORMAT_R16G16B16A16_SNORM (float)
PIPE_FORMAT_R16G16B16A16_SNORM (unorm8)
PIPE_FORMAT_R16_SSCALED (float)
PIPE_FORMAT_R16_SSCALED (unorm8)
PIPE_FORMAT_R16G16_SSCALED (float)
PIPE_FORMAT_R16G16_SSCALED (unorm8)
PIPE_FORMAT_R16G16B16_SSCALED (float)
PIPE_FORMAT_R16G16B16_SSCALED (unorm8)
PIPE_FORMAT_R16G16B16A16_SSCALED (float)
PIPE_FORMAT_R16G16B16A16_SSCALED (unorm8)
PIPE_FORMAT_R8G8B8_UNORM (unorm8)
PIPE_FORMAT_R32_FIXED (float)
PIPE_FORMAT_R32_FIXED (unorm8)
PIPE_FORMAT_R32G32_FIXED (float)
PIPE_FORMAT_R32G32_FIXED (unorm8)
PIPE_FORMAT_R32G32B32_FIXED (float)
PIPE_FORMAT_R32G32B32_FIXED (unorm8)
PIPE_FORMAT_R32G32B32A32_FIXED (float)
PIPE_FORMAT_R32G32B32A32_FIXED (unorm8)
PIPE_FORMAT_R16_FLOAT (float)
PIPE_FORMAT_R16_FLOAT (unorm8)
PIPE_FORMAT_R16G16_FLOAT (float)
PIPE_FORMAT_R16G16_FLOAT (unorm8)
PIPE_FORMAT_R16G16B16_FLOAT (float)
PIPE_FORMAT_R16G16B16_FLOAT (unorm8)
PIPE_FORMAT_R16G16B16A16_FLOAT (float)
PIPE_FORMAT_R16G16B16A16_FLOAT (unorm8)
PIPE_FORMAT_R5SG5SB6U_NORM (float)
PIPE_FORMAT_R5SG5SB6U_NORM (unorm8)
PIPE_FORMAT_B5G5R5X1_UNORM (float)
PIPE_FORMAT_B5G5R5X1_UNORM (unorm8)
PIPE_FORMAT_R10G10B10X2_USCALED (float)
PIPE_FORMAT_R10G10B10X2_USCALED (unorm8)
PIPE_FORMAT_R10G10B10X2_SNORM (float)
PIPE_FORMAT_R10G10B10X2_SNORM (unorm8)
PIPE_FORMAT_L4A4_UNORM (unorm8)
PIPE_FORMAT_B10G10R10A2_UNORM (float)
PIPE_FORMAT_B10G10R10A2_UNORM (unorm8)
PIPE_FORMAT_R10SG10SB10SA2U_NORM (float)
PIPE_FORMAT_R10SG10SB10SA2U_NORM (unorm8)
PIPE_FORMAT_B4G4R4X4_UNORM (float)
PIPE_FORMAT_B4G4R4X4_UNORM (unorm8)
PIPE_FORMAT_R10G10B10X2_UNORM (float)
PIPE_FORMAT_R10G10B10X2_UNORM (unorm8)
PIPE_FORMAT_A1B5G5R5_UNORM (float)
PIPE_FORMAT_A1B5G5R5_UNORM (unorm8)
PIPE_FORMAT_X1B5G5R5_UNORM (float)
PIPE_FORMAT_X1B5G5R5_UNORM (unorm8)

FAIL: lp_test_arit
==
round.v1(-0.5): ref = -0, out = -1, precision = -inf bits, FAIL
round.v1(0.5): ref = 0, out = 1, precision = -inf bits, FAIL

-- 
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] [Mesa-stable] [PATCH] nir/serialize: Alloc constants off the variable

2018-07-24 Thread Mark Janes
Please add the bugzilla reference for 107366

Tested-by: Mark Janes 

Jason Ekstrand  writes:

> nir_sweep assumes that constants area always allocated off the variable
> to which they belong.  Violating this assumption causes them to get
> freed early and leads to use-after-free bugs.
>
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/compiler/nir/nir_serialize.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/nir/nir_serialize.c 
> b/src/compiler/nir/nir_serialize.c
> index 6a30738c2d7..43016310048 100644
> --- a/src/compiler/nir/nir_serialize.c
> +++ b/src/compiler/nir/nir_serialize.c
> @@ -124,7 +124,7 @@ read_constant(read_ctx *ctx, nir_variable *nvar)
>  
> blob_copy_bytes(ctx->blob, (uint8_t *)c->values, sizeof(c->values));
> c->num_elements = blob_read_uint32(ctx->blob);
> -   c->elements = ralloc_array(ctx->nir, nir_constant *, c->num_elements);
> +   c->elements = ralloc_array(nvar, nir_constant *, c->num_elements);
> for (unsigned i = 0; i < c->num_elements; i++)
>c->elements[i] = read_constant(ctx, nvar);
>  
> -- 
> 2.17.1
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] nir/serialize: Alloc constants off the variable

2018-07-24 Thread Lionel Landwerlin

On 24/07/18 19:02, Jason Ekstrand wrote:

nir_sweep assumes that constants area always allocated off the variable
to which they belong.  Violating this assumption causes them to get
freed early and leads to use-after-free bugs.

Cc: mesa-sta...@lists.freedesktop.org


Reviewed-by: Lionel Landwerlin 


---
  src/compiler/nir/nir_serialize.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_serialize.c b/src/compiler/nir/nir_serialize.c
index 6a30738c2d7..43016310048 100644
--- a/src/compiler/nir/nir_serialize.c
+++ b/src/compiler/nir/nir_serialize.c
@@ -124,7 +124,7 @@ read_constant(read_ctx *ctx, nir_variable *nvar)
  
 blob_copy_bytes(ctx->blob, (uint8_t *)c->values, sizeof(c->values));

 c->num_elements = blob_read_uint32(ctx->blob);
-   c->elements = ralloc_array(ctx->nir, nir_constant *, c->num_elements);
+   c->elements = ralloc_array(nvar, nir_constant *, c->num_elements);
 for (unsigned i = 0; i < c->num_elements; i++)
c->elements[i] = read_constant(ctx, nvar);
  



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


[Mesa-dev] [PATCH] nir/serialize: Alloc constants off the variable

2018-07-24 Thread Jason Ekstrand
nir_sweep assumes that constants area always allocated off the variable
to which they belong.  Violating this assumption causes them to get
freed early and leads to use-after-free bugs.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/compiler/nir/nir_serialize.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_serialize.c b/src/compiler/nir/nir_serialize.c
index 6a30738c2d7..43016310048 100644
--- a/src/compiler/nir/nir_serialize.c
+++ b/src/compiler/nir/nir_serialize.c
@@ -124,7 +124,7 @@ read_constant(read_ctx *ctx, nir_variable *nvar)
 
blob_copy_bytes(ctx->blob, (uint8_t *)c->values, sizeof(c->values));
c->num_elements = blob_read_uint32(ctx->blob);
-   c->elements = ralloc_array(ctx->nir, nir_constant *, c->num_elements);
+   c->elements = ralloc_array(nvar, nir_constant *, c->num_elements);
for (unsigned i = 0; i < c->num_elements; i++)
   c->elements[i] = read_constant(ctx, nvar);
 
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH v2] intel/ppgtt: memory address alignment

2018-07-24 Thread Lionel Landwerlin

On 24/07/18 18:34, Kenneth Graunke wrote:

On Tuesday, July 24, 2018 5:34:57 AM PDT Lionel Landwerlin wrote:

That looks correct to me (and we do the same in Anv).
Also a bit baffled that we haven't run into issues earlier :(

But would be good to have Ken's Rb too.

Thanks a lot!

Reviewed-by: Lionel Landwerlin 

Yeah, this is probably for the best...we used to just ask the kernel
for memory and it would do this for us.  Now that we're doing it
ourselves, we ought to be defensive here.

Reviewed-by: Kenneth Graunke 

But I agree with Chris, I'm surprised that this would actually fix
anything...all of our allocations ought to multiples of PAGE_SIZE,
so unless we're starting at a funny address, they ought to remain
that way...

I wonder if this isn't papering over another bug.


Sergii,

If you can reproduce this bug locally, would you mind adding

 assert(size % 4096 == 0);

at the top of vma_alloc() and see if it hits the asserts.
Having a backtrace would be great :)

Thanks a lot,

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


Re: [Mesa-dev] [PATCH v2] intel/ppgtt: memory address alignment

2018-07-24 Thread Kenneth Graunke
On Tuesday, July 24, 2018 5:34:57 AM PDT Lionel Landwerlin wrote:
> That looks correct to me (and we do the same in Anv).
> Also a bit baffled that we haven't run into issues earlier :(
> 
> But would be good to have Ken's Rb too.
> 
> Thanks a lot!
> 
> Reviewed-by: Lionel Landwerlin 

Yeah, this is probably for the best...we used to just ask the kernel
for memory and it would do this for us.  Now that we're doing it
ourselves, we ought to be defensive here.

Reviewed-by: Kenneth Graunke 

But I agree with Chris, I'm surprised that this would actually fix
anything...all of our allocations ought to multiples of PAGE_SIZE,
so unless we're starting at a funny address, they ought to remain
that way...

I wonder if this isn't papering over another bug.


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


Re: [Mesa-dev] [PATCH v2 1/3] i965: Sweep NIR after linking phase to free held memory

2018-07-24 Thread Mark Janes
This patch segfaults when both of the following environment variables
are set:

NIR_TEST_CLONE=true
NIR_TEST_SERIALIZE=true

Dylan -- please do not apply this to any stable branch until this bug
has been resolved:

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

-Mark

Danylo Piliaiev  writes:

> After optimization passes and many trasfromations most of memory
> NIR holds is a garbage which was being freed only after shader deletion.
> Freeing it at the end of linking will save memory which would be useful
> in case there are a lot of complex shaders being compiled.
> The common case for this issue is 32bit game running under Wine.
>
> The cost of the optimization is around ~3-5% of compilation speed
> with complex shaders.
>
> V2: by Jason Ekstrand
> - Move nir_sweep up, right after the last change of NIR
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103274
>
> Signed-off-by: Danylo Piliaiev 
> ---
>  src/mesa/drivers/dri/i965/brw_link.cpp | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp 
> b/src/mesa/drivers/dri/i965/brw_link.cpp
> index 1071056f14..378426101b 100644
> --- a/src/mesa/drivers/dri/i965/brw_link.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_link.cpp
> @@ -317,6 +317,8 @@ brw_link_shader(struct gl_context *ctx, struct 
> gl_shader_program *shProg)
>NIR_PASS_V(prog->nir, nir_lower_atomics_to_ssbo,
>   prog->nir->info.num_abos);
>  
> +  nir_sweep(prog->nir);
> +
>infos[stage] = >nir->info;
>  
>update_xfb_info(prog->sh.LinkedTransformFeedback, infos[stage]);
> -- 
> 2.17.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 1/7] mesa: add ASTC 2D LDR decoder

2018-07-24 Thread Marek Olšák
On Tue, Jul 24, 2018 at 6:17 AM, Eric Engestrom
 wrote:
> On Monday, 2018-07-23 19:52:01 -0400, Marek Olšák wrote:
>> From: Marek Olšák 
>>
>> ---
>>  src/mesa/Makefile.sources  |2 +
>>  src/mesa/main/formats.c|   42 +
>>  src/mesa/main/formats.h|3 +
>>  src/mesa/main/texcompress_astc.cpp | 1871 
>>  src/mesa/main/texcompress_astc.h   |   47 +
>>  src/util/half_float.c  |   59 +
>>  src/util/half_float.h  |5 +
>>  7 files changed, 2029 insertions(+)
>>  create mode 100644 src/mesa/main/texcompress_astc.cpp
>>  create mode 100644 src/mesa/main/texcompress_astc.h
>>
>> diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
>> index 63f3734c322..ae8934e2830 100644
>> --- a/src/mesa/Makefile.sources
>> +++ b/src/mesa/Makefile.sources
>> @@ -207,20 +207,22 @@ MAIN_FILES = \
>>   main/shader_query.cpp \
>>   main/shared.c \
>>   main/shared.h \
>>   main/state.c \
>>   main/state.h \
>>   main/stencil.c \
>>   main/stencil.h \
>>   main/syncobj.c \
>>   main/syncobj.h \
>>   main/texcompress.c \
>> + main/texcompress_astc.cpp \
>> + main/texcompress_astc.h \
>>   main/texcompress_bptc.c \
>>   main/texcompress_bptc.h \
>>   main/texcompress_bptc_tmp.h \
>>   main/texcompress_cpal.c \
>>   main/texcompress_cpal.h \
>>   main/texcompress_etc.c \
>>   main/texcompress_etc.h \
>>   main/texcompress_etc_tmp.h \
>>   main/texcompress_fxt1.c \
>>   main/texcompress_fxt1.h \
>
> And to avoid breaking meson :)
>
> 8<
> diff --git a/src/mesa/meson.build b/src/mesa/meson.build
> index 8fb7db215c8f39212c07..29633691ee776089bc35 100644
> --- a/src/mesa/meson.build
> +++ b/src/mesa/meson.build
> @@ -254,6 +254,8 @@ files_libmesa_common = files(
>'main/syncobj.c',
>'main/syncobj.h',
>'main/texcompress.c',
> +  'main/texcompress_astc.cpp',
> +  'main/texcompress_astc.h',
>'main/texcompress_bptc.c',
>'main/texcompress_bptc.h',
>'main/texcompress_cpal.c',
> >8
>

Applied. Thanks.

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


Re: [Mesa-dev] [PATCH 2/2] i965: Context aware user space EU control through application

2018-07-24 Thread Marathe, Yogesh
> -Original Message-
> From: Landwerlin, Lionel G
> Sent: Tuesday, July 24, 2018 10:24 PM
> To: Marathe, Yogesh ; Chris Wilson  wilson.co.uk>; Muthukumar, Aravindan ;
> mesa-dev@lists.freedesktop.org
> Cc: Diwakar, Praveen 
> Subject: Re: [Mesa-dev] [PATCH 2/2] i965: Context aware user space EU control
> through application
> 
> On 24/07/18 17:41, Marathe, Yogesh wrote:
> > Lionel, Chris,
> >
> >> -Original Message-
> >> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> >> Behalf Of Lionel Landwerlin
> >> Sent: Friday, July 20, 2018 3:31 PM
> >> To: Chris Wilson ; Muthukumar, Aravindan
> >> ; mesa-dev@lists.freedesktop.org
> >> Subject: Re: [Mesa-dev] [PATCH 2/2] i965: Context aware user space EU
> >> control through application
> >>
> >> On 20/07/18 09:47, Chris Wilson wrote:
> >>> Quoting aravindan.muthuku...@intel.com (2018-07-20 09:32:57)
>  From: "Muthukumar, Aravindan" 
> 
> The Patch here is to give control to user/ application to really
> decide what's the max GPU load it would put. If that can be
> known in advance, rpcs can be programmed accordingly.
> This solution has changes across i915,
> drm and mesa (not limited only to kernel).
> 
> Here, we pass gpu_load_type = {high, medium, low} from application
> while context is created. Default here is 'High' and applications
> roughly know if they are going to eat up entire GPU. The typical
> usecase of 'Low' is idle screen or minor mouse movements. Users can
> read meaning of high/medium/low for their platform  & then program
> contexts accordingly. Here gpu_load_type directly translates to
> number of shader cores/EUs a particular GPU has.
> 
> Signed-off-by: Aravindan Muthukumar
> 
> Signed-off-by: Kedar J Karanje 
> Signed-off-by: Praveen Diwakar 
> Signed-off-by: Yogesh Marathe 
>  +/* Dynamic Eu control */
>  +struct drm_i915_load_type {
>  +   __u32 ctx_id;
>  +   __u32 load_type;
>  +};
>  +
>  +/* DYNAMIC EU CONTROL */
>  +int
>  +brw_hw_context_load_type(struct brw_bufmgr *bufmgr,
>  +uint32_t ctx_id,
>  +int load_type) {
>  +   struct drm_i915_load_type type = {
>  +   .ctx_id = ctx_id,
>  +   .load_type = load_type,
>  +   };
>  +   int err;
>  +
>  +   err = 0;
>  +   if(drmIoctl(bufmgr->fd, DRM_IOCTL_I915_LOAD_TYPE, ))
>  +   err = -errno;
> >>> This went through 4 people and none noticed that there already
> >>> exists a means to set per-context parameters. And it's even used
> >>> right next to this function.
> >>>
> >>> The word hint needs to be firmly embedded around here.
> >>> -Chris
> >>> __
> >> Yep,
> >>
> >> Looks like you want to get involved in this discussion :
> >> https://patchwork.freedesktop.org/series/42285/
> > I understand this is exposing per context eu config through debugfs.
> > That mostly (if not fully) matches the  kernel part of what we wanted
> > to achieve. We have additional code in kernel where we categorize
> > based on load type and fix a config per platform. For sure the kernel
> > parts can be merged but the proposal is different here and its specific to
> adding this capability through mesa.
> >
> > Here we are enabling applications to decide load while creating the
> > context and making it simple for application programmers by
> > abstracting it.  Also in these kernel patches, its seems to be
> > exposing the parameters to user space, are we discussing its user
> > space counterpart in mesa or in some other component? If not, I feel
> > this is bit different. Can it be a mesa extension? Then any app / process 
> > can do
> this without having privilege (root).
> 
> Yes, I was just pointing out that you might want to reuse existing patches for
> i915 so that we don't end up with 2 similar interfaces there.
> Obviously your extension would still be needed.
> 

Thanks, that’s clear now. 

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

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


Re: [Mesa-dev] [PATCH 2/2] i965: Context aware user space EU control through application

2018-07-24 Thread Lionel Landwerlin

On 24/07/18 17:41, Marathe, Yogesh wrote:

Lionel, Chris,


-Original Message-
From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf
Of Lionel Landwerlin
Sent: Friday, July 20, 2018 3:31 PM
To: Chris Wilson ; Muthukumar, Aravindan
; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 2/2] i965: Context aware user space EU control
through application

On 20/07/18 09:47, Chris Wilson wrote:

Quoting aravindan.muthuku...@intel.com (2018-07-20 09:32:57)

From: "Muthukumar, Aravindan" 

   The Patch here is to give control to user/ application to really
   decide what's the max GPU load it would put. If that can be
   known in advance, rpcs can be programmed accordingly.
   This solution has changes across i915,
   drm and mesa (not limited only to kernel).

   Here, we pass gpu_load_type = {high, medium, low} from application
   while context is created. Default here is 'High' and applications
   roughly know if they are going to eat up entire GPU. The typical
   usecase of 'Low' is idle screen or minor mouse movements. Users can
   read meaning of high/medium/low for their platform  & then program
   contexts accordingly. Here gpu_load_type directly translates to
   number of shader cores/EUs a particular GPU has.

   Signed-off-by: Aravindan Muthukumar 
   Signed-off-by: Kedar J Karanje 
   Signed-off-by: Praveen Diwakar 
   Signed-off-by: Yogesh Marathe 
+/* Dynamic Eu control */
+struct drm_i915_load_type {
+   __u32 ctx_id;
+   __u32 load_type;
+};
+
+/* DYNAMIC EU CONTROL */
+int
+brw_hw_context_load_type(struct brw_bufmgr *bufmgr,
+uint32_t ctx_id,
+int load_type) {
+   struct drm_i915_load_type type = {
+   .ctx_id = ctx_id,
+   .load_type = load_type,
+   };
+   int err;
+
+   err = 0;
+   if(drmIoctl(bufmgr->fd, DRM_IOCTL_I915_LOAD_TYPE, ))
+   err = -errno;

This went through 4 people and none noticed that there already exists
a means to set per-context parameters. And it's even used right next
to this function.

The word hint needs to be firmly embedded around here.
-Chris
__

Yep,

Looks like you want to get involved in this discussion :
https://patchwork.freedesktop.org/series/42285/

I understand this is exposing per context eu config through debugfs. That mostly
(if not fully) matches the  kernel part of what we wanted to achieve. We have
additional code in kernel where we categorize based on load type and fix
a config per platform. For sure the kernel parts can be merged but the proposal
is different here and its specific to adding this capability through mesa.

Here we are enabling applications to decide load while creating the context and
making it simple for application programmers by abstracting it.  Also in these 
kernel
patches, its seems to be exposing the parameters to user space, are we 
discussing
its user space counterpart in mesa or in some other component? If not, I feel 
this
is bit different. Can it be a mesa extension? Then any app / process can do this
without having privilege (root).


Yes, I was just pointing out that you might want to reuse existing 
patches for i915 so that we don't end up with 2 similar interfaces there.

Obviously your extension would still be needed.

-
Lionel




-
Lionel
___
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] gallium/tests: Don't ignore S3TC errors.

2018-07-24 Thread Emil Velikov
On 24 July 2018 at 13:58, Jose Fonseca  wrote:
> Now we do full S3TC decompression they should no longer fail.
> ---
>  src/gallium/tests/unit/u_format_test.c | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/src/gallium/tests/unit/u_format_test.c 
> b/src/gallium/tests/unit/u_format_test.c
> index 6de581fd049..437cc94b757 100644
> --- a/src/gallium/tests/unit/u_format_test.c
> +++ b/src/gallium/tests/unit/u_format_test.c
> @@ -380,11 +380,6 @@ test_format_unpack_rgba_8unorm(const struct 
> util_format_description *format_desc
> if (util_is_double_nan(test->unpacked[0][0][0]))
>success = TRUE;
>
> -   /* Ignore S3TC errors */
> -   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
> -  success = TRUE;
> -   }
> -
We normally want this in stable as well. The following provide a rough
relation to the commit effectively enabling the built-in S3TC.
Feel free to add it

Fixes: 34cf3c43bee ("mesa: Call DXTn functions directly")

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


Re: [Mesa-dev] [PATCH] travis: manually generate sys/syscall.h

2018-07-24 Thread Eric Engestrom
On Tuesday, 2018-07-24 19:44:14 +0300, Andres Gomez wrote:
> On Tue, 2018-07-24 at 09:07 -0700, Dylan Baker wrote:
> > Quoting Emil Velikov (2018-07-24 08:56:55)
> > > On 24 July 2018 at 11:29, Eric Engestrom  wrote:
> > > > On Thursday, 2018-07-19 15:33:33 +0300, Andres Gomez wrote:
> > > > > Until now, the needed bits were wrongly included in linux/memfd.h
> > > > > 
> > > > > Since Travis' sys/syscall.h doesn't provide the SYS_memfd_create, we
> > > 
> > > The definition has moved across libc versions. Initially it was in
> > > memfd.h these days it's in bits/syscall.h
> > > 
> > > > Isn't this a matter of libc version? Isn't the right fix to upgrade the
> > > > libc in the container instead of faking its files?
> > > > 
> > > 
> > > Last time I've looked either a) updated package wasn't available or b)
> > > it required sudo true (no more container, bring the VM)
> > > 
> > > > And if the libc required is quite recent, what we need is a fallback in
> > > > the code to support older libc (possibly with some features missing),
> > > > which this build failure rightly reports.
> > > > 
> > > 
> > > Keep in mind that Travis uses Ubuntu Trusty, which isn't really a user
> > > of mesa-git and nearly EOL.
> > > Since this is a build testing only, I would stick with the "build
> > > everything" mindset and vote in favour of this workaround.
> > > 
> > > Please change the Fixes tag to 3228335b55c - the first user of
> > > syscall.h. With that
> > > Reviewed-by: Emil Velikov 
> > > 
> > > -Emil
> > 
> > I prefer this approach as well as a short term fix. Perhaps a better long 
> > term
> > solution would be to build our own docker image that contains a more 
> > realistic
> > set of minimum versions for building current mesa than a 4 year old LTS (we
> > could build off of 16.04 for example).
> 
> I was going to answer in a similar fashion. Emil and Dylan have been
> faster than me. Thanks, guys ☺ !
> 
> Yes, Trusty is quite old and to "properly" fix this we would have to
> check that the macro exists (basically, check the kernel version
> against which glibc was compiled, ugh!).
> 
> What I could suggest is that, for the Intel driver, which is the
> consumer of memfd_create, they may want to check for the existence of
> the SYS_memfd_create in a way or another in configure.ac and meson ...
> or better, add those bits to this series and land it (CCing Greg V):
> https://patchwork.freedesktop.org/series/35931/
> 
> Specifically:
> https://patchwork.freedesktop.org/patch/200450/
> 
> Additionally, yeah, I think we may have to check whether we want to
> upgrade Travis CI to use Xenial instead of Trusty.
> 
> In any case, I'll go ahead and push this as is (with the comment from
> Emil). We can still revisit afterwards.

I'm convinced :)
Acked-by: Eric Engestrom 

> 
> -- 
> Br,
> 
> Andres
> ___
> 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] travis: manually generate sys/syscall.h

2018-07-24 Thread Andres Gomez
On Tue, 2018-07-24 at 09:07 -0700, Dylan Baker wrote:
> Quoting Emil Velikov (2018-07-24 08:56:55)
> > On 24 July 2018 at 11:29, Eric Engestrom  wrote:
> > > On Thursday, 2018-07-19 15:33:33 +0300, Andres Gomez wrote:
> > > > Until now, the needed bits were wrongly included in linux/memfd.h
> > > > 
> > > > Since Travis' sys/syscall.h doesn't provide the SYS_memfd_create, we
> > 
> > The definition has moved across libc versions. Initially it was in
> > memfd.h these days it's in bits/syscall.h
> > 
> > > Isn't this a matter of libc version? Isn't the right fix to upgrade the
> > > libc in the container instead of faking its files?
> > > 
> > 
> > Last time I've looked either a) updated package wasn't available or b)
> > it required sudo true (no more container, bring the VM)
> > 
> > > And if the libc required is quite recent, what we need is a fallback in
> > > the code to support older libc (possibly with some features missing),
> > > which this build failure rightly reports.
> > > 
> > 
> > Keep in mind that Travis uses Ubuntu Trusty, which isn't really a user
> > of mesa-git and nearly EOL.
> > Since this is a build testing only, I would stick with the "build
> > everything" mindset and vote in favour of this workaround.
> > 
> > Please change the Fixes tag to 3228335b55c - the first user of
> > syscall.h. With that
> > Reviewed-by: Emil Velikov 
> > 
> > -Emil
> 
> I prefer this approach as well as a short term fix. Perhaps a better long term
> solution would be to build our own docker image that contains a more realistic
> set of minimum versions for building current mesa than a 4 year old LTS (we
> could build off of 16.04 for example).

I was going to answer in a similar fashion. Emil and Dylan have been
faster than me. Thanks, guys ☺ !

Yes, Trusty is quite old and to "properly" fix this we would have to
check that the macro exists (basically, check the kernel version
against which glibc was compiled, ugh!).

What I could suggest is that, for the Intel driver, which is the
consumer of memfd_create, they may want to check for the existence of
the SYS_memfd_create in a way or another in configure.ac and meson ...
or better, add those bits to this series and land it (CCing Greg V):
https://patchwork.freedesktop.org/series/35931/

Specifically:
https://patchwork.freedesktop.org/patch/200450/

Additionally, yeah, I think we may have to check whether we want to
upgrade Travis CI to use Xenial instead of Trusty.

In any case, I'll go ahead and push this as is (with the comment from
Emil). We can still revisit afterwards.

-- 
Br,

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


Re: [Mesa-dev] [PATCH v2 10/26] python: Use explicit integer divisions

2018-07-24 Thread Eric Engestrom
On Wednesday, 2018-07-11 19:52:31 +0200, Mathieu Bridon wrote:
> In Python 2, divisions return an integer:
> 
> >>> 32 / 4
> 8
> 
> In Python 3 though, they return floats:
> 
> >>> 32 / 4
> 8.0
> 
> However, Python 3 has an explicit integer division operator:
> 
> >>> 32 // 4
> 8
> 
> That operator exists on Python >= 2.2, so let's use it everywhere to
> make the scripts compatible with both Python 2 and 3.
> 
> In addition, using __future__.division tells Python 2 to behave the same
> way as Python 3, which helps ensure the scripts produce the same output
> in both versions of Python.
> 
> Signed-off-by: Mathieu Bridon 

Reviewed-by: Eric Engestrom 

> ---
>  src/gallium/auxiliary/util/u_format_pack.py  | 4 ++--
>  src/gallium/auxiliary/util/u_format_parse.py | 7 +--
>  src/mapi/glapi/gen/glX_proto_send.py | 4 ++--
>  src/mesa/main/format_info.py | 4 ++--
>  src/mesa/main/format_pack.py | 8 
>  src/mesa/main/format_unpack.py   | 8 
>  6 files changed, 19 insertions(+), 16 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/util/u_format_pack.py 
> b/src/gallium/auxiliary/util/u_format_pack.py
> index 7a952a48b3..ad2e49281f 100644
> --- a/src/gallium/auxiliary/util/u_format_pack.py
> +++ b/src/gallium/auxiliary/util/u_format_pack.py
> @@ -36,7 +36,7 @@
>  '''
>  
>  
> -from __future__ import print_function
> +from __future__ import division, print_function
>  
>  from u_format_parse import *
>  
> @@ -240,7 +240,7 @@ def value_to_native(type, value):
>  return truncate_mantissa(value, 23)
>  return value
>  if type.type == FIXED:
> -return int(value * (1 << (type.size/2)))
> +return int(value * (1 << (type.size // 2)))
>  if not type.norm:
>  return int(value)
>  if type.type == UNSIGNED:
> diff --git a/src/gallium/auxiliary/util/u_format_parse.py 
> b/src/gallium/auxiliary/util/u_format_parse.py
> index c0456f6d15..d3874cd895 100644
> --- a/src/gallium/auxiliary/util/u_format_parse.py
> +++ b/src/gallium/auxiliary/util/u_format_parse.py
> @@ -29,6 +29,9 @@
>  '''
>  
>  
> +from __future__ import division
> +
> +
>  VOID, UNSIGNED, SIGNED, FIXED, FLOAT = range(5)
>  
>  SWIZZLE_X, SWIZZLE_Y, SWIZZLE_Z, SWIZZLE_W, SWIZZLE_0, SWIZZLE_1, 
> SWIZZLE_NONE, = range(7)
> @@ -76,7 +79,7 @@ class Channel:
>  if self.type == FLOAT:
>  return VERY_LARGE
>  if self.type == FIXED:
> -return (1 << (self.size/2)) - 1
> +return (1 << (self.size // 2)) - 1
>  if self.norm:
>  return 1
>  if self.type == UNSIGNED:
> @@ -90,7 +93,7 @@ class Channel:
>  if self.type == FLOAT:
>  return -VERY_LARGE
>  if self.type == FIXED:
> -return -(1 << (self.size/2))
> +return -(1 << (self.size // 2))
>  if self.type == UNSIGNED:
>  return 0
>  if self.norm:
> diff --git a/src/mapi/glapi/gen/glX_proto_send.py 
> b/src/mapi/glapi/gen/glX_proto_send.py
> index a920ecc012..03067d8a3c 100644
> --- a/src/mapi/glapi/gen/glX_proto_send.py
> +++ b/src/mapi/glapi/gen/glX_proto_send.py
> @@ -26,7 +26,7 @@
>  #Ian Romanick 
>  #Jeremy Kolb 
>  
> -from __future__ import print_function
> +from __future__ import division, print_function
>  
>  import argparse
>  
> @@ -809,7 +809,7 @@ generic_%u_byte( GLint rop, const void * ptr )
>  # Dividing by the array size (1 for
>  # non-arrays) gives us this.
>  
> -s = p.size() / p.get_element_count()
> +s = p.size() // p.get_element_count()
>  print("   %s __glXReadReply(dpy, %s, %s, %s);" % 
> (return_str, s, p.name, aa))
>  got_reply = 1
>  
> diff --git a/src/mesa/main/format_info.py b/src/mesa/main/format_info.py
> index bbecaa2451..00e27b3fba 100644
> --- a/src/mesa/main/format_info.py
> +++ b/src/mesa/main/format_info.py
> @@ -21,7 +21,7 @@
>  # TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
>  # SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
>  
> -from __future__ import print_function
> +from __future__ import division, print_function
>  
>  import format_parser as parser
>  import sys
> @@ -198,7 +198,7 @@ for fmat in formats:
>chan = fmat.array_element()
>norm = chan.norm or chan.type == parser.FLOAT
>print('  .ArrayFormat = MESA_ARRAY_FORMAT({0}),'.format(', '.join([
> - str(chan.size / 8),
> + str(chan.size // 8),
>   str(int(chan.sign)),
>   str(int(chan.type == parser.FLOAT)),
>   str(int(norm)),
> diff --git a/src/mesa/main/format_pack.py b/src/mesa/main/format_pack.py
> index d3c8d24acd..05262efb5b 100644
> --- a/src/mesa/main/format_pack.py
> +++ b/src/mesa/main/format_pack.py
> @@ -1,4 +1,4 @@
> -from __future__ import print_function
> +from __future__ 

Re: [Mesa-dev] [PATCH 2/2] i965: Context aware user space EU control through application

2018-07-24 Thread Marathe, Yogesh
Lionel, Chris,

> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf
> Of Lionel Landwerlin
> Sent: Friday, July 20, 2018 3:31 PM
> To: Chris Wilson ; Muthukumar, Aravindan
> ; mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH 2/2] i965: Context aware user space EU control
> through application
> 
> On 20/07/18 09:47, Chris Wilson wrote:
> > Quoting aravindan.muthuku...@intel.com (2018-07-20 09:32:57)
> >> From: "Muthukumar, Aravindan" 
> >>
> >>   The Patch here is to give control to user/ application to really
> >>   decide what's the max GPU load it would put. If that can be
> >>   known in advance, rpcs can be programmed accordingly.
> >>   This solution has changes across i915,
> >>   drm and mesa (not limited only to kernel).
> >>
> >>   Here, we pass gpu_load_type = {high, medium, low} from application
> >>   while context is created. Default here is 'High' and applications
> >>   roughly know if they are going to eat up entire GPU. The typical
> >>   usecase of 'Low' is idle screen or minor mouse movements. Users can
> >>   read meaning of high/medium/low for their platform  & then program
> >>   contexts accordingly. Here gpu_load_type directly translates to
> >>   number of shader cores/EUs a particular GPU has.
> >>
> >>   Signed-off-by: Aravindan Muthukumar 
> >>   Signed-off-by: Kedar J Karanje 
> >>   Signed-off-by: Praveen Diwakar 
> >>   Signed-off-by: Yogesh Marathe 
> >> +/* Dynamic Eu control */
> >> +struct drm_i915_load_type {
> >> +   __u32 ctx_id;
> >> +   __u32 load_type;
> >> +};
> >> +
> >> +/* DYNAMIC EU CONTROL */
> >> +int
> >> +brw_hw_context_load_type(struct brw_bufmgr *bufmgr,
> >> +uint32_t ctx_id,
> >> +int load_type) {
> >> +   struct drm_i915_load_type type = {
> >> +   .ctx_id = ctx_id,
> >> +   .load_type = load_type,
> >> +   };
> >> +   int err;
> >> +
> >> +   err = 0;
> >> +   if(drmIoctl(bufmgr->fd, DRM_IOCTL_I915_LOAD_TYPE, ))
> >> +   err = -errno;
> > This went through 4 people and none noticed that there already exists
> > a means to set per-context parameters. And it's even used right next
> > to this function.
> >
> > The word hint needs to be firmly embedded around here.
> > -Chris
> > __
> 
> Yep,
> 
> Looks like you want to get involved in this discussion :
> https://patchwork.freedesktop.org/series/42285/

I understand this is exposing per context eu config through debugfs. That mostly
(if not fully) matches the  kernel part of what we wanted to achieve. We have 
additional code in kernel where we categorize based on load type and fix 
a config per platform. For sure the kernel parts can be merged but the proposal 
is different here and its specific to adding this capability through mesa.

Here we are enabling applications to decide load while creating the context and 
making it simple for application programmers by abstracting it.  Also in these 
kernel 
patches, its seems to be exposing the parameters to user space, are we 
discussing 
its user space counterpart in mesa or in some other component? If not, I feel 
this
is bit different. Can it be a mesa extension? Then any app / process can do this
without having privilege (root).

> 
> -
> Lionel
> ___
> 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] travis: manually generate sys/syscall.h

2018-07-24 Thread Emil Velikov
On 24 July 2018 at 17:07, Dylan Baker  wrote:
> Quoting Emil Velikov (2018-07-24 08:56:55)
>> On 24 July 2018 at 11:29, Eric Engestrom  wrote:
>> > On Thursday, 2018-07-19 15:33:33 +0300, Andres Gomez wrote:
>> >> Until now, the needed bits were wrongly included in linux/memfd.h
>> >>
>> >> Since Travis' sys/syscall.h doesn't provide the SYS_memfd_create, we
>> The definition has moved across libc versions. Initially it was in
>> memfd.h these days it's in bits/syscall.h
>>
>> > Isn't this a matter of libc version? Isn't the right fix to upgrade the
>> > libc in the container instead of faking its files?
>> >
>> Last time I've looked either a) updated package wasn't available or b)
>> it required sudo true (no more container, bring the VM)
>>
>> > And if the libc required is quite recent, what we need is a fallback in
>> > the code to support older libc (possibly with some features missing),
>> > which this build failure rightly reports.
>> >
>> Keep in mind that Travis uses Ubuntu Trusty, which isn't really a user
>> of mesa-git and nearly EOL.
>> Since this is a build testing only, I would stick with the "build
>> everything" mindset and vote in favour of this workaround.
>>
>> Please change the Fixes tag to 3228335b55c - the first user of
>> syscall.h. With that
>> Reviewed-by: Emil Velikov 
>>
>> -Emil
>
> I prefer this approach as well as a short term fix. Perhaps a better long term
> solution would be to build our own docker image that contains a more realistic
> set of minimum versions for building current mesa than a 4 year old LTS (we
> could build off of 16.04 for example).
>
Maintaining a docker image requires a bit more time, so I'd suggest
stick with this for now.

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


Re: [Mesa-dev] [PATCH v3] vulkan: Fix compilation on older platforms

2018-07-24 Thread Emil Velikov
Hi Danylo,

Having a closer look inspired by Eric's comments

On 24 July 2018 at 15:37, Danylo Piliaiev  wrote:
>>> Check for DRM_EVENT_CONTEXT_VERSION >= 4 to use sequence_handler.
>>>
As you bump the libdrm version:
 - drop the existing DRM_EVENT_CONTEXT_VERSION guard
 - swap the DRM_EVENT_CONTEXT_VERSION macro with the actual version implemented

>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107170
>>>https://bugs.freedesktop.org/show_bug.cgi?id=106972
>>>https://bugs.freedesktop.org/show_bug.cgi?id=107176
>>>
Separate bugs it seems - hence separate patches?


>>>
>>> +LIBDRM_CRT_SEQUENCE_REQUIRED=2.4.89
>>> +
>>
>> There is no need for yet another version - just bump LIBDRM_REQUIRED.
>
> Bumping LIBDRM_REQUIRED would mean that older platforms won't be supported.
> I don't know how the decisions about support of older platforms are made but
> from my point of view bumping required libdrm version due to one vulkan
> extension
> may be overkill.
>
If we consider this as the only merit, then the number of
checks/version would practically explore.
Simply take each user libGL, libEGL, gbm, other multiply that with the
number of features we use.

Looking at Eero's bug (last one in the list) - he's using Ubuntu 16.04
which has 2.4.91 in xenial-updates


>> Why do we need the new define? From a quick look we should be above to
>> reuse VK_USE_PLATFORM_DISPLAY_KHR, we simply need the ifdef guards.
>
> If we will not bump global libdrm version requirement new define is
> necessary because
> rest of the code guarded by VK_USE_PLATFORM_DISPLAY_KHR works fine with
> older libdrm versions.
>
And by addressing that, this can go - one diverging codepath less ;-)

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


Re: [Mesa-dev] [PATCH v2] egl: Fix missing clamping in eglSetDamageRegionKHR

2018-07-24 Thread Dylan Baker
Quoting Eric Engestrom (2018-07-24 07:55:03)
> On Tuesday, 2018-07-24 18:15:54 +0530, Harish Krupo wrote:
> > Hi Eric,
> > 
> > Eric Engestrom  writes:
> > 
> > > On Sunday, 2018-07-08 12:53:00 +0530, Harish Krupo wrote:
> > >> Clamp the x and y co-ordinates of the rectangles.
> > >> 
> > >> v2: Clamp width/height after converting to co-ordinates
> > >> (Ilia Merkin)
> > >> 
> > >> Signed-off-by: Harish Krupo 
> > >> ---
> > >>  src/egl/main/eglapi.c | 25 +++--
> > >>  1 file changed, 11 insertions(+), 14 deletions(-)
> > >> 
> > >> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> > >> index c110349119..deb479b6d5 100644
> > >> --- a/src/egl/main/eglapi.c
> > >> +++ b/src/egl/main/eglapi.c
> > >> @@ -1320,9 +1320,7 @@ eglSwapBuffersWithDamageKHR(EGLDisplay dpy, 
> > >> EGLSurface surface,
> > >>  }
> > >>  
> > >>  /**
> > >> - * If the width of the passed rect is greater than the surface's
> > >> - * width then it is clamped to the width of the surface. Same with
> > >> - * height.
> > >> + * Clamp the rectangles so that they lie within the surface.
> > >>   */
> > >>  
> > >>  static void
> > >> @@ -1334,17 +1332,16 @@ _eglSetDamageRegionKHRClampRects(_EGLDisplay* 
> > >> disp, _EGLSurface* surf,
> > >> EGLint surf_width = surf->Width;
> > >>  
> > >> for (i = 0; i < (4 * n_rects); i += 4) {
> > >> -  EGLint x, y, rect_width, rect_height;
> > >> -  x = rects[i];
> > >> -  y = rects[i + 1];
> > >> -  rect_width = rects[i + 2];
> > >> -  rect_height = rects[i + 3];
> > >> -
> > >> -  if (rect_width > surf_width - x)
> > >> - rects[i + 2] = surf_width - x;
> > >> -
> > >> -  if (rect_height > surf_height - y)
> > >> - rects[i + 3] = surf_height - y;
> > >> +  EGLint x1, y1, x2, y2;
> > >> +  x1 = rects[i];
> > >> +  y1 = rects[i + 1];
> > >> +  x2 = rects[i + 2] + x1;
> > >> +  y2 = rects[i + 3] + y1;
> > >> +
> > >> +  rects[i] = CLAMP(x1, 0, surf_width);
> > >> +  rects[i + 1] = CLAMP(y1, 0, surf_height);
> > >> +  rects[i + 2] = CLAMP(x2, 0, surf_width) - rects[i];
> > >> +  rects[i + 3] = CLAMP(y2, 0, surf_height) - rects[i + 1];
> > >
> > > This looks correct to me:
> > > Reviewed-by: Eric Engestrom 
> > >
> > > I ran it through our CI as well, looks all good, no regression;
> > > would you like one of us to push it for you?
> > >
> > 
> > Thanks and yes please :)
> 
> Done; pushed as fd734608c3c40a1a93c6 with everyone's r-b.
> 
> I also just realised (after pushing, as usual) that I forgot to add:
> Fixes: 9827547313c7239486efb "egl/android: support for EGL_KHR_partial_update"
> 
> I'm therefore nominating it for stable branches by cc'ing mesa-stable@
> (and Dylan and Andres, release managers of 18.1 and 18.2).

Pulled into staging/18.1, Thanks for CC'ing me directly, that's much easier than
cc'ing stable :)

Dylan


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


Re: [Mesa-dev] [Mesa-stable] [PATCH] intel/compiler: Account for built-in uniforms in analyze_ubo_ranges

2018-07-24 Thread Dylan Baker
Quoting Jason Ekstrand (2018-07-23 10:46:31)
> The original pass only looked for load_uniform intrinsics but there are
> a number of other places that could end up loading a push constant.  One
> obvious omission was images which always implicitly use a push constant.
> Legacy VS clip planes also get pushed into the shader.
> 
> Cc: mesa-sta...@lists.freedesktop.org
> Cc: Kenneth Graunke 
> ---
>  src/intel/compiler/brw_nir.h  |  1 +
>  .../compiler/brw_nir_analyze_ubo_ranges.c | 41 +--
>  src/intel/vulkan/anv_pipeline.c   |  2 +-
>  src/mesa/drivers/dri/i965/brw_gs.c|  2 +-
>  src/mesa/drivers/dri/i965/brw_tcs.c   |  2 +-
>  src/mesa/drivers/dri/i965/brw_tes.c   |  2 +-
>  src/mesa/drivers/dri/i965/brw_vs.c|  2 +-
>  src/mesa/drivers/dri/i965/brw_wm.c|  2 +-
>  8 files changed, 45 insertions(+), 9 deletions(-)
> 
> diff --git a/src/intel/compiler/brw_nir.h b/src/intel/compiler/brw_nir.h
> index 19442b47eae..7d82edafe46 100644
> --- a/src/intel/compiler/brw_nir.h
> +++ b/src/intel/compiler/brw_nir.h
> @@ -148,6 +148,7 @@ void 
> brw_nir_lower_patch_vertices_in_to_uniform(nir_shader *nir);
>  
>  void brw_nir_analyze_ubo_ranges(const struct brw_compiler *compiler,
>  nir_shader *nir,
> +const struct brw_vs_prog_key *vs_key,
>  struct brw_ubo_range out_ranges[4]);
>  
>  bool brw_nir_opt_peephole_ffma(nir_shader *shader);
> diff --git a/src/intel/compiler/brw_nir_analyze_ubo_ranges.c 
> b/src/intel/compiler/brw_nir_analyze_ubo_ranges.c
> index cd5137da06e..cfa531675fc 100644
> --- a/src/intel/compiler/brw_nir_analyze_ubo_ranges.c
> +++ b/src/intel/compiler/brw_nir_analyze_ubo_ranges.c
> @@ -124,12 +124,29 @@ analyze_ubos_block(struct ubo_analysis_state *state, 
> nir_block *block)
>   continue;
>  
>nir_intrinsic_instr *intrin = nir_instr_as_intrinsic(instr);
> -  if (intrin->intrinsic == nir_intrinsic_load_uniform)
> +  switch (intrin->intrinsic) {
> +  case nir_intrinsic_load_uniform:
> +  case nir_intrinsic_image_deref_load:
> +  case nir_intrinsic_image_deref_store:
> +  case nir_intrinsic_image_deref_atomic_add:
> +  case nir_intrinsic_image_deref_atomic_min:
> +  case nir_intrinsic_image_deref_atomic_max:
> +  case nir_intrinsic_image_deref_atomic_and:
> +  case nir_intrinsic_image_deref_atomic_or:
> +  case nir_intrinsic_image_deref_atomic_xor:
> +  case nir_intrinsic_image_deref_atomic_exchange:
> +  case nir_intrinsic_image_deref_atomic_comp_swap:
> +  case nir_intrinsic_image_deref_size:
>   state->uses_regular_uniforms = true;
> -
> -  if (intrin->intrinsic != nir_intrinsic_load_ubo)
>   continue;
>  
> +  case nir_intrinsic_load_ubo:
> + break; /* Fall through to the analysis below */
> +
> +  default:
> + continue; /* Not a uniform or UBO intrinsic */
> +  }
> +
>nir_const_value *block_const = nir_src_as_const_value(intrin->src[0]);
>nir_const_value *offset_const = nir_src_as_const_value(intrin->src[1]);
>  
> @@ -179,6 +196,7 @@ print_ubo_entry(FILE *file,
>  void
>  brw_nir_analyze_ubo_ranges(const struct brw_compiler *compiler,
> nir_shader *nir,
> +   const struct brw_vs_prog_key *vs_key,
> struct brw_ubo_range out_ranges[4])
>  {
> const struct gen_device_info *devinfo = compiler->devinfo;
> @@ -197,6 +215,23 @@ brw_nir_analyze_ubo_ranges(const struct brw_compiler 
> *compiler,
>   _mesa_hash_table_create(mem_ctx, NULL, _mesa_key_pointer_equal),
> };
>  
> +   switch (nir->info.stage) {
> +   case MESA_SHADER_VERTEX:
> +  if (vs_key && vs_key->nr_userclip_plane_consts > 0)
> + state.uses_regular_uniforms = true;
> +  break;
> +
> +   case MESA_SHADER_COMPUTE:
> +  /* Compute shaders use push constants to get the subgroup ID so it's
> +   * best to just assume some system values are pushed.
> +   */
> +  state.uses_regular_uniforms = true;
> +  break;
> +
> +   default:
> +  break;
> +   }
> +
> /* Walk the IR, recording how many times each UBO block/offset is used. */
> nir_foreach_function(function, nir) {
>if (function->impl) {
> diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
> index 211cee788b8..1e6bd12b87d 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -472,7 +472,7 @@ anv_pipeline_compile(struct anv_pipeline *pipeline,
>anv_nir_apply_pipeline_layout(pipeline, layout, nir, prog_data, map);
>  
> if (stage != MESA_SHADER_COMPUTE)
> -  brw_nir_analyze_ubo_ranges(compiler, nir, prog_data->ubo_ranges);
> +  brw_nir_analyze_ubo_ranges(compiler, nir, NULL, prog_data->ubo_ranges);
>  
> assert(nir->num_uniforms == 

[Mesa-dev] [Bug 107170] Build fails if building against X server/libxrandr with no leases support

2018-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107170

--- Comment #2 from Emil Velikov  ---
Note that the xcb_randr API is not provided by libXrandr but xcb-randr ;-)
A simple version check of the latter should fix things.

-- 
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] travis: manually generate sys/syscall.h

2018-07-24 Thread Emil Velikov
On 24 July 2018 at 11:29, Eric Engestrom  wrote:
> On Thursday, 2018-07-19 15:33:33 +0300, Andres Gomez wrote:
>> Until now, the needed bits were wrongly included in linux/memfd.h
>>
>> Since Travis' sys/syscall.h doesn't provide the SYS_memfd_create, we
The definition has moved across libc versions. Initially it was in
memfd.h these days it's in bits/syscall.h

> Isn't this a matter of libc version? Isn't the right fix to upgrade the
> libc in the container instead of faking its files?
>
Last time I've looked either a) updated package wasn't available or b)
it required sudo true (no more container, bring the VM)

> And if the libc required is quite recent, what we need is a fallback in
> the code to support older libc (possibly with some features missing),
> which this build failure rightly reports.
>
Keep in mind that Travis uses Ubuntu Trusty, which isn't really a user
of mesa-git and nearly EOL.
Since this is a build testing only, I would stick with the "build
everything" mindset and vote in favour of this workaround.

Please change the Fixes tag to 3228335b55c - the first user of
syscall.h. With that
Reviewed-by: Emil Velikov 

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


Re: [Mesa-dev] [PATCH v3] vulkan: Fix compilation on older platforms

2018-07-24 Thread Eric Engestrom
On Friday, 2018-07-13 16:57:34 +0300, Danylo Piliaiev wrote:
> Make xlease automatically enabled only if xcb-randr >= 1.13,
> check its version if manually enabled.
> 
> Enable VK_EXT_display_control only when libdrm >= 2.4.89
> 
> Check for DRM_EVENT_CONTEXT_VERSION >= 4 to use sequence_handler.

You're changing 3 unrelated things here; please send 3 patches :)

> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107170
>   https://bugs.freedesktop.org/show_bug.cgi?id=106972
>   https://bugs.freedesktop.org/show_bug.cgi?id=107176
> 
> v2: - Add 'protect="VK_USE_DISPLAY_CONTROL"' attribute to
>VK_EXT_display_control in vk.xml
> - Add support for 'protect' attribute to anv_entrypoints_gen
>(copied from radv_entrypoints_gen)
> - Turn #if into #ifdef
> - Remove unnecessary pkg-config call from meson build (Dylan Baker)
> 
> v3: by Dylan Baker
> - Remove previously added changes to vk.xml and entrypoints
>generation because vk.xml is meant to be pulled from the external
>source.
> 
> Signed-off-by: Danylo Piliaiev 
> ---
>  configure.ac   | 29 +-
>  meson.build| 10 -
>  src/amd/vulkan/radv_extensions.py  |  9 +++-
>  src/amd/vulkan/radv_wsi_display.c  |  5 ++---
>  src/intel/vulkan/anv_extensions.py |  2 +-
>  src/intel/vulkan/anv_extensions_gen.py |  7 +++
>  src/intel/vulkan/anv_wsi_display.c |  4 ++--
>  src/vulkan/wsi/wsi_common_display.c|  8 +--
>  src/vulkan/wsi/wsi_common_display.h|  3 ++-
>  9 files changed, 51 insertions(+), 26 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index f135d05736..0b04525014 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -82,6 +82,8 @@ LIBDRM_FREEDRENO_REQUIRED=2.4.92
>  LIBDRM_ETNAVIV_REQUIRED=2.4.89
>  LIBDRM_VC4_REQUIRED=2.4.89
>  
> +LIBDRM_CRT_SEQUENCE_REQUIRED=2.4.89

I agree with everyone else here: just bump the libdrm version required
for vulkan :)

libdrm is absolutely trivial to update; any system that can update its
mesa can also update its libdrm.

> +
>  dnl Versions for external dependencies
>  DRI2PROTO_REQUIRED=2.8
>  GLPROTO_REQUIRED=1.4.14
> @@ -97,6 +99,7 @@ XCBDRI2_REQUIRED=1.8
>  XCBDRI3_MODIFIERS_REQUIRED=1.13
>  XCBGLX_REQUIRED=1.8.1
>  XCBPRESENT_MODIFIERS_REQUIRED=1.13
> +XCBRANDR_XLEASE_REQUIRED=1.13
>  XDAMAGE_REQUIRED=1.1
>  XSHMFENCE_REQUIRED=1.1
>  XVMC_REQUIRED=1.0.6
> @@ -1874,20 +1877,6 @@ if test x"$enable_dri3" = xyes; then
>  fi
>  fi
>  
> -
> -if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 'drm'; 
> then
> -have_xlease=yes
> -else
> -have_xlease=no
> -fi
> -
> -if test x"$have_xlease" = xyes; then
> -randr_modules="x11-xcb xcb-randr"
> -PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules])
> -xlib_randr_modules="xrandr"
> -PKG_CHECK_MODULES([XLIB_RANDR], [$xlib_randr_modules])
> -fi
> -
>  AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
>  AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
>  AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
> @@ -1905,14 +1894,24 @@ xno)
>  ;;
>  *)
>  if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 
> 'drm'; then
> -enable_xlib_lease=yes
> +xlease_modules="x11-xcb xcb-randr >= $XCBRANDR_XLEASE_REQUIRED 
> xrandr"
> +PKG_CHECK_EXISTS([$xlease_modules], [enable_xlib_lease=yes], 
> [enable_xlib_lease=no])
>  else
>  enable_xlib_lease=no
>  fi
>  esac
>  
> +if test x"$enable_xlib_lease" = xyes; then
> +randr_modules="x11-xcb xcb-randr >= $XCBRANDR_XLEASE_REQUIRED"
> +PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules])
> +xlib_randr_modules="xrandr"
> +PKG_CHECK_MODULES([XLIB_RANDR], [$xlib_randr_modules])
> +fi
> +
>  AM_CONDITIONAL(HAVE_XLIB_LEASE, test "x$enable_xlib_lease" = xyes)
>  
> +PKG_CHECK_EXISTS([libdrm >= $LIBDRM_CRT_SEQUENCE_REQUIRED], 
> [DEFINES="${DEFINES} -DVK_USE_DISPLAY_CONTROL"], [])
> +
>  dnl
>  dnl More DRI setup
>  dnl
> diff --git a/meson.build b/meson.build
> index 7d12af3d51..902074819c 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1088,6 +1088,8 @@ _drm_freedreno_ver = '2.4.92'
>  _drm_intel_ver = '2.4.75'
>  _drm_ver = '2.4.75'
>  
> +_drm_crt_sequence_ver = '2.4.89'
> +
>  _libdrm_checks = [
>['intel', with_dri_i915 or with_gallium_i915],
>['amdgpu', with_amd_vk or with_gallium_radeonsi],
> @@ -1361,11 +1363,17 @@ if with_platform_x11
>  dep_xcb_xfixes = dependency('xcb-xfixes')
>endif
>if with_xlib_lease
> -dep_xcb_xrandr = dependency('xcb-randr', version : '>= 1.12')
> +dep_xcb_xrandr = dependency('xcb-randr', version : '>= 1.13')
>  dep_xlib_xrandr = dependency('xrandr', version : '>= 1.3')
>endif
>  endif
>  
> +if with_any_vk
> +  if dep_libdrm.version().version_compare('>= ' + _drm_crt_sequence_ver)
> +pre_args += 

Re: [Mesa-dev] [PATCH] docs: move releases from Fridays to Wednesdays

2018-07-24 Thread Emil Velikov
On 19 July 2018 at 14:00, Andres Gomez  wrote:
> As discussed at:
> https://lists.freedesktop.org/archives/mesa-dev/2018-March/188525.html
>
> Cc: Emil Velikov 
> Cc: Juan A. Suarez Romero 
> Cc: Dylan Baker 
> Cc: Ian Romanick 
> Cc: Carl Worth 
> Cc: Mark Janes 
> Signed-off-by: Andres Gomez 

Acked-by: Emil Velikov 

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


Re: [Mesa-dev] [PATCH] docs: update calendar to match the 18.2 plan with the one announced

2018-07-24 Thread Emil Velikov
On 19 July 2018 at 14:03, Andres Gomez  wrote:
> Additionally, I've extended the 18.1 cycle by one more release,
> tentatively assigned to Dylan, due to the ~2 weeks delay for 18.2.
>
> Cc: Dylan Baker 
> Cc: Juan A. Suarez 
> Cc: Emil Velikov 
> Signed-off-by: Andres Gomez 

Acked-by: Emil Velikov 

Thanks for keeping things in sync.
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa: Fix copy-paste error in ConservativeRasterDilateRange initialization

2018-07-24 Thread Emil Velikov
On 22 July 2018 at 18:27, Rhys Perry  wrote:
> Reviewed-by: Rhys Perry 
>
> I'm not sure how much that's worth though, so I think I'll wait a few
> days being pushing it (I assume you can't push it) and see if anyone
> objects.
>
Please add the following as you do:

Fixes: 4580617509d ("mesa: add support for nvidia conservative
rasterization extensions")
Reviewed-by: Emil Velikov 

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


Re: [Mesa-dev] [PATCH] docs: correct typo in the submitting patches instructions

2018-07-24 Thread Emil Velikov
On 19 July 2018 at 14:02, Andres Gomez  wrote:
> Cc: Emil Velikov 
> Cc: Eric Engestrom 
> Signed-off-by: Andres Gomez 
> ---
>  docs/submittingpatches.html | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html
> index 178ec5f89ec..e5350bdb2cf 100644
> --- a/docs/submittingpatches.html
> +++ b/docs/submittingpatches.html
> @@ -36,7 +36,7 @@
>  perhaps, in very trivial cases.)
>  Code patches should follow Mesa
>  coding conventions.
> -Whenever possible, patches should only effect individual Mesa/Gallium
> +Whenever possible, patches should only affect individual Mesa/Gallium
I had to do a double-take to spot it. Thanks

Reviewed-by: Emil Velikov 

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


Re: [Mesa-dev] [PATCH] swrast: remove unneeded _glapi_check_multithread() call

2018-07-24 Thread Emil Velikov
On 18 July 2018 at 19:34, Eric Anholt  wrote:
> Emil Velikov  writes:
>
>> From: Emil Velikov 
>>
>> With commit c6c0f947142, back in 2006 Brian removed the
>> _glapi_check_multithread() call from core mesa - _mesa_make_current.
>>
>> He moved it to a DRI loader (type of) decision - with equivalents in
>> the monolithic OSMesa and libGL-Xlib.
>>
>> Some time afterwords, swrast (a DRI driver) was introduced as a copy
>> paste of the latter two. Remove the call since the DRI loader handles
>> that for us.
>>
>> Signed-off-by: Emil Velikov 
>
> Does anything make sure it gets called for classic drivers under EGL?
>
Good call - I cannot spot anything. Which means that all classic
drivers, but swrast is foobar'd.
Gallium itself calls _glapi_check_multithread so those drivers are safe.

> Actually, wouldn't it make sense to move this back to the core, at this
> point?
Since glapi is fiddly, I've opted for the least invasive patch. Moving
the call to core would be better, indeed.

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


Re: [Mesa-dev] [PATCH v2] egl: Fix missing clamping in eglSetDamageRegionKHR

2018-07-24 Thread Eric Engestrom
On Tuesday, 2018-07-24 18:15:54 +0530, Harish Krupo wrote:
> Hi Eric,
> 
> Eric Engestrom  writes:
> 
> > On Sunday, 2018-07-08 12:53:00 +0530, Harish Krupo wrote:
> >> Clamp the x and y co-ordinates of the rectangles.
> >> 
> >> v2: Clamp width/height after converting to co-ordinates
> >> (Ilia Merkin)
> >> 
> >> Signed-off-by: Harish Krupo 
> >> ---
> >>  src/egl/main/eglapi.c | 25 +++--
> >>  1 file changed, 11 insertions(+), 14 deletions(-)
> >> 
> >> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> >> index c110349119..deb479b6d5 100644
> >> --- a/src/egl/main/eglapi.c
> >> +++ b/src/egl/main/eglapi.c
> >> @@ -1320,9 +1320,7 @@ eglSwapBuffersWithDamageKHR(EGLDisplay dpy, 
> >> EGLSurface surface,
> >>  }
> >>  
> >>  /**
> >> - * If the width of the passed rect is greater than the surface's
> >> - * width then it is clamped to the width of the surface. Same with
> >> - * height.
> >> + * Clamp the rectangles so that they lie within the surface.
> >>   */
> >>  
> >>  static void
> >> @@ -1334,17 +1332,16 @@ _eglSetDamageRegionKHRClampRects(_EGLDisplay* 
> >> disp, _EGLSurface* surf,
> >> EGLint surf_width = surf->Width;
> >>  
> >> for (i = 0; i < (4 * n_rects); i += 4) {
> >> -  EGLint x, y, rect_width, rect_height;
> >> -  x = rects[i];
> >> -  y = rects[i + 1];
> >> -  rect_width = rects[i + 2];
> >> -  rect_height = rects[i + 3];
> >> -
> >> -  if (rect_width > surf_width - x)
> >> - rects[i + 2] = surf_width - x;
> >> -
> >> -  if (rect_height > surf_height - y)
> >> - rects[i + 3] = surf_height - y;
> >> +  EGLint x1, y1, x2, y2;
> >> +  x1 = rects[i];
> >> +  y1 = rects[i + 1];
> >> +  x2 = rects[i + 2] + x1;
> >> +  y2 = rects[i + 3] + y1;
> >> +
> >> +  rects[i] = CLAMP(x1, 0, surf_width);
> >> +  rects[i + 1] = CLAMP(y1, 0, surf_height);
> >> +  rects[i + 2] = CLAMP(x2, 0, surf_width) - rects[i];
> >> +  rects[i + 3] = CLAMP(y2, 0, surf_height) - rects[i + 1];
> >
> > This looks correct to me:
> > Reviewed-by: Eric Engestrom 
> >
> > I ran it through our CI as well, looks all good, no regression;
> > would you like one of us to push it for you?
> >
> 
> Thanks and yes please :)

Done; pushed as fd734608c3c40a1a93c6 with everyone's r-b.

I also just realised (after pushing, as usual) that I forgot to add:
Fixes: 9827547313c7239486efb "egl/android: support for EGL_KHR_partial_update"

I'm therefore nominating it for stable branches by cc'ing mesa-stable@
(and Dylan and Andres, release managers of 18.1 and 18.2).

> 
> Thank you
> Regards
> Harish Krupo
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 1/4] softpipe: Add assert verifying successful pipe_transfer_map

2018-07-24 Thread Emil Velikov
On 17 July 2018 at 11:32, Robert Foss  wrote:
> This failure mode is a bit tricky to debug and manifests itself
> later as a null pointer dereference, for which finding the origin
> is needlessly tricky.
>
> Signed-off-by: Robert Foss 
Reviewed-by: Emil Velikov 

Ever so mildly related: Android-x86 were the first ones hacking away
the auth check in core DRM.
Was not expecting that Mauro would try anything w/o it.

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


Re: [Mesa-dev] [PATCH v3] vulkan: Fix compilation on older platforms

2018-07-24 Thread Danylo Piliaiev

Hi Emil,

On 24.07.18 17:10, Emil Velikov wrote:

Hi Danylo,

On 13 July 2018 at 14:57, Danylo Piliaiev  wrote:

Make xlease automatically enabled only if xcb-randr >= 1.13,
check its version if manually enabled.

Enable VK_EXT_display_control only when libdrm >= 2.4.89

Check for DRM_EVENT_CONTEXT_VERSION >= 4 to use sequence_handler.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107170
   https://bugs.freedesktop.org/show_bug.cgi?id=106972
   https://bugs.freedesktop.org/show_bug.cgi?id=107176

v2: - Add 'protect="VK_USE_DISPLAY_CONTROL"' attribute to
VK_EXT_display_control in vk.xml
 - Add support for 'protect' attribute to anv_entrypoints_gen
(copied from radv_entrypoints_gen)
 - Turn #if into #ifdef
 - Remove unnecessary pkg-config call from meson build (Dylan Baker)

v3: by Dylan Baker
 - Remove previously added changes to vk.xml and entrypoints
generation because vk.xml is meant to be pulled from the external
source.

Signed-off-by: Danylo Piliaiev 
---
  configure.ac   | 29 +-
  meson.build| 10 -
  src/amd/vulkan/radv_extensions.py  |  9 +++-
  src/amd/vulkan/radv_wsi_display.c  |  5 ++---
  src/intel/vulkan/anv_extensions.py |  2 +-
  src/intel/vulkan/anv_extensions_gen.py |  7 +++
  src/intel/vulkan/anv_wsi_display.c |  4 ++--
  src/vulkan/wsi/wsi_common_display.c|  8 +--
  src/vulkan/wsi/wsi_common_display.h|  3 ++-
  9 files changed, 51 insertions(+), 26 deletions(-)

diff --git a/configure.ac b/configure.ac
index f135d05736..0b04525014 100644
--- a/configure.ac
+++ b/configure.ac
@@ -82,6 +82,8 @@ LIBDRM_FREEDRENO_REQUIRED=2.4.92
  LIBDRM_ETNAVIV_REQUIRED=2.4.89
  LIBDRM_VC4_REQUIRED=2.4.89

+LIBDRM_CRT_SEQUENCE_REQUIRED=2.4.89
+

There is no need for yet another version - just bump LIBDRM_REQUIRED.

Bumping LIBDRM_REQUIRED would mean that older platforms won't be supported.
I don't know how the decisions about support of older platforms are made 
but
from my point of view bumping required libdrm version due to one vulkan 
extension

may be overkill.

  dnl Versions for external dependencies
  DRI2PROTO_REQUIRED=2.8
  GLPROTO_REQUIRED=1.4.14
@@ -97,6 +99,7 @@ XCBDRI2_REQUIRED=1.8
  XCBDRI3_MODIFIERS_REQUIRED=1.13
  XCBGLX_REQUIRED=1.8.1
  XCBPRESENT_MODIFIERS_REQUIRED=1.13
+XCBRANDR_XLEASE_REQUIRED=1.13

Thinking out loud: I wonder if we cannot use a single variable for all
the xcb 1.13 bits.


  XDAMAGE_REQUIRED=1.1
  XSHMFENCE_REQUIRED=1.1
  XVMC_REQUIRED=1.0.6
@@ -1874,20 +1877,6 @@ if test x"$enable_dri3" = xyes; then
  fi
  fi

-
-if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 'drm'; then
-have_xlease=yes
-else
-have_xlease=no
-fi
-
-if test x"$have_xlease" = xyes; then
-randr_modules="x11-xcb xcb-randr"
-PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules])
-xlib_randr_modules="xrandr"
-PKG_CHECK_MODULES([XLIB_RANDR], [$xlib_randr_modules])
-fi
-
  AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
  AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
  AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
@@ -1905,14 +1894,24 @@ xno)
  ;;
  *)
  if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 
'drm'; then
-enable_xlib_lease=yes
+xlease_modules="x11-xcb xcb-randr >= $XCBRANDR_XLEASE_REQUIRED xrandr"
+PKG_CHECK_EXISTS([$xlease_modules], [enable_xlib_lease=yes], 
[enable_xlib_lease=no])
  else
  enable_xlib_lease=no
  fi
  esac

+if test x"$enable_xlib_lease" = xyes; then
+randr_modules="x11-xcb xcb-randr >= $XCBRANDR_XLEASE_REQUIRED"
+PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules])
+xlib_randr_modules="xrandr"
+PKG_CHECK_MODULES([XLIB_RANDR], [$xlib_randr_modules])
+fi
+
  AM_CONDITIONAL(HAVE_XLIB_LEASE, test "x$enable_xlib_lease" = xyes)

+PKG_CHECK_EXISTS([libdrm >= $LIBDRM_CRT_SEQUENCE_REQUIRED], [DEFINES="${DEFINES} 
-DVK_USE_DISPLAY_CONTROL"], [])
+

Why do we need the new define? From a quick look we should be above to
reuse VK_USE_PLATFORM_DISPLAY_KHR, we simply need the ifdef guards.
If we will not bump global libdrm version requirement new define is 
necessary because
rest of the code guarded by VK_USE_PLATFORM_DISPLAY_KHR works fine with 
older libdrm versions.

The comments are more or less also applicable for meson.

HTH
Emil


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


Re: [Mesa-dev] [PATCH v3] vulkan: Fix compilation on older platforms

2018-07-24 Thread Emil Velikov
Hi Danylo,

On 13 July 2018 at 14:57, Danylo Piliaiev  wrote:
> Make xlease automatically enabled only if xcb-randr >= 1.13,
> check its version if manually enabled.
>
> Enable VK_EXT_display_control only when libdrm >= 2.4.89
>
> Check for DRM_EVENT_CONTEXT_VERSION >= 4 to use sequence_handler.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107170
>   https://bugs.freedesktop.org/show_bug.cgi?id=106972
>   https://bugs.freedesktop.org/show_bug.cgi?id=107176
>
> v2: - Add 'protect="VK_USE_DISPLAY_CONTROL"' attribute to
>VK_EXT_display_control in vk.xml
> - Add support for 'protect' attribute to anv_entrypoints_gen
>(copied from radv_entrypoints_gen)
> - Turn #if into #ifdef
> - Remove unnecessary pkg-config call from meson build (Dylan Baker)
>
> v3: by Dylan Baker
> - Remove previously added changes to vk.xml and entrypoints
>generation because vk.xml is meant to be pulled from the external
>source.
>
> Signed-off-by: Danylo Piliaiev 
> ---
>  configure.ac   | 29 +-
>  meson.build| 10 -
>  src/amd/vulkan/radv_extensions.py  |  9 +++-
>  src/amd/vulkan/radv_wsi_display.c  |  5 ++---
>  src/intel/vulkan/anv_extensions.py |  2 +-
>  src/intel/vulkan/anv_extensions_gen.py |  7 +++
>  src/intel/vulkan/anv_wsi_display.c |  4 ++--
>  src/vulkan/wsi/wsi_common_display.c|  8 +--
>  src/vulkan/wsi/wsi_common_display.h|  3 ++-
>  9 files changed, 51 insertions(+), 26 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index f135d05736..0b04525014 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -82,6 +82,8 @@ LIBDRM_FREEDRENO_REQUIRED=2.4.92
>  LIBDRM_ETNAVIV_REQUIRED=2.4.89
>  LIBDRM_VC4_REQUIRED=2.4.89
>
> +LIBDRM_CRT_SEQUENCE_REQUIRED=2.4.89
> +
There is no need for yet another version - just bump LIBDRM_REQUIRED.

>  dnl Versions for external dependencies
>  DRI2PROTO_REQUIRED=2.8
>  GLPROTO_REQUIRED=1.4.14
> @@ -97,6 +99,7 @@ XCBDRI2_REQUIRED=1.8
>  XCBDRI3_MODIFIERS_REQUIRED=1.13
>  XCBGLX_REQUIRED=1.8.1
>  XCBPRESENT_MODIFIERS_REQUIRED=1.13
> +XCBRANDR_XLEASE_REQUIRED=1.13
Thinking out loud: I wonder if we cannot use a single variable for all
the xcb 1.13 bits.

>  XDAMAGE_REQUIRED=1.1
>  XSHMFENCE_REQUIRED=1.1
>  XVMC_REQUIRED=1.0.6
> @@ -1874,20 +1877,6 @@ if test x"$enable_dri3" = xyes; then
>  fi
>  fi
>
> -
> -if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 'drm'; 
> then
> -have_xlease=yes
> -else
> -have_xlease=no
> -fi
> -
> -if test x"$have_xlease" = xyes; then
> -randr_modules="x11-xcb xcb-randr"
> -PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules])
> -xlib_randr_modules="xrandr"
> -PKG_CHECK_MODULES([XLIB_RANDR], [$xlib_randr_modules])
> -fi
> -
>  AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
>  AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
>  AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
> @@ -1905,14 +1894,24 @@ xno)
>  ;;
>  *)
>  if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 
> 'drm'; then
> -enable_xlib_lease=yes
> +xlease_modules="x11-xcb xcb-randr >= $XCBRANDR_XLEASE_REQUIRED 
> xrandr"
> +PKG_CHECK_EXISTS([$xlease_modules], [enable_xlib_lease=yes], 
> [enable_xlib_lease=no])
>  else
>  enable_xlib_lease=no
>  fi
>  esac
>
> +if test x"$enable_xlib_lease" = xyes; then
> +randr_modules="x11-xcb xcb-randr >= $XCBRANDR_XLEASE_REQUIRED"
> +PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules])
> +xlib_randr_modules="xrandr"
> +PKG_CHECK_MODULES([XLIB_RANDR], [$xlib_randr_modules])
> +fi
> +
>  AM_CONDITIONAL(HAVE_XLIB_LEASE, test "x$enable_xlib_lease" = xyes)
>
> +PKG_CHECK_EXISTS([libdrm >= $LIBDRM_CRT_SEQUENCE_REQUIRED], 
> [DEFINES="${DEFINES} -DVK_USE_DISPLAY_CONTROL"], [])
> +
Why do we need the new define? From a quick look we should be above to
reuse VK_USE_PLATFORM_DISPLAY_KHR, we simply need the ifdef guards.

The comments are more or less also applicable for meson.

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


Re: [Mesa-dev] [PATCH] gallium/tests: Don't ignore S3TC errors.

2018-07-24 Thread Roland Scheidegger
Am 24.07.2018 um 14:58 schrieb Jose Fonseca:
> Now we do full S3TC decompression they should no longer fail.
> ---
>  src/gallium/tests/unit/u_format_test.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/src/gallium/tests/unit/u_format_test.c 
> b/src/gallium/tests/unit/u_format_test.c
> index 6de581fd049..437cc94b757 100644
> --- a/src/gallium/tests/unit/u_format_test.c
> +++ b/src/gallium/tests/unit/u_format_test.c
> @@ -380,11 +380,6 @@ test_format_unpack_rgba_8unorm(const struct 
> util_format_description *format_desc
> if (util_is_double_nan(test->unpacked[0][0][0]))
>success = TRUE;
>  
> -   /* Ignore S3TC errors */
> -   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
> -  success = TRUE;
> -   }
> -
> if (!success) {
>print_unpacked_rgba_8unorm(format_desc, "FAILED: ", unpacked, " 
> obtained\n");
>print_unpacked_rgba_8unorm(format_desc, "", expected, " 
> expected\n");
> 

Looks good to me.
Reviewed-by: Roland Scheidegger 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v3] nir/linker: Add the start of a pure-NIR linker for XFB

2018-07-24 Thread Alejandro Piñeiro
From: Neil Roberts 

v2: ignore names on purpose, for consistency with other places where
we are doing the same (Alejandro)

v3: changes proposed by Timothy Arceri, implemented by Alejandro Piñeiro:
   * Remove redundant 'struct active_xfb_varying'
   * Update several comments, including spec quotes if needed
   * Rename struct 'active_xfb_varying_array' to 'active_xfb_varyings'
   * Rename variable 'array' to 'active_varyings'
   * Replace one if condition for an assert (
Signed-off-by: Alejandro Piñeiro 
---
 src/compiler/Makefile.sources   |   1 +
 src/compiler/glsl/gl_nir_link_xfb.c | 317 
 src/compiler/glsl/gl_nir_linker.h   |   3 +
 src/compiler/glsl/meson.build   |   1 +
 4 files changed, 322 insertions(+)
 create mode 100644 src/compiler/glsl/gl_nir_link_xfb.c

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index db4dd1e89f4..fe9f607d2b1 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -31,6 +31,7 @@ LIBGLSL_FILES = \
glsl/gl_nir_link_atomics.c \
glsl/gl_nir_link_uniform_initializers.c \
glsl/gl_nir_link_uniforms.c \
+   glsl/gl_nir_link_xfb.c \
glsl/gl_nir_linker.c \
glsl/gl_nir_linker.h \
glsl/gl_nir.h \
diff --git a/src/compiler/glsl/gl_nir_link_xfb.c 
b/src/compiler/glsl/gl_nir_link_xfb.c
new file mode 100644
index 000..4703ac43400
--- /dev/null
+++ b/src/compiler/glsl/gl_nir_link_xfb.c
@@ -0,0 +1,317 @@
+/*
+ * 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 "nir.h"
+#include "gl_nir_linker.h"
+#include "ir_uniform.h" /* for gl_uniform_storage */
+#include "linker_util.h"
+#include "main/context.h"
+
+/*
+ * This file does the linking of GLSL transform feedback using NIR.
+ *
+ * Note: This linking pass is currently tailored for ARB_gl_spirv needs and
+ * particularities.
+ */
+
+struct active_xfb_buffer {
+   GLuint stride;
+   GLuint num_varyings;
+};
+
+struct active_xfb_varyings {
+   unsigned num_varyings;
+   unsigned num_outputs;
+   unsigned buffer_size;
+   struct nir_variable **varyings;
+   struct active_xfb_buffer buffers[MAX_FEEDBACK_BUFFERS];
+};
+
+static unsigned
+get_num_outputs(nir_variable *var)
+{
+   return glsl_count_attribute_slots(var->type,
+ false /* is_vertex_input */);
+}
+
+static void
+add_xfb_varying(struct active_xfb_varyings *active_varyings,
+nir_variable *var)
+{
+   if (active_varyings->num_varyings >= active_varyings->buffer_size) {
+  if (active_varyings->buffer_size == 0)
+ active_varyings->buffer_size = 1;
+  else
+ active_varyings->buffer_size *= 2;
+
+  active_varyings->varyings = realloc(active_varyings->varyings,
+  sizeof(nir_variable*) *
+  active_varyings->buffer_size);
+   }
+
+   active_varyings->varyings[active_varyings->num_varyings++] = var;
+
+   active_varyings->num_outputs += get_num_outputs(var);
+}
+
+static int
+cmp_xfb_offset(const void *x_generic, const void *y_generic)
+{
+   const nir_variable *const *x = x_generic;
+   const nir_variable *const *y = y_generic;
+
+   if ((*x)->data.xfb_buffer != (*y)->data.xfb_buffer)
+  return (*x)->data.xfb_buffer - (*y)->data.xfb_buffer;
+   return (*x)->data.offset - (*y)->data.offset;
+}
+
+static void
+get_active_xfb_varyings(struct gl_shader_program *prog,
+struct active_xfb_varyings *active_varyings)
+{
+   for (unsigned i = 0; i < MESA_SHADER_STAGES; ++i) {
+  struct gl_linked_shader *sh = prog->_LinkedShaders[i];
+  if (sh == NULL)
+ continue;
+
+  nir_shader *nir = sh->Program->nir;
+
+  nir_foreach_variable(var, >outputs) {
+ if (var->data.explicit_xfb_buffer &&
+ 

[Mesa-dev] [PATCH v2] nir/gather_info: Set info.gs.uses_streams

2018-07-24 Thread Alejandro Piñeiro
From: Neil Roberts 

Whenever a non-zero stream is written to it now sets uses_streams to
true. This reflects the code in validate_geometry_shader_emissions for
GLSL.

v2: set uses_streams at gather_info instead that at spirv to nir
(Jason Ekstrand)
---
 src/compiler/nir/nir_gather_info.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/compiler/nir/nir_gather_info.c 
b/src/compiler/nir/nir_gather_info.c
index 2b431e343e9..d0b656ea741 100644
--- a/src/compiler/nir/nir_gather_info.c
+++ b/src/compiler/nir/nir_gather_info.c
@@ -288,6 +288,11 @@ gather_intrinsic_info(nir_intrinsic_instr *instr, 
nir_shader *shader,
case nir_intrinsic_end_primitive_with_counter:
   assert(shader->info.stage == MESA_SHADER_GEOMETRY);
   shader->info.gs.uses_end_primitive = 1;
+
+   case nir_intrinsic_emit_vertex:
+  if (nir_intrinsic_stream_id(instr) > 0)
+ shader->info.gs.uses_streams = true;
+
   break;
 
default:
-- 
2.14.1

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


Re: [Mesa-dev] ANDROID: eglCreateImageKHR missing modifiers

2018-07-24 Thread Martin Fuzzey

Hi Thomasz,

thanks for your reply

On 21/07/18 04:27, Tomasz Figa wrote:


As you noticed, this adds back the dependency on gralloc handle
structure. Moreover, it actually adds a dependency on the handle
having a binary format compatible with gralloc_gbm_handle_t. This is
not something that we can do in upstream Mesa, since there are more
platforms running gralloc implementations other than gbm_gralloc.


Looking at it a bit more is it really that bad?

The compile time dependency is on gralloc_handle.h which is actually 
part of libdrm not a specific gralloc implementation.

Does mesa need to compile with old versions of libdrm?
0r is the structure going to be removed from libdrm?

As you say there is also the runtime dependency on the binary format of 
the handle structure *but* checking the magic will ensure that if we run 
with a different implementation of gralloc which doesn't have the same 
magic we will gracefully fall back to not supporting modifiers, just as 
we would with a new optional gralloc perform call.
We should probably also check the numFds, numInts field in the 
native_handle_t header to ensure that we can safely access the magic 
field to protect against any other gralloc implementations having a tiny 
handle format.





--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -43,6 +43,8 @@
   #include "gralloc_drm.h"
   #endif /* HAVE_DRM_GRALLOC */

+#include 
+
   #define ALIGN(val, align)  (((val) + (align) - 1) & ~((align) - 1))

   struct droid_yuv_format {
@@ -801,6 +803,9 @@ droid_create_image_from_prime_fd(_EGLDisplay *disp,
_EGLContext *ctx,
struct ANativeWindowBuffer *buf, int fd)
   {
  unsigned int pitch;
+   struct gralloc_gbm_handle_t *grh;
+   uint64_t modifier = 0;
+   bool have_modifier = false;

  if (is_yuv(buf->format)) {
 _EGLImage *image;
@@ -829,17 +834,34 @@ droid_create_image_from_prime_fd(_EGLDisplay
*disp, _EGLContext *ctx,
 return NULL;
  }

-   const EGLint attr_list[] = {
+   grh = (struct gralloc_gbm_handle_t *)buf->handle;
+   if (grh->magic == GRALLOC_HANDLE_MAGIC) {
+  modifier = grh->modifier;
+  have_modifier = true;
+   }
+
+   EGLint attr_list[] = {
 EGL_WIDTH, buf->width,
 EGL_HEIGHT, buf->height,
 EGL_LINUX_DRM_FOURCC_EXT, fourcc,
 EGL_DMA_BUF_PLANE0_FD_EXT, fd,
 EGL_DMA_BUF_PLANE0_PITCH_EXT, pitch,
 EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
+  EGL_DMA_BUF_PLANE0_MODIFIER_LO_EXT, modifier & 0x,
+  EGL_DMA_BUF_PLANE0_MODIFIER_HI_EXT, modifier >> 32,
 EGL_NONE, 0
  };

-   return dri2_create_image_dma_buf(disp, ctx, NULL, attr_list);
+   if (!have_modifier) {
+  for (int i=0; i < ARRAY_SIZE(attr_list); i+=2) {
+ if (attr_list[i] == EGL_DMA_BUF_PLANE0_MODIFIER_LO_EXT) {
+attr_list[i] = EGL_NONE;
+break;
+ }
+  }
+   }
+
+   return dri2_create_image_dma_buf(disp, ctx, NULL, (const EGLint
*)attr_list);
   }

What is the preferred way of fixing this?

Unfortunately, I don't have a very good solution for this. In Chrome
OS we just don't support modifiers in EGL/GLES on Android. Obviously
it would be a good idea to have some way to query gralloc for the
modifier, but I don't see Android providing any generic way to do it.

The least evil I can think of as a makeshift for now could be an
optional gralloc0 perform call that returns the modifier for given
buffer.


An advantage of a new perform call would be that other gralloc 
implementations could be extended to support it without changing their 
handle structure but is that really likely?


Regards,

Martin

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


Re: [Mesa-dev] [PATCH v2] intel/ppgtt: memory address alignment

2018-07-24 Thread Chris Wilson
Quoting Lionel Landwerlin (2018-07-24 13:45:18)
> On 24/07/18 13:42, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-07-24 13:34:57)
> >> That looks correct to me (and we do the same in Anv).
> >> Also a bit baffled that we haven't run into issues earlier :(
> > All the allocations should be in multiples of page size, alignment less
> > than a page size should be a no-op. Tracking down who doesn't think
> > IS_ALIGNED(bo->size, PAGE_SIZE) would be interesting.
> > -Chris
> >
> Buckets?

The bucket size is still a multiple of PAGE_SIZE, and gtt_offsets within
a bucket are computed as an offset from the base of the bucket (i.e.
vma_alloc() is only called once for the entire bucket, and it acts as a
cache to reduce the number of vma operations.)
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] radv: Still enable inmemory & API level caching if disk cache is not enabled.

2018-07-24 Thread Bas Nieuwenhuizen
That we don't have a background disk cache does not mean we should
prevent the app caching anything.

CC: 
---
 src/amd/vulkan/radv_pipeline_cache.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_pipeline_cache.c 
b/src/amd/vulkan/radv_pipeline_cache.c
index 6858d37eba8..7e2c305b1a0 100644
--- a/src/amd/vulkan/radv_pipeline_cache.c
+++ b/src/amd/vulkan/radv_pipeline_cache.c
@@ -248,7 +248,6 @@ radv_is_cache_disabled(struct radv_device *device)
 * MESA_GLSL_CACHE_DISABLE=1, and when VK_AMD_shader_info is requested.
 */
return (device->instance->debug_flags & RADV_DEBUG_NO_CACHE) ||
-  !device->physical_device->disk_cache ||
   device->keep_shader_info;
 }
 
@@ -271,7 +270,7 @@ radv_create_shader_variants_from_pipeline_cache(struct 
radv_device *device,
/* Don't cache when we want debug info, since this isn't
 * present in the cache.
 */
-   if (radv_is_cache_disabled(device)) {
+   if (radv_is_cache_disabled(device) || 
!device->physical_device->disk_cache) {
pthread_mutex_unlock(>mutex);
return false;
}
-- 
2.18.0

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


[Mesa-dev] [PATCH] freedreno: a2xx: ir2 update

2018-07-24 Thread Jonathan Marek
this patch brings a number of changes to ir2:
-ir2 now generates CF clauses as necessary during assembly. this simplifies
 fd2_program/fd2_compiler and is necessary to implement optimization passes
-ir2 now has separate vector/scalar instructions. this will make it easier
 to implementing scheduling of scalar+vector instructions together. dst_reg
 is also now seperate from src registers instead of a single list
-ir2 now implements register allocation. this makes it possible to compile
 shaders which have more than 64 TGSI registers
-ir2 now implements the following optimizations: removal of IN/OUT MOV
 instructions generated by TGSI and removal of unused instructions when
 some exports are disabled
-ir2 now allows full 8-bit index for constants
-ir2_alloc no longer allocates 4 times too many bytes

Signed-off-by: Jonathan Marek 
---
 .../drivers/freedreno/a2xx/fd2_compiler.c | 210 ++---
 .../drivers/freedreno/a2xx/fd2_program.c  |  75 +-
 .../drivers/freedreno/a2xx/instr-a2xx.h   |  28 +-
 src/gallium/drivers/freedreno/a2xx/ir-a2xx.c  | 734 +++---
 src/gallium/drivers/freedreno/a2xx/ir-a2xx.h  | 113 +--
 5 files changed, 615 insertions(+), 545 deletions(-)

diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_compiler.c 
b/src/gallium/drivers/freedreno/a2xx/fd2_compiler.c
index 3ad47f9850..12f9a1ce0a 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_compiler.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_compiler.c
@@ -93,9 +93,6 @@ struct fd2_compile_context {
unsigned position, psize;
 
uint64_t need_sync;
-
-   /* current exec CF instruction */
-   struct ir2_cf *cf;
 };
 
 static int
@@ -130,7 +127,6 @@ compile_init(struct fd2_compile_context *ctx, struct 
fd_program_stateobj *prog,
 
ctx->prog = prog;
ctx->so = so;
-   ctx->cf = NULL;
ctx->pred_depth = 0;
 
ret = tgsi_parse_init(>parser, so->tokens);
@@ -236,15 +232,6 @@ compile_free(struct fd2_compile_context *ctx)
tgsi_parse_free(>parser);
 }
 
-static struct ir2_cf *
-next_exec_cf(struct fd2_compile_context *ctx)
-{
-   struct ir2_cf *cf = ctx->cf;
-   if (!cf || cf->exec.instrs_count >= ARRAY_SIZE(ctx->cf->exec.instrs))
-   ctx->cf = cf = ir2_cf_create(ctx->so->ir, EXEC);
-   return cf;
-}
-
 static void
 compile_vtx_fetch(struct fd2_compile_context *ctx)
 {
@@ -252,13 +239,13 @@ compile_vtx_fetch(struct fd2_compile_context *ctx)
int i;
for (i = 0; i < ctx->num_regs[TGSI_FILE_INPUT]; i++) {
struct ir2_instruction *instr = ir2_instr_create(
-   next_exec_cf(ctx), IR2_FETCH);
+   ctx->so->ir, IR2_FETCH);
instr->fetch.opc = VTX_FETCH;
 
ctx->need_sync |= 1 << (i+1);
 
-   ir2_reg_create(instr, i+1, "xyzw", 0);
-   ir2_reg_create(instr, 0, "x", 0);
+   ir2_dst_create(instr, i+1, "xyzw", 0);
+   ir2_reg_create(instr, 0, "x", IR2_REG_INPUT);
 
if (i == 0)
instr->sync = true;
@@ -266,7 +253,6 @@ compile_vtx_fetch(struct fd2_compile_context *ctx)
vfetch_instrs[i] = instr;
}
ctx->so->num_vfetch_instrs = i;
-   ctx->cf = NULL;
 }
 
 /*
@@ -312,7 +298,7 @@ get_temp_gpr(struct fd2_compile_context *ctx, int idx)
return num;
 }
 
-static struct ir2_register *
+static struct ir2_dst_register *
 add_dst_reg(struct fd2_compile_context *ctx, struct ir2_instruction *alu,
const struct tgsi_dst_register *dst)
 {
@@ -351,10 +337,10 @@ add_dst_reg(struct fd2_compile_context *ctx, struct 
ir2_instruction *alu,
swiz[3] = (dst->WriteMask & TGSI_WRITEMASK_W) ? 'w' : '_';
swiz[4] = '\0';
 
-   return ir2_reg_create(alu, num, swiz, flags);
+   return ir2_dst_create(alu, num, swiz, flags);
 }
 
-static struct ir2_register *
+static struct ir2_src_register *
 add_src_reg(struct fd2_compile_context *ctx, struct ir2_instruction *alu,
const struct tgsi_src_register *src)
 {
@@ -373,6 +359,7 @@ add_src_reg(struct fd2_compile_context *ctx, struct 
ir2_instruction *alu,
if (ctx->type == PIPE_SHADER_VERTEX) {
num = src->Index + 1;
} else {
+   flags |= IR2_REG_INPUT;
num = export_linkage(ctx,
ctx->input_export_idx[src->Index]);
}
@@ -415,7 +402,7 @@ static void
 add_vector_clamp(struct tgsi_full_instruction *inst, struct ir2_instruction 
*alu)
 {
if (inst->Instruction.Saturate) {
-   alu->alu.vector_clamp = true;
+   alu->alu_vector.clamp = true;
}
 }
 
@@ -423,7 +410,7 @@ static void
 add_scalar_clamp(struct tgsi_full_instruction *inst, struct ir2_instruction 
*alu)
 {
if (inst->Instruction.Saturate) {
-   alu->alu.scalar_clamp = true;
+   

[Mesa-dev] [PATCH] gallium/tests: Don't ignore S3TC errors.

2018-07-24 Thread Jose Fonseca
Now we do full S3TC decompression they should no longer fail.
---
 src/gallium/tests/unit/u_format_test.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/src/gallium/tests/unit/u_format_test.c 
b/src/gallium/tests/unit/u_format_test.c
index 6de581fd049..437cc94b757 100644
--- a/src/gallium/tests/unit/u_format_test.c
+++ b/src/gallium/tests/unit/u_format_test.c
@@ -380,11 +380,6 @@ test_format_unpack_rgba_8unorm(const struct 
util_format_description *format_desc
if (util_is_double_nan(test->unpacked[0][0][0]))
   success = TRUE;
 
-   /* Ignore S3TC errors */
-   if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
-  success = TRUE;
-   }
-
if (!success) {
   print_unpacked_rgba_8unorm(format_desc, "FAILED: ", unpacked, " 
obtained\n");
   print_unpacked_rgba_8unorm(format_desc, "", expected, " 
expected\n");
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH v2] egl: Fix missing clamping in eglSetDamageRegionKHR

2018-07-24 Thread Harish Krupo
Hi Eric,

Eric Engestrom  writes:

> On Sunday, 2018-07-08 12:53:00 +0530, Harish Krupo wrote:
>> Clamp the x and y co-ordinates of the rectangles.
>> 
>> v2: Clamp width/height after converting to co-ordinates
>> (Ilia Merkin)
>> 
>> Signed-off-by: Harish Krupo 
>> ---
>>  src/egl/main/eglapi.c | 25 +++--
>>  1 file changed, 11 insertions(+), 14 deletions(-)
>> 
>> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
>> index c110349119..deb479b6d5 100644
>> --- a/src/egl/main/eglapi.c
>> +++ b/src/egl/main/eglapi.c
>> @@ -1320,9 +1320,7 @@ eglSwapBuffersWithDamageKHR(EGLDisplay dpy, EGLSurface 
>> surface,
>>  }
>>  
>>  /**
>> - * If the width of the passed rect is greater than the surface's
>> - * width then it is clamped to the width of the surface. Same with
>> - * height.
>> + * Clamp the rectangles so that they lie within the surface.
>>   */
>>  
>>  static void
>> @@ -1334,17 +1332,16 @@ _eglSetDamageRegionKHRClampRects(_EGLDisplay* disp, 
>> _EGLSurface* surf,
>> EGLint surf_width = surf->Width;
>>  
>> for (i = 0; i < (4 * n_rects); i += 4) {
>> -  EGLint x, y, rect_width, rect_height;
>> -  x = rects[i];
>> -  y = rects[i + 1];
>> -  rect_width = rects[i + 2];
>> -  rect_height = rects[i + 3];
>> -
>> -  if (rect_width > surf_width - x)
>> - rects[i + 2] = surf_width - x;
>> -
>> -  if (rect_height > surf_height - y)
>> - rects[i + 3] = surf_height - y;
>> +  EGLint x1, y1, x2, y2;
>> +  x1 = rects[i];
>> +  y1 = rects[i + 1];
>> +  x2 = rects[i + 2] + x1;
>> +  y2 = rects[i + 3] + y1;
>> +
>> +  rects[i] = CLAMP(x1, 0, surf_width);
>> +  rects[i + 1] = CLAMP(y1, 0, surf_height);
>> +  rects[i + 2] = CLAMP(x2, 0, surf_width) - rects[i];
>> +  rects[i + 3] = CLAMP(y2, 0, surf_height) - rects[i + 1];
>
> This looks correct to me:
> Reviewed-by: Eric Engestrom 
>
> I ran it through our CI as well, looks all good, no regression;
> would you like one of us to push it for you?
>

Thanks and yes please :)

Thank you
Regards
Harish Krupo
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] egl: Fix missing clamping in eglSetDamageRegionKHR

2018-07-24 Thread Eric Engestrom
On Sunday, 2018-07-08 12:53:00 +0530, Harish Krupo wrote:
> Clamp the x and y co-ordinates of the rectangles.
> 
> v2: Clamp width/height after converting to co-ordinates
> (Ilia Merkin)
> 
> Signed-off-by: Harish Krupo 
> ---
>  src/egl/main/eglapi.c | 25 +++--
>  1 file changed, 11 insertions(+), 14 deletions(-)
> 
> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> index c110349119..deb479b6d5 100644
> --- a/src/egl/main/eglapi.c
> +++ b/src/egl/main/eglapi.c
> @@ -1320,9 +1320,7 @@ eglSwapBuffersWithDamageKHR(EGLDisplay dpy, EGLSurface 
> surface,
>  }
>  
>  /**
> - * If the width of the passed rect is greater than the surface's
> - * width then it is clamped to the width of the surface. Same with
> - * height.
> + * Clamp the rectangles so that they lie within the surface.
>   */
>  
>  static void
> @@ -1334,17 +1332,16 @@ _eglSetDamageRegionKHRClampRects(_EGLDisplay* disp, 
> _EGLSurface* surf,
> EGLint surf_width = surf->Width;
>  
> for (i = 0; i < (4 * n_rects); i += 4) {
> -  EGLint x, y, rect_width, rect_height;
> -  x = rects[i];
> -  y = rects[i + 1];
> -  rect_width = rects[i + 2];
> -  rect_height = rects[i + 3];
> -
> -  if (rect_width > surf_width - x)
> - rects[i + 2] = surf_width - x;
> -
> -  if (rect_height > surf_height - y)
> - rects[i + 3] = surf_height - y;
> +  EGLint x1, y1, x2, y2;
> +  x1 = rects[i];
> +  y1 = rects[i + 1];
> +  x2 = rects[i + 2] + x1;
> +  y2 = rects[i + 3] + y1;
> +
> +  rects[i] = CLAMP(x1, 0, surf_width);
> +  rects[i + 1] = CLAMP(y1, 0, surf_height);
> +  rects[i + 2] = CLAMP(x2, 0, surf_width) - rects[i];
> +  rects[i + 3] = CLAMP(y2, 0, surf_height) - rects[i + 1];

This looks correct to me:
Reviewed-by: Eric Engestrom 

I ran it through our CI as well, looks all good, no regression;
would you like one of us to push it for you?

> }
>  }
>  
> -- 
> 2.18.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] intel/ppgtt: memory address alignment

2018-07-24 Thread Lionel Landwerlin

On 24/07/18 13:42, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-07-24 13:34:57)

That looks correct to me (and we do the same in Anv).
Also a bit baffled that we haven't run into issues earlier :(

All the allocations should be in multiples of page size, alignment less
than a page size should be a no-op. Tracking down who doesn't think
IS_ALIGNED(bo->size, PAGE_SIZE) would be interesting.
-Chris


Buckets?

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


Re: [Mesa-dev] [PATCH v2] intel/ppgtt: memory address alignment

2018-07-24 Thread Chris Wilson
Quoting Lionel Landwerlin (2018-07-24 13:34:57)
> That looks correct to me (and we do the same in Anv).
> Also a bit baffled that we haven't run into issues earlier :(

All the allocations should be in multiples of page size, alignment less
than a page size should be a no-op. Tracking down who doesn't think
IS_ALIGNED(bo->size, PAGE_SIZE) would be interesting.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] intel/ppgtt: memory address alignment

2018-07-24 Thread Lionel Landwerlin

That looks correct to me (and we do the same in Anv).
Also a bit baffled that we haven't run into issues earlier :(

But would be good to have Ken's Rb too.

Thanks a lot!

Reviewed-by: Lionel Landwerlin 

On 24/07/18 12:50, Sergii Romantsov wrote:

Kernel (for ppgtt) requires memory address to be
aligned to page size (4096).
Added such alignment for buffers marked with EXEC_OBJECT_PINNED.

-v2: added marking that also fixes initial commit 01058a552294

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106997
Fixes: a363bb2cd0e2 (i965: Allocate VMA in userspace for full-PPGTT systems.)
Fixes: 01058a552294 (i965: Add virtual memory allocator infrastructure to 
brw_bufmgr.)
Signed-off-by: Sergii Romantsov 
---
  src/mesa/drivers/dri/i965/brw_bufmgr.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 09d45e3..8383735 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -643,7 +643,7 @@ retry:
 bo->kflags = bufmgr->initial_kflags;
  
 if ((bo->kflags & EXEC_OBJECT_PINNED) && bo->gtt_offset == 0ull) {

-  bo->gtt_offset = vma_alloc(bufmgr, memzone, bo->size, 1);
+  bo->gtt_offset = vma_alloc(bufmgr, memzone, bo->size, 4096);
  
if (bo->gtt_offset == 0ull)

   goto err_free;
@@ -784,7 +784,7 @@ brw_bo_gem_create_from_name(struct brw_bufmgr *bufmgr,
 bo->kflags = bufmgr->initial_kflags;
  
 if (bo->kflags & EXEC_OBJECT_PINNED)

-  bo->gtt_offset = vma_alloc(bufmgr, BRW_MEMZONE_OTHER, bo->size, 1);
+  bo->gtt_offset = vma_alloc(bufmgr, BRW_MEMZONE_OTHER, bo->size, 4096);
  
 _mesa_hash_table_insert(bufmgr->handle_table, >gem_handle, bo);

 _mesa_hash_table_insert(bufmgr->name_table, >global_name, bo);
@@ -1424,7 +1424,7 @@ brw_bo_gem_create_from_prime_internal(struct brw_bufmgr 
*bufmgr, int prime_fd,
  
 if (bo->kflags & EXEC_OBJECT_PINNED) {

assert(bo->size > 0);
-  bo->gtt_offset = vma_alloc(bufmgr, BRW_MEMZONE_OTHER, bo->size, 1);
+  bo->gtt_offset = vma_alloc(bufmgr, BRW_MEMZONE_OTHER, bo->size, 4096);
 }
  
 if (tiling_mode < 0) {



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


Re: [Mesa-dev] [PATCH] i965/miptree: Fix can_blit_slice()

2018-07-24 Thread Andres Gomez
Hi Nanley,

I'm observing regressions for SKL and BDW which doesn't seem to be
solved with this new patch, in git master. Therefore, I've gone ahead
and reported:
https://bugs.freedesktop.org/show_bug.cgi?id=107359

On Mon, 2018-07-23 at 10:17 -0700, Nanley Chery wrote:
> Satisfy the BLT engine's row pitch limitation on the destination
> miptree. The destination miptree is untiled, so its row_pitch will be
> slightly less than or equal to the source miptree's row_pitch. Use the
> source miptree's row_pitch in can_blit_slice instead of its blt_pitch.
> 
> Fixes 0288fe8d0417730bdd5b3477130dd1dc32bdbcd3
> ("i965/miptree: Use the correct BLT pitch")
> 
> Cc: 
> Reported-by: Dylan Baker 
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index a18d5ac3624..d8e823e4826 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -3544,8 +3544,13 @@ static bool
>  can_blit_slice(struct intel_mipmap_tree *mt,
> unsigned int level, unsigned int slice)
>  {
> -   /* See intel_miptree_blit() for details on the 32k pitch limit. */
> -   if (intel_miptree_blt_pitch(mt) >= 32768)
> +   /* The blit destination is untiled, so its row_pitch will be slightly less
> +* than or equal to the source's row_pitch. The BLT engine only supports
> +* linear row pitches up to but not including 32k.
> +*
> +* See intel_miptree_blit() for details on the 32k pitch limit.
> +*/
> +   if (mt->surf.row_pitch >= 32768)
>return false;
>  
> return true;
-- 
Br,

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


Re: [Mesa-dev] [PATCH v2] intel/ppgtt: memory address alignment

2018-07-24 Thread Sergii Romantsov
Hello, Kenneth.
Looks like you are expert in memory management for i965.
Could you, please, point me if that idea of patch is correct and what could
i improve?

Seems its better somehow to bind it to I915_GTT_PAGE_SIZE... right?

On Tue, Jul 24, 2018 at 2:50 PM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:

> Kernel (for ppgtt) requires memory address to be
> aligned to page size (4096).
> Added such alignment for buffers marked with EXEC_OBJECT_PINNED.
>
> -v2: added marking that also fixes initial commit 01058a552294
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106997
> Fixes: a363bb2cd0e2 (i965: Allocate VMA in userspace for full-PPGTT
> systems.)
> Fixes: 01058a552294 (i965: Add virtual memory allocator infrastructure to
> brw_bufmgr.)
> Signed-off-by: Sergii Romantsov 
> ---
>  src/mesa/drivers/dri/i965/brw_bufmgr.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> index 09d45e3..8383735 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> @@ -643,7 +643,7 @@ retry:
> bo->kflags = bufmgr->initial_kflags;
>
> if ((bo->kflags & EXEC_OBJECT_PINNED) && bo->gtt_offset == 0ull) {
> -  bo->gtt_offset = vma_alloc(bufmgr, memzone, bo->size, 1);
> +  bo->gtt_offset = vma_alloc(bufmgr, memzone, bo->size, 4096);
>
>if (bo->gtt_offset == 0ull)
>   goto err_free;
> @@ -784,7 +784,7 @@ brw_bo_gem_create_from_name(struct brw_bufmgr *bufmgr,
> bo->kflags = bufmgr->initial_kflags;
>
> if (bo->kflags & EXEC_OBJECT_PINNED)
> -  bo->gtt_offset = vma_alloc(bufmgr, BRW_MEMZONE_OTHER, bo->size, 1);
> +  bo->gtt_offset = vma_alloc(bufmgr, BRW_MEMZONE_OTHER, bo->size,
> 4096);
>
> _mesa_hash_table_insert(bufmgr->handle_table, >gem_handle, bo);
> _mesa_hash_table_insert(bufmgr->name_table, >global_name, bo);
> @@ -1424,7 +1424,7 @@ brw_bo_gem_create_from_prime_internal(struct
> brw_bufmgr *bufmgr, int prime_fd,
>
> if (bo->kflags & EXEC_OBJECT_PINNED) {
>assert(bo->size > 0);
> -  bo->gtt_offset = vma_alloc(bufmgr, BRW_MEMZONE_OTHER, bo->size, 1);
> +  bo->gtt_offset = vma_alloc(bufmgr, BRW_MEMZONE_OTHER, bo->size,
> 4096);
> }
>
> if (tiling_mode < 0) {
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



-- 
Sergii Romantsov
GlobalLogic Inc.
www.globallogic.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/4] radv: generate entrypoints for VK_ANDROID_native_buffer

2018-07-24 Thread Robert Foss

Hey Mauro,

This looks good to me.

Signed-off-by: Robert Foss 

On 2018-07-22 10:14, Mauro Rossi wrote:

Patch changes radv entrypoints generator to not skip this extension even
though it is set as disabled in the vk.xml

Reference: 63525ba730 ("android: enable VK_ANDROID_native_buffer")
Fixes: 69f447553c ("vulkan: Drop vk_android_native_buffer.xml")
Signed-off-by: Mauro Rossi 
---
  src/amd/vulkan/radv_entrypoints_gen.py | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/src/amd/vulkan/radv_entrypoints_gen.py 
b/src/amd/vulkan/radv_entrypoints_gen.py
index bef0c447f6..16aa30797e 100644
--- a/src/amd/vulkan/radv_entrypoints_gen.py
+++ b/src/amd/vulkan/radv_entrypoints_gen.py
@@ -413,9 +413,6 @@ def get_entrypoints(doc, entrypoints_to_defines, 
start_index):
  if ext_name not in supported_exts:
  continue
  
-if extension.attrib['supported'] != 'vulkan':

-continue
-
  ext = supported_exts[ext_name]
  ext.type = extension.attrib['type']
  


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


Re: [Mesa-dev] [PATCH 4/4] android: radv: enable build of vulkan.radv HAL module

2018-07-24 Thread Robert Foss

Hey Mauro,

This looks good to me.

Reviewed-by: Robert Foss 

On 2018-07-22 10:15, Mauro Rossi wrote:

src/amd/Android.mk requires to include src/amd/vulkan/Android.mk
to enable the build of vulkan.radv module

Signed-off-by: Mauro Rossi 
---
  src/amd/Android.mk | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/amd/Android.mk b/src/amd/Android.mk
index 07af05287f..6129e360cb 100644
--- a/src/amd/Android.mk
+++ b/src/amd/Android.mk
@@ -27,3 +27,4 @@ include $(LOCAL_PATH)/Makefile.sources
  
  include $(LOCAL_PATH)/Android.addrlib.mk

  include $(LOCAL_PATH)/Android.common.mk
+include $(LOCAL_PATH)/vulkan/Android.mk


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


Re: [Mesa-dev] [PATCH 1/4] radv: move vk_format_table.c to generated sources

2018-07-24 Thread Robert Foss

Hey Mauro,

This looks good to me.

Signed-off-by: Robert Foss 

On 2018-07-22 10:14, Mauro Rossi wrote:

Android build system will try to compile vk_format_table.c
as a shipped source, but at compile time it will be missing,
we move it to generated source, where it belongs

Signed-off-by: Mauro Rossi 
---
  src/amd/vulkan/Makefile.sources | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/Makefile.sources b/src/amd/vulkan/Makefile.sources
index 152fdd7cb7..53a638362b 100644
--- a/src/amd/vulkan/Makefile.sources
+++ b/src/amd/vulkan/Makefile.sources
@@ -69,7 +69,6 @@ VULKAN_FILES := \
radv_util.h \
radv_wsi.c \
si_cmd_buffer.c \
-   vk_format_table.c \
vk_format.h \
$(RADV_WS_AMDGPU_FILES)
  
@@ -89,5 +88,6 @@ VULKAN_GENERATED_FILES := \

radv_entrypoints.c \
radv_entrypoints.h \
radv_extensions.c \
-   radv_extensions.h
+   radv_extensions.h \
+   vk_format_table.c
  


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


[Mesa-dev] [PATCH v2] intel/ppgtt: memory address alignment

2018-07-24 Thread Sergii Romantsov
Kernel (for ppgtt) requires memory address to be
aligned to page size (4096).
Added such alignment for buffers marked with EXEC_OBJECT_PINNED.

-v2: added marking that also fixes initial commit 01058a552294

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106997
Fixes: a363bb2cd0e2 (i965: Allocate VMA in userspace for full-PPGTT systems.)
Fixes: 01058a552294 (i965: Add virtual memory allocator infrastructure to 
brw_bufmgr.)
Signed-off-by: Sergii Romantsov 
---
 src/mesa/drivers/dri/i965/brw_bufmgr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 09d45e3..8383735 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -643,7 +643,7 @@ retry:
bo->kflags = bufmgr->initial_kflags;
 
if ((bo->kflags & EXEC_OBJECT_PINNED) && bo->gtt_offset == 0ull) {
-  bo->gtt_offset = vma_alloc(bufmgr, memzone, bo->size, 1);
+  bo->gtt_offset = vma_alloc(bufmgr, memzone, bo->size, 4096);
 
   if (bo->gtt_offset == 0ull)
  goto err_free;
@@ -784,7 +784,7 @@ brw_bo_gem_create_from_name(struct brw_bufmgr *bufmgr,
bo->kflags = bufmgr->initial_kflags;
 
if (bo->kflags & EXEC_OBJECT_PINNED)
-  bo->gtt_offset = vma_alloc(bufmgr, BRW_MEMZONE_OTHER, bo->size, 1);
+  bo->gtt_offset = vma_alloc(bufmgr, BRW_MEMZONE_OTHER, bo->size, 4096);
 
_mesa_hash_table_insert(bufmgr->handle_table, >gem_handle, bo);
_mesa_hash_table_insert(bufmgr->name_table, >global_name, bo);
@@ -1424,7 +1424,7 @@ brw_bo_gem_create_from_prime_internal(struct brw_bufmgr 
*bufmgr, int prime_fd,
 
if (bo->kflags & EXEC_OBJECT_PINNED) {
   assert(bo->size > 0);
-  bo->gtt_offset = vma_alloc(bufmgr, BRW_MEMZONE_OTHER, bo->size, 1);
+  bo->gtt_offset = vma_alloc(bufmgr, BRW_MEMZONE_OTHER, bo->size, 4096);
}
 
if (tiling_mode < 0) {
-- 
2.7.4

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


[Mesa-dev] [Bug 106922] Tangrams demo: LLVM ERROR: Cannot select: 0x7e8d8750: i16 = bitcast 0x7e8d8af8

2018-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106922

--- Comment #4 from Christoph Haag  ---
After seeing
https://www.phoronix.com/scan.php?page=news_item=RADV-VK_KHR_16bit_storage
I thought I'd try again.

I now get a much clearer error:

SPIR-V WARNING:
In file ../src/compiler/spirv/spirv_to_nir.c:3436
Unsupported SPIR-V capability: SpvCapabilityInt16
28 bytes into the SPIR-V binary

The application then (unsurprisingly) crashes.

-- 
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/2] RFC : Context aware user space Resource control

2018-07-24 Thread Lionel Landwerlin

On 23/07/18 10:20, Kedar J Karanje wrote:

On Fri, Jul 20, 2018 at 10:59:03AM +0100, Lionel Landwerlin wrote:

On 20/07/18 09:32, aravindan.muthuku...@intel.com wrote:

diff --git a/src/egl/generate/egl.xml b/src/egl/generate/egl.xml
index 9250f93..52b0c9f 100644
--- a/src/egl/generate/egl.xml
+++ b/src/egl/generate/egl.xml
@@ -460,6 +460,14 @@
  
  
+
+
+
+
+
+
+
+
  
  
  

Are you defining a new extension here?
The chunk above seems to imply this is from IMG, but still commented as
reserved.

As far as I understand enums need to be allocated through Khronos group
before you can make use of them.
Otherwise this will be unusable by applications as soon as another extension
reuses the same enums...

Hello Lionel,
   Thank you for the comments, yes we used IMG extension as a template and were
   wondering how the xml is modified , when we found the procedure for proposing
   an extension : https://www.khronos.org/registry/OpenGL/docs/rules.html ,
   just wondering how does it work for RFC ,
   Do we need to get through the Khronos process first then send for RFC or
   is the other way round ok ? I shall dig into the mail archives for any
   existing extension and how it came into being.

Thanks,
Kedar


Hey Kedar,

I think usually there is some amount of discussion internally about 
whether the feature makes sense.

Then it's published through Khronos and finally the implementation can land.

-
Lionel


Thanks,

-
Lionel
___
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] travis: manually generate sys/syscall.h

2018-07-24 Thread Eric Engestrom
On Thursday, 2018-07-19 15:33:33 +0300, Andres Gomez wrote:
> Until now, the needed bits were wrongly included in linux/memfd.h
> 
> Since Travis' sys/syscall.h doesn't provide the SYS_memfd_create, we

Isn't this a matter of libc version? Isn't the right fix to upgrade the
libc in the container instead of faking its files?

And if the libc required is quite recent, what we need is a fallback in
the code to support older libc (possibly with some features missing),
which this build failure rightly reports.

> generate that header manually, including the needed bits to avoid
> compilation problems, as the ones observed after:
> 3228335b55c ("intel: aubinator: handle GGTT mappings")
> 
> Fixes: 7e2af374742 ("travis: split the make target to three separate ones")
> 
> Cc: Emil Velikov 
> Cc: Juan A. Suarez Romero 
> Cc: Dylan Baker 
> Cc: Eric Engestrom 
> Signed-off-by: Andres Gomez 
> ---
>  .travis.yml | 27 ---
>  1 file changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 012cc9139e0..8b1730bec69 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -584,13 +584,34 @@ install:
> "#ifndef _LINUX_MEMFD_H" \
> "#define _LINUX_MEMFD_H" \
> "" \
> -   "#define __NR_memfd_create 319" \
> -   "#define SYS_memfd_create __NR_memfd_create" \
> -   "" \
> "#define MFD_CLOEXEC 0x0001U" \
> "#define MFD_ALLOW_SEALING   0x0002U" \
> "" \
> "#endif /* _LINUX_MEMFD_H */" > linux/memfd.h
> +
> +  # Generate this header, including the missing SYS_memfd_create
> +  # macro, which is not provided by the header in the Travis
> +  # instance
> +  mkdir -p sys
> +  printf "%s\n" \
> +   "#ifndef _SYSCALL_H" \
> +   "#define _SYSCALL_H  1" \
> +   "" \
> +   "#include " \
> +   "" \
> +   "#ifndef _LIBC" \
> +   "# include " \
> +   "#endif" \
> +   "" \
> +   "#ifndef __NR_memfd_create" \
> +   "# define __NR_memfd_create 319 /* Taken from  
> */" \
> +   "#endif" \
> +   "" \
> +   "#ifndef SYS_memfd_create" \
> +   "# define SYS_memfd_create __NR_memfd_create" \
> +   "#endif" \
> +   "" \
> +   "#endif" > sys/syscall.h
>  fi
>  
>  script:
> -- 
> 2.18.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 1/7] mesa: add ASTC 2D LDR decoder

2018-07-24 Thread Eric Engestrom
On Monday, 2018-07-23 19:52:01 -0400, Marek Olšák wrote:
> From: Marek Olšák 
> 
> ---
>  src/mesa/Makefile.sources  |2 +
>  src/mesa/main/formats.c|   42 +
>  src/mesa/main/formats.h|3 +
>  src/mesa/main/texcompress_astc.cpp | 1871 
>  src/mesa/main/texcompress_astc.h   |   47 +
>  src/util/half_float.c  |   59 +
>  src/util/half_float.h  |5 +
>  7 files changed, 2029 insertions(+)
>  create mode 100644 src/mesa/main/texcompress_astc.cpp
>  create mode 100644 src/mesa/main/texcompress_astc.h
> 
> diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
> index 63f3734c322..ae8934e2830 100644
> --- a/src/mesa/Makefile.sources
> +++ b/src/mesa/Makefile.sources
> @@ -207,20 +207,22 @@ MAIN_FILES = \
>   main/shader_query.cpp \
>   main/shared.c \
>   main/shared.h \
>   main/state.c \
>   main/state.h \
>   main/stencil.c \
>   main/stencil.h \
>   main/syncobj.c \
>   main/syncobj.h \
>   main/texcompress.c \
> + main/texcompress_astc.cpp \
> + main/texcompress_astc.h \
>   main/texcompress_bptc.c \
>   main/texcompress_bptc.h \
>   main/texcompress_bptc_tmp.h \
>   main/texcompress_cpal.c \
>   main/texcompress_cpal.h \
>   main/texcompress_etc.c \
>   main/texcompress_etc.h \
>   main/texcompress_etc_tmp.h \
>   main/texcompress_fxt1.c \
>   main/texcompress_fxt1.h \

And to avoid breaking meson :)

8<
diff --git a/src/mesa/meson.build b/src/mesa/meson.build
index 8fb7db215c8f39212c07..29633691ee776089bc35 100644
--- a/src/mesa/meson.build
+++ b/src/mesa/meson.build
@@ -254,6 +254,8 @@ files_libmesa_common = files(
   'main/syncobj.c',
   'main/syncobj.h',
   'main/texcompress.c',
+  'main/texcompress_astc.cpp',
+  'main/texcompress_astc.h',
   'main/texcompress_bptc.c',
   'main/texcompress_bptc.h',
   'main/texcompress_cpal.c',
>8

> diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
> index fdb53afd570..d4cd5d2182c 100644
> --- a/src/mesa/main/formats.c
> +++ b/src/mesa/main/formats.c
> @@ -620,20 +620,62 @@ _mesa_is_format_etc2(mesa_format format)
> case MESA_FORMAT_ETC2_SIGNED_RG11_EAC:
> case MESA_FORMAT_ETC2_RGB8_PUNCHTHROUGH_ALPHA1:
> case MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1:
>return GL_TRUE;
> default:
>return GL_FALSE;
> }
>  }
>  
>  
> +/**
> + * Return TRUE if format is an ASTC 2D compressed format.
> + */
> +bool
> +_mesa_is_format_astc_2d(mesa_format format)
> +{
> +   switch (format) {
> +   case MESA_FORMAT_RGBA_ASTC_4x4:
> +   case MESA_FORMAT_RGBA_ASTC_5x4:
> +   case MESA_FORMAT_RGBA_ASTC_5x5:
> +   case MESA_FORMAT_RGBA_ASTC_6x5:
> +   case MESA_FORMAT_RGBA_ASTC_6x6:
> +   case MESA_FORMAT_RGBA_ASTC_8x5:
> +   case MESA_FORMAT_RGBA_ASTC_8x6:
> +   case MESA_FORMAT_RGBA_ASTC_8x8:
> +   case MESA_FORMAT_RGBA_ASTC_10x5:
> +   case MESA_FORMAT_RGBA_ASTC_10x6:
> +   case MESA_FORMAT_RGBA_ASTC_10x8:
> +   case MESA_FORMAT_RGBA_ASTC_10x10:
> +   case MESA_FORMAT_RGBA_ASTC_12x10:
> +   case MESA_FORMAT_RGBA_ASTC_12x12:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_4x4:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x4:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x5:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_6x5:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_6x6:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_8x5:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_8x6:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_8x8:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_10x5:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_10x6:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_10x8:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_10x10:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_12x10:
> +   case MESA_FORMAT_SRGB8_ALPHA8_ASTC_12x12:
> +  return true;
> +   default:
> +  return false;
> +   }
> +}
> +
> +
>  /**
>   * If the given format is a compressed format, return a corresponding
>   * uncompressed format.
>   */
>  mesa_format
>  _mesa_get_uncompressed_format(mesa_format format)
>  {
> switch (format) {
> case MESA_FORMAT_RGB_FXT1:
>return MESA_FORMAT_BGR_UNORM8;
> diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
> index 2afa886782b..335e4de9955 100644
> --- a/src/mesa/main/formats.h
> +++ b/src/mesa/main/formats.h
> @@ -714,20 +714,23 @@ _mesa_is_format_unsigned(mesa_format format);
>  
>  extern GLboolean
>  _mesa_is_format_signed(mesa_format format);
>  
>  extern GLboolean
>  _mesa_is_format_integer(mesa_format format);
>  
>  extern bool
>  _mesa_is_format_etc2(mesa_format format);
>  
> +bool
> +_mesa_is_format_astc_2d(mesa_format format);
> +
>  GLenum
>  _mesa_is_format_color_format(mesa_format format);
>  
>  extern GLenum
>  _mesa_get_format_color_encoding(mesa_format format);
>  
>  extern GLuint
>  _mesa_format_image_size(mesa_format format, GLsizei width,
>  GLsizei height, GLsizei depth);
>  
> diff --git 

Re: [Mesa-dev] [PATCH] travis: manually generate sys/syscall.h

2018-07-24 Thread Juan A. Suarez Romero
Reviewed-by: Juan A. Suarez 



On Thu, 2018-07-19 at 15:33 +0300, Andres Gomez wrote:
> Until now, the needed bits were wrongly included in linux/memfd.h
> 
> Since Travis' sys/syscall.h doesn't provide the SYS_memfd_create, we
> generate that header manually, including the needed bits to avoid
> compilation problems, as the ones observed after:
> 3228335b55c ("intel: aubinator: handle GGTT mappings")
> 
> Fixes: 7e2af374742 ("travis: split the make target to three separate ones")
> 
> Cc: Emil Velikov 
> Cc: Juan A. Suarez Romero 
> Cc: Dylan Baker 
> Cc: Eric Engestrom 
> Signed-off-by: Andres Gomez 
> ---
>  .travis.yml | 27 ---
>  1 file changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 012cc9139e0..8b1730bec69 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -584,13 +584,34 @@ install:
> "#ifndef _LINUX_MEMFD_H" \
> "#define _LINUX_MEMFD_H" \
> "" \
> -   "#define __NR_memfd_create 319" \
> -   "#define SYS_memfd_create __NR_memfd_create" \
> -   "" \
> "#define MFD_CLOEXEC 0x0001U" \
> "#define MFD_ALLOW_SEALING   0x0002U" \
> "" \
> "#endif /* _LINUX_MEMFD_H */" > linux/memfd.h
> +
> +  # Generate this header, including the missing SYS_memfd_create
> +  # macro, which is not provided by the header in the Travis
> +  # instance
> +  mkdir -p sys
> +  printf "%s\n" \
> +   "#ifndef _SYSCALL_H" \
> +   "#define _SYSCALL_H  1" \
> +   "" \
> +   "#include " \
> +   "" \
> +   "#ifndef _LIBC" \
> +   "# include " \
> +   "#endif" \
> +   "" \
> +   "#ifndef __NR_memfd_create" \
> +   "# define __NR_memfd_create 319 /* Taken from  
> */" \
> +   "#endif" \
> +   "" \
> +   "#ifndef SYS_memfd_create" \
> +   "# define SYS_memfd_create __NR_memfd_create" \
> +   "#endif" \
> +   "" \
> +   "#endif" > sys/syscall.h
>  fi
>  
>  script:

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


Re: [Mesa-dev] [PATCH v2 1/2] i965, anv: Add extra unused character in disk_cache renderer temp string

2018-07-24 Thread Lionel Landwerlin

On 23/07/18 05:27, Jordan Justen wrote:

This extra character should not be used by snprintf, but we make it
available to verify that we printed the exact number we wanted, and
didn't overflow.

v2:
  * Also update Anvil

Signed-off-by: Jordan Justen 
Reviewed-by: Lionel Landwerlin  (v1)


For the series v2 :

Reviewed-by: Lionel Landwerlin 


---
  src/intel/vulkan/anv_device.c  | 4 ++--
  src/mesa/drivers/dri/i965/brw_disk_cache.c | 5 +++--
  2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 04fd6a829ed..247ba641336 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -278,10 +278,10 @@ static void
  anv_physical_device_init_disk_cache(struct anv_physical_device *device)
  {
  #ifdef ENABLE_SHADER_CACHE
-   char renderer[9];
+   char renderer[10];
 MAYBE_UNUSED int len = snprintf(renderer, sizeof(renderer), "anv_%04x",
 device->chipset_id);
-   assert(len == sizeof(renderer) - 1);
+   assert(len == sizeof(renderer) - 2);
  
 char timestamp[41];

 _mesa_sha1_format(timestamp, device->driver_build_sha1);
diff --git a/src/mesa/drivers/dri/i965/brw_disk_cache.c 
b/src/mesa/drivers/dri/i965/brw_disk_cache.c
index c478753d4ad..a678c355b9d 100644
--- a/src/mesa/drivers/dri/i965/brw_disk_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_disk_cache.c
@@ -377,10 +377,11 @@ void
  brw_disk_cache_init(struct intel_screen *screen)
  {
  #ifdef ENABLE_SHADER_CACHE
-   char renderer[10];
+   /* array length: print length + null char + 1 extra to verify it is unused 
*/
+   char renderer[11];
 MAYBE_UNUSED int len = snprintf(renderer, sizeof(renderer), "i965_%04x",
 screen->deviceID);
-   assert(len == sizeof(renderer) - 1);
+   assert(len == sizeof(renderer) - 2);
  
 const struct build_id_note *note =

build_id_find_nhdr_for_addr(brw_disk_cache_init);



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


[Mesa-dev] [PATCH v3 1/4] softpipe: Add assert verifying successful pipe_transfer_map

2018-07-24 Thread Robert Foss
This failure mode is a bit tricky to debug and manifests itself
later as a null pointer dereference, for which finding the origin
is needlessly tricky.

Signed-off-by: Robert Foss 
Reviewed-by: Brian Paul 
---

Changes since v2:
  - Added r-b

Changes since v1:
  - Patch added

 src/gallium/drivers/softpipe/sp_tile_cache.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/softpipe/sp_tile_cache.c 
b/src/gallium/drivers/softpipe/sp_tile_cache.c
index 351736ee421..211cc5ef4b0 100644
--- a/src/gallium/drivers/softpipe/sp_tile_cache.c
+++ b/src/gallium/drivers/softpipe/sp_tile_cache.c
@@ -209,6 +209,7 @@ sp_tile_cache_set_surface(struct softpipe_tile_cache *tc,
 
PIPE_TRANSFER_UNSYNCHRONIZED,
 0, 0, ps->width, 
ps->height,
 >transfer[i]);
+assert(tc->transfer_map[i]);
  }
   }
   else {
-- 
2.17.1

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


[Mesa-dev] [PATCH v3 3/4] platform/android: Enable kms_swrast fallback

2018-07-24 Thread Robert Foss
Add support for the ForceSoftware option, which is togglable
on the Android platform through setting the "drm.gpu.force_software"
property to a non-zero value.

kms_swrast is also enabled as a fallback for when a driver is not
able to be loaded for for a drm node that was opened.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---

Changes since v2:
  - Further remove variable/argument that is just a copy of other variable

Changes since v1:
  - Added r-b
  - Removed local variable

Changes since RFC:
  - Removed whitespace change
  - Switched variable type from int to EGLBoolean
  - Removed software renderer fallback from platform_android, since
it is already implemented in _eglMatchDriver()

 src/egl/drivers/dri2/platform_android.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 92b2d2b343e..669881a7152 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1198,7 +1198,11 @@ droid_load_driver(_EGLDisplay *disp)
struct dri2_egl_display *dri2_dpy = disp->DriverData;
const char *err;
 
-   dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
+   if (disp->Options.ForceSoftware)
+  dri2_dpy->driver_name = strdup("kms_swrast");
+   else
+  dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
+
if (dri2_dpy->driver_name == NULL)
   return false;
 
@@ -1362,10 +1366,6 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay 
*disp)
const char *err;
int ret;
 
-   /* Not supported yet */
-   if (disp->Options.ForceSoftware)
-  return EGL_FALSE;
-
loader_set_logger(_eglLog);
 
dri2_dpy = calloc(1, sizeof(*dri2_dpy));
@@ -1384,10 +1384,12 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay 
*disp)
 
dri2_dpy->fd = droid_open_device(disp);
if (dri2_dpy->fd < 0) {
-  err = "DRI2: failed to open device";
+  err = "DRI2: failed to open device, trying software device";
   goto cleanup;
}
 
+   /* Fallback to forcing software rendering is implemented using
+* disp->Options.ForceSoftware in egldriver.c */
if (!droid_load_driver(disp)) {
   err = "DRI2: failed to load driver";
   goto cleanup;
-- 
2.17.1

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


[Mesa-dev] [PATCH v3 0/4] Android kms_swrast support

2018-07-24 Thread Robert Foss

This series implements kms_swrast support for the Android
platform. And since having to debug a null pointer dereference,
simplify that process for the next guy.

As it stands now, any kernel must have the following ioctls flagged with
DRM_RENDER_ALLOW[1], which isn't the case in the mainline kernel.

DRM_IOCTL_MODE_CREATE_DUMB
DRM_IOCTL_MODE_MAP_DUMB

I've started a seperate discussion on the kernel ML[1] to seeks some more 
answers
about what the upstream linux community views as the best solution


[1] https://lkml.org/lkml/2018/7/24/187


Changes since v2:
  - Added r-b
  - Actually implement all of Erics feedback

Changes since v1:
  - Added r-b
  - Added patch for asserting on failed pipe_transfer_map()

Changes since RFC:
  - Dropped "st/dri: Allow kms_swrast to work without a device FD"
  - Removed software renderer fallback from platform_android
  - Fixed various smaller issues


Rob Herring (1):
  android: Build kms_swrast for the Android platform

Robert Foss (3):
  softpipe: Add assert verifying successful pipe_transfer_map
  egl/android: Add Android property for forcing software rendering
  platform/android: Enable kms_swrast fallback

 src/egl/drivers/dri2/platform_android.c  | 14 +
 src/egl/main/egldriver.c | 10 ++
 src/gallium/Android.mk   |  2 +-
 src/gallium/auxiliary/pipe-loader/Android.mk |  1 +
 src/gallium/drivers/softpipe/Android.mk  |  4 +--
 src/gallium/drivers/softpipe/sp_tile_cache.c |  1 +
 src/gallium/state_trackers/dri/Android.mk|  1 +
 src/gallium/winsys/sw/kms-dri/Android.mk | 33 
 8 files changed, 57 insertions(+), 9 deletions(-)
 create mode 100644 src/gallium/winsys/sw/kms-dri/Android.mk

-- 
2.17.1

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


  1   2   >