Re: [Mesa-dev] MESA_Build_ERROR

2019-03-18 Thread Sergii Romantsov
Hello,
seems my question was wrong - sorry.
Actually looks like your toolchain doesn't support this sys-call.
Think, you could try or update your toolchain if it possible to be
containing SYS_memfd_create
or you could try to use meson (
https://ubuntu.pkgs.org/18.10/ubuntu-universe-i386/meson_0.47.2-1ubuntu2_all.deb.html)
instead of autotools
Note: for meson option '-Dtools' should't contain 'intel'

On Mon, Mar 18, 2019 at 12:32 PM Milav  wrote:

> Hello Romantsov,
>
> Here i have sent uname -a result.
>
> teqdiligent@ubuntu:~$ uname -a
> Linux ubuntu 4.2.0-27-generic #32~14.04.1-Ubuntu SMP Fri Jan 22 15:32:26
> UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> teqdiligent@ubuntu:~$
>
>
> ---
>
> in '/usr/include/bits/syscall.h' there is no define of *memfd_create.*
>
>
> ---
>
> Regards
>
> Milav
> On 3/15/19 5:12 PM, Sergii Romantsov wrote:
>
> /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c: In
>> function 'memfd_create':
>> /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19:
>> error: 'SYS_memfd_create' undeclared (first use in this function)
>> /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19:
>> note: each undeclared identifier is reported only once for each function it
>> appears in
>
> What is your kernel (uname -a)?
> Seems memfd_create is supported from 3.17
> And just for case what is content of file '/usr/include/bits/syscall.h'?
>
> On Fri, Mar 15, 2019 at 10:26 AM Milav  wrote:
>
>> Hello Sir,
>>
>> This Is Milav Soni From TEQ DILIGENT.
>>
>> I cross compiled the xserver using jhbuild.
>>
>> I follow the following link.
>>
>> https://www.x.org/wiki/CrossCompilingXorg/
>>
>> But when it comes in mesa configuration, it gives following error.
>>
>>
>> /*--error-*/
>>
>> copying selected object files to avoid basename conflicts...
>>   CXXLDglsl_compiler
>> make[4]: Leaving directory
>> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/compiler'
>> make[3]: Leaving directory
>> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/compiler'
>> Making all in intel
>> make[3]: Entering directory
>> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel'
>> make  all-am
>> make[4]: Entering directory
>> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel'
>>   CC   isl/libisl_tiled_memcpy_sse41_la-isl_tiled_memcpy_sse41.lo
>>   CC   tools/tools_aubinator-aub_mem.o
>> /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:
>> In function 'memfd_create':
>> /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19:
>> error: 'SYS_memfd_create' undeclared (first use in this function)
>> /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19:
>> note: each undeclared identifier is reported only once for each function it
>> appears in
>> make[4]: *** [tools/tools_aubinator-aub_mem.o] Error 1
>> make[4]: *** Waiting for unfinished jobs
>> *arm-cortexa8-linux-gnueabihf-gcc: error: unrecognized command line
>> option '-msse4.1'*
>> make[4]: *** [isl/libisl_tiled_memcpy_sse41_la-isl_tiled_memcpy_sse41.lo]
>> Error 1
>> make[4]: Leaving directory
>> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel'
>> make[3]: *** [all] Error 2
>> make[3]: Leaving directory
>> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel'
>> make[2]: *** [all-recursive] Error 1
>> make[2]: Leaving directory
>> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src'
>> make[1]: *** [all] Error 2
>> make[1]: Leaving directory
>> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src'
>> make: *** [all-recursive] Error 1
>> *** Error during phase build of mesa-mesa: ## Error running make
>> -j 2  *** [37/38]
>>
>>   [1] Rerun phase build
>>   [2] Ignore error and continue to install
>>   [3] Give up on module
>>   [4] Start shell
>>   [5] Reload configuration
>>   [6] Go to phase "wipe directory and start over"
>>   [7] Go to phase "configure"
>>   [8] Go to phase "clean"
>>   [9] Go to phase "distclean"
>> choice: ^X^CInterr

Re: [Mesa-dev] MESA_Build_ERROR

2019-03-15 Thread Sergii Romantsov
>
> /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c: In
> function 'memfd_create':
> /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19:
> error: 'SYS_memfd_create' undeclared (first use in this function)
> /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19:
> note: each undeclared identifier is reported only once for each function it
> appears in

What is your kernel (uname -a)?
Seems memfd_create is supported from 3.17
And just for case what is content of file '/usr/include/bits/syscall.h'?

On Fri, Mar 15, 2019 at 10:26 AM Milav  wrote:

> Hello Sir,
>
> This Is Milav Soni From TEQ DILIGENT.
>
> I cross compiled the xserver using jhbuild.
>
> I follow the following link.
>
> https://www.x.org/wiki/CrossCompilingXorg/
>
> But when it comes in mesa configuration, it gives following error.
>
>
> /*--error-*/
>
> copying selected object files to avoid basename conflicts...
>   CXXLDglsl_compiler
> make[4]: Leaving directory
> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/compiler'
> make[3]: Leaving directory
> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/compiler'
> Making all in intel
> make[3]: Entering directory
> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel'
> make  all-am
> make[4]: Entering directory
> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel'
>   CC   isl/libisl_tiled_memcpy_sse41_la-isl_tiled_memcpy_sse41.lo
>   CC   tools/tools_aubinator-aub_mem.o
> /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c: In
> function 'memfd_create':
> /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19:
> error: 'SYS_memfd_create' undeclared (first use in this function)
> /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19:
> note: each undeclared identifier is reported only once for each function it
> appears in
> make[4]: *** [tools/tools_aubinator-aub_mem.o] Error 1
> make[4]: *** Waiting for unfinished jobs
> *arm-cortexa8-linux-gnueabihf-gcc: error: unrecognized command line option
> '-msse4.1'*
> make[4]: *** [isl/libisl_tiled_memcpy_sse41_la-isl_tiled_memcpy_sse41.lo]
> Error 1
> make[4]: Leaving directory
> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel'
> make[3]: *** [all] Error 2
> make[3]: Leaving directory
> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory
> `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src'
> make: *** [all-recursive] Error 1
> *** Error during phase build of mesa-mesa: ## Error running make
> -j 2  *** [37/38]
>
>   [1] Rerun phase build
>   [2] Ignore error and continue to install
>   [3] Give up on module
>   [4] Start shell
>   [5] Reload configuration
>   [6] Go to phase "wipe directory and start over"
>   [7] Go to phase "configure"
>   [8] Go to phase "clean"
>   [9] Go to phase "distclean"
> choice: ^X^CInterrupted
> teqdiligent@ubuntu:~$
>
>
> /*---*/
>
> I use following configuration.
>
> $/home/teqdiligent/sources/xorg/git/mesa/mesa/autogen.sh --prefix
> /home/teqdiligent/jhbuild/wega_build/usr/local --disable-Werror
> --enable-autotools --enable-xa  --disable-static --disable-dri2
> --with-driver=dri --cache-file=~/sources/xorg/git/autoconf-cache
> --with-log-dir=/var/log --with-mesa-source=~/sources/xorg/git/mesa
> --enable-malloc0returnsnull --build=x86_64-unknown-linux-gnu
> --host=arm-cortexa8-linux-gnueabihf --target=arm-cortexa8-linux-gnueabihf
> AR="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-ar"
> RANLIB="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-ranlib"
> STRIP="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-strip"
> AS="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-as"
> OBJDUMP="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-objdump"
> NM="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-nm&quo

Re: [Mesa-dev] [PATCH v1] nir: Length of boolean vtn_value now is 1

2019-01-23 Thread Sergii Romantsov
Hello, Jason. Sorry for belated answer.
Why length of 1 was selected: primary type SpvOpTypeBool is already using
length 1 (and description "For Workgroup pointers, this is the size of the
referenced type.").

Additionally with length of 4 CI gives 3 failed tests:
https://mesa-ci.01.org/global_logic/builds/56/group/63a9f0ea7bb98050796b649e85481845
.
With length of 1 it passes:
https://mesa-ci.01.org/global_logic/builds/57/group/63a9f0ea7bb98050796b649e85481845

So do we still need to use 4?

On Thu, Jan 17, 2019 at 7:13 PM Jason Ekstrand  wrote:

> I think this is probably mostly ok.  There's still some question about
> exactly what gets stored there and who is storing it.
>
> On Thu, Jan 17, 2019 at 4:34 AM apinheiro  wrote:
>
>> I was waiting Jason to chime in, but just in case he is too busy I took
>> a look in detail to the patch. It LGTM, so assuming it passes intel CI:
>>
>> Reviewed-by: Alejandro Piñeiro 
>>
>> On 15/1/19 12:08, Sergii Romantsov wrote:
>> > During conversion type-length was lost due to math.
>> >
>> > CC: Jason Ekstrand 
>> > Fixes: 44227453ec03 (nir: Switch to using 1-bit Booleans for almost
>> everything)
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109353
>> > Signed-off-by: Sergii Romantsov 
>> > ---
>> >   src/compiler/spirv/spirv_to_nir.c | 9 ++---
>> >   1 file changed, 6 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/src/compiler/spirv/spirv_to_nir.c
>> b/src/compiler/spirv/spirv_to_nir.c
>> > index e3dc619..faad771 100644
>> > --- a/src/compiler/spirv/spirv_to_nir.c
>> > +++ b/src/compiler/spirv/spirv_to_nir.c
>> > @@ -1042,14 +1042,16 @@ vtn_type_layout_std430(struct vtn_builder *b,
>> struct vtn_type *type,
>> >   {
>> >  switch (type->base_type) {
>> >  case vtn_base_type_scalar: {
>> > -  uint32_t comp_size = glsl_get_bit_size(type->type) / 8;
>> > +  uint32_t comp_size = glsl_type_is_boolean(type->type)
>> > + ? 1 : glsl_get_bit_size(type->type) / 8;
>>
>
> Because we don't know in spirv_to_nir what size the back-end is going to
> use for booleans, we should assume they're 32-bit and use 4 here and
> below.  Otherwise, we may end up with booleans overlapping other stuff.
>
>
>> > *size_out = comp_size;
>> > *align_out = comp_size;
>> > return type;
>> >  }
>> >
>> >  case vtn_base_type_vector: {
>> > -  uint32_t comp_size = glsl_get_bit_size(type->type) / 8;
>> > +  uint32_t comp_size = glsl_type_is_boolean(type->type)
>> > + ? 1 : glsl_get_bit_size(type->type) / 8;
>> > unsigned align_comps = type->length == 3 ? 4 : type->length;
>> > *size_out = comp_size * type->length,
>> > *align_out = comp_size * align_comps;
>> > @@ -1168,7 +1170,8 @@ vtn_handle_type(struct vtn_builder *b, SpvOp
>> opcode,
>> > val->type->base_type = vtn_base_type_vector;
>> > val->type->type =
>> glsl_vector_type(glsl_get_base_type(base->type), elems);
>> > val->type->length = elems;
>> > -  val->type->stride = glsl_get_bit_size(base->type) / 8;
>> > +  val->type->stride = glsl_type_is_boolean(val->type->type)
>> > + ? 1 : glsl_get_bit_size(base->type) / 8;
>> > val->type->array_element = base;
>> > break;
>> >  }
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v1] nir: Length of boolean vtn_value now is 1

2019-01-15 Thread Sergii Romantsov
During conversion type-length was lost due to math.

CC: Jason Ekstrand 
Fixes: 44227453ec03 (nir: Switch to using 1-bit Booleans for almost everything)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109353
Signed-off-by: Sergii Romantsov 
---
 src/compiler/spirv/spirv_to_nir.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index e3dc619..faad771 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1042,14 +1042,16 @@ vtn_type_layout_std430(struct vtn_builder *b, struct 
vtn_type *type,
 {
switch (type->base_type) {
case vtn_base_type_scalar: {
-  uint32_t comp_size = glsl_get_bit_size(type->type) / 8;
+  uint32_t comp_size = glsl_type_is_boolean(type->type)
+ ? 1 : glsl_get_bit_size(type->type) / 8;
   *size_out = comp_size;
   *align_out = comp_size;
   return type;
}
 
case vtn_base_type_vector: {
-  uint32_t comp_size = glsl_get_bit_size(type->type) / 8;
+  uint32_t comp_size = glsl_type_is_boolean(type->type)
+ ? 1 : glsl_get_bit_size(type->type) / 8;
   unsigned align_comps = type->length == 3 ? 4 : type->length;
   *size_out = comp_size * type->length,
   *align_out = comp_size * align_comps;
@@ -1168,7 +1170,8 @@ vtn_handle_type(struct vtn_builder *b, SpvOp opcode,
   val->type->base_type = vtn_base_type_vector;
   val->type->type = glsl_vector_type(glsl_get_base_type(base->type), 
elems);
   val->type->length = elems;
-  val->type->stride = glsl_get_bit_size(base->type) / 8;
+  val->type->stride = glsl_type_is_boolean(val->type->type)
+ ? 1 : glsl_get_bit_size(base->type) / 8;
   val->type->array_element = base;
   break;
}
-- 
2.7.4

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


[Mesa-dev] [PATCH v2] configure/vulkan: linking issue of Vulkan

2018-11-19 Thread Sergii Romantsov
From: Sergii Romantsov 

Xcb-dri3 is installed into custom directory.
Installing of Vulkan on Ubuntu 16.04 fails during relinking.
Potential reason: seems during relinking a path to the custom
dri3-path is missed: glx.la depends on libloader_dri3_helper.la
which depends on XCB_DRI3_LIBS.
XCB_DRI3_LIBS contains a correct custom path, but its invisible
on lib@GL_LIB@_la_LIBADD stage.
Seems caught libtool-issue.
Solution: library-dependicies GL_LIB_DEPS moved upper.

CC: Dylan Baker 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107624
Signed-off-by: Sergii Romantsov 
---
 src/glx/Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
index d208ce1..2a1fce3 100644
--- a/src/glx/Makefile.am
+++ b/src/glx/Makefile.am
@@ -175,10 +175,10 @@ endif
 # against the system one.
 GL_LIBS = \
$(LIBDRM_LIBS) \
+   $(GL_LIB_DEPS) \
libglx.la \
$(top_builddir)/src/mapi/glapi/libglapi.la \
-   $(top_builddir)/src/mapi/shared-glapi/libglapi.la \
-   $(GL_LIB_DEPS)
+   $(top_builddir)/src/mapi/shared-glapi/libglapi.la
 
 GL_LDFLAGS = \
-no-undefined \
-- 
2.7.4

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


[Mesa-dev] [PATCH v4] mesa/driconf: rotation of 0-vector

2018-11-07 Thread Sergii Romantsov
Specification doesn't define behaviour for rotation of 0-vector.
In https://github.com/KhronosGroup/OpenGL-API/issues/41 said that
behaviour is undefined and agreed that it would be fine for
implementation to do something useful for this.
Windows and Nvidia drivers have a workaround for that.
For compatibility proposed optimized version of computations.
Specification defines a formula of rotation (see "OpenGL 4.6
(Compatibility Profile) - May 14, 2018", paragraph "12.1.1 Matrices").

Optimized formula will look so:

   R = cos(angle) * I

That is equavalent to logic that magnitude of (0,0,0)-vector is 1.0.

-v2: logic moved to _math_matrix_rotate

-v3: general optimization of computations

-v4: added compatible_0vector_rotation option

CC: Tapani Pälli 
CC: Timothy Arceri 
CC: Brian Paul 
Signed-off-by: Sergii Romantsov 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100960
Spec: https://github.com/KhronosGroup/OpenGL-API/issues/41
---
 src/mesa/drivers/dri/i915/intel_screen.c |  1 +
 src/mesa/drivers/dri/i965/brw_context.c  |  3 +++
 src/mesa/drivers/dri/i965/intel_screen.c |  1 +
 src/mesa/main/matrix.c   |  3 ++-
 src/mesa/main/mtypes.h   |  5 +
 src/mesa/math/m_matrix.c | 14 +-
 src/mesa/math/m_matrix.h |  2 +-
 src/util/xmlpool/t_options.h |  5 +
 8 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
b/src/mesa/drivers/dri/i915/intel_screen.c
index 50934c1..49a1c5f 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -71,6 +71,7 @@ DRI_CONF_BEGIN
   DRI_CONF_FORCE_GLSL_EXTENSIONS_WARN("false")
   DRI_CONF_DISABLE_GLSL_LINE_CONTINUATIONS("false")
   DRI_CONF_DISABLE_BLEND_FUNC_EXTENDED("false")
+  DRI_CONF_COMPATIBLE_0VECTOR_ROTATION("false")
 
   DRI_CONF_OPT_BEGIN_B(stub_occlusion_query, "false")
 DRI_CONF_DESC(en, "Enable stub ARB_occlusion_query support on 
915/945.")
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 6ba64e4..ca50364 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -890,6 +890,9 @@ brw_process_driconf_options(struct brw_context *brw)
ctx->Const.AllowGLSLCrossStageInterpolationMismatch =
   driQueryOptionb(options, 
"allow_glsl_cross_stage_interpolation_mismatch");
 
+   ctx->Const.Compatible0VectorRotation =
+  driQueryOptionb(options, "compatible_0vector_rotation");
+
ctx->Const.dri_config_options_sha1 = ralloc_array(brw, unsigned char, 20);
driComputeOptionsSha1(>screen->optionCache,
  ctx->Const.dri_config_options_sha1);
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index c57fb54..67938b6 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -87,6 +87,7 @@ DRI_CONF_BEGIN
   DRI_CONF_ALLOW_GLSL_CROSS_STAGE_INTERPOLATION_MISMATCH("false")
   DRI_CONF_ALLOW_HIGHER_COMPAT_VERSION("false")
   DRI_CONF_FORCE_GLSL_ABS_SQRT("false")
+  DRI_CONF_COMPATIBLE_0VECTOR_ROTATION("false")
 
   DRI_CONF_OPT_BEGIN_B(shader_precompile, "true")
 DRI_CONF_DESC(en, "Perform code generation at shader link time.")
diff --git a/src/mesa/main/matrix.c b/src/mesa/main/matrix.c
index 8065a83..28537a5 100644
--- a/src/mesa/main/matrix.c
+++ b/src/mesa/main/matrix.c
@@ -415,7 +415,8 @@ _mesa_Rotatef( GLfloat angle, GLfloat x, GLfloat y, GLfloat 
z )
 
FLUSH_VERTICES(ctx, 0);
if (angle != 0.0F) {
-  _math_matrix_rotate( ctx->CurrentStack->Top, angle, x, y, z);
+  _math_matrix_rotate( ctx->CurrentStack->Top, angle, x, y, z,
+   ctx->Const.Compatible0VectorRotation );
   ctx->NewState |= ctx->CurrentStack->DirtyFlag;
}
 }
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 9ed49b7..e9cbcf1 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3789,6 +3789,11 @@ struct gl_constants
GLboolean AllowLayoutQualifiersOnFunctionParameters;
 
/**
+* Allow compatible to Windows and Nvidia logic of 0-vector rotation.
+*/
+   GLboolean Compatible0VectorRotation;
+
+   /**
 * Force computing the absolute value for sqrt() and inversesqrt() to follow
 * D3D9 when apps rely on this behaviour.
 */
diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
index 57a4953..8ff7b11 100644
--- a/src/mesa/math/m_matrix.c
+++ b/src/mesa/math/m_matrix.c
@@ -794,7 +794,7 @@ static GLboolean matrix_invert( GLmatrix *mat )
  */
 void
 _math_matrix_rotate( GLmatrix *mat,
-GLfloat angle, GLflo

[Mesa-dev] [PATCH v1] i965/batch/debug: Allow log be dumped before assert

2018-11-05 Thread Sergii Romantsov
Message that may show the culprit of assert now will
be dumped before that for debug purposes.

CC: Kenneth Graunke 
CC: Lionel G Landwerlin 
Signed-off-by: Sergii Romantsov 
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 8b769ea..353fcba 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -725,10 +725,10 @@ execbuffer(int fd,
 
   /* Update brw_bo::gtt_offset */
   if (batch->validation_list[i].offset != bo->gtt_offset) {
- assert(!(bo->kflags & EXEC_OBJECT_PINNED));
  DBG("BO %d migrated: 0x%" PRIx64 " -> 0x%llx\n",
  bo->gem_handle, bo->gtt_offset,
  batch->validation_list[i].offset);
+ assert(!(bo->kflags & EXEC_OBJECT_PINNED));
  bo->gtt_offset = batch->validation_list[i].offset;
   }
}
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v3] autotools: library-dependency when no sse and 32-bit

2018-11-05 Thread Sergii Romantsov
Could, please, somebody push?

On Thu, Nov 1, 2018 at 6:11 PM Dylan Baker  wrote:

> Reviewed-by: Dylan Baker 
>
> Quoting Sergii Romantsov (2018-11-01 04:02:43)
> > Building of 32bit Mesa may fail if __SSE__ is not specified.
> > Added missed dependency from libm.
> >
> > v2: avoided dependecy on any flag, just link
> >
> > v3: meson doesn't fail, but have added dependency on libm
> >
> > CC: Dylan Baker 
> > CC: Lionel G Landwerlin 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
> > Signed-off-by: Sergii Romantsov 
> > ---
> >  src/util/Makefile.am | 3 ++-
> >  src/util/meson.build | 2 +-
> >  2 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/util/Makefile.am b/src/util/Makefile.am
> > index d79f2b3..85c7553 100644
> > --- a/src/util/Makefile.am
> > +++ b/src/util/Makefile.am
> > @@ -60,7 +60,8 @@ libmesautil_la_LIBADD = \
> > $(PTHREAD_LIBS) \
> > $(CLOCK_LIB) \
> > $(ZLIB_LIBS) \
> > -   $(LIBATOMIC_LIBS)
> > +   $(LIBATOMIC_LIBS) \
> > +   -lm
> >
> >  libxmlconfig_la_SOURCES = $(XMLCONFIG_FILES)
> >  libxmlconfig_la_CFLAGS = \
> > diff --git a/src/util/meson.build b/src/util/meson.build
> > index 49d84c1..5b82b21 100644
> > --- a/src/util/meson.build
> > +++ b/src/util/meson.build
> > @@ -113,7 +113,7 @@ libmesa_util = static_library(
> >'mesa_util',
> >[files_mesa_util, format_srgb],
> >include_directories : inc_common,
> > -  dependencies : [dep_zlib, dep_clock, dep_thread, dep_atomic],
> > +  dependencies : [dep_zlib, dep_clock, dep_thread, dep_atomic, dep_m],
> >c_args : [c_msvc_compat_args, c_vis_args],
> >build_by_default : false
> >  )
> > --
> > 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


[Mesa-dev] [PATCH v3] autotools: library-dependency when no sse and 32-bit

2018-11-01 Thread Sergii Romantsov
Building of 32bit Mesa may fail if __SSE__ is not specified.
Added missed dependency from libm.

v2: avoided dependecy on any flag, just link

v3: meson doesn't fail, but have added dependency on libm

CC: Dylan Baker 
CC: Lionel G Landwerlin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
Signed-off-by: Sergii Romantsov 
---
 src/util/Makefile.am | 3 ++-
 src/util/meson.build | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/util/Makefile.am b/src/util/Makefile.am
index d79f2b3..85c7553 100644
--- a/src/util/Makefile.am
+++ b/src/util/Makefile.am
@@ -60,7 +60,8 @@ libmesautil_la_LIBADD = \
$(PTHREAD_LIBS) \
$(CLOCK_LIB) \
$(ZLIB_LIBS) \
-   $(LIBATOMIC_LIBS)
+   $(LIBATOMIC_LIBS) \
+   -lm
 
 libxmlconfig_la_SOURCES = $(XMLCONFIG_FILES)
 libxmlconfig_la_CFLAGS = \
diff --git a/src/util/meson.build b/src/util/meson.build
index 49d84c1..5b82b21 100644
--- a/src/util/meson.build
+++ b/src/util/meson.build
@@ -113,7 +113,7 @@ libmesa_util = static_library(
   'mesa_util',
   [files_mesa_util, format_srgb],
   include_directories : inc_common,
-  dependencies : [dep_zlib, dep_clock, dep_thread, dep_atomic],
+  dependencies : [dep_zlib, dep_clock, dep_thread, dep_atomic, dep_m],
   c_args : [c_msvc_compat_args, c_vis_args],
   build_by_default : false
 )
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v2] autotools: library-dependency when no sse and 32-bit

2018-11-01 Thread Sergii Romantsov
Hi,
meson doesn't fail, but, probably, better to add for sure.
Will do soon.

On Thu, Nov 1, 2018 at 12:25 PM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Hi Sergii,
>
> Do we need the same fix in meson?
>
> Thanks,
>
> -
> Lionel
>
> On 01/11/2018 07:25, Sergii Romantsov wrote:
>
> Thanks, Dylan.
> Could, please, somebody push it?
>
> On Tue, Oct 30, 2018 at 5:30 PM Dylan Baker  wrote:
>
>> Reviewed-by: Dylan Baker 
>>
>> Quoting Sergii Romantsov (2018-10-30 02:45:14)
>> > Building of 32bit Mesa may fail if __SSE__ is not specified.
>> > Added missed dependency from libm.
>> >
>> > CC: Dylan Baker 
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
>> > Signed-off-by: Sergii Romantsov 
>> > ---
>> >  src/util/Makefile.am | 3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/src/util/Makefile.am b/src/util/Makefile.am
>> > index d79f2b3..85c7553 100644
>> > --- a/src/util/Makefile.am
>> > +++ b/src/util/Makefile.am
>> > @@ -60,7 +60,8 @@ libmesautil_la_LIBADD = \
>> > $(PTHREAD_LIBS) \
>> > $(CLOCK_LIB) \
>> > $(ZLIB_LIBS) \
>> > -   $(LIBATOMIC_LIBS)
>> > +   $(LIBATOMIC_LIBS) \
>> > +   -lm
>> >
>> >  libxmlconfig_la_SOURCES = $(XMLCONFIG_FILES)
>> >  libxmlconfig_la_CFLAGS = \
>> > --
>> > 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 
> listmesa-dev@lists.freedesktop.orghttps://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 v2] autotools: library-dependency when no sse and 32-bit

2018-11-01 Thread Sergii Romantsov
Thanks, Dylan.
Could, please, somebody push it?

On Tue, Oct 30, 2018 at 5:30 PM Dylan Baker  wrote:

> Reviewed-by: Dylan Baker 
>
> Quoting Sergii Romantsov (2018-10-30 02:45:14)
> > Building of 32bit Mesa may fail if __SSE__ is not specified.
> > Added missed dependency from libm.
> >
> > CC: Dylan Baker 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
> > Signed-off-by: Sergii Romantsov 
> > ---
> >  src/util/Makefile.am | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/util/Makefile.am b/src/util/Makefile.am
> > index d79f2b3..85c7553 100644
> > --- a/src/util/Makefile.am
> > +++ b/src/util/Makefile.am
> > @@ -60,7 +60,8 @@ libmesautil_la_LIBADD = \
> > $(PTHREAD_LIBS) \
> > $(CLOCK_LIB) \
> > $(ZLIB_LIBS) \
> > -   $(LIBATOMIC_LIBS)
> > +   $(LIBATOMIC_LIBS) \
> > +   -lm
> >
> >  libxmlconfig_la_SOURCES = $(XMLCONFIG_FILES)
> >  libxmlconfig_la_CFLAGS = \
> > --
> > 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] intel/aubinator_error_decode: link libm

2018-11-01 Thread Sergii Romantsov
Hello, it looks like not complete fix.
In my opinion issue is that libmesautil requires -lm than any library that
uses libmesautil will not have such issue.
Patch: https://patchwork.freedesktop.org/patch/259176/

On Thu, Nov 1, 2018 at 6:12 AM Jonathan Gray  wrote:

> aubinator_error_decode needs to link libm to build on OpenBSD/i386
> ../../src/util/.libs/libmesautil.a(libmesautil_la-half_float.o): In
> function `_mesa_float_to_half':
> half_float.c:(.text+0x91): undefined reference to `lrintf'
> half_float.c:(.text+0xc1): undefined reference to `lrintf'
>
> Signed-off-by: Jonathan Gray 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/intel/Makefile.tools.am | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/Makefile.tools.am b/src/intel/Makefile.tools.am
> index 4809962b188..da49d37a728 100644
> --- a/src/intel/Makefile.tools.am
> +++ b/src/intel/Makefile.tools.am
> @@ -61,7 +61,8 @@ tools_aubinator_error_decode_LDADD = \
> isl/libisl.la \
> $(top_builddir)/src/util/libmesautil.la \
> $(PTHREAD_LIBS) \
> -   $(ZLIB_LIBS)
> +   $(ZLIB_LIBS) \
> +   -lm
>
>  tools_aubinator_error_decode_CFLAGS = \
> $(AM_CFLAGS) \
> --
> 2.19.1
>
> ___
> 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 v1 1/5] meson: compilation flags for sse

2018-10-30 Thread Sergii Romantsov
Thanks for a comments. I see the most of that patches have no sense,
probably, except one:

Yeah, I think we should land that if it fixes the build for 32bit x86.

Here is: https://patchwork.freedesktop.org/patch/259176/

On Mon, Oct 29, 2018 at 6:04 PM Dylan Baker  wrote:

> Quoting Sergii Romantsov (2018-10-29 01:44:28)
> > Hello,
> >
> > What problem are we solving?
> >
> > That we don't get fast paths in rounding.h by default on i686, I
> think?
> >
> > Yes, it adds optimization for rounding.h. On x86_64 msse is enabled by
> default
> > (as example by gcc).
> > And additionally helps to fix autotools 32b build (missed linkage with
> m-lib if
> > no optimization).
> >
> >
> > This will make the code non-portable from an SSE capable system to a
> > non-sse
> > capable system. That's a pretty old system at this point (Pentium
> III and
> > Athlon
> > XP)
> >
> > As i found in gcc-docs (https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/
> > i386-and-x86_002d64-Options.html) exactly mentioned systems are supports
> SSE.
> > But in the patch i'm checking if -msse supported by compiler.
> > If its incorrect than does it mean that compiler doesn't based on system
> > capabilities? And does it mean that adding option -msse4.1 is also
> enabled in
> > wrong way?
>
> Right, the compiler can support instructions the "build" machine (computer
> running the compiler) can't run. Even for builds of the same architecture.
>
> No, the -msee4.1 case in src/mesa is different. We have a runtime check in
> libmesa that detects sse4.1 features at run time and loads the sse4.1
> optimized
> functions if it can, or falls back to non-sse4.1 versions if it can't.
>
> > I'm cloning gcc to check how it supports 'sse' and if it based on system
> > capabilities. Also we may try to add some possibility to check
> cpu-capabilities
> > (around cpuid).
> > But if we don't need such optimization, than it will be nice at least to
> fix
> > autotools 32b build (https://patchwork.freedesktop.org/patch/258659/) -
> i will
> > update patch just by linking -lm with mesautil.
>
> Yeah, I think we should land that if it fixes the build for 32bit x86.
>
> Dylan
>


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


[Mesa-dev] [PATCH v2] autotools: library-dependency when no sse and 32-bit

2018-10-30 Thread Sergii Romantsov
Building of 32bit Mesa may fail if __SSE__ is not specified.
Added missed dependency from libm.

CC: Dylan Baker 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
Signed-off-by: Sergii Romantsov 
---
 src/util/Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/util/Makefile.am b/src/util/Makefile.am
index d79f2b3..85c7553 100644
--- a/src/util/Makefile.am
+++ b/src/util/Makefile.am
@@ -60,7 +60,8 @@ libmesautil_la_LIBADD = \
$(PTHREAD_LIBS) \
$(CLOCK_LIB) \
$(ZLIB_LIBS) \
-   $(LIBATOMIC_LIBS)
+   $(LIBATOMIC_LIBS) \
+   -lm
 
 libxmlconfig_la_SOURCES = $(XMLCONFIG_FILES)
 libxmlconfig_la_CFLAGS = \
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v1 1/5] meson: compilation flags for sse

2018-10-29 Thread Sergii Romantsov
Hello,
>
> What problem are we solving?

That we don't get fast paths in rounding.h by default on i686, I think?

Yes, it adds optimization for rounding.h. On x86_64 msse is enabled by
default (as example by gcc).
And additionally helps to fix autotools 32b build (missed linkage with
m-lib if no optimization).

This will make the code non-portable from an SSE capable system to a non-sse
> capable system. That's a pretty old system at this point (Pentium III and
> Athlon
> XP)

As i found in gcc-docs (
https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html)
exactly mentioned systems are supports SSE.
But in the patch i'm checking if -msse supported by compiler.
If its incorrect than does it mean that compiler doesn't based on system
capabilities? And does it mean that adding option -msse4.1 is also enabled
in wrong way?

I'm cloning gcc to check how it supports 'sse' and if it based on system
capabilities. Also we may try to add some possibility to check
cpu-capabilities (around cpuid).
But if we don't need such optimization, than it will be nice at least to
fix autotools 32b build (https://patchwork.freedesktop.org/patch/258659/) -
i will update patch just by linking -lm with mesautil.

Please, advise.

On Fri, Oct 26, 2018 at 9:54 PM Dylan Baker  wrote:

> Quoting Matt Turner (2018-10-26 10:44:47)
> > On Fri, Oct 26, 2018 at 3:06 AM Sergii Romantsov
> >  wrote:
> > >
> > > While building of 32bit Mesa gcc doesn't specifies __SSE__ by default.
> > > So it has to be done manually by flag '-msee'.
> > > Added support of such specification to build-system.
> > >
> > > CC: Dylan Baker 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
> > > Signed-off-by: Sergii Romantsov 
> >
> > We can't do that.
> >
> > Maybe I'm missing some context. What problem are we solving?
>
> That we don't get fast paths in rounding.h by default on i686, I think?
> ___
> 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


[Mesa-dev] [PATCH v1 4/5] autotools: library-dependency when no sse and 32-bit

2018-10-26 Thread Sergii Romantsov
Building of 32bit Mesa may fail if __SSE__ is not specified.
Added missed dependency from libm.

CC: Dylan Baker 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
Signed-off-by: Sergii Romantsov 
---
 src/util/Makefile.am | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/util/Makefile.am b/src/util/Makefile.am
index d79f2b3..24eeaa8 100644
--- a/src/util/Makefile.am
+++ b/src/util/Makefile.am
@@ -62,6 +62,11 @@ libmesautil_la_LIBADD = \
$(ZLIB_LIBS) \
$(LIBATOMIC_LIBS)
 
+if !SSE_CFLAGS
+libmesautil_la_LIBADD += \
+   -lm
+endif
+
 libxmlconfig_la_SOURCES = $(XMLCONFIG_FILES)
 libxmlconfig_la_CFLAGS = \
$(DEFINES) \
-- 
2.7.4

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


[Mesa-dev] [PATCH v1 3/5] autotools: compilation flags for sse

2018-10-26 Thread Sergii Romantsov
While building of 32bit Mesa gcc doesn't specifies __SSE__ by default.
So it has to be done manually by flag '-msee'.
Added support of such specification to build-system.

CC: Dylan Baker 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
Signed-off-by: Sergii Romantsov 
---
 configure.ac | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/configure.ac b/configure.ac
index ab9bdce..f88ac87 100644
--- a/configure.ac
+++ b/configure.ac
@@ -421,13 +421,27 @@ dnl
 dnl Optional flags, check for compiler support
 dnl
 SSE41_CFLAGS="-msse4.1"
+dnl
+dnl x86_64 enables -msse by default, on x86 it required to be enabled manually
+dnl
+SSE_CFLAGS=
+SSE_CXXFLAGS=
+
 dnl Code compiled by GCC with -msse* assumes a 16 byte aligned
 dnl stack, but on x86-32 such alignment is not guaranteed.
 case "$target_cpu" in
 i?86)
 SSE41_CFLAGS="$SSE41_CFLAGS -mstackrealign"
+AX_CHECK_COMPILE_FLAG([-msse],[SSE_CFLAGS="-msse 
-mstackrealign"])
+AC_LANG_PUSH([C++])
+AX_CHECK_COMPILE_FLAG([-msse],[SSE_CXXFLAGS="-msse 
-mstackrealign"])
+AC_LANG_POP([C++])
 ;;
 esac
+AC_SUBST([SSE_CFLAGS], $SSE_CFLAGS)
+AC_SUBST([SSE_CXXFLAGS], $SSE_CXXFLAGS)
+AM_CONDITIONAL([SSE_CFLAGS], [test -n x$SSE_CFLAGS])
+
 save_CFLAGS="$CFLAGS"
 CFLAGS="$SSE41_CFLAGS $CFLAGS"
 AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
-- 
2.7.4

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


[Mesa-dev] [PATCH v1 2/5] meson: specify -msse manually for 32-bit build

2018-10-26 Thread Sergii Romantsov
While building of 32bit Mesa gcc doesn't specifies __SSE__ by default.
So it has to be done manually by flag '-msee'.
Added support of such specification to build-system.
That enables optimization for file src/util/rounding.h.

CC: Dylan Baker 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
Signed-off-by: Sergii Romantsov 
---
 src/compiler/glsl/meson.build   | 2 +-
 src/compiler/meson.build| 4 ++--
 src/compiler/nir/meson.build| 2 +-
 src/glx/meson.build | 2 +-
 src/intel/blorp/meson.build | 2 +-
 src/intel/common/meson.build| 2 +-
 src/intel/compiler/meson.build  | 4 ++--
 src/intel/isl/meson.build   | 2 +-
 src/intel/tools/meson.build | 2 +-
 src/mesa/drivers/dri/common/meson.build | 4 ++--
 src/mesa/meson.build| 4 ++--
 src/util/meson.build| 2 +-
 12 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/src/compiler/glsl/meson.build b/src/compiler/glsl/meson.build
index 71b4c42..1b96bdc 100644
--- a/src/compiler/glsl/meson.build
+++ b/src/compiler/glsl/meson.build
@@ -215,7 +215,7 @@ libglsl = static_library(
   [files_libglsl, glsl_parser, glsl_lexer_cpp, ir_expression_operation_h,
ir_expression_operation_strings_h, ir_expression_operation_constant_h],
   c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
-  cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
+  cpp_args : [cpp_vis_args, cpp_msvc_compat_args, cpp_sse_args],
   link_with : libglcpp,
   include_directories : [inc_common, inc_compiler, inc_nir],
   dependencies : idep_nir,
diff --git a/src/compiler/meson.build b/src/compiler/meson.build
index 0f8f3c1..8ae49c4 100644
--- a/src/compiler/meson.build
+++ b/src/compiler/meson.build
@@ -48,8 +48,8 @@ libcompiler = static_library(
   'compiler',
   [files_libcompiler, ir_expression_operation_h],
   include_directories : [inc_mapi, inc_mesa, inc_compiler, inc_common],
-  c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
-  cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
+  c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args, c_sse_args],
+  cpp_args : [cpp_vis_args, cpp_msvc_compat_args, cpp_sse_args],
   dependencies : [dep_valgrind],
   build_by_default : false,
 )
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index d8f6564..528d8f7 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -215,7 +215,7 @@ libnir = static_library(
nir_opcodes_h, nir_constant_expressions_c, nir_builder_opcodes_h,
vtn_gather_types_c, nir_intrinsics_c, nir_intrinsics_h],
   include_directories : [inc_common, inc_compiler, 
include_directories('../spirv')],
-  c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
+  c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args, c_sse_args],
   link_with : libcompiler,
   build_by_default : false,
 )
diff --git a/src/glx/meson.build b/src/glx/meson.build
index dd8ba60..1d4327f 100644
--- a/src/glx/meson.build
+++ b/src/glx/meson.build
@@ -146,7 +146,7 @@ libglx = static_library(
   [files_libglx, glx_generated],
   include_directories : [inc_common, inc_glapi, inc_loader, inc_gl_internal],
   c_args : [
-c_vis_args, gl_lib_cargs,
+c_vis_args, gl_lib_cargs, c_sse_args,
 '-DGL_LIB_NAME="lib@0@.so.@1@"'.format(gl_lib_name, 
gl_lib_version.split('.')[0]),
   ],
   link_with : [
diff --git a/src/intel/blorp/meson.build b/src/intel/blorp/meson.build
index c1201b0..490ce6f 100644
--- a/src/intel/blorp/meson.build
+++ b/src/intel/blorp/meson.build
@@ -32,6 +32,6 @@ libblorp = static_library(
   'blorp',
   files_libblorp,
   include_directories : [inc_common, inc_intel],
-  c_args : [c_vis_args, no_override_init_args],
+  c_args : [c_vis_args, no_override_init_args, c_sse_args],
   dependencies : idep_nir_headers,
 )
diff --git a/src/intel/common/meson.build b/src/intel/common/meson.build
index 332e978..c452a40 100644
--- a/src/intel/common/meson.build
+++ b/src/intel/common/meson.build
@@ -41,7 +41,7 @@ libintel_common = static_library(
   ['intel_common', genX_xml_h],
   files_libintel_common,
   include_directories : [inc_common, inc_intel],
-  c_args : [c_vis_args, no_override_init_args],
+  c_args : [c_vis_args, no_override_init_args, c_sse_args],
   link_with : [libisl],
   dependencies : [dep_expat, dep_libdrm, dep_thread],
 )
diff --git a/src/intel/compiler/meson.build b/src/intel/compiler/meson.build
index 3cdeb62..a6fd188 100644
--- a/src/intel/compiler/meson.build
+++ b/src/intel/compiler/meson.build
@@ -134,8 +134,8 @@ libintel_compiler = static_library(
   'intel_compiler',
   [libintel_compiler_files, brw_nir_trig, ir_expression_operation_h],
   include_directories : [inc_common, inc_intel],
-  c_args : [c_vis_args, no_override_init_args],
-  cpp_args : [cpp_vis_args],
+  c_args : [c_vis_args, no_override_init_args, c_sse_args],
+  cpp_args : [cp

[Mesa-dev] [PATCH v1 1/5] meson: compilation flags for sse

2018-10-26 Thread Sergii Romantsov
While building of 32bit Mesa gcc doesn't specifies __SSE__ by default.
So it has to be done manually by flag '-msee'.
Added support of such specification to build-system.

CC: Dylan Baker 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
Signed-off-by: Sergii Romantsov 
---
 meson.build | 12 
 1 file changed, 12 insertions(+)

diff --git a/meson.build b/meson.build
index 505cc6c..f335434 100644
--- a/meson.build
+++ b/meson.build
@@ -806,6 +806,12 @@ if cc.has_argument('-fvisibility=hidden')
   c_vis_args += '-fvisibility=hidden'
 endif
 
+c_sse_args = []
+# x86_64 enables -msse by default, on x86 it required to be enabled manually
+if host_machine.cpu_family() == 'x86' and cc.has_argument('-msse')
+  c_sse_args += ['-msse', '-mstackrealign']
+endif
+
 # Check for generic C++ arguments
 cpp_args = []
 foreach a : ['-Wall', '-fno-math-errno', '-fno-trapping-math',
@@ -836,6 +842,12 @@ if cpp.has_argument('-fvisibility=hidden')
   cpp_vis_args += '-fvisibility=hidden'
 endif
 
+cpp_sse_args = []
+# x86_64 enables -msse by default, on x86 it required to be enabled manually
+if host_machine.cpu_family() == 'x86' and cpp.has_argument('-msse')
+  cpp_sse_args += ['-msse', '-mstackrealign']
+endif
+
 # Check for C and C++ arguments for MSVC2013 compatibility. These are only used
 # in parts of the mesa code base that need to compile with old versions of
 # MSVC, mainly common code
-- 
2.7.4

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


[Mesa-dev] [PATCH v1 5/5] autotools: specify -msse manually for 32-bit build

2018-10-26 Thread Sergii Romantsov
While building of 32bit Mesa gcc doesn't specifies __SSE__ by default.
So it has to be done manually by flag '-msee'.
Added support of such specification to build-system.
That enables optimization for file src/util/rounding.h.

CC: Dylan Baker 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
Signed-off-by: Sergii Romantsov 
---
 src/Makefile.am | 2 +-
 src/compiler/Makefile.am| 6 --
 src/glx/Makefile.am | 3 ++-
 src/intel/Makefile.am   | 6 --
 src/intel/Makefile.common.am| 2 +-
 src/mesa/Makefile.am| 7 +--
 src/mesa/drivers/dri/common/Makefile.am | 3 ++-
 src/util/Makefile.am| 3 ++-
 8 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index c4fcd8a..cff6fc3 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -113,7 +113,7 @@ EXTRA_DIST += \
getopt hgl SConscript \
$(top_srcdir)/include/GL/mesa_glinterop.h
 
-AM_CFLAGS = $(VISIBILITY_CFLAGS)
+AM_CFLAGS = $(VISIBILITY_CFLAGS) $(SSE_CFLAGS)
 AM_CXXFLAGS = $(VISIBILITY_CXXFLAGS)
 
 AM_CPPFLAGS = \
diff --git a/src/compiler/Makefile.am b/src/compiler/Makefile.am
index 73435a3..3ad87ce 100644
--- a/src/compiler/Makefile.am
+++ b/src/compiler/Makefile.am
@@ -43,11 +43,13 @@ AM_CPPFLAGS = \
 AM_CFLAGS = \
$(VISIBILITY_CFLAGS) \
$(WNO_OVERRIDE_INIT) \
-   $(MSVC2013_COMPAT_CFLAGS)
+   $(MSVC2013_COMPAT_CFLAGS) \
+   $(SSE_CFLAGS)
 
 AM_CXXFLAGS = \
$(VISIBILITY_CXXFLAGS) \
-   $(MSVC2013_COMPAT_CXXFLAGS)
+   $(MSVC2013_COMPAT_CXXFLAGS) \
+   $(SSE_CXXFLAGS)
 
 noinst_LTLIBRARIES = libcompiler.la
 
diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
index 8f9d80c..cb17c0f 100644
--- a/src/glx/Makefile.am
+++ b/src/glx/Makefile.am
@@ -45,7 +45,8 @@ AM_CFLAGS = \
$(LIBDRM_CFLAGS) \
$(DRI2PROTO_CFLAGS) \
$(GLPROTO_CFLAGS) \
-   $(X11_INCLUDES)
+   $(X11_INCLUDES) \
+   $(SSE_CFLAGS)
 
 lib_LTLIBRARIES = lib@GL_LIB@.la
 
diff --git a/src/intel/Makefile.am b/src/intel/Makefile.am
index 95764b8..5f37a2a 100644
--- a/src/intel/Makefile.am
+++ b/src/intel/Makefile.am
@@ -44,10 +44,12 @@ AM_CPPFLAGS = \
 
 AM_CFLAGS = \
$(VISIBILITY_CFLAGS) \
-   $(WNO_OVERRIDE_INIT)
+   $(WNO_OVERRIDE_INIT) \
+   $(SSE_CFLAGS)
 
 AM_CXXFLAGS = \
-   $(VISIBILITY_CXXFLAGS)
+   $(VISIBILITY_CXXFLAGS) \
+   $(SSE_CXXFLAGS)
 
 MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D)
 PYTHON_GEN = $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS)
diff --git a/src/intel/Makefile.common.am b/src/intel/Makefile.common.am
index 443cefc..3f9415e 100644
--- a/src/intel/Makefile.common.am
+++ b/src/intel/Makefile.common.am
@@ -21,7 +21,7 @@
 
 noinst_LTLIBRARIES += common/libintel_common.la
 
-common_libintel_common_la_CFLAGS = $(AM_CFLAGS) $(LIBDRM_CFLAGS) 
$(EXPAT_CFLAGS)
+common_libintel_common_la_CFLAGS = $(AM_CFLAGS) $(LIBDRM_CFLAGS) 
$(EXPAT_CFLAGS) $(SSE_CFLAGS)
 common_libintel_common_la_SOURCES = $(COMMON_FILES)
 common_libintel_common_la_LIBADD = $(EXPAT_LIBS)
 
diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am
index 195e440..b97f58e 100644
--- a/src/mesa/Makefile.am
+++ b/src/mesa/Makefile.am
@@ -114,11 +114,14 @@ AM_CFLAGS = \
$(VDPAU_CFLAGS) \
$(LLVM_CFLAGS) \
$(VISIBILITY_CFLAGS) \
-   $(MSVC2013_COMPAT_CFLAGS)
+   $(MSVC2013_COMPAT_CFLAGS) \
+   $(SSE_CFLAGS)
+
 AM_CXXFLAGS = \
$(LLVM_CFLAGS) \
$(VISIBILITY_CXXFLAGS) \
-   $(MSVC2013_COMPAT_CXXFLAGS)
+   $(MSVC2013_COMPAT_CXXFLAGS) \
+   $(SSE_CXXFLAGS)
 
 ARCH_LIBS =
 
diff --git a/src/mesa/drivers/dri/common/Makefile.am 
b/src/mesa/drivers/dri/common/Makefile.am
index 192b364..d653340 100644
--- a/src/mesa/drivers/dri/common/Makefile.am
+++ b/src/mesa/drivers/dri/common/Makefile.am
@@ -33,7 +33,8 @@ AM_CFLAGS = \
-I$(top_builddir)/src/util/ \
$(LIBDRM_CFLAGS) \
$(DEFINES) \
-   $(VISIBILITY_CFLAGS)
+   $(VISIBILITY_CFLAGS) \
+   $(SSE_CFLAGS)
 
 noinst_LTLIBRARIES = \
libdricommon.la \
diff --git a/src/util/Makefile.am b/src/util/Makefile.am
index 24eeaa8..9f7fe98 100644
--- a/src/util/Makefile.am
+++ b/src/util/Makefile.am
@@ -50,7 +50,8 @@ libmesautil_la_CPPFLAGS = \
-I$(top_srcdir)/src/gallium/auxiliary \
$(VISIBILITY_CFLAGS) \
$(MSVC2013_COMPAT_CFLAGS) \
-   $(ZLIB_CFLAGS)
+   $(ZLIB_CFLAGS) \
+   $(SSE_CFLAGS)
 
 libmesautil_la_SOURCES = \
$(MESA_UTIL_FILES) \
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v3] mesa: rotation of 0-vector

2018-10-10 Thread Sergii Romantsov
Hello,
i've updated a test for the latest version of mesa-patch:
https://patchwork.freedesktop.org/patch/255629/
The image should looks for any driver (Windows, Nvidia, mesa) like this:
[image: Screenshot from 2018-10-10 13-47-56.png]

On Fri, Sep 21, 2018 at 4:21 PM Sergii Romantsov 
wrote:

> Specification doesn't define behaviour for rotation of 0-vector.
> In https://github.com/KhronosGroup/OpenGL-API/issues/41 said that
> behaviour is undefined and agreed that it would be fine for
> implementation to do something useful for this.
> Windows and Nvidia drivers have a workaround for that.
> For compatibility proposed optimized version of computations.
> Specification defines a formula of rotation (see "OpenGL 4.6
> (Compatibility Profile) - May 14, 2018", paragraph "12.1.1 Matrices").
>
> Optimized formula will look so:
>
>R = cos(angle) * I
>
> That is equavalent to logic that magnitude of (0,0,0)-vector is 1.0.
>
> -v2: logic moved to _math_matrix_rotate
>
> -v3: general optimization of computations
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100960
> Signed-off-by: Sergii Romantsov 
> ---
>  src/mesa/math/m_matrix.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
> index 57a4953..3eef122 100644
> --- a/src/mesa/math/m_matrix.c
> +++ b/src/mesa/math/m_matrix.c
> @@ -824,6 +824,18 @@ _math_matrix_rotate( GLmatrix *mat,
> M(1,0) = s;
>  }
>   }
> + else {
> +/* https://bugs.freedesktop.org/show_bug.cgi?id=100960
> + * https://github.com/KhronosGroup/OpenGL-API/issues/41
> + * Here we will treat magnitude as 1.0 if it really 0.0.
> + * So that is kind of workaround for empty-vectors to have
> + * compatibility with Windows and Nvidia drivers.
> + */
> +optimized = GL_TRUE;
> +M(0,0) = c;
> +M(1,1) = c;
> +M(2,2) = c;
> + }
>}
>else if (z == 0.0F) {
>   optimized = GL_TRUE;
> --
> 2.7.4
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v1] loader/dri3: wait for fences if back-buffer available

2018-10-01 Thread Sergii Romantsov
Yes, it also works

On Mon, Oct 1, 2018 at 5:24 PM Michel Dänzer  wrote:

> On 2018-10-01 12:37 p.m., Sergii Romantsov wrote:
> > Kabylake doesn't have such issue, but also it doesn't have
> > a front buffers in that case.
> > Coffelake can be fixed if to wait for fences if it has back-buffer.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108097
> > Fixes: aefac10fecc9 (loader/dri3: Only wait for back buffer fences in
> dri3_get_buffer)
> > CC: Michel Dänzer 
> > Signed-off-by: Sergii Romantsov 
> > ---
> >  src/loader/loader_dri3_helper.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/loader/loader_dri3_helper.c
> b/src/loader/loader_dri3_helper.c
> > index 258678a..e9f59a2 100644
> > --- a/src/loader/loader_dri3_helper.c
> > +++ b/src/loader/loader_dri3_helper.c
> > @@ -1819,7 +1819,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> >draw->buffers[buf_id] = buffer;
> > }
> >
> > -   if (buffer_type == loader_dri3_buffer_back)
> > +   if (buffer_type == loader_dri3_buffer_back || draw->have_back)
> >dri3_fence_await(draw->conn, draw, buffer);
> >
> > /*
> >
>
> Thanks for the patch, but unfortunately, this re-introduces
> https://bugs.freedesktop.org/106404 .  Also, conceptually it's not clear
> why the presence of a back buffer would affect waiting for the fake
> front buffer's fence.
>
>
> Unfortunately, I'm unable to reproduce the problem with radeonsi. Does
> the patch below help by any chance?
>
>
> diff --git a/src/loader/loader_dri3_helper.c
> b/src/loader/loader_dri3_helper.c
> index f641a34e6d1..1981b5f0515 100644
> --- a/src/loader/loader_dri3_helper.c
> +++ b/src/loader/loader_dri3_helper.c
> @@ -1736,6 +1736,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
>  struct loader_dri3_drawable *draw)
>  {
> struct loader_dri3_buffer *buffer;
> +   bool fence_await = buffer_type == loader_dri3_buffer_back;
> int buf_id;
>
> if (buffer_type == loader_dri3_buffer_back) {
> @@ -1791,6 +1792,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> 0, 0, 0, 0,
> draw->width, draw->height);
>  dri3_fence_trigger(draw->conn, new_buffer);
> +fence_await = true;
>   }
>   dri3_free_render_buffer(draw, buffer);
>} else if (buffer_type == loader_dri3_buffer_front) {
> @@ -1812,13 +1814,14 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
>new_buffer->linear_buffer,
>0, 0, draw->width, draw->height,
>0, 0, 0);
> - }
> + } else
> +fence_await = true;
>}
>buffer = new_buffer;
>draw->buffers[buf_id] = buffer;
> }
>
> -   if (buffer_type == loader_dri3_buffer_back)
> +   if (fence_await)
>dri3_fence_await(draw->conn, draw, buffer);
>
>     /*
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> 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


[Mesa-dev] [PATCH v1] loader/dri3: wait for fences if back-buffer available

2018-10-01 Thread Sergii Romantsov
Kabylake doesn't have such issue, but also it doesn't have
a front buffers in that case.
Coffelake can be fixed if to wait for fences if it has back-buffer.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108097
Fixes: aefac10fecc9 (loader/dri3: Only wait for back buffer fences in 
dri3_get_buffer)
CC: Michel Dänzer 
Signed-off-by: Sergii Romantsov 
---
 src/loader/loader_dri3_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 258678a..e9f59a2 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -1819,7 +1819,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
   draw->buffers[buf_id] = buffer;
}
 
-   if (buffer_type == loader_dri3_buffer_back)
+   if (buffer_type == loader_dri3_buffer_back || draw->have_back)
   dri3_fence_await(draw->conn, draw, buffer);
 
/*
-- 
2.7.4

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


[Mesa-dev] [PATCH v3] mesa: rotation of 0-vector

2018-09-21 Thread Sergii Romantsov
Specification doesn't define behaviour for rotation of 0-vector.
In https://github.com/KhronosGroup/OpenGL-API/issues/41 said that
behaviour is undefined and agreed that it would be fine for
implementation to do something useful for this.
Windows and Nvidia drivers have a workaround for that.
For compatibility proposed optimized version of computations.
Specification defines a formula of rotation (see "OpenGL 4.6
(Compatibility Profile) - May 14, 2018", paragraph "12.1.1 Matrices").

Optimized formula will look so:

   R = cos(angle) * I

That is equavalent to logic that magnitude of (0,0,0)-vector is 1.0.

-v2: logic moved to _math_matrix_rotate

-v3: general optimization of computations

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100960
Signed-off-by: Sergii Romantsov 
---
 src/mesa/math/m_matrix.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
index 57a4953..3eef122 100644
--- a/src/mesa/math/m_matrix.c
+++ b/src/mesa/math/m_matrix.c
@@ -824,6 +824,18 @@ _math_matrix_rotate( GLmatrix *mat,
M(1,0) = s;
 }
  }
+ else {
+/* https://bugs.freedesktop.org/show_bug.cgi?id=100960
+ * https://github.com/KhronosGroup/OpenGL-API/issues/41
+ * Here we will treat magnitude as 1.0 if it really 0.0.
+ * So that is kind of workaround for empty-vectors to have
+ * compatibility with Windows and Nvidia drivers.
+ */
+optimized = GL_TRUE;
+M(0,0) = c;
+M(1,1) = c;
+M(2,2) = c;
+ }
   }
   else if (z == 0.0F) {
  optimized = GL_TRUE;
-- 
2.7.4

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


Re: [Mesa-dev] [ANNOUNCE] Mesa 18.2.1 release candidate

2018-09-20 Thread Sergii Romantsov
Hello,
about rejected:

> Sergii Romantsov (1):
>   4aec44c0d9c i965/tools: 32bit compilation with meson
> Reason: this commit was immediately reverted by commit 2dce1175c1c.


Actually, commit 'i965/tools: 32bit compilation with meson' depends on
'intel: compiler option msse2 and mstackrealign'
And it was reverted due to the second one wasn't pushed before.

So, i would say it may be queued because 'intel: compiler option msse2 and
mstackrealign' is also queued.

On Thu, Sep 20, 2018 at 12:43 AM Juan A. Suarez Romero 
wrote:

> Hello list,
>
> The candidate for the Mesa 18.2.1 is now available. Currently we have:
>  - 57 queued (+1 squashed)
>  - 0 nominated (outstanding)
>  - and 2 rejected patches
>
> The current queue consists of:
>
> Vulkan headers are now updated to 1.1.84.
>
> Lot of fixes for Vulkan drivers.
>
> In RADV driver there are fixes for crashes in the CTS testsuite, GPU hangs
> when
> using indirect descriptors, fixes for VK_EXT_conditional_rendering
> extension,
> and some other fixes.
>
> On the other hand, ANV driver also contains several fixes related with
> vertex
> attributes, disabling cache in SKL GT4 tessellation shader, clamping
> scissors in
> framebuffer, support for v3 in VK_EXT_vertex_attribute_divisor extension,
> and
> several other fixes.
>
> Other fixes are also available for Broadcom's Android driver, radeonsi,
> r600,
> v3d, and so on.
>
> Meson also gets a couple of fixes, including fixes when compiling 32bit
> Intel
> drivers.
>
>
> Take a look at section "Mesa stable queue" for more information.
>
>
> Testing reports/general approval
> 
> Any testing reports (or general approval of the state of the branch) will
> be
> greatly appreciated.
>
> The plan is to have 18.2.1 this Friday (21st September), around or shortly
> after 12:00
> GMT.
>
> If you have any questions or suggestions - be that about the current patch
> queue
> or otherwise, please go ahead.
>
>
> Trivial merge conflicts
> ---
> commit 3f20c0a004e3e8ed4f56114af445ac9eed9e19e6
> Author: Sergii Romantsov 
>
> i965/tools: 32bit compilation with meson
>
> (cherry picked from commit 97fcccb25ed5f55139c03ebc1c71742f0f25f683)
>
> commit f1305c32c1cd4f7c59ef5dfb2eac9edabc70
> Author: Jason Ekstrand 
>
> nir: Add a small pass to rematerialize derefs per-block
>
> (cherry picked from commit 7d1d1208c2b38890fe065b6431ef2e3b7166bae4)
>
>
> Cheers,
> J.A.
>
>
> Mesa stable queue
> -
>
> Nominated (0)
> ==
>
> Queued (57)
> ===
> Andres Gomez (1):
>   Revert "Revert "glsl: skip stringification in preprocessor if in
> unreachable branch""
>
> Andrii Simiklit (4):
>   mesa/util: add missing va_end() after va_copy()
>   mesa/util: don't ignore NULL returned from 'malloc'
>   mesa/util: don't use the same 'va_list' instance twice
>   apple/glx/log: added missing va_end() after va_copy()
>
> Bas Nieuwenhuizen (4):
>   radv: Use build ID if available for cache UUID.
>   radv: Only allow 16 user SGPRs for compute on GFX9+.
>   radv: Set the user SGPR MSB for Vega.
>   radv: Support v3 of VK_EXT_vertex_attribute_divisor.
>
> Christopher Egert (1):
>   radeon: fix ColorMask
>
> Dave Airlie (1):
>   virgl: don't send a shader create with no data. (v2)
>
> Dylan Baker (1):
>   meson: Print a message about why a libdrm version was selected
>
> Eric Anholt (2):
>   v3d: Fix setup of the VCM cache size.
>   v3d: Fix SRC_ALPHA_SATURATE blending for RTs without alpha.
>
> Erik Faye-Lund (2):
>   virgl: adjust strides when mapping temp-resources
>   winsys/virgl: avoid unintended behavior
>
> Fritz Koenig (2):
>   mesa: FramebufferParameteri parameter checking
>   mesa: Additional FlipY applications
>
> Gert Wollny (2):
>   mesa/texture: Also check for LA texture when querying intensity
> component size
>   winsys/virgl: correct resource and handle allocation (v2)
>
> Ian Romanick (1):
>   i965/fs: Don't propagate conditional modifiers from integer compares
> to adds
>
> Jason Ekstrand (11):
>   nir/opt_if: Re-materialize derefs in use blocks before peeling loops
>   nir/loop_unroll: Re-materialize derefs in use blocks before unrolling
>   nir: Add a small pass to rematerialize derefs per-block
>Squashed with:
>   nir: add initializer data to fix MSVC compile error
>   anv/query: Write both dwords in emit_zero_queries
>   anv: Support v3 of VK_EXT_

[Mesa-dev] [PATCH v2] anv/skylake: disable ForceThreadDispatchEnable

2018-09-19 Thread Sergii Romantsov
On Skylake enabling of ForceThreadDispatchEnable causes gpu-hang.

-v2: enabling of  ForceThreadDispatchEnable is only for gen8, for
 gen9 and higher reverted enabling of PixelShaderHasUAV.

CC: Jason Ekstrand 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107941
Fixes: 79270d2140ec (anv: Stop setting 3DSTATE_PS_EXTRA::PixelShaderHasUAV)
Signed-off-by: Sergii Romantsov 
---
 src/intel/vulkan/genX_pipeline.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 9595a71..b469270 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -1445,7 +1445,7 @@ emit_3dstate_wm(struct anv_pipeline *pipeline, struct 
anv_subpass *subpass,
 wm.EarlyDepthStencilControl = EDSC_NORMAL;
  }
 
-#if GEN_GEN >= 8
+#if GEN_GEN == 8
  /* Gen8 hardware tries to compute ThreadDispatchEnable for us but
   * doesn't take into account KillPixels when no depth or stencil
   * writes are enabled.  In order for occlusion queries to work
@@ -1663,6 +1663,37 @@ emit_3dstate_ps_extra(struct anv_pipeline *pipeline,
  wm_prog_data->uses_kill;
 
 #if GEN_GEN >= 9
+  /* The stricter cross-primitive coherency guarantees that the hardware
+   * gives us with the "Accesses UAV" bit set for at least one shader stage
+   * and the "UAV coherency required" bit set on the 3DPRIMITIVE command 
are
+   * redundant within the current image, atomic counter and SSBO GL APIs,
+   * which all have very loose ordering and coherency requirements and
+   * generally rely on the application to insert explicit barriers when a
+   * shader invocation is expected to see the memory writes performed by 
the
+   * invocations of some previous primitive.  Regardless of the value of
+   * "UAV coherency required", the "Accesses UAV" bits will implicitly 
cause
+   * an in most cases useless DC flush when the lowermost stage with the 
bit
+   * set finishes execution.
+   *
+   * It would be nice to disable it, but in some cases we can't because on
+   * Gen8+ it also has an influence on rasterization via the PS UAV-only
+   * signal (which could be set independently from the coherency mechanism
+   * in the 3DSTATE_WM command on Gen7), and because in some cases it will
+   * determine whether the hardware skips execution of the fragment shader
+   * or not via the ThreadDispatchEnable signal.  However if we know that
+   * GEN8_PS_BLEND_HAS_WRITEABLE_RT is going to be set and
+   * GEN8_PSX_PIXEL_SHADER_NO_RT_WRITE is not set it shouldn't make any
+   * difference so we may just disable it here.
+   *
+   * Gen8 hardware tries to compute ThreadDispatchEnable for us but doesn't
+   * take into account KillPixels when no depth or stencil writes are
+   * enabled. In order for occlusion queries to work correctly with no
+   * attachments, we need to force-enable here.
+   */
+  if ((wm_prog_data->has_side_effects || wm_prog_data->uses_kill) &&
+  !has_color_buffer_write_enabled(pipeline, blend))
+ ps.PixelShaderHasUAV = true;
+
   ps.PixelShaderComputesStencil = wm_prog_data->computed_stencil;
   ps.PixelShaderPullsBary= wm_prog_data->pulls_bary;
 
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v1] anv/skylake: disable ForceThreadDispatchEnable

2018-09-19 Thread Sergii Romantsov
Probably there should be some much more complex conditions for doing that,
but as initial solution...

On Wed, Sep 19, 2018 at 6:55 PM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:

> On Skylake enabling of ForceThreadDispatchEnable causes gpu-hang.
>
> CC: Jason Ekstrand 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107941
> Fixes: 79270d2140ec (anv: Stop setting 3DSTATE_PS_EXTRA::
> PixelShaderHasUAV)
> Signed-off-by: Sergii Romantsov 
> ---
>  src/intel/vulkan/genX_pipeline.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_
> pipeline.c
> index 9595a71..bf5150d 100644
> --- a/src/intel/vulkan/genX_pipeline.c
> +++ b/src/intel/vulkan/genX_pipeline.c
> @@ -1462,7 +1462,8 @@ emit_3dstate_wm(struct anv_pipeline *pipeline,
> struct anv_subpass *subpass,
>* is 3DSTATE_PS_EXTRA::PixelShaderHasUAV which causes hangs on
> BDW.
>* Given two bad options, we choose the one which works.
>*/
> - if ((wm_prog_data->has_side_effects || wm_prog_data->uses_kill)
> &&
> + if (!pipeline->device->info.is_skylake &&
> + (wm_prog_data->has_side_effects || wm_prog_data->uses_kill)
> &&
>   !has_color_buffer_write_enabled(pipeline, blend))
>  wm.ForceThreadDispatchEnable = ForceON;
>  #endif
> --
> 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


[Mesa-dev] [PATCH v1] anv/skylake: disable ForceThreadDispatchEnable

2018-09-19 Thread Sergii Romantsov
On Skylake enabling of ForceThreadDispatchEnable causes gpu-hang.

CC: Jason Ekstrand 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107941
Fixes: 79270d2140ec (anv: Stop setting 3DSTATE_PS_EXTRA::PixelShaderHasUAV)
Signed-off-by: Sergii Romantsov 
---
 src/intel/vulkan/genX_pipeline.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 9595a71..bf5150d 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -1462,7 +1462,8 @@ emit_3dstate_wm(struct anv_pipeline *pipeline, struct 
anv_subpass *subpass,
   * is 3DSTATE_PS_EXTRA::PixelShaderHasUAV which causes hangs on BDW.
   * Given two bad options, we choose the one which works.
   */
- if ((wm_prog_data->has_side_effects || wm_prog_data->uses_kill) &&
+ if (!pipeline->device->info.is_skylake &&
+ (wm_prog_data->has_side_effects || wm_prog_data->uses_kill) &&
  !has_color_buffer_write_enabled(pipeline, blend))
 wm.ForceThreadDispatchEnable = ForceON;
 #endif
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v2] mesa: rotation of 0-vector

2018-09-18 Thread Sergii Romantsov
>
> Isn't x guaranteed to be 0.0F here?

Yes, it will 0.0f but its not used in any computation anywhere. So new
'else'-block should be treated as (1,0,0) on input - its optimized
computation of rotation only by x.

On Tue, Sep 18, 2018 at 5:56 PM, Gustaw Smolarczyk 
wrote:

> wt., 18 wrz 2018 o 15:59 Sergii Romantsov 
> napisał(a):
> >
> > Specification doesn't define behaviour for rotation of 0-vector.
> > Windows and Nvidia drivers have a workaround for that.
> > For compatibility proposed that for 0-vector a rotation will be
> > done around x-axis.
> >
> > -v2: logic moved to _math_matrix_rotate
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100960
> > Signed-off-by: Sergii Romantsov 
> > ---
> >  src/mesa/math/m_matrix.c | 19 +++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
> > index 57a4953..2b3adb3 100644
> > --- a/src/mesa/math/m_matrix.c
> > +++ b/src/mesa/math/m_matrix.c
> > @@ -824,6 +824,25 @@ _math_matrix_rotate( GLmatrix *mat,
> > M(1,0) = s;
> >  }
> >   }
> > + else {
> > +/* https://bugs.freedesktop.org/show_bug.cgi?id=100960
> > + * https://github.com/KhronosGroup/OpenGL-API/issues/41
> > + * So that is kind of workaround for empty-vectors to have
> > + * compatibility with Windows and Nvidia drivers.
> > + */
> > +optimized = GL_TRUE;
> > +/* rotate only around x-axis */
> > +M(1,1) = c;
> > +M(2,2) = c;
> > +if (x < 0.0F) {
>
> Isn't x guaranteed to be 0.0F here? And I think you wanted to treat it
> as 1.0F in that case, so that (0, 0, 0) becomes (1, 0, 0).
>
> Regards,
> Gustaw Smolarczyk
>
> > +   M(1,2) = s;
> > +   M(2,1) = -s;
> > +}
> > +else {
> > +   M(1,2) = -s;
> > +   M(2,1) = s;
> > +}
> > + }
> >}
> >else if (z == 0.0F) {
> >   optimized = GL_TRUE;
> > --
> > 2.7.4
> >
> > _______
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



-- 
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 v2] mesa: rotation of 0-vector

2018-09-18 Thread Sergii Romantsov
Uploaded new version.
Seems that waiting for any response on
https://github.com/KhronosGroup/OpenGL-API/issues/41 may take much more
time

On Tue, Sep 18, 2018 at 4:57 PM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:

> Specification doesn't define behaviour for rotation of 0-vector.
> Windows and Nvidia drivers have a workaround for that.
> For compatibility proposed that for 0-vector a rotation will be
> done around x-axis.
>
> -v2: logic moved to _math_matrix_rotate
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100960
> Signed-off-by: Sergii Romantsov 
> ---
>  src/mesa/math/m_matrix.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
> index 57a4953..2b3adb3 100644
> --- a/src/mesa/math/m_matrix.c
> +++ b/src/mesa/math/m_matrix.c
> @@ -824,6 +824,25 @@ _math_matrix_rotate( GLmatrix *mat,
> M(1,0) = s;
>  }
>   }
> + else {
> +/* https://bugs.freedesktop.org/show_bug.cgi?id=100960
> + * https://github.com/KhronosGroup/OpenGL-API/issues/41
> + * So that is kind of workaround for empty-vectors to have
> + * compatibility with Windows and Nvidia drivers.
> + */
> +optimized = GL_TRUE;
> +/* rotate only around x-axis */
> +M(1,1) = c;
> +M(2,2) = c;
> +if (x < 0.0F) {
> +   M(1,2) = s;
> +   M(2,1) = -s;
> +}
> +else {
> +   M(1,2) = -s;
> +   M(2,1) = s;
> +}
> + }
>}
>else if (z == 0.0F) {
>   optimized = GL_TRUE;
> --
> 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


[Mesa-dev] [PATCH v2] mesa: rotation of 0-vector

2018-09-18 Thread Sergii Romantsov
Specification doesn't define behaviour for rotation of 0-vector.
Windows and Nvidia drivers have a workaround for that.
For compatibility proposed that for 0-vector a rotation will be
done around x-axis.

-v2: logic moved to _math_matrix_rotate

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100960
Signed-off-by: Sergii Romantsov 
---
 src/mesa/math/m_matrix.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
index 57a4953..2b3adb3 100644
--- a/src/mesa/math/m_matrix.c
+++ b/src/mesa/math/m_matrix.c
@@ -824,6 +824,25 @@ _math_matrix_rotate( GLmatrix *mat,
M(1,0) = s;
 }
  }
+ else {
+/* https://bugs.freedesktop.org/show_bug.cgi?id=100960
+ * https://github.com/KhronosGroup/OpenGL-API/issues/41
+ * So that is kind of workaround for empty-vectors to have
+ * compatibility with Windows and Nvidia drivers.
+ */
+optimized = GL_TRUE;
+/* rotate only around x-axis */
+M(1,1) = c;
+M(2,2) = c;
+if (x < 0.0F) {
+   M(1,2) = s;
+   M(2,1) = -s;
+}
+else {
+   M(1,2) = -s;
+   M(2,1) = s;
+}
+ }
   }
   else if (z == 0.0F) {
  optimized = GL_TRUE;
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v1] autotools: multiple definitions for libmesagallium

2018-09-18 Thread Sergii Romantsov
Hello, Eric.
>
> Sergii, do you guys still use autotools, or did you see that in some test
> build that uses autotools just to cover everything?

Yes, we are still using autotools sometimes (and meson also). And issue was
reported by not our guy. So looks like we are not alone with autotools...

On Mon, Sep 17, 2018 at 7:53 PM, Eric Engestrom  wrote:

>
>
> On September 17, 2018 4:16:12 PM UTC, Dylan Baker 
> wrote:
> > I'm not crazy about this solution, it seems more like papering over a
> > bug than
> > fixing the bug. I'm really curious why we can reproduce this in
> > autotools but
> > not meson as well.
>
> Yeah, I have to agree with Dylan there, but then again I'm not sure anyone
> cares about autotools anymore, so meh… why not.
>
> Sergii, do you guys still use autotools, or did you see that in some test
> build that uses autotools just to cover everything?
>
> >
> > Dylan
> >
> > Quoting Sergii Romantsov (2018-09-17 03:23:04)
> > > Error of multiple definitions for libmesagallium and libmesautil may
> > be
> > > fixed by linker-option allow-multiple-definition
> > >
> > > CC: Dylan Baker 
> > > Fixes: 8396043f304b (Replace uses of _mesa_bitcount with
> > util_bitcount)
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107923
> > > Signed-off-by: Sergii Romantsov 
> > > ---
> > >  src/gallium/targets/libgl-xlib/Makefile.am | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/src/gallium/targets/libgl-xlib/Makefile.am
> > b/src/gallium/targets/libgl-xlib/Makefile.am
> > > index dc7c6ed..094d4be 100644
> > > --- a/src/gallium/targets/libgl-xlib/Makefile.am
> > > +++ b/src/gallium/targets/libgl-xlib/Makefile.am
> > > @@ -46,6 +46,7 @@ lib@GL_LIB@_la_SOURCES = xlib.c
> > >  lib@GL_LIB@_la_LDFLAGS = \
> > > -no-undefined \
> > > -version-number 1:5:0 \
> > > +   -Wl,--allow-multiple-definition \
> > >     $(BSYMBOLIC) \
> > > $(GC_SECTIONS) \
> > > $(LD_NO_UNDEFINED)
> > > --
> > > 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


[Mesa-dev] [PATCH v1] autotools: multiple definitions for libmesagallium

2018-09-17 Thread Sergii Romantsov
Error of multiple definitions for libmesagallium and libmesautil may be
fixed by linker-option allow-multiple-definition

CC: Dylan Baker 
Fixes: 8396043f304b (Replace uses of _mesa_bitcount with util_bitcount)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107923
Signed-off-by: Sergii Romantsov 
---
 src/gallium/targets/libgl-xlib/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/targets/libgl-xlib/Makefile.am 
b/src/gallium/targets/libgl-xlib/Makefile.am
index dc7c6ed..094d4be 100644
--- a/src/gallium/targets/libgl-xlib/Makefile.am
+++ b/src/gallium/targets/libgl-xlib/Makefile.am
@@ -46,6 +46,7 @@ lib@GL_LIB@_la_SOURCES = xlib.c
 lib@GL_LIB@_la_LDFLAGS = \
-no-undefined \
-version-number 1:5:0 \
+   -Wl,--allow-multiple-definition \
$(BSYMBOLIC) \
$(GC_SECTIONS) \
$(LD_NO_UNDEFINED)
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v1] glsl: missed error_emitted for do_assignment

2018-09-14 Thread Sergii Romantsov
Seems that patch is simplified version of already exist one:
https://patchwork.freedesktop.org/series/48256/

On Fri, Sep 14, 2018 at 4:39 PM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:

> During do_assignment a validation of rhs may fail.
> Because of lack error_emitted an error_value may not be generated.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107547
> Signed-off-by: Sergii Romantsov 
> ---
>  src/compiler/glsl/ast_to_hir.cpp | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_
> hir.cpp
> index 5d3f10b..da1654b 100644
> --- a/src/compiler/glsl/ast_to_hir.cpp
> +++ b/src/compiler/glsl/ast_to_hir.cpp
> @@ -1013,6 +1013,8 @@ do_assignment(exec_list *instructions, struct
> _mesa_glsl_parse_state *state,
>   mark_whole_array_access(lhs);
>}
> }
> +   else
> +  error_emitted = true;
>
> /* Most callers of do_assignment (assign, add_assign, pre_inc/dec,
>  * but not post_inc) need the converted assigned value as an rvalue
> --
> 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


[Mesa-dev] [PATCH v1] glsl: missed error_emitted for do_assignment

2018-09-14 Thread Sergii Romantsov
During do_assignment a validation of rhs may fail.
Because of lack error_emitted an error_value may not be generated.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107547
Signed-off-by: Sergii Romantsov 
---
 src/compiler/glsl/ast_to_hir.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 5d3f10b..da1654b 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -1013,6 +1013,8 @@ do_assignment(exec_list *instructions, struct 
_mesa_glsl_parse_state *state,
  mark_whole_array_access(lhs);
   }
}
+   else
+  error_emitted = true;
 
/* Most callers of do_assignment (assign, add_assign, pre_inc/dec,
 * but not post_inc) need the converted assigned value as an rvalue
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v1] mesa: rotation of 0-vector

2018-09-13 Thread Sergii Romantsov
Hello,
thanks for looking on that.
Will update after any answer on
https://github.com/KhronosGroup/OpenGL-API/issues/41
Hope that is correct place for such things.

On Thu, Sep 13, 2018 at 4:57 AM, Timothy Arceri 
wrote:

> On 13/9/18 12:44 am, Brian Paul wrote:
>
>> On 09/12/2018 07:30 AM, Sergii Romantsov wrote:
>>
>>> Specification doesn't define behaviour for rotation of 0-vector.
>>> But khronos.org says that vector has to be normalized.
>>> As workaround assumed that for 0-vector x-position will be
>>> defined as 1.0f.
>>>
>>> Bugzilla: https://na01.safelinks.protection.outlook.com/?url=https%3A%
>>> 2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D100960&
>>> amp;data=02%7C01%7Cbrianp%40vmware.com%7Cfde139ec0f4448b
>>> 8090d08d618b3f0ce%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%
>>> 7C0%7C636723558454036605sdata=IAlt%2FkpHJyb5JHRYaOTfhf5
>>> v9V7Xl5iQBNBdqe2PHQs%3Dreserved=0
>>> Signed-off-by: Sergii Romantsov 
>>> ---
>>>   src/mesa/main/matrix.c | 5 +
>>>   1 file changed, 5 insertions(+)
>>>
>>> diff --git a/src/mesa/main/matrix.c b/src/mesa/main/matrix.c
>>> index 8065a83..631b203 100644
>>> --- a/src/mesa/main/matrix.c
>>> +++ b/src/mesa/main/matrix.c
>>> @@ -415,6 +415,11 @@ _mesa_Rotatef( GLfloat angle, GLfloat x, GLfloat y,
>>> GLfloat z )
>>>  FLUSH_VERTICES(ctx, 0);
>>>  if (angle != 0.0F) {
>>> +  /* khronos.org says that ||( x,y,z )|| = 1 (if not, the GL will
>>> normalize this vector)
>>> +  * So that is kind of workaround for empty-vectors.
>>> +  * */
>>>
>>
>> Comment style should be:
>>
>> /* khronos.org says ...
>>   * So that ...
>>   */
>>
>
> Thanks for looking into the bug. However the api docs shouldn't be quoted.
> They are unversioned, are at times wrong and should not be used as a
> definative source when making changes or implementing features. Please only
> quote and use the spec for such things.
>
>
>> You might also note the bug number in the code in case anyone wonders
>> what app would hit this.
>>
>>
>> +  if (x == 0 && y == 0 && z == 0)
>>> + x = 1.0f;
>>>
>>
> If the spec doesn't define behavior we should probably file a bug against
> the compatibility spec rather than assuming things. Clearly recording the
> problem (including applications it appears in), specifying the current
> behaviors in other drivers and proposing updated wording to the spec is
> usually the fastest way to resolve this type of thing.
>
> Also if this were the correct change it should be made in
> _math_matrix_rotate() this change will make some of the existing code there
> unreachable.
>
> Finally it would be a good idea to have a piglit test for this once any
> spec clarification is done.
>
>
>
>> You may as well use 0.0f in the test too, just to be sure no silly
>> int/float/double conversion happens.
>>
>> _math_matrix_rotate( ctx->CurrentStack->Top, angle, x, y, z);
>>> ctx->NewState |= ctx->CurrentStack->DirtyFlag;
>>>  }
>>>
>>>
>> -Brian
>>
>> ___
>> 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
>



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


[Mesa-dev] [PATCH v1] mesa: rotation of 0-vector

2018-09-12 Thread Sergii Romantsov
Specification doesn't define behaviour for rotation of 0-vector.
But khronos.org says that vector has to be normalized.
As workaround assumed that for 0-vector x-position will be
defined as 1.0f.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100960
Signed-off-by: Sergii Romantsov 
---
 src/mesa/main/matrix.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/main/matrix.c b/src/mesa/main/matrix.c
index 8065a83..631b203 100644
--- a/src/mesa/main/matrix.c
+++ b/src/mesa/main/matrix.c
@@ -415,6 +415,11 @@ _mesa_Rotatef( GLfloat angle, GLfloat x, GLfloat y, 
GLfloat z )
 
FLUSH_VERTICES(ctx, 0);
if (angle != 0.0F) {
+  /* khronos.org says that ||( x,y,z )|| = 1 (if not, the GL will 
normalize this vector)
+  * So that is kind of workaround for empty-vectors.
+  * */
+  if (x == 0 && y == 0 && z == 0)
+ x = 1.0f;
   _math_matrix_rotate( ctx->CurrentStack->Top, angle, x, y, z);
   ctx->NewState |= ctx->CurrentStack->DirtyFlag;
}
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v3] mesa/meson: 32bit xmlconfig linkage

2018-09-10 Thread Sergii Romantsov
Hello,
just reminder for case: don't have push-rights...

On Fri, Sep 7, 2018 at 8:05 PM, Dylan Baker  wrote:

> Quoting Sergii Romantsov (2018-09-07 02:43:41)
> > Building of 32bit mesa with meson causes linkage issue:
> > "undefined reference to `util_get_process_name'"
> > Fixed by adding link-with mesa_util for xmlconfig primary.
> >
> > v2: Removed '[]', commit message corrected.
> >
> > v3: Reverted changes in gbm and glx libraries.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107843
> > Fixes: 2e1e6511f76370870b5cd "util: extract get_process_name from
> xmlconfig.c"
> > Cc: Marek Ol\u0161ák 
> > Cc: Dylan Baker 
> > Signed-off-by: Sergii Romantsov 
> > Reviewed-by: Eric Engestrom 
> > ---
> >  src/util/meson.build | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/src/util/meson.build b/src/util/meson.build
> > index a4ff0b9..e3d96b6 100644
> > --- a/src/util/meson.build
> > +++ b/src/util/meson.build
> > @@ -117,6 +117,7 @@ libxmlconfig = static_library(
> >'xmlconfig',
> >files_xmlconfig,
> >include_directories : inc_common,
> > +  link_with : libmesa_util,
> >dependencies : [dep_expat, dep_m],
> >c_args : [
> >  c_msvc_compat_args, c_vis_args,
> > --
> > 2.7.4
> >
>
> Reviewed-by: Dylan Baker 
>
> ___
> 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 v5] intel: compiler option msse2 and mstackrealign

2018-09-07 Thread Sergii Romantsov
Oh, thanks.
So maybe that one https://patchwork.freedesktop.org/patch/247572/ one more
time :)?
And this https://patchwork.freedesktop.org/patch/247729/ ?

On Fri, Sep 7, 2018 at 3:46 PM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> It's good, pushed.
>
> On 07/09/2018 10:57, Lionel Landwerlin wrote:
>
> There was a test that failed, but I think it might be flakyness.
> I'm retrying one more time. Will get back to you in ~1h.
>
> -
> Lionel
>
> On 07/09/2018 10:32, Sergii Romantsov wrote:
>
> Hello, Lionel.
> Any regression with CI?
>
> On Thu, Sep 6, 2018 at 12:33 PM, Lionel Landwerlin <
> lionel.g.landwer...@intel.com> wrote:
>
>> Giving it a run through CI and I'll push after.
>>
>> Thanks!
>>
>>
>> On 06/09/2018 09:07, Sergii Romantsov wrote:
>>
>>> Seems in case of 32-bit library, usage of msse2 makes
>>> some stack corruption or incorrect instructions.
>>> Usage with mstackrealign fixes that case.
>>>
>>> v2: Fixed meson.
>>>
>>> v3: Definition of c_sse2_args moved on the top (L.Landwerlin).
>>>  Added mstackrealign for Android's mks where msee4.1 is used.
>>>
>>> v4: Added for Vulkan also.
>>>
>>> v5: Commit message correction.
>>>
>>> CC: 
>>> Fixes: 6b05c080f202 (i965: Compile with -msse3)
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107779
>>> Signed-off-by: Sergii Romantsov 
>>> Reviewed-by: Dylan Baker 
>>> Reviewed-by: Emil Velikov 
>>> Reviewed-by: Lionel Landwerlin 
>>> ---
>>>   src/intel/Makefile.vulkan.am  | 2 +-
>>>   src/intel/meson.build | 1 +
>>>   src/intel/vulkan/meson.build  | 4 ++--
>>>   src/mesa/Android.libmesa_dricore.mk   | 2 +-
>>>   src/mesa/Android.libmesa_sse41.mk | 2 +-
>>>   src/mesa/drivers/dri/i965/Makefile.am | 2 +-
>>>   src/mesa/drivers/dri/i965/meson.build | 6 +++---
>>>   7 files changed, 10 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
>>> index 9555d98..d511263 100644
>>> --- a/src/intel/Makefile.vulkan.am
>>> +++ b/src/intel/Makefile.vulkan.am
>>> @@ -104,7 +104,7 @@ noinst_LTLIBRARIES += $(VULKAN_PER_GEN_LIBS)
>>> VULKAN_CFLAGS = \
>>> $(AM_CFLAGS) \
>>> -   -msse2
>>> +   -msse2 -mstackrealign
>>> VULKAN_CPPFLAGS = \
>>> -I$(top_srcdir)/src/compiler \
>>> diff --git a/src/intel/meson.build b/src/intel/meson.build
>>> index b3dcbdc..3c57e79 100644
>>> --- a/src/intel/meson.build
>>> +++ b/src/intel/meson.build
>>> @@ -18,6 +18,7 @@
>>>   # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>>> DEALINGS IN THE
>>>   # SOFTWARE.
>>>   +c_sse2_args = ['-msse2', '-mstackrealign']
>>>   inc_intel = include_directories('.')
>>> subdir('blorp')
>>> diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
>>> index e11bcb0..f1beb1d 100644
>>> --- a/src/intel/vulkan/meson.build
>>> +++ b/src/intel/vulkan/meson.build
>>> @@ -102,7 +102,7 @@ foreach g : [['70', ['gen7_cmd_buffer.c']], ['75',
>>> ['gen7_cmd_buffer.c']],
>>> inc_vulkan_wsi,
>>>   ],
>>>   c_args : [
>>> -  c_vis_args, no_override_init_args, '-msse2',
>>> +  c_vis_args, no_override_init_args, c_sse2_args,
>>> '-DGEN_VERSIONx10=@0@'.format(_gen),
>>>   ],
>>>   dependencies : [dep_libdrm, dep_valgrind, idep_nir_headers],
>>> @@ -146,7 +146,7 @@ anv_deps = [
>>>   anv_flags = [
>>> c_vis_args,
>>> no_override_init_args,
>>> -  '-msse2',
>>> +  c_sse2_args,
>>>   ]
>>> if with_platform_x11
>>> diff --git a/src/mesa/Android.libmesa_dricore.mk b/src/mesa/
>>> Android.libmesa_dricore.mk
>>> index 34fd858..7921177 100644
>>> --- a/src/mesa/Android.libmesa_dricore.mk
>>> +++ b/src/mesa/Android.libmesa_dricore.mk
>>> @@ -49,7 +49,7 @@ ifeq ($(ARCH_X86_HAVE_SSE4_1),true)
>>>   LOCAL_WHOLE_STATIC_LIBRARIES := \
>>> libmesa_sse41
>>>   LOCAL_CFLAGS := \
>>> -   -msse4.1 \
>>> +   -msse4.1 -mstackrealign \
>>>  -DUSE_SSE41
>>>   endif
>>>   diff --git a/src/mesa/Android.libmesa_sse41.mk b/src/mesa/
>>> Android.libmesa_sse41.mk
>>> index da

[Mesa-dev] [PATCH v3] mesa/meson: 32bit xmlconfig linkage

2018-09-07 Thread Sergii Romantsov
Building of 32bit mesa with meson causes linkage issue:
"undefined reference to `util_get_process_name'"
Fixed by adding link-with mesa_util for xmlconfig primary.

v2: Removed '[]', commit message corrected.

v3: Reverted changes in gbm and glx libraries.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107843
Fixes: 2e1e6511f76370870b5cd "util: extract get_process_name from xmlconfig.c"
Cc: Marek Olšák 
Cc: Dylan Baker 
Signed-off-by: Sergii Romantsov 
Reviewed-by: Eric Engestrom 
---
 src/util/meson.build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/util/meson.build b/src/util/meson.build
index a4ff0b9..e3d96b6 100644
--- a/src/util/meson.build
+++ b/src/util/meson.build
@@ -117,6 +117,7 @@ libxmlconfig = static_library(
   'xmlconfig',
   files_xmlconfig,
   include_directories : inc_common,
+  link_with : libmesa_util,
   dependencies : [dep_expat, dep_m],
   c_args : [
 c_msvc_compat_args, c_vis_args,
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v5] intel: compiler option msse2 and mstackrealign

2018-09-07 Thread Sergii Romantsov
Hello, Lionel.
Any regression with CI?

On Thu, Sep 6, 2018 at 12:33 PM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Giving it a run through CI and I'll push after.
>
> Thanks!
>
>
> On 06/09/2018 09:07, Sergii Romantsov wrote:
>
>> Seems in case of 32-bit library, usage of msse2 makes
>> some stack corruption or incorrect instructions.
>> Usage with mstackrealign fixes that case.
>>
>> v2: Fixed meson.
>>
>> v3: Definition of c_sse2_args moved on the top (L.Landwerlin).
>>  Added mstackrealign for Android's mks where msee4.1 is used.
>>
>> v4: Added for Vulkan also.
>>
>> v5: Commit message correction.
>>
>> CC: 
>> Fixes: 6b05c080f202 (i965: Compile with -msse3)
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107779
>> Signed-off-by: Sergii Romantsov 
>> Reviewed-by: Dylan Baker 
>> Reviewed-by: Emil Velikov 
>> Reviewed-by: Lionel Landwerlin 
>> ---
>>   src/intel/Makefile.vulkan.am  | 2 +-
>>   src/intel/meson.build | 1 +
>>   src/intel/vulkan/meson.build  | 4 ++--
>>   src/mesa/Android.libmesa_dricore.mk   | 2 +-
>>   src/mesa/Android.libmesa_sse41.mk | 2 +-
>>   src/mesa/drivers/dri/i965/Makefile.am | 2 +-
>>   src/mesa/drivers/dri/i965/meson.build | 6 +++---
>>   7 files changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
>> index 9555d98..d511263 100644
>> --- a/src/intel/Makefile.vulkan.am
>> +++ b/src/intel/Makefile.vulkan.am
>> @@ -104,7 +104,7 @@ noinst_LTLIBRARIES += $(VULKAN_PER_GEN_LIBS)
>> VULKAN_CFLAGS = \
>> $(AM_CFLAGS) \
>> -   -msse2
>> +   -msse2 -mstackrealign
>> VULKAN_CPPFLAGS = \
>> -I$(top_srcdir)/src/compiler \
>> diff --git a/src/intel/meson.build b/src/intel/meson.build
>> index b3dcbdc..3c57e79 100644
>> --- a/src/intel/meson.build
>> +++ b/src/intel/meson.build
>> @@ -18,6 +18,7 @@
>>   # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> DEALINGS IN THE
>>   # SOFTWARE.
>>   +c_sse2_args = ['-msse2', '-mstackrealign']
>>   inc_intel = include_directories('.')
>> subdir('blorp')
>> diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
>> index e11bcb0..f1beb1d 100644
>> --- a/src/intel/vulkan/meson.build
>> +++ b/src/intel/vulkan/meson.build
>> @@ -102,7 +102,7 @@ foreach g : [['70', ['gen7_cmd_buffer.c']], ['75',
>> ['gen7_cmd_buffer.c']],
>> inc_vulkan_wsi,
>>   ],
>>   c_args : [
>> -  c_vis_args, no_override_init_args, '-msse2',
>> +  c_vis_args, no_override_init_args, c_sse2_args,
>> '-DGEN_VERSIONx10=@0@'.format(_gen),
>>   ],
>>   dependencies : [dep_libdrm, dep_valgrind, idep_nir_headers],
>> @@ -146,7 +146,7 @@ anv_deps = [
>>   anv_flags = [
>> c_vis_args,
>> no_override_init_args,
>> -  '-msse2',
>> +  c_sse2_args,
>>   ]
>> if with_platform_x11
>> diff --git a/src/mesa/Android.libmesa_dricore.mk b/src/mesa/
>> Android.libmesa_dricore.mk
>> index 34fd858..7921177 100644
>> --- a/src/mesa/Android.libmesa_dricore.mk
>> +++ b/src/mesa/Android.libmesa_dricore.mk
>> @@ -49,7 +49,7 @@ ifeq ($(ARCH_X86_HAVE_SSE4_1),true)
>>   LOCAL_WHOLE_STATIC_LIBRARIES := \
>> libmesa_sse41
>>   LOCAL_CFLAGS := \
>> -   -msse4.1 \
>> +   -msse4.1 -mstackrealign \
>>  -DUSE_SSE41
>>   endif
>>   diff --git a/src/mesa/Android.libmesa_sse41.mk b/src/mesa/
>> Android.libmesa_sse41.mk
>> index da40f43..de19a1f 100644
>> --- a/src/mesa/Android.libmesa_sse41.mk
>> +++ b/src/mesa/Android.libmesa_sse41.mk
>> @@ -34,7 +34,7 @@ LOCAL_SRC_FILES += \
>> $(X86_SSE41_FILES)
>> LOCAL_CFLAGS := \
>> -   -msse4.1
>> +   -msse4.1 -mstackrealign
>> LOCAL_C_INCLUDES := \
>> $(MESA_TOP)/src/mapi \
>> diff --git a/src/mesa/drivers/dri/i965/Makefile.am
>> b/src/mesa/drivers/dri/i965/Makefile.am
>> index 889d4c6..0afa7a2 100644
>> --- a/src/mesa/drivers/dri/i965/Makefile.am
>> +++ b/src/mesa/drivers/dri/i965/Makefile.am
>> @@ -44,7 +44,7 @@ AM_CFLAGS = \
>> $(WNO_OVERRIDE_INIT) \
>> $(LIBDRM_CFLAGS) \
>> $(VALGRIND_CFLAGS) \
>> -   -msse2
>> +   -msse2 -mstackrealign
>> AM_CXXFLAGS = $(AM_CFLAGS)
>>   diff --git a/src/mesa/drivers/dri/i965/meson.build
>&g

Re: [Mesa-dev] [PATCH v1] mesa/meson: 32bit xmlconfig linkage

2018-09-07 Thread Sergii Romantsov
Hello, Eric.

 but we don't want to remove libmesa_util from the other libs


Does it mean to revert src/gbm/meson.build and src/glx/meson.build ?

On Thu, Sep 6, 2018 at 8:30 PM, Eric Engestrom 
wrote:

> On Thursday, 2018-09-06 17:38:36 +0300, Sergii Romantsov wrote:
> > Building of 32bit mesa with meson causes linkage issue:
> > "undefined reference to `util_get_process_name'"
> > Fixed by adding link-with mesa_util for xmlconfig primary.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107843
> > Signed-off-by: Sergii Romantsov 
> > ---
> >  src/gbm/meson.build  | 2 +-
> >  src/glx/meson.build  | 2 +-
> >  src/util/meson.build | 1 +
> >  3 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/gbm/meson.build b/src/gbm/meson.build
> > index 2e9d380..6ca8b38 100644
> > --- a/src/gbm/meson.build
> > +++ b/src/gbm/meson.build
> > @@ -51,7 +51,7 @@ libgbm = shared_library(
> >include_directories : incs_gbm,
> >c_args : [c_vis_args, args_gbm],
> >link_args : [ld_args_gc_sections],
> > -  link_with : [libloader, libmesa_util, libxmlconfig],
> > +  link_with : [libloader, libxmlconfig],
> >dependencies : [deps_gbm, dep_dl, dep_thread],
> >version : '1.0.0',
> >install : true,
> > diff --git a/src/glx/meson.build b/src/glx/meson.build
> > index dd8ba60..5a97d3e 100644
> > --- a/src/glx/meson.build
> > +++ b/src/glx/meson.build
> > @@ -150,7 +150,7 @@ libglx = static_library(
> >  '-DGL_LIB_NAME="lib@0@.so.@1@"'.format(gl_lib_name,
> gl_lib_version.split('.')[0]),
> >],
> >link_with : [
> > -libloader, libloader_dri3_helper, libmesa_util, libxmlconfig,
> > +libloader, libloader_dri3_helper, libxmlconfig,
> >  extra_libs_libglx,
> >],
> >dependencies : [dep_libdrm, dep_dri2proto, dep_glproto, dep_x11,
> dep_glvnd],
> > diff --git a/src/util/meson.build b/src/util/meson.build
> > index a4ff0b9..c5714a7 100644
> > --- a/src/util/meson.build
> > +++ b/src/util/meson.build
> > @@ -117,6 +117,7 @@ libxmlconfig = static_library(
> >'xmlconfig',
> >files_xmlconfig,
> >include_directories : inc_common,
> > +  link_with : [libmesa_util],
>
> This line is indeed necessary (although the [] are not), but we don't
> want to remove libmesa_util from the other libs.
>
> When you send a v2, can you please add:
>
> Fixes: 2e1e6511f76370870b5cd "util: extract get_process_name from
> xmlconfig.c"
> Cc: Marek Olšák 
> Cc: Dylan Baker 
> Reviewed-by: Eric Engestrom 
>
> Thanks for the patch!
>
> >dependencies : [dep_expat, dep_m],
> >c_args : [
> >  c_msvc_compat_args, c_vis_args,
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



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


[Mesa-dev] [PATCH v2] mesa/meson: 32bit xmlconfig linkage

2018-09-07 Thread Sergii Romantsov
Building of 32bit mesa with meson causes linkage issue:
"undefined reference to `util_get_process_name'"
Fixed by adding link-with mesa_util for xmlconfig primary.

v2: Removed '[]', commit message corrected.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107843
Fixes: 2e1e6511f76370870b5cd "util: extract get_process_name from xmlconfig.c"
Cc: Marek Olšák 
Cc: Dylan Baker 
Signed-off-by: Sergii Romantsov 
Reviewed-by: Eric Engestrom 
---
 src/gbm/meson.build  | 2 +-
 src/glx/meson.build  | 2 +-
 src/util/meson.build | 1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/gbm/meson.build b/src/gbm/meson.build
index 2e9d380..6ca8b38 100644
--- a/src/gbm/meson.build
+++ b/src/gbm/meson.build
@@ -51,7 +51,7 @@ libgbm = shared_library(
   include_directories : incs_gbm,
   c_args : [c_vis_args, args_gbm],
   link_args : [ld_args_gc_sections],
-  link_with : [libloader, libmesa_util, libxmlconfig],
+  link_with : [libloader, libxmlconfig],
   dependencies : [deps_gbm, dep_dl, dep_thread],
   version : '1.0.0',
   install : true,
diff --git a/src/glx/meson.build b/src/glx/meson.build
index dd8ba60..5a97d3e 100644
--- a/src/glx/meson.build
+++ b/src/glx/meson.build
@@ -150,7 +150,7 @@ libglx = static_library(
 '-DGL_LIB_NAME="lib@0@.so.@1@"'.format(gl_lib_name, 
gl_lib_version.split('.')[0]),
   ],
   link_with : [
-libloader, libloader_dri3_helper, libmesa_util, libxmlconfig,
+libloader, libloader_dri3_helper, libxmlconfig,
 extra_libs_libglx,
   ],
   dependencies : [dep_libdrm, dep_dri2proto, dep_glproto, dep_x11, dep_glvnd],
diff --git a/src/util/meson.build b/src/util/meson.build
index a4ff0b9..e3d96b6 100644
--- a/src/util/meson.build
+++ b/src/util/meson.build
@@ -117,6 +117,7 @@ libxmlconfig = static_library(
   'xmlconfig',
   files_xmlconfig,
   include_directories : inc_common,
+  link_with : libmesa_util,
   dependencies : [dep_expat, dep_m],
   c_args : [
 c_msvc_compat_args, c_vis_args,
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v1] mesa/meson: 32bit xmlconfig linkage

2018-09-06 Thread Sergii Romantsov
Probably, here is a sense to remove constructions similar to 'libmesa_util,
libxmlconfig' and left only libxmlconfig for the rest of meson.build files.
Any doubts?

On Thu, Sep 6, 2018 at 5:38 PM, Sergii Romantsov  wrote:

> Building of 32bit mesa with meson causes linkage issue:
> "undefined reference to `util_get_process_name'"
> Fixed by adding link-with mesa_util for xmlconfig primary.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107843
> Signed-off-by: Sergii Romantsov 
> ---
>  src/gbm/meson.build  | 2 +-
>  src/glx/meson.build  | 2 +-
>  src/util/meson.build | 1 +
>  3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/gbm/meson.build b/src/gbm/meson.build
> index 2e9d380..6ca8b38 100644
> --- a/src/gbm/meson.build
> +++ b/src/gbm/meson.build
> @@ -51,7 +51,7 @@ libgbm = shared_library(
>include_directories : incs_gbm,
>c_args : [c_vis_args, args_gbm],
>link_args : [ld_args_gc_sections],
> -  link_with : [libloader, libmesa_util, libxmlconfig],
> +  link_with : [libloader, libxmlconfig],
>dependencies : [deps_gbm, dep_dl, dep_thread],
>version : '1.0.0',
>install : true,
> diff --git a/src/glx/meson.build b/src/glx/meson.build
> index dd8ba60..5a97d3e 100644
> --- a/src/glx/meson.build
> +++ b/src/glx/meson.build
> @@ -150,7 +150,7 @@ libglx = static_library(
>  '-DGL_LIB_NAME="lib@0@.so.@1@"'.format(gl_lib_name,
> gl_lib_version.split('.')[0]),
>],
>link_with : [
> -libloader, libloader_dri3_helper, libmesa_util, libxmlconfig,
> +libloader, libloader_dri3_helper, libxmlconfig,
>  extra_libs_libglx,
>],
>dependencies : [dep_libdrm, dep_dri2proto, dep_glproto, dep_x11,
> dep_glvnd],
> diff --git a/src/util/meson.build b/src/util/meson.build
> index a4ff0b9..c5714a7 100644
> --- a/src/util/meson.build
> +++ b/src/util/meson.build
> @@ -117,6 +117,7 @@ libxmlconfig = static_library(
>'xmlconfig',
>files_xmlconfig,
>include_directories : inc_common,
> +  link_with : [libmesa_util],
>dependencies : [dep_expat, dep_m],
>c_args : [
>  c_msvc_compat_args, c_vis_args,
> --
> 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


[Mesa-dev] [PATCH v1] mesa/meson: 32bit xmlconfig linkage

2018-09-06 Thread Sergii Romantsov
Building of 32bit mesa with meson causes linkage issue:
"undefined reference to `util_get_process_name'"
Fixed by adding link-with mesa_util for xmlconfig primary.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107843
Signed-off-by: Sergii Romantsov 
---
 src/gbm/meson.build  | 2 +-
 src/glx/meson.build  | 2 +-
 src/util/meson.build | 1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/gbm/meson.build b/src/gbm/meson.build
index 2e9d380..6ca8b38 100644
--- a/src/gbm/meson.build
+++ b/src/gbm/meson.build
@@ -51,7 +51,7 @@ libgbm = shared_library(
   include_directories : incs_gbm,
   c_args : [c_vis_args, args_gbm],
   link_args : [ld_args_gc_sections],
-  link_with : [libloader, libmesa_util, libxmlconfig],
+  link_with : [libloader, libxmlconfig],
   dependencies : [deps_gbm, dep_dl, dep_thread],
   version : '1.0.0',
   install : true,
diff --git a/src/glx/meson.build b/src/glx/meson.build
index dd8ba60..5a97d3e 100644
--- a/src/glx/meson.build
+++ b/src/glx/meson.build
@@ -150,7 +150,7 @@ libglx = static_library(
 '-DGL_LIB_NAME="lib@0@.so.@1@"'.format(gl_lib_name, 
gl_lib_version.split('.')[0]),
   ],
   link_with : [
-libloader, libloader_dri3_helper, libmesa_util, libxmlconfig,
+libloader, libloader_dri3_helper, libxmlconfig,
 extra_libs_libglx,
   ],
   dependencies : [dep_libdrm, dep_dri2proto, dep_glproto, dep_x11, dep_glvnd],
diff --git a/src/util/meson.build b/src/util/meson.build
index a4ff0b9..c5714a7 100644
--- a/src/util/meson.build
+++ b/src/util/meson.build
@@ -117,6 +117,7 @@ libxmlconfig = static_library(
   'xmlconfig',
   files_xmlconfig,
   include_directories : inc_common,
+  link_with : [libmesa_util],
   dependencies : [dep_expat, dep_m],
   c_args : [
 c_msvc_compat_args, c_vis_args,
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v1 2/2] driconf: replaced file with defines

2018-09-06 Thread Sergii Romantsov
Looks like you are right.
After 'git clean' its ok.
Thanks.

On Thu, Sep 6, 2018 at 2:37 PM Eric Engestrom 
wrote:

> On Thursday, 2018-09-06 12:59:48 +0300, Sergii Romantsov wrote:
> > Building of 32bit mesa with meson causes issues:
> > "expected ‘}’ before ‘DRI_CONF_MESA_NO_ERROR’"
> > "expected ‘}’ before
> ‘DRI_CONF_ALLOW_GLSL_CROSS_STAGE_INTERPOLATION_MISMATCH’"
> > "expected ‘}’ before ‘DRI_CONF_ALLOW_RGB10_CONFIGS’"
> > File with defines replaced to correct.
>
> I think this might be caused by autotools leftovers.
> Try doing the same thing in a fresh clone?
>
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107843
> > Signed-off-by: Sergii Romantsov 
> > ---
> >  src/util/xmlpool.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/util/xmlpool.h b/src/util/xmlpool.h
> > index ebd4e7c..f2181ce 100644
> > --- a/src/util/xmlpool.h
> > +++ b/src/util/xmlpool.h
> > @@ -100,6 +100,6 @@
> >   * Predefined option sections and options with multi-lingual
> descriptions
> >   * are now automatically generated.
> >   */
> > -#include "xmlpool/options.h"
> > +#include "util/xmlpool/options.h"
> >
> >  #endif
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v1 1/2] i965/tools: 32bit compilation with meson

2018-09-06 Thread Sergii Romantsov
With -Dtools=all compilation is passed now.
At this moment looking additionally on linkage issue with building, have
solution but would like to find better, so hope will provide additional 3rd
commit today.

On Thu, Sep 6, 2018 at 1:03 PM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Aren't other tools affected as well?
>
> Thanks,
>
> -
> Lionel
>
> On 06/09/2018 10:59, Sergii Romantsov wrote:
>
>> Building of 32bit mesa with meson causes issue:
>> "implicit declaration of function ‘__builtin_ia32_clflush’".
>> Fixed by adding msse2 compilation flag.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107843
>> Fixes: 314879f7fec0 (i965: Fix asynchronous mappings on !LLC platforms.)
>> Signed-off-by: Sergii Romantsov 
>> ---
>>   src/intel/tools/meson.build | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/intel/tools/meson.build b/src/intel/tools/meson.build
>> index 3617478..44d6bdd 100644
>> --- a/src/intel/tools/meson.build
>> +++ b/src/intel/tools/meson.build
>> @@ -90,7 +90,7 @@ libintel_sanitize_gpu = shared_library(
>> dependencies : [dep_dl, dep_thread],
>> include_directories : [inc_common, inc_intel, inc_drm_uapi],
>> link_with : [libintel_common, libmesa_util],
>> -  c_args : [c_vis_args, no_override_init_args],
>> +  c_args : [c_vis_args, no_override_init_args, c_sse2_args],
>> build_by_default : true,
>> install_dir: get_option('libexecdir'),
>> install: true
>>
>
>
> ___
> 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


[Mesa-dev] [PATCH v1 2/2] driconf: replaced file with defines

2018-09-06 Thread Sergii Romantsov
Building of 32bit mesa with meson causes issues:
"expected ‘}’ before ‘DRI_CONF_MESA_NO_ERROR’"
"expected ‘}’ before ‘DRI_CONF_ALLOW_GLSL_CROSS_STAGE_INTERPOLATION_MISMATCH’"
"expected ‘}’ before ‘DRI_CONF_ALLOW_RGB10_CONFIGS’"
File with defines replaced to correct.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107843
Signed-off-by: Sergii Romantsov 
---
 src/util/xmlpool.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/util/xmlpool.h b/src/util/xmlpool.h
index ebd4e7c..f2181ce 100644
--- a/src/util/xmlpool.h
+++ b/src/util/xmlpool.h
@@ -100,6 +100,6 @@
  * Predefined option sections and options with multi-lingual descriptions
  * are now automatically generated.
  */
-#include "xmlpool/options.h"
+#include "util/xmlpool/options.h"
 
 #endif
-- 
2.7.4

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


[Mesa-dev] [PATCH v1 1/2] i965/tools: 32bit compilation with meson

2018-09-06 Thread Sergii Romantsov
Building of 32bit mesa with meson causes issue:
"implicit declaration of function ‘__builtin_ia32_clflush’".
Fixed by adding msse2 compilation flag.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107843
Fixes: 314879f7fec0 (i965: Fix asynchronous mappings on !LLC platforms.)
Signed-off-by: Sergii Romantsov 
---
 src/intel/tools/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/tools/meson.build b/src/intel/tools/meson.build
index 3617478..44d6bdd 100644
--- a/src/intel/tools/meson.build
+++ b/src/intel/tools/meson.build
@@ -90,7 +90,7 @@ libintel_sanitize_gpu = shared_library(
   dependencies : [dep_dl, dep_thread],
   include_directories : [inc_common, inc_intel, inc_drm_uapi],
   link_with : [libintel_common, libmesa_util],
-  c_args : [c_vis_args, no_override_init_args],
+  c_args : [c_vis_args, no_override_init_args, c_sse2_args],
   build_by_default : true,
   install_dir: get_option('libexecdir'),
   install: true
-- 
2.7.4

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


Re: [Mesa-dev] [Mesa-stable] [PATCH v4] i965: compiler option msse2 and mstackrealign

2018-09-06 Thread Sergii Romantsov
Hello,

can you replace i965 with intel in the title of the commit

done

I assume you have commit access?

Unfortunately, i don't.

Thanks everybody for pointing details.

On Wed, Sep 5, 2018 at 8:41 PM, Dylan Baker  wrote:

> Quoting Sergii Romantsov (2018-09-05 04:40:37)
> > Seems in case of 32-bit library, usage of msse2 makes
> > some stack corruption or incorrect instructions.
> > Usage with mstackrealign fixes that case.
> >
> > v2: Fixed meson.
> >
> > v3: Definition of c_sse2_args moved on the top (L.Landwerlin).
> > Added mstackrealign for Android's mks where msee4.1 is used.
> >
> > v4: Added for Vulkan also.
> >
> > CC: 
> > Fixes: 6b05c080f202 (i965: Compile with -msse3)
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107779
> > Signed-off-by: Sergii Romantsov 
> > ---
> >  src/intel/Makefile.vulkan.am  | 2 +-
> >  src/intel/meson.build | 1 +
> >  src/intel/vulkan/meson.build  | 4 ++--
> >  src/mesa/Android.libmesa_dricore.mk   | 2 +-
> >  src/mesa/Android.libmesa_sse41.mk | 2 +-
> >  src/mesa/drivers/dri/i965/Makefile.am | 2 +-
> >  src/mesa/drivers/dri/i965/meson.build | 6 +++---
> >  7 files changed, 10 insertions(+), 9 deletions(-)
> >
> > diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
> > index 9555d98..d511263 100644
> > --- a/src/intel/Makefile.vulkan.am
> > +++ b/src/intel/Makefile.vulkan.am
> > @@ -104,7 +104,7 @@ noinst_LTLIBRARIES += $(VULKAN_PER_GEN_LIBS)
> >
> >  VULKAN_CFLAGS = \
> > $(AM_CFLAGS) \
> > -   -msse2
> > +   -msse2 -mstackrealign
> >
> >  VULKAN_CPPFLAGS = \
> > -I$(top_srcdir)/src/compiler \
> > diff --git a/src/intel/meson.build b/src/intel/meson.build
> > index b3dcbdc..3c57e79 100644
> > --- a/src/intel/meson.build
> > +++ b/src/intel/meson.build
> > @@ -18,6 +18,7 @@
> >  # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS IN THE
> >  # SOFTWARE.
> >
> > +c_sse2_args = ['-msse2', '-mstackrealign']
> >  inc_intel = include_directories('.')
> >
> >  subdir('blorp')
> > diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
> > index e11bcb0..f1beb1d 100644
> > --- a/src/intel/vulkan/meson.build
> > +++ b/src/intel/vulkan/meson.build
> > @@ -102,7 +102,7 @@ foreach g : [['70', ['gen7_cmd_buffer.c']], ['75',
> ['gen7_cmd_buffer.c']],
> >inc_vulkan_wsi,
> >  ],
> >  c_args : [
> > -  c_vis_args, no_override_init_args, '-msse2',
> > +  c_vis_args, no_override_init_args, c_sse2_args,
> >'-DGEN_VERSIONx10=@0@'.format(_gen),
> >  ],
> >  dependencies : [dep_libdrm, dep_valgrind, idep_nir_headers],
> > @@ -146,7 +146,7 @@ anv_deps = [
> >  anv_flags = [
> >c_vis_args,
> >no_override_init_args,
> > -  '-msse2',
> > +  c_sse2_args,
> >  ]
> >
> >  if with_platform_x11
> > diff --git a/src/mesa/Android.libmesa_dricore.mk b/src/mesa/
> Android.libmesa_dricore.mk
> > index 34fd858..7921177 100644
> > --- a/src/mesa/Android.libmesa_dricore.mk
> > +++ b/src/mesa/Android.libmesa_dricore.mk
> > @@ -49,7 +49,7 @@ ifeq ($(ARCH_X86_HAVE_SSE4_1),true)
> >  LOCAL_WHOLE_STATIC_LIBRARIES := \
> > libmesa_sse41
> >  LOCAL_CFLAGS := \
> > -   -msse4.1 \
> > +   -msse4.1 -mstackrealign \
> > -DUSE_SSE41
> >  endif
> >
> > diff --git a/src/mesa/Android.libmesa_sse41.mk b/src/mesa/
> Android.libmesa_sse41.mk
> > index da40f43..de19a1f 100644
> > --- a/src/mesa/Android.libmesa_sse41.mk
> > +++ b/src/mesa/Android.libmesa_sse41.mk
> > @@ -34,7 +34,7 @@ LOCAL_SRC_FILES += \
> > $(X86_SSE41_FILES)
> >
> >  LOCAL_CFLAGS := \
> > -   -msse4.1
> > +   -msse4.1 -mstackrealign
> >
> >  LOCAL_C_INCLUDES := \
> > $(MESA_TOP)/src/mapi \
> > diff --git a/src/mesa/drivers/dri/i965/Makefile.am
> b/src/mesa/drivers/dri/i965/Makefile.am
> > index 889d4c6..0afa7a2 100644
> > --- a/src/mesa/drivers/dri/i965/Makefile.am
> > +++ b/src/mesa/drivers/dri/i965/Makefile.am
> > @@ -44,7 +44,7 @@ AM_CFLAGS = \
> > $(WNO_OVERRIDE_INIT) \
> > $(LIBDRM_CFLAGS) \
> > $(VALGRIND_CFLAGS) \
> > -   -msse2
> > +   -msse2 -mstackrealign
> >
> >  AM_CXXFLAGS = $(AM_CFLAGS)
> >
> > diff --git a/src/mesa/drivers/dri/i965/meson.build
> b/src/mesa/drivers/dri/i965/meson.build
>

[Mesa-dev] [PATCH v5] intel: compiler option msse2 and mstackrealign

2018-09-06 Thread Sergii Romantsov
Seems in case of 32-bit library, usage of msse2 makes
some stack corruption or incorrect instructions.
Usage with mstackrealign fixes that case.

v2: Fixed meson.

v3: Definition of c_sse2_args moved on the top (L.Landwerlin).
Added mstackrealign for Android's mks where msee4.1 is used.

v4: Added for Vulkan also.

v5: Commit message correction.

CC: 
Fixes: 6b05c080f202 (i965: Compile with -msse3)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107779
Signed-off-by: Sergii Romantsov 
Reviewed-by: Dylan Baker 
Reviewed-by: Emil Velikov 
Reviewed-by: Lionel Landwerlin 
---
 src/intel/Makefile.vulkan.am  | 2 +-
 src/intel/meson.build | 1 +
 src/intel/vulkan/meson.build  | 4 ++--
 src/mesa/Android.libmesa_dricore.mk   | 2 +-
 src/mesa/Android.libmesa_sse41.mk | 2 +-
 src/mesa/drivers/dri/i965/Makefile.am | 2 +-
 src/mesa/drivers/dri/i965/meson.build | 6 +++---
 7 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
index 9555d98..d511263 100644
--- a/src/intel/Makefile.vulkan.am
+++ b/src/intel/Makefile.vulkan.am
@@ -104,7 +104,7 @@ noinst_LTLIBRARIES += $(VULKAN_PER_GEN_LIBS)
 
 VULKAN_CFLAGS = \
$(AM_CFLAGS) \
-   -msse2
+   -msse2 -mstackrealign
 
 VULKAN_CPPFLAGS = \
-I$(top_srcdir)/src/compiler \
diff --git a/src/intel/meson.build b/src/intel/meson.build
index b3dcbdc..3c57e79 100644
--- a/src/intel/meson.build
+++ b/src/intel/meson.build
@@ -18,6 +18,7 @@
 # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 # SOFTWARE.
 
+c_sse2_args = ['-msse2', '-mstackrealign']
 inc_intel = include_directories('.')
 
 subdir('blorp')
diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
index e11bcb0..f1beb1d 100644
--- a/src/intel/vulkan/meson.build
+++ b/src/intel/vulkan/meson.build
@@ -102,7 +102,7 @@ foreach g : [['70', ['gen7_cmd_buffer.c']], ['75', 
['gen7_cmd_buffer.c']],
   inc_vulkan_wsi,
 ],
 c_args : [
-  c_vis_args, no_override_init_args, '-msse2',
+  c_vis_args, no_override_init_args, c_sse2_args,
   '-DGEN_VERSIONx10=@0@'.format(_gen),
 ],
 dependencies : [dep_libdrm, dep_valgrind, idep_nir_headers],
@@ -146,7 +146,7 @@ anv_deps = [
 anv_flags = [
   c_vis_args,
   no_override_init_args,
-  '-msse2',
+  c_sse2_args,
 ]
 
 if with_platform_x11
diff --git a/src/mesa/Android.libmesa_dricore.mk 
b/src/mesa/Android.libmesa_dricore.mk
index 34fd858..7921177 100644
--- a/src/mesa/Android.libmesa_dricore.mk
+++ b/src/mesa/Android.libmesa_dricore.mk
@@ -49,7 +49,7 @@ ifeq ($(ARCH_X86_HAVE_SSE4_1),true)
 LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_sse41
 LOCAL_CFLAGS := \
-   -msse4.1 \
+   -msse4.1 -mstackrealign \
-DUSE_SSE41
 endif
 
diff --git a/src/mesa/Android.libmesa_sse41.mk 
b/src/mesa/Android.libmesa_sse41.mk
index da40f43..de19a1f 100644
--- a/src/mesa/Android.libmesa_sse41.mk
+++ b/src/mesa/Android.libmesa_sse41.mk
@@ -34,7 +34,7 @@ LOCAL_SRC_FILES += \
$(X86_SSE41_FILES)
 
 LOCAL_CFLAGS := \
-   -msse4.1
+   -msse4.1 -mstackrealign
 
 LOCAL_C_INCLUDES := \
$(MESA_TOP)/src/mapi \
diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
b/src/mesa/drivers/dri/i965/Makefile.am
index 889d4c6..0afa7a2 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -44,7 +44,7 @@ AM_CFLAGS = \
$(WNO_OVERRIDE_INIT) \
$(LIBDRM_CFLAGS) \
$(VALGRIND_CFLAGS) \
-   -msse2
+   -msse2 -mstackrealign
 
 AM_CXXFLAGS = $(AM_CFLAGS)
 
diff --git a/src/mesa/drivers/dri/i965/meson.build 
b/src/mesa/drivers/dri/i965/meson.build
index 6c94f4a..b95e2d7 100644
--- a/src/mesa/drivers/dri/i965/meson.build
+++ b/src/mesa/drivers/dri/i965/meson.build
@@ -142,7 +142,7 @@ foreach v : ['40', '45', '50', '60', '70', '75', '80', 
'90', '100', '110']
 ['genX_blorp_exec.c', 'genX_state_upload.c', gen_xml_pack],
 include_directories : [inc_common, inc_intel, inc_dri_common],
 c_args : [
-  c_vis_args, no_override_init_args, '-msse2',
+  c_vis_args, no_override_init_args, c_sse2_args,
   '-DGEN_VERSIONx10=@0@'.format(v),
 ],
 dependencies : [dep_libdrm, idep_nir_headers],
@@ -183,8 +183,8 @@ libi965 = static_library(
   include_directories : [
 inc_common, inc_intel, inc_dri_common, inc_util, inc_drm_uapi,
   ],
-  c_args : [c_vis_args, no_override_init_args, '-msse2'],
-  cpp_args : [cpp_vis_args, '-msse2'],
+  c_args : [c_vis_args, no_override_init_args, c_sse2_args],
+  cpp_args : [cpp_vis_args, c_sse2_args],
   link_with : [
 i965_gen_libs, libintel_common, libintel_dev, libisl, libintel_compiler,
 libblorp,
-- 
2.7.4

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


[Mesa-dev] [PATCH v4] i965: compiler option msse2 and mstackrealign

2018-09-05 Thread Sergii Romantsov
Seems in case of 32-bit library, usage of msse2 makes
some stack corruption or incorrect instructions.
Usage with mstackrealign fixes that case.

v2: Fixed meson.

v3: Definition of c_sse2_args moved on the top (L.Landwerlin).
Added mstackrealign for Android's mks where msee4.1 is used.

v4: Added for Vulkan also.

CC: 
Fixes: 6b05c080f202 (i965: Compile with -msse3)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107779
Signed-off-by: Sergii Romantsov 
---
 src/intel/Makefile.vulkan.am  | 2 +-
 src/intel/meson.build | 1 +
 src/intel/vulkan/meson.build  | 4 ++--
 src/mesa/Android.libmesa_dricore.mk   | 2 +-
 src/mesa/Android.libmesa_sse41.mk | 2 +-
 src/mesa/drivers/dri/i965/Makefile.am | 2 +-
 src/mesa/drivers/dri/i965/meson.build | 6 +++---
 7 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
index 9555d98..d511263 100644
--- a/src/intel/Makefile.vulkan.am
+++ b/src/intel/Makefile.vulkan.am
@@ -104,7 +104,7 @@ noinst_LTLIBRARIES += $(VULKAN_PER_GEN_LIBS)
 
 VULKAN_CFLAGS = \
$(AM_CFLAGS) \
-   -msse2
+   -msse2 -mstackrealign
 
 VULKAN_CPPFLAGS = \
-I$(top_srcdir)/src/compiler \
diff --git a/src/intel/meson.build b/src/intel/meson.build
index b3dcbdc..3c57e79 100644
--- a/src/intel/meson.build
+++ b/src/intel/meson.build
@@ -18,6 +18,7 @@
 # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 # SOFTWARE.
 
+c_sse2_args = ['-msse2', '-mstackrealign']
 inc_intel = include_directories('.')
 
 subdir('blorp')
diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
index e11bcb0..f1beb1d 100644
--- a/src/intel/vulkan/meson.build
+++ b/src/intel/vulkan/meson.build
@@ -102,7 +102,7 @@ foreach g : [['70', ['gen7_cmd_buffer.c']], ['75', 
['gen7_cmd_buffer.c']],
   inc_vulkan_wsi,
 ],
 c_args : [
-  c_vis_args, no_override_init_args, '-msse2',
+  c_vis_args, no_override_init_args, c_sse2_args,
   '-DGEN_VERSIONx10=@0@'.format(_gen),
 ],
 dependencies : [dep_libdrm, dep_valgrind, idep_nir_headers],
@@ -146,7 +146,7 @@ anv_deps = [
 anv_flags = [
   c_vis_args,
   no_override_init_args,
-  '-msse2',
+  c_sse2_args,
 ]
 
 if with_platform_x11
diff --git a/src/mesa/Android.libmesa_dricore.mk 
b/src/mesa/Android.libmesa_dricore.mk
index 34fd858..7921177 100644
--- a/src/mesa/Android.libmesa_dricore.mk
+++ b/src/mesa/Android.libmesa_dricore.mk
@@ -49,7 +49,7 @@ ifeq ($(ARCH_X86_HAVE_SSE4_1),true)
 LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_sse41
 LOCAL_CFLAGS := \
-   -msse4.1 \
+   -msse4.1 -mstackrealign \
-DUSE_SSE41
 endif
 
diff --git a/src/mesa/Android.libmesa_sse41.mk 
b/src/mesa/Android.libmesa_sse41.mk
index da40f43..de19a1f 100644
--- a/src/mesa/Android.libmesa_sse41.mk
+++ b/src/mesa/Android.libmesa_sse41.mk
@@ -34,7 +34,7 @@ LOCAL_SRC_FILES += \
$(X86_SSE41_FILES)
 
 LOCAL_CFLAGS := \
-   -msse4.1
+   -msse4.1 -mstackrealign
 
 LOCAL_C_INCLUDES := \
$(MESA_TOP)/src/mapi \
diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
b/src/mesa/drivers/dri/i965/Makefile.am
index 889d4c6..0afa7a2 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -44,7 +44,7 @@ AM_CFLAGS = \
$(WNO_OVERRIDE_INIT) \
$(LIBDRM_CFLAGS) \
$(VALGRIND_CFLAGS) \
-   -msse2
+   -msse2 -mstackrealign
 
 AM_CXXFLAGS = $(AM_CFLAGS)
 
diff --git a/src/mesa/drivers/dri/i965/meson.build 
b/src/mesa/drivers/dri/i965/meson.build
index 6c94f4a..b95e2d7 100644
--- a/src/mesa/drivers/dri/i965/meson.build
+++ b/src/mesa/drivers/dri/i965/meson.build
@@ -142,7 +142,7 @@ foreach v : ['40', '45', '50', '60', '70', '75', '80', 
'90', '100', '110']
 ['genX_blorp_exec.c', 'genX_state_upload.c', gen_xml_pack],
 include_directories : [inc_common, inc_intel, inc_dri_common],
 c_args : [
-  c_vis_args, no_override_init_args, '-msse2',
+  c_vis_args, no_override_init_args, c_sse2_args,
   '-DGEN_VERSIONx10=@0@'.format(v),
 ],
 dependencies : [dep_libdrm, idep_nir_headers],
@@ -183,8 +183,8 @@ libi965 = static_library(
   include_directories : [
 inc_common, inc_intel, inc_dri_common, inc_util, inc_drm_uapi,
   ],
-  c_args : [c_vis_args, no_override_init_args, '-msse2'],
-  cpp_args : [cpp_vis_args, '-msse2'],
+  c_args : [c_vis_args, no_override_init_args, c_sse2_args],
+  cpp_args : [cpp_vis_args, c_sse2_args],
   link_with : [
 i965_gen_libs, libintel_common, libintel_dev, libisl, libintel_compiler,
 libblorp,
-- 
2.7.4

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


[Mesa-dev] [PATCH v3] i965: compiler option msse2 and mstackrealign

2018-09-05 Thread Sergii Romantsov
Seems in case of 32-bit library, usage of msse2 makes
some stack corruption or incorrect instructions.
Usage with mstackrealign fixes that case.

v2: fixed meson

v3: Definition of c_sse2_args moved on the top (L.Landwerlin).
Added mstackrealign for Android's mks where msee4.1 is used.

CC: 
Fixes: 6b05c080f202 (i965: Compile with -msse3)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107779
Signed-off-by: Sergii Romantsov 
---
 src/intel/meson.build | 1 +
 src/mesa/Android.libmesa_dricore.mk   | 2 +-
 src/mesa/Android.libmesa_sse41.mk | 2 +-
 src/mesa/drivers/dri/i965/Makefile.am | 2 +-
 src/mesa/drivers/dri/i965/meson.build | 6 +++---
 5 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/intel/meson.build b/src/intel/meson.build
index b3dcbdc..3c57e79 100644
--- a/src/intel/meson.build
+++ b/src/intel/meson.build
@@ -18,6 +18,7 @@
 # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 # SOFTWARE.
 
+c_sse2_args = ['-msse2', '-mstackrealign']
 inc_intel = include_directories('.')
 
 subdir('blorp')
diff --git a/src/mesa/Android.libmesa_dricore.mk 
b/src/mesa/Android.libmesa_dricore.mk
index 34fd858..7921177 100644
--- a/src/mesa/Android.libmesa_dricore.mk
+++ b/src/mesa/Android.libmesa_dricore.mk
@@ -49,7 +49,7 @@ ifeq ($(ARCH_X86_HAVE_SSE4_1),true)
 LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_sse41
 LOCAL_CFLAGS := \
-   -msse4.1 \
+   -msse4.1 -mstackrealign \
-DUSE_SSE41
 endif
 
diff --git a/src/mesa/Android.libmesa_sse41.mk 
b/src/mesa/Android.libmesa_sse41.mk
index da40f43..de19a1f 100644
--- a/src/mesa/Android.libmesa_sse41.mk
+++ b/src/mesa/Android.libmesa_sse41.mk
@@ -34,7 +34,7 @@ LOCAL_SRC_FILES += \
$(X86_SSE41_FILES)
 
 LOCAL_CFLAGS := \
-   -msse4.1
+   -msse4.1 -mstackrealign
 
 LOCAL_C_INCLUDES := \
$(MESA_TOP)/src/mapi \
diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
b/src/mesa/drivers/dri/i965/Makefile.am
index 889d4c6..0afa7a2 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -44,7 +44,7 @@ AM_CFLAGS = \
$(WNO_OVERRIDE_INIT) \
$(LIBDRM_CFLAGS) \
$(VALGRIND_CFLAGS) \
-   -msse2
+   -msse2 -mstackrealign
 
 AM_CXXFLAGS = $(AM_CFLAGS)
 
diff --git a/src/mesa/drivers/dri/i965/meson.build 
b/src/mesa/drivers/dri/i965/meson.build
index 6c94f4a..b95e2d7 100644
--- a/src/mesa/drivers/dri/i965/meson.build
+++ b/src/mesa/drivers/dri/i965/meson.build
@@ -142,7 +142,7 @@ foreach v : ['40', '45', '50', '60', '70', '75', '80', 
'90', '100', '110']
 ['genX_blorp_exec.c', 'genX_state_upload.c', gen_xml_pack],
 include_directories : [inc_common, inc_intel, inc_dri_common],
 c_args : [
-  c_vis_args, no_override_init_args, '-msse2',
+  c_vis_args, no_override_init_args, c_sse2_args,
   '-DGEN_VERSIONx10=@0@'.format(v),
 ],
 dependencies : [dep_libdrm, idep_nir_headers],
@@ -183,8 +183,8 @@ libi965 = static_library(
   include_directories : [
 inc_common, inc_intel, inc_dri_common, inc_util, inc_drm_uapi,
   ],
-  c_args : [c_vis_args, no_override_init_args, '-msse2'],
-  cpp_args : [cpp_vis_args, '-msse2'],
+  c_args : [c_vis_args, no_override_init_args, c_sse2_args],
+  cpp_args : [cpp_vis_args, c_sse2_args],
   link_with : [
 i965_gen_libs, libintel_common, libintel_dev, libisl, libintel_compiler,
 libblorp,
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v1] i965: compiler option msse2 and mstackrealign

2018-09-05 Thread Sergii Romantsov
Hello, sorry for delay in answer.

I think you might need to update the other build systems (Android.mk/meson)

Have done it for meson, but with Android i can't check if issue present or
if it will be fixed. And seems it requires some extra knowledge/time. Could
we try to discuss it in separate thread/patch?

The toplevel meson/makefile have a -mstackrealign that seem to make the
> description of the issue you're fixing.
> Maybe that's where this change should go.

Do you mean to move compilation flag for all libs? Seems at this moment
flag mstackrealign is needed only for i965-dri, so maybe its better to
enable only if needed?

For meson it might be nice to add a c_sse2_args = ['-msse2',
> '-mstackrealign'] at the src/intel level

Done

Also, since this is extremely trivial and fixes bugs, this should be cc'd
> to mesa stable for 18.1 and 18.2

Sorry, not clear for me: should i do anything with that?


On Wed, Sep 5, 2018 at 1:19 AM, Dylan Baker  wrote:

> Quoting Sergii Romantsov (2018-09-04 03:46:23)
> > Seems in case of 32-bit library, usage of msse2 makes
> > some stack corruption or incorrect instructions.
> > Usage with mstackrealign fixes that case.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107779
> > Signed-off-by: Sergii Romantsov 
> > ---
> >  src/mesa/drivers/dri/i965/Makefile.am | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/Makefile.am
> b/src/mesa/drivers/dri/i965/Makefile.am
> > index 889d4c6..0afa7a2 100644
> > --- a/src/mesa/drivers/dri/i965/Makefile.am
> > +++ b/src/mesa/drivers/dri/i965/Makefile.am
> > @@ -44,7 +44,7 @@ AM_CFLAGS = \
> > $(WNO_OVERRIDE_INIT) \
> > $(LIBDRM_CFLAGS) \
> > $(VALGRIND_CFLAGS) \
> > -   -msse2
> > +   -msse2 -mstackrealign
> >
> >  AM_CXXFLAGS = $(AM_CFLAGS)
> >
> > --
> > 2.7.4
> >
>
> Also, since this is extremely trivial and fixes bugs, this should be cc'd
> to
> mesa stable for 18.1 and 18.2
>
> Thanks,
> Dylan
>
> ___
> 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


[Mesa-dev] [PATCH v2] i965: compiler option msse2 and mstackrealign

2018-09-05 Thread Sergii Romantsov
Seems in case of 32-bit library, usage of msse2 makes
some stack corruption or incorrect instructions.
Usage with mstackrealign fixes that case.

v2: fixed meson

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107779
Signed-off-by: Sergii Romantsov 
---
 src/intel/meson.build | 2 ++
 src/mesa/drivers/dri/i965/Makefile.am | 2 +-
 src/mesa/drivers/dri/i965/meson.build | 6 +++---
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/intel/meson.build b/src/intel/meson.build
index b3dcbdc..7a0d6d7 100644
--- a/src/intel/meson.build
+++ b/src/intel/meson.build
@@ -32,3 +32,5 @@ endif
 if with_intel_vk
   subdir('vulkan')
 endif
+
+c_sse2_args = ['-msse2', '-mstackrealign']
\ No newline at end of file
diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
b/src/mesa/drivers/dri/i965/Makefile.am
index 889d4c6..0afa7a2 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -44,7 +44,7 @@ AM_CFLAGS = \
$(WNO_OVERRIDE_INIT) \
$(LIBDRM_CFLAGS) \
$(VALGRIND_CFLAGS) \
-   -msse2
+   -msse2 -mstackrealign
 
 AM_CXXFLAGS = $(AM_CFLAGS)
 
diff --git a/src/mesa/drivers/dri/i965/meson.build 
b/src/mesa/drivers/dri/i965/meson.build
index 6c94f4a..b95e2d7 100644
--- a/src/mesa/drivers/dri/i965/meson.build
+++ b/src/mesa/drivers/dri/i965/meson.build
@@ -142,7 +142,7 @@ foreach v : ['40', '45', '50', '60', '70', '75', '80', 
'90', '100', '110']
 ['genX_blorp_exec.c', 'genX_state_upload.c', gen_xml_pack],
 include_directories : [inc_common, inc_intel, inc_dri_common],
 c_args : [
-  c_vis_args, no_override_init_args, '-msse2',
+  c_vis_args, no_override_init_args, c_sse2_args,
   '-DGEN_VERSIONx10=@0@'.format(v),
 ],
 dependencies : [dep_libdrm, idep_nir_headers],
@@ -183,8 +183,8 @@ libi965 = static_library(
   include_directories : [
 inc_common, inc_intel, inc_dri_common, inc_util, inc_drm_uapi,
   ],
-  c_args : [c_vis_args, no_override_init_args, '-msse2'],
-  cpp_args : [cpp_vis_args, '-msse2'],
+  c_args : [c_vis_args, no_override_init_args, c_sse2_args],
+  cpp_args : [cpp_vis_args, c_sse2_args],
   link_with : [
 i965_gen_libs, libintel_common, libintel_dev, libisl, libintel_compiler,
 libblorp,
-- 
2.7.4

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


[Mesa-dev] [PATCH v1] i965: compiler option msse2 and mstackrealign

2018-09-04 Thread Sergii Romantsov
Seems in case of 32-bit library, usage of msse2 makes
some stack corruption or incorrect instructions.
Usage with mstackrealign fixes that case.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107779
Signed-off-by: Sergii Romantsov 
---
 src/mesa/drivers/dri/i965/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
b/src/mesa/drivers/dri/i965/Makefile.am
index 889d4c6..0afa7a2 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -44,7 +44,7 @@ AM_CFLAGS = \
$(WNO_OVERRIDE_INIT) \
$(LIBDRM_CFLAGS) \
$(VALGRIND_CFLAGS) \
-   -msse2
+   -msse2 -mstackrealign
 
 AM_CXXFLAGS = $(AM_CFLAGS)
 
-- 
2.7.4

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


[Mesa-dev] [PATCH v1 1/2] glsl/standalone: segfault with --dump-builder for ir_texture

2018-08-31 Thread Sergii Romantsov
Shader that contains builtin functions texture* causes segfault for
standalone compiler with parameter --dump-builder.
Added handling of ir_texture as rhs of assignment.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107767
Signed-off-by: Sergii Romantsov 
---
 src/compiler/glsl/ir_builder_print_visitor.cpp | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/src/compiler/glsl/ir_builder_print_visitor.cpp 
b/src/compiler/glsl/ir_builder_print_visitor.cpp
index da04868..eb98f41 100644
--- a/src/compiler/glsl/ir_builder_print_visitor.cpp
+++ b/src/compiler/glsl/ir_builder_print_visitor.cpp
@@ -60,6 +60,8 @@ public:
virtual ir_visitor_status visit_leave(class ir_swizzle *);
virtual ir_visitor_status visit_leave(class ir_return *);
 
+   virtual ir_visitor_status visit_enter(ir_texture *ir);
+
 private:
void print_with_indent(const char *fmt, ...);
void print_without_indent(const char *fmt, ...);
@@ -446,6 +448,7 @@ ir_builder_print_visitor::print_without_declaration(const 
ir_swizzle *ir)
  print_without_declaration(ir->val);
  print_without_indent(")");
   } else {
+ assert(he);
  print_without_indent("swizzle_%c(r%04X)",
   swiz[ir->mask.x],
   (unsigned)(uintptr_t) he->data);
@@ -453,6 +456,7 @@ ir_builder_print_visitor::print_without_declaration(const 
ir_swizzle *ir)
} else {
   static const char swiz[4] = { 'X', 'Y', 'Z', 'W' };
 
+  assert(he);
   print_without_indent("swizzle(r%04X, MAKE_SWIZZLE4(SWIZZLE_%c, 
SWIZZLE_%c, SWIZZLE_%c, SWIZZLE_%c), %u)",
(unsigned)(uintptr_t) he->data,
swiz[ir->mask.x],
@@ -527,6 +531,7 @@ ir_builder_print_visitor::visit_leave(ir_assignment *ir)
   _mesa_hash_table_search(index_map, ir->rhs);
 
assert(ir->condition == NULL);
+   assert(ir->lhs && ir->rhs);
 
print_with_indent("body.emit(assign(r%04X, r%04X, 0x%02x));\n\n",
  (unsigned)(uintptr_t) he_lhs->data,
@@ -684,6 +689,20 @@ ir_builder_print_visitor::visit_leave(ir_return *ir)
 }
 
 ir_visitor_status
+ir_builder_print_visitor::visit_enter(ir_texture *ir)
+{
+   const struct hash_entry *const he =
+  _mesa_hash_table_search(index_map, ir);
+   if (!he)
+   {
+  const unsigned my_index = next_ir_index++;
+  _mesa_hash_table_insert(index_map, ir, (void *)(uintptr_t) my_index);
+   }
+
+   return visit_continue;
+}
+
+ir_visitor_status
 ir_builder_print_visitor::visit_leave(ir_call *ir)
 {
const unsigned my_index = next_ir_index++;
-- 
2.7.4

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


[Mesa-dev] [PATCH v1 2/2] glsl/standalone: --dump-builder: dump of ir_texture

2018-08-31 Thread Sergii Romantsov
For standalone compilation with parameter --dump-builder in dump
absent description of texture invocation.
Added the simplest handling.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107767
Signed-off-by: Sergii Romantsov 
---
 src/compiler/glsl/ir_builder_print_visitor.cpp | 51 ++
 1 file changed, 51 insertions(+)

diff --git a/src/compiler/glsl/ir_builder_print_visitor.cpp 
b/src/compiler/glsl/ir_builder_print_visitor.cpp
index eb98f41..679d1b8 100644
--- a/src/compiler/glsl/ir_builder_print_visitor.cpp
+++ b/src/compiler/glsl/ir_builder_print_visitor.cpp
@@ -61,6 +61,7 @@ public:
virtual ir_visitor_status visit_leave(class ir_return *);
 
virtual ir_visitor_status visit_enter(ir_texture *ir);
+   virtual ir_visitor_status visit_leave(ir_texture *ir);
 
 private:
void print_with_indent(const char *fmt, ...);
@@ -703,6 +704,56 @@ ir_builder_print_visitor::visit_enter(ir_texture *ir)
 }
 
 ir_visitor_status
+ir_builder_print_visitor::visit_leave(ir_texture *ir)
+{
+   const struct hash_entry *const he_lhs =
+  _mesa_hash_table_search(index_map, ir);
+   const struct hash_entry *const he_rhs_sampler =
+  _mesa_hash_table_search(index_map, ir->sampler);
+   const struct hash_entry *const he_rhs_coord =
+  _mesa_hash_table_search(index_map, ir->coordinate);
+   const struct hash_entry *const he_rhs_proj =
+  _mesa_hash_table_search(index_map, ir->projector);
+   const struct hash_entry *const he_rhs_comp =
+  _mesa_hash_table_search(index_map, ir->shadow_comparator);
+   const struct hash_entry *const he_rhs_offset =
+  _mesa_hash_table_search(index_map, ir->offset);
+   const struct hash_entry *const he_rhs_lodinfo = ir->op != ir_txd
+  ? _mesa_hash_table_search(index_map, ir->lod_info.lod)  //use any member 
due to union
+  : NULL;
+   const struct hash_entry *const he_rhs_lodinfo_pdx = ir->op == ir_txd
+  ? _mesa_hash_table_search(index_map, ir->lod_info.grad.dPdx)
+  : NULL;
+   const struct hash_entry *const he_rhs_lodinfo_pdy = ir->op == ir_txd
+  ? _mesa_hash_table_search(index_map, ir->lod_info.grad.dPdy)
+  : NULL;
+
+   print_with_indent("ir_texture *const r%04X = new(mem_ctx) ir_texture(%s, 
r%04X",
+ he_lhs->data,
+ ir->opcode_string(),
+ he_rhs_sampler->data);
+   if (he_rhs_coord)
+  print_without_indent(", r%04X", he_rhs_coord->data);
+   if (he_rhs_proj)
+  print_without_indent(", r%04X", he_rhs_proj->data);
+   if (he_rhs_comp)
+  print_without_indent(", r%04X", he_rhs_comp->data);
+   if (he_rhs_offset)
+  print_without_indent(", r%04X", he_rhs_offset->data);
+   if (he_rhs_lodinfo)
+  print_without_indent(", r%04X", he_rhs_lodinfo->data);
+   if (he_rhs_lodinfo_pdx)
+  print_without_indent(", r%04X", he_rhs_lodinfo_pdx->data);
+   if (he_rhs_lodinfo_pdy)
+  print_without_indent(", r%04X", he_rhs_lodinfo_pdy->data);
+   print_without_indent(");\n");
+
+   print_with_indent("body.emit(r%04X);\n", he_lhs->data);
+
+   return visit_continue;
+}
+
+ir_visitor_status
 ir_builder_print_visitor::visit_leave(ir_call *ir)
 {
const unsigned my_index = next_ir_index++;
-- 
2.7.4

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


[Mesa-dev] [PATCH v1] configure/vulkan: linking issue of Vulkan

2018-08-20 Thread Sergii Romantsov
Installing of Vulkan on Ubuntu 16.04 fails during relinking.
Seems caught libtool-issue.
Library-dependicies GL_LIB_DEPS moved upper.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107624
Signed-off-by: Sergii Romantsov 
---
 src/glx/Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
index 8f9d80c..bb30a85 100644
--- a/src/glx/Makefile.am
+++ b/src/glx/Makefile.am
@@ -176,10 +176,10 @@ endif
 # against the system one.
 GL_LIBS = \
$(LIBDRM_LIBS) \
+   $(GL_LIB_DEPS) \
libglx.la \
$(top_builddir)/src/mapi/glapi/libglapi.la \
-   $(top_builddir)/src/mapi/shared-glapi/libglapi.la \
-   $(GL_LIB_DEPS)
+   $(top_builddir)/src/mapi/shared-glapi/libglapi.la
 
 GL_LDFLAGS = \
-no-undefined \
-- 
2.7.4

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


[Mesa-dev] [PATCH v2] configure/intel: checking for correct xcb-randr version

2018-08-17 Thread Sergii Romantsov
On Ubuntu 16.04 xcb-randr version is 1.11.1.
Thats enough to build Intel dri-driver.
But Intel Vulkan with enabled xlib-lease requires xcb-randr version 1.13.
Added such checking on configuration stage.

-v2: corrected bugzilla link

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106976
Fixes: 7ab1fffcd2a5 (vulkan: Add EXT_acquire_xlib_display [v5])
Signed-off-by: Sergii Romantsov 
---
 configure.ac | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/configure.ac b/configure.ac
index 2f1d13c..c73e0b0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -97,6 +97,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
@@ -1582,7 +1583,6 @@ AM_CONDITIONAL(HAVE_APPLEDRI, test "x$enable_dri" = xyes 
-a "x$dri_platform" = x
 AM_CONDITIONAL(HAVE_LMSENSORS, test "x$enable_lmsensors" = xyes )
 AM_CONDITIONAL(HAVE_GALLIUM_EXTRA_HUD, test "x$enable_gallium_extra_hud" = 
xyes )
 AM_CONDITIONAL(HAVE_WINDOWSDRI, test "x$enable_dri" = xyes -a "x$dri_platform" 
= xwindows )
-AM_CONDITIONAL(HAVE_XLEASE, test "x$have_xlease" = xyes )
 
 AC_ARG_ENABLE([shared-glapi],
 [AS_HELP_STRING([--enable-shared-glapi],
@@ -1895,19 +1895,6 @@ if test x"$enable_dri3" = xyes; then
 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')
@@ -2164,6 +2151,15 @@ if test -n "$with_vulkan_drivers"; then
 VULKAN_DRIVERS=`echo $VULKAN_DRIVERS|tr " " "\n"|sort -u|tr "\n" " "`
 fi
 
+if test x"$enable_xlib_lease" = xyes; then
+randr_modules="x11-xcb xrandr"
+if test "x$HAVE_INTEL_VULKAN" = xyes; then
+randr_modules+=" xcb-randr >= $XCBRANDR_XLEASE_REQUIRED"
+else
+randr_modules+=" xcb-randr"
+fi
+PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules])
+fi
 
 DEFINES="$DEFINES -DENABLE_SHADER_CACHE"
 AM_CONDITIONAL(NEED_MEGADRIVER, test -n "$DRI_DIRS")
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v5 1/2] intel/ppgtt: memory address alignment

2018-08-16 Thread Sergii Romantsov
And also thanks to you :).

On Thu, Aug 16, 2018 at 4:16 PM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Both patches pushed to master.
>
> Thanks!
>
> -
> Lionel
>
>
> On 15/08/18 16:03, Lionel Landwerlin wrote:
>
>> On 15/08/18 12:23, Sergii Romantsov wrote:
>>
>>> Kernel (for ppgtt) requires memory address to be
>>> aligned to page size (4096).
>>>
>>> -v2: added marking that also fixes initial commit 01058a552294.
>>> -v3: numbers replaced by PAGE_SIZE; buffer-object size is aligned
>>> instead of alignment of offsets (Chris Wilson).
>>> -v4: changes related to PAGE_SIZE moved to separate commit
>>> -v5: restored alignment to page-size for 0-size.
>>>
>>> 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 
>>>
>>
>> CI seems happy this time :
>>
>> Reviewed-by: Lionel Landwerlin 
>>
>> ---
>>>   src/mesa/drivers/dri/i965/brw_bufmgr.c | 7 +++
>>>   1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
>>> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
>>> index 09d45e3..19e2d14 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
>>> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
>>> @@ -496,7 +496,6 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
>>> uint32_t stride)
>>>   {
>>>  struct brw_bo *bo;
>>> -   unsigned int page_size = getpagesize();
>>>  int ret;
>>>  struct bo_cache_bucket *bucket;
>>>  bool alloc_from_cache;
>>> @@ -522,12 +521,12 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
>>>   * allocation up.
>>>   */
>>>  if (bucket == NULL) {
>>> -  bo_size = size;
>>> -  if (bo_size < page_size)
>>> - bo_size = page_size;
>>> +  unsigned int page_size = getpagesize();
>>> +  bo_size = size == 0 ? page_size : ALIGN(size, page_size);
>>>  } else {
>>> bo_size = bucket->size;
>>>  }
>>> +   assert(bo_size);
>>>mtx_lock(>lock);
>>>  /* Get a buffer out of the cache if available */
>>>
>>
>>
>> ___
>> 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
>



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


[Mesa-dev] [PATCH v1] configure/intel: checking for correct xcb-randr version

2018-08-16 Thread Sergii Romantsov
On Ubuntu 16.04 xcb-randr version is 1.11.1.
Thats enough to build Intel dri-driver.
But Intel Vulkan with enabled xlib-lease requires xcb-randr version 1.13.
Added such checking on configuration stage.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106997
Fixes: 7ab1fffcd2a5 (vulkan: Add EXT_acquire_xlib_display [v5])
Signed-off-by: Sergii Romantsov 
---
 configure.ac | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/configure.ac b/configure.ac
index c2155a5..fb4e501 100644
--- a/configure.ac
+++ b/configure.ac
@@ -97,6 +97,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
@@ -1582,7 +1583,6 @@ AM_CONDITIONAL(HAVE_APPLEDRI, test "x$enable_dri" = xyes 
-a "x$dri_platform" = x
 AM_CONDITIONAL(HAVE_LMSENSORS, test "x$enable_lmsensors" = xyes )
 AM_CONDITIONAL(HAVE_GALLIUM_EXTRA_HUD, test "x$enable_gallium_extra_hud" = 
xyes )
 AM_CONDITIONAL(HAVE_WINDOWSDRI, test "x$enable_dri" = xyes -a "x$dri_platform" 
= xwindows )
-AM_CONDITIONAL(HAVE_XLEASE, test "x$have_xlease" = xyes )
 
 AC_ARG_ENABLE([shared-glapi],
 [AS_HELP_STRING([--enable-shared-glapi],
@@ -1895,19 +1895,6 @@ if test x"$enable_dri3" = xyes; then
 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')
@@ -2164,6 +2151,15 @@ if test -n "$with_vulkan_drivers"; then
 VULKAN_DRIVERS=`echo $VULKAN_DRIVERS|tr " " "\n"|sort -u|tr "\n" " "`
 fi
 
+if test x"$enable_xlib_lease" = xyes; then
+randr_modules="x11-xcb xrandr"
+if test "x$HAVE_INTEL_VULKAN" = xyes; then
+randr_modules+=" xcb-randr >= $XCBRANDR_XLEASE_REQUIRED"
+else
+randr_modules+=" xcb-randr"
+fi
+PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules])
+fi
 
 DEFINES="$DEFINES -DENABLE_SHADER_CACHE"
 AM_CONDITIONAL(NEED_MEGADRIVER, test -n "$DRI_DIRS")
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v1] i965: Emitting 3DSTATE_SO_BUFFER of 0-size.

2018-08-15 Thread Sergii Romantsov
Hello,
that patch is according to remark:
>
> "Additionally, we probably ought to fix the callers to stop allocating 0
> size BOs.
> It looks like most of them come from the 3DSTATE_SO_BUFFER code,
> where one stream has valid transform feedback info, and the other
> 3 are empty. "


 And seems additional one: https://patchwork.freedesktop.org/patch/244674/


On Wed, Aug 15, 2018 at 3:21 PM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:

> Avoided filling of whole structure and bo-allocation if
> size of surface is 0.
>
> Signed-off-by: Sergii Romantsov 
> ---
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index ea5ad55..c051848 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -3787,19 +3787,20 @@ genX(upload_3dstate_so_buffers)(struct
> brw_context *brw)
> for (int i = 0; i < 4; i++) {
>struct intel_buffer_object *bufferobj =
>   intel_buffer_object(xfb_obj->Buffers[i]);
> +  uint32_t start = xfb_obj->Offset[i];
> +  uint32_t end = ALIGN(start + xfb_obj->Size[i], 4);
> +  uint32_t const size = end - start;
>
> -  if (!bufferobj) {
> +  if (!bufferobj || !size) {
>   brw_batch_emit(brw, GENX(3DSTATE_SO_BUFFER), sob) {
>  sob.SOBufferIndex = i;
>   }
>   continue;
>}
>
> -  uint32_t start = xfb_obj->Offset[i];
>assert(start % 4 == 0);
> -  uint32_t end = ALIGN(start + xfb_obj->Size[i], 4);
>struct brw_bo *bo =
> - intel_bufferobj_buffer(brw, bufferobj, start, end - start, true);
> + intel_bufferobj_buffer(brw, bufferobj, start, size, true);
>assert(end <= bo->size);
>
>brw_batch_emit(brw, GENX(3DSTATE_SO_BUFFER), sob) {
> --
> 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


[Mesa-dev] [PATCH v1] i965/bo/perf: 0-sized-bo allocation log

2018-08-15 Thread Sergii Romantsov
Added debug-log in case of bo-allocation with 0 size.
Potentially we may not need to allocate such buffers and each
case could be analyzed to improve behaviour.

Signed-off-by: Sergii Romantsov 
---
 src/mesa/drivers/dri/i965/brw_bufmgr.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 09d45e3..726b266 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -514,6 +514,9 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
 * be idle before we can memset.  Just disallow that combination.
 */
assert(!(busy && zeroed));
+   if (!size && unlikely(INTEL_DEBUG & DEBUG_PERF))
+  dbg_printf("performance: allocation of 0-sized BO: %s\n", name);
+
 
/* Round the allocated size up to a power of two number of pages. */
bucket = bucket_for_size(bufmgr, size);
-- 
2.7.4

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


[Mesa-dev] [PATCH v1] i965: Emitting 3DSTATE_SO_BUFFER of 0-size.

2018-08-15 Thread Sergii Romantsov
Avoided filling of whole structure and bo-allocation if
size of surface is 0.

Signed-off-by: Sergii Romantsov 
---
 src/mesa/drivers/dri/i965/genX_state_upload.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index ea5ad55..c051848 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -3787,19 +3787,20 @@ genX(upload_3dstate_so_buffers)(struct brw_context *brw)
for (int i = 0; i < 4; i++) {
   struct intel_buffer_object *bufferobj =
  intel_buffer_object(xfb_obj->Buffers[i]);
+  uint32_t start = xfb_obj->Offset[i];
+  uint32_t end = ALIGN(start + xfb_obj->Size[i], 4);
+  uint32_t const size = end - start;
 
-  if (!bufferobj) {
+  if (!bufferobj || !size) {
  brw_batch_emit(brw, GENX(3DSTATE_SO_BUFFER), sob) {
 sob.SOBufferIndex = i;
  }
  continue;
   }
 
-  uint32_t start = xfb_obj->Offset[i];
   assert(start % 4 == 0);
-  uint32_t end = ALIGN(start + xfb_obj->Size[i], 4);
   struct brw_bo *bo =
- intel_bufferobj_buffer(brw, bufferobj, start, end - start, true);
+ intel_bufferobj_buffer(brw, bufferobj, start, size, true);
   assert(end <= bo->size);
 
   brw_batch_emit(brw, GENX(3DSTATE_SO_BUFFER), sob) {
-- 
2.7.4

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


[Mesa-dev] [PATCH v5 1/2] intel/ppgtt: memory address alignment

2018-08-15 Thread Sergii Romantsov
Kernel (for ppgtt) requires memory address to be
aligned to page size (4096).

-v2: added marking that also fixes initial commit 01058a552294.
-v3: numbers replaced by PAGE_SIZE; buffer-object size is aligned
instead of alignment of offsets (Chris Wilson).
-v4: changes related to PAGE_SIZE moved to separate commit
-v5: restored alignment to page-size for 0-size.

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 | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 09d45e3..19e2d14 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -496,7 +496,6 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
   uint32_t stride)
 {
struct brw_bo *bo;
-   unsigned int page_size = getpagesize();
int ret;
struct bo_cache_bucket *bucket;
bool alloc_from_cache;
@@ -522,12 +521,12 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
 * allocation up.
 */
if (bucket == NULL) {
-  bo_size = size;
-  if (bo_size < page_size)
- bo_size = page_size;
+  unsigned int page_size = getpagesize();
+  bo_size = size == 0 ? page_size : ALIGN(size, page_size);
} else {
   bo_size = bucket->size;
}
+   assert(bo_size);
 
mtx_lock(>lock);
/* Get a buffer out of the cache if available */
-- 
2.7.4

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


[Mesa-dev] [PATCH v5 2/2] intel/ppgtt: 4096 replaced by PAGE_SIZE

2018-08-15 Thread Sergii Romantsov
Usage of number 4096 replaced by PAGE_SIZE.

Signed-off-by: Sergii Romantsov 
---
 src/mesa/drivers/dri/i965/brw_bufmgr.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 19e2d14..b0f83fb 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -195,7 +195,7 @@ bo_tile_size(struct brw_bufmgr *bufmgr, uint64_t size, 
uint32_t tiling)
   return size;
 
/* 965+ just need multiples of page size for tiling */
-   return ALIGN(size, 4096);
+   return ALIGN(size, PAGE_SIZE);
 }
 
 /*
@@ -1577,12 +1577,12 @@ init_cache_buckets(struct brw_bufmgr *bufmgr)
 * width/height alignment and rounding of sizes to pages will
 * get us useful cache hit rates anyway)
 */
-   add_bucket(bufmgr, 4096);
-   add_bucket(bufmgr, 4096 * 2);
-   add_bucket(bufmgr, 4096 * 3);
+   add_bucket(bufmgr, PAGE_SIZE);
+   add_bucket(bufmgr, PAGE_SIZE * 2);
+   add_bucket(bufmgr, PAGE_SIZE * 3);
 
/* Initialize the linked lists for BO reuse cache. */
-   for (size = 4 * 4096; size <= cache_max_size; size *= 2) {
+   for (size = 4 * PAGE_SIZE; size <= cache_max_size; size *= 2) {
   add_bucket(bufmgr, size);
 
   add_bucket(bufmgr, size + size * 1 / 4);
@@ -1728,7 +1728,7 @@ brw_bufmgr_init(struct gen_device_info *devinfo, int fd)
  bufmgr->initial_kflags |= EXEC_OBJECT_PINNED;
 
  util_vma_heap_init(>vma_allocator[BRW_MEMZONE_LOW_4G],
-4096, _4GB);
+PAGE_SIZE, _4GB);
  util_vma_heap_init(>vma_allocator[BRW_MEMZONE_OTHER],
 1 * _4GB, gtt_size - 1 * _4GB);
   } else if (devinfo->gen >= 10) {
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v4 1/2] intel/ppgtt: memory address alignment

2018-08-15 Thread Sergii Romantsov
Hello, Kenneth.
Thanks for remarks.
Will update patch soon and also will try to look on 3DSTATE_SO_BUFFER.

On Tue, Aug 14, 2018 at 8:39 PM, Kenneth Graunke 
wrote:

> Hi Sergii,
>
> This patch causes 2,384 failures in CI.  The issue is that we're
> apparently trying to allocate 0 size BOs in some places, which are
> getting rounded up to 4096 with the current code...but with your patch,
> we get ALIGN(0, 4096) == 0, and assert(bo_size) triggers.
>
> We might want to continue rounding up for now.  Additionally, we
> probably ought to fix the callers to stop allocating 0 size BOs.
> It looks like most of them come from the 3DSTATE_SO_BUFFER code,
> where one stream has valid transform feedback info, and the other
> 3 are empty.  Whoops.
>
> Would you like to fix that, or should I?
>
> --Ken
>
> On Tuesday, August 14, 2018 4:28:35 AM PDT Sergii Romantsov wrote:
> > Hello,
> > seems some part of the World is still may waiting for a possibility to
> play
> > Dying Light... till pushed :)
> >
> > On Mon, Aug 6, 2018 at 4:26 PM, Lionel Landwerlin <
> > lionel.g.landwer...@intel.com> wrote:
> >
> > > On 06/08/18 13:41, Sergii Romantsov wrote:
> > >
> > >> Kernel (for ppgtt) requires memory address to be
> > >> aligned to page size (4096).
> > >>
> > >> -v2: added marking that also fixes initial commit 01058a552294.
> > >> -v3: numbers replaced by PAGE_SIZE; buffer-object size is aligned
> > >> instead of alignment of offsets (Chris Wilson).
> > >> -v4: changes related to PAGE_SIZE moved to separate commit
> > >>
> > >> 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 
> > >>
> > >
> > > Reviewed-by: Lionel Landwerlin 
> > >
> > > Thanks!
> > >
> > >
> > > ---
> > >>   src/mesa/drivers/dri/i965/brw_bufmgr.c | 7 +++
> > >>   1 file changed, 3 insertions(+), 4 deletions(-)
> > >>
> > >> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > >> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > >> index 09d45e3..8274c2e 100644
> > >> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > >> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> > >> @@ -496,7 +496,6 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
> > >> uint32_t stride)
> > >>   {
> > >>  struct brw_bo *bo;
> > >> -   unsigned int page_size = getpagesize();
> > >>  int ret;
> > >>  struct bo_cache_bucket *bucket;
> > >>  bool alloc_from_cache;
> > >> @@ -522,12 +521,12 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
> > >>   * allocation up.
> > >>   */
> > >>  if (bucket == NULL) {
> > >> -  bo_size = size;
> > >> -  if (bo_size < page_size)
> > >> - bo_size = page_size;
> > >> +  unsigned int page_size = getpagesize();
> > >> +  bo_size = ALIGN(size, page_size);
> > >>  } else {
> > >> bo_size = bucket->size;
> > >>  }
> > >> +   assert(bo_size);
> > >>mtx_lock(>lock);
> > >>  /* Get a buffer out of the cache if available */
> > >>
> > >
> > >
> > > ___
> > > 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 v4 1/2] intel/ppgtt: memory address alignment

2018-08-14 Thread Sergii Romantsov
Hello,
seems some part of the World is still may waiting for a possibility to play
Dying Light... till pushed :)

On Mon, Aug 6, 2018 at 4:26 PM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> On 06/08/18 13:41, Sergii Romantsov wrote:
>
>> Kernel (for ppgtt) requires memory address to be
>> aligned to page size (4096).
>>
>> -v2: added marking that also fixes initial commit 01058a552294.
>> -v3: numbers replaced by PAGE_SIZE; buffer-object size is aligned
>> instead of alignment of offsets (Chris Wilson).
>> -v4: changes related to PAGE_SIZE moved to separate commit
>>
>> 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 
>>
>
> Reviewed-by: Lionel Landwerlin 
>
> Thanks!
>
>
> ---
>>   src/mesa/drivers/dri/i965/brw_bufmgr.c | 7 +++
>>   1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
>> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
>> index 09d45e3..8274c2e 100644
>> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
>> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
>> @@ -496,7 +496,6 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
>> uint32_t stride)
>>   {
>>  struct brw_bo *bo;
>> -   unsigned int page_size = getpagesize();
>>  int ret;
>>  struct bo_cache_bucket *bucket;
>>  bool alloc_from_cache;
>> @@ -522,12 +521,12 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
>>   * allocation up.
>>   */
>>  if (bucket == NULL) {
>> -  bo_size = size;
>> -  if (bo_size < page_size)
>> - bo_size = page_size;
>> +  unsigned int page_size = getpagesize();
>> +  bo_size = ALIGN(size, page_size);
>>  } else {
>> bo_size = bucket->size;
>>  }
>> +   assert(bo_size);
>>mtx_lock(>lock);
>>  /* Get a buffer out of the cache if available */
>>
>
>
> ___
> 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


[Mesa-dev] [PATCH v4 1/2] intel/ppgtt: memory address alignment

2018-08-06 Thread Sergii Romantsov
Kernel (for ppgtt) requires memory address to be
aligned to page size (4096).

-v2: added marking that also fixes initial commit 01058a552294.
-v3: numbers replaced by PAGE_SIZE; buffer-object size is aligned
instead of alignment of offsets (Chris Wilson).
-v4: changes related to PAGE_SIZE moved to separate commit

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 | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 09d45e3..8274c2e 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -496,7 +496,6 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
   uint32_t stride)
 {
struct brw_bo *bo;
-   unsigned int page_size = getpagesize();
int ret;
struct bo_cache_bucket *bucket;
bool alloc_from_cache;
@@ -522,12 +521,12 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
 * allocation up.
 */
if (bucket == NULL) {
-  bo_size = size;
-  if (bo_size < page_size)
- bo_size = page_size;
+  unsigned int page_size = getpagesize();
+  bo_size = ALIGN(size, page_size);
} else {
   bo_size = bucket->size;
}
+   assert(bo_size);
 
mtx_lock(>lock);
/* Get a buffer out of the cache if available */
-- 
2.7.4

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


[Mesa-dev] [PATCH v4 2/2] intel/ppgtt: 4096 replaced by PAGE_SIZE

2018-08-06 Thread Sergii Romantsov
Usage of number 4096 replaced by PAGE_SIZE.

Signed-off-by: Sergii Romantsov 
---
 src/mesa/drivers/dri/i965/brw_bufmgr.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 8274c2e..66d7751 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -195,7 +195,7 @@ bo_tile_size(struct brw_bufmgr *bufmgr, uint64_t size, 
uint32_t tiling)
   return size;
 
/* 965+ just need multiples of page size for tiling */
-   return ALIGN(size, 4096);
+   return ALIGN(size, PAGE_SIZE);
 }
 
 /*
@@ -1577,12 +1577,12 @@ init_cache_buckets(struct brw_bufmgr *bufmgr)
 * width/height alignment and rounding of sizes to pages will
 * get us useful cache hit rates anyway)
 */
-   add_bucket(bufmgr, 4096);
-   add_bucket(bufmgr, 4096 * 2);
-   add_bucket(bufmgr, 4096 * 3);
+   add_bucket(bufmgr, PAGE_SIZE);
+   add_bucket(bufmgr, PAGE_SIZE * 2);
+   add_bucket(bufmgr, PAGE_SIZE * 3);
 
/* Initialize the linked lists for BO reuse cache. */
-   for (size = 4 * 4096; size <= cache_max_size; size *= 2) {
+   for (size = 4 * PAGE_SIZE; size <= cache_max_size; size *= 2) {
   add_bucket(bufmgr, size);
 
   add_bucket(bufmgr, size + size * 1 / 4);
@@ -1728,7 +1728,7 @@ brw_bufmgr_init(struct gen_device_info *devinfo, int fd)
  bufmgr->initial_kflags |= EXEC_OBJECT_PINNED;
 
  util_vma_heap_init(>vma_allocator[BRW_MEMZONE_LOW_4G],
-4096, _4GB);
+PAGE_SIZE, _4GB);
  util_vma_heap_init(>vma_allocator[BRW_MEMZONE_OTHER],
 1 * _4GB, gtt_size - 1 * _4GB);
   } else if (devinfo->gen >= 10) {
-- 
2.7.4

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


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

2018-07-27 Thread Sergii Romantsov
Hello, Kenneth and Lionel.
Maybe, could we make a final review?

On Wed, Jul 25, 2018 at 4:24 PM, Sergii Romantsov <
sergii.romant...@globallogic.com> wrote:

> Sorry,
> do we have any objections about PAGE_SIZE usage instead of 4096?
>
> And what do you think if, maybe, some auto Intel-internal tests to run
> with that patch?
>
>
> On Wed, Jul 25, 2018 at 1:21 PM, Sergii Romantsov <
> sergii.romant...@gmail.com> wrote:
>
>> Kernel (for ppgtt) requires memory address to be
>> aligned to page size (4096).
>>
>> -v2: added marking that also fixes initial commit 01058a552294.
>> -v3: numbers replaced by PAGE_SIZE; buffer-object size is aligned
>> instead of alignment of offsets (Chris Wilson).
>>
>> 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 | 19 +--
>>  1 file changed, 9 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
>> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
>> index 09d45e3..66d7751 100644
>> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
>> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
>> @@ -195,7 +195,7 @@ bo_tile_size(struct brw_bufmgr *bufmgr, uint64_t
>> size, uint32_t tiling)
>>return size;
>>
>> /* 965+ just need multiples of page size for tiling */
>> -   return ALIGN(size, 4096);
>> +   return ALIGN(size, PAGE_SIZE);
>>  }
>>
>>  /*
>> @@ -496,7 +496,6 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
>>uint32_t stride)
>>  {
>> struct brw_bo *bo;
>> -   unsigned int page_size = getpagesize();
>> int ret;
>> struct bo_cache_bucket *bucket;
>> bool alloc_from_cache;
>> @@ -522,12 +521,12 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
>>  * allocation up.
>>  */
>> if (bucket == NULL) {
>> -  bo_size = size;
>> -  if (bo_size < page_size)
>> - bo_size = page_size;
>> +  unsigned int page_size = getpagesize();
>> +  bo_size = ALIGN(size, page_size);
>> } else {
>>bo_size = bucket->size;
>> }
>> +   assert(bo_size);
>>
>> mtx_lock(>lock);
>> /* Get a buffer out of the cache if available */
>> @@ -1578,12 +1577,12 @@ init_cache_buckets(struct brw_bufmgr *bufmgr)
>>  * width/height alignment and rounding of sizes to pages will
>>  * get us useful cache hit rates anyway)
>>  */
>> -   add_bucket(bufmgr, 4096);
>> -   add_bucket(bufmgr, 4096 * 2);
>> -   add_bucket(bufmgr, 4096 * 3);
>> +   add_bucket(bufmgr, PAGE_SIZE);
>> +   add_bucket(bufmgr, PAGE_SIZE * 2);
>> +   add_bucket(bufmgr, PAGE_SIZE * 3);
>>
>> /* Initialize the linked lists for BO reuse cache. */
>> -   for (size = 4 * 4096; size <= cache_max_size; size *= 2) {
>> +   for (size = 4 * PAGE_SIZE; size <= cache_max_size; size *= 2) {
>>add_bucket(bufmgr, size);
>>
>>add_bucket(bufmgr, size + size * 1 / 4);
>> @@ -1729,7 +1728,7 @@ brw_bufmgr_init(struct gen_device_info *devinfo,
>> int fd)
>>   bufmgr->initial_kflags |= EXEC_OBJECT_PINNED;
>>
>>   util_vma_heap_init(>vma_allocator[BRW_MEMZONE_LOW_4G],
>> -    4096, _4GB);
>> +PAGE_SIZE, _4GB);
>>   util_vma_heap_init(>vma_allocator[BRW_MEMZONE_OTHER],
>>  1 * _4GB, gtt_size - 1 * _4GB);
>>} else if (devinfo->gen >= 10) {
>> --
>> 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
>



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

2018-07-25 Thread Sergii Romantsov
Sorry,
do we have any objections about PAGE_SIZE usage instead of 4096?

And what do you think if, maybe, some auto Intel-internal tests to run with
that patch?


On Wed, Jul 25, 2018 at 1:21 PM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:

> Kernel (for ppgtt) requires memory address to be
> aligned to page size (4096).
>
> -v2: added marking that also fixes initial commit 01058a552294.
> -v3: numbers replaced by PAGE_SIZE; buffer-object size is aligned
> instead of alignment of offsets (Chris Wilson).
>
> 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 | 19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> index 09d45e3..66d7751 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> @@ -195,7 +195,7 @@ bo_tile_size(struct brw_bufmgr *bufmgr, uint64_t size,
> uint32_t tiling)
>return size;
>
> /* 965+ just need multiples of page size for tiling */
> -   return ALIGN(size, 4096);
> +   return ALIGN(size, PAGE_SIZE);
>  }
>
>  /*
> @@ -496,7 +496,6 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
>uint32_t stride)
>  {
> struct brw_bo *bo;
> -   unsigned int page_size = getpagesize();
> int ret;
> struct bo_cache_bucket *bucket;
> bool alloc_from_cache;
> @@ -522,12 +521,12 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
>  * allocation up.
>  */
> if (bucket == NULL) {
> -  bo_size = size;
> -  if (bo_size < page_size)
> - bo_size = page_size;
> +  unsigned int page_size = getpagesize();
> +  bo_size = ALIGN(size, page_size);
> } else {
>bo_size = bucket->size;
> }
> +   assert(bo_size);
>
> mtx_lock(>lock);
> /* Get a buffer out of the cache if available */
> @@ -1578,12 +1577,12 @@ init_cache_buckets(struct brw_bufmgr *bufmgr)
>  * width/height alignment and rounding of sizes to pages will
>  * get us useful cache hit rates anyway)
>  */
> -   add_bucket(bufmgr, 4096);
> -   add_bucket(bufmgr, 4096 * 2);
> -   add_bucket(bufmgr, 4096 * 3);
> +   add_bucket(bufmgr, PAGE_SIZE);
> +   add_bucket(bufmgr, PAGE_SIZE * 2);
> +   add_bucket(bufmgr, PAGE_SIZE * 3);
>
> /* Initialize the linked lists for BO reuse cache. */
> -   for (size = 4 * 4096; size <= cache_max_size; size *= 2) {
> +   for (size = 4 * PAGE_SIZE; size <= cache_max_size; size *= 2) {
>add_bucket(bufmgr, size);
>
>add_bucket(bufmgr, size + size * 1 / 4);
> @@ -1729,7 +1728,7 @@ brw_bufmgr_init(struct gen_device_info *devinfo, int
> fd)
>   bufmgr->initial_kflags |= EXEC_OBJECT_PINNED;
>
>   util_vma_heap_init(>vma_allocator[BRW_MEMZONE_LOW_4G],
> -4096, _4GB);
> +PAGE_SIZE, _4GB);
>   util_vma_heap_init(>vma_allocator[BRW_MEMZONE_OTHER],
>      1 * _4GB, gtt_size - 1 * _4GB);
>} else if (devinfo->gen >= 10) {
> --
> 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


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

2018-07-25 Thread Sergii Romantsov
Kernel (for ppgtt) requires memory address to be
aligned to page size (4096).

-v2: added marking that also fixes initial commit 01058a552294.
-v3: numbers replaced by PAGE_SIZE; buffer-object size is aligned
instead of alignment of offsets (Chris Wilson).

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 | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 09d45e3..66d7751 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -195,7 +195,7 @@ bo_tile_size(struct brw_bufmgr *bufmgr, uint64_t size, 
uint32_t tiling)
   return size;
 
/* 965+ just need multiples of page size for tiling */
-   return ALIGN(size, 4096);
+   return ALIGN(size, PAGE_SIZE);
 }
 
 /*
@@ -496,7 +496,6 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
   uint32_t stride)
 {
struct brw_bo *bo;
-   unsigned int page_size = getpagesize();
int ret;
struct bo_cache_bucket *bucket;
bool alloc_from_cache;
@@ -522,12 +521,12 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
 * allocation up.
 */
if (bucket == NULL) {
-  bo_size = size;
-  if (bo_size < page_size)
- bo_size = page_size;
+  unsigned int page_size = getpagesize();
+  bo_size = ALIGN(size, page_size);
} else {
   bo_size = bucket->size;
}
+   assert(bo_size);
 
mtx_lock(>lock);
/* Get a buffer out of the cache if available */
@@ -1578,12 +1577,12 @@ init_cache_buckets(struct brw_bufmgr *bufmgr)
 * width/height alignment and rounding of sizes to pages will
 * get us useful cache hit rates anyway)
 */
-   add_bucket(bufmgr, 4096);
-   add_bucket(bufmgr, 4096 * 2);
-   add_bucket(bufmgr, 4096 * 3);
+   add_bucket(bufmgr, PAGE_SIZE);
+   add_bucket(bufmgr, PAGE_SIZE * 2);
+   add_bucket(bufmgr, PAGE_SIZE * 3);
 
/* Initialize the linked lists for BO reuse cache. */
-   for (size = 4 * 4096; size <= cache_max_size; size *= 2) {
+   for (size = 4 * PAGE_SIZE; size <= cache_max_size; size *= 2) {
   add_bucket(bufmgr, size);
 
   add_bucket(bufmgr, size + size * 1 / 4);
@@ -1729,7 +1728,7 @@ brw_bufmgr_init(struct gen_device_info *devinfo, int fd)
  bufmgr->initial_kflags |= EXEC_OBJECT_PINNED;
 
  util_vma_heap_init(>vma_allocator[BRW_MEMZONE_LOW_4G],
-4096, _4GB);
+PAGE_SIZE, _4GB);
  util_vma_heap_init(>vma_allocator[BRW_MEMZONE_OTHER],
 1 * _4GB, gtt_size - 1 * _4GB);
   } else if (devinfo->gen >= 10) {
-- 
2.7.4

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


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

2018-07-25 Thread Sergii Romantsov
Hello, Chris.
Your variant also works.
But i wonder about comment:
   /* If we don't have caching at this size, don't actually round the
* allocation up.
*/
   if (bucket == NULL) {

Has it any sense now? If 'no' - will delete it in next patch update.

Was trying to get commit where and why it was added and it brings me to:
commit 514db96c117adc84940bb08ebd0e8f84879bd4ad
Author: Kenneth Graunke 
Date:   Mon Mar 20 16:40:01 2017 -0700

i965: Import libdrm_intel.

This imports commit 19c4cfc54918d361f2535aec16650e9f0be667cd of
libdrm/intel/*.[ch], minus a few files that we're never going to use
(and would immediately delete), plus a few necessary dependencies.

We rename intel_bufmgr.h to brw_bufmgr.h to avoid #include conflicts.
We also fix UTF-8 symbol problems in intel_bufmgr_gem.c comments
because vim keeps trying to fix that every time I edit the file,
and we may as well fix it right away.


Repository of libdrm (master and tags about 2.4.7 and 2.4.8) doesn't
contain such commit. Observed only that it fixes some crash of VB (
https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg5146035.html)

On Wed, Jul 25, 2018 at 10:48 AM, Chris Wilson 
wrote:

> Quoting Sergii Romantsov (2018-07-25 08:42:55)
> > Hello,
> > here is a backtrace:
> ...
>
> Please try:
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> index 09d45e30ecc..8274c2e0b2f 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> @@ -496,7 +496,6 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
>uint32_t stride)
>  {
> struct brw_bo *bo;
> -   unsigned int page_size = getpagesize();
> int ret;
> struct bo_cache_bucket *bucket;
> bool alloc_from_cache;
> @@ -522,12 +521,12 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
>  * allocation up.
>  */
> if (bucket == NULL) {
> -  bo_size = size;
> -  if (bo_size < page_size)
> - bo_size = page_size;
> +  unsigned int page_size = getpagesize();
> +  bo_size = ALIGN(size, page_size);
> } else {
>bo_size = bucket->size;
> }
> +   assert(bo_size);
>
> mtx_lock(>lock);
> /* Get a buffer out of the cache if available */
>



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

2018-07-25 Thread Sergii Romantsov
Hello,
here is a backtrace:

Core was generated by `glretrace ./DyingLightGame.trace'.
Program terminated with signal SIGABRT, Aborted.
#0  0x7f2852895428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f2854cb48c0 (LWP 15940))]
(gdb) bt
#0  0x7f2852895428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7f285289702a in __GI_abort () at abort.c:89
#2  0x7f285288dbd7 in __assert_fail_base (fmt=,
assertion=assertion@entry=0x7f284f4fb62f "size % 4096 == 0",
file=file@entry=0x7f284f4fb58f
"brw_bufmgr.c", line=line@entry=405,
function=function@entry=0x7f284f4fbc30 <__PRETTY_FUNCTION__.43658>
"vma_alloc") at assert.c:92
#3  0x7f285288dc82 in __GI___assert_fail (assertion=0x7f284f4fb62f
"size % 4096 == 0", file=0x7f284f4fb58f "brw_bufmgr.c", line=405,
function=0x7f284f4fbc30 <__PRETTY_FUNCTION__.43658> "vma_alloc")
at assert.c:101
#4  0x7f284ef43777 in vma_alloc (bufmgr=0x1414840,
memzone=BRW_MEMZONE_OTHER, size=255726400, alignment=4096) at
brw_bufmgr.c:405
#5  0x7f284ef43ef7 in bo_alloc_internal (bufmgr=0x1414840,
name=0x7f284f506370 "bufferobj", size=255726400, memzone=BRW_MEMZONE_OTHER,
flags=0, tiling_mode=0, stride=0) at brw_bufmgr.c:652
#6  0x7f284ef43ff7 in brw_bo_alloc (bufmgr=0x1414840,
name=0x7f284f506370 "bufferobj", size=255726400, memzone=BRW_MEMZONE_OTHER)
at brw_bufmgr.c:677
#7  0x7f284ef88465 in alloc_buffer_object (brw=0x1598d80,
intel_obj=0x1f9c68d0) at intel_buffer_objects.c:100
#8  0x7f284ef88759 in brw_buffer_data (ctx=0x1598d80, target=34962,
size=255726400, data=0x7f282f1b1010, usage=35044, storageFlags=259,
obj=0x1f9c68d0) at intel_buffer_objects.c:210
#9  0x7f284e9f33d7 in buffer_data (no_error=false, func=0x7f284f41a17c
"glBufferData", usage=35044, data=0x7f282f1b1010, size=255726400,
target=34962, bufObj=0x1f9c68d0, ctx=0x1598d80)
at main/bufferobj.c:2065
#10 buffer_data_error (ctx=0x1598d80, bufObj=0x1f9c68d0, target=34962,
size=255726400, data=0x7f282f1b1010, usage=35044, func=0x7f284f41a17c
"glBufferData") at main/bufferobj.c:2091
#11 0x7f284e9f37e3 in _mesa_buffer_data (ctx=0x1598d80,
bufObj=0x1f9c68d0, target=34962, size=255726400, data=0x7f282f1b1010,
usage=35044, func=0x7f284f41a17c "glBufferData") at main/bufferobj.c:2107
#12 0x7f284e9f38cf in _mesa_BufferData (target=34962, size=255726400,
data=0x7f282f1b1010, usage=35044) at main/bufferobj.c:2132
#13 0x004c910b in ?? ()
#14 0x0040bff4 in ?? ()
#15 0x0040c61c in ?? ()
#16 0x00407e95 in ?? ()
#17 0x7f2852880830 in __libc_start_main (main=0x407810, argc=2,
argv=0x7ffc8d9394b8, init=, fini=,
rtld_fini=, stack_end=0x7ffc8d9394a8)
at ../csu/libc-start.c:291
#18 0x0040 in _start ()


On Tue, Jul 24, 2018 at 8:43 PM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

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



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


[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] [PATCH] intel/ppgtt: memory address alignment

2018-07-23 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.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106997
Fixes: a363bb2cd0e2 (i965: Allocate VMA in userspace for full-PPGTT systems.)
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


Re: [Mesa-dev] [PATCH v2] intel/batch_decoder: decoding of 3DSTATE_CONSTANT_BODY.

2018-07-16 Thread Sergii Romantsov
Hello, Kenneth.
Any more remarks?

On Thu, Jul 12, 2018 at 3:47 PM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:

> SNB doesn't have a definition of 3DSTATE_CONSTANT_BODY, thats
> why we got segmentation fault when used INTEL_DEBUG=bat.
> Fixed by adding of 3DSTATE_CONSTANT_BODY into 3DSTATE_CONSTANT
> of VS, GS and PS structures.
>
> v2: added definition of 3DSTATE_CONSTANT_BODY to the gen6.xml
>
> Fixes: 169d8e011ae (intel: Fix 3DSTATE_CONSTANT buffer decoding.)
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107190
> Signed-off-by: Sergii Romantsov 
> ---
>  src/intel/genxml/gen6.xml | 38
> ++-
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 12 -
>  2 files changed, 20 insertions(+), 30 deletions(-)
>
> diff --git a/src/intel/genxml/gen6.xml b/src/intel/genxml/gen6.xml
> index c2967cd..62d2574 100644
> --- a/src/intel/genxml/gen6.xml
> +++ b/src/intel/genxml/gen6.xml
> @@ -622,6 +622,17 @@
>  
>
>
> +  
> + type="offset"/>
> + type="uint"/>
> + type="address"/>
> + type="uint"/>
> + type="address"/>
> + type="uint"/>
> + type="address"/>
> + type="uint"/>
> +  
> +
>
>   default="3"/>
>   default="3"/>
> @@ -633,14 +644,7 @@
>  
>   type="MEMORY_OBJECT_CONTROL_STATE"/>
>  
> - type="offset"/>
> - type="uint"/>
> - type="address"/>
> - type="uint"/>
> - type="address"/>
> - type="uint"/>
> - type="address"/>
> - type="uint"/>
> + type="3DSTATE_CONSTANT_BODY"/>
>
>
>
> @@ -654,14 +658,7 @@
>  
>   type="MEMORY_OBJECT_CONTROL_STATE"/>
>  
> - type="offset"/>
> - type="uint"/>
> - type="address"/>
> - type="uint"/>
> - type="address"/>
> - type="uint"/>
> - type="address"/>
> - type="uint"/>
> + type="3DSTATE_CONSTANT_BODY"/>
>
>
>
> @@ -675,14 +672,7 @@
>  
>   type="MEMORY_OBJECT_CONTROL_STATE"/>
>  
> - type="offset"/>
> - type="uint"/>
> - type="address"/>
> - type="uint"/>
> - type="address"/>
> - type="uint"/>
> - type="address"/>
> - type="uint"/>
> + type="3DSTATE_CONSTANT_BODY"/>
>
>
>
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index 7fe1288..a4e395c 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -1879,8 +1879,8 @@ genX(upload_wm)(struct brw_context *brw)
>   /* Pointer to the WM constant buffer.  Covered by the set of
>* state flags from gen6_upload_wm_push_constants.
>*/
> - wmcp.PointertoPSConstantBuffer0 = stage_state->push_const_
> offset;
> - wmcp.PSConstantBuffer0ReadLength = stage_state->push_const_size
> - 1;
> + wmcp.ConstantBody.PointertoConstantBuffer0 =
> stage_state->push_const_offset;
> + wmcp.ConstantBody.ConstantBuffer0ReadLength =
> stage_state->push_const_size - 1;
>}
> }
>  #endif
> @@ -2215,8 +2215,8 @@ genX(upload_vs_state)(struct brw_context *brw)
> brw_batch_emit(brw, GENX(3DSTATE_CONSTANT_VS), cvs) {
>if (stage_state->push_const_size != 0) {
>   cvs.Buffer0Valid = true;
> - cvs.PointertoVSConstantBuffer0 = stage_state->push_const_offset;
> - cvs.VSConstantBuffer0ReadLength = stage_state->push_const_size
> - 1;
> + cvs.ConstantBody.PointertoConstantBuffer0 =
> stage_state->push_const_offset;
> + cvs.ConstantBody.ConstantBuffer0ReadLength =
> stage_state->push_const_size - 1;
>}
> }
>  #endif
> @@ -2707,8 +2707,8 @@ genX(upload_gs_state)(struct brw_context *brw)
> brw_batch_emit(brw, GENX(3DSTATE_CONSTANT_GS), cgs) {
>if (active && stage_state->push_const_size != 0) {
>   cgs.Buffer0Valid = true;
> - cgs.PointertoGSConstantBuffer0 = stage_state->push_const_offset;
> - cgs.GSConstantBuffer0ReadLength = stage_state->push_const_size
> - 1;
> + cgs.ConstantBody.PointertoConstantBuffer0 =
> stage_state->push_const_offset;
> + cgs.ConstantBody.ConstantBuffer0ReadLength =
> stage_state->push_const_size - 1;
>}
> }
>  #endif
> --
> 2.7.4
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v2] intel/batch_decoder: decoding of 3DSTATE_CONSTANT_BODY.

2018-07-12 Thread Sergii Romantsov
SNB doesn't have a definition of 3DSTATE_CONSTANT_BODY, thats
why we got segmentation fault when used INTEL_DEBUG=bat.
Fixed by adding of 3DSTATE_CONSTANT_BODY into 3DSTATE_CONSTANT
of VS, GS and PS structures.

v2: added definition of 3DSTATE_CONSTANT_BODY to the gen6.xml

Fixes: 169d8e011ae (intel: Fix 3DSTATE_CONSTANT buffer decoding.)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107190
Signed-off-by: Sergii Romantsov 
---
 src/intel/genxml/gen6.xml | 38 ++-
 src/mesa/drivers/dri/i965/genX_state_upload.c | 12 -
 2 files changed, 20 insertions(+), 30 deletions(-)

diff --git a/src/intel/genxml/gen6.xml b/src/intel/genxml/gen6.xml
index c2967cd..62d2574 100644
--- a/src/intel/genxml/gen6.xml
+++ b/src/intel/genxml/gen6.xml
@@ -622,6 +622,17 @@
 
   
 
+  
+
+
+
+
+
+
+
+
+  
+
   
 
 
@@ -633,14 +644,7 @@
 
 
 
-
-
-
-
-
-
-
-
+
   
 
   
@@ -654,14 +658,7 @@
 
 
 
-
-
-
-
-
-
-
-
+
   
 
   
@@ -675,14 +672,7 @@
 
 
 
-
-
-
-
-
-
-
-
+
   
 
   
diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index 7fe1288..a4e395c 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -1879,8 +1879,8 @@ genX(upload_wm)(struct brw_context *brw)
  /* Pointer to the WM constant buffer.  Covered by the set of
   * state flags from gen6_upload_wm_push_constants.
   */
- wmcp.PointertoPSConstantBuffer0 = stage_state->push_const_offset;
- wmcp.PSConstantBuffer0ReadLength = stage_state->push_const_size - 1;
+ wmcp.ConstantBody.PointertoConstantBuffer0 = 
stage_state->push_const_offset;
+ wmcp.ConstantBody.ConstantBuffer0ReadLength = 
stage_state->push_const_size - 1;
   }
}
 #endif
@@ -2215,8 +2215,8 @@ genX(upload_vs_state)(struct brw_context *brw)
brw_batch_emit(brw, GENX(3DSTATE_CONSTANT_VS), cvs) {
   if (stage_state->push_const_size != 0) {
  cvs.Buffer0Valid = true;
- cvs.PointertoVSConstantBuffer0 = stage_state->push_const_offset;
- cvs.VSConstantBuffer0ReadLength = stage_state->push_const_size - 1;
+ cvs.ConstantBody.PointertoConstantBuffer0 = 
stage_state->push_const_offset;
+ cvs.ConstantBody.ConstantBuffer0ReadLength = 
stage_state->push_const_size - 1;
   }
}
 #endif
@@ -2707,8 +2707,8 @@ genX(upload_gs_state)(struct brw_context *brw)
brw_batch_emit(brw, GENX(3DSTATE_CONSTANT_GS), cgs) {
   if (active && stage_state->push_const_size != 0) {
  cgs.Buffer0Valid = true;
- cgs.PointertoGSConstantBuffer0 = stage_state->push_const_offset;
- cgs.GSConstantBuffer0ReadLength = stage_state->push_const_size - 1;
+ cgs.ConstantBody.PointertoConstantBuffer0 = 
stage_state->push_const_offset;
+ cgs.ConstantBody.ConstantBuffer0ReadLength = 
stage_state->push_const_size - 1;
   }
}
 #endif
-- 
2.7.4

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


[Mesa-dev] [PATCH] intel/batch_decoder: decoding of 3DSTATE_CONSTANT_BODY.

2018-07-11 Thread Sergii Romantsov
SNB doesn't have a difinition of 3DSTATE_CONSTANT_BODY, thats
why we got segmentation fault when used INTEL_DEBUG=bat.
Fixed by avoiding parsing of 3DSTATE_CONSTANT_BODY if gen_spec
is not observed.

Fixes: 169d8e011ae (intel: Fix 3DSTATE_CONSTANT buffer decoding.)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107190
Signed-off-by: Sergii Romantsov 
---
 src/intel/common/gen_batch_decoder.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/intel/common/gen_batch_decoder.c 
b/src/intel/common/gen_batch_decoder.c
index fe7536d..973221b 100644
--- a/src/intel/common/gen_batch_decoder.c
+++ b/src/intel/common/gen_batch_decoder.c
@@ -561,6 +561,10 @@ decode_3dstate_constant(struct gen_batch_decode_ctx *ctx, 
const uint32_t *p)
struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
struct gen_group *body =
   gen_spec_find_struct(ctx->spec, "3DSTATE_CONSTANT_BODY");
+   if (body == NULL) {
+  fprintf(ctx->fp, "did not find 3DSTATE_CONSTANT_BODY info\n");
+  return;
+   }
 
uint32_t read_length[4] = {0};
uint64_t read_addr[4];
-- 
2.7.4

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


[Mesa-dev] [PATCH v1] configure.ac: Missed package 'wayland-egl-backend'

2018-06-12 Thread Sergii Romantsov
Added support of wayland-egl-backend for old Ubuntus.
Building of mesa with parameter "--with-egl-platforms=x11,wayland"
fails:
"configure: error: Package requirements (wayland-egl-backend >= 3)
were not met: No package 'wayland-egl-backend' found"

Ubuntu's releases less than 18.10 don't have package
libwayland-egl-backend-dev.
To fix that issue used mesa-platfrom-header wayland-egl-backend.h.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106897
Signed-off-by: Sergii Romantsov 
---
 configure.ac  | 20 ++-
 src/egl/Makefile.am   |  5 ++
 src/egl/wayland/wayland-egl/wayland-egl-backend.h | 67 +++
 3 files changed, 91 insertions(+), 1 deletion(-)
 create mode 100644 src/egl/wayland/wayland-egl/wayland-egl-backend.h

diff --git a/configure.ac b/configure.ac
index 75ee1a7..32b3c53 100644
--- a/configure.ac
+++ b/configure.ac
@@ -91,6 +91,7 @@ LIBVA_REQUIRED=0.39.0
 VDPAU_REQUIRED=1.1
 WAYLAND_REQUIRED=1.11
 WAYLAND_EGL_BACKEND_REQUIRED=3
+UBUNTU_WAYLAND_EGL_BACKEND_REQUIRED=18.10
 WAYLAND_PROTOCOLS_REQUIRED=1.8
 XCB_REQUIRED=1.9.3
 XCBDRI2_REQUIRED=1.8
@@ -1810,7 +1811,24 @@ for plat in $platforms; do
 PKG_CHECK_MODULES([WAYLAND_SERVER], [wayland-server >= 
$WAYLAND_REQUIRED])
 PKG_CHECK_MODULES([WAYLAND_PROTOCOLS], [wayland-protocols >= 
$WAYLAND_PROTOCOLS_REQUIRED])
 if test "x$enable_egl" = xyes; then
-  PKG_CHECK_MODULES([WAYLAND_EGL], [wayland-egl-backend >= 
$WAYLAND_EGL_BACKEND_REQUIRED])
+  case "$host_os" in
+  linux*)
+  AC_SUBST([DISTRIBUTOR_ID],[$( lsb_release -is )])
+  AC_SUBST([RELEASE_VERSION],[$( lsb_release -rs )])
+  ;;
+  *)
+  AC_SUBST([DISTRIBUTOR_ID])
+  AC_SUBST([RELEASE_VERSION])
+  ;;
+  esac
+
+  if test "$DISTRIBUTOR_ID" = "Ubuntu" -a  $RELEASE_VERSION \< 
$UBUNTU_WAYLAND_EGL_BACKEND_REQUIRED ; then
+  DEFINES="$DEFINES -DHAVE_PLATFORM_WAYLAND_BACKEND"
+  AM_CONDITIONAL([HAVE_PLATFORM_WAYLAND_BACKEND], [test "xyes" = 
xyes])
+  else
+  PKG_CHECK_MODULES([WAYLAND_EGL], [wayland-egl-backend >= 
$WAYLAND_EGL_BACKEND_REQUIRED])
+  AM_CONDITIONAL([HAVE_PLATFORM_WAYLAND_BACKEND], [test "xyes" != 
xyes])
+  fi
 fi
 WAYLAND_PROTOCOLS_DATADIR=`$PKG_CONFIG --variable=pkgdatadir 
wayland-protocols`
 
diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
index be3547d..0ef0a42 100644
--- a/src/egl/Makefile.am
+++ b/src/egl/Makefile.am
@@ -121,6 +121,11 @@ AM_CFLAGS += \
-DDEFAULT_DRIVER_DIR=\"$(DRI_DRIVER_SEARCH_DIR)\" \
-D_EGL_BUILT_IN_DRIVER_DRI2
 
+if HAVE_PLATFORM_WAYLAND_BACKEND
+AM_CFLAGS += \
+   -I$(top_srcdir)/src/egl/wayland/wayland-egl
+endif
+
 nodist_libEGL_common_la_SOURCES = \
$(dri2_backend_GENERATED_FILES)
 
diff --git a/src/egl/wayland/wayland-egl/wayland-egl-backend.h 
b/src/egl/wayland/wayland-egl/wayland-egl-backend.h
new file mode 100644
index 000..869c86f
--- /dev/null
+++ b/src/egl/wayland/wayland-egl/wayland-egl-backend.h
@@ -0,0 +1,67 @@
+/*
+ * Copyright © 2011 Benjamin Franzke
+ *
+ * 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.
+ *
+ * Authors:
+ *Benjamin Franzke 
+ */
+
+#ifndef _WAYLAND_EGL_PRIV_H
+#define _WAYLAND_EGL_PRIV_H
+
+#include 
+
+#ifdef  __cplusplus
+extern "C" {
+#endif
+
+/*
+ * NOTE: This version must be kept in sync with the Version field in the
+ * wayland-egl-backend.pc.in file.
+ */
+#define WL_EGL_WINDOW_VERSION 3
+
+struct wl_surface;
+
+struct wl_egl_window {
+   const intptr_t version;
+
+   int width;
+   int height;
+   int dx;
+   int dy;
+
+   int attach

Re: [Mesa-dev] [PATCH] dri3: Only update number of back buffers in loader_dri3_get_buffers

2018-04-30 Thread Sergii Romantsov
Hello,
with my simple tests it works, but have some remarks (but don't have much
experience with dri3):

1. It looks little dangerous to move logic of destroying buffers and seems
in your version we are loosing some logic with 'busy' and 'num_back'
2. And also looks like buffers just will not be destroyed on time for some
cases.
3. From my opinion it will be safer to use in function 'dri3_get_buffer'
call (with my patch):
 'dri3_fence_await(draw->conn, NULL, buffer)' instead of
'dri3_fence_await(draw->conn, draw, buffer)'

On Fri, Apr 27, 2018 at 6:56 PM, Michel Dänzer <mic...@daenzer.net> wrote:

> From: Michel Dänzer <michel.daen...@amd.com>
>
> And only free no longer needed back buffers there as well.
>
> We want to stick to the same back buffer throughout a frame, otherwise
> we can run into various issues.
>
> Bugzilla: https://bugs.freedesktop.org/105906
> Fixes: 3160cb86aa92 "egl/x11: Re-allocate buffers if format is suboptimal"
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
> ---
>
> Sergii, Eero, here's an alternative fix which I think is cleaner, can
> you test it?
>
>  src/loader/loader_dri3_helper.c | 19 +++
>  1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_
> helper.c
> index 23729f7ecb2..6db8303d26d 100644
> --- a/src/loader/loader_dri3_helper.c
> +++ b/src/loader/loader_dri3_helper.c
> @@ -420,13 +420,6 @@ dri3_handle_present_event(struct
> loader_dri3_drawable *draw,
>
>   if (buf && buf->pixmap == ie->pixmap)
>  buf->busy = 0;
> -
> - if (buf && draw->cur_blit_source != b && !buf->busy &&
> - (buf->reallocate ||
> - (draw->num_back <= b && b < LOADER_DRI3_MAX_BACK))) {
> -dri3_free_render_buffer(draw, buf);
> -draw->buffers[b] = NULL;
> - }
>}
>break;
> }
> @@ -559,7 +552,6 @@ dri3_find_back(struct loader_dri3_drawable *draw)
> /* Check whether we need to reuse the current back buffer as new back.
>  * In that case, wait until it's not busy anymore.
>  */
> -   dri3_update_num_back(draw);
> num_to_consider = draw->num_back;
> if (!loader_dri3_have_image_blit(draw) && draw->cur_blit_source !=
> -1) {
>num_to_consider = 1;
> @@ -1815,6 +1807,7 @@ loader_dri3_get_buffers(__DRIdrawable *driDrawable,
>  {
> struct loader_dri3_drawable *draw = loaderPrivate;
> struct loader_dri3_buffer   *front, *back;
> +   int buf_id;
>
> buffers->image_mask = 0;
> buffers->front = NULL;
> @@ -1826,6 +1819,16 @@ loader_dri3_get_buffers(__DRIdrawable *driDrawable,
> if (!dri3_update_drawable(driDrawable, draw))
>return false;
>
> +   dri3_update_num_back(draw);
> +
> +   /* Free no longer needed back buffers */
> +   for (buf_id = draw->num_back; buf_id < LOADER_DRI3_MAX_BACK; buf_id++)
> {
> +  if (draw->cur_blit_source != buf_id && draw->buffers[buf_id]) {
> + dri3_free_render_buffer(draw, draw->buffers[buf_id]);
> + draw->buffers[buf_id] = NULL;
> +  }
> +   }
> +
> /* pixmaps always have front buffers.
>  * Exchange swaps also mandate fake front buffers.
>  */
> --
> 2.17.0
>
>


-- 
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 v2] dri3: Prevent multiple freeing of buffers.

2018-04-27 Thread Sergii Romantsov
Hello, Michel

On 2018-04-10 09:44 AM, Sergii Romantsov wrote:
> Commit 3160cb86aa92 adds optimization with flag 'reallocate'.
> Processing of flag causes buffers freeing while pointer
> is still hold in caller stack and than again used to be freed.
>
> Fixes: 3160cb86aa92 "egl/x11: Re-allocate buffers if format is suboptimal"
>
> v2:
>  used flag 'busy' instead of introducing new one.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105906
> Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
> Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
> ---
>  src/loader/loader_dri3_helper.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_
helper.c
> index fe17df1..a934db1 100644
> --- a/src/loader/loader_dri3_helper.c
> +++ b/src/loader/loader_dri3_helper.c
> @@ -1688,6 +1688,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> (buffer_type == loader_dri3_buffer_front &&
draw->have_fake_front))
>&& buffer) {
>
> + buffer->busy = true;
>   /* Fill the new buffer with data from an old buffer */
>   dri3_fence_await(draw->conn, draw, buffer);
>   if (!loader_dri3_blit_image(draw,

Hello, Michel,
I've updated patch according to your remarks:
https://lists.freedesktop.org/archives/mesa-dev/2018-April/193331.html

And about question

> This seems a bit of a hack. Will this always be cleared again, in
> particular if it's the fake front buffer?
>
There are seems no needs in clearing due the next step is unconditional
freeing of that buffer by call 'dri3_free_render_buffer(draw, buffer)'.


On Thu, Apr 26, 2018 at 7:43 PM, Michel Dänzer <mic...@daenzer.net> wrote:

> On 2018-04-10 09:44 AM, Sergii Romantsov wrote:
> > Commit 3160cb86aa92 adds optimization with flag 'reallocate'.
> > Processing of flag causes buffers freeing while pointer
> > is still hold in caller stack and than again used to be freed.
> >
> > Fixes: 3160cb86aa92 "egl/x11: Re-allocate buffers if format is
> suboptimal"
> >
> > v2:
> >  used flag 'busy' instead of introducing new one.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105906
> > Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
> > Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
> > ---
> >  src/loader/loader_dri3_helper.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_
> helper.c
> > index fe17df1..a934db1 100644
> > --- a/src/loader/loader_dri3_helper.c
> > +++ b/src/loader/loader_dri3_helper.c
> > @@ -1688,6 +1688,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> > (buffer_type == loader_dri3_buffer_front &&
> draw->have_fake_front))
> >&& buffer) {
> >
> > + buffer->busy = true;
> >   /* Fill the new buffer with data from an old buffer */
> >   dri3_fence_await(draw->conn, draw, buffer);
> >   if (!loader_dri3_blit_image(draw,
>
> This seems a bit of a hack. Will this always be cleared again, in
> particular if it's the fake front buffer?
>
>
> > @@ -1731,6 +1732,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> >draw->buffers[buf_id] = buffer;
> > }
> > dri3_fence_await(draw->conn, draw, buffer);
> > +   buffer = draw->buffers[buf_id];
>
> This should be something like
>
>if (buffer_type == loader_dri3_buffer_back) {
>   buf_id = dri3_find_back(draw);
>
>   if (buf_id < 0)
>  return NULL;
>}
>buffer = draw->buffers[buf_id];
>
> to get the now-current back buffer.
>
>
> > @@ -1744,7 +1746,8 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> > if (buffer_type == loader_dri3_buffer_back &&
> > draw->cur_blit_source != -1 &&
> > draw->buffers[draw->cur_blit_source] &&
> > -   buffer != draw->buffers[draw->cur_blit_source]) {
> > +   buffer != draw->buffers[draw->cur_blit_source] &&
> > +   buffer != NULL) {
> >
> >struct loader_dri3_buffer *source = draw->buffers[draw->cur_blit_
> source];
> >
> >
>
> With the above, this NULL guard isn't needed.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v3] dri3: Prevent multiple freeing of buffers.

2018-04-27 Thread Sergii Romantsov
Commit 3160cb86aa92 adds optimization with flag 'reallocate'.
Processing of flag causes buffers freeing while pointer
is still hold in caller stack and than again used to be freed.

Fixes: 3160cb86aa92 "egl/x11: Re-allocate buffers if format is suboptimal"

v2:
 used flag 'busy' instead of introducing new one.
v3:
 added searching for back-buffer after potential freeing previous one.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105906
Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
---
 src/loader/loader_dri3_helper.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index fe17df1..6524afc 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -1688,6 +1688,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
(buffer_type == loader_dri3_buffer_front && draw->have_fake_front))
   && buffer) {
 
+ buffer->busy = true;
  /* Fill the new buffer with data from an old buffer */
  dri3_fence_await(draw->conn, draw, buffer);
  if (!loader_dri3_blit_image(draw,
@@ -1731,6 +1732,12 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
   draw->buffers[buf_id] = buffer;
}
dri3_fence_await(draw->conn, draw, buffer);
+   if (buffer_type == loader_dri3_buffer_back) {
+  buf_id = dri3_find_back(draw);
+  if (buf_id < 0)
+  return NULL;
+   }
+   buffer = draw->buffers[buf_id];
 
/*
 * Do we need to preserve the content of a previous buffer?
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] dri3: Prevent multiple freeing of buffers.

2018-04-16 Thread Sergii Romantsov
Hello (ping) Thomas and Daniel,
any more suggestions? As i can see Eero has done a test-run and v2 also
looks good.

As alternative solution we also may try to call '*dri3_fence_await(draw->conn,
draw, buffer)'* with '*draw*'-parameter as '*NULL'.*
What do you think?

On Tue, Apr 10, 2018 at 11:10 AM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:

> Hello,
> i've updated patch simply,
> but that seems requires additional checking because in call 
> *dri3_handle_present_event
> *potentially may happens reset of '*busy*' with condition '*buf->pixmap
> == ie->pixmap*'
>
> On Fri, Apr 6, 2018 at 9:03 PM, Thomas Hellstrom <thellst...@vmware.com>
> wrote:
>
>> Hi,
>>
>>
>> On 04/06/2018 04:51 PM, Daniel Stone wrote:
>>
>>> Hi Sergii,
>>>
>>> On 6 April 2018 at 09:12, Sergii Romantsov <sergii.romant...@gmail.com>
>>> wrote:
>>>
>>>> Commit 3160cb86aa92 adds optimization with flag 'reallocate'.
>>>> Processing of flag causes buffers freeing while pointer
>>>> is still hold in caller stack and than again used to be freed.
>>>>
>>> Thanks a lot for writing this. I take it the core of the problem is
>>> that dri3_handle_present_event() can be called whilst we're inside
>>> dri3_get_buffer(), which wasn't the case before.
>>>
>>> This was only introduced as of a727c804a2c1, and I'm not sure I fully
>>> follow the rationale for that commit. Thomas, why do we need to
>>> process the events? I guess we could also fake it by turning 'busy'
>>> into a refcount, which would be incremented/decremented as it is today
>>> when posting buffers and getting Idle events, but also when we're
>>> holding a local pointer which we can't have stolen from under us.
>>>
>>> Cheers,
>>> Daniel
>>>
>>
>> The motivation for this commit IIRC was that with internal glretrace
>> automated tests, we typically would end up with corrupt rendering due to
>> invalid viewports after window resizes. The resize events were typically
>> not picked up as fast with dri3 as with dri2, so due to the lack of
>> documented strategy how to handle window- and viewport resizes with dri3
>> clients, I tried to make it mimic dri2 where we had no such issues. The
>> reason for the slow pick up was that dri3 was waiting for fences rather
>> than on X replies...
>>
>> /Thomas
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] dri3: Prevent multiple freeing of buffers.

2018-04-10 Thread Sergii Romantsov
Hello,
i've updated patch simply,
but that seems requires additional checking because in call
*dri3_handle_present_event
*potentially may happens reset of '*busy*' with condition '*buf->pixmap ==
ie->pixmap*'

On Fri, Apr 6, 2018 at 9:03 PM, Thomas Hellstrom <thellst...@vmware.com>
wrote:

> Hi,
>
>
> On 04/06/2018 04:51 PM, Daniel Stone wrote:
>
>> Hi Sergii,
>>
>> On 6 April 2018 at 09:12, Sergii Romantsov <sergii.romant...@gmail.com>
>> wrote:
>>
>>> Commit 3160cb86aa92 adds optimization with flag 'reallocate'.
>>> Processing of flag causes buffers freeing while pointer
>>> is still hold in caller stack and than again used to be freed.
>>>
>> Thanks a lot for writing this. I take it the core of the problem is
>> that dri3_handle_present_event() can be called whilst we're inside
>> dri3_get_buffer(), which wasn't the case before.
>>
>> This was only introduced as of a727c804a2c1, and I'm not sure I fully
>> follow the rationale for that commit. Thomas, why do we need to
>> process the events? I guess we could also fake it by turning 'busy'
>> into a refcount, which would be incremented/decremented as it is today
>> when posting buffers and getting Idle events, but also when we're
>> holding a local pointer which we can't have stolen from under us.
>>
>> Cheers,
>> Daniel
>>
>
> The motivation for this commit IIRC was that with internal glretrace
> automated tests, we typically would end up with corrupt rendering due to
> invalid viewports after window resizes. The resize events were typically
> not picked up as fast with dri3 as with dri2, so due to the lack of
> documented strategy how to handle window- and viewport resizes with dri3
> clients, I tried to make it mimic dri2 where we had no such issues. The
> reason for the slow pick up was that dri3 was waiting for fences rather
> than on X replies...
>
> /Thomas
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v2] dri3: Prevent multiple freeing of buffers.

2018-04-10 Thread Sergii Romantsov
Commit 3160cb86aa92 adds optimization with flag 'reallocate'.
Processing of flag causes buffers freeing while pointer
is still hold in caller stack and than again used to be freed.

Fixes: 3160cb86aa92 "egl/x11: Re-allocate buffers if format is suboptimal"

v2:
 used flag 'busy' instead of introducing new one.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105906
Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
---
 src/loader/loader_dri3_helper.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index fe17df1..a934db1 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -1688,6 +1688,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
(buffer_type == loader_dri3_buffer_front && draw->have_fake_front))
   && buffer) {
 
+ buffer->busy = true;
  /* Fill the new buffer with data from an old buffer */
  dri3_fence_await(draw->conn, draw, buffer);
  if (!loader_dri3_blit_image(draw,
@@ -1731,6 +1732,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
   draw->buffers[buf_id] = buffer;
}
dri3_fence_await(draw->conn, draw, buffer);
+   buffer = draw->buffers[buf_id];
 
/*
 * Do we need to preserve the content of a previous buffer?
@@ -1744,7 +1746,8 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
if (buffer_type == loader_dri3_buffer_back &&
draw->cur_blit_source != -1 &&
draw->buffers[draw->cur_blit_source] &&
-   buffer != draw->buffers[draw->cur_blit_source]) {
+   buffer != draw->buffers[draw->cur_blit_source] &&
+   buffer != NULL) {
 
   struct loader_dri3_buffer *source = draw->buffers[draw->cur_blit_source];
 
-- 
2.7.4

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


[Mesa-dev] [PATCH] dri3: Prevent multiple freeing of buffers.

2018-04-06 Thread Sergii Romantsov
Commit 3160cb86aa92 adds optimization with flag 'reallocate'.
Processing of flag causes buffers freeing while pointer
is still hold in caller stack and than again used to be freed.

Fixes: 3160cb86aa92 "egl/x11: Re-allocate buffers if format is suboptimal"

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105906
Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
---
 src/loader/loader_dri3_helper.c | 7 +--
 src/loader/loader_dri3_helper.h | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index fe17df1..5f9cc42 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -422,7 +422,7 @@ dri3_handle_present_event(struct loader_dri3_drawable *draw,
 buf->busy = 0;
 
  if (buf && draw->cur_blit_source != b && !buf->busy &&
- (buf->reallocate ||
+ ((buf->reallocate && !buf->in_use_to_destroy) ||
  (draw->num_back <= b && b < LOADER_DRI3_MAX_BACK))) {
 dri3_free_render_buffer(draw, buf);
 draw->buffers[b] = NULL;
@@ -1688,6 +1688,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
(buffer_type == loader_dri3_buffer_front && draw->have_fake_front))
   && buffer) {
 
+ buffer->in_use_to_destroy = true;
  /* Fill the new buffer with data from an old buffer */
  dri3_fence_await(draw->conn, draw, buffer);
  if (!loader_dri3_blit_image(draw,
@@ -1731,6 +1732,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
   draw->buffers[buf_id] = buffer;
}
dri3_fence_await(draw->conn, draw, buffer);
+   buffer = draw->buffers[buf_id];
 
/*
 * Do we need to preserve the content of a previous buffer?
@@ -1744,7 +1746,8 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
if (buffer_type == loader_dri3_buffer_back &&
draw->cur_blit_source != -1 &&
draw->buffers[draw->cur_blit_source] &&
-   buffer != draw->buffers[draw->cur_blit_source]) {
+   buffer != draw->buffers[draw->cur_blit_source] &&
+   buffer != NULL) {
 
   struct loader_dri3_buffer *source = draw->buffers[draw->cur_blit_source];
 
diff --git a/src/loader/loader_dri3_helper.h b/src/loader/loader_dri3_helper.h
index 7e3d829..9232d61 100644
--- a/src/loader/loader_dri3_helper.h
+++ b/src/loader/loader_dri3_helper.h
@@ -62,6 +62,7 @@ struct loader_dri3_buffer {
bool busy;   /* Set on swap, cleared on IdleNotify */
bool own_pixmap; /* We allocated the pixmap ID, free on destroy 
*/
bool reallocate; /* Buffer should be reallocated and not reused 
*/
+   bool in_use_to_destroy; /* Buffer is in use and will be 
destroyed soon */
 
uint32_t num_planes;
uint32_t size;
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

2018-04-04 Thread Sergii Romantsov
Hello, Mark.
I've done: Cc, Tested-by and Reviewed-by also added.

On Wed, Apr 4, 2018 at 8:16 AM, Mark Janes <mark.a.ja...@intel.com> wrote:

> This patch passes Intel's CI suites.
> It needs a CC for stable in the commit message.
>
> Tested-by: Mark Janes <mark.a.ja...@intel.com>
>
> Sergii Romantsov <sergii.romant...@gmail.com> writes:
>
> > Gen8+ use 48-bit address relocations so need to extend the sign
> > to 64-bit return value. Without it we have higher bits zeroed
> > and missing the negavive values.
> > Haswell and older use 32-bit deltas so are unaffected by this issue.
> >
> > v2:
> >   used int32_t fucntion parameter instead of explicit type conversion.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
> > Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
> > Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
> > ---
> >  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > index ebc02ff..7286140 100644
> > --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > @@ -1079,7 +1079,7 @@ brw_batch_references(struct intel_batchbuffer
> *batch, struct brw_bo *bo)
> >  static uint64_t
> >  emit_reloc(struct intel_batchbuffer *batch,
> > struct brw_reloc_list *rlist, uint32_t offset,
> > -   struct brw_bo *target, uint32_t target_offset,
> > +   struct brw_bo *target, int32_t target_offset,
> > unsigned int reloc_flags)
> >  {
> > assert(target != NULL);
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v3] i965: Extend the negative 32-bit deltas to 64-bits

2018-04-04 Thread Sergii Romantsov
Gen8+ use 48-bit address relocations so need to extend the sign
to 64-bit return value. Without it we have higher bits zeroed
and missing the negavive values.
Haswell and older use 32-bit deltas so are unaffected by this issue.

v2:
  used int32_t fucntion parameter instead of explicit type conversion.

v3:
  added "Cc" into commit-message.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: "18.0" <mesa-sta...@lists.freedesktop.org>
Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
Tested-by: Mark Janes <mark.a.ja...@intel.com>
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index ebc02ff..7286140 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -1079,7 +1079,7 @@ brw_batch_references(struct intel_batchbuffer *batch, 
struct brw_bo *bo)
 static uint64_t
 emit_reloc(struct intel_batchbuffer *batch,
struct brw_reloc_list *rlist, uint32_t offset,
-   struct brw_bo *target, uint32_t target_offset,
+   struct brw_bo *target, int32_t target_offset,
unsigned int reloc_flags)
 {
assert(target != NULL);
-- 
2.7.4

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


[Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

2018-04-02 Thread Sergii Romantsov
Gen8+ use 48-bit address relocations so need to extend the sign
to 64-bit return value. Without it we have higher bits zeroed
and missing the negavive values.
Haswell and older use 32-bit deltas so are unaffected by this issue.

v2:
  used int32_t fucntion parameter instead of explicit type conversion.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index ebc02ff..7286140 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -1079,7 +1079,7 @@ brw_batch_references(struct intel_batchbuffer *batch, 
struct brw_bo *bo)
 static uint64_t
 emit_reloc(struct intel_batchbuffer *batch,
struct brw_reloc_list *rlist, uint32_t offset,
-   struct brw_bo *target, uint32_t target_offset,
+   struct brw_bo *target, int32_t target_offset,
unsigned int reloc_flags)
 {
assert(target != NULL);
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

2018-03-27 Thread Sergii Romantsov
Hello Chris and Emil.
Could we make a final decision? Because I'm bit confused what you are
expecting exactly.

I would prefer to left initial patch as is (if its possible).

On Tue, Mar 27, 2018 at 9:20 AM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:

> Hello Stuart,
> Nice to hear.
> And thanks for your time and contribution.
>
> On Tue, Mar 27, 2018 at 8:40 AM, Stuart Young <cef...@gmail.com> wrote:
>
>> Hi Sergii,
>>
>> I built this into mesa 17.3.7 and it seems to solve all the issues I've
>> seen that were mentioned in 101408.
>>
>> This includes not just the issues with the Mortar, but the other visual
>> artefacts that I've noticed with the player models and with other weapons
>> in the game.
>>
>> Many thanks for digging into this.
>>
>>
>> On 26 March 2018 at 23:22, Sergii Romantsov <
>> sergii.romant...@globallogic.com> wrote:
>>
>>> Hello, Stuart.
>>> Could You, please, test this patch?
>>>
>>> On Mon, Mar 26, 2018 at 3:16 PM, Sergii Romantsov <
>>> sergii.romant...@gmail.com> wrote:
>>>
>>>> Negative deltas are used to fake a range in a large buffer.
>>>> See 900a5c91eeb3
>>>> "i965: Use negative relocation deltas to minimise vertex uploads"
>>>>
>>>> Gen8+ use 48-bit address relocations so need to extend the sign
>>>> to 64-bit return value. Without it we have higher bits zeroed
>>>> and missing the negavive values.
>>>> Haswell and older use 32-bit deltas so are unaffected by this issue.
>>>>
>>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
>>>> Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
>>>> Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
>>>> ---
>>>>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>>>> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>>>> index d824ff2..128da77 100644
>>>> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>>>> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>>>> @@ -1124,8 +1124,10 @@ emit_reloc(struct intel_batchbuffer *batch,
>>>> /* Using the old buffer offset, write in what the right data would
>>>> be, in
>>>>  * case the buffer doesn't move and we can short-circuit the
>>>> relocation
>>>>  * processing in the kernel
>>>> +*
>>>> +* Some target_offsets may be negative, so extend the sign to 64
>>>> bits.
>>>>  */
>>>> -   return entry->offset + target_offset;
>>>> +   return entry->offset + (int64_t)((int32_t)target_offset);
>>>>  }
>>>>
>>>>  uint64_t
>>>> --
>>>> 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
>>>
>>
>>
>>
>> --
>> Stuart Young (aka Cefiar)
>>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

2018-03-27 Thread Sergii Romantsov
Hello Stuart,
Nice to hear.
And thanks for your time and contribution.

On Tue, Mar 27, 2018 at 8:40 AM, Stuart Young <cef...@gmail.com> wrote:

> Hi Sergii,
>
> I built this into mesa 17.3.7 and it seems to solve all the issues I've
> seen that were mentioned in 101408.
>
> This includes not just the issues with the Mortar, but the other visual
> artefacts that I've noticed with the player models and with other weapons
> in the game.
>
> Many thanks for digging into this.
>
>
> On 26 March 2018 at 23:22, Sergii Romantsov <sergii.romantsov@globallogic.
> com> wrote:
>
>> Hello, Stuart.
>> Could You, please, test this patch?
>>
>> On Mon, Mar 26, 2018 at 3:16 PM, Sergii Romantsov <
>> sergii.romant...@gmail.com> wrote:
>>
>>> Negative deltas are used to fake a range in a large buffer.
>>> See 900a5c91eeb3
>>> "i965: Use negative relocation deltas to minimise vertex uploads"
>>>
>>> Gen8+ use 48-bit address relocations so need to extend the sign
>>> to 64-bit return value. Without it we have higher bits zeroed
>>> and missing the negavive values.
>>> Haswell and older use 32-bit deltas so are unaffected by this issue.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
>>> Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
>>> Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
>>> ---
>>>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>>> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>>> index d824ff2..128da77 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>>> @@ -1124,8 +1124,10 @@ emit_reloc(struct intel_batchbuffer *batch,
>>> /* Using the old buffer offset, write in what the right data would
>>> be, in
>>>  * case the buffer doesn't move and we can short-circuit the
>>> relocation
>>>  * processing in the kernel
>>> +*
>>> +* Some target_offsets may be negative, so extend the sign to 64
>>> bits.
>>>  */
>>> -   return entry->offset + target_offset;
>>> +   return entry->offset + (int64_t)((int32_t)target_offset);
>>>  }
>>>
>>>  uint64_t
>>> --
>>> 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
>>
>
>
>
> --
> Stuart Young (aka Cefiar)
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

2018-03-26 Thread Sergii Romantsov
Hello, Emil. Thanks for involving.
> Fixes: cee9f3890351 ("i965: Allow 48-bit addressing on Gen8+.")

Actually that patch doesn't fix exactly cee9f3890351. Also I wrote earlier
(probably, my e-mails may go into spam :)):
"That issue is present even on mesa 13-0.0 and also solved with similar
type-conversion fix."

On Mon, Mar 26, 2018 at 4:57 PM, Emil Velikov <emil.l.veli...@gmail.com>
wrote:

> On 26 March 2018 at 13:31, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> > Quoting Sergii Romantsov (2018-03-26 13:16:24)
> >> Negative deltas are used to fake a range in a large buffer.
> >> See 900a5c91eeb3
> >> "i965: Use negative relocation deltas to minimise vertex uploads"
> >>
> >> Gen8+ use 48-bit address relocations so need to extend the sign
> >
> > Note that 48-bit relocations were only switched on in
> > commit cee9f3890351 ("i965: Allow 48-bit addressing on Gen8+.")
> > to save having to backport too far (although the patch is trivial).
> >
> Agreed, one could backport it for older instances, although it seems
> unneeded.
> Please use a simple fixes tag like:
>
> Fixes: cee9f3890351 ("i965: Allow 48-bit addressing on Gen8+.")
>
> >> to 64-bit return value. Without it we have higher bits zeroed
> >> and missing the negavive values.
> >> Haswell and older use 32-bit deltas so are unaffected by this issue.
> >>
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
> >> Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
> >> Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
> >> ---
> >>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> >> index d824ff2..128da77 100644
> >> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> >> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> >> @@ -1124,8 +1124,10 @@ emit_reloc(struct intel_batchbuffer *batch,
> >> /* Using the old buffer offset, write in what the right data would
> be, in
> >>  * case the buffer doesn't move and we can short-circuit the
> relocation
> >>  * processing in the kernel
> >> +*
> >> +* Some target_offsets may be negative, so extend the sign to 64
> bits.
> >>  */
> >> -   return entry->offset + target_offset;
> >> +   return entry->offset + (int64_t)((int32_t)target_offset);
> >
> > Although just changing s/uint32_t target_offset/int32_t target_offset/
> > may be cleaner.
>
> Seems like there's plenty of users that opt for unsigned. Might be
> better to address the issue as-is and as a follow-up do a consistent
> to-signed sweep.
> It keeps the fix small and simple, plus avoids a ton of extra warnings
> [for those using -W*sign*] ;-)
>
> -Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

2018-03-26 Thread Sergii Romantsov
Hello, Chris. Thank you for reviewing patch.
Do you mean changing just only emit_reloc() parameter type or all the
preceding callers too?

Also, please, explain what you mean about patch cee9f3890351?
That issue is present even on mesa 13-0.0 and also solved with similar
type-conversion fix.


Regards, Sergii.

On Mon, Mar 26, 2018 at 3:31 PM, Chris Wilson <ch...@chris-wilson.co.uk>
wrote:

> Quoting Sergii Romantsov (2018-03-26 13:16:24)
> > Negative deltas are used to fake a range in a large buffer.
> > See 900a5c91eeb3
> > "i965: Use negative relocation deltas to minimise vertex uploads"
> >
> > Gen8+ use 48-bit address relocations so need to extend the sign
>
> Note that 48-bit relocations were only switched on in
> commit cee9f3890351 ("i965: Allow 48-bit addressing on Gen8+.")
> to save having to backport too far (although the patch is trivial).
>
> > to 64-bit return value. Without it we have higher bits zeroed
> > and missing the negavive values.
> > Haswell and older use 32-bit deltas so are unaffected by this issue.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
> > Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
> > Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
> > ---
> >  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > index d824ff2..128da77 100644
> > --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > @@ -1124,8 +1124,10 @@ emit_reloc(struct intel_batchbuffer *batch,
> > /* Using the old buffer offset, write in what the right data would
> be, in
> >  * case the buffer doesn't move and we can short-circuit the
> relocation
> >  * processing in the kernel
> > +*
> > +* Some target_offsets may be negative, so extend the sign to 64
> bits.
> >  */
> > -   return entry->offset + target_offset;
> > +   return entry->offset + (int64_t)((int32_t)target_offset);
>
> Although just changing s/uint32_t target_offset/int32_t target_offset/
> may be cleaner.
> -Chris
> ___
> 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] i965: Extend the negative 32-bit deltas to 64-bits

2018-03-26 Thread Sergii Romantsov
Hello, Stuart.
Could You, please, test this patch?

On Mon, Mar 26, 2018 at 3:16 PM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:

> Negative deltas are used to fake a range in a large buffer.
> See 900a5c91eeb3
> "i965: Use negative relocation deltas to minimise vertex uploads"
>
> Gen8+ use 48-bit address relocations so need to extend the sign
> to 64-bit return value. Without it we have higher bits zeroed
> and missing the negavive values.
> Haswell and older use 32-bit deltas so are unaffected by this issue.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
> Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
> Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
> ---
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index d824ff2..128da77 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -1124,8 +1124,10 @@ emit_reloc(struct intel_batchbuffer *batch,
> /* Using the old buffer offset, write in what the right data would be,
> in
>  * case the buffer doesn't move and we can short-circuit the relocation
>  * processing in the kernel
> +*
> +* Some target_offsets may be negative, so extend the sign to 64 bits.
>  */
> -   return entry->offset + target_offset;
> +   return entry->offset + (int64_t)((int32_t)target_offset);
>  }
>
>  uint64_t
> --
> 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


[Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

2018-03-26 Thread Sergii Romantsov
Negative deltas are used to fake a range in a large buffer.
See 900a5c91eeb3
"i965: Use negative relocation deltas to minimise vertex uploads"

Gen8+ use 48-bit address relocations so need to extend the sign
to 64-bit return value. Without it we have higher bits zeroed
and missing the negavive values.
Haswell and older use 32-bit deltas so are unaffected by this issue.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
Signed-off-by: Sergii Romantsov <sergii.romant...@globallogic.com>
Tested-by: Andriy Khulap <andriy.khu...@globallogic.com>
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index d824ff2..128da77 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -1124,8 +1124,10 @@ emit_reloc(struct intel_batchbuffer *batch,
/* Using the old buffer offset, write in what the right data would be, in
 * case the buffer doesn't move and we can short-circuit the relocation
 * processing in the kernel
+*
+* Some target_offsets may be negative, so extend the sign to 64 bits.
 */
-   return entry->offset + target_offset;
+   return entry->offset + (int64_t)((int32_t)target_offset);
 }
 
 uint64_t
-- 
2.7.4

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