Re: [Mesa-dev] Getting write permissions on the mesa repo to push panfrost stuff

[Boris Brezillon]

On Thu, 04 Jul 2019 20:49:32 -0700
Kenneth Graunke  wrote:

> On Thursday, July 4, 2019 5:23:44 AM PDT Boris Brezillon wrote:
> > Hello,
> > 
> > Alyssa recently proposed that I push my own panfrost-related
> > submissions once they received proper review and are considered
> > ready to merged (meaning that received enough A-b/R-b tags).
> > 
> > In order to do that, I'd need to obtain write permissions on the git
> > repo. Note that I already have an account on fd.o (my nick is
> > bbrezillon). I guess Alyssa and/or Tomew will ack this request soon. Let
> > me know if you need anything else from me.
> > 
> > Regards,
> > 
> > Boris  
> 
> Hi there!
> 
> I just added @bbrezillon as a "Developer" on gitlab.fdo/mesa, which
> should grant you commit access!
> 
> I noticed that there are two similar looking Gitlab accounts:
> 
> @bbrezillon - Boris Brezillon
> @bbrezillion - Boris Brezillon
> 
> The former seems to be active, and the latter not so much.  Is that also
> yours - just a typo?

Yes, the latter (the one with a typo) has been created back when I
started contributing to igt and drm-misc, but I don't remember the
password, and I no longer have access to my @free-electrons (or
@bootlin, I dont rememenber) address, which means I can't reset the
password.

> Should it be deleted?

Note that I still contribute to drm-misc and might have to push things
to igt at some point (I don't need a password for that, I push
through ssh). If you delete the account, can you make sure the new one
also has push rights to those repos (those 2 are not on gitlab.fd.o
IIRC)?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Set minimum possible GLSL version

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 

On Fri, Jul 5, 2019 at 12:59 AM Ian Romanick  wrote:
>
> From: Ian Romanick 
>
> Set the absolute minimum possible GLSL version.  API_OPENGL_CORE can
> mean an OpenGL 3.0 forward-compatible context, so that implies a minimum
> possible version of 1.30.  Otherwise, the minimum possible version 1.20.
> Since Mesa unconditionally advertises GL_ARB_shading_language_100 and
> GL_ARB_shader_objects, every driver has GLSL 1.20... even if they don't
> advertise any extensions to enable any shader stages (e.g.,
> GL_ARB_vertex_shader).
>
> Converts about 2,500 piglit tests from crash to skip on NV18.
> ---
>  src/mesa/main/context.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
> index e5a89d9c2fc..516660d55d2 100644
> --- a/src/mesa/main/context.c
> +++ b/src/mesa/main/context.c
> @@ -616,6 +616,17 @@ _mesa_init_constants(struct gl_constants *consts, gl_api 
> api)
> consts->MaxProgramMatrices = MAX_PROGRAM_MATRICES;
> consts->MaxProgramMatrixStackDepth = MAX_PROGRAM_MATRIX_STACK_DEPTH;
>
> +   /* Set the absolute minimum possible GLSL version.  API_OPENGL_CORE can
> +* mean an OpenGL 3.0 forward-compatible context, so that implies a 
> minimum
> +* possible version of 1.30.  Otherwise, the minimum possible version 
> 1.20.
> +* Since Mesa unconditionally advertises GL_ARB_shading_language_100 and
> +* GL_ARB_shader_objects, every driver has GLSL 1.20... even if they don't
> +* advertise any extensions to enable any shader stages (e.g.,
> +* GL_ARB_vertex_shader).
> +*/
> +   consts->GLSLVersion = api == API_OPENGL_CORE ? 130 : 120;
> +   consts->GLSLVersionCompat = consts->GLSLVersion;
> +
> /* Assume that if GLSL 1.30+ (or GLSL ES 3.00+) is supported that
>  * gl_VertexID is implemented using a native hardware register with OpenGL
>  * semantics.
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: avoid _mesa_problem invocation when running on drivers without glsl

[Ilia Mirkin]

On Fri, Jul 5, 2019 at 12:56 AM Ian Romanick  wrote:
>
> On 7/4/19 4:21 PM, Ilia Mirkin wrote:
> > For example wine might query GL_SHADING_LANGUAGE_VERSION on a driver
> > that doesn't support GLSL. This is not a problem in itself, we can just
> > return a INVALID_ENUM error.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109524
> > Signed-off-by: Ilia Mirkin 
> > ---
> >  src/mesa/main/getstring.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/src/mesa/main/getstring.c b/src/mesa/main/getstring.c
> > index 3d5ae0b694b..6c0dd9048da 100644
> > --- a/src/mesa/main/getstring.c
> > +++ b/src/mesa/main/getstring.c
> > @@ -150,6 +150,8 @@ _mesa_GetString( GLenum name )
> >case GL_SHADING_LANGUAGE_VERSION:
> >   if (ctx->API == API_OPENGLES)
> >  break;
> > + if (_mesa_is_desktop_gl(ctx) && ctx->Const.GLSLVersion == 0)
> > +break;
>
> GLSL version should never be zero.  We advertise GL_ARB_shading_language
> in all drivers, so every driver has "GLSL" even if it doesn't have
> vertex shaders or fragment shaders.  I thought I sent out a patch some
> time ago that set GLSLVersion to 120 by default to avoid problems like this.

That may be, but either they weren't merged, or other things changed
in between which nullified their effect. Currently
_mesa_compute_version will leave GLSLVersion blank for pre-GL 2.0
contexts. FWIW this makes wine work ok:

diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 5f004ff1dab..948bdbcc891 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -634,6 +634,8 @@ _mesa_compute_version(struct gl_context *ctx)
   default:
  if (ctx->Version >= 33)
 ctx->Const.GLSLVersion = ctx->Version * 10;
+ else
+ctx->Const.GLSLVersion = 120;
  break;
   }
}


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

[Mesa-dev] [PATCH] mesa: Set minimum possible GLSL version

[Ian Romanick]

From: Ian Romanick 

Set the absolute minimum possible GLSL version.  API_OPENGL_CORE can
mean an OpenGL 3.0 forward-compatible context, so that implies a minimum
possible version of 1.30.  Otherwise, the minimum possible version 1.20.
Since Mesa unconditionally advertises GL_ARB_shading_language_100 and
GL_ARB_shader_objects, every driver has GLSL 1.20... even if they don't
advertise any extensions to enable any shader stages (e.g.,
GL_ARB_vertex_shader).

Converts about 2,500 piglit tests from crash to skip on NV18.
---
 src/mesa/main/context.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index e5a89d9c2fc..516660d55d2 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -616,6 +616,17 @@ _mesa_init_constants(struct gl_constants *consts, gl_api 
api)
consts->MaxProgramMatrices = MAX_PROGRAM_MATRICES;
consts->MaxProgramMatrixStackDepth = MAX_PROGRAM_MATRIX_STACK_DEPTH;
 
+   /* Set the absolute minimum possible GLSL version.  API_OPENGL_CORE can
+* mean an OpenGL 3.0 forward-compatible context, so that implies a minimum
+* possible version of 1.30.  Otherwise, the minimum possible version 1.20.
+* Since Mesa unconditionally advertises GL_ARB_shading_language_100 and
+* GL_ARB_shader_objects, every driver has GLSL 1.20... even if they don't
+* advertise any extensions to enable any shader stages (e.g.,
+* GL_ARB_vertex_shader).
+*/
+   consts->GLSLVersion = api == API_OPENGL_CORE ? 130 : 120;
+   consts->GLSLVersionCompat = consts->GLSLVersion;
+
/* Assume that if GLSL 1.30+ (or GLSL ES 3.00+) is supported that
 * gl_VertexID is implemented using a native hardware register with OpenGL
 * semantics.
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH] mesa: avoid _mesa_problem invocation when running on drivers without glsl

[Ian Romanick]

On 7/4/19 4:21 PM, Ilia Mirkin wrote:
> For example wine might query GL_SHADING_LANGUAGE_VERSION on a driver
> that doesn't support GLSL. This is not a problem in itself, we can just
> return a INVALID_ENUM error.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109524
> Signed-off-by: Ilia Mirkin 
> ---
>  src/mesa/main/getstring.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/mesa/main/getstring.c b/src/mesa/main/getstring.c
> index 3d5ae0b694b..6c0dd9048da 100644
> --- a/src/mesa/main/getstring.c
> +++ b/src/mesa/main/getstring.c
> @@ -150,6 +150,8 @@ _mesa_GetString( GLenum name )
>case GL_SHADING_LANGUAGE_VERSION:
>   if (ctx->API == API_OPENGLES)
>  break;
> + if (_mesa_is_desktop_gl(ctx) && ctx->Const.GLSLVersion == 0)
> +break;

GLSL version should never be zero.  We advertise GL_ARB_shading_language
in all drivers, so every driver has "GLSL" even if it doesn't have
vertex shaders or fragment shaders.  I thought I sent out a patch some
time ago that set GLSLVersion to 120 by default to avoid problems like this.

>return shading_language_version(ctx);
>case GL_PROGRAM_ERROR_STRING_ARB:
>   if (ctx->API == API_OPENGL_COMPAT &&
> 

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

Re: [Mesa-dev] Getting write permissions on the mesa repo to push panfrost stuff

[Kenneth Graunke]

On Thursday, July 4, 2019 5:23:44 AM PDT Boris Brezillon wrote:
> Hello,
> 
> Alyssa recently proposed that I push my own panfrost-related
> submissions once they received proper review and are considered
> ready to merged (meaning that received enough A-b/R-b tags).
> 
> In order to do that, I'd need to obtain write permissions on the git
> repo. Note that I already have an account on fd.o (my nick is
> bbrezillon). I guess Alyssa and/or Tomew will ack this request soon. Let
> me know if you need anything else from me.
> 
> Regards,
> 
> Boris

Hi there!

I just added @bbrezillon as a "Developer" on gitlab.fdo/mesa, which
should grant you commit access!

I noticed that there are two similar looking Gitlab accounts:

@bbrezillon - Boris Brezillon
@bbrezillion - Boris Brezillon

The former seems to be active, and the latter not so much.  Is that also
yours - just a typo?  Should it be deleted?  Just wanted to make sure
people aren't trying to spoof you, and that I got the right account...

--Ken


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

[Mesa-dev] [Bug 110735] Meson can't find 32-bit libXvMCW in non-standard path

[bugzilla-daemon]

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

--- Comment #3 from charlie  ---
I can wait.

Setting "-Dc_link_args" in a config file results in:
meson: error: unrecognized arguments: ..

So I set it in a meson crossfile like:
[properties]
c_link_args = ['-L /home/a/lib32']

Results in 'XvMCW not found'.

I also tried setting a native file
(https://mesonbuild.com/Native-environments.html) mesa32.ini like:

[paths]
libdir = '/home/a/lib32'
prefix = '/home/a'

Still not found.

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

[Mesa-dev] [PATCH] mesa: avoid _mesa_problem invocation when running on drivers without glsl

[Ilia Mirkin]

For example wine might query GL_SHADING_LANGUAGE_VERSION on a driver
that doesn't support GLSL. This is not a problem in itself, we can just
return a INVALID_ENUM error.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109524
Signed-off-by: Ilia Mirkin 
---
 src/mesa/main/getstring.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/main/getstring.c b/src/mesa/main/getstring.c
index 3d5ae0b694b..6c0dd9048da 100644
--- a/src/mesa/main/getstring.c
+++ b/src/mesa/main/getstring.c
@@ -150,6 +150,8 @@ _mesa_GetString( GLenum name )
   case GL_SHADING_LANGUAGE_VERSION:
  if (ctx->API == API_OPENGLES)
 break;
+ if (_mesa_is_desktop_gl(ctx) && ctx->Const.GLSLVersion == 0)
+break;
 return shading_language_version(ctx);
   case GL_PROGRAM_ERROR_STRING_ARB:
  if (ctx->API == API_OPENGL_COMPAT &&
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH] gallium: remove boolean from state tracker APIs

[Timothy Arceri]

Looks good to me.

Reviewed-by: Timothy Arceri 

On 5/7/19 5:36 am, Ilia Mirkin wrote:

Signed-off-by: Ilia Mirkin 
---

It's actually a bit tricky to compile all the bits involved, so some of
this is untested. However if it so happens that I missed a spot, it
should be trivial to fix.

  src/gallium/include/state_tracker/graw.h  |  8 +-
  src/gallium/include/state_tracker/st_api.h| 73 +--
  src/gallium/include/state_tracker/sw_winsys.h |  5 +-
  src/gallium/state_trackers/dri/dri_drawable.c | 34 -
  src/gallium/state_trackers/dri/dri_drawable.h |  6 +-
  src/gallium/state_trackers/dri/dri_screen.c   |  8 +-
  src/gallium/state_trackers/glx/xlib/xm_st.c   | 24 +++---
  src/gallium/state_trackers/glx/xlib/xm_st.h   |  2 +-
  src/gallium/state_trackers/hgl/hgl.c  | 14 ++--
  src/gallium/state_trackers/osmesa/osmesa.c|  8 +-
  src/gallium/state_trackers/wgl/stw_st.c   | 14 ++--
  src/gallium/state_trackers/wgl/stw_st.h   |  2 +-
  src/gallium/targets/graw-null/graw_util.c | 14 ++--
  src/gallium/winsys/sw/dri/dri_sw_winsys.c | 12 +--
  src/gallium/winsys/sw/gdi/gdi_sw_winsys.c | 10 +--
  src/gallium/winsys/sw/hgl/hgl_sw_winsys.c |  8 +-
  .../winsys/sw/kms-dri/kms_dri_sw_winsys.c | 12 +--
  src/gallium/winsys/sw/null/null_sw_winsys.c   |  8 +-
  .../winsys/sw/wrapper/wrapper_sw_winsys.c | 10 +--
  src/gallium/winsys/sw/xlib/xlib_sw_winsys.c   | 14 ++--
  src/mesa/state_tracker/st_manager.c   | 50 ++---
  src/mesa/state_tracker/st_manager.h   |  2 +-
  22 files changed, 168 insertions(+), 170 deletions(-)

diff --git a/src/gallium/include/state_tracker/graw.h 
b/src/gallium/include/state_tracker/graw.h
index 78ddf0a87f7..af81cc8871b 100644
--- a/src/gallium/include/state_tracker/graw.h
+++ b/src/gallium/include/state_tracker/graw.h
@@ -79,7 +79,7 @@ PUBLIC void *graw_parse_fragment_shader( struct pipe_context 
*pipe,
   * If an option has been successfully parsed, argi is updated
   * to point just after the option and return TRUE.
   */
-PUBLIC boolean graw_parse_args(int *argi, int argc, char *argv[]);
+PUBLIC bool graw_parse_args(int *argi, int argc, char *argv[]);
  
  /* Saves surface contents to a file.

   *
@@ -89,8 +89,8 @@ PUBLIC boolean graw_parse_args(int *argi, int argc, char 
*argv[]);
   *
   * Returns TRUE if the surface has been saved.
   */
-PUBLIC boolean graw_save_surface_to_file(struct pipe_context *pipe,
- struct pipe_surface *surface,
- const char *filename);
+PUBLIC bool graw_save_surface_to_file(struct pipe_context *pipe,
+  struct pipe_surface *surface,
+  const char *filename);
  
  #endif

diff --git a/src/gallium/include/state_tracker/st_api.h 
b/src/gallium/include/state_tracker/st_api.h
index 2b63b8a3d2a..b2b81b6ebc4 100644
--- a/src/gallium/include/state_tracker/st_api.h
+++ b/src/gallium/include/state_tracker/st_api.h
@@ -27,7 +27,6 @@
  #ifndef _ST_API_H_
  #define _ST_API_H_
  
-#include "pipe/p_compiler.h"

  #include "pipe/p_format.h"
  
  /**

@@ -218,19 +217,19 @@ struct st_visual
   */
  struct st_config_options
  {
-   boolean disable_blend_func_extended;
-   boolean disable_glsl_line_continuations;
-   boolean force_glsl_extensions_warn;
+   bool disable_blend_func_extended;
+   bool disable_glsl_line_continuations;
+   bool force_glsl_extensions_warn;
 unsigned force_glsl_version;
-   boolean allow_glsl_extension_directive_midshader;
-   boolean allow_glsl_builtin_const_expression;
-   boolean allow_glsl_relaxed_es;
-   boolean allow_glsl_builtin_variable_redeclaration;
-   boolean allow_higher_compat_version;
-   boolean glsl_zero_init;
-   boolean force_glsl_abs_sqrt;
-   boolean allow_glsl_cross_stage_interpolation_mismatch;
-   boolean allow_glsl_layout_qualifier_on_function_parameters;
+   bool allow_glsl_extension_directive_midshader;
+   bool allow_glsl_builtin_const_expression;
+   bool allow_glsl_relaxed_es;
+   bool allow_glsl_builtin_variable_redeclaration;
+   bool allow_higher_compat_version;
+   bool glsl_zero_init;
+   bool force_glsl_abs_sqrt;
+   bool allow_glsl_cross_stage_interpolation_mismatch;
+   bool allow_glsl_layout_qualifier_on_function_parameters;
 unsigned char config_options_sha1[20];
  };
  
@@ -319,9 +318,9 @@ struct st_framebuffer_iface

  *
  * @att is one of the front buffer attachments.
  */
-   boolean (*flush_front)(struct st_context_iface *stctx,
-  struct st_framebuffer_iface *stfbi,
-  enum st_attachment_type statt);
+   bool (*flush_front)(struct st_context_iface *stctx,
+   struct st_framebuffer_iface *stfbi,
+   enum st_attachment_type statt);
  
 /**

  * The state tracker asks for the textures it needs.
@@ -340,13 +339,13 @@ struct st_framebuffer_iface
  * 

[Mesa-dev] [PATCH] gallium: remove boolean from state tracker APIs

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---

It's actually a bit tricky to compile all the bits involved, so some of
this is untested. However if it so happens that I missed a spot, it
should be trivial to fix.

 src/gallium/include/state_tracker/graw.h  |  8 +-
 src/gallium/include/state_tracker/st_api.h| 73 +--
 src/gallium/include/state_tracker/sw_winsys.h |  5 +-
 src/gallium/state_trackers/dri/dri_drawable.c | 34 -
 src/gallium/state_trackers/dri/dri_drawable.h |  6 +-
 src/gallium/state_trackers/dri/dri_screen.c   |  8 +-
 src/gallium/state_trackers/glx/xlib/xm_st.c   | 24 +++---
 src/gallium/state_trackers/glx/xlib/xm_st.h   |  2 +-
 src/gallium/state_trackers/hgl/hgl.c  | 14 ++--
 src/gallium/state_trackers/osmesa/osmesa.c|  8 +-
 src/gallium/state_trackers/wgl/stw_st.c   | 14 ++--
 src/gallium/state_trackers/wgl/stw_st.h   |  2 +-
 src/gallium/targets/graw-null/graw_util.c | 14 ++--
 src/gallium/winsys/sw/dri/dri_sw_winsys.c | 12 +--
 src/gallium/winsys/sw/gdi/gdi_sw_winsys.c | 10 +--
 src/gallium/winsys/sw/hgl/hgl_sw_winsys.c |  8 +-
 .../winsys/sw/kms-dri/kms_dri_sw_winsys.c | 12 +--
 src/gallium/winsys/sw/null/null_sw_winsys.c   |  8 +-
 .../winsys/sw/wrapper/wrapper_sw_winsys.c | 10 +--
 src/gallium/winsys/sw/xlib/xlib_sw_winsys.c   | 14 ++--
 src/mesa/state_tracker/st_manager.c   | 50 ++---
 src/mesa/state_tracker/st_manager.h   |  2 +-
 22 files changed, 168 insertions(+), 170 deletions(-)

diff --git a/src/gallium/include/state_tracker/graw.h 
b/src/gallium/include/state_tracker/graw.h
index 78ddf0a87f7..af81cc8871b 100644
--- a/src/gallium/include/state_tracker/graw.h
+++ b/src/gallium/include/state_tracker/graw.h
@@ -79,7 +79,7 @@ PUBLIC void *graw_parse_fragment_shader( struct pipe_context 
*pipe,
  * If an option has been successfully parsed, argi is updated
  * to point just after the option and return TRUE.
  */
-PUBLIC boolean graw_parse_args(int *argi, int argc, char *argv[]);
+PUBLIC bool graw_parse_args(int *argi, int argc, char *argv[]);
 
 /* Saves surface contents to a file.
  *
@@ -89,8 +89,8 @@ PUBLIC boolean graw_parse_args(int *argi, int argc, char 
*argv[]);
  *
  * Returns TRUE if the surface has been saved.
  */
-PUBLIC boolean graw_save_surface_to_file(struct pipe_context *pipe,
- struct pipe_surface *surface,
- const char *filename);
+PUBLIC bool graw_save_surface_to_file(struct pipe_context *pipe,
+  struct pipe_surface *surface,
+  const char *filename);
 
 #endif
diff --git a/src/gallium/include/state_tracker/st_api.h 
b/src/gallium/include/state_tracker/st_api.h
index 2b63b8a3d2a..b2b81b6ebc4 100644
--- a/src/gallium/include/state_tracker/st_api.h
+++ b/src/gallium/include/state_tracker/st_api.h
@@ -27,7 +27,6 @@
 #ifndef _ST_API_H_
 #define _ST_API_H_
 
-#include "pipe/p_compiler.h"
 #include "pipe/p_format.h"
 
 /**
@@ -218,19 +217,19 @@ struct st_visual
  */
 struct st_config_options
 {
-   boolean disable_blend_func_extended;
-   boolean disable_glsl_line_continuations;
-   boolean force_glsl_extensions_warn;
+   bool disable_blend_func_extended;
+   bool disable_glsl_line_continuations;
+   bool force_glsl_extensions_warn;
unsigned force_glsl_version;
-   boolean allow_glsl_extension_directive_midshader;
-   boolean allow_glsl_builtin_const_expression;
-   boolean allow_glsl_relaxed_es;
-   boolean allow_glsl_builtin_variable_redeclaration;
-   boolean allow_higher_compat_version;
-   boolean glsl_zero_init;
-   boolean force_glsl_abs_sqrt;
-   boolean allow_glsl_cross_stage_interpolation_mismatch;
-   boolean allow_glsl_layout_qualifier_on_function_parameters;
+   bool allow_glsl_extension_directive_midshader;
+   bool allow_glsl_builtin_const_expression;
+   bool allow_glsl_relaxed_es;
+   bool allow_glsl_builtin_variable_redeclaration;
+   bool allow_higher_compat_version;
+   bool glsl_zero_init;
+   bool force_glsl_abs_sqrt;
+   bool allow_glsl_cross_stage_interpolation_mismatch;
+   bool allow_glsl_layout_qualifier_on_function_parameters;
unsigned char config_options_sha1[20];
 };
 
@@ -319,9 +318,9 @@ struct st_framebuffer_iface
 *
 * @att is one of the front buffer attachments.
 */
-   boolean (*flush_front)(struct st_context_iface *stctx,
-  struct st_framebuffer_iface *stfbi,
-  enum st_attachment_type statt);
+   bool (*flush_front)(struct st_context_iface *stctx,
+   struct st_framebuffer_iface *stfbi,
+   enum st_attachment_type statt);
 
/**
 * The state tracker asks for the textures it needs.
@@ -340,13 +339,13 @@ struct st_framebuffer_iface
 * the last call might be destroyed.  This behavior might change in the
 * future.
 */
-   boolean (*validate)(struct st_context_iface *stctx,
- 

[Mesa-dev] [Bug 110735] Meson can't find 32-bit libXvMCW in non-standard path

[bugzilla-daemon]

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

--- Comment #2 from Dylan Baker  ---
I'm not at my computer right now (its a holiday here), but you might be
able to fix this by seeing -Dc_link_args="-L /path/with/xvmc"

I'm on mobile, please excuse autocorrect fail.

On Thu, Jul 4, 2019, 00:32  wrote:

> *Comment # 1  on
> bug 110735  from
> charlie  *
>
> As a temporary work around--link to code from non-standard directory to the
> 32-bit /usr/lib directory, for example:
>
> if [[ $ARCH == *86 ]]; then
> sudo find ${HOME}/lib32/ -name "libXvMC*" -type f -maxdepth 1 -exec bash -c 
> 'ln
> -s "$0" /usr/lib/"${0##*/}"' {} \;
> sudo find ${HOME}/lib32/ -name "libXvMC*" -type l -maxdepth 1 -exec bash -c 
> 'ln
> -s "$0" /usr/lib/"${0##*/}"' {} \;
> fi
>
> Then delete links after compiling finishes:
>
> sudo rm /usr/lib/libXvMC*
>
> _
> Update: setting an rpath on 32-bit complied libXvMC* would still not let Meson
> find the libs.
>
> --
> You are receiving this mail because:
>
>- You are on the CC list for the bug.
>
>

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

[Mesa-dev] [PATCH] dma-buf: Update docs to discourage use of dma_buf_mmap()

[Steven Price]

dma_buf_mmap() allows a device driver to forward a mmap() call to the
dma_buf exporter. However this mechanism provides no way for userspace
to use the DMA_BUF_IOCTL_SYNC mechanism to ensure coherency with the
mapped buffer.

Because of this it is wise to migrate away from providing this
mmap() forwarding mechanism and update drivers to avoid using it.
However the user ABI must be maintained, so this existing mmap()
forwarding cannot be removed.

Signed-off-by: Steven Price 
---
 drivers/dma-buf/dma-buf.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index bf4d4c80fbc6..2a7a2c8c4182 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -731,20 +731,17 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
  *
  * - And as a CPU fallback in userspace processing pipelines.
  *
- *   Similar to the motivation for kernel cpu access it is again important that
- *   the userspace code of a given importing subsystem can use the same
- *   interfaces with a imported dma-buf buffer object as with a native buffer
- *   object. This is especially important for drm where the userspace part of
- *   contemporary OpenGL, X, and other drivers is huge, and reworking them to
- *   use a different way to mmap a buffer rather invasive.
+ *   Ideally userspace code should directly mmap the dma-buf fd which allows
+ *   the use of the SYNC_START/SYNC_END ioctls as detailed above. However there
+ *   are situations where there is a large body of existing code and reworking
+ *   it to support a different way to mmap a buffer is rather invasive.
  *
- *   The assumption in the current dma-buf interfaces is that redirecting the
- *   initial mmap is all that's needed. A survey of some of the existing
- *   subsystems shows that no driver seems to do any nefarious thing like
- *   syncing up with outstanding asynchronous processing on the device or
- *   allocating special resources at fault time. So hopefully this is good
- *   enough, since adding interfaces to intercept pagefaults and allow pte
- *   shootdowns would increase the complexity quite a bit.
+ *   Some drivers therefore provide an interface that simply redirects the
+ *   mmap to the dma-buf exporter. This is fine as long as the SYNC_START and
+ *   SYNC_END ioctls don't do anything, but may lead to coherency issues
+ *   if they are required. New code should avoid using this because of
+ *   potentially hard to debug coherency problems. The interface, however,
+ *   remains for backwards compatibility.
  *
  *   Interface::
  *  int dma_buf_mmap(struct dma_buf \*, struct vm_area_struct \*,
-- 
2.20.1

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

[Mesa-dev] [Bug 111051] Mesa crashed on KDE Plasma Wayland session

[bugzilla-daemon]

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

--- Comment #2 from Strangiato  ---
Created attachment 144703
  --> https://bugs.freedesktop.org/attachment.cgi?id=144703=edit
kwin settings

(In reply to Denis from comment #1)
> hi Strangiato. Provide please your GPU (or CPU) version, if I have it - I
> will try to reproduce issue.
intel hd graphics, intel celeron G1820 cpu.


> Also:
> >I can't reproduce consistently, the crash occurred just once.
> but in the original ticket you provided steps and wrote that this crash is
> reproducible for you. That's correct?
The steps are correct.
However the crash is not reproducible, it was my mistake while I was reporting
the crash.


I'm attaching my kwin settings.

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

Re: [Mesa-dev] [PATCH kmscube] Search for a suitable config

[Emil Velikov]

On Wed, 3 Jul 2019 at 08:16, Drew DeVault  wrote:
>
> Instead of assuming the first will be suitable. kmscube fails to start
> for me without this change.

Yes please. Picking the first one is rarely the correct thing to do.
Especially when we have platform specific attributes which are exempt
from the sorting rules.

> ---
>  common.c | 52 +---
>  common.h |  1 +
>  2 files changed, 46 insertions(+), 7 deletions(-)
>
> diff --git a/common.c b/common.c
> index f9bd280..45c074d 100644
> --- a/common.c
> +++ b/common.c
> @@ -24,11 +24,47 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
>  #include "common.h"
>
> +static bool egl_get_config(EGLDisplay disp, EGLint *attribs,
Nit: "const EGLint *attribs" and keep the const notation in the parent function.

> +   EGLConfig *out, EGLint visual_id) {
Nit: { on the next line

> +   EGLint count = 0, matched = 0, ret;
> +
> +   ret = eglGetConfigs(disp, NULL, 0, );
> +   if (ret == EGL_FALSE || count == 0) {
> +   printf("eglGetConfigs returned no configs\n");
> +   return false;
> +   }
> +
> +   EGLConfig configs[count];
> +
VLAs are convenient, although they lead to messy binary, are not
supported on some platforms etc.
How about:

EGLConfig configs[128];
assert(count...)

> +   ret = eglChooseConfig(disp, attribs, configs, count, );
> +   if (ret == EGL_FALSE) {
> +   printf("eglChooseConfig failed\n");
> +   return false;
> +   }
> +
> +   for (int i = 0; i < matched; ++i) {
> +   EGLint visual;
> +   if (!eglGetConfigAttrib(disp, configs[i],
> +   EGL_NATIVE_VISUAL_ID, )) {
> +   continue;
> +   }
> +
> +   if (!visual_id || visual == visual_id) {
> +   *out = configs[i];
> +   return true;
> +   }
> +   }
> +
> +   printf("no valid egl config found\n");
> +   return false;
> +}
> +
>  struct gbm * init_gbm(int drm_fd, int w, int h)
>  {
>  struct gbm *gbm = calloc(1, sizeof (struct gbm));
> @@ -59,7 +95,7 @@ int init_egl(struct egl *egl, const struct gbm *gbm)
> EGL_NONE
> };
>
> -   static const EGLint config_attribs[] = {
> +   static EGLint config_attribs[] = {
Nit: Keep the const.

> EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
> EGL_RED_SIZE, 1,
> EGL_GREEN_SIZE, 1,
> @@ -81,9 +117,10 @@ int init_egl(struct egl *egl, const struct gbm *gbm)
> get_proc(eglDestroySyncKHR);
> get_proc(eglWaitSyncKHR);
> get_proc(eglDupNativeFenceFDANDROID);
> +   get_proc(eglCreatePlatformWindowSurfaceEXT);
Move this and associated changes to a separate commit, preserving the
fallback to eglCreateWindowSurface().

>
> if (egl->eglGetPlatformDisplayEXT) {
> -   egl->display = 
> egl->eglGetPlatformDisplayEXT(EGL_PLATFORM_GBM_KHR,
> +   egl->display = 
> egl->eglGetPlatformDisplayEXT(EGL_PLATFORM_GBM_MESA,
Out of curiosity: Both constants are numerically the same. Why the change?

> gbm->dev, NULL);
> } else {
> egl->display = eglGetDisplay((void *)gbm->dev);
> @@ -106,8 +143,9 @@ int init_egl(struct egl *egl, const struct gbm *gbm)
> return -1;
> }
>
> -   if (!eglChooseConfig(egl->display, config_attribs, >config, 1, 
> ) || n != 1) {
> -   printf("failed to choose config: %d\n", n);
> +   if (!egl_get_config(egl->display, config_attribs,
> +   >config, GBM_FORMAT_XRGB)) {
Let's use gbm.format instead of open-coding it.

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

Re: [Mesa-dev] Getting write permissions on the mesa repo to push panfrost stuff

[Emil Velikov]

On Thu, 4 Jul 2019 at 13:23, Boris Brezillon
 wrote:
>
> Hello,
>
> Alyssa recently proposed that I push my own panfrost-related
> submissions once they received proper review and are considered
> ready to merged (meaning that received enough A-b/R-b tags).
>
> In order to do that, I'd need to obtain write permissions on the git
> repo. Note that I already have an account on fd.o (my nick is
> bbrezillon). I guess Alyssa and/or Tomew will ack this request soon. Let
> me know if you need anything else from me.
>
You have 29 patches and are always welcome to feedback. With my mesa hat on:
Acked-by: Emil Velikov 

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

[Mesa-dev] Getting write permissions on the mesa repo to push panfrost stuff

[Boris Brezillon]

Hello,

Alyssa recently proposed that I push my own panfrost-related
submissions once they received proper review and are considered
ready to merged (meaning that received enough A-b/R-b tags).

In order to do that, I'd need to obtain write permissions on the git
repo. Note that I already have an account on fd.o (my nick is
bbrezillon). I guess Alyssa and/or Tomew will ack this request soon. Let
me know if you need anything else from me.

Regards,

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

Re: [Mesa-dev] [PATCH] panfrost: Take into account off-screen FBOs

[Erik Faye-Lund]

On Thu, 2019-07-04 at 10:02 +0200, Tomeu Vizoso wrote:
> In that case, ctx->pipe_framebuffer.cbufs[0] can be NULL.
> 
> Signed-off-by: Tomeu Vizoso 
> Cc: Boris Brezillon 
> Fixes: 5375d009be18 ("panfrost: Pass referenced BOs to the SUBMIT
> ioctls")

Nit: this isn't really about off-screen vs on-screen, but rendering
with vs without a color-buffer. Sure, non-color buffers can't be on-
screen, but you can have off-screen color-buffers as well.

I know this patch already landed, but if you keep this in mind for the
future, perhaps we can avoid confusing commit messages.

> ---
>  src/gallium/drivers/panfrost/pan_drm.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/panfrost/pan_drm.c
> b/src/gallium/drivers/panfrost/pan_drm.c
> index 8de4f483435c..b89f8e66a877 100644
> --- a/src/gallium/drivers/panfrost/pan_drm.c
> +++ b/src/gallium/drivers/panfrost/pan_drm.c
> @@ -238,7 +238,6 @@ panfrost_drm_submit_job(struct panfrost_context
> *ctx, u64 job_desc, int reqs)
>  int
>  panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx, bool
> has_draws, bool is_scanout)
>  {
> -struct pipe_surface *surf = ctx->pipe_framebuffer.cbufs[0];
>   int ret;
>  
>  struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
> @@ -256,9 +255,12 @@ panfrost_drm_submit_vs_fs_job(struct
> panfrost_context *ctx, bool has_draws, bool
>  }
>  
>  if (job->first_tiler.gpu || job->clear) {
> -struct panfrost_resource *res = pan_resource(surf-
> >texture);
> -assert(res->bo);
> -panfrost_job_add_bo(job, res->bo);
> +struct pipe_surface *surf = ctx-
> >pipe_framebuffer.cbufs[0];
> +if (surf) {
> +struct panfrost_resource *res =
> pan_resource(surf->texture);
> +assert(res->bo);
> +panfrost_job_add_bo(job, res->bo);
> +}
>  ret = panfrost_drm_submit_job(ctx,
> panfrost_fragment_job(ctx, has_draws), PANFROST_JD_REQ_FS);
>  assert(!ret);
>  }

I'm not sure this is actually correct either. I don't think there's any
guarantee that the currently bound framebuffer is what was actually
last rendered to. For instance if an application renders to the
backbuffer, switches to some FBO, does some rendering, switches back
and swaps buffers right away. I believe the currently bound framebuffer
will be the FBO at this point, because framebuffer-state is bound
lazily.

I think instead you'd want to add a reference in
panfrost_set_framebuffer_state(), right before you start rendering to
it... And at this point, you shouldn't need to special-case cbuf 0, you
should just add a reference to all cbufs as well as the zsbuf.

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

[Mesa-dev] [Bug 106875] The game Anima Gate of Memories has artefects

[bugzilla-daemon]

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

--- Comment #4 from Timothy Arceri  ---
According to the Unity manual it force the legacy OpenGL code path. The launch
options as documented in the manual:

OpenGL core profile command line arguments
--

It’s possible to start the editor or the player with OpenGL using the command
line arguments:

-force-opengl: To use the legacy OpenGL back-end
-force-glcore: To use the new OpenGL back-end. With this argument, Unity
will detect all the features the platform support to run with the best OpenGL
version possible and all available OpenGL extensions
-force-glcoreXY: XY can be 32, 33, 40, 41, 42, 43, 44 or 45; each number
representing a specific version of OpenGL. If the platform doesn’t support a
specific version of OpenGL, Unity will fallback to a supported version
-force-clamped: Request that Unity doesn’t use OpenGL extensions which
guarantees that multiple platforms will execute the same code path. This is an
approach to test if an issue is platform specific (a driver bug for example).

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

[Mesa-dev] [Bug 106875] The game Anima Gate of Memories has artefects

[bugzilla-daemon]

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

--- Comment #3 from Timothy Arceri  ---
Seems the work around suggested but the games devs is to set the following
launch option: -force-opengl

Not sure what it does but this worked for me.

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

[Mesa-dev] [Bug 111051] Mesa crashed on KDE Plasma Wayland session

[bugzilla-daemon]

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

Denis  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Denis  ---
hi Strangiato. Provide please your GPU (or CPU) version, if I have it - I will
try to reproduce issue.

Also would be helpful to see your kwin settings:
>~/.config/kwinrc

Also:
>I can't reproduce consistently, the crash occurred just once.
but in the original ticket you provided steps and wrote that this crash is
reproducible for you. That's correct?

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

Re: [Mesa-dev] [PATCH 3/3] panfrost: Add support for modifiers

[Daniel Stone]

Hi,

On Thu, 4 Jul 2019 at 09:47, Tomeu Vizoso  wrote:
> On Thu, 4 Jul 2019 at 10:05, Tomeu Vizoso  wrote:
> > -pres->layout = should_tile ? PAN_TILED : PAN_LINEAR;
> > +   if (want_afbc || (is_renderable && can_afbc && !is_texture))
> > +pres->layout = PAN_AFBC;
>
> We regress here because we seem to have some bugs regarding AFBC usage
> with some formats such as rgba4 and rgb5_a1:
>
> https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/399237
>
> I'm looking at only enabling AFBC when explicitly asked to by the winsys.

Again, the winsys just pulls the list of acceptable format/modifier
pairs from the EGL format query. If Panfrost declares 1555+AFBC to be
a supported combination, then the winsys will pass that on for clients
to use. If it isn't working, my suggestion is to just never advertise
it in the first place.

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

Re: [Mesa-dev] [PATCH 3/3] panfrost: Add support for modifiers

[Daniel Stone]

Hi Tomeu,

On Thu, 4 Jul 2019 at 09:05, Tomeu Vizoso  wrote:
> @@ -362,14 +392,19 @@ panfrost_resource_create_bo(struct panfrost_screen 
> *screen, struct panfrost_reso
>
>  /* Tiling textures is almost always faster, unless we only use it 
> once */
>
> +bool can_afbc = panfrost_format_supports_afbc(res->format);
> +bool want_afbc = 
> drm_find_modifier(DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP), 
> modifiers, count);
> +bool want_linear = drm_find_modifier(DRM_FORMAT_MOD_LINEAR, 
> modifiers, count);
>
> [...]
> -bool should_tile = !is_streaming && is_texture && is_2d && 
> !is_scanout;
> +bool should_tile = !is_streaming && is_texture && is_2d && 
> !want_linear && !is_scanout;

I don't think this is right.

The list of modifiers we pass in is the total list of acceptable
modifiers. Clients don't make any judgement or discernment about them,
but just pass in the full list. For example, in Weston we use EGL to
query the list of all modifiers supported by the driver, and then give
those to the client as the list of acceptable modifiers; the EGL
Wayland winsys will then pass that list into DRIImage create.

This means that 'want_linear' will be true as long as Panfrost (or, on
GBM, the KMS driver) supports linear, which realistically is all the
time.

I think ultimately we want should_tile to be (in order of evaluation):
  * definitively false if we can't support it - GPU doesn't support
it, isn't a 2D texture/RT, etc
  * if the above passes, definitively true if the above conditions are
met and we have passed in a modifier set which includes AFBC
  * if we can do it (first test) but we have no modifiers,
definitively false if it's a shared/scanout buffer (i.e. we need to
export the buffer somewhere else but the client isn't modifier-aware),
or definitively true if it's just an internal buffer

That code seems pretty familiar from VC4 (which is in turn probably
from freedreno? everything else is). It could be semi-useful to look
at how VC4 has structured its resource creation decision tree for
modifiers, but on the other hand they also have an implicit fallback
mode; when modifiers aren't available, it will pass the tiling
information through a magic kernel side-channel, which we really don't
want to do here.

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

Re: [Mesa-dev] [PATCH 2/2] radv: do not crash when generating binning state for unknown chips

[Bas Nieuwenhuizen]

r-b

On Thu, Jul 4, 2019 at 8:51 AM Samuel Pitoiset
 wrote:
>
> These values are only useful if binning is disabled.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_pipeline.c | 44 +-
>  1 file changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index 71d3be240b2..49687405705 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -2691,29 +2691,29 @@ radv_pipeline_generate_binning_state(struct 
> radeon_cmdbuf *ctx_cs,
>
> VkExtent2D bin_size = radv_compute_bin_size(pipeline, pCreateInfo);
>
> -   unsigned context_states_per_bin; /* allowed range: [1, 6] */
> -   unsigned persistent_states_per_bin; /* allowed range: [1, 32] */
> -   unsigned fpovs_per_batch; /* allowed range: [0, 255], 0 = unlimited */
> -
> -   switch (pipeline->device->physical_device->rad_info.family) {
> -   case CHIP_VEGA10:
> -   case CHIP_VEGA12:
> -   case CHIP_VEGA20:
> -   context_states_per_bin = 1;
> -   persistent_states_per_bin = 1;
> -   fpovs_per_batch = 63;
> -   break;
> -   case CHIP_RAVEN:
> -   case CHIP_RAVEN2:
> -   context_states_per_bin = 6;
> -   persistent_states_per_bin = 32;
> -   fpovs_per_batch = 63;
> -   break;
> -   default:
> -   unreachable("unhandled family while determining binning 
> state.");
> -   }
> -
> if (pipeline->device->pbb_allowed && bin_size.width && 
> bin_size.height) {
> +   unsigned context_states_per_bin; /* allowed range: [1, 6] */
> +   unsigned persistent_states_per_bin; /* allowed range: [1, 32] 
> */
> +   unsigned fpovs_per_batch; /* allowed range: [0, 255], 0 = 
> unlimited */
> +
> +   switch (pipeline->device->physical_device->rad_info.family) {
> +   case CHIP_VEGA10:
> +   case CHIP_VEGA12:
> +   case CHIP_VEGA20:
> +   context_states_per_bin = 1;
> +   persistent_states_per_bin = 1;
> +   fpovs_per_batch = 63;
> +   break;
> +   case CHIP_RAVEN:
> +   case CHIP_RAVEN2:
> +   context_states_per_bin = 6;
> +   persistent_states_per_bin = 32;
> +   fpovs_per_batch = 63;
> +   break;
> +   default:
> +   unreachable("unhandled family while determining 
> binning state.");
> +   }
> +
> pa_sc_binner_cntl_0 =
> S_028C44_BINNING_MODE(V_028C44_BINNING_ALLOWED) |
> S_028C44_BIN_SIZE_X(bin_size.width == 16) |
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] radv: fix potential crash in the compute resolve path

[Bas Nieuwenhuizen]

r-b

On Thu, Jul 4, 2019 at 8:51 AM Samuel Pitoiset
 wrote:
>
> If the destination attachment is UNUSED.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_meta_resolve_cs.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta_resolve_cs.c 
> b/src/amd/vulkan/radv_meta_resolve_cs.c
> index 7d3cc166e0d..13c61509b21 100644
> --- a/src/amd/vulkan/radv_meta_resolve_cs.c
> +++ b/src/amd/vulkan/radv_meta_resolve_cs.c
> @@ -917,12 +917,13 @@ radv_cmd_buffer_resolve_subpass_cs(struct 
> radv_cmd_buffer *cmd_buffer)
> for (uint32_t i = 0; i < subpass->color_count; ++i) {
> struct radv_subpass_attachment src_att = 
> subpass->color_attachments[i];
> struct radv_subpass_attachment dst_att = 
> subpass->resolve_attachments[i];
> -   struct radv_image_view *src_iview = 
> fb->attachments[src_att.attachment].attachment;
> -   struct radv_image_view *dst_iview = 
> fb->attachments[dst_att.attachment].attachment;
>
> if (dst_att.attachment == VK_ATTACHMENT_UNUSED)
> continue;
>
> +   struct radv_image_view *src_iview = 
> fb->attachments[src_att.attachment].attachment;
> +   struct radv_image_view *dst_iview = 
> fb->attachments[dst_att.attachment].attachment;
> +
> VkImageResolve region = {
> .extent = (VkExtent3D){ fb->width, fb->height, 0 },
> .srcSubresource = (VkImageSubresourceLayers) {
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] All-black X windows on glamor with etnaviv

[Michel Dänzer]

On 2019-07-04 5:28 a.m., Jiaxun Yang wrote:
> Hi folks,
> 
> We had some reports that glamor is not working correctly with etnaviv
> mesa driver for long time. Previously Lukas Hartmann wad proposed a
> patch [1] replacing linear rendering buffer with a tiled buffer and it
> do works but giving scrambled output. We just dig the issue deeper and
> managed to let it give out a normal output.
> 
> Since Vivante hardware doesn't actually support tiled surface/texture,
> once the driver accpet a imported buffer or called to create a resource,
> it will make a shadow tiled buffer, and convert the content in tiled
> buffer to the content it linear buffer when  etna_flush_resource in
> mesa/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c is called.
> However, it was never been called with glamor. By contrast other
> applications like kmscube or weston using EGL GLES have correct behavior.
> 
> Our solution is just flush the buffer everytime , it's not a elegant
> way, but it works. Since GC1000 is only giving OpenGL 1.4 rather than
> 2.1 as minimal requirement of glamor. We also have to force glamor work
> with GLES.
> 
> Any idea if we can solve this issue correctly?

I suspect etna_resource_get_handle needs to check for
PIPE_HANDLE_USAGE_EXPLICIT_FLUSH. If it's not set, the caller will not
call the flush_resource hook for this resource. This needs to be
recorded in struct etna_resource. Then in etna_flush, if this was
recorded for the resource backing any of the cbufs in the current
pipe_framebuffer_state, etna_flush_resource needs to be called for that
resource.

It might be possible to optimize this somewhat, e.g. maybe etna_flush
only needs to do this when it's called with certain PIPE_FLUSH_* flags
(not) set corresponding to glFlush, but not for other internal flushes.


-- 
Earthling Michel Dänzer   |  https://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] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

Lionel Landwerlin  changed:

   What|Removed |Added

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

--- Comment #18 from Lionel Landwerlin  ---
(In reply to Shmerl from comment #17)
> Oh, this is something already:
> 
> strings X4 | grep 'vulkan/linux'
> VK_LAYER_PATH=vulkan/linux
> 
> The game is doing something fishy, that's why above you can also see it
> looking for that weird "vulkan/linux" location.

Heh, you can always try to create that directory and link to the layer's file
there.

Anyway it doesn't seem like a layer bug so I'm closing this.
Thanks

--- Comment #19 from Eero Tamminen  ---
(In reply to Lionel Landwerlin from comment #15)
> Thanks it seems to be using the system loader.
> At this point I have no idea apart from the game manually calling setenv()
> to drop the VK_LAYER_PATH variable.

Environment can be easily checked for a running program:
  tr '\0' '\n' < /proc/PID/environ | grep VK

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

Re: [Mesa-dev] [RFC PATCH] mesa: Export BOs in RW mode

[Daniel Vetter]

On Thu, Jul 4, 2019 at 11:26 AM Steven Price  wrote:
>
> On 03/07/2019 17:18, Daniel Vetter wrote:
> > On Wed, Jul 3, 2019 at 6:11 PM Steven Price  wrote:
> [...]
> >> In theory the exporter should do whatever is required to ensure that the
> >> CPU is synchronised when a user space mapping exists. There are some
> >> issues here though:
> >>
> >> * In theory the kernel driver should map the dma_buf purely for the
> >> duration that a job is using the buffer (and unmap immediately after).
> >> This gives the exporter the knowledge of when the GPU is using the
> >> memory and allows the exporter to page out of the memory if necessary.
> >> In practise this map/unmap operation is expensive (updating the GPU's
> >> page tables) so most drivers don't actually bother and keep the memory
> >> mapped. This means the exporter cannot tell when the buffer is used or
> >> move the pages.
> >
> > Yeah refaulting is too slow if you care the least about performance.
> >
> >> * The CPU mappings can be faulted on demand (performing the necessary
> >> CPU cache invalidate if needed) and shot-down to allow moving the
> >> memory. In theory when the GPU needs the memory it should map the buffer
> >> and the exporter can then shoot down the mappings, perform the CPU cache
> >> clean and then allow the GPU to use the memory. A subsequent CPU access
> >> would then refault the page, ensuring a CPU cache invalidate so the
> >> latest data is visible.
> >
> > We thought that was the answer, until it was clear its not. dma-buf
> > mmap isn't coherent, you need to call the begin/end ioctls.
> >
> >> * The majority of exporters are simple and deal with uncached memory
> >> (e.g. frame buffers) or are actually exporting back to the same driver
> >> (e.g. window surfaces). In these situations either the driver already
> >> has the necessary "magic" to deal with caches (e.g. kbase provides
> >> explicit cache maintenance operations), or it's "uncached" anyway so it
> >> doesn't matter. This means that hardly anyone tests with the complex
> >> cases...
> >>
> >> From a user space ABI, my understanding is that a dma_buf mmap() mapping
> >> should be coherent, and user space isn't expected to do anything to make
> >> it work. Obviously any importing device might have it's own coherency
> >> details which will be up to the ABI of that device (e.g. Mali has caches
> >> which may need to be flushed - this is usually done at the start/end of
> >> a job chain, so coherency is not guaranteed while the job chain is 
> >> running).
> >
> > See my other reply, but this isn't correct. dma-buf has explicit cache
> > maintenance ops. It's just that generally everyone (ok, display only
> > drivers using the cma helpers) ends up exporting coherent memory and
> > that's why this works. Doesn't make it a bright idea imo ...
>
> Sorry, I'd completely forgotten about the DMA_BUF_IOCTL_SYNC ioctl when
> I wrote this. But to a large extent this ship has already sailed, and
> indeed the current users of dma_buf_mmap() implicitly assume that no
> sync is necessary (since there's no mechanism to forward the syncs onto
> the exporter). Indeed the comment in dma-buf.c says:
>
>  *   The assumption in the current dma-buf interfaces is that redirecting the
>  *   initial mmap is all that's needed. A survey of some of the existing
>  *   subsystems shows that no driver seems to do any nefarious thing like
>  *   syncing up with outstanding asynchronous processing on the device or
>  *   allocating special resources at fault time. So hopefully this is good
>  *   enough, since adding interfaces to intercept pagefaults and allow pte
>  *   shootdowns would increase the complexity quite a bit.
>
> I'd be happy to kill off dma_buf_mmap() and require user space to mmap
> via the dma_buf handle (and also therefore to handle the manual sync
> ioctls), but I'm not sure how we achieve that while maintaining
> backwards compatibility.

Uh I forgot to fully update this in my doc update in 2016. That text
originally predates the sync ioctl. Care to type a patch?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] mesa: Export BOs in RW mode

[Steven Price]

On 03/07/2019 17:18, Daniel Vetter wrote:
> On Wed, Jul 3, 2019 at 6:11 PM Steven Price  wrote:
[...]
>> In theory the exporter should do whatever is required to ensure that the
>> CPU is synchronised when a user space mapping exists. There are some
>> issues here though:
>>
>> * In theory the kernel driver should map the dma_buf purely for the
>> duration that a job is using the buffer (and unmap immediately after).
>> This gives the exporter the knowledge of when the GPU is using the
>> memory and allows the exporter to page out of the memory if necessary.
>> In practise this map/unmap operation is expensive (updating the GPU's
>> page tables) so most drivers don't actually bother and keep the memory
>> mapped. This means the exporter cannot tell when the buffer is used or
>> move the pages.
> 
> Yeah refaulting is too slow if you care the least about performance.
> 
>> * The CPU mappings can be faulted on demand (performing the necessary
>> CPU cache invalidate if needed) and shot-down to allow moving the
>> memory. In theory when the GPU needs the memory it should map the buffer
>> and the exporter can then shoot down the mappings, perform the CPU cache
>> clean and then allow the GPU to use the memory. A subsequent CPU access
>> would then refault the page, ensuring a CPU cache invalidate so the
>> latest data is visible.
> 
> We thought that was the answer, until it was clear its not. dma-buf
> mmap isn't coherent, you need to call the begin/end ioctls.
> 
>> * The majority of exporters are simple and deal with uncached memory
>> (e.g. frame buffers) or are actually exporting back to the same driver
>> (e.g. window surfaces). In these situations either the driver already
>> has the necessary "magic" to deal with caches (e.g. kbase provides
>> explicit cache maintenance operations), or it's "uncached" anyway so it
>> doesn't matter. This means that hardly anyone tests with the complex
>> cases...
>>
>> From a user space ABI, my understanding is that a dma_buf mmap() mapping
>> should be coherent, and user space isn't expected to do anything to make
>> it work. Obviously any importing device might have it's own coherency
>> details which will be up to the ABI of that device (e.g. Mali has caches
>> which may need to be flushed - this is usually done at the start/end of
>> a job chain, so coherency is not guaranteed while the job chain is running).
> 
> See my other reply, but this isn't correct. dma-buf has explicit cache
> maintenance ops. It's just that generally everyone (ok, display only
> drivers using the cma helpers) ends up exporting coherent memory and
> that's why this works. Doesn't make it a bright idea imo ...

Sorry, I'd completely forgotten about the DMA_BUF_IOCTL_SYNC ioctl when
I wrote this. But to a large extent this ship has already sailed, and
indeed the current users of dma_buf_mmap() implicitly assume that no
sync is necessary (since there's no mechanism to forward the syncs onto
the exporter). Indeed the comment in dma-buf.c says:

 *   The assumption in the current dma-buf interfaces is that redirecting the
 *   initial mmap is all that's needed. A survey of some of the existing
 *   subsystems shows that no driver seems to do any nefarious thing like
 *   syncing up with outstanding asynchronous processing on the device or
 *   allocating special resources at fault time. So hopefully this is good
 *   enough, since adding interfaces to intercept pagefaults and allow pte
 *   shootdowns would increase the complexity quite a bit.

I'd be happy to kill off dma_buf_mmap() and require user space to mmap
via the dma_buf handle (and also therefore to handle the manual sync
ioctls), but I'm not sure how we achieve that while maintaining
backwards compatibility.

Thanks,

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

Re: [Mesa-dev] [PATCH 2/3] panfrost: Allocate scanout BOs in panfrost device

[Boris Brezillon]

On Thu,  4 Jul 2019 10:04:42 +0200
Tomeu Vizoso  wrote:

> @@ -382,11 +362,14 @@ panfrost_resource_create_bo(struct panfrost_screen 
> *screen, struct panfrost_reso
>  
>  /* Tiling textures is almost always faster, unless we only use it 
> once */
>  
> +#define SCANOUT (PIPE_BIND_SCANOUT | PIPE_BIND_SHARED | 
> PIPE_BIND_DISPLAY_TARGET)
> +
> +bool is_scanout = (res->bind & SCANOUT);
>  bool is_texture = (res->bind & PIPE_BIND_SAMPLER_VIEW);
>  bool is_2d = res->depth0 == 1 && res->array_size == 1;
> -bool is_streaming = (res->usage != PIPE_USAGE_STREAM);
> +bool is_streaming = (res->usage == PIPE_USAGE_STREAM);
>  
> -bool should_tile = is_streaming && is_texture && is_2d;
> +bool should_tile = !is_streaming && is_texture && is_2d && 
> !is_scanout;
>  
>  /* Depth/stencil can't be tiled, only linear or AFBC */
>  should_tile &= !(res->bind & PIPE_BIND_DEPTH_STENCIL);
> @@ -425,10 +408,6 @@ panfrost_resource_create(struct pipe_screen *screen,
>  assert(0);
>  }
>  
> -if (template->bind &
> -(PIPE_BIND_DISPLAY_TARGET | PIPE_BIND_SCANOUT | 
> PIPE_BIND_SHARED))
> -return panfrost_create_scanout_res(screen, template);
> -
>  struct panfrost_resource *so = rzalloc(screen, struct 
> panfrost_resource);
>  struct panfrost_screen *pscreen = (struct panfrost_screen *) screen;
>  
> @@ -440,6 +419,20 @@ panfrost_resource_create(struct pipe_screen *screen,
>  util_range_init(>valid_buffer_range);
>  
>  panfrost_resource_create_bo(pscreen, so);
> +
> +/* Set up the "scanout resource" (the dmabuf export of our buffer to
> + * the KMS handle) if the buffer might ever have
> + * resource_get_handle(WINSYS_HANDLE_TYPE_KMS) called on it.
> + */
> +if (template->bind & PIPE_BIND_SCANOUT) {

That's probably intentional but I thought I'd mention it just to be
sure this is what you intend to do: the scanout obj is now only created
when PIPE_BIND_SCANOUT is set while it was previously created for
PIPE_BIND_SHARED and PIPE_BIND_DISPLAY_TARGET too.

> +so->scanout =
> +renderonly_scanout_for_resource(>base, 
> pscreen->ro, NULL);
> +if (!so->scanout) {
> +panfrost_resource_destroy(screen, >base);
> +return NULL;
> +}
> +}
> +
>  return (struct pipe_resource *)so;
>  }
>  
> diff --git a/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c 
> b/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
> index bf599a1497c9..5b316a2b1f37 100644
> --- a/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
> +++ b/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
> @@ -90,7 +90,7 @@ struct pipe_screen *kmsro_drm_screen_create(int fd,
> ro.gpu_fd = drmOpenWithType("panfrost", NULL, DRM_NODE_RENDER);
>  
> if (ro.gpu_fd >= 0) {
> -  ro.create_for_resource = 
> renderonly_create_kms_dumb_buffer_for_resource,
> +  ro.create_for_resource = renderonly_create_gpu_import_for_resource,
>screen = panfrost_drm_screen_create_renderonly();
>if (!screen)
>   close(ro.gpu_fd);

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

[Mesa-dev] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

--- Comment #17 from Shmerl  ---
Oh, this is something already:

strings X4 | grep 'vulkan/linux'
VK_LAYER_PATH=vulkan/linux

The game is doing something fishy, that's why above you can also see it looking
for that weird "vulkan/linux" location.

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

Re: [Mesa-dev] [PATCH 1/3] panfrost: Cache BO imports

[Boris Brezillon]

Hi Tomeu,

On Thu,  4 Jul 2019 10:04:41 +0200
Tomeu Vizoso  wrote:

> If two jobs use the same GEM object at the same time, the job that
> finishes first will (previous to this commit) close the GEM object, even
> if there's a job still referencing it.
> 
> To prevent this, have all jobs use the same panfrost_bo for a given GEM
> object, so it's only closed once the last job is done with it.
> 
> Signed-off-by: Tomeu Vizoso 
> ---
>  src/gallium/drivers/panfrost/pan_allocate.h |  2 +-
>  src/gallium/drivers/panfrost/pan_drm.c  | 46 +++--
>  src/gallium/drivers/panfrost/pan_resource.c | 20 -
>  src/gallium/drivers/panfrost/pan_screen.h   |  6 +++
>  4 files changed, 68 insertions(+), 6 deletions(-)
> 
> diff --git a/src/gallium/drivers/panfrost/pan_allocate.h 
> b/src/gallium/drivers/panfrost/pan_allocate.h
> index 20ba204dee86..2dfa913b8c4d 100644
> --- a/src/gallium/drivers/panfrost/pan_allocate.h
> +++ b/src/gallium/drivers/panfrost/pan_allocate.h
> @@ -59,7 +59,7 @@ struct panfrost_transfer {
>  };
>  
>  struct panfrost_bo {
> -struct pipe_reference reference;
> +int refcnt;
>  
>  /* Mapping for the entire object (all levels) */
>  uint8_t *cpu;
> diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
> b/src/gallium/drivers/panfrost/pan_drm.c
> index b89f8e66a877..9648ac1d452d 100644
> --- a/src/gallium/drivers/panfrost/pan_drm.c
> +++ b/src/gallium/drivers/panfrost/pan_drm.c
> @@ -103,7 +103,12 @@ panfrost_drm_create_bo(struct panfrost_screen *screen, 
> size_t size,
>  // TODO map and unmap on demand?
>  panfrost_drm_mmap_bo(screen, bo);
>  
> -pipe_reference_init(>reference, 1);
> +p_atomic_set(>refcnt, 1);
> +
> +pthread_mutex_lock(>handle_table_lock);
> +_mesa_hash_table_insert(screen->handle_table, >gem_handle, bo);
> +pthread_mutex_unlock(>handle_table_lock);
> +
>  return bo;
>  }
>  
> @@ -116,6 +121,9 @@ panfrost_drm_release_bo(struct panfrost_screen *screen, 
> struct panfrost_bo *bo)
>  if (!bo)
>  return;
>  
> +pthread_mutex_lock(>handle_table_lock);
> +_mesa_hash_table_remove_key(screen->handle_table, >gem_handle);
> +
>  panfrost_drm_munmap_bo(screen, bo);
>  
>  ret = drmIoctl(screen->fd, DRM_IOCTL_GEM_CLOSE, _close);
> @@ -125,6 +133,8 @@ panfrost_drm_release_bo(struct panfrost_screen *screen, 
> struct panfrost_bo *bo)
>  }
>  
>  ralloc_free(bo);
> +
> +pthread_mutex_unlock(>handle_table_lock);
>  }
>  
>  void
> @@ -150,17 +160,41 @@ panfrost_drm_free_slab(struct panfrost_screen *screen, 
> struct panfrost_memory *m
>  mem->bo = NULL;
>  }
>  
> +/* lookup a buffer, call w/ table_lock held: */
> +static struct panfrost_bo *lookup_bo(struct hash_table *tbl, uint32_t key)

I tend to add _locked() suffixes to functions that are supposed to be
called with a lock held, just for people who don't read comments (like
me :)). 

> +{
> + struct panfrost_bo *bo = NULL;
> + struct hash_entry *entry = _mesa_hash_table_search(tbl, );
> + if (entry) {
> + /* found, incr refcnt and return: */
> + bo = entry->data;

You need:

/* BO is about to freed, don't return it. */
if (!p_atomic_read(>refcnt))
return NULL;

here (see below for a detailed explanation about the race).

> + panfrost_bo_reference(bo);
> + }
> + return bo;
> +}
> +
>  struct panfrost_bo *
>  panfrost_drm_import_bo(struct panfrost_screen *screen, int fd)
>  {
> - struct panfrost_bo *bo = rzalloc(screen, struct panfrost_bo);
> + struct panfrost_bo *bo = NULL;
>  struct drm_panfrost_get_bo_offset get_bo_offset = {0,};
>  int ret;
>  unsigned gem_handle;
>  
> +pthread_mutex_lock(>handle_table_lock);
> +

Unrelated/nit: we should really agree on an indentation model (tab vs
spaces). I keep trying to adapt to the context surrounding my changes
(using tabs when tabs are used nearby, spaces otherwise), but now
we're starting to have a mix of tabs and spaces inside the same
functions.

>   ret = drmPrimeFDToHandle(screen->fd, fd, _handle);
>   assert(!ret);
>  
> +if (ret)
> +goto out_unlock;
> +

Can't we take the lock here instead?

> +bo = lookup_bo(screen->handle_table, gem_handle);
> +if (bo)
> +goto out_unlock;
> +
> +bo = rzalloc(screen, struct panfrost_bo);
> +
>   get_bo_offset.handle = gem_handle;
>  ret = drmIoctl(screen->fd, DRM_IOCTL_PANFROST_GET_BO_OFFSET, 
> _bo_offset);
>  assert(!ret);
> @@ -169,10 +203,16 @@ panfrost_drm_import_bo(struct panfrost_screen *screen, 
> int fd)
>  bo->gpu = (mali_ptr) get_bo_offset.offset;
>  bo->size = lseek(fd, 0, SEEK_END);
>  assert(bo->size > 0);
> -pipe_reference_init(>reference, 1);
> +

[Mesa-dev] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

--- Comment #16 from Shmerl  ---
OK, I'll try to strace it to get some details and will also ping developers of
the game with this question.

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

[Mesa-dev] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

--- Comment #15 from Lionel Landwerlin  ---
(In reply to Shmerl from comment #13)
> OK, I run it now also to match mesa-master Vulkan driver with the loader.
> I.e. using not the system ICD, but the one built with mesa-master (though
> that doesn't change the outcome, but at least reduces potential mismatches).
> 
> Here is the result of /proc//maps: https://pastebin.com/raw/vPwn0xTd

Thanks it seems to be using the system loader.
At this point I have no idea apart from the game manually calling setenv() to
drop the VK_LAYER_PATH variable.

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

Re: [Mesa-dev] [PATCH 3/3] panfrost: Add support for modifiers

[Tomeu Vizoso]

On Thu, 4 Jul 2019 at 10:05, Tomeu Vizoso  wrote:
>
> Implement query_dmabuf_modifiers and resource_create_with_modifiers so
> Wayland clients can share AFBC buffers with the compositor.
>
> For now this is guarded behind the PAN_MESA_DEBUG=modifiers env var
> because implementing those callbacks causes Weston to try to pass
> modifiers to the Rockchip KMS driver, which currently doesn't support
> modifiers, thus failing the modeset.
>
> This has been fixed in Weston 6.0, so we can enable unconditionally once
> we are confident that most people testing panfrost have upgraded.
>
> This lays the ground for scanning out AFBC buffers, if the KMS driver
> supports it.
>
> Signed-off-by: Tomeu Vizoso 
> ---
>  src/gallium/drivers/panfrost/pan_drm.c  |  1 +
>  src/gallium/drivers/panfrost/pan_resource.c | 74 ++---
>  src/gallium/drivers/panfrost/pan_screen.c   | 37 +++
>  src/gallium/drivers/panfrost/pan_util.h |  7 ++
>  4 files changed, 108 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
> b/src/gallium/drivers/panfrost/pan_drm.c
> index 9648ac1d452d..623793a84411 100644
> --- a/src/gallium/drivers/panfrost/pan_drm.c
> +++ b/src/gallium/drivers/panfrost/pan_drm.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>
> +#include "drm-uapi/drm_fourcc.h"
>  #include "drm-uapi/panfrost_drm.h"
>
>  #include "util/u_memory.h"
> diff --git a/src/gallium/drivers/panfrost/pan_resource.c 
> b/src/gallium/drivers/panfrost/pan_resource.c
> index 54497d3de2bb..d901d43168fb 100644
> --- a/src/gallium/drivers/panfrost/pan_resource.c
> +++ b/src/gallium/drivers/panfrost/pan_resource.c
> @@ -34,6 +34,7 @@
>  #include "drm-uapi/drm_fourcc.h"
>
>  #include "state_tracker/winsys_handle.h"
> +#include "util/u_drm.h"
>  #include "util/u_format.h"
>  #include "util/u_memory.h"
>  #include "util/u_surface.h"
> @@ -91,6 +92,18 @@ panfrost_resource_from_handle(struct pipe_screen *pscreen,
>
> rsc->bo = panfrost_drm_import_bo(screen, whandle->handle);
>
> +   switch(whandle->modifier) {
> +   case DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP):
> +   rsc->layout = PAN_AFBC;
> +   break;
> +   case DRM_FORMAT_MOD_LINEAR:
> +   rsc->layout = PAN_LINEAR;
> +   break;
> +   default:
> +fprintf(stderr, "unknown modifier: 0x%"PRIx64"\n", 
> whandle->modifier);
> +   assert(0);
> +   }
> +
>  size_t bo_size;
>  panfrost_setup_slices(rsc, _size);
>  assert(bo_size == rsc->bo->size);
> @@ -106,6 +119,21 @@ panfrost_resource_from_handle(struct pipe_screen 
> *pscreen,
>  return prsc;
>  }
>
> +static uint64_t
> +panfrost_resource_modifier(struct panfrost_resource *rsrc)
> +{
> +switch (rsrc->layout) {
> +case PAN_AFBC:
> +return DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP);
> +case PAN_TILED:
> +return DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED;
> +case PAN_LINEAR:
> +return DRM_FORMAT_MOD_LINEAR;
> +default:
> +return DRM_FORMAT_MOD_INVALID;
> +}
> +}
> +
>  static boolean
>  panfrost_resource_get_handle(struct pipe_screen *pscreen,
>   struct pipe_context *ctx,
> @@ -117,7 +145,7 @@ panfrost_resource_get_handle(struct pipe_screen *pscreen,
>  struct panfrost_resource *rsrc = (struct panfrost_resource *) pt;
>  struct renderonly_scanout *scanout = rsrc->scanout;
>
> -handle->modifier = DRM_FORMAT_MOD_INVALID;
> +handle->modifier = panfrost_resource_modifier(rsrc);
>
> if (handle->type == WINSYS_HANDLE_TYPE_SHARED) {
> return FALSE;
> @@ -341,7 +369,9 @@ panfrost_setup_slices(struct panfrost_resource *pres, 
> size_t *bo_size)
>  }
>
>  static void
> -panfrost_resource_create_bo(struct panfrost_screen *screen, struct 
> panfrost_resource *pres)
> +panfrost_resource_create_bo(struct panfrost_screen *screen,
> +struct panfrost_resource *pres,
> +const uint64_t *modifiers, int count)
>  {
> struct pipe_resource *res = >base;
>
> @@ -362,14 +392,19 @@ panfrost_resource_create_bo(struct panfrost_screen 
> *screen, struct panfrost_reso
>
>  /* Tiling textures is almost always faster, unless we only use it 
> once */
>
> +bool can_afbc = panfrost_format_supports_afbc(res->format);
> +bool want_afbc = 
> drm_find_modifier(DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP), 
> modifiers, count);
> +bool want_linear = drm_find_modifier(DRM_FORMAT_MOD_LINEAR, 
> modifiers, count);
> +
>  #define SCANOUT (PIPE_BIND_SCANOUT | PIPE_BIND_SHARED | 
> PIPE_BIND_DISPLAY_TARGET)
>
>  bool is_scanout = (res->bind & SCANOUT);
>  bool is_texture = (res->bind & PIPE_BIND_SAMPLER_VIEW);
> +bool is_renderable = (res->bind & PIPE_BIND_RENDER_TARGET);
>

[Mesa-dev] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

--- Comment #14 from Shmerl  ---
May be something is statically compiled into it?

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

[Mesa-dev] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

--- Comment #13 from Shmerl  ---
OK, I run it now also to match mesa-master Vulkan driver with the loader. I.e.
using not the system ICD, but the one built with mesa-master (though that
doesn't change the outcome, but at least reduces potential mismatches).

Here is the result of /proc//maps: https://pastebin.com/raw/vPwn0xTd

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

[Mesa-dev] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

--- Comment #12 from Lionel Landwerlin  ---
(In reply to Shmerl from comment #11)
> I'm using GOG version, and actually launch the binary directly with those
> env variables prefixed for a test (X4 is a binary).
> 
> I.e.
> 
> VK_LOADER_DEBUG=all
> VK_LAYER_PATH=/opt/mesa-master/share/vulkan/explicit_layer.d
> VK_INSTANCE_LAYERS=VK_LAYER_MESA_overlay ./X4

Can you look at a strace dump or once the game is loaded cat
/proc//maps to check whether the game might be using its own version
of the loader?

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

[Mesa-dev] All-black X windows on glamor with etnaviv

[Jiaxun Yang]

Hi folks,

We had some reports that glamor is not working correctly with etnaviv 
mesa driver for long time. Previously Lukas Hartmann wad proposed a 
patch [1] replacing linear rendering buffer with a tiled buffer and it 
do works but giving scrambled output. We just dig the issue deeper and 
managed to let it give out a normal output.


Since Vivante hardware doesn't actually support tiled surface/texture, 
once the driver accpet a imported buffer or called to create a resource, 
it will make a shadow tiled buffer, and convert the content in tiled 
buffer to the content it linear buffer when  etna_flush_resource in 
mesa/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c is called. 
However, it was never been called with glamor. By contrast other 
applications like kmscube or weston using EGL GLES have correct behavior.


Our solution is just flush the buffer everytime , it's not a elegant 
way, but it works. Since GC1000 is only giving OpenGL 1.4 rather than 
2.1 as minimal requirement of glamor. We also have to force glamor work 
with GLES.


Any idea if we can solve this issue correctly?

See our patches below:

diff --git a/src/gallium/drivers/etnaviv/etnaviv_blt.c 
b/src/gallium/drivers/etnaviv/etnaviv_blt.c

index 42d1a44..342758c 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_blt.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_blt.c
@@ -247,6 +247,7 @@ etna_blit_clear_color_blt(struct pipe_context *pctx, 
struct pipe_surface *dst,

    surf->level->clear_value = new_clear_value;
    resource_written(ctx, surf->base.texture);
    etna_resource(surf->base.texture)->seqno++;
+   pctx->flush_resource(pctx, surf->base.texture);
 }

 static void
@@ -323,6 +324,7 @@ etna_blit_clear_zs_blt(struct pipe_context *pctx, 
struct pipe_surface *dst,

    surf->level->clear_value = new_clear_value;
    resource_written(ctx, surf->base.texture);
    etna_resource(surf->base.texture)->seqno++;
+   pctx->flush_resource(pctx, surf->base.texture);
 }

 static void
@@ -519,6 +521,7 @@ etna_try_blt_blit(struct pipe_context *pctx,

    dst->seqno++;
    dst_lev->ts_valid = false;
+   pctx->flush_resource(pctx, blit_info->dst.resource);

    return true;
 }
diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c

index 45c30cb..b36afbf 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
@@ -24,6 +24,7 @@
  *    Wladimir J. van der Laan 
  */

+#include 
 #include "etnaviv_clear_blit.h"

 #include "hw/common.xml.h"
diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
b/src/gallium/drivers/etnaviv/etnaviv_context.c

index b0a56c6..13233e7 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_context.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
@@ -297,10 +297,14 @@ etna_draw_vbo(struct pipe_context *pctx, const 
struct pipe_draw_info *info)

    if (DBG_ENABLED(ETNA_DBG_FLUSH_ALL))
   pctx->flush(pctx, NULL, 0);

-   if (ctx->framebuffer_s.cbufs[0])
+   if (ctx->framebuffer_s.cbufs[0]) {
etna_resource(ctx->framebuffer_s.cbufs[0]->texture)->seqno++;
-   if (ctx->framebuffer_s.zsbuf)
+  pctx->flush_resource(pctx, ctx->framebuffer_s.cbufs[0]->texture);
+   }
+   if (ctx->framebuffer_s.zsbuf) {
etna_resource(ctx->framebuffer_s.zsbuf->texture)->seqno++;
+  pctx->flush_resource(pctx, ctx->framebuffer_s.zsbuf->texture);
+   }
    if (info->index_size && indexbuf != info->index.resource)
   pipe_resource_reference(, NULL);
 }
diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
b/src/gallium/drivers/etnaviv/etnaviv_rs.c

index 8c85f32..5fd81e0 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
@@ -325,6 +325,7 @@ etna_blit_clear_color_rs(struct pipe_context *pctx, 
struct pipe_surface *dst,

    surf->level->clear_value = new_clear_value;
    resource_written(ctx, surf->base.texture);
    etna_resource(surf->base.texture)->seqno++;
+   pctx->flush_resource(pctx, surf->base.texture);
 }

 static void
@@ -388,6 +389,7 @@ etna_blit_clear_zs_rs(struct pipe_context *pctx, 
struct pipe_surface *dst,

    surf->level->clear_value = new_clear_value;
    resource_written(ctx, surf->base.texture);
    etna_resource(surf->base.texture)->seqno++;
+   pctx->flush_resource(pctx, surf->base.texture);
 }

 static void
@@ -745,6 +747,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
    dst->seqno++;
    dst->levels[blit_info->dst.level].ts_valid = false;
    ctx->dirty |= ETNA_DIRTY_DERIVE_TS;
+   pctx->flush_resource(pctx, blit_info->dst.resource);

    return true;

diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
b/src/gallium/drivers/etnaviv/etnaviv_transfer.c

index d875803..9ec3463 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
@@ -158,6 +158,7 @@ etna_transfer_unmap(struct pipe_context *pctx, 
struct pipe_transfer *ptrans)

   if (rsc->base.bind & 

[Mesa-dev] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

--- Comment #11 from Shmerl  ---
I'm using GOG version, and actually launch the binary directly with those env
variables prefixed for a test (X4 is a binary).

I.e.

VK_LOADER_DEBUG=all
VK_LAYER_PATH=/opt/mesa-master/share/vulkan/explicit_layer.d
VK_INSTANCE_LAYERS=VK_LAYER_MESA_overlay ./X4

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

[Mesa-dev] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

--- Comment #10 from Lionel Landwerlin  ---
Are you using the %command% trick in steam or some other mean?
It looks like something is stripping your VK_LAYER_PATH environment variable.

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

Re: [Mesa-dev] [PATCH] panfrost: Take into account off-screen FBOs

[Boris Brezillon]

On Thu,  4 Jul 2019 10:02:54 +0200
Tomeu Vizoso  wrote:

> In that case, ctx->pipe_framebuffer.cbufs[0] can be NULL.
> 
> Signed-off-by: Tomeu Vizoso 
> Cc: Boris Brezillon 

Reviewed-by: Boris Brezillon 

> Fixes: 5375d009be18 ("panfrost: Pass referenced BOs to the SUBMIT ioctls")
> ---
>  src/gallium/drivers/panfrost/pan_drm.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
> b/src/gallium/drivers/panfrost/pan_drm.c
> index 8de4f483435c..b89f8e66a877 100644
> --- a/src/gallium/drivers/panfrost/pan_drm.c
> +++ b/src/gallium/drivers/panfrost/pan_drm.c
> @@ -238,7 +238,6 @@ panfrost_drm_submit_job(struct panfrost_context *ctx, u64 
> job_desc, int reqs)
>  int
>  panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx, bool has_draws, 
> bool is_scanout)
>  {
> -struct pipe_surface *surf = ctx->pipe_framebuffer.cbufs[0];
>   int ret;
>  
>  struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
> @@ -256,9 +255,12 @@ panfrost_drm_submit_vs_fs_job(struct panfrost_context 
> *ctx, bool has_draws, bool
>  }
>  
>  if (job->first_tiler.gpu || job->clear) {
> -struct panfrost_resource *res = pan_resource(surf->texture);
> -assert(res->bo);
> -panfrost_job_add_bo(job, res->bo);
> +struct pipe_surface *surf = ctx->pipe_framebuffer.cbufs[0];
> +if (surf) {
> +struct panfrost_resource *res = 
> pan_resource(surf->texture);
> +assert(res->bo);
> +panfrost_job_add_bo(job, res->bo);
> +}
>  ret = panfrost_drm_submit_job(ctx, 
> panfrost_fragment_job(ctx, has_draws), PANFROST_JD_REQ_FS);
>  assert(!ret);
>  }

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

[Mesa-dev] [PATCH 3/3] panfrost: Add support for modifiers

[Tomeu Vizoso]

Implement query_dmabuf_modifiers and resource_create_with_modifiers so
Wayland clients can share AFBC buffers with the compositor.

For now this is guarded behind the PAN_MESA_DEBUG=modifiers env var
because implementing those callbacks causes Weston to try to pass
modifiers to the Rockchip KMS driver, which currently doesn't support
modifiers, thus failing the modeset.

This has been fixed in Weston 6.0, so we can enable unconditionally once
we are confident that most people testing panfrost have upgraded.

This lays the ground for scanning out AFBC buffers, if the KMS driver
supports it.

Signed-off-by: Tomeu Vizoso 
---
 src/gallium/drivers/panfrost/pan_drm.c  |  1 +
 src/gallium/drivers/panfrost/pan_resource.c | 74 ++---
 src/gallium/drivers/panfrost/pan_screen.c   | 37 +++
 src/gallium/drivers/panfrost/pan_util.h |  7 ++
 4 files changed, 108 insertions(+), 11 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
b/src/gallium/drivers/panfrost/pan_drm.c
index 9648ac1d452d..623793a84411 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 
+#include "drm-uapi/drm_fourcc.h"
 #include "drm-uapi/panfrost_drm.h"
 
 #include "util/u_memory.h"
diff --git a/src/gallium/drivers/panfrost/pan_resource.c 
b/src/gallium/drivers/panfrost/pan_resource.c
index 54497d3de2bb..d901d43168fb 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -34,6 +34,7 @@
 #include "drm-uapi/drm_fourcc.h"
 
 #include "state_tracker/winsys_handle.h"
+#include "util/u_drm.h"
 #include "util/u_format.h"
 #include "util/u_memory.h"
 #include "util/u_surface.h"
@@ -91,6 +92,18 @@ panfrost_resource_from_handle(struct pipe_screen *pscreen,
 
rsc->bo = panfrost_drm_import_bo(screen, whandle->handle);
 
+   switch(whandle->modifier) {
+   case DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP):
+   rsc->layout = PAN_AFBC;
+   break;
+   case DRM_FORMAT_MOD_LINEAR:
+   rsc->layout = PAN_LINEAR;
+   break;
+   default:
+fprintf(stderr, "unknown modifier: 0x%"PRIx64"\n", 
whandle->modifier);
+   assert(0);
+   }
+
 size_t bo_size;
 panfrost_setup_slices(rsc, _size);
 assert(bo_size == rsc->bo->size);
@@ -106,6 +119,21 @@ panfrost_resource_from_handle(struct pipe_screen *pscreen,
 return prsc;
 }
 
+static uint64_t
+panfrost_resource_modifier(struct panfrost_resource *rsrc)
+{
+switch (rsrc->layout) {
+case PAN_AFBC:
+return DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP);
+case PAN_TILED:
+return DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED;
+case PAN_LINEAR:
+return DRM_FORMAT_MOD_LINEAR;
+default:
+return DRM_FORMAT_MOD_INVALID;
+}
+}
+
 static boolean
 panfrost_resource_get_handle(struct pipe_screen *pscreen,
  struct pipe_context *ctx,
@@ -117,7 +145,7 @@ panfrost_resource_get_handle(struct pipe_screen *pscreen,
 struct panfrost_resource *rsrc = (struct panfrost_resource *) pt;
 struct renderonly_scanout *scanout = rsrc->scanout;
 
-handle->modifier = DRM_FORMAT_MOD_INVALID;
+handle->modifier = panfrost_resource_modifier(rsrc);
 
if (handle->type == WINSYS_HANDLE_TYPE_SHARED) {
return FALSE;
@@ -341,7 +369,9 @@ panfrost_setup_slices(struct panfrost_resource *pres, 
size_t *bo_size)
 }
 
 static void
-panfrost_resource_create_bo(struct panfrost_screen *screen, struct 
panfrost_resource *pres)
+panfrost_resource_create_bo(struct panfrost_screen *screen,
+struct panfrost_resource *pres,
+const uint64_t *modifiers, int count)
 {
struct pipe_resource *res = >base;
 
@@ -362,14 +392,19 @@ panfrost_resource_create_bo(struct panfrost_screen 
*screen, struct panfrost_reso
 
 /* Tiling textures is almost always faster, unless we only use it once 
*/
 
+bool can_afbc = panfrost_format_supports_afbc(res->format);
+bool want_afbc = 
drm_find_modifier(DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP), modifiers, 
count);
+bool want_linear = drm_find_modifier(DRM_FORMAT_MOD_LINEAR, modifiers, 
count);
+
 #define SCANOUT (PIPE_BIND_SCANOUT | PIPE_BIND_SHARED | 
PIPE_BIND_DISPLAY_TARGET)
 
 bool is_scanout = (res->bind & SCANOUT);
 bool is_texture = (res->bind & PIPE_BIND_SAMPLER_VIEW);
+bool is_renderable = (res->bind & PIPE_BIND_RENDER_TARGET);
 bool is_2d = res->depth0 == 1 && res->array_size == 1;
 bool is_streaming = (res->usage == PIPE_USAGE_STREAM);
 
-bool should_tile = !is_streaming && is_texture && is_2d && !is_scanout;
+bool should_tile = !is_streaming && is_texture && is_2d && 

[Mesa-dev] [PATCH 1/3] panfrost: Cache BO imports

[Tomeu Vizoso]

If two jobs use the same GEM object at the same time, the job that
finishes first will (previous to this commit) close the GEM object, even
if there's a job still referencing it.

To prevent this, have all jobs use the same panfrost_bo for a given GEM
object, so it's only closed once the last job is done with it.

Signed-off-by: Tomeu Vizoso 
---
 src/gallium/drivers/panfrost/pan_allocate.h |  2 +-
 src/gallium/drivers/panfrost/pan_drm.c  | 46 +++--
 src/gallium/drivers/panfrost/pan_resource.c | 20 -
 src/gallium/drivers/panfrost/pan_screen.h   |  6 +++
 4 files changed, 68 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_allocate.h 
b/src/gallium/drivers/panfrost/pan_allocate.h
index 20ba204dee86..2dfa913b8c4d 100644
--- a/src/gallium/drivers/panfrost/pan_allocate.h
+++ b/src/gallium/drivers/panfrost/pan_allocate.h
@@ -59,7 +59,7 @@ struct panfrost_transfer {
 };
 
 struct panfrost_bo {
-struct pipe_reference reference;
+int refcnt;
 
 /* Mapping for the entire object (all levels) */
 uint8_t *cpu;
diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
b/src/gallium/drivers/panfrost/pan_drm.c
index b89f8e66a877..9648ac1d452d 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -103,7 +103,12 @@ panfrost_drm_create_bo(struct panfrost_screen *screen, 
size_t size,
 // TODO map and unmap on demand?
 panfrost_drm_mmap_bo(screen, bo);
 
-pipe_reference_init(>reference, 1);
+p_atomic_set(>refcnt, 1);
+
+pthread_mutex_lock(>handle_table_lock);
+_mesa_hash_table_insert(screen->handle_table, >gem_handle, bo);
+pthread_mutex_unlock(>handle_table_lock);
+
 return bo;
 }
 
@@ -116,6 +121,9 @@ panfrost_drm_release_bo(struct panfrost_screen *screen, 
struct panfrost_bo *bo)
 if (!bo)
 return;
 
+pthread_mutex_lock(>handle_table_lock);
+_mesa_hash_table_remove_key(screen->handle_table, >gem_handle);
+
 panfrost_drm_munmap_bo(screen, bo);
 
 ret = drmIoctl(screen->fd, DRM_IOCTL_GEM_CLOSE, _close);
@@ -125,6 +133,8 @@ panfrost_drm_release_bo(struct panfrost_screen *screen, 
struct panfrost_bo *bo)
 }
 
 ralloc_free(bo);
+
+pthread_mutex_unlock(>handle_table_lock);
 }
 
 void
@@ -150,17 +160,41 @@ panfrost_drm_free_slab(struct panfrost_screen *screen, 
struct panfrost_memory *m
 mem->bo = NULL;
 }
 
+/* lookup a buffer, call w/ table_lock held: */
+static struct panfrost_bo *lookup_bo(struct hash_table *tbl, uint32_t key)
+{
+   struct panfrost_bo *bo = NULL;
+   struct hash_entry *entry = _mesa_hash_table_search(tbl, );
+   if (entry) {
+   /* found, incr refcnt and return: */
+   bo = entry->data;
+   panfrost_bo_reference(bo);
+   }
+   return bo;
+}
+
 struct panfrost_bo *
 panfrost_drm_import_bo(struct panfrost_screen *screen, int fd)
 {
-   struct panfrost_bo *bo = rzalloc(screen, struct panfrost_bo);
+   struct panfrost_bo *bo = NULL;
 struct drm_panfrost_get_bo_offset get_bo_offset = {0,};
 int ret;
 unsigned gem_handle;
 
+pthread_mutex_lock(>handle_table_lock);
+
ret = drmPrimeFDToHandle(screen->fd, fd, _handle);
assert(!ret);
 
+if (ret)
+goto out_unlock;
+
+bo = lookup_bo(screen->handle_table, gem_handle);
+if (bo)
+goto out_unlock;
+
+bo = rzalloc(screen, struct panfrost_bo);
+
get_bo_offset.handle = gem_handle;
 ret = drmIoctl(screen->fd, DRM_IOCTL_PANFROST_GET_BO_OFFSET, 
_bo_offset);
 assert(!ret);
@@ -169,10 +203,16 @@ panfrost_drm_import_bo(struct panfrost_screen *screen, 
int fd)
 bo->gpu = (mali_ptr) get_bo_offset.offset;
 bo->size = lseek(fd, 0, SEEK_END);
 assert(bo->size > 0);
-pipe_reference_init(>reference, 1);
+p_atomic_set(>refcnt, 1);
 
 // TODO map and unmap on demand?
 panfrost_drm_mmap_bo(screen, bo);
+
+_mesa_hash_table_insert(screen->handle_table, >gem_handle, bo);
+
+out_unlock:
+pthread_mutex_unlock(>handle_table_lock);
+
 return bo;
 }
 
diff --git a/src/gallium/drivers/panfrost/pan_resource.c 
b/src/gallium/drivers/panfrost/pan_resource.c
index b651fcffb111..beef26a5ded0 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -47,6 +47,18 @@
 #include "pan_util.h"
 #include "pan_tiling.h"
 
+static uint32_t
+u32_hash(const void *key)
+{
+return _mesa_hash_data(key, sizeof(uint32_t));
+}
+
+static bool
+u32_equals(const void *key1, const void *key2)
+{
+return *(const uint32_t *)key1 == *(const uint32_t *)key2;
+}
+
 static struct pipe_resource *
 panfrost_resource_from_handle(struct pipe_screen *pscreen,
   const struct pipe_resource 

[Mesa-dev] [PATCH 2/3] panfrost: Allocate scanout BOs in panfrost device

[Tomeu Vizoso]

In preparation for using AFBC for BOs that could be scanned out (though
they are likely to be only shared with the compositor for now), use the
buffer allocation UABI of the GPU driver, as dumb buffers cannot be
allocated for AFBC.

Signed-off-by: Tomeu Vizoso 
---
 src/gallium/drivers/panfrost/pan_resource.c   | 71 +--
 .../winsys/kmsro/drm/kmsro_drm_winsys.c   |  2 +-
 2 files changed, 33 insertions(+), 40 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_resource.c 
b/src/gallium/drivers/panfrost/pan_resource.c
index beef26a5ded0..54497d3de2bb 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -47,6 +47,13 @@
 #include "pan_util.h"
 #include "pan_tiling.h"
 
+static void
+panfrost_setup_slices(struct panfrost_resource *pres, size_t *bo_size);
+
+static void
+panfrost_resource_destroy(struct pipe_screen *screen,
+  struct pipe_resource *pt);
+
 static uint32_t
 u32_hash(const void *key)
 {
@@ -83,8 +90,12 @@ panfrost_resource_from_handle(struct pipe_screen *pscreen,
 prsc->screen = pscreen;
 
rsc->bo = panfrost_drm_import_bo(screen, whandle->handle);
-   rsc->slices[0].stride = whandle->stride;
-   rsc->slices[0].initialized = true;
+
+size_t bo_size;
+panfrost_setup_slices(rsc, _size);
+assert(bo_size == rsc->bo->size);
+for (unsigned l = 0; l <= rsc->base.last_level; ++l)
+rsc->slices[l].initialized = true;
 
if (screen->ro) {
rsc->scanout =
@@ -198,37 +209,6 @@ panfrost_surface_destroy(struct pipe_context *pipe,
 ralloc_free(surf);
 }
 
-static struct pipe_resource *
-panfrost_create_scanout_res(struct pipe_screen *screen,
-const struct pipe_resource *template)
-{
-struct panfrost_screen *pscreen = pan_screen(screen);
-struct pipe_resource scanout_templat = *template;
-struct renderonly_scanout *scanout;
-struct winsys_handle handle;
-struct pipe_resource *res;
-
-scanout = renderonly_scanout_for_resource(_templat,
-  pscreen->ro, );
-if (!scanout)
-return NULL;
-
-assert(handle.type == WINSYS_HANDLE_TYPE_FD);
-/* TODO: handle modifiers? */
-res = screen->resource_from_handle(screen, template, ,
-   
PIPE_HANDLE_USAGE_FRAMEBUFFER_WRITE);
-close(handle.handle);
-if (!res)
-return NULL;
-
-struct panfrost_resource *pres = pan_resource(res);
-
-pres->scanout = scanout;
-pscreen->display_target = pres;
-
-return res;
-}
-
 /* Computes sizes for checksumming, which is 8 bytes per 16x16 tile */
 
 #define CHECKSUM_TILE_WIDTH 16
@@ -382,11 +362,14 @@ panfrost_resource_create_bo(struct panfrost_screen 
*screen, struct panfrost_reso
 
 /* Tiling textures is almost always faster, unless we only use it once 
*/
 
+#define SCANOUT (PIPE_BIND_SCANOUT | PIPE_BIND_SHARED | 
PIPE_BIND_DISPLAY_TARGET)
+
+bool is_scanout = (res->bind & SCANOUT);
 bool is_texture = (res->bind & PIPE_BIND_SAMPLER_VIEW);
 bool is_2d = res->depth0 == 1 && res->array_size == 1;
-bool is_streaming = (res->usage != PIPE_USAGE_STREAM);
+bool is_streaming = (res->usage == PIPE_USAGE_STREAM);
 
-bool should_tile = is_streaming && is_texture && is_2d;
+bool should_tile = !is_streaming && is_texture && is_2d && !is_scanout;
 
 /* Depth/stencil can't be tiled, only linear or AFBC */
 should_tile &= !(res->bind & PIPE_BIND_DEPTH_STENCIL);
@@ -425,10 +408,6 @@ panfrost_resource_create(struct pipe_screen *screen,
 assert(0);
 }
 
-if (template->bind &
-(PIPE_BIND_DISPLAY_TARGET | PIPE_BIND_SCANOUT | PIPE_BIND_SHARED))
-return panfrost_create_scanout_res(screen, template);
-
 struct panfrost_resource *so = rzalloc(screen, struct 
panfrost_resource);
 struct panfrost_screen *pscreen = (struct panfrost_screen *) screen;
 
@@ -440,6 +419,20 @@ panfrost_resource_create(struct pipe_screen *screen,
 util_range_init(>valid_buffer_range);
 
 panfrost_resource_create_bo(pscreen, so);
+
+/* Set up the "scanout resource" (the dmabuf export of our buffer to
+ * the KMS handle) if the buffer might ever have
+ * resource_get_handle(WINSYS_HANDLE_TYPE_KMS) called on it.
+ */
+if (template->bind & PIPE_BIND_SCANOUT) {
+so->scanout =
+renderonly_scanout_for_resource(>base, 
pscreen->ro, NULL);
+if (!so->scanout) {
+panfrost_resource_destroy(screen, >base);
+return NULL;
+}
+}
+
 return (struct pipe_resource *)so;
 }
 
diff --git 

[Mesa-dev] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

--- Comment #9 from Shmerl  ---
The game and layer are both 64-bit.

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

[Mesa-dev] [PATCH] panfrost: Take into account off-screen FBOs

[Tomeu Vizoso]

In that case, ctx->pipe_framebuffer.cbufs[0] can be NULL.

Signed-off-by: Tomeu Vizoso 
Cc: Boris Brezillon 
Fixes: 5375d009be18 ("panfrost: Pass referenced BOs to the SUBMIT ioctls")
---
 src/gallium/drivers/panfrost/pan_drm.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
b/src/gallium/drivers/panfrost/pan_drm.c
index 8de4f483435c..b89f8e66a877 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -238,7 +238,6 @@ panfrost_drm_submit_job(struct panfrost_context *ctx, u64 
job_desc, int reqs)
 int
 panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx, bool has_draws, 
bool is_scanout)
 {
-struct pipe_surface *surf = ctx->pipe_framebuffer.cbufs[0];
int ret;
 
 struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
@@ -256,9 +255,12 @@ panfrost_drm_submit_vs_fs_job(struct panfrost_context 
*ctx, bool has_draws, bool
 }
 
 if (job->first_tiler.gpu || job->clear) {
-struct panfrost_resource *res = pan_resource(surf->texture);
-assert(res->bo);
-panfrost_job_add_bo(job, res->bo);
+struct pipe_surface *surf = ctx->pipe_framebuffer.cbufs[0];
+if (surf) {
+struct panfrost_resource *res = 
pan_resource(surf->texture);
+assert(res->bo);
+panfrost_job_add_bo(job, res->bo);
+}
 ret = panfrost_drm_submit_job(ctx, panfrost_fragment_job(ctx, 
has_draws), PANFROST_JD_REQ_FS);
 assert(!ret);
 }
-- 
2.20.1

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

[Mesa-dev] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

--- Comment #8 from Eero Tamminen  ---
Have you checked it's not 32-bit vs. 64-bit issue?

("file" command tells you which arch given library/binary is using, and you can
see where the game binary / libraries are from /proc/PID/maps file.)

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

Re: [Mesa-dev] radeonsi: glmark2 - regression (GL_INVALID_OPERATION in glFramebufferTexture2D) - bisected

[Michel Dänzer]

On 2019-07-03 8:49 p.m., Marek Olšák wrote:
> NDEBUG is set = release
> NDEBUG is not set = debugoptimized
> NDEBUG is not set and DEBUG is set = debug
> 
> NDEBUG is not set ---> enable assertions and cheap debug code, NIR enables
> expensive validations
> DEBUG is set ---> enable possibly very expensive debug code, may be
> replaced by !NDEBUG in the future

There is no such connection between DEBUG and NDEBUG.

DEBUG is controlled by the meson buildtype configuration item, release
and debugoptimized being two out of more possible values.

NDEBUG is controlled by meson's b_ndebug configuration item. While its
default value depends on the build type, it can be freely enabled or
disabled with any build type.


-- 
Earthling Michel Dänzer   |  https://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] [Bug 110735] Meson can't find 32-bit libXvMCW in non-standard path

[bugzilla-daemon]

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

--- Comment #1 from charlie  ---
As a temporary work around--link to code from non-standard directory to the
32-bit /usr/lib directory, for example:

if [[ $ARCH == *86 ]]; then
sudo find ${HOME}/lib32/ -name "libXvMC*" -type f -maxdepth 1 -exec bash -c 'ln
-s "$0" /usr/lib/"${0##*/}"' {} \;
sudo find ${HOME}/lib32/ -name "libXvMC*" -type l -maxdepth 1 -exec bash -c 'ln
-s "$0" /usr/lib/"${0##*/}"' {} \;
fi

Then delete links after compiling finishes:

sudo rm /usr/lib/libXvMC*

_
Update: setting an rpath on 32-bit complied libXvMC* would still not let Meson
find the libs.

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

[Mesa-dev] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

--- Comment #7 from Shmerl  ---
This part looks weird (i.e. vulkan/linux there)

DEBUG: ReadDataFilesInSearchPaths: Searching the following paths for manifest
files: vulkan/linux

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

[Mesa-dev] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

--- Comment #6 from Shmerl  ---
I see a strange difference. I placed my built layer in /opt/mesa-master. For
vkcube when it works, I run it like this:

VK_LOADER_DEBUG=all
VK_LAYER_PATH=/opt/mesa-master/share/vulkan/explicit_layer.d
VK_INSTANCE_LAYERS=VK_LAYER_MESA_overlay vkcube

Result (it finds it):

...
DEBUG: ReadDataFilesInSearchPaths: Searching the following paths for manifest
files:
/etc/xdg/vulkan/implicit_layer.d:/etc/vulkan/implicit_layer.d:/usr/share/vulkan/implicit_layer.d:/usr/share/vulkan/implicit_layer.d:/usr/local/share/vulkan/implicit_layer.d:/home/user/.local/share/vulkan/implicit_layer.d

DEBUG: ReadDataFilesInSearchPaths: Searching the following paths for manifest
files:
/etc/xdg/vulkan/implicit_layer.d:/etc/vulkan/implicit_layer.d:/usr/share/vulkan/implicit_layer.d:/usr/share/vulkan/implicit_layer.d:/usr/local/share/vulkan/implicit_layer.d:/home/user/.local/share/vulkan/implicit_layer.d

DEBUG: ReadDataFilesInSearchPaths: Searching the following paths for manifest
files: /opt/mesa-master/share/vulkan/explicit_layer.d
...


For X4, when it doesn't work:

VK_LOADER_DEBUG=all
VK_LAYER_PATH=/opt/mesa-master/share/vulkan/explicit_layer.d
VK_INSTANCE_LAYERS=VK_LAYER_MESA_overlay ./X4

Result:

...
DEBUG: ReadDataFilesInSearchPaths: Searching the following paths for manifest
files:
/etc/xdg/vulkan/implicit_layer.d:/etc/vulkan/implicit_layer.d:/usr/share/vulkan/implicit_layer.d:/usr/share/vulkan/implicit_layer.d:/usr/local/share/vulkan/implicit_layer.d:/home/user/.local/share/vulkan/implicit_layer.d

DEBUG: ReadDataFilesInSearchPaths: Searching the following paths for manifest
files:
/etc/xdg/vulkan/implicit_layer.d:/etc/vulkan/implicit_layer.d:/usr/share/vulkan/implicit_layer.d:/usr/share/vulkan/implicit_layer.d:/usr/local/share/vulkan/implicit_layer.d:/home/user/.local/share/vulkan/implicit_layer.d

DEBUG: ReadDataFilesInSearchPaths: Searching the following paths for manifest
files: vulkan/linux

DEBUG: ReadDataFilesInSearchPaths: Searching the following paths for manifest
files:
/etc/xdg/vulkan/icd.d:/etc/vulkan/icd.d:/usr/share/vulkan/icd.d:/usr/share/vulkan/icd.d:/usr/local/share/vulkan/icd.d:/home/user/.local/share/vulkan/icd.d
...
WARNING: loaderAddLayerNameToList: Failed to find layer name
VK_LAYER_MESA_overlay to activate
WARNING: loaderAddLayerNameToList: Failed to find layer name
VK_LAYER_MESA_overlay to activate
...

Somehow search resolution is different so it doesn't find it.

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

[Mesa-dev] [Bug 110735] Meson can't find 32-bit libXvMCW in non-standard path

[bugzilla-daemon]

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

charlie  changed:

   What|Removed |Added

 CC||baker.dyla...@gmail.com

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

[Mesa-dev] [Bug 111054] Vulkan overlay doesn't work with X4: Foundations

[bugzilla-daemon]

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

--- Comment #5 from Lionel Landwerlin  ---
Running with VK_LOADER_DEBUG=all might help figuring out what's going wrong.

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

[Mesa-dev] [PATCH 2/2] radv: do not crash when generating binning state for unknown chips

[Samuel Pitoiset]

These values are only useful if binning is disabled.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_pipeline.c | 44 +-
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 71d3be240b2..49687405705 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -2691,29 +2691,29 @@ radv_pipeline_generate_binning_state(struct 
radeon_cmdbuf *ctx_cs,
 
VkExtent2D bin_size = radv_compute_bin_size(pipeline, pCreateInfo);
 
-   unsigned context_states_per_bin; /* allowed range: [1, 6] */
-   unsigned persistent_states_per_bin; /* allowed range: [1, 32] */
-   unsigned fpovs_per_batch; /* allowed range: [0, 255], 0 = unlimited */
-
-   switch (pipeline->device->physical_device->rad_info.family) {
-   case CHIP_VEGA10:
-   case CHIP_VEGA12:
-   case CHIP_VEGA20:
-   context_states_per_bin = 1;
-   persistent_states_per_bin = 1;
-   fpovs_per_batch = 63;
-   break;
-   case CHIP_RAVEN:
-   case CHIP_RAVEN2:
-   context_states_per_bin = 6;
-   persistent_states_per_bin = 32;
-   fpovs_per_batch = 63;
-   break;
-   default:
-   unreachable("unhandled family while determining binning 
state.");
-   }
-
if (pipeline->device->pbb_allowed && bin_size.width && bin_size.height) 
{
+   unsigned context_states_per_bin; /* allowed range: [1, 6] */
+   unsigned persistent_states_per_bin; /* allowed range: [1, 32] */
+   unsigned fpovs_per_batch; /* allowed range: [0, 255], 0 = 
unlimited */
+
+   switch (pipeline->device->physical_device->rad_info.family) {
+   case CHIP_VEGA10:
+   case CHIP_VEGA12:
+   case CHIP_VEGA20:
+   context_states_per_bin = 1;
+   persistent_states_per_bin = 1;
+   fpovs_per_batch = 63;
+   break;
+   case CHIP_RAVEN:
+   case CHIP_RAVEN2:
+   context_states_per_bin = 6;
+   persistent_states_per_bin = 32;
+   fpovs_per_batch = 63;
+   break;
+   default:
+   unreachable("unhandled family while determining binning 
state.");
+   }
+
pa_sc_binner_cntl_0 =
S_028C44_BINNING_MODE(V_028C44_BINNING_ALLOWED) |
S_028C44_BIN_SIZE_X(bin_size.width == 16) |
-- 
2.22.0

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

[Mesa-dev] [PATCH 1/2] radv: fix potential crash in the compute resolve path

[Samuel Pitoiset]

If the destination attachment is UNUSED.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_meta_resolve_cs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_resolve_cs.c 
b/src/amd/vulkan/radv_meta_resolve_cs.c
index 7d3cc166e0d..13c61509b21 100644
--- a/src/amd/vulkan/radv_meta_resolve_cs.c
+++ b/src/amd/vulkan/radv_meta_resolve_cs.c
@@ -917,12 +917,13 @@ radv_cmd_buffer_resolve_subpass_cs(struct radv_cmd_buffer 
*cmd_buffer)
for (uint32_t i = 0; i < subpass->color_count; ++i) {
struct radv_subpass_attachment src_att = 
subpass->color_attachments[i];
struct radv_subpass_attachment dst_att = 
subpass->resolve_attachments[i];
-   struct radv_image_view *src_iview = 
fb->attachments[src_att.attachment].attachment;
-   struct radv_image_view *dst_iview = 
fb->attachments[dst_att.attachment].attachment;
 
if (dst_att.attachment == VK_ATTACHMENT_UNUSED)
continue;
 
+   struct radv_image_view *src_iview = 
fb->attachments[src_att.attachment].attachment;
+   struct radv_image_view *dst_iview = 
fb->attachments[dst_att.attachment].attachment;
+
VkImageResolve region = {
.extent = (VkExtent3D){ fb->width, fb->height, 0 },
.srcSubresource = (VkImageSubresourceLayers) {
-- 
2.22.0

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