[Mesa-dev] [PATCH] mesa: Make gl_vertex_array contain pointers to first order VAO members.

[Mathias . Froehlich]

From: Mathias Fröhlich 

Hi,

The change basically strips down gl_vertex_array to two pointers
into the VAO. Consequently the current vertex attributes in the
vbo module need to be represented by structs present in the VAO
instead of gl_vertex_array instances.
The change prepares the backends somewhat to use the _DrawVAO for
draw operations in the longer term.

The change introduced no piglit quick regressions on classic swrast
to test drivers using tnl, i965 and radeonsi.

Please review!
Thanks!

best
Mathias


Instead of keeping a copy of the vertex array content in
struct gl_vertex_array only keep pointers to the first order
information originaly in the VAO.
For that represent the current values by struct gl_array_attributes
and struct gl_vertex_buffer_binding.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/drivers/dri/i965/brw_context.h   |   2 +-
 src/mesa/drivers/dri/i965/brw_draw.c  |  30 +++---
 src/mesa/drivers/dri/i965/brw_draw_upload.c   | 130 ++
 src/mesa/drivers/dri/i965/genX_state_upload.c |  23 +++--
 src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c  |  86 ++---
 src/mesa/main/arrayobj.c  |  16 
 src/mesa/main/attrib.c|   1 -
 src/mesa/main/mtypes.h|  47 +++---
 src/mesa/main/varray.c|  21 -
 src/mesa/main/varray.h|  49 +++---
 src/mesa/state_tracker/st_atom.c  |   7 +-
 src/mesa/state_tracker/st_atom_array.c| 115 ++-
 src/mesa/state_tracker/st_cb_rasterpos.c  |  26 +++---
 src/mesa/state_tracker/st_draw_feedback.c |  46 ++---
 src/mesa/tnl/t_draw.c |  81 
 src/mesa/tnl/t_rebase.c   |  20 ++--
 src/mesa/tnl/t_rebase.h   |   2 +-
 src/mesa/vbo/vbo.h|   4 +-
 src/mesa/vbo/vbo_context.c|  52 +--
 src/mesa/vbo/vbo_exec.c   |  16 ++--
 src/mesa/vbo/vbo_exec_api.c   |  22 ++---
 src/mesa/vbo/vbo_private.h|   3 +-
 src/mesa/vbo/vbo_save_draw.c  |   2 +-
 src/mesa/vbo/vbo_split.c  |   2 +-
 src/mesa/vbo/vbo_split.h  |   4 +-
 src/mesa/vbo/vbo_split_copy.c |  97 +++
 src/mesa/vbo/vbo_split_inplace.c  |   6 +-
 27 files changed, 480 insertions(+), 430 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index d6e3c7807f..ee55c32087 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1456,7 +1456,7 @@ gl_clip_plane *brw_select_clip_planes(struct gl_context 
*ctx);
 
 /* brw_draw_upload.c */
 unsigned brw_get_vertex_surface_type(struct brw_context *brw,
- const struct gl_vertex_array *glarray);
+ const struct gl_array_attributes *glattr);
 
 static inline unsigned
 brw_get_index_type(unsigned index_size)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 299e7f929e..677eb87729 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -277,7 +277,7 @@ brw_emit_prim(struct brw_context *brw,
 
 static void
 brw_merge_inputs(struct brw_context *brw,
- const struct gl_vertex_array *arrays[])
+ const struct gl_vertex_array *arrays)
 {
const struct gen_device_info *devinfo = >screen->devinfo;
const struct gl_context *ctx = >ctx;
@@ -291,7 +291,7 @@ brw_merge_inputs(struct brw_context *brw,
 
for (i = 0; i < VERT_ATTRIB_MAX; i++) {
   brw->vb.inputs[i].buffer = -1;
-  brw->vb.inputs[i].glarray = arrays[i];
+  brw->vb.inputs[i].glarray = [i];
}
 
if (devinfo->gen < 8 && !devinfo->is_haswell) {
@@ -300,14 +300,18 @@ brw_merge_inputs(struct brw_context *brw,
* 2_10_10_10_REV vertex formats.  Set appropriate workaround flags.
*/
   while (mask) {
+ const struct gl_vertex_array *glarray;
+ const struct gl_array_attributes *glattrib;
  uint8_t wa_flags = 0;
 
  i = u_bit_scan64();
+ glarray = brw->vb.inputs[i].glarray;
+ glattrib = glarray->VertexAttrib;
 
- switch (brw->vb.inputs[i].glarray->Type) {
+ switch (glattrib->Type) {
 
  case GL_FIXED:
-wa_flags = brw->vb.inputs[i].glarray->Size;
+wa_flags = glattrib->Size;
 break;
 
  case GL_INT_2_10_10_10_REV:
@@ -315,12 +319,12 @@ brw_merge_inputs(struct brw_context *brw,
 /* fallthough */
 
  case GL_UNSIGNED_INT_2_10_10_10_REV:
-if (brw->vb.inputs[i].glarray->Format == GL_BGRA)
+if (glattrib->Format == 

Re: [Mesa-dev] [PATCH 1/4] glxinfo/wglinfo: remove print_shader_limits() code

[Mathias Fröhlich]

Hi Brian,

On Monday, 5 March 2018 17:53:01 CET Brian Paul wrote:
> And add queries of GL 2.0 limits.  All the VS, FS, GS limits which were
> reported with print_shader_limits() are also covered by the GL 2.0 and
> 3.2 queries.

You can put my 

Reviewed-by: Mathias Fröhlich 

to the series.

best

Mathias


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

Re: [Mesa-dev] [PATCH] glsl: Fix memory leak with known glsl_type instances

[Tapani Pälli]

Hi;

On 01.03.2018 03:12, Kenneth Graunke wrote:

On Thursday, February 15, 2018 1:12:54 AM PST Tapani Pälli wrote:

From: Simon Hausmann 

When looking up known glsl_type instances in the various hash tables, we
end up leaking the key instances used for the lookup, as the glsl_type
constructor allocates memory on the global mem_ctx. This patch changes
glsl_type to manage its own memory, which fixes the leak and also allows
getting rid of the global mem_ctx and its mutex.

v2: remove lambda usage (Tapani)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104884
Signed-off-by: Simon Hausmann 
Signed-off-by: Tapani Pälli 
---
  src/compiler/glsl_types.cpp | 83 -
  src/compiler/glsl_types.h   | 44 +++-
  2 files changed, 41 insertions(+), 86 deletions(-)

diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index 3cc5eb0495..81ff97b1f7 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -28,23 +28,12 @@
  #include "util/hash_table.h"
  
  
-mtx_t glsl_type::mem_mutex = _MTX_INITIALIZER_NP;

  mtx_t glsl_type::hash_mutex = _MTX_INITIALIZER_NP;
  hash_table *glsl_type::array_types = NULL;
  hash_table *glsl_type::record_types = NULL;
  hash_table *glsl_type::interface_types = NULL;
  hash_table *glsl_type::function_types = NULL;
  hash_table *glsl_type::subroutine_types = NULL;
-void *glsl_type::mem_ctx = NULL;
-
-void
-glsl_type::init_ralloc_type_ctx(void)
-{
-   if (glsl_type::mem_ctx == NULL) {
-  glsl_type::mem_ctx = ralloc_context(NULL);
-  assert(glsl_type::mem_ctx != NULL);
-   }
-}
  
  glsl_type::glsl_type(GLenum gl_type,

   glsl_base_type base_type, unsigned vector_elements,
@@ -63,14 +52,12 @@ glsl_type::glsl_type(GLenum gl_type,
 STATIC_ASSERT((unsigned(GLSL_TYPE_INT)   & 3) == unsigned(GLSL_TYPE_INT));
 STATIC_ASSERT((unsigned(GLSL_TYPE_FLOAT) & 3) == 
unsigned(GLSL_TYPE_FLOAT));
  
-   mtx_lock(_type::mem_mutex);

+   this->mem_ctx = ralloc_context(NULL);
+   assert(this->mem_ctx != NULL);
  
-   init_ralloc_type_ctx();

 assert(name != NULL);
 this->name = ralloc_strdup(this->mem_ctx, name);
  
-   mtx_unlock(_type::mem_mutex);

-
 /* Neither dimension is zero or both dimensions are zero.
  */
 assert((vector_elements == 0) == (matrix_columns == 0));
@@ -86,14 +73,12 @@ glsl_type::glsl_type(GLenum gl_type, glsl_base_type 
base_type,
 sampler_array(array), interface_packing(0),
 interface_row_major(0), length(0)
  {
-   mtx_lock(_type::mem_mutex);
+   this->mem_ctx = ralloc_context(NULL);
+   assert(this->mem_ctx != NULL);
  
-   init_ralloc_type_ctx();

 assert(name != NULL);
 this->name = ralloc_strdup(this->mem_ctx, name);
  
-   mtx_unlock(_type::mem_mutex);

-
 memset(& fields, 0, sizeof(fields));
  
 matrix_columns = vector_elements = 1;

@@ -110,9 +95,9 @@ glsl_type::glsl_type(const glsl_struct_field *fields, 
unsigned num_fields,
  {
 unsigned int i;
  
-   mtx_lock(_type::mem_mutex);

+   this->mem_ctx = ralloc_context(NULL);
+   assert(this->mem_ctx != NULL);
  
-   init_ralloc_type_ctx();

 assert(name != NULL);
 this->name = ralloc_strdup(this->mem_ctx, name);
 this->fields.structure = ralloc_array(this->mem_ctx,
@@ -123,8 +108,6 @@ glsl_type::glsl_type(const glsl_struct_field *fields, 
unsigned num_fields,
this->fields.structure[i].name = ralloc_strdup(this->fields.structure,
   fields[i].name);
 }
-
-   mtx_unlock(_type::mem_mutex);
  }
  
  glsl_type::glsl_type(const glsl_struct_field *fields, unsigned num_fields,

@@ -140,9 +123,9 @@ glsl_type::glsl_type(const glsl_struct_field *fields, 
unsigned num_fields,
  {
 unsigned int i;
  
-   mtx_lock(_type::mem_mutex);

+   this->mem_ctx = ralloc_context(NULL);
+   assert(this->mem_ctx != NULL);
  
-   init_ralloc_type_ctx();

 assert(name != NULL);
 this->name = ralloc_strdup(this->mem_ctx, name);
 this->fields.structure = rzalloc_array(this->mem_ctx,
@@ -152,8 +135,6 @@ glsl_type::glsl_type(const glsl_struct_field *fields, 
unsigned num_fields,
this->fields.structure[i].name = ralloc_strdup(this->fields.structure,
   fields[i].name);
 }
-
-   mtx_unlock(_type::mem_mutex);
  }
  
  glsl_type::glsl_type(const glsl_type *return_type,

@@ -167,9 +148,8 @@ glsl_type::glsl_type(const glsl_type *return_type,
  {
 unsigned int i;
  
-   mtx_lock(_type::mem_mutex);

-
-   init_ralloc_type_ctx();
+   this->mem_ctx = ralloc_context(NULL);
+   assert(this->mem_ctx != NULL);
  
 this->fields.parameters = rzalloc_array(this->mem_ctx,

 glsl_function_param, num_params + 
1);
@@ -185,8 +165,6 @@ glsl_type::glsl_type(const glsl_type *return_type,
this->fields.parameters[i + 

Re: [Mesa-dev] [PATCH] intel: Add missing includes for building on Android

[Tapani Pälli]

LGTM
Reviewed-by: Tapani Pälli 

On 06.03.2018 03:00, Clayton Craft wrote:

This adds a missing library to the i965/Android.mk file, and updates
intel/Android.mk to include the new library. Without this, mesa does not
build on Android.

Fixes: 272bef0601a "intel: Split gen_device_info out into
libintel_dev"
---
  src/intel/Android.mk | 1 +
  src/mesa/drivers/dri/i965/Android.mk | 1 +
  2 files changed, 2 insertions(+)

diff --git a/src/intel/Android.mk b/src/intel/Android.mk
index db6c770f35..380473d0ac 100644
--- a/src/intel/Android.mk
+++ b/src/intel/Android.mk
@@ -28,6 +28,7 @@ include $(LOCAL_PATH)/Makefile.sources
  include $(LOCAL_PATH)/Android.blorp.mk
  include $(LOCAL_PATH)/Android.common.mk
  include $(LOCAL_PATH)/Android.compiler.mk
+include $(LOCAL_PATH)/Android.dev.mk
  include $(LOCAL_PATH)/Android.genxml.mk
  include $(LOCAL_PATH)/Android.isl.mk
  include $(LOCAL_PATH)/Android.vulkan.mk
diff --git a/src/mesa/drivers/dri/i965/Android.mk 
b/src/mesa/drivers/dri/i965/Android.mk
index 83959cbf6c..964313e6c5 100644
--- a/src/mesa/drivers/dri/i965/Android.mk
+++ b/src/mesa/drivers/dri/i965/Android.mk
@@ -289,6 +289,7 @@ LOCAL_SRC_FILES := \
  LOCAL_WHOLE_STATIC_LIBRARIES := \
$(MESA_DRI_WHOLE_STATIC_LIBRARIES) \
$(I965_PERGEN_LIBS) \
+   libmesa_intel_dev \
libmesa_intel_common \
libmesa_isl \
libmesa_blorp \


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

[Mesa-dev] [PATCH 1/3] glx/dri: Add a driconf option to disable GLX_SGI_video_sync

[Thomas Hellstrom]

Drivers on virtual hardware don't want to expose this extension to
GLX compositors, similarly to GLX_OML_sync_control, since that significantly
increases latency.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 
Reviewed-by: Deepak Rawat 
---
 src/glx/dri2_glx.c   | 9 ++---
 src/glx/dri3_glx.c   | 6 +-
 src/util/xmlpool/t_options.h | 5 +
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 0f44635725..91afc33750 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -1102,7 +1102,6 @@ dri2BindExtensions(struct dri2_screen *psc, struct 
glx_display * priv,
 
extensions = psc->core->getExtensions(psc->driScreen);
 
-   __glXEnableDirectExtension(>base, "GLX_SGI_video_sync");
__glXEnableDirectExtension(>base, "GLX_SGI_swap_control");
__glXEnableDirectExtension(>base, "GLX_MESA_swap_control");
__glXEnableDirectExtension(>base, "GLX_SGI_make_current_read");
@@ -1207,6 +1206,7 @@ dri2CreateScreen(int screen, struct glx_display * priv)
char *driverName = NULL, *loader_driverName, *deviceName, *tmp;
drm_magic_t magic;
int i;
+   unsigned char disable;
 
psc = calloc(1, sizeof *psc);
if (psc == NULL)
@@ -1325,8 +1325,6 @@ dri2CreateScreen(int screen, struct glx_display * priv)
psp->getBufferAge = NULL;
 
if (pdp->driMinor >= 2) {
-  unsigned char disable;
-
   psp->getDrawableMSC = dri2DrawableGetMSC;
   psp->waitForMSC = dri2WaitForMSC;
   psp->waitForSBC = dri2WaitForSBC;
@@ -1338,6 +1336,11 @@ dri2CreateScreen(int screen, struct glx_display * priv)
  __glXEnableDirectExtension(>base, "GLX_OML_sync_control");
}
 
+   if (psc->config->configQueryb(psc->driScreen,
+ "glx_disable_sgi_video_sync",
+ ) || !disable)
+  __glXEnableDirectExtension(>base, "GLX_SGI_video_sync");
+
/* DRI2 supports SubBuffer through DRI2CopyRegion, so it's always
 * available.*/
psp->copySubBuffer = dri2CopySubBuffer;
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 016f91b196..adfc349968 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -721,7 +721,6 @@ dri3_bind_extensions(struct dri3_screen *psc, struct 
glx_display * priv,
 
extensions = psc->core->getExtensions(psc->driScreen);
 
-   __glXEnableDirectExtension(>base, "GLX_SGI_video_sync");
__glXEnableDirectExtension(>base, "GLX_SGI_swap_control");
__glXEnableDirectExtension(>base, "GLX_MESA_swap_control");
__glXEnableDirectExtension(>base, "GLX_SGI_make_current_read");
@@ -956,6 +955,11 @@ dri3_create_screen(int screen, struct glx_display * priv)
  ) || !disable)
   __glXEnableDirectExtension(>base, "GLX_OML_sync_control");
 
+   if (psc->config->configQueryb(psc->driScreen,
+ "glx_disable_sgi_video_sync",
+ ) || !disable)
+  __glXEnableDirectExtension(>base, "GLX_SGI_video_sync");
+
psp->copySubBuffer = dri3_copy_sub_buffer;
__glXEnableDirectExtension(>base, "GLX_MESA_copy_sub_buffer");
 
diff --git a/src/util/xmlpool/t_options.h b/src/util/xmlpool/t_options.h
index 5f377c9dcd..3ada813d63 100644
--- a/src/util/xmlpool/t_options.h
+++ b/src/util/xmlpool/t_options.h
@@ -346,6 +346,11 @@ DRI_CONF_OPT_BEGIN_B(glx_disable_oml_sync_control, def) \
DRI_CONF_DESC(en, gettext("Disable the GLX_OML_sync_control extension")) \
 DRI_CONF_OPT_END
 
+#define DRI_CONF_DISABLE_SGI_VIDEO_SYNC(def) \
+DRI_CONF_OPT_BEGIN_B(glx_disable_sgi_video_sync, def) \
+   DRI_CONF_DESC(en, gettext("Disable the GLX_SGI_video_sync extension")) \
+DRI_CONF_OPT_END
+
 
 /**
  * \brief Software-fallback options.  To allow using features (like
-- 
2.14.3

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

[Mesa-dev] [PATCH 3/3] drirc: Disable the GLX_SGI_video_sync extension for gnome-shell on vmware

[Thomas Hellstrom]

With this extension enabled and a server GLX implementation that actually
honors it, Window movement lags considerably on gnome-shell/vmware, so
disable it by default.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 
Reviewed-by: Deepak Rawat 
---
 src/util/drirc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/util/drirc b/src/util/drirc
index bdc90227c6..c964588e72 100644
--- a/src/util/drirc
+++ b/src/util/drirc
@@ -275,6 +275,7 @@ TODO: document the other workarounds.
 
 
 
+
 

 
-- 
2.14.3

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

[Mesa-dev] [PATCH 0/3] Fix vmware dri3 latency on gnome-shell

[Thomas Hellstrom]

Similarly to what we previously did for GLX_OML_sync_control, we want to
disable the GLX_SGI_video_sync extension for gnome-shell on vmware. With
either of these extensions enabled, window movement lag increases
significantly.

The reason this hits with dri3 and not with dri2 is that with dri2 on
xf86-video-vmware, this extension is enabled, although not fully implemented.
With dri3 we actually sync to the X server's built in fake 60Hz vblank
interval.


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

[Mesa-dev] [PATCH 2/3] gallium/st_dri: Honor the glx_disable_sgi_video_sync config option

[Thomas Hellstrom]

This option is disabled by default. Primarily intended for drivers on
virtual hardware.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 
Reviewed-by: Deepak Rawat 
---
 src/gallium/auxiliary/pipe-loader/driinfo_gallium.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h 
b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
index 505aae402e..21dc599dc2 100644
--- a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
+++ b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
@@ -4,6 +4,7 @@ DRI_CONF_SECTION_PERFORMANCE
DRI_CONF_MESA_NO_ERROR("false")
DRI_CONF_DISABLE_EXT_BUFFER_AGE("false")
DRI_CONF_DISABLE_OML_SYNC_CONTROL("false")
+   DRI_CONF_DISABLE_SGI_VIDEO_SYNC("false")
 DRI_CONF_SECTION_END
 
 DRI_CONF_SECTION_QUALITY
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH] anv/entrypoints: VkGetDeviceProcAddr returns NULL for core instance commands

[Iago Toral]

On Mon, 2018-03-05 at 12:11 +, Emil Velikov wrote:
> Hi Iago,
> 
> Top level questions:
> 
> I think this and the original commit should go to stable right?

I am not sure if this qualifies for stable: these patches don't fix any
user-visible bugs. If an application was calling vkGetDeviceProcAddr to
get pointers to non-device functions (which is incorrect by the spec)
the previous behavior would allow it to get away with it without
issues, bit with these patches it will start to crash since it will
receive NULL pointers.

> The dispatch in 17.3 is very different making, yet 18.0 should be
> perfectly fine.
> 
> Mildly related - anv is missing a special case for following three
> extensions. Should we port those over from radv?
> 
> vkCreateInstance vkEnumerateInstanceExtensionProperties
> vkEnumerateInstanceLayerProperties

What is the exception exactly? Right now we report NULL for these from
vkGetDeviceProcAddr which is the right thing to do.

> Bas, you might want to port these over?
> 
> On 5 March 2018 at 10:46, Iago Toral Quiroga 
> wrote:
> > af5f2322d0c64 addressed this for extension commands, but the spec
> > mandates
> > this behavior also for core API commands. From the Vulkan spec,
> > Table 2. vkGetDeviceProcAddr behavior:
> > 
> > device pnamereturn
> > --
> > (..)
> > device core device-level commandfp
> > (...)
> > 
> > See that it specifically states "device-level".
> > 
> > Since the vk.xml file doesn't state if core commands are instance
> > or
> > device level, we identify device level commands as the ones that
> > take a
> > VkDevice, VkQueue or VkCommandBuffer as their first parameter.
> > 
> > Fixes test failures in new work-in-progress CTS tests.
> 
> AFAICT this and the original patch are in-light of the following
> github issue, right?
> If so, please add it to the commit message.
> 
> https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issu
> es/2323

Yes, they are both related to that. I'll add the reference in the
commit log.

> > ---
> >  src/intel/vulkan/anv_entrypoints_gen.py | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/intel/vulkan/anv_entrypoints_gen.py
> > b/src/intel/vulkan/anv_entrypoints_gen.py
> > index 34ffedb116..f0bfc3b6f8 100644
> > --- a/src/intel/vulkan/anv_entrypoints_gen.py
> > +++ b/src/intel/vulkan/anv_entrypoints_gen.py
> > @@ -222,7 +222,11 @@ anv_entrypoint_is_enabled(int index, uint32_t
> > core_version,
> >  % for e in entrypoints:
> > case ${e.num}:
> > % if e.core_version:
> > -  return ${e.core_version.c_vk_version()} <= core_version;
> > +  % if e.instance_dispatch:
> > + return !device && ${e.core_version.c_vk_version()} <=
> > core_version;
> > +  % else:
> > + return ${e.core_version.c_vk_version()} <= core_version;
> > +  % endif
> > % elif e.extension:
> >% if e.extension.type == 'instance':
> >return !device && instance->${e.extension.name[3:]};
> > @@ -350,6 +354,12 @@ def cal_hash(name):
> > 
> >  EntrypointParam = namedtuple('EntrypointParam', 'type name decl')
> > 
> > +DeviceChildrenList = ['VkDevice', 'VkQueue', 'VkCommandBuffer' ]
> > +
> > +def is_device_child(name):
> > +   """Tell if the given type name is a VkDevice or one of its
> > children."""
> > +   return name in DeviceChildrenList
> > +
> >  class Entrypoint(object):
> >  def __init__(self, name, return_type, params, guard = None):
> >  self.name = name
> > @@ -358,6 +368,7 @@ class Entrypoint(object):
> >  self.guard = guard
> >  self.enabled = False
> >  self.num = None
> > +self.instance_dispatch = not
> > is_device_child(params[0].type)
> 
> On a quick look this seems odd - one is interested in instance
> dispatch, yet checking for device.
> There are some subtleties about it in the above mentioned report.
> 
> Please add a small comment about those.
> 
> With the link + trivial comment the patch is
> Reviewed-by: Emil Velikov 
> 
> -Emil
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Status of radeonsi NIR

[Timothy Arceri]

On 05/03/18 03:43, Benedikt Schemmer wrote:

Hi all,
I thought I'd do some testing on my machine to see if there are any 
problems with nir (enabled with R600_DEBUG=nir)


Tested on Ubuntu 17.10 with mesa git of today
(oibaf for 32 bit, mine with LLVM5.0 on 64 bit because I cant figure out 
how to build 32bit drivers on ubuntu :( )

Xeon 1260l and 8GB DDR3-10600 with RX460 4GB

works means no obvious visual artifacts etc.
I didn't have time to do detailed benchmarking.

---

Alien Isolation - works

Bioshock Infinite - works, nonir Overall avg 45.58, min 9.81, max 
104.49; nir avg 31.47 min 8.35 max 94.19


Hi,

Do you recall what resolution / settings you used?

With a quick test I'm seeing pretty good results on Ultra.

3840 x 2160 - Ultra on RX 580: (tgsi) 90.89, (nir) 107.22




CAT Interstellar (UE4) - works

Dead Island Definitive - works

Dead Island Riptide Definitive - works

Deus Ex: Mankind Divided - works, nonir low 8.3 avg 24.2 high 37.6; nir 
low 1 avg 22.8 high 35.8
but shader generation crashes two times: once around half the loader bar 
with complete system freeze and then again around the end but only 
exiting the applicationand this is reproducible by deleting the shader 
cache


Mad Max[vulcan beta] - works
benchmark 1
nonir 43/45/47
nir 10/46/50
benchmark 2
nonir 14/37/41
nir 24/36/40
benchmark 3
nonir 8/43/61
nir 5/41/61
benchmark 4
nonir 9/49/78
nir 4/47/74

Tomb Raider - TressFX doesn't work: hair flickering and is riddled with 
small green block artifacts, smoothing is missing; speed is the same 
28.6 ish


Hitman GO (Unity) - works

Unity of Command (PyGame, SDL) - works

Talos Principle Benchmark nir 64.7 nonir 67


I have more games if there are any usual suspects that are likely to 
cause problems.


Cheers,
Benedikt

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

[Mesa-dev] [PATCH v2 2/2] spirv: fix OpUConvert when the source is signed

[Samuel Iglesias Gonsálvez]

From: Iago Toral Quiroga 

In this case we don't want to do sign-extension, since the value is
interpreted as unsigned. If we want sign-extension, OpSConvert should
be used.
---
 src/compiler/spirv/vtn_alu.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index a5cefc35773..0b279fe7e54 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -349,7 +349,6 @@ vtn_nir_alu_op_for_spirv_opcode(struct vtn_builder *b,
 
/* Conversions: */
case SpvOpQuantizeToF16: return nir_op_fquantize2f16;
-   case SpvOpUConvert:
case SpvOpConvertFToU:
case SpvOpConvertFToS:
case SpvOpConvertSToF:
@@ -374,6 +373,25 @@ vtn_nir_alu_op_for_spirv_opcode(struct vtn_builder *b,
   }
   return nir_type_conversion_op(src, dst, nir_rounding_mode_undef);
}
+
+   case SpvOpUConvert: {
+  nir_alu_type src_base = (nir_alu_type) nir_alu_type_get_base_type(src);
+  if (src_base == nir_type_int) {
+ /* SPIR-V expects to interpret the signed value as unsigned and
+  * not sign extend. Return the opcode accordingly.
+  */
+ unsigned dst_bit_size = nir_alu_type_get_type_size(dst);
+ switch (dst_bit_size) {
+ case 16:   return nir_op_u2u16;
+ case 32:   return nir_op_u2u32;
+ case 64:   return nir_op_u2u64;
+ default:
+vtn_fail("Invalid nir alu bit size");
+ }
+  }
+  return nir_type_conversion_op(src, dst, nir_rounding_mode_undef);
+   }
+
/* Derivatives: */
case SpvOpDPdx: return nir_op_fddx;
case SpvOpDPdy: return nir_op_fddy;
-- 
2.14.1

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

[Mesa-dev] [PATCH v2 1/2] spirv: fix OpSConvert when the source is unsigned

[Samuel Iglesias Gonsálvez]

OpSConvert interprets the MSB of the unsigned value as the sign bit and
extends it to the new type. If we want to preserve the value, we need
to use OpUConvert opcode.

v2:
- No need to check dst type.
- Fix typo in comment.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/compiler/spirv/vtn_alu.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index d0c9e316935..a5cefc35773 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -354,10 +354,26 @@ vtn_nir_alu_op_for_spirv_opcode(struct vtn_builder *b,
case SpvOpConvertFToS:
case SpvOpConvertSToF:
case SpvOpConvertUToF:
-   case SpvOpSConvert:
case SpvOpFConvert:
   return nir_type_conversion_op(src, dst, nir_rounding_mode_undef);
 
+   case SpvOpSConvert: {
+  nir_alu_type src_base = (nir_alu_type) nir_alu_type_get_base_type(src);
+  if (src_base == nir_type_uint) {
+ /* SPIR-V expects to interpret the unsigned value as signed and
+  * do sign extend. Return the opcode accordingly.
+  */
+ unsigned dst_bit_size = nir_alu_type_get_type_size(dst);
+ switch (dst_bit_size) {
+ case 16:   return nir_op_i2i16;
+ case 32:   return nir_op_i2i32;
+ case 64:   return nir_op_i2i64;
+ default:
+vtn_fail("Invalid nir alu bit size");
+ }
+  }
+  return nir_type_conversion_op(src, dst, nir_rounding_mode_undef);
+   }
/* Derivatives: */
case SpvOpDPdx: return nir_op_fddx;
case SpvOpDPdy: return nir_op_fddy;
-- 
2.14.1

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

[Mesa-dev] [Bug 93965] Please backport OSMesaCreateContextAttribs to 11.1

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

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

[Mesa-dev] [Bug 36488] please update Mesa Home Page : http://mesa3d.sourceforge.net with better gallium info

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

--- Comment #2 from Timothy Arceri  ---
This report is old and out of date. The current web page is in a pretty good
state IMO. Closing.

-- 
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] Revert "nir: bump loop unroll limit to 96."

[Dave Airlie]

On 6 March 2018 at 13:59, Timothy Arceri  wrote:
> On 06/03/18 14:48, Timothy Arceri wrote:
>>
>> This reverts commit 2d36efdb7f18f061c519dbb93f6058bf161aad33.
>>
>> This raised limit turns out to harmful for more complex shaders,
>> it causes excessive spilling in some Bioshock Infinite shaders.
>
>
> While not as bad as Bioshock (which went from 0 -> 268 in three shaders)
> Dirt Showdown VGPR spilling went from 40 -> 67 and 0 -> 17 in a couple of
> shaders also as a result of loop unrolling.

Okay!

Reviewed-by: Dave Airlie 

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

[Mesa-dev] [Bug 103945] FireFox Error Abort with flash objects

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Timothy Arceri  ---
No further details were provided. Closing.

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

[Mesa-dev] [Bug 50317] [r600g+llvm] Piglit test failures: LLVM ERROR: Cannot select: target intrinsic %llvm.AMDGPU.sin

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #18 from Timothy Arceri  ---
r600 + llvm is never going to be completed. Closing as won't fix.

-- 
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 103126] glthread doesn't offload anything in Witcher 2

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #3 from Timothy Arceri  ---
I believe the dispatch code uses asm, disabling it probably falls back to a
dispatch path that doesn't contain glthread. Either that or something else
glthread related relies on asm being enabled. Either way this doesn't seem like
a bug. Closing.

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

[Mesa-dev] [Bug 96550] 12.0.0-rc3: mesa_dri_drivers.so linking fails with: relocation R_X86_64_32S against `V4F_COUNT' can not be used when making a shared object

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Timothy Arceri  ---
The using the link time optimisation flag is not an officially supported way to
build mesa.

-- 
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 92293] A compilation error happen when update mesa from 10.6.7 to 11.0.2

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

-- 
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 35560] libOSMesa.so now (since 7.2 perhaps) contains the GL API preventing creating one executable with interchangeable libGL.so files

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

-- 
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 35200] Mesa 7.6 implementation error: bad datatype in interpolate_int_colors

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #8 from Timothy Arceri  ---
If someone wants a software renderer the should use llvmpipe over swrast these
days. Closing as won't fix (assuming it wasn't fixed at some stage over the
years).

-- 
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 28017] Compiz segfaults, backtrace log and patch included

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #4 from Timothy Arceri  ---
The current mesa code looks to have changed and probably avoids this issue. 

Closing.

-- 
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 105285] Mesa-utils -8.4 - glxinfo report has a blank value in GL_NUM_SHADING_LANGUAGE_VERSIONS subsection and also the aligniment below 4.3 seems not correct

[bugzilla-daemon]

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

--- Comment #7 from Arun Sivaraman  ---
Created attachment 137810
  --> https://bugs.freedesktop.org/attachment.cgi?id=137810=edit
GTX850m_glxinfo-l

-- 
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 105285] Mesa-utils -8.4 - glxinfo report has a blank value in GL_NUM_SHADING_LANGUAGE_VERSIONS subsection and also the aligniment below 4.3 seems not correct

[bugzilla-daemon]

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

--- Comment #6 from Arun Sivaraman  ---
Thanks for the reply, well I have developed a front-end application to view
glxinfo, vulkaninfo and clinfo reports, and i was trying to include both
Compat. profile and Core profile limits to the report. I will attach my glxinfo
-l report for my GTX 850m.

Here is the front-end application
https://github.com/arunsivaramanneo/GPU-Viewer, well Code is a mess and i am
not a programmer but somehow it works.

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

Re: [Mesa-dev] [PATCH] Revert "nir: bump loop unroll limit to 96."

[Timothy Arceri]

On 06/03/18 14:48, Timothy Arceri wrote:

This reverts commit 2d36efdb7f18f061c519dbb93f6058bf161aad33.

This raised limit turns out to harmful for more complex shaders,
it causes excessive spilling in some Bioshock Infinite shaders.


While not as bad as Bioshock (which went from 0 -> 268 in three shaders) 
Dirt Showdown VGPR spilling went from 40 -> 67 and 0 -> 17 in a couple 
of shaders also as a result of loop unrolling.





The fps for the ssao demo on radv remains unchanged when reverting
this.

Cc: Dave Airlie 
---
  src/compiler/nir/nir_opt_loop_unroll.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/compiler/nir/nir_opt_loop_unroll.c 
b/src/compiler/nir/nir_opt_loop_unroll.c
index dae5bfc902..79d04f978b 100644
--- a/src/compiler/nir/nir_opt_loop_unroll.c
+++ b/src/compiler/nir/nir_opt_loop_unroll.c
@@ -33,10 +33,8 @@
   * to give about the same results. Around 5 instructions per node.  But some
   * loops that would unroll with GLSL IR fail to unroll if we set this to 25 so
   * we set it to 26.
- * This was bumped to 96 because it unrolled more loops with a positive
- * effect (vulkan ssao demo).
   */
-#define LOOP_UNROLL_LIMIT 96
+#define LOOP_UNROLL_LIMIT 26
  
  /* Prepare this loop for unrolling by first converting to lcssa and then

   * converting the phis from the loops first block and the block that follows


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

[Mesa-dev] [PATCH] Revert "nir: bump loop unroll limit to 96."

[Timothy Arceri]

This reverts commit 2d36efdb7f18f061c519dbb93f6058bf161aad33.

This raised limit turns out to harmful for more complex shaders,
it causes excessive spilling in some Bioshock Infinite shaders.

The fps for the ssao demo on radv remains unchanged when reverting
this.

Cc: Dave Airlie 
---
 src/compiler/nir/nir_opt_loop_unroll.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/compiler/nir/nir_opt_loop_unroll.c 
b/src/compiler/nir/nir_opt_loop_unroll.c
index dae5bfc902..79d04f978b 100644
--- a/src/compiler/nir/nir_opt_loop_unroll.c
+++ b/src/compiler/nir/nir_opt_loop_unroll.c
@@ -33,10 +33,8 @@
  * to give about the same results. Around 5 instructions per node.  But some
  * loops that would unroll with GLSL IR fail to unroll if we set this to 25 so
  * we set it to 26.
- * This was bumped to 96 because it unrolled more loops with a positive
- * effect (vulkan ssao demo).
  */
-#define LOOP_UNROLL_LIMIT 96
+#define LOOP_UNROLL_LIMIT 26
 
 /* Prepare this loop for unrolling by first converting to lcssa and then
  * converting the phis from the loops first block and the block that follows
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH v2 2/5] i965/miptree: Use cpu tiling/detiling when mapping

[Nanley Chery]

On Mon, Mar 05, 2018 at 02:40:25PM -0800, Nanley Chery wrote:
> On Thu, Jan 25, 2018 at 08:23:45AM -0800, Scott D Phillips wrote:
> > Rename the (un)map_gtt functions to (un)map_map (map by
> > returning a map) and add new functions (un)map_tiled_memcpy that
> > return a shadow buffer populated with the intel_tiled_memcpy
> > functions.
> > 
> > v2: Compute extents properly in the x|y-rounded-down case (Chris Wilson)
> > ---
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 95 
> > ---
> >  1 file changed, 86 insertions(+), 9 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > index c480eade93..85297cb0c1 100644
> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > @@ -31,6 +31,7 @@
> >  #include "intel_image.h"
> >  #include "intel_mipmap_tree.h"
> >  #include "intel_tex.h"
> > +#include "intel_tiled_memcpy.h"
> >  #include "intel_blit.h"
> >  #include "intel_fbo.h"
> >  
> > @@ -3028,10 +3029,10 @@ intel_miptree_unmap_raw(struct intel_mipmap_tree 
> > *mt)
> >  }
> >  
> >  static void
> > -intel_miptree_map_gtt(struct brw_context *brw,
> > - struct intel_mipmap_tree *mt,
> > - struct intel_miptree_map *map,
> > - unsigned int level, unsigned int slice)
> > +intel_miptree_map_map(struct brw_context *brw,
> > +  struct intel_mipmap_tree *mt,
> > +  struct intel_miptree_map *map,
> > +  unsigned int level, unsigned int slice)
> >  {
> > unsigned int bw, bh;
> > void *base;
> > @@ -3049,7 +3050,7 @@ intel_miptree_map_gtt(struct brw_context *brw,
> > y /= bh;
> > x /= bw;
> >  
> > -   base = intel_miptree_map_raw(brw, mt, map->mode);
> > +   base = intel_miptree_map_raw(brw, mt, map->mode | MAP_RAW);
> >  
> > if (base == NULL)
> >map->ptr = NULL;
> > @@ -3075,11 +3076,80 @@ intel_miptree_map_gtt(struct brw_context *brw,
> >  }
> >  
> >  static void
> > -intel_miptree_unmap_gtt(struct intel_mipmap_tree *mt)
> > +intel_miptree_unmap_map(struct intel_mipmap_tree *mt)
> >  {
> > intel_miptree_unmap_raw(mt);
> >  }
> >  
> > +/* Compute extent parameters for use with tiled_memcpy functions.
> > + * xs are in units of bytes and ys are in units of strides. */
> > +static inline void
> > +tile_extents(struct intel_mipmap_tree *mt, struct intel_miptree_map *map,
> > + unsigned int level, unsigned int slice, unsigned int *x1,
> > + unsigned int *x2, unsigned int *y1, unsigned int *y2)
> > +{
> > +   unsigned int block_width, block_height, block_bytes;
> > +   unsigned int x0_el, y0_el;
> > +
> > +   _mesa_get_format_block_size(mt->format, _width, _height);
> > +   block_bytes = _mesa_get_format_bytes(mt->format);
> > +
> > +   assert(map->x % block_width == 0);
> > +   assert(map->y % block_height == 0);
> > +
> > +   intel_miptree_get_image_offset(mt, level, slice, _el, _el);
> > +   *x1 = (map->x / block_width + x0_el) * block_bytes;
> > +   *y1 = map->y / block_height + y0_el;
> > +   *x2 = (DIV_ROUND_UP(map->x + map->w, block_width) + x0_el) * 
> > block_bytes;
> > +   *y2 = DIV_ROUND_UP(map->y + map->h, block_height) + y0_el;
> > +}
> > +
> > +static void
> > +intel_miptree_map_tiled_memcpy(struct brw_context *brw,
> > +   struct intel_mipmap_tree *mt,
> > +   struct intel_miptree_map *map,
> > +   unsigned int level, unsigned int slice)
> > +{
> > +   unsigned int x1, x2, y1, y2;
> > +   tile_extents(mt, map, level, slice, , , , );
> > +   map->stride = _mesa_format_row_stride(mt->format, map->w);
> > +   map->buffer = map->ptr = malloc(map->stride * (y2 - y1));
> > +
> > +   if (!(map->mode & GL_MAP_INVALIDATE_RANGE_BIT)) {
> > +  char *src = intel_miptree_map_raw(brw, mt, map->mode | MAP_RAW);
> > +  src += mt->offset;
> > +
> > +  tiled_to_linear(x1, x2, y1, y2, map->ptr, src, map->stride,
> > +  mt->surf.row_pitch, brw->has_swizzling, 
> > mt->surf.tiling,
> > +  memcpy);
> > +
> 
> Do we have a mechanism to test if a miptree level and slice are valid?
> It doesn't seem like the mode have the GL_MAP_INVALIDATE_RANGE_BIT set
> in all the cases we care about.
> 
> For example, it looks like we'll do an extra memcpy operation when the
> user specifies an image for the first time (using glTexImage2D for
> example).
> 
> It looks like there are unknown perf implications with this path. How do
> you feel about putting this behind a debug flag?
> 

I just talked about this with Jason and it seems like the lack of
GL_MAP_INVALIDATE_RANGE_BIT being set may be a bug in core mesa. Also
from that discussion, it seems like we want to move away from gtt
mapping in release builds for more than just performance reasons, so
never mind the bit about the 

Re: [Mesa-dev] [PATCH 11/22 v2] nir: Recognize some more open-coded fmin / fmax

[Jason Ekstrand]

On Mon, Mar 5, 2018 at 2:25 PM, Ian Romanick  wrote:

> On 03/05/2018 02:07 PM, Jason Ekstrand wrote:
> > On Mon, Mar 5, 2018 at 11:11 AM, Ian Romanick  > > wrote:
> >
> > On 02/28/2018 12:48 PM, Jason Ekstrand wrote:
> > > Rb
> >
> > For both or just this one?
> >
> >
> > If you put the ~ on there, both.
>
> I'm not sure what you mean.  That's all the other patch ([PATCH 11.1/22]
> nir: Mark bcsel-to-fmin (or fmax) transformations as inexact) does.
>

Sorry, I got confused.  Yes, RB to both.


> > > On Wed, Feb 28, 2018 at 12:18 PM, Ian Romanick <
> i...@freedesktop.org 
> > > >> wrote:
> > >
> > > From: Ian Romanick 
> > >  > >>
> > >
> > > This transformation is inexact because section 4.7.1 (Range and
> > > Precision) says:
> > >
> > > Operations and built-in functions that operate on a NaN
> > are not
> > > required to return a NaN as the result.
> > >
> > > The fmin or fmax might not return NaN in cases where the
> original
> > > expression would be required to return NaN.
> > >
> > > v2: Reorder operands and mark as inexact.  The latter
> suggested by
> > > Jason.
> > >
> > > shader-db results:
> > >
> > > Haswell, Broadwell, and Skylake had similar results. (Skylake
> > shown)
> > > total instructions in shared programs: 14514817 -> 14514808
> > (<.01%)
> > > instructions in affected programs: 229 -> 220 (-3.93%)
> > > helped: 3
> > > HURT: 0
> > > helped stats (abs) min: 1 max: 4 x̄: 3.00 x̃: 4
> > > helped stats (rel) min: 2.86% max: 4.12% x̄: 3.70% x̃: 4.12%
> > >
> > > total cycles in shared programs: 533145211 -> 533144939 (<.01%)
> > > cycles in affected programs: 37268 -> 36996 (-0.73%)
> > > helped: 8
> > > HURT: 0
> > > helped stats (abs) min: 2 max: 134 x̄: 34.00 x̃: 2
> > > helped stats (rel) min: 0.02% max: 14.22% x̄: 3.53% x̃: 0.05%
> > >
> > > Sandy Bridge and Ivy Bridge had similar results. (Ivy Bridge
> > shown)
> > > total cycles in shared programs: 257618409 -> 257618403 (<.01%)
> > > cycles in affected programs: 12582 -> 12576 (-0.05%)
> > > helped: 3
> > > HURT: 0
> > > helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2
> > > helped stats (rel) min: 0.05% max: 0.05% x̄: 0.05% x̃: 0.05%
> > >
> > > No changes on Iron Lake or GM45.
> > >
> > > Signed-off-by: Ian Romanick  > 
> > >  > >>
> > > ---
> > >  src/compiler/nir/nir_opt_algebraic.py | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/src/compiler/nir/nir_opt_algebraic.py
> > > b/src/compiler/nir/nir_opt_algebraic.py
> > > index d40d59b..17f4d9c 100644
> > > --- a/src/compiler/nir/nir_opt_algebraic.py
> > > +++ b/src/compiler/nir/nir_opt_algebraic.py
> > > @@ -170,6 +170,8 @@ optimizations = [
> > > (('fge', ('fneg', ('fabs', a)), 0.0), ('feq', a, 0.0)),
> > > (('bcsel', ('flt', b, a), b, a), ('fmin', a, b)),
> > > (('bcsel', ('flt', a, b), b, a), ('fmax', a, b)),
> > > +   (('~bcsel', ('fge', a, b), b, a), ('fmin', a, b)),
> > > +   (('~bcsel', ('fge', b, a), b, a), ('fmax', a, b)),
> > > (('bcsel', ('inot', a), b, c), ('bcsel', a, c, b)),
> > > (('bcsel', a, ('bcsel', a, b, c), d), ('bcsel', a, b, d)),
> > > (('bcsel', a, True, 'b@bool'), ('ior', a, b)),
> > > --
> > > 2.9.5
> > >
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > 
> >  > >
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> > >  > >
> > >
> > >
> >
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Few issues with Meson

[Mike Lothian]

Hi

I've been trying to get a Gentoo ebuild ready for meson

I've had to fudge the llvm-config for cross compiling a 32bit mesa on
a 64bit machine

I notice that -Dvulkan-drivers= doesn't accept intel,radeon like
autotools used to, it also seems as long as one value is correct the
other is ignored

Also -Dva-libs-path= doesn't play well with absolute paths, or rather
install_megadrivers.py is doing something strange - normally gentoo
installs everything to a temporary image path then puts those files
into the live system. It seems install_megadrivers.py doesn't do this
and installs directly to the live system - I worked around it by
dropping the /usr

The inital ebuild is in the FireBurn overlay
(https://github.com/FireBurn/Overlay/blob/master/media-libs/mesa/mesa-.ebuild)

Regards

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

Re: [Mesa-dev] [PATCH 2/4] i965: perf: query topology

[Rafael Antognolli]

On Thu, Feb 22, 2018 at 05:24:38PM +, Lionel Landwerlin wrote:
> With the introduction of asymmetric slices in CNL, we cannot rely on
> the previous SUBSLICE_MASK getparam to tell userspace what subslices
> are available.
> 
> We introduce a new uAPI in the kernel driver to report exactly what
> part of the GPU are fused and require this to be available on Gen10+.
> 
> Prior generations can continue to rely on GETPARAM on older kernels.
> 
> This patch is quite a lot of code because we have to support lots of
> different kernel versions, ranging from not providing any information
> (for Haswell on 4.13 through 4.17), to being able to query through
> GETPARAM (for gen8/9 on 4.13 through 4.17), to finally requiring 4.17
> for Gen10+.

I don't think it's that much code. It's reasonable given how many
interfaces we have to query such data.

> This change stores topology information in a unified way on
> brw_context.topology from the various kernel APIs. And then generates
> the appropriate values for the equations from that unified topology.
> 
> Signed-off-by: Lionel Landwerlin 
> ---
>  src/mesa/drivers/dri/i965/brw_context.h   |  14 ++
>  src/mesa/drivers/dri/i965/brw_performance_query.c | 267 
> --
>  2 files changed, 208 insertions(+), 73 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 050b656e3da..69bf7530fbc 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -1160,6 +1160,20 @@ struct brw_context
>bool supported;
> } predicate;
>  
> +   struct {
> +  uint8_t slice_mask[4];
> +  uint8_t subslice_mask[100];
> +  uint8_t eu_mask[100];
> +
> +  uint16_t max_slices;
> +  uint16_t max_subslices;
> +  uint16_t max_eus_per_subslice;
> +
> +  uint16_t subslice_slice_stride;
> +  uint16_t eu_slice_stride;
> +  uint16_t eu_subslice_stride;
> +   } topology;
> +

I wonder if such information shouldn't be stored in gen_device_info. But
it seems the rest of the OA code seems to be tied to i965 anyways, so I
guess this should be fine.

In any case, series is:

Acked-by: Rafael Antognolli 

> struct {
>/* Variables referenced in the XML meta data for OA performance
> * counters, e.g in the normalization equations.
> diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c 
> b/src/mesa/drivers/dri/i965/brw_performance_query.c
> index c0bb4442bec..10f519a757f 100644
> --- a/src/mesa/drivers/dri/i965/brw_performance_query.c
> +++ b/src/mesa/drivers/dri/i965/brw_performance_query.c
> @@ -1888,6 +1888,192 @@ init_oa_configs(struct brw_context *brw, const char 
> *sysfs_dev_dir)
> }
>  }
>  
> +static bool
> +query_topology(struct brw_context *brw)
> +{
> +   __DRIscreen *screen = brw->screen->driScrnPriv;
> +   struct drm_i915_query_item item = {
> +  .query_id = DRM_I915_QUERY_TOPOLOGY_INFO,
> +   };
> +   struct drm_i915_query query = {
> +  .num_items = 1,
> +  .items_ptr = (uintptr_t) ,
> +   };
> +
> +   return false;
> +
> +   if (drmIoctl(screen->fd, DRM_IOCTL_I915_QUERY, ))
> +  return false;
> +
> +   struct drm_i915_query_topology_info *topo_info =
> +  (struct drm_i915_query_topology_info *) calloc(1, item.length);
> +   item.data_ptr = (uintptr_t) topo_info;
> +
> +   if (drmIoctl(screen->fd, DRM_IOCTL_I915_QUERY, ))
> +  return false;
> +
> +   brw->topology.max_slices = topo_info->max_slices;
> +   brw->topology.max_subslices = topo_info->max_subslices;
> +   brw->topology.max_eus_per_subslice = topo_info->max_eus_per_subslice;
> +
> +   brw->topology.subslice_slice_stride =
> +  DIV_ROUND_UP(brw->topology.max_subslices, 8);
> +   brw->topology.eu_subslice_stride =
> +  DIV_ROUND_UP(brw->topology.max_eus_per_subslice, 8);
> +   brw->topology.eu_slice_stride = brw->topology.max_subslices *
> +  brw->topology.eu_subslice_stride;
> +
> +   assert(DIV_ROUND_UP(topo_info->max_slices, 8) <=
> +  sizeof(brw->topology.slice_mask));
> +   memcpy(brw->topology.slice_mask, topo_info->data,
> +  DIV_ROUND_UP(topo_info->max_slices, 8));
> +
> +   assert(DIV_ROUND_UP(topo_info->max_slices * topo_info->max_subslices, 8) 
> <=
> +  sizeof(brw->topology.subslice_mask));
> +   memcpy(brw->topology.subslice_mask,
> +  _info->data[topo_info->subslice_offset],
> +  topo_info->max_slices * topo_info->subslice_stride);
> +
> +   assert(DIV_ROUND_UP(topo_info->max_slices * topo_info->max_subslices *
> +   topo_info->max_eus_per_subslice, 8) <=
> +  sizeof(brw->topology.eu_mask));
> +   memcpy(brw->topology.eu_mask,
> +  _info->data[topo_info->eu_offset],
> +  topo_info->max_slices * topo_info->max_subslices * 
> topo_info->eu_stride);
> +
> +   free(topo_info);
> +
> +   return true;
> +}
> +
> +static bool
> 

[Mesa-dev] [PATCH] intel: Add missing includes for building on Android

[Clayton Craft]

This adds a missing library to the i965/Android.mk file, and updates
intel/Android.mk to include the new library. Without this, mesa does not
build on Android.

Fixes: 272bef0601a "intel: Split gen_device_info out into
libintel_dev"
---
 src/intel/Android.mk | 1 +
 src/mesa/drivers/dri/i965/Android.mk | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/intel/Android.mk b/src/intel/Android.mk
index db6c770f35..380473d0ac 100644
--- a/src/intel/Android.mk
+++ b/src/intel/Android.mk
@@ -28,6 +28,7 @@ include $(LOCAL_PATH)/Makefile.sources
 include $(LOCAL_PATH)/Android.blorp.mk
 include $(LOCAL_PATH)/Android.common.mk
 include $(LOCAL_PATH)/Android.compiler.mk
+include $(LOCAL_PATH)/Android.dev.mk
 include $(LOCAL_PATH)/Android.genxml.mk
 include $(LOCAL_PATH)/Android.isl.mk
 include $(LOCAL_PATH)/Android.vulkan.mk
diff --git a/src/mesa/drivers/dri/i965/Android.mk 
b/src/mesa/drivers/dri/i965/Android.mk
index 83959cbf6c..964313e6c5 100644
--- a/src/mesa/drivers/dri/i965/Android.mk
+++ b/src/mesa/drivers/dri/i965/Android.mk
@@ -289,6 +289,7 @@ LOCAL_SRC_FILES := \
 LOCAL_WHOLE_STATIC_LIBRARIES := \
$(MESA_DRI_WHOLE_STATIC_LIBRARIES) \
$(I965_PERGEN_LIBS) \
+   libmesa_intel_dev \
libmesa_intel_common \
libmesa_isl \
libmesa_blorp \
-- 
2.16.2

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

[Mesa-dev] [Bug 105353] Textures flickering in Civilizations VI

[bugzilla-daemon]

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

Bug ID: 105353
   Summary: Textures flickering in Civilizations VI
   Product: Mesa
   Version: 17.3
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: mato...@arcor.de
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 137806
  --> https://bugs.freedesktop.org/attachment.cgi?id=137806=edit
Civ 6 Bug Video

When i start a game in Civ 6 the map textures flicker/it looks like junks of it
get rendered to low in the 3d world every 10th frame or so. In the unexplored
area or the water i get flickering black and yellow triangles. I captured it in
a video.

My system: GPU: RX Vega 56, Software: Linux 4.15, amdgpu 1.4.0, Mesa 17.3.6

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

Re: [Mesa-dev] [PATCH 21/22] i965/vec4: Allow CSE on subset VF constant loads

[Kenneth Graunke]

On Friday, February 23, 2018 3:56:06 PM PST Ian Romanick wrote:
> From: Ian Romanick 
> 
> No changes on other platforms.
> 
> Haswell, Ivy Bridge, and Sandy Bridge had similar results. (Haswell shown)
> total instructions in shared programs: 13059891 -> 13059884 (<.01%)
> instructions in affected programs: 431 -> 424 (-1.62%)
> helped: 7
> HURT: 0
> helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
> helped stats (rel) min: 1.19% max: 5.26% x̄: 2.05% x̃: 1.49%
> 95% mean confidence interval for instructions value: -1.00 -1.00
> 95% mean confidence interval for instructions %-change: -3.39% -0.71%
> Instructions are helped.
> 
> total cycles in shared programs: 409260032 -> 409260018 (<.01%)
> cycles in affected programs: 4228 -> 4214 (-0.33%)
> helped: 7
> HURT: 0
> helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2
> helped stats (rel) min: 0.28% max: 2.04% x̄: 0.54% x̃: 0.28%
> 95% mean confidence interval for cycles value: -2.00 -2.00
> 95% mean confidence interval for cycles %-change: -1.15% 0.07%
> 
> Inconclusive result (%-change mean confidence interval includes 0).
> 
> Signed-off-by: Ian Romanick 
> ---
>  src/intel/compiler/brw_vec4_cse.cpp | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/src/intel/compiler/brw_vec4_cse.cpp 
> b/src/intel/compiler/brw_vec4_cse.cpp
> index aa2f127..3302939 100644
> --- a/src/intel/compiler/brw_vec4_cse.cpp
> +++ b/src/intel/compiler/brw_vec4_cse.cpp
> @@ -104,6 +104,27 @@ operands_match(const vec4_instruction *a, const 
> vec4_instruction *b)
>return xs[0].equals(ys[0]) &&
>   ((xs[1].equals(ys[1]) && xs[2].equals(ys[2])) ||
>(xs[2].equals(ys[1]) && xs[1].equals(ys[2])));
> +   } else if (a->opcode == BRW_OPCODE_MOV &&
> +  xs[0].file == IMM &&
> +  xs[0].type == BRW_REGISTER_TYPE_VF) {
> +  src_reg tmp_x = xs[0];
> +  src_reg tmp_y = ys[0];
> +
> +  /* Smash out the values that are not part of the writemask.  Otherwise
> +   * the equals and negative_equals operators will fail due to mismatches
> +   * in unused components.
> +   */
> +  static const uint32_t mask[] = {
> + 0x, 0x00ff, 0xff00, 0x,
> + 0x00ff, 0x00ff00ff, 0x0000, 0x00ff,
> + 0xff00, 0xffff, 0xff00ff00, 0xff00,
> + 0x, 0x00ff, 0xff00, 0x
> +  };

This looks a bit crazy at first glance...it isn't though, it's just a
mapping from WRITEMASK_* to the proper byte masks.  But I think it might
be clearer to write it with an explicit formula:

unsigned ab_writemask = a->dst.writemask & b->dst.writemask;
uint32_t mask = ((ab_writemask & WRITEMASK_X) ? 0x00ff : 0) |
((ab_writemask & WRITEMASK_Y) ? 0xff00 : 0) |
((ab_writemask & WRITEMASK_Z) ? 0x00ff : 0) |
((ab_writemask & WRITEMASK_W) ? 0xff00 : 0);
tmp_x.ud &= mask;
tmp_y.ud &= mask;

This makes it pretty obvious what's going on.

Either way (though I prefer mine),
Reviewed-by: Kenneth Graunke 

> +
> +  tmp_x.ud &= mask[a->dst.writemask & b->dst.writemask];
> +  tmp_y.ud &= mask[a->dst.writemask & b->dst.writemask];
> +
> +  return tmp_x.equals(tmp_y);
> } else if (!a->is_commutative()) {
>return xs[0].equals(ys[0]) && xs[1].equals(ys[1]) && 
> xs[2].equals(ys[2]);
> } else {
> 



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

Re: [Mesa-dev] [PATCH 18/22] i965/fs: Add infrastructure for generating CSEL instructions.

[Matt Turner]

On Fri, Feb 23, 2018 at 3:56 PM, Ian Romanick  wrote:
> From: Kenneth Graunke 
>
> v2 (idr): Don't allow CSEL with a non-float src2.
>
> v3 (idr): Add CSEL to fs_inst::flags_written.  Suggested by Matt.

brw_disassemble_inst
fs_visitor::dump_instruction
vec4_instruction:writes_flag
vec4_visitor::dump_instruction

should all be updated similarly.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 95323] GL33-CTS.CommonBugs.CommonBug_ReservedNames fails

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|FIXED   |WORKSFORME

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

[Mesa-dev] [Bug 95323] GL33-CTS.CommonBugs.CommonBug_ReservedNames fails

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #2 from Timothy Arceri  ---
The test is now called KHR-GL33.CommonBugs.CommonBug_ReservedNames and seems to
pass with git master. This was likely fixed a while ago. Closing bug.

-- 
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 17/22] nir: Narrow some dot product operations

[Matt Turner]

On Fri, Feb 23, 2018 at 3:56 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> On vector platforms, this helps elide some constant loads.
>
> No changes on Broadwell or Skylake.
>
> Haswell
> total instructions in shared programs: 13093793 -> 13060163 (-0.26%)
> instructions in affected programs: 1277532 -> 1243902 (-2.63%)
> helped: 13216
> HURT: 95

What's going on in the hurt shaders?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103062] Error starting game FS17

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #12 from Timothy Arceri  ---
The user seems to be trying to run Farming Simulator 17 via wine. I believe
Wine uses compat profile by default and so the game fails to start due to mesas
limited support for compat. Apparently Wine staging defaults to core for Mesa
drivers.

Either way this doesn't seem like there is any real bug with mesa here, just
missing support for compat which is well known and doesn't require us to track
bugs like this.

Closing.

-- 
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 18/22] i965/fs: Add infrastructure for generating CSEL instructions.

[Matt Turner]

On Fri, Feb 23, 2018 at 3:56 PM, Ian Romanick  wrote:
> From: Kenneth Graunke 
>
> v2 (idr): Don't allow CSEL with a non-float src2.
>
> v3 (idr): Add CSEL to fs_inst::flags_written.  Suggested by Matt.
>
> Signed-off-by: Kenneth Graunke 
> Signed-off-by: Ian Romanick 
> ---
>  src/intel/compiler/brw_eu.h |  1 +
>  src/intel/compiler/brw_eu_emit.c|  1 +
>  src/intel/compiler/brw_fs.cpp   |  1 +
>  src/intel/compiler/brw_fs_builder.h | 22 +-
>  src/intel/compiler/brw_fs_generator.cpp |  5 +
>  5 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
> index 2d0f56f..3201624 100644
> --- a/src/intel/compiler/brw_eu.h
> +++ b/src/intel/compiler/brw_eu.h
> @@ -171,6 +171,7 @@ ALU2(SHR)
>  ALU2(SHL)
>  ALU1(DIM)
>  ALU2(ASR)
> +ALU3(CSEL)
>  ALU1(F32TO16)
>  ALU1(F16TO32)
>  ALU2(ADD)
> diff --git a/src/intel/compiler/brw_eu_emit.c 
> b/src/intel/compiler/brw_eu_emit.c
> index c25d8d6..305a759 100644
> --- a/src/intel/compiler/brw_eu_emit.c
> +++ b/src/intel/compiler/brw_eu_emit.c
> @@ -953,6 +953,7 @@ ALU2(SHR)
>  ALU2(SHL)
>  ALU1(DIM)
>  ALU2(ASR)
> +ALU3(CSEL)
>  ALU1(FRC)
>  ALU1(RNDD)
>  ALU2(MAC)
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index bed632d..accae1b 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -929,6 +929,7 @@ unsigned
>  fs_inst::flags_written() const
>  {
> if ((conditional_mod && (opcode != BRW_OPCODE_SEL &&
> +opcode != BRW_OPCODE_CSEL &&
>  opcode != BRW_OPCODE_IF &&
>  opcode != BRW_OPCODE_WHILE)) ||
> opcode == FS_OPCODE_MOV_DISPATCH_TO_FLAGS) {
> diff --git a/src/intel/compiler/brw_fs_builder.h 
> b/src/intel/compiler/brw_fs_builder.h
> index 87394bc..47eac42 100644
> --- a/src/intel/compiler/brw_fs_builder.h
> +++ b/src/intel/compiler/brw_fs_builder.h
> @@ -458,7 +458,6 @@ namespace brw {
>ALU1(BFREV)
>ALU1(CBIT)
>ALU2(CMPN)
> -  ALU3(CSEL)
>ALU1(DIM)
>ALU2(DP2)
>ALU2(DP3)
> @@ -534,6 +533,27 @@ namespace brw {
>}
>
>/**
> +   * CSEL: dst = src2  0.0f ? src0 : src1
> +   */
> +  instruction *
> +  CSEL(const dst_reg , const src_reg , const src_reg ,
> +   const src_reg , brw_conditional_mod condition) const
> +  {
> + /* CSEL only operates on floats, so we can't do integer =/>
> +  * comparisons.  Zero/non-zero (== and !=) comparisons almost work.
> +  * 0x8000 fails because it is -0.0, and -0.0 == 0.0.
> +  */
> + assert(src2.type == BRW_REGISTER_TYPE_F);
> +
> + return set_condmod(condition,
> +emit(BRW_OPCODE_CSEL,
> + retype(dst, BRW_REGISTER_TYPE_F),
> + retype(src0, BRW_REGISTER_TYPE_F),
> + retype(src1, BRW_REGISTER_TYPE_F),
> + src2));
> +  }
> +
> +  /**
> * Emit a linear interpolation instruction.
> */
>instruction *
> diff --git a/src/intel/compiler/brw_fs_generator.cpp 
> b/src/intel/compiler/brw_fs_generator.cpp
> index cd5be05..9157367 100644
> --- a/src/intel/compiler/brw_fs_generator.cpp
> +++ b/src/intel/compiler/brw_fs_generator.cpp
> @@ -1826,6 +1826,11 @@ fs_generator::generate_code(const cfg_t *cfg, int 
> dispatch_width)
>case BRW_OPCODE_SEL:
>  brw_SEL(p, dst, src[0], src[1]);
>  break;
> +  case BRW_OPCODE_CSEL:
> + brw_set_default_access_mode(p, BRW_ALIGN_16);
> + brw_CSEL(p, dst, src[0], src[1], src[2]);
> + brw_set_default_access_mode(p, BRW_ALIGN_1);
> + break;

This is not okay, actually. Gen11 gets rid of Align16 mode, and even
on Gen10 I've switched all 3-src instructions to use align1 mode. Just
make it work like MAD/LRP/etc and it'll be fine.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] PATH(s) to run Firefox with different Mesa versions

[Germano Massullo]

Good day
I am testing Firefox with various Mesa versions to find which version
started triggering the bug
<>
https://bugs.freedesktop.org/show_bug.cgi?id=104216

I packaged Mesa 18 for Fedora 27
https://copr-be.cloud.fedoraproject.org/results/germano/mesa_18/fedora-27-x86_64/00720216-mesa/
and then I unpacked
mesa-dri-drivers-18.0.0-0.1.rc4.fc27.x86_64.rpm
and runned Firefox with command
LIBGL_DRIVERS_PATH=/home/user/mesa-dri-drivers-18.0.0-0.1.rc4.fc27.x86_64/usr/lib64/dri/
firefox

Question: is LIBGL_DRIVERS_PATH enough to let Firefox use a different
Mesa version?
I am asking this because on the console I am getting

libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swras

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

Re: [Mesa-dev] [PATCH 1/2] radeonsi: move si_nir_load_input_gs() to si_shader.c

[Dave Airlie]

For 1,1.5,2

Reviewed-by: Dave Airlie 

On 1 March 2018 at 14:24, Timothy Arceri  wrote:
> All the tess shader and tgsi equivalents are here and it allows
> use to use llvm_type_is_64bit() in the following patch without
> exposing it externally.
> ---
>  src/gallium/drivers/radeonsi/si_shader.c  | 20 
>  src/gallium/drivers/radeonsi/si_shader_internal.h |  9 -
>  src/gallium/drivers/radeonsi/si_shader_nir.c  | 20 
>  3 files changed, 20 insertions(+), 29 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> b/src/gallium/drivers/radeonsi/si_shader.c
> index 2a50b266f6..f3a37d71a0 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -1682,6 +1682,26 @@ LLVMValueRef si_llvm_load_input_gs(struct 
> ac_shader_abi *abi,
> return LLVMBuildBitCast(ctx->ac.builder, value, type, "");
>  }
>
> +static LLVMValueRef si_nir_load_input_gs(struct ac_shader_abi *abi,
> +unsigned location,
> +unsigned driver_location,
> +unsigned component,
> +unsigned num_components,
> +unsigned vertex_index,
> +unsigned const_index,
> +LLVMTypeRef type)
> +{
> +   struct si_shader_context *ctx = si_shader_context_from_abi(abi);
> +
> +   LLVMValueRef value[8];
> +   for (unsigned i = component; i < num_components + component; i++) {
> +   value[i] = si_llvm_load_input_gs(>abi, driver_location  
> / 4,
> +vertex_index, type, i);
> +   }
> +
> +   return ac_build_varying_gather_values(>ac, value, 
> num_components, component);
> +}
> +
>  static LLVMValueRef fetch_input_gs(
> struct lp_build_tgsi_context *bld_base,
> const struct tgsi_full_src_register *reg,
> diff --git a/src/gallium/drivers/radeonsi/si_shader_internal.h 
> b/src/gallium/drivers/radeonsi/si_shader_internal.h
> index dbe4f2e969..dc73517018 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_internal.h
> +++ b/src/gallium/drivers/radeonsi/si_shader_internal.h
> @@ -337,13 +337,4 @@ void si_llvm_load_input_fs(
>
>  bool si_nir_build_llvm(struct si_shader_context *ctx, struct nir_shader 
> *nir);
>
> -LLVMValueRef si_nir_load_input_gs(struct ac_shader_abi *abi,
> - unsigned location,
> - unsigned driver_location,
> - unsigned component,
> - unsigned num_components,
> - unsigned vertex_index,
> - unsigned const_index,
> - LLVMTypeRef type);
> -
>  #endif
> diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
> b/src/gallium/drivers/radeonsi/si_shader_nir.c
> index 2ca093e237..fc709d8546 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_nir.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
> @@ -771,26 +771,6 @@ static void declare_nir_input_fs(struct 
> si_shader_context *ctx,
> si_llvm_load_input_fs(ctx, input_index, out);
>  }
>
> -LLVMValueRef si_nir_load_input_gs(struct ac_shader_abi *abi,
> - unsigned location,
> - unsigned driver_location,
> - unsigned component,
> - unsigned num_components,
> - unsigned vertex_index,
> - unsigned const_index,
> - LLVMTypeRef type)
> -{
> -   struct si_shader_context *ctx = si_shader_context_from_abi(abi);
> -
> -   LLVMValueRef value[8];
> -   for (unsigned i = component; i < num_components + component; i++) {
> -   value[i] = si_llvm_load_input_gs(>abi, driver_location  
> / 4,
> -vertex_index, type, i);
> -   }
> -
> -   return ac_build_varying_gather_values(>ac, value, 
> num_components, component);
> -}
> -
>  LLVMValueRef
>  si_nir_lookup_interp_param(struct ac_shader_abi *abi,
>enum glsl_interp_mode interp, unsigned location)
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] ac/shader: scan output usage mask for VS and TES

[Dave Airlie]

On 1 March 2018 at 20:54, Samuel Pitoiset  wrote:
> Signed-off-by: Samuel Pitoiset 

For the series:

Reviewed-by: Dave Airlie 

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

Re: [Mesa-dev] [PATCH 1/3] ac: add ac_count_scratch_private_memory()

[Dave Airlie]

On 2 March 2018 at 07:12, Samuel Pitoiset  wrote:
> Imported from RadeonSI.

For the series

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

[Mesa-dev] [Bug 105183] Weird assertion in NIR linker

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #1 from Timothy Arceri  ---
Fixed by:

author  Timothy Arceri 
committer Timothy Arceri 
commit  cdeac00264b14b78bb234aa082bbc499f933

nir: remove old assert

This was originally intended to make sure the remap location
was not -1. However the code has changed alot since then,
the location is now never set to -1 and we also handle
components meaning this old assert has been doing comparisons
with the pointer to the array of component data.

Reviewed-by: Ian Romanick 
Reviewed-by: Iago Toral Quiroga 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105183

-- 
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 libdrm] intel/intel_chipset.h: Sync Cannonlake IDs.

[Rodrigo Vivi]

On Mon, Mar 05, 2018 at 02:51:46PM -0800, Rafael Antognolli wrote:
> This is matching both the kernel and the spec.
> 
> Reviewed-by: Rafael Antognolli .

pushed, thanks

> 
> On Wed, Feb 14, 2018 at 05:42:24PM -0800, Rodrigo Vivi wrote:
> > Let's sync CNL ids with Spec and kernel.
> > 
> > Sync with kernel commit '3f43031b1693 ("drm/i915/cnl:
> > Add Cannonlake PCI IDs for another SKU.")' and
> > commit 'e3890d05b342 ("drm/i915/cnl: Sync PCI ID with Spec.")'
> > 
> > Cc: James Ausmus 
> > Cc: Lucas De Marchi 
> > Cc: Paulo Zanoni 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  intel/intel_chipset.h | 52 
> > +++
> >  1 file changed, 28 insertions(+), 24 deletions(-)
> > 
> > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > index 3818e71e..01d250e8 100644
> > --- a/intel/intel_chipset.h
> > +++ b/intel/intel_chipset.h
> > @@ -241,16 +241,20 @@
> >  #define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7
> >  #define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8
> >  
> > -#define PCI_CHIP_CANNONLAKE_U_GT2_00x5A52
> > -#define PCI_CHIP_CANNONLAKE_U_GT2_10x5A5A
> > -#define PCI_CHIP_CANNONLAKE_U_GT2_20x5A42
> > -#define PCI_CHIP_CANNONLAKE_U_GT2_30x5A4A
> > -#define PCI_CHIP_CANNONLAKE_Y_GT2_00x5A51
> > -#define PCI_CHIP_CANNONLAKE_Y_GT2_10x5A59
> > -#define PCI_CHIP_CANNONLAKE_Y_GT2_20x5A41
> > -#define PCI_CHIP_CANNONLAKE_Y_GT2_30x5A49
> > -#define PCI_CHIP_CANNONLAKE_Y_GT2_40x5A71
> > -#define PCI_CHIP_CANNONLAKE_Y_GT2_50x5A79
> > +#define PCI_CHIP_CANNONLAKE_0  0x5A51
> > +#define PCI_CHIP_CANNONLAKE_1  0x5A59
> > +#define PCI_CHIP_CANNONLAKE_2  0x5A41
> > +#define PCI_CHIP_CANNONLAKE_3  0x5A49
> > +#define PCI_CHIP_CANNONLAKE_4  0x5A52
> > +#define PCI_CHIP_CANNONLAKE_5  0x5A5A
> > +#define PCI_CHIP_CANNONLAKE_6  0x5A42
> > +#define PCI_CHIP_CANNONLAKE_7  0x5A4A
> > +#define PCI_CHIP_CANNONLAKE_8  0x5A50
> > +#define PCI_CHIP_CANNONLAKE_9  0x5A40
> > +#define PCI_CHIP_CANNONLAKE_10 0x5A54
> > +#define PCI_CHIP_CANNONLAKE_11 0x5A5C
> > +#define PCI_CHIP_CANNONLAKE_12 0x5A44
> > +#define PCI_CHIP_CANNONLAKE_13 0x5A4C
> >  
> >  #define IS_MOBILE(devid)   ((devid) == PCI_CHIP_I855_GM || \
> >  (devid) == PCI_CHIP_I915_GM || \
> > @@ -515,20 +519,20 @@
> >  IS_GEMINILAKE(devid) || \
> >  IS_COFFEELAKE(devid))
> >  
> > -#define IS_CNL_Y(devid)((devid) == PCI_CHIP_CANNONLAKE_Y_GT2_0 
> > || \
> > -(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_1 || \
> > -(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_2 || \
> > -(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_3 || \
> > -(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_4 || \
> > -(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_5)
> > -
> > -#define IS_CNL_U(devid)((devid) == PCI_CHIP_CANNONLAKE_U_GT2_0 
> > || \
> > -(devid) == PCI_CHIP_CANNONLAKE_U_GT2_1 || \
> > -(devid) == PCI_CHIP_CANNONLAKE_U_GT2_2 || \
> > -(devid) == PCI_CHIP_CANNONLAKE_U_GT2_3)
> > -
> > -#define IS_CANNONLAKE(devid)   (IS_CNL_U(devid) || \
> > -IS_CNL_Y(devid))
> > +#define IS_CANNONLAKE(devid)   ((devid) == PCI_CHIP_CANNONLAKE_0 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_1 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_2 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_3 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_4 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_5 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_6 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_7 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_8 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_9 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_10 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_11 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_12 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_13)
> >  
> >  #define IS_GEN10(devid)(IS_CANNONLAKE(devid))
> >  
> > -- 
> > 2.13.6
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___

Re: [Mesa-dev] [PATCH libdrm] intel/intel_chipset.h: Sync Cannonlake IDs.

[Rafael Antognolli]

This is matching both the kernel and the spec.

Reviewed-by: Rafael Antognolli .

On Wed, Feb 14, 2018 at 05:42:24PM -0800, Rodrigo Vivi wrote:
> Let's sync CNL ids with Spec and kernel.
> 
> Sync with kernel commit '3f43031b1693 ("drm/i915/cnl:
> Add Cannonlake PCI IDs for another SKU.")' and
> commit 'e3890d05b342 ("drm/i915/cnl: Sync PCI ID with Spec.")'
> 
> Cc: James Ausmus 
> Cc: Lucas De Marchi 
> Cc: Paulo Zanoni 
> Signed-off-by: Rodrigo Vivi 
> ---
>  intel/intel_chipset.h | 52 
> +++
>  1 file changed, 28 insertions(+), 24 deletions(-)
> 
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 3818e71e..01d250e8 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -241,16 +241,20 @@
>  #define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7
>  #define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8
>  
> -#define PCI_CHIP_CANNONLAKE_U_GT2_0  0x5A52
> -#define PCI_CHIP_CANNONLAKE_U_GT2_1  0x5A5A
> -#define PCI_CHIP_CANNONLAKE_U_GT2_2  0x5A42
> -#define PCI_CHIP_CANNONLAKE_U_GT2_3  0x5A4A
> -#define PCI_CHIP_CANNONLAKE_Y_GT2_0  0x5A51
> -#define PCI_CHIP_CANNONLAKE_Y_GT2_1  0x5A59
> -#define PCI_CHIP_CANNONLAKE_Y_GT2_2  0x5A41
> -#define PCI_CHIP_CANNONLAKE_Y_GT2_3  0x5A49
> -#define PCI_CHIP_CANNONLAKE_Y_GT2_4  0x5A71
> -#define PCI_CHIP_CANNONLAKE_Y_GT2_5  0x5A79
> +#define PCI_CHIP_CANNONLAKE_00x5A51
> +#define PCI_CHIP_CANNONLAKE_10x5A59
> +#define PCI_CHIP_CANNONLAKE_20x5A41
> +#define PCI_CHIP_CANNONLAKE_30x5A49
> +#define PCI_CHIP_CANNONLAKE_40x5A52
> +#define PCI_CHIP_CANNONLAKE_50x5A5A
> +#define PCI_CHIP_CANNONLAKE_60x5A42
> +#define PCI_CHIP_CANNONLAKE_70x5A4A
> +#define PCI_CHIP_CANNONLAKE_80x5A50
> +#define PCI_CHIP_CANNONLAKE_90x5A40
> +#define PCI_CHIP_CANNONLAKE_10   0x5A54
> +#define PCI_CHIP_CANNONLAKE_11   0x5A5C
> +#define PCI_CHIP_CANNONLAKE_12   0x5A44
> +#define PCI_CHIP_CANNONLAKE_13   0x5A4C
>  
>  #define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \
>(devid) == PCI_CHIP_I915_GM || \
> @@ -515,20 +519,20 @@
>IS_GEMINILAKE(devid) || \
>IS_COFFEELAKE(devid))
>  
> -#define IS_CNL_Y(devid)  ((devid) == PCI_CHIP_CANNONLAKE_Y_GT2_0 
> || \
> -  (devid) == PCI_CHIP_CANNONLAKE_Y_GT2_1 || \
> -  (devid) == PCI_CHIP_CANNONLAKE_Y_GT2_2 || \
> -  (devid) == PCI_CHIP_CANNONLAKE_Y_GT2_3 || \
> -  (devid) == PCI_CHIP_CANNONLAKE_Y_GT2_4 || \
> -  (devid) == PCI_CHIP_CANNONLAKE_Y_GT2_5)
> -
> -#define IS_CNL_U(devid)  ((devid) == PCI_CHIP_CANNONLAKE_U_GT2_0 
> || \
> -  (devid) == PCI_CHIP_CANNONLAKE_U_GT2_1 || \
> -  (devid) == PCI_CHIP_CANNONLAKE_U_GT2_2 || \
> -  (devid) == PCI_CHIP_CANNONLAKE_U_GT2_3)
> -
> -#define IS_CANNONLAKE(devid) (IS_CNL_U(devid) || \
> -  IS_CNL_Y(devid))
> +#define IS_CANNONLAKE(devid) ((devid) == PCI_CHIP_CANNONLAKE_0 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_1 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_2 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_3 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_4 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_5 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_6 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_7 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_8 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_9 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_10 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_11 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_12 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_13)
>  
>  #define IS_GEN10(devid)  (IS_CANNONLAKE(devid))
>  
> -- 
> 2.13.6
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 20/22] i965/vec4: Relax writemask condition in CSE

[Kenneth Graunke]

On Friday, February 23, 2018 3:56:05 PM PST Ian Romanick wrote:
> From: Ian Romanick 
> 
> If the previously seen instruction generates more fields than the new
> instruction, still allow CSE to happen.  This doesn't do much, but it
> also enables a couple more shaders in the next patch.  It helped quite a
> bit in another change series that I have (at least for now) abandoned.
> 
> No changes on Skylake, Broadwell, Iron Lake or GM45.

Skylake and Broadwell sort of go without saying, they don't use this
compiler :)

It might be worth leaving some kind of comment (or renaming variables?)
in instructions_match() to indicate that 'a' is the generating
expression and 'b' is the second instance...since it's no longer
exactly symmetrical.

Either way,
Reviewed-by: Kenneth Graunke 


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

Re: [Mesa-dev] [PATCH v2 2/5] i965/miptree: Use cpu tiling/detiling when mapping

[Nanley Chery]

On Thu, Jan 25, 2018 at 08:23:45AM -0800, Scott D Phillips wrote:
> Rename the (un)map_gtt functions to (un)map_map (map by
> returning a map) and add new functions (un)map_tiled_memcpy that
> return a shadow buffer populated with the intel_tiled_memcpy
> functions.
> 
> v2: Compute extents properly in the x|y-rounded-down case (Chris Wilson)
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 95 
> ---
>  1 file changed, 86 insertions(+), 9 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index c480eade93..85297cb0c1 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -31,6 +31,7 @@
>  #include "intel_image.h"
>  #include "intel_mipmap_tree.h"
>  #include "intel_tex.h"
> +#include "intel_tiled_memcpy.h"
>  #include "intel_blit.h"
>  #include "intel_fbo.h"
>  
> @@ -3028,10 +3029,10 @@ intel_miptree_unmap_raw(struct intel_mipmap_tree *mt)
>  }
>  
>  static void
> -intel_miptree_map_gtt(struct brw_context *brw,
> -   struct intel_mipmap_tree *mt,
> -   struct intel_miptree_map *map,
> -   unsigned int level, unsigned int slice)
> +intel_miptree_map_map(struct brw_context *brw,
> +  struct intel_mipmap_tree *mt,
> +  struct intel_miptree_map *map,
> +  unsigned int level, unsigned int slice)
>  {
> unsigned int bw, bh;
> void *base;
> @@ -3049,7 +3050,7 @@ intel_miptree_map_gtt(struct brw_context *brw,
> y /= bh;
> x /= bw;
>  
> -   base = intel_miptree_map_raw(brw, mt, map->mode);
> +   base = intel_miptree_map_raw(brw, mt, map->mode | MAP_RAW);
>  
> if (base == NULL)
>map->ptr = NULL;
> @@ -3075,11 +3076,80 @@ intel_miptree_map_gtt(struct brw_context *brw,
>  }
>  
>  static void
> -intel_miptree_unmap_gtt(struct intel_mipmap_tree *mt)
> +intel_miptree_unmap_map(struct intel_mipmap_tree *mt)
>  {
> intel_miptree_unmap_raw(mt);
>  }
>  
> +/* Compute extent parameters for use with tiled_memcpy functions.
> + * xs are in units of bytes and ys are in units of strides. */
> +static inline void
> +tile_extents(struct intel_mipmap_tree *mt, struct intel_miptree_map *map,
> + unsigned int level, unsigned int slice, unsigned int *x1,
> + unsigned int *x2, unsigned int *y1, unsigned int *y2)
> +{
> +   unsigned int block_width, block_height, block_bytes;
> +   unsigned int x0_el, y0_el;
> +
> +   _mesa_get_format_block_size(mt->format, _width, _height);
> +   block_bytes = _mesa_get_format_bytes(mt->format);
> +
> +   assert(map->x % block_width == 0);
> +   assert(map->y % block_height == 0);
> +
> +   intel_miptree_get_image_offset(mt, level, slice, _el, _el);
> +   *x1 = (map->x / block_width + x0_el) * block_bytes;
> +   *y1 = map->y / block_height + y0_el;
> +   *x2 = (DIV_ROUND_UP(map->x + map->w, block_width) + x0_el) * block_bytes;
> +   *y2 = DIV_ROUND_UP(map->y + map->h, block_height) + y0_el;
> +}
> +
> +static void
> +intel_miptree_map_tiled_memcpy(struct brw_context *brw,
> +   struct intel_mipmap_tree *mt,
> +   struct intel_miptree_map *map,
> +   unsigned int level, unsigned int slice)
> +{
> +   unsigned int x1, x2, y1, y2;
> +   tile_extents(mt, map, level, slice, , , , );
> +   map->stride = _mesa_format_row_stride(mt->format, map->w);
> +   map->buffer = map->ptr = malloc(map->stride * (y2 - y1));
> +
> +   if (!(map->mode & GL_MAP_INVALIDATE_RANGE_BIT)) {
> +  char *src = intel_miptree_map_raw(brw, mt, map->mode | MAP_RAW);
> +  src += mt->offset;
> +
> +  tiled_to_linear(x1, x2, y1, y2, map->ptr, src, map->stride,
> +  mt->surf.row_pitch, brw->has_swizzling, 
> mt->surf.tiling,
> +  memcpy);
> +

Do we have a mechanism to test if a miptree level and slice are valid?
It doesn't seem like the mode have the GL_MAP_INVALIDATE_RANGE_BIT set
in all the cases we care about.

For example, it looks like we'll do an extra memcpy operation when the
user specifies an image for the first time (using glTexImage2D for
example).

It looks like there are unknown perf implications with this path. How do
you feel about putting this behind a debug flag?

-Nanley

> +  intel_miptree_unmap_raw(mt);
> +   }
> +}
> +
> +static void
> +intel_miptree_unmap_tiled_memcpy(struct brw_context *brw,
> + struct intel_mipmap_tree *mt,
> + struct intel_miptree_map *map,
> + unsigned int level,
> + unsigned int slice)
> +{
> +   if (map->mode & GL_MAP_WRITE_BIT) {
> +  unsigned int x1, x2, y1, y2;
> +  tile_extents(mt, map, level, slice, , , , );
> +
> +  char *dst = intel_miptree_map_raw(brw, mt, map->mode | 

Re: [Mesa-dev] [PATCH 19/22 v3] i965/fs: Merge CMP and SEL into CSEL on Gen8+

[Kenneth Graunke]

On Wednesday, February 28, 2018 12:20:28 PM PST Ian Romanick wrote:
> From: Ian Romanick 
> 
> v2: Fix several problems handling inverted predicates.  Add a much
> bigger comment around the BRW_CONDITIONAL_NZ case.
> 
> v3: Allow uniforms and shader inputs as sources for the original SEL and
> CMP instructions.  This enables a LOT more shaders to receive CSEL
> merging (5816 vs 8564 on SKL).
> 
> Broadwell and Skylake had similar results. (Broadwell shown)
> helped: 8527
> HURT: 0
> helped stats (abs) min: 1 max: 27 x̄: 2.44 x̃: 1
> helped stats (rel) min: 0.03% max: 17.80% x̄: 1.12% x̃: 0.70%
> 95% mean confidence interval for instructions value: -2.51 -2.36
> 95% mean confidence interval for instructions %-change: -1.15% -1.10%
> Instructions are helped.
> 
> total cycles in shared programs: 559442317 -> 558288357 (-0.21%)
> cycles in affected programs: 372699860 -> 371545900 (-0.31%)
> helped: 6748
> HURT: 1450
> helped stats (abs) min: 1 max: 32000 x̄: 182.41 x̃: 12
> helped stats (rel) min: <.01% max: 66.08% x̄: 3.42% x̃: 0.70%
> HURT stats (abs)   min: 1 max: 2538 x̄: 53.08 x̃: 14
> HURT stats (rel)   min: <.01% max: 96.72% x̄: 3.32% x̃: 0.90%
> 95% mean confidence interval for cycles value: -179.01 -102.51
> 95% mean confidence interval for cycles %-change: -2.37% -2.08%
> Cycles are helped.
> 
> LOST:   0
> GAINED: 6
> 
> No changes on earlier platforms.
> 
> Signed-off-by: Ian Romanick 

Nice, thanks for doing this, Ian!

Reviewed-by: Kenneth Graunke 


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

[Mesa-dev] [PATCH 2/2] etnaviv: add get_driver_query_group_info(..)

[Christian Gmeiner]

This enables AMD_performance_monitor extension.

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

diff --git a/src/gallium/drivers/etnaviv/etnaviv_query.c 
b/src/gallium/drivers/etnaviv/etnaviv_query.c
index 9e897cd75a..2d257a9d34 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_query.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_query.c
@@ -110,6 +110,18 @@ etna_get_driver_query_info(struct pipe_screen *pscreen, 
unsigned index,
return etna_sw_get_driver_query_info(pscreen, index, info);
 }
 
+static int
+etna_get_driver_query_group_info(struct pipe_screen *pscreen, unsigned index,
+ struct pipe_driver_query_group_info *info)
+{
+   int nr_sw_groups = etna_sw_get_driver_query_group_info(pscreen, 0, NULL);
+
+   if (!info)
+  return nr_sw_groups;
+
+   return etna_sw_get_driver_query_group_info(pscreen, index, info);
+}
+
 static void
 etna_set_active_query_state(struct pipe_context *pipe, boolean enable)
 {
@@ -119,6 +131,7 @@ void
 etna_query_screen_init(struct pipe_screen *pscreen)
 {
pscreen->get_driver_query_info = etna_get_driver_query_info;
+   pscreen->get_driver_query_group_info = etna_get_driver_query_group_info;
 }
 
 void
-- 
2.14.3

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

[Mesa-dev] [PATCH 1/2] etnaviv: add query_group_info for sw counters

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 src/gallium/drivers/etnaviv/etnaviv_query_sw.c | 30 --
 src/gallium/drivers/etnaviv/etnaviv_query_sw.h |  5 +
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_query_sw.c 
b/src/gallium/drivers/etnaviv/etnaviv_query_sw.c
index 2e65065b28..f955d8e210 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_query_sw.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_query_sw.c
@@ -118,16 +118,16 @@ etna_sw_create_query(struct etna_context *ctx, unsigned 
query_type)
return q;
 }
 
+static const struct pipe_driver_query_info list[] = {
+   {"prims-emitted", PIPE_QUERY_PRIMITIVES_EMITTED, { 0 }},
+   {"draw-calls", ETNA_QUERY_DRAW_CALLS, { 0 }},
+   {"rs-operations", ETNA_QUERY_RS_OPERATIONS, { 0 }},
+};
+
 int
 etna_sw_get_driver_query_info(struct pipe_screen *pscreen, unsigned index,
   struct pipe_driver_query_info *info)
 {
-   static const struct pipe_driver_query_info list[] = {
-  {"prims-emitted", PIPE_QUERY_PRIMITIVES_EMITTED, { 0 }},
-  {"draw-calls", ETNA_QUERY_DRAW_CALLS, { 0 }},
-  {"rs-operations", ETNA_QUERY_RS_OPERATIONS, { 0 }},
-   };
-
if (!info)
   return ARRAY_SIZE(list);
 
@@ -138,3 +138,21 @@ etna_sw_get_driver_query_info(struct pipe_screen *pscreen, 
unsigned index,
 
return 1;
 }
+
+int
+etna_sw_get_driver_query_group_info(struct pipe_screen *pscreen,
+unsigned index,
+struct pipe_driver_query_group_info *info)
+{
+   if (!info)
+  return ARRAY_SIZE(list);
+
+   if (index != 0)
+  return 0;
+
+   info->name = "driver";
+   info->max_active_queries = ARRAY_SIZE(list);
+   info->num_queries = ARRAY_SIZE(list);
+
+   return 1;
+}
diff --git a/src/gallium/drivers/etnaviv/etnaviv_query_sw.h 
b/src/gallium/drivers/etnaviv/etnaviv_query_sw.h
index 9321147094..f5a2dbef1a 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_query_sw.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_query_sw.h
@@ -51,4 +51,9 @@ int
 etna_sw_get_driver_query_info(struct pipe_screen *pscreen, unsigned index,
   struct pipe_driver_query_info *info);
 
+int
+etna_sw_get_driver_query_group_info(struct pipe_screen *pscreen,
+unsigned index,
+struct pipe_driver_query_group_info *info);
+
 #endif
-- 
2.14.3

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

[Mesa-dev] [PATCH 0/2] etnaviv: amd_performance_monitor support

[Christian Gmeiner]

Nothing fancy - passes all amd_performance_monitor piglits.

Christian Gmeiner (2):
  etnaviv: add query_group_info for sw counters
  etnaviv: add get_driver_query_group_info(..)

 src/gallium/drivers/etnaviv/etnaviv_query.c| 13 +++
 src/gallium/drivers/etnaviv/etnaviv_query_sw.c | 30 --
 src/gallium/drivers/etnaviv/etnaviv_query_sw.h |  5 +
 3 files changed, 42 insertions(+), 6 deletions(-)

-- 
2.14.3

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

Re: [Mesa-dev] [PATCH 11/22 v2] nir: Recognize some more open-coded fmin / fmax

[Ian Romanick]

On 03/05/2018 02:07 PM, Jason Ekstrand wrote:
> On Mon, Mar 5, 2018 at 11:11 AM, Ian Romanick  > wrote:
> 
> On 02/28/2018 12:48 PM, Jason Ekstrand wrote:
> > Rb
> 
> For both or just this one?
> 
> 
> If you put the ~ on there, both.

I'm not sure what you mean.  That's all the other patch ([PATCH 11.1/22]
nir: Mark bcsel-to-fmin (or fmax) transformations as inexact) does.

> > On Wed, Feb 28, 2018 at 12:18 PM, Ian Romanick  
> > >> wrote:
> >
> >     From: Ian Romanick  
> >      >>
> >
> >     This transformation is inexact because section 4.7.1 (Range and
> >     Precision) says:
> >
> >         Operations and built-in functions that operate on a NaN
> are not
> >         required to return a NaN as the result.
> >
> >     The fmin or fmax might not return NaN in cases where the original
> >     expression would be required to return NaN.
> >
> >     v2: Reorder operands and mark as inexact.  The latter suggested by
> >     Jason.
> >
> >     shader-db results:
> >
> >     Haswell, Broadwell, and Skylake had similar results. (Skylake
> shown)
> >     total instructions in shared programs: 14514817 -> 14514808
> (<.01%)
> >     instructions in affected programs: 229 -> 220 (-3.93%)
> >     helped: 3
> >     HURT: 0
> >     helped stats (abs) min: 1 max: 4 x̄: 3.00 x̃: 4
> >     helped stats (rel) min: 2.86% max: 4.12% x̄: 3.70% x̃: 4.12%
> >
> >     total cycles in shared programs: 533145211 -> 533144939 (<.01%)
> >     cycles in affected programs: 37268 -> 36996 (-0.73%)
> >     helped: 8
> >     HURT: 0
> >     helped stats (abs) min: 2 max: 134 x̄: 34.00 x̃: 2
> >     helped stats (rel) min: 0.02% max: 14.22% x̄: 3.53% x̃: 0.05%
> >
> >     Sandy Bridge and Ivy Bridge had similar results. (Ivy Bridge
> shown)
> >     total cycles in shared programs: 257618409 -> 257618403 (<.01%)
> >     cycles in affected programs: 12582 -> 12576 (-0.05%)
> >     helped: 3
> >     HURT: 0
> >     helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2
> >     helped stats (rel) min: 0.05% max: 0.05% x̄: 0.05% x̃: 0.05%
> >
> >     No changes on Iron Lake or GM45.
> >
> >     Signed-off-by: Ian Romanick  
> >      >>
> >     ---
> >      src/compiler/nir/nir_opt_algebraic.py | 2 ++
> >      1 file changed, 2 insertions(+)
> >
> >     diff --git a/src/compiler/nir/nir_opt_algebraic.py
> >     b/src/compiler/nir/nir_opt_algebraic.py
> >     index d40d59b..17f4d9c 100644
> >     --- a/src/compiler/nir/nir_opt_algebraic.py
> >     +++ b/src/compiler/nir/nir_opt_algebraic.py
> >     @@ -170,6 +170,8 @@ optimizations = [
> >         (('fge', ('fneg', ('fabs', a)), 0.0), ('feq', a, 0.0)),
> >         (('bcsel', ('flt', b, a), b, a), ('fmin', a, b)),
> >         (('bcsel', ('flt', a, b), b, a), ('fmax', a, b)),
> >     +   (('~bcsel', ('fge', a, b), b, a), ('fmin', a, b)),
> >     +   (('~bcsel', ('fge', b, a), b, a), ('fmax', a, b)),
> >         (('bcsel', ('inot', a), b, c), ('bcsel', a, c, b)),
> >         (('bcsel', a, ('bcsel', a, b, c), d), ('bcsel', a, b, d)),
> >         (('bcsel', a, True, 'b@bool'), ('ior', a, b)),
> >     --
> >     2.9.5
> >
> >     ___
> >     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 18/22] i965/fs: Add infrastructure for generating CSEL instructions.

[Kenneth Graunke]

On Monday, March 5, 2018 11:17:29 AM PST Ian Romanick wrote:
> On 02/28/2018 12:58 AM, Samuel Iglesias Gonsálvez wrote:
> > On 24/02/18 00:56, Ian Romanick wrote:
> >> From: Kenneth Graunke 
> >>
> >> v2 (idr): Don't allow CSEL with a non-float src2.
> >>
> >> v3 (idr): Add CSEL to fs_inst::flags_written.  Suggested by Matt.
> >>
> >> Signed-off-by: Kenneth Graunke 
> >> Signed-off-by: Ian Romanick 
> >> ---
> >>  src/intel/compiler/brw_eu.h |  1 +
> >>  src/intel/compiler/brw_eu_emit.c|  1 +
> >>  src/intel/compiler/brw_fs.cpp   |  1 +
> >>  src/intel/compiler/brw_fs_builder.h | 22 +-
> >>  src/intel/compiler/brw_fs_generator.cpp |  5 +
> >>  5 files changed, 29 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/intel/compiler/brw_fs_generator.cpp 
> >> b/src/intel/compiler/brw_fs_generator.cpp
> >> index cd5be05..9157367 100644
> >> --- a/src/intel/compiler/brw_fs_generator.cpp
> >> +++ b/src/intel/compiler/brw_fs_generator.cpp
> >> @@ -1826,6 +1826,11 @@ fs_generator::generate_code(const cfg_t *cfg, int 
> >> dispatch_width)
> >>case BRW_OPCODE_SEL:
> >> brw_SEL(p, dst, src[0], src[1]);
> >> break;
> >> +  case BRW_OPCODE_CSEL:
> >> + brw_set_default_access_mode(p, BRW_ALIGN_16);
> >> + brw_CSEL(p, dst, src[0], src[1], src[2]);
> >> + brw_set_default_access_mode(p, BRW_ALIGN_1);
> > 
> > Setting the access mode to ALIGN_1 is not needed, right? It will
> > continue with the next instruction in the loop that sets ALIGN1 at the
> > beginning of the loop.
> 
> This was in Ken's original patch, so I'm not 100% sure.  I've seen this
> pattern around generating some other instructions, so my gut tells me
> that it's done like this to be explicit and more defensive.

Yeah, I don't think it's strictly necessary, but it's probably a good
idea regardless, just to be defensive.  Most instructions should be
align1, and we just want to emit this one instruction in align16.

A more conservative approach still would be to push/set_default/pop.
I think when I wrote this, I was planning on eliminating push/pop, but
that never happened (and probably won't at this point).

I think it's fine as is, or I'd be fine with push/set/pop.


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] [PATCH 2/3] i965/extensions: Enable ASTC HDR on CannonLake

[Nanley Chery]

Cc: Rafael Antognolli 
---
 src/mesa/drivers/dri/i965/intel_extensions.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 73a6c73f537..c451f6cf749 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -297,7 +297,7 @@ intelInitExtensions(struct gl_context *ctx)
   ctx->Extensions.ARB_post_depth_coverage = true;
}
 
-   if (gen_device_info_is_9lp(devinfo))
+   if (devinfo->gen == 10 || gen_device_info_is_9lp(devinfo))
   ctx->Extensions.KHR_texture_compression_astc_hdr = true;
 
if (devinfo->gen >= 6)
-- 
2.16.1

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

[Mesa-dev] [PATCH 3/3] i965/tex_image: Avoid the ASTC LDR workaround on gen9lp

[Nanley Chery]

Both the internal documentation and the results of testing this in the
CI suggest that this is unnecessary. Add the fixes tag because this
reduces an internal benchmark's startup time significantly. Eero
reported that a less optimal version of this patch reduced the startup
time of the benchmark by about 14 seconds.

Fixes: 710b1d2e665 "i965/tex_image: Flush certain subnormal ASTC channel values"
Cc: Eero Tamminen 
Cc: Scott D Phillips 
---
 src/mesa/drivers/dri/i965/intel_tex_image.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c 
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index e25bc9a0c08..a0408b304d5 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -927,7 +927,7 @@ intelCompressedTexSubImage(struct gl_context *ctx, GLuint 
dims,
 !_mesa_is_srgb_format(gl_format);
struct brw_context *brw = (struct brw_context*) ctx;
const struct gen_device_info *devinfo = >screen->devinfo;
-   if (devinfo->gen == 9 && is_linear_astc)
+   if (devinfo->gen == 9 && !gen_device_info_is_9lp(devinfo) && is_linear_astc)
   flush_astc_denorms(ctx, dims, texImage,
  xoffset, yoffset, zoffset,
  width, height, depth);
-- 
2.16.1

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

[Mesa-dev] [PATCH 1/3] i965/mipmap_tree: Don't allocate CCS when emulating ETC support

[Nanley Chery]

---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index c6213b21629..8586968fd6f 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -205,11 +205,11 @@ intel_miptree_supports_ccs(struct brw_context *brw,
if (devinfo->gen < 8 && (mip_mapped || arrayed))
   return false;
 
-   /* There's no point in using an MCS buffer if the surface isn't in a
-* renderable format.
-*/
-   if (!brw->mesa_format_supports_render[mt->format])
+   /* There's no need for an MCS buffer if the surface isn't renderable. */
+   if (!brw->mesa_format_supports_render[mt->format] ||
+   (mt->etc_format != MESA_FORMAT_NONE)) {
   return false;
+   }
 
return true;
 }
-- 
2.16.1

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

Re: [Mesa-dev] [PATCH 11/22 v2] nir: Recognize some more open-coded fmin / fmax

[Jason Ekstrand]

On Mon, Mar 5, 2018 at 11:11 AM, Ian Romanick  wrote:

> On 02/28/2018 12:48 PM, Jason Ekstrand wrote:
> > Rb
>
> For both or just this one?
>

If you put the ~ on there, both.


> > On Wed, Feb 28, 2018 at 12:18 PM, Ian Romanick  > > wrote:
> >
> > From: Ian Romanick  > >
> >
> > This transformation is inexact because section 4.7.1 (Range and
> > Precision) says:
> >
> > Operations and built-in functions that operate on a NaN are not
> > required to return a NaN as the result.
> >
> > The fmin or fmax might not return NaN in cases where the original
> > expression would be required to return NaN.
> >
> > v2: Reorder operands and mark as inexact.  The latter suggested by
> > Jason.
> >
> > shader-db results:
> >
> > Haswell, Broadwell, and Skylake had similar results. (Skylake shown)
> > total instructions in shared programs: 14514817 -> 14514808 (<.01%)
> > instructions in affected programs: 229 -> 220 (-3.93%)
> > helped: 3
> > HURT: 0
> > helped stats (abs) min: 1 max: 4 x̄: 3.00 x̃: 4
> > helped stats (rel) min: 2.86% max: 4.12% x̄: 3.70% x̃: 4.12%
> >
> > total cycles in shared programs: 533145211 -> 533144939 (<.01%)
> > cycles in affected programs: 37268 -> 36996 (-0.73%)
> > helped: 8
> > HURT: 0
> > helped stats (abs) min: 2 max: 134 x̄: 34.00 x̃: 2
> > helped stats (rel) min: 0.02% max: 14.22% x̄: 3.53% x̃: 0.05%
> >
> > Sandy Bridge and Ivy Bridge had similar results. (Ivy Bridge shown)
> > total cycles in shared programs: 257618409 -> 257618403 (<.01%)
> > cycles in affected programs: 12582 -> 12576 (-0.05%)
> > helped: 3
> > HURT: 0
> > helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2
> > helped stats (rel) min: 0.05% max: 0.05% x̄: 0.05% x̃: 0.05%
> >
> > No changes on Iron Lake or GM45.
> >
> > Signed-off-by: Ian Romanick  > >
> > ---
> >  src/compiler/nir/nir_opt_algebraic.py | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/src/compiler/nir/nir_opt_algebraic.py
> > b/src/compiler/nir/nir_opt_algebraic.py
> > index d40d59b..17f4d9c 100644
> > --- a/src/compiler/nir/nir_opt_algebraic.py
> > +++ b/src/compiler/nir/nir_opt_algebraic.py
> > @@ -170,6 +170,8 @@ optimizations = [
> > (('fge', ('fneg', ('fabs', a)), 0.0), ('feq', a, 0.0)),
> > (('bcsel', ('flt', b, a), b, a), ('fmin', a, b)),
> > (('bcsel', ('flt', a, b), b, a), ('fmax', a, b)),
> > +   (('~bcsel', ('fge', a, b), b, a), ('fmin', a, b)),
> > +   (('~bcsel', ('fge', b, a), b, a), ('fmax', a, b)),
> > (('bcsel', ('inot', a), b, c), ('bcsel', a, c, b)),
> > (('bcsel', a, ('bcsel', a, b, c), d), ('bcsel', a, b, d)),
> > (('bcsel', a, True, 'b@bool'), ('ior', a, b)),
> > --
> > 2.9.5
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org  freedesktop.org>
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> >
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/5] i965/miptree: Use cpu tiling/detiling when mapping

[Jason Ekstrand]

On Mon, Mar 5, 2018 at 11:39 AM, Nanley Chery  wrote:

> On Tue, Jan 09, 2018 at 11:16:59PM -0800, Scott D Phillips wrote:
> > Rename the (un)map_gtt functions to (un)map_map (map by
> > returning a map) and add new functions (un)map_tiled_memcpy that
> > return a shadow buffer populated with the intel_tiled_memcpy
> > functions.
>
> Could you mention some of the rationale?
>
> > ---
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 95
> ---
> >  1 file changed, 86 insertions(+), 9 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > index ead0c359c0..7a90dafa1e 100644
> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > @@ -31,6 +31,7 @@
> >  #include "intel_image.h"
> >  #include "intel_mipmap_tree.h"
> >  #include "intel_tex.h"
> > +#include "intel_tiled_memcpy.h"
> >  #include "intel_blit.h"
> >  #include "intel_fbo.h"
> >
> > @@ -3031,10 +3032,10 @@ intel_miptree_unmap_raw(struct intel_mipmap_tree
> *mt)
> >  }
> >
> >  static void
> > -intel_miptree_map_gtt(struct brw_context *brw,
> > -   struct intel_mipmap_tree *mt,
> > -   struct intel_miptree_map *map,
> > -   unsigned int level, unsigned int slice)
> > +intel_miptree_map_map(struct brw_context *brw,
> > +  struct intel_mipmap_tree *mt,
> > +  struct intel_miptree_map *map,
> > +  unsigned int level, unsigned int slice)
> >  {
> > unsigned int bw, bh;
> > void *base;
> > @@ -3052,7 +3053,7 @@ intel_miptree_map_gtt(struct brw_context *brw,
> > y /= bh;
> > x /= bw;
> >
> > -   base = intel_miptree_map_raw(brw, mt, map->mode);
> > +   base = intel_miptree_map_raw(brw, mt, map->mode | MAP_RAW);
> >
> > if (base == NULL)
> >map->ptr = NULL;
> > @@ -3078,11 +3079,80 @@ intel_miptree_map_gtt(struct brw_context *brw,
> >  }
> >
> >  static void
> > -intel_miptree_unmap_gtt(struct intel_mipmap_tree *mt)
> > +intel_miptree_unmap_map(struct intel_mipmap_tree *mt)
> >  {
> > intel_miptree_unmap_raw(mt);
> >  }
> >
> > +/* Compute extent parameters for use with tiled_memcpy functions.
> > + * xs are in units of bytes and ys are in units of strides. */
> > +static inline void
> > +tile_extents(struct intel_mipmap_tree *mt, struct intel_miptree_map
> *map,
> > + unsigned int level, unsigned int slice, unsigned int *x1,
> > + unsigned int *x2, unsigned int *y1, unsigned int *y2)
>
> It would be nice to give these variables units:
> x1_B, y1_el, etc.
>
> > +{
> > +   unsigned int block_width, block_height, block_bytes;
> > +   unsigned int x0_el, y0_el;
> > +
> > +   _mesa_get_format_block_size(mt->format, _width,
> _height);
> > +   block_bytes = _mesa_get_format_bytes(mt->format);
>
> block_bytes == mt->cpp (in theory anyways)
>
> > +
> > +   assert(map->x % block_width == 0);
> > +   assert(map->y % block_height == 0);
> > +
> > +   intel_miptree_get_image_offset(mt, level, slice, _el, _el);
> > +   *x1 = (map->x / block_width + x0_el) * block_bytes;
> > +   *y1 = map->y / block_height + y0_el;
> > +   *x2 = *x1 + DIV_ROUND_UP(map->w, block_width) * block_bytes;
> > +   *y2 = *y1 + DIV_ROUND_UP(map->h, block_height);
> > +}
> > +
> > +static void
> > +intel_miptree_map_tiled_memcpy(struct brw_context *brw,
> > +   struct intel_mipmap_tree *mt,
> > +   struct intel_miptree_map *map,
> > +   unsigned int level, unsigned int slice)
> > +{
> > +   unsigned int x1, x2, y1, y2;
> > +   tile_extents(mt, map, level, slice, , , , );
> > +   map->stride = _mesa_format_row_stride(mt->format, map->w);
> > +   map->buffer = map->ptr = malloc(map->stride * (y2 - y1));
>
> Using _mesa_align_malloc should improve memory accesses for our 128bit
> formats.
>
> We should probably also assert(map->ptr) or throw a GL_OUT_OF_MEMORY
> error if the alloc fails.
>
> > +
> > +   if (!(map->mode & GL_MAP_INVALIDATE_RANGE_BIT)) {
> > +  char *src = intel_miptree_map_raw(brw, mt, map->mode | MAP_RAW);
> > +  src += mt->offset;
> > +
> > +  tiled_to_linear(x1, x2, y1, y2, map->ptr, src, map->stride,
> > +  mt->surf.row_pitch, brw->has_swizzling,
> mt->surf.tiling,
> > +  memcpy);
> > +
> > +  intel_miptree_unmap_raw(mt);
> > +   }
> > +}
> > +
> > +static void
> > +intel_miptree_unmap_tiled_memcpy(struct brw_context *brw,
> > + struct intel_mipmap_tree *mt,
> > + struct intel_miptree_map *map,
> > + unsigned int level,
> > + unsigned int slice)
> > +{
> > +   if (map->mode & GL_MAP_WRITE_BIT) {
> > +  unsigned int x1, x2, y1, y2;
> > +  tile_extents(mt, map, level, 

[Mesa-dev] [PATCH] spirv: Add SpvCapabilityShaderViewportIndexLayerEXT

[Caio Marcelo de Oliveira Filho]

This capability allows gl_ViewportIndex and gl_Layer to also be used
as outputs in Vertex and Tesselation shaders.

v2: Make conditional to the capability, add gl_Layer, add tesselation
shaders. (Iago)

v3: Don't export to tesselation control shader.

v4: Add Reviewd-by tag.

Reviewed-by: Iago Toral Quiroga 
---

Iago, I don't have write access to the repository. Could you apply
this?

 src/compiler/shader_info.h | 1 +
 src/compiler/spirv/spirv_to_nir.c  | 4 
 src/compiler/spirv/vtn_variables.c | 8 
 3 files changed, 13 insertions(+)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index e7fd7dbe62..2fcbde74be 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -43,6 +43,7 @@ struct spirv_supported_capabilities {
bool multiview;
bool variable_pointers;
bool storage_16bit;
+   bool shader_viewport_index_layer;
 };
 
 typedef struct shader_info {
diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index c6df764682..fdb2993db5 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3203,6 +3203,10 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
  spv_check_supported(storage_16bit, cap);
  break;
 
+  case SpvCapabilityShaderViewportIndexLayerEXT:
+ spv_check_supported(shader_viewport_index_layer, cap);
+ break;
+
   default:
  vtn_fail("Unhandled capability");
   }
diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 7e8a090add..11d2aabac8 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1187,6 +1187,10 @@ vtn_get_builtin_location(struct vtn_builder *b,
  *mode = nir_var_shader_in;
   else if (b->shader->info.stage == MESA_SHADER_GEOMETRY)
  *mode = nir_var_shader_out;
+  else if (b->options && b->options->caps.shader_viewport_index_layer &&
+   (b->shader->info.stage == MESA_SHADER_VERTEX ||
+b->shader->info.stage == MESA_SHADER_TESS_EVAL))
+ *mode = nir_var_shader_out;
   else
  vtn_fail("invalid stage for SpvBuiltInLayer");
   break;
@@ -1194,6 +1198,10 @@ vtn_get_builtin_location(struct vtn_builder *b,
   *location = VARYING_SLOT_VIEWPORT;
   if (b->shader->info.stage == MESA_SHADER_GEOMETRY)
  *mode = nir_var_shader_out;
+  else if (b->options && b->options->caps.shader_viewport_index_layer &&
+   (b->shader->info.stage == MESA_SHADER_VERTEX ||
+b->shader->info.stage == MESA_SHADER_TESS_EVAL))
+ *mode = nir_var_shader_out;
   else if (b->shader->info.stage == MESA_SHADER_FRAGMENT)
  *mode = nir_var_shader_in;
   else
-- 
2.16.2

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

Re: [Mesa-dev] [RFC] radeonsi: guard against indexbuf not being set

[Roman Gilg]

This is a RFC because I don't really know what I'm doing here. But we
have this problem with AMD and KWin already for quite a long time and
I hope it can be fixed now.

I followed the debug output and tried this guard. On my system this
fixed the issue with Alt+Tab crashing KWin. Still this might be not
the right solution to the problem.

According to git-blame 330d0607 was the last time this condition was touched.

On Mon, Mar 5, 2018 at 10:31 PM, Roman Gilg  wrote:
> Fixes crashes of clients when index_size != 0, but there was no indexbuf
> set in si_draw_vbo.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103234
>
> Signed-off-by: Roman Gilg 
> ---
>  src/gallium/drivers/radeonsi/si_state_draw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
> b/src/gallium/drivers/radeonsi/si_state_draw.c
> index ad470fd..e53da38 100644
> --- a/src/gallium/drivers/radeonsi/si_state_draw.c
> +++ b/src/gallium/drivers/radeonsi/si_state_draw.c
> @@ -680,7 +680,7 @@ static void si_emit_draw_packets(struct si_context *sctx,
> }
>
> /* draw packet */
> -   if (index_size) {
> +   if (index_size && indexbuf) {
> if (index_size != sctx->last_index_size) {
> unsigned index_type;
>
> --
> 2.7.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [RFC] radeonsi: guard against indexbuf not being set

[Roman Gilg]

Fixes crashes of clients when index_size != 0, but there was no indexbuf
set in si_draw_vbo.

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

Signed-off-by: Roman Gilg 
---
 src/gallium/drivers/radeonsi/si_state_draw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index ad470fd..e53da38 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -680,7 +680,7 @@ static void si_emit_draw_packets(struct si_context *sctx,
}
 
/* draw packet */
-   if (index_size) {
+   if (index_size && indexbuf) {
if (index_size != sctx->last_index_size) {
unsigned index_type;
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 1/2] meson: Allow building dri based EGL without GLX

[Eric Anholt]

Dylan Baker  writes:

> It should be possible to build EGL without GLX, but the meson build
> currently doesn't allow that because it too tightly couples glx and dri.
> This patch eases dri and glx apart, so that EGL without GLX can be
> built.

These are:

Reviewed-by: Eric Anholt 


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

Re: [Mesa-dev] [PATCH mesa] freedreno: add missing include

[Rob Clark]

On Mon, Mar 5, 2018 at 12:52 PM, Eric Engestrom
 wrote:
> Fixes: 26a9321d0ae819f2a49d7 "freedreno: add global_bindings state"
> Cc: Rob Clark 
> Signed-off-by: Eric Engestrom 
> ---
>  src/gallium/drivers/freedreno/freedreno_state.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/drivers/freedreno/freedreno_state.c 
> b/src/gallium/drivers/freedreno/freedreno_state.c
> index 05717da95995e5cec6a5..907653e64af244bcc364 100644
> --- a/src/gallium/drivers/freedreno/freedreno_state.c
> +++ b/src/gallium/drivers/freedreno/freedreno_state.c
> @@ -40,6 +40,8 @@
>  #include "freedreno_query_hw.h"
>  #include "freedreno_util.h"
>
> +#include 
> +

hmm, freedreno_util.h already has

  #include 

which should in theory be enough..

But I did screw up and push the 'add global bindings state' before
spinning a libdrm release and bumping mesa's libdrm_freedreno version
dependency.  Not sure if that could be related to the compile error
you were hitting?

BR,
-R

>  /* All the generic state handling.. In case of CSO's that are specific
>   * to the GPU version, when the bind and the delete are common they can
>   * go in here.
> --
> Cheers,
>   Eric
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 0/6] Remove stubbed GLX_SGIX_swap_{barrier, group}

[Brian Paul]

On 03/05/2018 01:29 PM, Ian Romanick wrote:

On 03/05/2018 11:08 AM, Ian Romanick wrote:

On 03/05/2018 10:48 AM, Emil Velikov wrote:

Hi all,

It seems like these two extensions were never implemented or advertised.
Be that in:
  - glx/dri
  - glx/apple
  - classic xlib-glx
  - gallium xlib-glx

Yet, the entry points were available, hence apps might have linked
against it.


If an app was linking with an extension entry point instead of using
glXGetProcAddress, it is the app's bug.


True, but if we remove it and an app starts failing the end-user just 
thinks "broken driver" and gets frustrated.  I seem to remember writing 
some GLX stubs years ago for that reason.






Furthermore I cannot see any users of those on my system and a courtesy
google search. Additionally the Nvidia driver (checked version 390.25)
does not implement/advertise them either.

That said, I'm fairly confident that we can safely remove the no-op
stubs. Even though that the entry points were statically exposed.

Brian, Ian,

Do you have any recollection about these experimental SGI extensions?


Ajax and I had talked about implementing swap_group a few times, but
there were some technical challenges that we were too lazy to tackle.  I
think that's about as far as any of it ever got.


I should have also said...

Acked-by: Ian Romanick 


I'm fine with removing them too.  If someone really complains, they can 
always be restored.


Acked-by: Brian Paul 





Thanks
Emil

Cc: Ian Romanick 
Cc: Brian Paul 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA=CvxXt0YOXugGkbbzyxn0jAoAF0A6dRVbzGLLUqFneB8=NKrvsG5BEf-hY9B40F25ozkFXQA9YzWqK8P4QpZ5Xtc=

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA=CvxXt0YOXugGkbbzyxn0jAoAF0A6dRVbzGLLUqFneB8=NKrvsG5BEf-hY9B40F25ozkFXQA9YzWqK8P4QpZ5Xtc=



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA=CvxXt0YOXugGkbbzyxn0jAoAF0A6dRVbzGLLUqFneB8=NKrvsG5BEf-hY9B40F25ozkFXQA9YzWqK8P4QpZ5Xtc=



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

Re: [Mesa-dev] [RFC 0/6] Remove stubbed GLX_SGIX_swap_{barrier, group}

[Ian Romanick]

On 03/05/2018 11:08 AM, Ian Romanick wrote:
> On 03/05/2018 10:48 AM, Emil Velikov wrote:
>> Hi all,
>>
>> It seems like these two extensions were never implemented or advertised.
>> Be that in:
>>  - glx/dri
>>  - glx/apple
>>  - classic xlib-glx
>>  - gallium xlib-glx
>>
>> Yet, the entry points were available, hence apps might have linked
>> against it.
> 
> If an app was linking with an extension entry point instead of using
> glXGetProcAddress, it is the app's bug.
> 
>> Furthermore I cannot see any users of those on my system and a courtesy 
>> google search. Additionally the Nvidia driver (checked version 390.25) 
>> does not implement/advertise them either.
>>
>> That said, I'm fairly confident that we can safely remove the no-op 
>> stubs. Even though that the entry points were statically exposed.
>>
>> Brian, Ian,
>>
>> Do you have any recollection about these experimental SGI extensions?
> 
> Ajax and I had talked about implementing swap_group a few times, but
> there were some technical challenges that we were too lazy to tackle.  I
> think that's about as far as any of it ever got.

I should have also said...

Acked-by: Ian Romanick 

>> Thanks
>> Emil
>>
>> Cc: Ian Romanick 
>> Cc: Brian Paul 
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

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

Re: [Mesa-dev] [PATCH 2/5] i965/miptree: Use cpu tiling/detiling when mapping

[Nanley Chery]

On Tue, Jan 09, 2018 at 11:16:59PM -0800, Scott D Phillips wrote:
> Rename the (un)map_gtt functions to (un)map_map (map by
> returning a map) and add new functions (un)map_tiled_memcpy that
> return a shadow buffer populated with the intel_tiled_memcpy
> functions.

Could you mention some of the rationale?

> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 95 
> ---
>  1 file changed, 86 insertions(+), 9 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index ead0c359c0..7a90dafa1e 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -31,6 +31,7 @@
>  #include "intel_image.h"
>  #include "intel_mipmap_tree.h"
>  #include "intel_tex.h"
> +#include "intel_tiled_memcpy.h"
>  #include "intel_blit.h"
>  #include "intel_fbo.h"
>  
> @@ -3031,10 +3032,10 @@ intel_miptree_unmap_raw(struct intel_mipmap_tree *mt)
>  }
>  
>  static void
> -intel_miptree_map_gtt(struct brw_context *brw,
> -   struct intel_mipmap_tree *mt,
> -   struct intel_miptree_map *map,
> -   unsigned int level, unsigned int slice)
> +intel_miptree_map_map(struct brw_context *brw,
> +  struct intel_mipmap_tree *mt,
> +  struct intel_miptree_map *map,
> +  unsigned int level, unsigned int slice)
>  {
> unsigned int bw, bh;
> void *base;
> @@ -3052,7 +3053,7 @@ intel_miptree_map_gtt(struct brw_context *brw,
> y /= bh;
> x /= bw;
>  
> -   base = intel_miptree_map_raw(brw, mt, map->mode);
> +   base = intel_miptree_map_raw(brw, mt, map->mode | MAP_RAW);
>  
> if (base == NULL)
>map->ptr = NULL;
> @@ -3078,11 +3079,80 @@ intel_miptree_map_gtt(struct brw_context *brw,
>  }
>  
>  static void
> -intel_miptree_unmap_gtt(struct intel_mipmap_tree *mt)
> +intel_miptree_unmap_map(struct intel_mipmap_tree *mt)
>  {
> intel_miptree_unmap_raw(mt);
>  }
>  
> +/* Compute extent parameters for use with tiled_memcpy functions.
> + * xs are in units of bytes and ys are in units of strides. */
> +static inline void
> +tile_extents(struct intel_mipmap_tree *mt, struct intel_miptree_map *map,
> + unsigned int level, unsigned int slice, unsigned int *x1,
> + unsigned int *x2, unsigned int *y1, unsigned int *y2)

It would be nice to give these variables units:
x1_B, y1_el, etc.

> +{
> +   unsigned int block_width, block_height, block_bytes;
> +   unsigned int x0_el, y0_el;
> +
> +   _mesa_get_format_block_size(mt->format, _width, _height);
> +   block_bytes = _mesa_get_format_bytes(mt->format);

block_bytes == mt->cpp (in theory anyways)

> +
> +   assert(map->x % block_width == 0);
> +   assert(map->y % block_height == 0);
> +
> +   intel_miptree_get_image_offset(mt, level, slice, _el, _el);
> +   *x1 = (map->x / block_width + x0_el) * block_bytes;
> +   *y1 = map->y / block_height + y0_el;
> +   *x2 = *x1 + DIV_ROUND_UP(map->w, block_width) * block_bytes;
> +   *y2 = *y1 + DIV_ROUND_UP(map->h, block_height);
> +}
> +
> +static void
> +intel_miptree_map_tiled_memcpy(struct brw_context *brw,
> +   struct intel_mipmap_tree *mt,
> +   struct intel_miptree_map *map,
> +   unsigned int level, unsigned int slice)
> +{
> +   unsigned int x1, x2, y1, y2;
> +   tile_extents(mt, map, level, slice, , , , );
> +   map->stride = _mesa_format_row_stride(mt->format, map->w);
> +   map->buffer = map->ptr = malloc(map->stride * (y2 - y1));

Using _mesa_align_malloc should improve memory accesses for our 128bit formats.

We should probably also assert(map->ptr) or throw a GL_OUT_OF_MEMORY
error if the alloc fails.

> +
> +   if (!(map->mode & GL_MAP_INVALIDATE_RANGE_BIT)) {
> +  char *src = intel_miptree_map_raw(brw, mt, map->mode | MAP_RAW);
> +  src += mt->offset;
> +
> +  tiled_to_linear(x1, x2, y1, y2, map->ptr, src, map->stride,
> +  mt->surf.row_pitch, brw->has_swizzling, 
> mt->surf.tiling,
> +  memcpy);
> +
> +  intel_miptree_unmap_raw(mt);
> +   }
> +}
> +
> +static void
> +intel_miptree_unmap_tiled_memcpy(struct brw_context *brw,
> + struct intel_mipmap_tree *mt,
> + struct intel_miptree_map *map,
> + unsigned int level,
> + unsigned int slice)
> +{
> +   if (map->mode & GL_MAP_WRITE_BIT) {
> +  unsigned int x1, x2, y1, y2;
> +  tile_extents(mt, map, level, slice, , , , );
> +
> +  char *dst = intel_miptree_map_raw(brw, mt, map->mode | MAP_RAW);
> +  dst += mt->offset;
> +
> +  linear_to_tiled(x1, x2, y1, y2, dst, map->ptr, mt->surf.row_pitch,
> +  map->stride, brw->has_swizzling, mt->surf.tiling, 
> memcpy);
> +
> +  

Re: [Mesa-dev] [RFC 0/6] Remove stubbed GLX_SGIX_swap_{barrier, group}

[Adam Jackson]

On Mon, 2018-03-05 at 11:08 -0800, Ian Romanick wrote:
> On 03/05/2018 10:48 AM, Emil Velikov wrote:
> > 
> > Brian, Ian,
> > 
> > Do you have any recollection about these experimental SGI extensions?
> 
> Ajax and I had talked about implementing swap_group a few times, but
> there were some technical challenges that we were too lazy to tackle.  I
> think that's about as far as any of it ever got.

SGI Prism had this working with fglrx, I suspect InfiniteReality had it
too. We got part of the server-side support merged to Xorg but I don't
think the client side ever saw the light of day. At any rate the empty
stubs can't possibly be helping anything.

Series is:

Reviewed-by: Adam Jackson 

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

Re: [Mesa-dev] [PATCH 18/22] i965/fs: Add infrastructure for generating CSEL instructions.

[Ian Romanick]

On 02/28/2018 12:58 AM, Samuel Iglesias Gonsálvez wrote:
> On 24/02/18 00:56, Ian Romanick wrote:
>> From: Kenneth Graunke 
>>
>> v2 (idr): Don't allow CSEL with a non-float src2.
>>
>> v3 (idr): Add CSEL to fs_inst::flags_written.  Suggested by Matt.
>>
>> Signed-off-by: Kenneth Graunke 
>> Signed-off-by: Ian Romanick 
>> ---
>>  src/intel/compiler/brw_eu.h |  1 +
>>  src/intel/compiler/brw_eu_emit.c|  1 +
>>  src/intel/compiler/brw_fs.cpp   |  1 +
>>  src/intel/compiler/brw_fs_builder.h | 22 +-
>>  src/intel/compiler/brw_fs_generator.cpp |  5 +
>>  5 files changed, 29 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
>> index 2d0f56f..3201624 100644
>> --- a/src/intel/compiler/brw_eu.h
>> +++ b/src/intel/compiler/brw_eu.h
>> @@ -171,6 +171,7 @@ ALU2(SHR)
>>  ALU2(SHL)
>>  ALU1(DIM)
>>  ALU2(ASR)
>> +ALU3(CSEL)
>>  ALU1(F32TO16)
>>  ALU1(F16TO32)
>>  ALU2(ADD)
>> diff --git a/src/intel/compiler/brw_eu_emit.c 
>> b/src/intel/compiler/brw_eu_emit.c
>> index c25d8d6..305a759 100644
>> --- a/src/intel/compiler/brw_eu_emit.c
>> +++ b/src/intel/compiler/brw_eu_emit.c
>> @@ -953,6 +953,7 @@ ALU2(SHR)
>>  ALU2(SHL)
>>  ALU1(DIM)
>>  ALU2(ASR)
>> +ALU3(CSEL)
>>  ALU1(FRC)
>>  ALU1(RNDD)
>>  ALU2(MAC)
>> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
>> index bed632d..accae1b 100644
>> --- a/src/intel/compiler/brw_fs.cpp
>> +++ b/src/intel/compiler/brw_fs.cpp
>> @@ -929,6 +929,7 @@ unsigned
>>  fs_inst::flags_written() const
>>  {
>> if ((conditional_mod && (opcode != BRW_OPCODE_SEL &&
>> +opcode != BRW_OPCODE_CSEL &&
>>  opcode != BRW_OPCODE_IF &&
>>  opcode != BRW_OPCODE_WHILE)) ||
>> opcode == FS_OPCODE_MOV_DISPATCH_TO_FLAGS) {
>> diff --git a/src/intel/compiler/brw_fs_builder.h 
>> b/src/intel/compiler/brw_fs_builder.h
>> index 87394bc..47eac42 100644
>> --- a/src/intel/compiler/brw_fs_builder.h
>> +++ b/src/intel/compiler/brw_fs_builder.h
>> @@ -458,7 +458,6 @@ namespace brw {
>>ALU1(BFREV)
>>ALU1(CBIT)
>>ALU2(CMPN)
>> -  ALU3(CSEL)
>>ALU1(DIM)
>>ALU2(DP2)
>>ALU2(DP3)
>> @@ -534,6 +533,27 @@ namespace brw {
>>}
>>  
>>/**
>> +   * CSEL: dst = src2  0.0f ? src0 : src1
>> +   */
>> +  instruction *
>> +  CSEL(const dst_reg , const src_reg , const src_reg ,
>> +   const src_reg , brw_conditional_mod condition) const
>> +  {
>> + /* CSEL only operates on floats, so we can't do integer =/>
>> +  * comparisons.  Zero/non-zero (== and !=) comparisons almost work.
>> +  * 0x8000 fails because it is -0.0, and -0.0 == 0.0.
>> +  */
>> + assert(src2.type == BRW_REGISTER_TYPE_F);
>> +
>> + return set_condmod(condition,
>> +emit(BRW_OPCODE_CSEL,
>> + retype(dst, BRW_REGISTER_TYPE_F),
>> + retype(src0, BRW_REGISTER_TYPE_F),
>> + retype(src1, BRW_REGISTER_TYPE_F),
>> + src2));
>> +  }
>> +
>> +  /**
>> * Emit a linear interpolation instruction.
>> */
>>instruction *
>> diff --git a/src/intel/compiler/brw_fs_generator.cpp 
>> b/src/intel/compiler/brw_fs_generator.cpp
>> index cd5be05..9157367 100644
>> --- a/src/intel/compiler/brw_fs_generator.cpp
>> +++ b/src/intel/compiler/brw_fs_generator.cpp
>> @@ -1826,6 +1826,11 @@ fs_generator::generate_code(const cfg_t *cfg, int 
>> dispatch_width)
>>case BRW_OPCODE_SEL:
>>   brw_SEL(p, dst, src[0], src[1]);
>>   break;
>> +  case BRW_OPCODE_CSEL:
>> + brw_set_default_access_mode(p, BRW_ALIGN_16);
>> + brw_CSEL(p, dst, src[0], src[1], src[2]);
>> + brw_set_default_access_mode(p, BRW_ALIGN_1);
> 
> Setting the access mode to ALIGN_1 is not needed, right? It will
> continue with the next instruction in the loop that sets ALIGN1 at the
> beginning of the loop.

This was in Ken's original patch, so I'm not 100% sure.  I've seen this
pattern around generating some other instructions, so my gut tells me
that it's done like this to be explicit and more defensive.

> In any case,
> 
> Reviewed-by: Samuel Iglesias Gonsálvez 
> 
> Sam
> 
> 
>> + break;
>>case BRW_OPCODE_BFREV:
>>   assert(devinfo->gen >= 7);
>>   brw_BFREV(p, retype(dst, BRW_REGISTER_TYPE_UD),
> 




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

Re: [Mesa-dev] [PATCH] gallium: work around libtool relink issue for libdrm

[Emil Velikov]

On 5 March 2018 at 16:41, Roman Gilg  wrote:
> This is similar to commit 90633079. libtool links first to system directories
> instead of custom locations of libdrm on relinking. Since a more recent libdrm
> version than the one provided by the system is often needed when compiling
> mesa, make sure this works by putting libdrm in front.
>
> See also: https://bugs.freedesktop.org/show_bug.cgi?id=100259
>
> Signed-off-by: Roman Gilg 
> ---
>  src/gallium/targets/dri/Makefile.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/targets/dri/Makefile.am 
> b/src/gallium/targets/dri/Makefile.am
> index 1d05d91..509faff 100644
> --- a/src/gallium/targets/dri/Makefile.am
> +++ b/src/gallium/targets/dri/Makefile.am
> @@ -52,9 +52,9 @@ gallium_dri_la_LIBADD = \
> $(top_builddir)/src/gallium/drivers/rbug/librbug.la \
> $(top_builddir)/src/gallium/drivers/trace/libtrace.la \
> $(top_builddir)/src/mapi/shared-glapi/libglapi.la \
> +   $(LIBDRM_LIBS) \
> $(SELINUX_LIBS) \
> $(EXPAT_LIBS) \
> -   $(LIBDRM_LIBS) \
> $(GALLIUM_COMMON_LIB_DEPS)
>
It feels like a fragile workaround, although it will have no negative effects.
Hence - ship it ;-)

Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH 11/22 v2] nir: Recognize some more open-coded fmin / fmax

[Ian Romanick]

On 02/28/2018 12:48 PM, Jason Ekstrand wrote:
> Rb

For both or just this one?

> On Wed, Feb 28, 2018 at 12:18 PM, Ian Romanick  > wrote:
> 
> From: Ian Romanick  >
> 
> This transformation is inexact because section 4.7.1 (Range and
> Precision) says:
> 
>     Operations and built-in functions that operate on a NaN are not
>     required to return a NaN as the result.
> 
> The fmin or fmax might not return NaN in cases where the original
> expression would be required to return NaN.
> 
> v2: Reorder operands and mark as inexact.  The latter suggested by
> Jason.
> 
> shader-db results:
> 
> Haswell, Broadwell, and Skylake had similar results. (Skylake shown)
> total instructions in shared programs: 14514817 -> 14514808 (<.01%)
> instructions in affected programs: 229 -> 220 (-3.93%)
> helped: 3
> HURT: 0
> helped stats (abs) min: 1 max: 4 x̄: 3.00 x̃: 4
> helped stats (rel) min: 2.86% max: 4.12% x̄: 3.70% x̃: 4.12%
> 
> total cycles in shared programs: 533145211 -> 533144939 (<.01%)
> cycles in affected programs: 37268 -> 36996 (-0.73%)
> helped: 8
> HURT: 0
> helped stats (abs) min: 2 max: 134 x̄: 34.00 x̃: 2
> helped stats (rel) min: 0.02% max: 14.22% x̄: 3.53% x̃: 0.05%
> 
> Sandy Bridge and Ivy Bridge had similar results. (Ivy Bridge shown)
> total cycles in shared programs: 257618409 -> 257618403 (<.01%)
> cycles in affected programs: 12582 -> 12576 (-0.05%)
> helped: 3
> HURT: 0
> helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2
> helped stats (rel) min: 0.05% max: 0.05% x̄: 0.05% x̃: 0.05%
> 
> No changes on Iron Lake or GM45.
> 
> Signed-off-by: Ian Romanick  >
> ---
>  src/compiler/nir/nir_opt_algebraic.py | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/compiler/nir/nir_opt_algebraic.py
> b/src/compiler/nir/nir_opt_algebraic.py
> index d40d59b..17f4d9c 100644
> --- a/src/compiler/nir/nir_opt_algebraic.py
> +++ b/src/compiler/nir/nir_opt_algebraic.py
> @@ -170,6 +170,8 @@ optimizations = [
>     (('fge', ('fneg', ('fabs', a)), 0.0), ('feq', a, 0.0)),
>     (('bcsel', ('flt', b, a), b, a), ('fmin', a, b)),
>     (('bcsel', ('flt', a, b), b, a), ('fmax', a, b)),
> +   (('~bcsel', ('fge', a, b), b, a), ('fmin', a, b)),
> +   (('~bcsel', ('fge', b, a), b, a), ('fmax', a, b)),
>     (('bcsel', ('inot', a), b, c), ('bcsel', a, c, b)),
>     (('bcsel', a, ('bcsel', a, b, c), d), ('bcsel', a, b, d)),
>     (('bcsel', a, True, 'b@bool'), ('ior', a, b)),
> --
> 2.9.5
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> 
> 

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

Re: [Mesa-dev] [PATCH] st/mesa: ensure that images don't try to reference non-existent levels

[Ilia Mirkin]

The problem is that st_finalize_texture isn't doing its job in some
circumstances. Specifically, if I have a 2-level 2d array with level0
= (2,2,7) and level1 = (1,1,7) with a non-mipmap filter (e.g.
GL_NEAREST), then at no point are two resources combined into one.

Clamping the level will avoid the assert, but it's not the right thing
either since it'll still be passing in the wrong resource.

On Mon, Mar 5, 2018 at 2:05 PM, Marek Olšák  wrote:
> Maybe st/mesa should clamp the level instead of assert.
>
> Marek
>
> On Thu, Mar 1, 2018 at 7:23 AM, Ilia Mirkin  wrote:
>> Yes, as I mentioned this makes some tests assert.
>>
>> They were passing before, but it was through luck since the actual images
>> were never accessed.
>>
>> On Mar 1, 2018 04:04, "Timothy Arceri"  wrote:
>>>
>>> This causes the CTS tests to assert on radeonsi where they previously
>>> passed. If that expected?
>>>
>>> On 27/02/18 16:19, Ilia Mirkin wrote:

 Ideally the st_finalize_texture call would take care of that, but it
 doesn't seem to with KHR-GL45.shader_image_size.advanced-nonMS-*. This
 assertions makes sure that no such values are passed to the driver.

 Signed-off-by: Ilia Mirkin 
 ---

 This will trigger asserts in CTS, but I think that's better than feeding
 broken values to driver backends.

   src/mesa/state_tracker/st_atom_image.c | 1 +
   1 file changed, 1 insertion(+)

 diff --git a/src/mesa/state_tracker/st_atom_image.c
 b/src/mesa/state_tracker/st_atom_image.c
 index 1c4980173f4..421c926cf04 100644
 --- a/src/mesa/state_tracker/st_atom_image.c
 +++ b/src/mesa/state_tracker/st_atom_image.c
 @@ -97,6 +97,7 @@ st_convert_image(const struct st_context *st, const
 struct gl_image_unit *u,
   img->resource = stObj->pt;
 img->u.tex.level = u->Level + stObj->base.MinLevel;
 +  assert(img->u.tex.level <= img->resource->last_level);
 if (stObj->pt->target == PIPE_TEXTURE_3D) {
if (u->Layered) {
   img->u.tex.first_layer = 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] [RFC 0/6] Remove stubbed GLX_SGIX_swap_{barrier, group}

[Ian Romanick]

On 03/05/2018 10:48 AM, Emil Velikov wrote:
> Hi all,
> 
> It seems like these two extensions were never implemented or advertised.
> Be that in:
>  - glx/dri
>  - glx/apple
>  - classic xlib-glx
>  - gallium xlib-glx
> 
> Yet, the entry points were available, hence apps might have linked
> against it.

If an app was linking with an extension entry point instead of using
glXGetProcAddress, it is the app's bug.

> Furthermore I cannot see any users of those on my system and a courtesy 
> google search. Additionally the Nvidia driver (checked version 390.25) 
> does not implement/advertise them either.
> 
> That said, I'm fairly confident that we can safely remove the no-op 
> stubs. Even though that the entry points were statically exposed.
> 
> Brian, Ian,
> 
> Do you have any recollection about these experimental SGI extensions?

Ajax and I had talked about implementing swap_group a few times, but
there were some technical challenges that we were too lazy to tackle.  I
think that's about as far as any of it ever got.

> Thanks
> Emil
> 
> Cc: Ian Romanick 
> Cc: Brian Paul 
> 
> ___
> 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 RFC] radeonsi: Disable IEEE_MODE.

[Jan Vesely]

On Mon, 2018-03-05 at 10:04 +, Eric Engestrom wrote:
> On Saturday, 2018-03-03 18:35:02 -0500, Jan Vesely wrote:
> > Neither GL nor CL nor SPIRV needs the IEEE handling of sNaNs.
> > 
> > Signed-off-by: Jan Vesely 
> > ---
> > This is the 3rd way to handle broken fmin/fmax in clover CL.
> > It can be worked around in libclc (to not use
> > llvm.fminnum/llvm.fmaxnum)[0]
> > LLVM can be patched to not use IEEE_MODE[1]
> > Or it can be fixed in the config reg in mesa.
> > 
> > The third option is arguably the worst (changes semantics of compiled
> > code), but since the first two efforts have been stalled for months.
> > Here's the third one.
> > 
> > Jan
> > 
> > [0] 
> > http://lists.llvm.org/pipermail/libclc-dev/2017-November/thread.html#2692
> > [1] https://reviews.llvm.org/D40514
> > 
> > 
> >  src/gallium/drivers/radeonsi/si_compute.c | 8 
> >  src/gallium/drivers/radeonsi/si_shader.c  | 6 +-
> >  2 files changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
> > b/src/gallium/drivers/radeonsi/si_compute.c
> > index 41927988cf..d0fcba485b 100644
> > --- a/src/gallium/drivers/radeonsi/si_compute.c
> > +++ b/src/gallium/drivers/radeonsi/si_compute.c
> > @@ -70,6 +70,10 @@ static void code_object_to_config(const 
> > amd_kernel_code_t *code_object,
> >   struct si_shader_config *out_config) {
> >  
> > uint32_t rsrc1 = code_object->compute_pgm_resource_registers;
> > +   /* Disable IEEE mode. IEEE_MODE determines sNaN handling by fmin/fmax
> > +* instructions. Nothing wants the IEEE rules here.
> > +* Ideally LLVM would not emit this configuration. */
> > +   rsrc1 &= C_00B848_IEEE_MODE;
> 
> I don't know anything about this code, but this bit op looks odd to me;
> I would expect to see either:
>   rsrc1 &= ~C_00B848_IEEE_MODE;

C_00B848_IEEE_MODE is defined as 0xFF7F, so it's already bit-
negated.

Jan

> or:
>   rsrc1 |= C_00B848_IEEE_MODE;
> 
> > uint32_t rsrc2 = code_object->compute_pgm_resource_registers >> 32;
> > out_config->num_sgprs = code_object->wavefront_sgpr_count;
> > out_config->num_vgprs = code_object->workitem_vgpr_count;
> > @@ -137,6 +141,10 @@ static void si_create_compute_state_async(void *job, 
> > int thread_index)
> > S_00B848_SGPRS((shader->config.num_sgprs - 1) / 8) |
> > S_00B848_DX10_CLAMP(1) |
> > S_00B848_FLOAT_MODE(shader->config.float_mode);
> > +   /* Disable IEEE mode. IEEE_MODE determines sNaN handling by
> > +* fmin/fmax instructions. Nothing wants the IEEE rules.
> > +* Ideally LLVM would not emit this configuration. */
> > +   shader->config.rsrc1 &= C_00B848_IEEE_MODE;
> >  
> > shader->config.rsrc2 =
> > S_00B84C_USER_SGPR(user_sgprs) |
> > diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> > b/src/gallium/drivers/radeonsi/si_shader.c
> > index 2a50b266f6..01bad71a4e 100644
> > --- a/src/gallium/drivers/radeonsi/si_shader.c
> > +++ b/src/gallium/drivers/radeonsi/si_shader.c
> > @@ -5178,7 +5178,11 @@ void si_shader_binary_read_config(struct 
> > ac_shader_binary *binary,
> > conf->num_sgprs = MAX2(conf->num_sgprs, 
> > (G_00B028_SGPRS(value) + 1) * 8);
> > conf->num_vgprs = MAX2(conf->num_vgprs, 
> > (G_00B028_VGPRS(value) + 1) * 4);
> > conf->float_mode =  G_00B028_FLOAT_MODE(value);
> > -   conf->rsrc1 = value;
> > +   /* Disable IEEE mode. IEEE_MODE determines sNaN
> > +* handling by fmin/fmax instructions.
> > +* Nothing wants the IEEE rules here.
> > +* Ideally LLVM would not emit this configuration. */
> > +   conf->rsrc1 = value & C_00B848_IEEE_MODE;
> > break;
> > case R_00B02C_SPI_SHADER_PGM_RSRC2_PS:
> > conf->lds_size = MAX2(conf->lds_size, 
> > G_00B02C_EXTRA_LDS_SIZE(value));
> > -- 
> > 2.14.3
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH] st/mesa: ensure that images don't try to reference non-existent levels

[Marek Olšák]

Maybe st/mesa should clamp the level instead of assert.

Marek

On Thu, Mar 1, 2018 at 7:23 AM, Ilia Mirkin  wrote:
> Yes, as I mentioned this makes some tests assert.
>
> They were passing before, but it was through luck since the actual images
> were never accessed.
>
> On Mar 1, 2018 04:04, "Timothy Arceri"  wrote:
>>
>> This causes the CTS tests to assert on radeonsi where they previously
>> passed. If that expected?
>>
>> On 27/02/18 16:19, Ilia Mirkin wrote:
>>>
>>> Ideally the st_finalize_texture call would take care of that, but it
>>> doesn't seem to with KHR-GL45.shader_image_size.advanced-nonMS-*. This
>>> assertions makes sure that no such values are passed to the driver.
>>>
>>> Signed-off-by: Ilia Mirkin 
>>> ---
>>>
>>> This will trigger asserts in CTS, but I think that's better than feeding
>>> broken values to driver backends.
>>>
>>>   src/mesa/state_tracker/st_atom_image.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/src/mesa/state_tracker/st_atom_image.c
>>> b/src/mesa/state_tracker/st_atom_image.c
>>> index 1c4980173f4..421c926cf04 100644
>>> --- a/src/mesa/state_tracker/st_atom_image.c
>>> +++ b/src/mesa/state_tracker/st_atom_image.c
>>> @@ -97,6 +97,7 @@ st_convert_image(const struct st_context *st, const
>>> struct gl_image_unit *u,
>>>   img->resource = stObj->pt;
>>> img->u.tex.level = u->Level + stObj->base.MinLevel;
>>> +  assert(img->u.tex.level <= img->resource->last_level);
>>> if (stObj->pt->target == PIPE_TEXTURE_3D) {
>>>if (u->Layered) {
>>>   img->u.tex.first_layer = 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 11/29] intel/blorp: Include nir_format_convert.h in blorp_blit.c

[Pohjolainen, Topi]

On Fri, Jan 26, 2018 at 05:59:40PM -0800, Jason Ekstrand wrote:
> nir_mask_shift_or is now defined in nir_format_convert.h so we can
> delete the copy in blorp_blit.c.
> ---
>  src/intel/blorp/blorp_blit.c | 20 +---
>  1 file changed, 1 insertion(+), 19 deletions(-)

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> index 5cfc1a9..d54dd1e 100644
> --- a/src/intel/blorp/blorp_blit.c
> +++ b/src/intel/blorp/blorp_blit.c
> @@ -22,6 +22,7 @@
>   */
>  
>  #include "blorp_nir_builder.h"
> +#include "compiler/nir/nir_format_convert.h"
>  
>  #include "blorp_priv.h"
>  
> @@ -282,25 +283,6 @@ blorp_blit_txf_ms_mcs(nir_builder *b, struct 
> brw_blorp_blit_vars *v,
> return >dest.ssa;
>  }
>  
> -static nir_ssa_def *
> -nir_mask_shift_or(struct nir_builder *b, nir_ssa_def *dst, nir_ssa_def *src,
> -  uint32_t src_mask, int src_left_shift)
> -{
> -   nir_ssa_def *masked = nir_iand(b, src, nir_imm_int(b, src_mask));
> -
> -   nir_ssa_def *shifted;
> -   if (src_left_shift > 0) {
> -  shifted = nir_ishl(b, masked, nir_imm_int(b, src_left_shift));
> -   } else if (src_left_shift < 0) {
> -  shifted = nir_ushr(b, masked, nir_imm_int(b, -src_left_shift));
> -   } else {
> -  assert(src_left_shift == 0);
> -  shifted = masked;
> -   }
> -
> -   return nir_ior(b, dst, shifted);
> -}
> -
>  /**
>   * Emit code to compensate for the difference between Y and W tiling.
>   *
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/6] gallium/x11: remove empty GLX_SGIX_swap_group stubs

[Emil Velikov]

From: Emil Velikov 

The extension was never implemented. Quick search suggests:
 - no actual users (on my Arch setup)
 - the Nvidia driver does not implement the extension

Signed-off-by: Emil Velikov 
---
 src/gallium/state_trackers/glx/xlib/glx_api.c | 12 
 src/gallium/state_trackers/glx/xlib/glx_getproc.c |  3 ---
 2 files changed, 15 deletions(-)

diff --git a/src/gallium/state_trackers/glx/xlib/glx_api.c 
b/src/gallium/state_trackers/glx/xlib/glx_api.c
index 80bf3e5494f..3bd07c280d0 100644
--- a/src/gallium/state_trackers/glx/xlib/glx_api.c
+++ b/src/gallium/state_trackers/glx/xlib/glx_api.c
@@ -2647,18 +2647,6 @@ glXAssociateDMPbufferSGIX(Display *dpy, GLXPbufferSGIX 
pbuffer,
 #endif
 
 
-/*** GLX_SGIX_swap_group ***/
-
-PUBLIC void
-glXJoinSwapGroupSGIX(Display *dpy, GLXDrawable drawable, GLXDrawable member)
-{
-   (void) dpy;
-   (void) drawable;
-   (void) member;
-}
-
-
-
 /*** GLX_SUN_get_transparent_index ***/
 
 PUBLIC Status
diff --git a/src/gallium/state_trackers/glx/xlib/glx_getproc.c 
b/src/gallium/state_trackers/glx/xlib/glx_getproc.c
index 71d3ad8c8a7..58b476341db 100644
--- a/src/gallium/state_trackers/glx/xlib/glx_getproc.c
+++ b/src/gallium/state_trackers/glx/xlib/glx_getproc.c
@@ -147,9 +147,6 @@ static struct name_address_pair GLX_functions[] = {
{ "glXAssociateDMPbufferSGIX", (__GLXextFuncPtr) glXAssociateDMPbufferSGIX 
},
 #endif
 
-   /*** GLX_SGIX_swap_group ***/
-   { "glXJoinSwapGroupSGIX", (__GLXextFuncPtr) glXJoinSwapGroupSGIX },
-
/*** GLX_SUN_get_transparent_index ***/
{ "glXGetTransparentIndexSUN", (__GLXextFuncPtr) glXGetTransparentIndexSUN 
},
 
-- 
2.16.0

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

[Mesa-dev] [PATCH 6/6] glx: remove empty GLX_SGIX_swap_group stubs

[Emil Velikov]

From: Emil Velikov 

The extension was never implemented. Quick search suggests:
 - no actual users (on my Arch setup)
 - the Nvidia driver does not implement the extension

Signed-off-by: Emil Velikov 
---
 src/glx/apple/glx_empty.c | 12 
 src/glx/glxcmds.c | 16 
 src/glx/glxextensions.c   |  1 -
 src/glx/glxextensions.h   |  1 -
 4 files changed, 30 deletions(-)

diff --git a/src/glx/apple/glx_empty.c b/src/glx/apple/glx_empty.c
index 427c3a59356..b7afbce7dd5 100644
--- a/src/glx/apple/glx_empty.c
+++ b/src/glx/apple/glx_empty.c
@@ -49,18 +49,6 @@ glXWaitVideoSyncSGI(int divisor, int remainder, unsigned int 
*count)
 }
 
 
-/*
-** GLX_SGIX_swap_group
-*/
-void
-glXJoinSwapGroupSGIX(Display * dpy, GLXDrawable drawable, GLXDrawable member)
-{
-   (void) dpy;
-   (void) drawable;
-   (void) member;
-}
-
-
 /*
 ** GLX_OML_sync_control
 */
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 57af039d1be..949c2a59314 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -2036,19 +2036,6 @@ glXGetFBConfigFromVisualSGIX(Display * dpy, XVisualInfo 
* vis)
 }
 
 #ifndef GLX_USE_APPLEGL
-/*
-** GLX_SGIX_swap_group
-*/
-static void
-__glXJoinSwapGroupSGIX(Display * dpy, GLXDrawable drawable,
-   GLXDrawable member)
-{
-   (void) dpy;
-   (void) drawable;
-   (void) member;
-}
-
-
 /*
 ** GLX_OML_sync_control
 */
@@ -2520,9 +2507,6 @@ static const struct name_address_pair GLX_functions[] = {
GLX_FUNCTION(glXSelectEventSGIX),
GLX_FUNCTION(glXGetSelectedEventSGIX),
 
-   /*** GLX_SGIX_swap_group ***/
-   GLX_FUNCTION2(glXJoinSwapGroupSGIX, __glXJoinSwapGroupSGIX),
-
/*** GLX_MESA_copy_sub_buffer ***/
GLX_FUNCTION2(glXCopySubBufferMESA, __glXCopySubBufferMESA),
 
diff --git a/src/glx/glxextensions.c b/src/glx/glxextensions.c
index de015f25464..a575862670f 100644
--- a/src/glx/glxextensions.c
+++ b/src/glx/glxextensions.c
@@ -161,7 +161,6 @@ static const struct extension_info known_glx_extensions[] = 
{
{ GLX(SGIS_multisample),VER(0,0), Y, Y, N, N },
{ GLX(SGIX_fbconfig),   VER(1,3), Y, Y, N, N },
{ GLX(SGIX_pbuffer),VER(1,3), Y, Y, N, N },
-   { GLX(SGIX_swap_group), VER(0,0), N, N, N, N },
{ GLX(SGIX_visual_select_group),VER(0,0), Y, Y, N, N },
{ GLX(SGI_make_current_read),   VER(1,3), Y, N, N, N },
{ GLX(SGI_swap_control),VER(0,0), Y, N, N, N },
diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
index 0af28a2dde1..c6428d46b4d 100644
--- a/src/glx/glxextensions.h
+++ b/src/glx/glxextensions.h
@@ -67,7 +67,6 @@ enum
SGIS_multisample_bit,
SGIX_fbconfig_bit,
SGIX_pbuffer_bit,
-   SGIX_swap_group_bit,
SGIX_visual_select_group_bit,
SGI_make_current_read_bit,
SGI_swap_control_bit,
-- 
2.16.0

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

[Mesa-dev] [PATCH 1/6] x11: remove empty GLX_SGIX_swap_barrier stubs

[Emil Velikov]

From: Emil Velikov 

The extension was never implemented. Quick search suggests:
 - no actual users (on my Arch setup)
 - the Nvidia driver does not implement the extension

Signed-off-by: Emil Velikov 
---
 src/mesa/drivers/x11/fakeglx.c | 25 -
 src/mesa/drivers/x11/glxapi.c  | 28 
 src/mesa/drivers/x11/glxapi.h  |  4 
 3 files changed, 57 deletions(-)

diff --git a/src/mesa/drivers/x11/fakeglx.c b/src/mesa/drivers/x11/fakeglx.c
index 42c48264bab..c49178b9afa 100644
--- a/src/mesa/drivers/x11/fakeglx.c
+++ b/src/mesa/drivers/x11/fakeglx.c
@@ -2695,27 +2695,6 @@ Fake_glXJoinSwapGroupSGIX(Display *dpy, GLXDrawable 
drawable, GLXDrawable member
 
 
 
-/*** GLX_SGIX_swap_barrier ***/
-
-static void
-Fake_glXBindSwapBarrierSGIX(Display *dpy, GLXDrawable drawable, int barrier)
-{
-   (void) dpy;
-   (void) drawable;
-   (void) barrier;
-}
-
-static Bool
-Fake_glXQueryMaxSwapBarriersSGIX(Display *dpy, int screen, int *max)
-{
-   (void) dpy;
-   (void) screen;
-   (void) max;
-   return False;
-}
-
-
-
 /*** GLX_SUN_get_transparent_index ***/
 
 static Status
@@ -2959,10 +2938,6 @@ _mesa_GetGLXDispatchTable(void)
/*** GLX_SGIX_swap_group ***/
glx.JoinSwapGroupSGIX = Fake_glXJoinSwapGroupSGIX;
 
-   /*** GLX_SGIX_swap_barrier ***/
-   glx.BindSwapBarrierSGIX = Fake_glXBindSwapBarrierSGIX;
-   glx.QueryMaxSwapBarriersSGIX = Fake_glXQueryMaxSwapBarriersSGIX;
-
/*** GLX_SUN_get_transparent_index ***/
glx.GetTransparentIndexSUN = Fake_glXGetTransparentIndexSUN;
 
diff --git a/src/mesa/drivers/x11/glxapi.c b/src/mesa/drivers/x11/glxapi.c
index 5017546c7e3..637c6ae3caf 100644
--- a/src/mesa/drivers/x11/glxapi.c
+++ b/src/mesa/drivers/x11/glxapi.c
@@ -923,30 +923,6 @@ glXJoinSwapGroupSGIX(Display *dpy, GLXDrawable drawable, 
GLXDrawable member)
 }
 
 
-/*** GLX_SGIX_swap_barrier ***/
-
-void PUBLIC
-glXBindSwapBarrierSGIX(Display *dpy, GLXDrawable drawable, int barrier)
-{
-   struct _glxapi_table *t;
-   GET_DISPATCH(dpy, t);
-   if (!t)
-  return;
-   t->BindSwapBarrierSGIX(dpy, drawable, barrier);
-}
-
-Bool PUBLIC
-glXQueryMaxSwapBarriersSGIX(Display *dpy, int screen, int *max)
-{
-   struct _glxapi_table *t;
-   GET_DISPATCH(dpy, t);
-   if (!t)
-  return False;
-   return t->QueryMaxSwapBarriersSGIX(dpy, screen, max);
-}
-
-
-
 /*** GLX_SUN_get_transparent_index ***/
 
 Status PUBLIC
@@ -1204,10 +1180,6 @@ static struct name_address_pair GLX_functions[] = {
/*** GLX_SGIX_swap_group ***/
{ "glXJoinSwapGroupSGIX", (__GLXextFuncPtr) glXJoinSwapGroupSGIX },
 
-   /*** GLX_SGIX_swap_barrier ***/
-   { "glXBindSwapBarrierSGIX", (__GLXextFuncPtr) glXBindSwapBarrierSGIX },
-   { "glXQueryMaxSwapBarriersSGIX", (__GLXextFuncPtr) 
glXQueryMaxSwapBarriersSGIX },
-
/*** GLX_SUN_get_transparent_index ***/
{ "glXGetTransparentIndexSUN", (__GLXextFuncPtr) glXGetTransparentIndexSUN 
},
 
diff --git a/src/mesa/drivers/x11/glxapi.h b/src/mesa/drivers/x11/glxapi.h
index 7bccc50aa78..4f3087cac7a 100644
--- a/src/mesa/drivers/x11/glxapi.h
+++ b/src/mesa/drivers/x11/glxapi.h
@@ -167,10 +167,6 @@ struct _glxapi_table {
/*** GLX_SGIX_swap_group ***/
void (*JoinSwapGroupSGIX)(Display *, GLXDrawable, GLXDrawable);
 
-   /*** GLX_SGIX_swap_barrier ***/
-   void (*BindSwapBarrierSGIX)(Display *, GLXDrawable, int);
-   Bool (*QueryMaxSwapBarriersSGIX)(Display *, int, int *);
-
/*** GLX_SUN_get_transparent_index ***/
Status (*GetTransparentIndexSUN)(Display *, Window, Window, long *);
 
-- 
2.16.0

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

[Mesa-dev] [PATCH 2/6] gallium/x11: remove empty GLX_SGIX_swap_barrier stubs

[Emil Velikov]

From: Emil Velikov 

The extension was never implemented. Quick search suggests:
 - no actual users (on my Arch setup)
 - the Nvidia driver does not implement the extension

Signed-off-by: Emil Velikov 
---
 src/gallium/state_trackers/glx/xlib/glx_api.c | 21 -
 src/gallium/state_trackers/glx/xlib/glx_getproc.c |  4 
 2 files changed, 25 deletions(-)

diff --git a/src/gallium/state_trackers/glx/xlib/glx_api.c 
b/src/gallium/state_trackers/glx/xlib/glx_api.c
index 6ec3a31d5fc..80bf3e5494f 100644
--- a/src/gallium/state_trackers/glx/xlib/glx_api.c
+++ b/src/gallium/state_trackers/glx/xlib/glx_api.c
@@ -2659,27 +2659,6 @@ glXJoinSwapGroupSGIX(Display *dpy, GLXDrawable drawable, 
GLXDrawable member)
 
 
 
-/*** GLX_SGIX_swap_barrier ***/
-
-PUBLIC void
-glXBindSwapBarrierSGIX(Display *dpy, GLXDrawable drawable, int barrier)
-{
-   (void) dpy;
-   (void) drawable;
-   (void) barrier;
-}
-
-PUBLIC Bool
-glXQueryMaxSwapBarriersSGIX(Display *dpy, int screen, int *max)
-{
-   (void) dpy;
-   (void) screen;
-   (void) max;
-   return False;
-}
-
-
-
 /*** GLX_SUN_get_transparent_index ***/
 
 PUBLIC Status
diff --git a/src/gallium/state_trackers/glx/xlib/glx_getproc.c 
b/src/gallium/state_trackers/glx/xlib/glx_getproc.c
index e7564ad9cde..71d3ad8c8a7 100644
--- a/src/gallium/state_trackers/glx/xlib/glx_getproc.c
+++ b/src/gallium/state_trackers/glx/xlib/glx_getproc.c
@@ -150,10 +150,6 @@ static struct name_address_pair GLX_functions[] = {
/*** GLX_SGIX_swap_group ***/
{ "glXJoinSwapGroupSGIX", (__GLXextFuncPtr) glXJoinSwapGroupSGIX },
 
-   /*** GLX_SGIX_swap_barrier ***/
-   { "glXBindSwapBarrierSGIX", (__GLXextFuncPtr) glXBindSwapBarrierSGIX },
-   { "glXQueryMaxSwapBarriersSGIX", (__GLXextFuncPtr) 
glXQueryMaxSwapBarriersSGIX },
-
/*** GLX_SUN_get_transparent_index ***/
{ "glXGetTransparentIndexSUN", (__GLXextFuncPtr) glXGetTransparentIndexSUN 
},
 
-- 
2.16.0

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

[Mesa-dev] [PATCH 3/6] glx: remove empty GLX_SGIX_swap_barrier stubs

[Emil Velikov]

From: Emil Velikov 

The extension was never implemented. Quick search suggests:
 - no actual users (on my Arch setup)
 - the Nvidia driver does not implement the extension

Signed-off-by: Emil Velikov 
---
 src/glx/apple/glx_empty.c | 21 -
 src/glx/glxcmds.c | 25 -
 src/glx/glxextensions.c   |  1 -
 src/glx/glxextensions.h   |  1 -
 4 files changed, 48 deletions(-)

diff --git a/src/glx/apple/glx_empty.c b/src/glx/apple/glx_empty.c
index 33fffb5f61c..427c3a59356 100644
--- a/src/glx/apple/glx_empty.c
+++ b/src/glx/apple/glx_empty.c
@@ -61,27 +61,6 @@ glXJoinSwapGroupSGIX(Display * dpy, GLXDrawable drawable, 
GLXDrawable member)
 }
 
 
-/*
-** GLX_SGIX_swap_barrier
-*/
-void
-glXBindSwapBarrierSGIX(Display * dpy, GLXDrawable drawable, int barrier)
-{
-   (void) dpy;
-   (void) drawable;
-   (void) barrier;
-}
-
-Bool
-glXQueryMaxSwapBarriersSGIX(Display * dpy, int screen, int *max)
-{
-   (void) dpy;
-   (void) screen;
-   (void) max;
-   return False;
-}
-
-
 /*
 ** GLX_OML_sync_control
 */
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 943b81754f3..57af039d1be 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -2049,27 +2049,6 @@ __glXJoinSwapGroupSGIX(Display * dpy, GLXDrawable 
drawable,
 }
 
 
-/*
-** GLX_SGIX_swap_barrier
-*/
-static void
-__glXBindSwapBarrierSGIX(Display * dpy, GLXDrawable drawable, int barrier)
-{
-   (void) dpy;
-   (void) drawable;
-   (void) barrier;
-}
-
-static Bool
-__glXQueryMaxSwapBarriersSGIX(Display * dpy, int screen, int *max)
-{
-   (void) dpy;
-   (void) screen;
-   (void) max;
-   return False;
-}
-
-
 /*
 ** GLX_OML_sync_control
 */
@@ -2544,10 +2523,6 @@ static const struct name_address_pair GLX_functions[] = {
/*** GLX_SGIX_swap_group ***/
GLX_FUNCTION2(glXJoinSwapGroupSGIX, __glXJoinSwapGroupSGIX),
 
-   /*** GLX_SGIX_swap_barrier ***/
-   GLX_FUNCTION2(glXBindSwapBarrierSGIX, __glXBindSwapBarrierSGIX),
-   GLX_FUNCTION2(glXQueryMaxSwapBarriersSGIX, __glXQueryMaxSwapBarriersSGIX),
-
/*** GLX_MESA_copy_sub_buffer ***/
GLX_FUNCTION2(glXCopySubBufferMESA, __glXCopySubBufferMESA),
 
diff --git a/src/glx/glxextensions.c b/src/glx/glxextensions.c
index af6ffbf6600..de015f25464 100644
--- a/src/glx/glxextensions.c
+++ b/src/glx/glxextensions.c
@@ -161,7 +161,6 @@ static const struct extension_info known_glx_extensions[] = 
{
{ GLX(SGIS_multisample),VER(0,0), Y, Y, N, N },
{ GLX(SGIX_fbconfig),   VER(1,3), Y, Y, N, N },
{ GLX(SGIX_pbuffer),VER(1,3), Y, Y, N, N },
-   { GLX(SGIX_swap_barrier),   VER(0,0), N, N, N, N },
{ GLX(SGIX_swap_group), VER(0,0), N, N, N, N },
{ GLX(SGIX_visual_select_group),VER(0,0), Y, Y, N, N },
{ GLX(SGI_make_current_read),   VER(1,3), Y, N, N, N },
diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
index d73128bd0ea..0af28a2dde1 100644
--- a/src/glx/glxextensions.h
+++ b/src/glx/glxextensions.h
@@ -67,7 +67,6 @@ enum
SGIS_multisample_bit,
SGIX_fbconfig_bit,
SGIX_pbuffer_bit,
-   SGIX_swap_barrier_bit,
SGIX_swap_group_bit,
SGIX_visual_select_group_bit,
SGI_make_current_read_bit,
-- 
2.16.0

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

[Mesa-dev] [PATCH 4/6] x11: remove empty GLX_SGIX_swap_group stubs

[Emil Velikov]

From: Emil Velikov 

The extension was never implemented. Quick search suggests:
 - no actual users (on my Arch setup)
 - the Nvidia driver does not implement the extension

Signed-off-by: Emil Velikov 
---
 src/mesa/drivers/x11/fakeglx.c | 15 ---
 src/mesa/drivers/x11/glxapi.c  | 16 
 src/mesa/drivers/x11/glxapi.h  |  3 ---
 3 files changed, 34 deletions(-)

diff --git a/src/mesa/drivers/x11/fakeglx.c b/src/mesa/drivers/x11/fakeglx.c
index c49178b9afa..233b6e254fe 100644
--- a/src/mesa/drivers/x11/fakeglx.c
+++ b/src/mesa/drivers/x11/fakeglx.c
@@ -2683,18 +2683,6 @@ Fake_glXAssociateDMPbufferSGIX(Display *dpy, 
GLXPbufferSGIX pbuffer, DMparams *p
 #endif
 
 
-/*** GLX_SGIX_swap_group ***/
-
-static void
-Fake_glXJoinSwapGroupSGIX(Display *dpy, GLXDrawable drawable, GLXDrawable 
member)
-{
-   (void) dpy;
-   (void) drawable;
-   (void) member;
-}
-
-
-
 /*** GLX_SUN_get_transparent_index ***/
 
 static Status
@@ -2935,9 +2923,6 @@ _mesa_GetGLXDispatchTable(void)
glx.AssociateDMPbufferSGIX = NULL;
 #endif
 
-   /*** GLX_SGIX_swap_group ***/
-   glx.JoinSwapGroupSGIX = Fake_glXJoinSwapGroupSGIX;
-
/*** GLX_SUN_get_transparent_index ***/
glx.GetTransparentIndexSUN = Fake_glXGetTransparentIndexSUN;
 
diff --git a/src/mesa/drivers/x11/glxapi.c b/src/mesa/drivers/x11/glxapi.c
index 637c6ae3caf..f112c8ab090 100644
--- a/src/mesa/drivers/x11/glxapi.c
+++ b/src/mesa/drivers/x11/glxapi.c
@@ -910,19 +910,6 @@ glXAssociateDMPbufferSGIX(Display *dpy, GLXPbufferSGIX 
pbuffer, DMparams *params
 #endif
 
 
-/*** GLX_SGIX_swap_group ***/
-
-void PUBLIC
-glXJoinSwapGroupSGIX(Display *dpy, GLXDrawable drawable, GLXDrawable member)
-{
-   struct _glxapi_table *t;
-   GET_DISPATCH(dpy, t);
-   if (!t)
-  return;
-   t->JoinSwapGroupSGIX(dpy, drawable, member);
-}
-
-
 /*** GLX_SUN_get_transparent_index ***/
 
 Status PUBLIC
@@ -1177,9 +1164,6 @@ static struct name_address_pair GLX_functions[] = {
{ "glXAssociateDMPbufferSGIX", (__GLXextFuncPtr) glXAssociateDMPbufferSGIX 
},
 #endif
 
-   /*** GLX_SGIX_swap_group ***/
-   { "glXJoinSwapGroupSGIX", (__GLXextFuncPtr) glXJoinSwapGroupSGIX },
-
/*** GLX_SUN_get_transparent_index ***/
{ "glXGetTransparentIndexSUN", (__GLXextFuncPtr) glXGetTransparentIndexSUN 
},
 
diff --git a/src/mesa/drivers/x11/glxapi.h b/src/mesa/drivers/x11/glxapi.h
index 4f3087cac7a..03af158afae 100644
--- a/src/mesa/drivers/x11/glxapi.h
+++ b/src/mesa/drivers/x11/glxapi.h
@@ -164,9 +164,6 @@ struct _glxapi_table {
void *AssociciateDMPbufferSGIX;
 #endif
 
-   /*** GLX_SGIX_swap_group ***/
-   void (*JoinSwapGroupSGIX)(Display *, GLXDrawable, GLXDrawable);
-
/*** GLX_SUN_get_transparent_index ***/
Status (*GetTransparentIndexSUN)(Display *, Window, Window, long *);
 
-- 
2.16.0

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

[Mesa-dev] [RFC 0/6] Remove stubbed GLX_SGIX_swap_{barrier,group}

[Emil Velikov]

Hi all,

It seems like these two extensions were never implemented or advertised.
Be that in:
 - glx/dri
 - glx/apple
 - classic xlib-glx
 - gallium xlib-glx

Yet, the entry points were available, hence apps might have linked
against it.

Furthermore I cannot see any users of those on my system and a courtesy 
google search. Additionally the Nvidia driver (checked version 390.25) 
does not implement/advertise them either.

That said, I'm fairly confident that we can safely remove the no-op 
stubs. Even though that the entry points were statically exposed.

Brian, Ian,

Do you have any recollection about these experimental SGI extensions?

Thanks
Emil

Cc: Ian Romanick 
Cc: Brian Paul 


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

Re: [Mesa-dev] [PATCH 10/29] nir/format_convert: Add a function to pack RGB9_E5 formats

[Pohjolainen, Topi]

On Fri, Jan 26, 2018 at 05:59:39PM -0800, Jason Ekstrand wrote:
> ---
>  src/compiler/nir/nir_format_convert.h | 64 
> +++
>  1 file changed, 64 insertions(+)

I didn't check against any specs but this looks to match
format_rgb9e5.h::float3_to_rgb9e5().

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/compiler/nir/nir_format_convert.h 
> b/src/compiler/nir/nir_format_convert.h
> index 0ffd0db..479191e 100644
> --- a/src/compiler/nir/nir_format_convert.h
> +++ b/src/compiler/nir/nir_format_convert.h
> @@ -23,6 +23,8 @@
>  
>  #include "nir_builder.h"
>  
> +#include "util/format_rgb9e5.h"
> +
>  static inline nir_ssa_def *
>  nir_shift(nir_builder *b, nir_ssa_def *value, int left_shift)
>  {
> @@ -168,3 +170,65 @@ nir_format_pack_r11g11b10f(nir_builder *b, nir_ssa_def 
> *color)
>  
> return packed;
>  }
> +
> +static inline nir_ssa_def *
> +nir_format_pack_r9g9b9e5(nir_builder *b, nir_ssa_def *color)
> +{
> +   /* See also float3_to_rgb9e5 */
> +
> +   /* First, we need to clamp it to range. */
> +   nir_ssa_def *clamped = nir_fmin(b, color, nir_imm_float(b, MAX_RGB9E5));
> +
> +   /* Get rid of negatives and NaN */
> +   clamped = nir_bcsel(b, nir_ult(b, nir_imm_int(b, 0x7f80), color),
> +  nir_imm_float(b, 0), clamped);
> +
> +   /* maxrgb.u = MAX3(rc.u, gc.u, bc.u); */
> +   nir_ssa_def *maxu = nir_umax(b, nir_channel(b, clamped, 0),
> +   nir_umax(b, nir_channel(b, clamped, 1),
> +   nir_channel(b, clamped, 2)));
> +
> +   /* maxrgb.u += maxrgb.u & (1 << (23-9)); */
> +   maxu = nir_iadd(b, maxu, nir_iand(b, maxu, nir_imm_int(b, 1 << 14)));
> +
> +   /* exp_shared = MAX2((maxrgb.u >> 23), -RGB9E5_EXP_BIAS - 1 + 127) +
> +*  1 + RGB9E5_EXP_BIAS - 127;
> +*/
> +   nir_ssa_def *exp_shared =
> +  nir_iadd(b, nir_umax(b, nir_ushr(b, maxu, nir_imm_int(b, 23)),
> +  nir_imm_int(b, -RGB9E5_EXP_BIAS - 1 + 127)),
> +  nir_imm_int(b, 1 + RGB9E5_EXP_BIAS - 127));
> +
> +   /* revdenom_biasedexp = 127 - (exp_shared - RGB9E5_EXP_BIAS -
> +* RGB9E5_MANTISSA_BITS) + 1;
> +*/
> +   nir_ssa_def *revdenom_biasedexp =
> +  nir_isub(b, nir_imm_int(b, 127 + RGB9E5_EXP_BIAS +
> + RGB9E5_MANTISSA_BITS + 1),
> +  exp_shared);
> +
> +   /* revdenom.u = revdenom_biasedexp << 23; */
> +   nir_ssa_def *revdenom =
> +  nir_ishl(b, revdenom_biasedexp, nir_imm_int(b, 23));
> +
> +   /* rm = (int) (rc.f * revdenom.f);
> +* gm = (int) (gc.f * revdenom.f);
> +* bm = (int) (bc.f * revdenom.f);
> +*/
> +   nir_ssa_def *mantissa =
> +  nir_f2i32(b, nir_fmul(b, clamped, revdenom));
> +
> +   /* rm = (rm & 1) + (rm >> 1);
> +* gm = (gm & 1) + (gm >> 1);
> +* bm = (bm & 1) + (bm >> 1);
> +*/
> +   mantissa = nir_iadd(b, nir_iand(b, mantissa, nir_imm_int(b, 1)),
> +  nir_ushr(b, mantissa, nir_imm_int(b, 1)));
> +
> +   nir_ssa_def *packed = nir_channel(b, mantissa, 0);
> +   packed = nir_mask_shift_or(b, packed, nir_channel(b, mantissa, 1), ~0, 9);
> +   packed = nir_mask_shift_or(b, packed, nir_channel(b, mantissa, 2), ~0, 
> 18);
> +   packed = nir_mask_shift_or(b, packed, exp_shared, ~0, 27);
> +
> +   return packed;
> +}
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 100259] [EGL] [GBM] undefined reference to `gbm_bo_create_with_modifiers'

[bugzilla-daemon]

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

--- Comment #25 from Roman Gilg  ---
I "necro-bumped" this bug because I wanted to share my findings in regards to
the manual manipulation of the relink_command, what I haven't seen here before.

Maybe that's trivial to you, but implying that I'm just someone who "starts
building stuff and doesn't know how to manage multiple copies on their system"
is not very nice of you.

Also I thought it's a bug in Libtool, so why are missing abilities in regards
to building stuff to blame now?

Fact is if you today try to build mesa AMD DRI libs on Ubuntu 16.04 together
with libdrm as described in the documentation in some non-system paths your
install will fail. So why this bug is labeled NOTABUG and not at least
NOTOURBUG is another question.

Anyways I will not disrupt the peace of this bug report anymore. Sorry for the
inconvenience.

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

Re: [Mesa-dev] [PATCH v3] clover: Allow overriding platform/device version numbers

[Pierre Moreau]

With Francisco’s comments addressed,

Reviewed-by: Pierre Moreau 

On 2018-03-04 — 09:13, Aaron Watry wrote:
> Useful for testing API, builtin library, and device completeness of
> not-yet-supported versions.
> 
> Signed-off-by: Aaron Watry 
> (v1) Reviewed-by: Pierre Moreau 
> (v2) Reviewed-by: Francisco Jerez 
> Cc: Jan Vesely 
> Cc: Emil Velikov 
> 
> v3: mark CL version overrides as static and const
> v2: Make version_string in platform const in case
> ---
> Emil, hopefully this is along the lines of what you wanted.
> 
> I believe that function-scoped static const variables are only 
> evaluated/initialized once.
> 
> --Aaron
> 
>  src/gallium/state_trackers/clover/api/platform.cpp | 10 +++---
>  src/gallium/state_trackers/clover/core/device.cpp  |  9 +++--
>  2 files changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/clover/api/platform.cpp 
> b/src/gallium/state_trackers/clover/api/platform.cpp
> index ed86163311..23e524a630 100644
> --- a/src/gallium/state_trackers/clover/api/platform.cpp
> +++ b/src/gallium/state_trackers/clover/api/platform.cpp
> @@ -23,6 +23,7 @@
>  #include "api/util.hpp"
>  #include "core/platform.hpp"
>  #include "git_sha1.h"
> +#include "util/u_debug.h"
>  
>  using namespace clover;
>  
> @@ -57,14 +58,17 @@ clover::GetPlatformInfo(cl_platform_id d_platform, 
> cl_platform_info param,
>buf.as_string() = "FULL_PROFILE";
>break;
>  
> -   case CL_PLATFORM_VERSION:
> -  buf.as_string() = "OpenCL 1.1 Mesa " PACKAGE_VERSION
> +   case CL_PLATFORM_VERSION: {
> +  static const std::string version_string = std::string(
> +debug_get_option("CLOVER_PLATFORM_VERSION_OVERRIDE", "1.1"));
> +
> +  buf.as_string() = "OpenCL " + version_string + " Mesa " PACKAGE_VERSION
>  #ifdef MESA_GIT_SHA1
>  " (" MESA_GIT_SHA1 ")"
>  #endif
>  ;
>break;
> -
> +   }
> case CL_PLATFORM_NAME:
>buf.as_string() = "Clover";
>break;
> diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
> b/src/gallium/state_trackers/clover/core/device.cpp
> index 71cf4bf60a..b3a3903bcd 100644
> --- a/src/gallium/state_trackers/clover/core/device.cpp
> +++ b/src/gallium/state_trackers/clover/core/device.cpp
> @@ -25,6 +25,7 @@
>  #include "core/platform.hpp"
>  #include "pipe/p_screen.h"
>  #include "pipe/p_state.h"
> +#include "util/u_debug.h"
>  
>  using namespace clover;
>  
> @@ -268,10 +269,14 @@ device::endianness() const {
>  
>  std::string
>  device::device_version() const {
> -return "1.1";
> +   static const std::string device_version = std::string(
> + debug_get_option("CLOVER_DEVICE_VERSION_OVERRIDE", "1.1"));
> +   return device_version;
>  }
>  
>  std::string
>  device::device_clc_version() const {
> -return "1.1";
> +   static const std::string device_clc_version = std::string(
> + debug_get_option("CLOVER_DEVICE_CLC_VERSION_OVERRIDE", "1.1"));
> +   return device_clc_version;
>  }
> -- 
> 2.14.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [PATCH] configure: remove unused AM_CONDITIONAL

[Emil Velikov]

From: Emil Velikov 

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

diff --git a/configure.ac b/configure.ac
index d8093597dd0..0cfb0f7d851 100644
--- a/configure.ac
+++ b/configure.ac
@@ -451,7 +451,6 @@ if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" = x1; then
 LIBATOMIC_LIBS="-latomic"
 fi
 fi
-AM_CONDITIONAL([GCC_ATOMIC_BUILTINS_SUPPORTED], [test 
x$GCC_ATOMIC_BUILTINS_SUPPORTED = x1])
 AC_SUBST([LIBATOMIC_LIBS])
 
 dnl Check if host supports 64-bit atomics
-- 
2.16.0

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

Re: [Mesa-dev] [PATCH] travis: keep meson version below 0.45.0

[Dylan Baker]

Quoting Andres Gomez (2018-03-05 07:25:36)
> Recently Meson upgraded to 0.45.0 and it needs python 3.5+, which is
> not available in Trusty.
> 
> Cc: Eric Engestrom 
> Cc: Dylan Baker 
> Cc: Emil Velikov 
> Cc: Jon Turney 
> Signed-off-by: Andres Gomez 
> ---
>  .travis.yml | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 823111ca539..dcd150b482b 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -460,10 +460,11 @@ before_install:
>  install:
>- pip2 install --user mako
>  
> -  # Install the latest meson from pip, since the version in the ubuntu repos 
> is
> -  # often quite old.
> +  # Install a more modern meson from pip, since the version in the
> +  # ubuntu repos is often quite old. Avoid >=0.45.0 as it needs python
> +  # 3.5+
>- if test "x$BUILD" = xmeson; then
> -  pip3 install --user meson;
> +  pip3 install --user "meson<0.45.0";
>  fi
>  
># Since libdrm gets updated in configure.ac regularly, try to pick up the
> -- 
> 2.16.1
> 

Reviewed-by: Dylan Baker 


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

Re: [Mesa-dev] [PATCH v3] clover: Allow overriding platform/device version numbers

[Francisco Jerez]

Aaron Watry  writes:

> Useful for testing API, builtin library, and device completeness of
> not-yet-supported versions.
>
> Signed-off-by: Aaron Watry 
> (v1) Reviewed-by: Pierre Moreau 
> (v2) Reviewed-by: Francisco Jerez 
> Cc: Jan Vesely 
> Cc: Emil Velikov 
>
> v3: mark CL version overrides as static and const
> v2: Make version_string in platform const in case
> ---
> Emil, hopefully this is along the lines of what you wanted.
>
> I believe that function-scoped static const variables are only 
> evaluated/initialized once.
>
> --Aaron
>
>  src/gallium/state_trackers/clover/api/platform.cpp | 10 +++---
>  src/gallium/state_trackers/clover/core/device.cpp  |  9 +++--
>  2 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/platform.cpp 
> b/src/gallium/state_trackers/clover/api/platform.cpp
> index ed86163311..23e524a630 100644
> --- a/src/gallium/state_trackers/clover/api/platform.cpp
> +++ b/src/gallium/state_trackers/clover/api/platform.cpp
> @@ -23,6 +23,7 @@
>  #include "api/util.hpp"
>  #include "core/platform.hpp"
>  #include "git_sha1.h"
> +#include "util/u_debug.h"
>  
>  using namespace clover;
>  
> @@ -57,14 +58,17 @@ clover::GetPlatformInfo(cl_platform_id d_platform, 
> cl_platform_info param,
>buf.as_string() = "FULL_PROFILE";
>break;
>  
> -   case CL_PLATFORM_VERSION:
> -  buf.as_string() = "OpenCL 1.1 Mesa " PACKAGE_VERSION
> +   case CL_PLATFORM_VERSION: {
> +  static const std::string version_string = std::string(

The std::string() conversions here and below are redundant, with them
removed:

Reviewed-by: Francisco Jerez 

> +debug_get_option("CLOVER_PLATFORM_VERSION_OVERRIDE", "1.1"));
> +
> +  buf.as_string() = "OpenCL " + version_string + " Mesa " PACKAGE_VERSION
>  #ifdef MESA_GIT_SHA1
>  " (" MESA_GIT_SHA1 ")"
>  #endif
>  ;
>break;
> -
> +   }
> case CL_PLATFORM_NAME:
>buf.as_string() = "Clover";
>break;
> diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
> b/src/gallium/state_trackers/clover/core/device.cpp
> index 71cf4bf60a..b3a3903bcd 100644
> --- a/src/gallium/state_trackers/clover/core/device.cpp
> +++ b/src/gallium/state_trackers/clover/core/device.cpp
> @@ -25,6 +25,7 @@
>  #include "core/platform.hpp"
>  #include "pipe/p_screen.h"
>  #include "pipe/p_state.h"
> +#include "util/u_debug.h"
>  
>  using namespace clover;
>  
> @@ -268,10 +269,14 @@ device::endianness() const {
>  
>  std::string
>  device::device_version() const {
> -return "1.1";
> +   static const std::string device_version = std::string(
> + debug_get_option("CLOVER_DEVICE_VERSION_OVERRIDE", "1.1"));
> +   return device_version;
>  }
>  
>  std::string
>  device::device_clc_version() const {
> -return "1.1";
> +   static const std::string device_clc_version = std::string(
> + debug_get_option("CLOVER_DEVICE_CLC_VERSION_OVERRIDE", "1.1"));
> +   return device_clc_version;
>  }
> -- 
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [PATCH mesa] freedreno: add missing include

[Eric Engestrom]

Fixes: 26a9321d0ae819f2a49d7 "freedreno: add global_bindings state"
Cc: Rob Clark 
Signed-off-by: Eric Engestrom 
---
 src/gallium/drivers/freedreno/freedreno_state.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/freedreno/freedreno_state.c 
b/src/gallium/drivers/freedreno/freedreno_state.c
index 05717da95995e5cec6a5..907653e64af244bcc364 100644
--- a/src/gallium/drivers/freedreno/freedreno_state.c
+++ b/src/gallium/drivers/freedreno/freedreno_state.c
@@ -40,6 +40,8 @@
 #include "freedreno_query_hw.h"
 #include "freedreno_util.h"
 
+#include 
+
 /* All the generic state handling.. In case of CSO's that are specific
  * to the GPU version, when the bind and the delete are common they can
  * go in here.
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] [PATCH 09/29] nir/format_convert: Add pack/unpack for R11F_G11F_B10F

[Pohjolainen, Topi]

On Sun, Mar 04, 2018 at 07:44:09AM -0600, Jason Ekstrand wrote:
> On March 4, 2018 03:11:03 "Pohjolainen, Topi"
>  wrote:
> 
> >On Fri, Jan 26, 2018 at 05:59:38PM -0800, Jason Ekstrand wrote:
> >>---
> >> src/compiler/nir/nir_format_convert.h | 38 
> >> +++
> >> 1 file changed, 38 insertions(+)
> >>
> >>diff --git a/src/compiler/nir/nir_format_convert.h
> >>b/src/compiler/nir/nir_format_convert.h
> >>index 07618dc..0ffd0db 100644
> >>--- a/src/compiler/nir/nir_format_convert.h
> >>+++ b/src/compiler/nir/nir_format_convert.h
> >>@@ -130,3 +130,41 @@ nir_format_srgb_to_linear(nir_builder *b, nir_ssa_def 
> >>*c)
> >>return nir_fsat(b, nir_bcsel(b, nir_flt(b, c, nir_imm_float(b, 
> >> 0.04045f)),
> >>linear, curved));
> >> }
> >>+
> >>+static inline nir_ssa_def *
> >>+nir_format_unpack_11f11f10f(nir_builder *b, nir_ssa_def *packed)
> >>+{
> >>+   nir_ssa_def *chans[3];
> >>+   chans[0] = nir_mask_shift(b, packed, 0x07ff, 4);
> >>+   chans[1] = nir_mask_shift(b, packed, 0x003ff100, -7);
> >>+   chans[2] = nir_mask_shift(b, packed, 0xffc0, -17);
> >>+
> >>+   for (unsigned i = 0; i < 3; i++)
> >>+  chans[i] = nir_unpack_half_2x16_split_x(b, chans[i]);
> >>+
> >>+   return nir_vec(b, chans, 3);
> >>+}
> >>+
> >>+static inline nir_ssa_def *
> >>+nir_format_pack_r11g11b10f(nir_builder *b, nir_ssa_def *color)
> >>+{
> >>+   /* 10 and 11-bit floats are unsigned.  Clamp to non-negative */
> >>+   nir_ssa_def *clamped = nir_fmax(b, color, nir_imm_float(b, 0));
> >>+
> >>+   nir_ssa_def *undef = nir_ssa_undef(b, 1, color->bit_size);
> >>+   nir_ssa_def *p1 = nir_pack_half_2x16_split(b, nir_channel(b, clamped, 
> >>0),
> >>+ nir_channel(b, clamped, 
> >>1));
> >>+   nir_ssa_def *p2 = nir_pack_half_2x16_split(b, nir_channel(b, clamped, 
> >>2),
> >>+ undef);
> >>+
> >>+   /* A 10 or 11-bit float has the same exponent as a 16-bit float but with
> >>+* fewer exponent bits and no sign bit.  All we have to do is throw away
> >
> >   mantissa?
> >
> >>+* the sign bit and the bottom mantissa bits and shift it into place.
> >>+*/
> >>+   nir_ssa_def *packed = nir_imm_int(b, 0);
> >>+   packed = nir_mask_shift_or(b, packed, p1, 0x7ff0, -4);
> >>+   packed = nir_mask_shift_or(b, packed, p1, 0x7ff0, -9);
> >>+   packed = nir_mask_shift_or(b, packed, p2, 0x7ff0, 17);
> >
> >Shouldn't the mask be 0x7FE? Otherwise the lowest bit collides with the
> >exponent bits of green?
> 
> Yes, I think it should.  That may explain an issue I was setting
> earlier that caused me to not enable compressed blorp_copy for
> r11g11b10f formats. Good catch!

Nice! This patch is then also:

Reviewed-by: Topi Pohjolainen 

> 
> >>+
> >>+   return packed;
> >>+}
> >>--
> >>2.5.0.400.gff86faf
> >>
> >>___
> >>mesa-dev mailing list
> >>mesa-dev@lists.freedesktop.org
> >>https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/29] intel/isl: Add a helper for inverting swizzles

[Pohjolainen, Topi]

On Sun, Mar 04, 2018 at 07:10:01AM -0600, Jason Ekstrand wrote:
> On March 3, 2018 10:50:43 "Pohjolainen, Topi"
>  wrote:
> 
> >On Thu, Mar 01, 2018 at 03:04:14PM -0800, Jason Ekstrand wrote:
> >>On Thu, Mar 1, 2018 at 6:49 AM, Pohjolainen, Topi <
> >>topi.pohjolai...@gmail.com> wrote:
> >>
> >>> On Mon, Feb 26, 2018 at 08:42:42AM -0800, Jason Ekstrand wrote:
> >>> > On Mon, Feb 26, 2018 at 6:19 AM, Pohjolainen, Topi <
> >>> > topi.pohjolai...@gmail.com> wrote:
> >>> >
> >>> > > On Fri, Jan 26, 2018 at 05:59:34PM -0800, Jason Ekstrand wrote:
> >>> > > > ---
> >>> > > >  src/intel/isl/isl.c | 30 ++
> >>> > > >  src/intel/isl/isl.h |  2 ++
> >>> > > >  2 files changed, 32 insertions(+)
> >>> > > >
> >>> > > > diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> >>> > > > index a2d3ae6..420d387 100644
> >>> > > > --- a/src/intel/isl/isl.c
> >>> > > > +++ b/src/intel/isl/isl.c
> >>> > > > @@ -2379,3 +2379,33 @@ isl_swizzle_compose(struct isl_swizzle first,
> >>> > > struct isl_swizzle second)
> >>> > > >.a = swizzle_select(first.a, second),
> >>> > > > };
> >>> > > >  }
> >>> > > > +
> >>> > > > +/**
> >>> > > > + * Returns a swizzle that is the pseudo-inverse of this swizzle.
> >>> > > > + */
> >>> > > > +struct isl_swizzle
> >>> > > > +isl_swizzle_invert(struct isl_swizzle swizzle)
> >>> > > > +{
> >>> > > > +   /* Default to zero for channels which do not show up in the
> >>> swizzle
> >>> > > */
> >>> > > > +   enum isl_channel_select chans[4] = {
> >>> > > > +  ISL_CHANNEL_SELECT_ZERO,
> >>> > > > +  ISL_CHANNEL_SELECT_ZERO,
> >>> > > > +  ISL_CHANNEL_SELECT_ZERO,
> >>> > > > +  ISL_CHANNEL_SELECT_ZERO,
> >>> > > > +   };
> >>> > > > +
> >>> > > > +   /* We go in ABGR order so that, if there are any duplicates, the
> >>> > > first one
> >>> > > > +* is taken if you look at it in RGBA order.  This is what
> >>> Haswell
> >>> > > hardware
> >>> > > > +* does for render target swizzles.
> >>> > > > +*/
> >>> > > > +   if ((unsigned)(swizzle.a - ISL_CHANNEL_SELECT_RED) < 4)
> >>> > > > +  chans[swizzle.a - ISL_CHANNEL_SELECT_RED] =
> >>> > > ISL_CHANNEL_SELECT_ALPHA;
> >>> > > > +   if ((unsigned)(swizzle.b - ISL_CHANNEL_SELECT_RED) < 4)
> >>> > > > +  chans[swizzle.b - ISL_CHANNEL_SELECT_RED] =
> >>> > > ISL_CHANNEL_SELECT_BLUE;
> >>> > > > +   if ((unsigned)(swizzle.g - ISL_CHANNEL_SELECT_RED) < 4)
> >>> > > > +  chans[swizzle.g - ISL_CHANNEL_SELECT_RED] =
> >>> > > ISL_CHANNEL_SELECT_GREEN;
> >>> > > > +   if ((unsigned)(swizzle.r - ISL_CHANNEL_SELECT_RED) < 4)
> >>> > > > +  chans[swizzle.r - ISL_CHANNEL_SELECT_RED] =
> >>> > > ISL_CHANNEL_SELECT_RED;
> >>> > > > +
> >>> > > > +   return (struct isl_swizzle) { chans[0], chans[1], chans[2],
> >>> chans[3]
> >>> > > };
> >>> > >
> >>> > > If given
> >>> > >
> >>> > > swizzle == { ISL_CHANNEL_SELECT_RED,
> >>> > >  ISL_CHANNEL_SELECT_GREEN,
> >>> > >  ISL_CHANNEL_SELECT_BLUE,
> >>> > >  ISL_CHANNEL_SELECT_ALPHA },
> >>> > >
> >>> > > then
> >>> > > chans[ISL_CHANNEL_SELECT_ALPHA - ISL_CHANNEL_SELECT_RED] ==
> >>> chans[3] ==
> >>> > > ISL_CHANNEL_SELECT_ALPHA
> >>> > >
> >>> > > and so on, and the function returns the same swizzle as given?
> >>> >
> >>> >
> >>> > Yes, that is how the subtraction works.
> >>>
> >>> I was expecting it to "invert" that, i.e., to return ABGR. But okay, if
> >>> given
> >>> identity swizzle it returns identity.
> >>>
> >>> In order to understand how it works I thought I read further the series to
> >>> find an example - there seems to be one in patch 12 and another in patch
> >>> 16.
> >>> In case of 16 and destination format B4G4R4A4 the swizzle looks to be BGRA
> >>> (looking at anv_formats.c::main_formats).
> >>>
> >>> In that case we get:
> >>>
> >>>chans[ALPHA - RED] = chans[3] = ALPHA
> >>>chans[RED   - RED] = chans[0] = BLUE
> >>>chans[GREEN - RED] = chans[1] = GREEN
> >>>chans[BLUE  - RED] = chans[2] = RED
> >>>
> >>> and as a swizzle BLUE, GREEN, RED, ALPHA. This is again the same as given.
> >>> What am I not understanding?
> >>>
> >>
> >>I think the confusion is what "invert" means.  It doesn't mean we reverse
> >>the channels or anything like that.  It's an inverse in the sense that when
> >>you compose a swizzle with it's inverse, you get the identity back out.
> >>The inverse of BGRA is BGRA because if you apply the BGRA swizzle twice,
> >>you get RGBA again.  If you start with ARGB, you get
> >>
> >>chans[BLUE - RED] = chans[2] = ALPHA
> >>chans[GREEN - RED] = chans[1] = BLUE
> >>chans[RED - RED] = chans[0] = GREEN
> >>chans[ALPHA - RED] = chans[3] = RED
> >>
> >>This gives an inverse swizzle of GBAR which is certainly a weird swizzle.
> >>However, if you apply ARGB and then GBAR, you get back to identity since
> >>one is a left rotate and one is a right rotate.  Does that make a bit more
> >>sense?
> >
> >Thanks again for 

[Mesa-dev] [Bug 100259] [EGL] [GBM] undefined reference to `gbm_bo_create_with_modifiers'

[bugzilla-daemon]

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

--- Comment #24 from Emil Velikov  ---
Precisely the issue is fundamentally the same and there's three solutions.
Here's another 

$export LD_LIBRARY_PATH=/path/to/custom/build/DSOs && ./configure...

Let's not necro-bump bugs every time someone starts building stuff and doesn't
know how to manage multiple copies on their system :-\ Please?

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

[Mesa-dev] [Bug 100259] [EGL] [GBM] undefined reference to `gbm_bo_create_with_modifiers'

[bugzilla-daemon]

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

--- Comment #23 from Roman Gilg  ---
Sorry, that's what I forgot to mention: I compile libdrm from current master
with prefix /opt/drm.

In this case if

-L/opt/drm/lib

in the relink_command in mesa/src/gallium/targets/dri/gallium_dri.la

is before -lexpat, the install works. If it is behind -lexpat libtool doesn't
link my compiled libdrm in /opt/drm but apparently tries to link the system
ones in /usr/lib.

The problematic functionality in my case is btw not a GBM function, but some
new functions in libdrm_amdgpu.so used by the AMD drivers. But the problem in
principle is the same.

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

Re: [Mesa-dev] [ANNOUNCE] mesa 18.0.0-rc4

[Ernst Sjöstrand]

Is there a lot of new patches queued up before the 18.0 release? In
that case you could push them to a branch (before tagging)
and it could be given a quick pre-test... Not sure how that ties in
the with current release process.

Regards
//Ernst

2018-02-09 3:27 GMT+01:00 Emil Velikov :
> The fourth release candidate for Mesa 18.0.0 is now available.
>
>
> Andres Gomez (1):
>   i965: perform 2 uploads with dual slot *64*PASSTHRU formats on gen<8
>
> Bas Nieuwenhuizen (1):
>   radv: Signal fence correctly after sparse binding.
>
> Dave Airlie (4):
>   r600/eg: construct proper rat mask for image/buffers.
>   r600/sb: insert the else clause when we might depart from a loop
>   radv/gfx9: fix block compression texture views. (v2)
>   virgl: also remove dimension on indirect.
>
> Dylan Baker (2):
>   meson: Don't confuse the install and search paths for dri drivers
>   meson: Check for actual LLVM required versions
>
> Emil Velikov (3):
>   radv: Stop advertising VK_KHX_multiview
>   cherry-ignore: radv: Don't expose VK_KHX_multiview on android.
>   Update version to 18.0.0-rc4
>
> Eric Anholt (1):
>   mesa: Drop incorrect A4B4G4R4
> _mesa_format_matches_format_and_type() cases.
>
> George Kyriazis (2):
>   meson/swr: re-shuffle generated files
>   meson/swr: Updated copyright dates
>
> Jason Ekstrand (3):
>   anv/cmd_buffer: Re-emit the pipeline at every subpass
>   anv: Stop advertising VK_KHX_multiview
>   i965: Call prepare_external after implicit window-system MSAA resolves
>
> Jon Turney (9):
>   meson: libdrm shouldn't appear in Requires.private: if it wasn't found
>   configure: Default to gbm=no on osx
>   osx: ld doesn't support --build-id
>   glx/apple: include util/debug.h for env_var_as_boolean prototype
>   glx/apple: locate dispatch table functions to wrap by name
>   glx/test: fix building for osx
>   travis: conditionalize building of prerequisites on if OS=linux
>   travis: pip -> pip2
>   travis: add osx autotools build
>
> Jordan Justen (1):
>   i965: Create new program cache bo when clearing the program cache
>
> Kenneth Graunke (1):
>   i965: Bump official kernel requirement to Linux v3.9.
>
> Lucas Stach (1):
>   renderonly: fix dumb BO allocation for non 32bpp formats
>
> Marc Dietrich (1):
>   meson: don't install windows headers on non-windows platforms
>
> Marek Olšák (1):
>   winsys/amdgpu: fix assertion failure with UVD and VCE rings
>
> Matthew Nicholls (1):
>   radv: remove predication on cache flushes
>
> Michel Dänzer (1):
>   winsys/radeon: Compute is_displayable in surf_drm_to_winsys
>
> Rafael Antognolli (2):
>   anv/gen10: Emit CS stall and mark push constants dirty.
>   i965/gen10: Use CS Stall instead of WriteImmediate.
>
> Roland Scheidegger (1):
>   r600: don't do stack workarounds for hemlock
>
> Stephan Gerhold (1):
>   util/build-id: Fix address comparison for binaries with LOAD vaddr > 0
>
> Tapani Pälli (3):
>   i965: fix prog_data leak in brw_disk_cache
>   i965: fix disk_cache leak when destroying context
>   nir: mark unused space in packed_tex_data
>
> Timothy Arceri (1):
>   st/shader_cache: restore num_tgsi_tokens when loading from cache
>
> git tag: mesa-18.0.0-rc4
>
> https://mesa.freedesktop.org/archive/mesa-18.0.0-rc4.tar.gz
> MD5:  b09a18dd7a0ab9c3f55a820b5a25  mesa-18.0.0-rc4.tar.gz
> SHA1: b0785f1b2328e3d68a5e01cc00663301bb0829c2  mesa-18.0.0-rc4.tar.gz
> SHA256: e5d038a58221fe9c62b3f784df67210e87df81559032cfee7648d51bdce3a356
>  mesa-18.0.0-rc4.tar.gz
> SHA512: 
> e7d7898ab8b4788adaf34d7eb924f893314acd2dbf4970d71ecfa8e44b8662e1e924db97365ddb7b8fc3bd0744ba82dd1942439582cb685b54e86f00f8e51310
>  mesa-18.0.0-rc4.tar.gz
> PGP:  https://mesa.freedesktop.org/archive/mesa-18.0.0-rc4.tar.gz.sig
>
> https://mesa.freedesktop.org/archive/mesa-18.0.0-rc4.tar.xz
> MD5:  195889b71ee88785d55b03d99e0034d3  mesa-18.0.0-rc4.tar.xz
> SHA1: ea24546b10f1a089c25c992d01083d7eb005ec44  mesa-18.0.0-rc4.tar.xz
> SHA256: ad575becea192f04403b6783492955f395dd8faad7e51cbcbad203be70eb9075
>  mesa-18.0.0-rc4.tar.xz
> SHA512: 
> 91dd0a4396715a7896fc47aabf38c4b486df3b50c9764795805550ef01724d2e2281ba9b000e82760ea0e199c58d8c9943dbc732b2adab46554ff5c2f9e2ece1
>  mesa-18.0.0-rc4.tar.xz
> PGP:  https://mesa.freedesktop.org/archive/mesa-18.0.0-rc4.tar.xz.sig
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105344] Installation bug by video card modules conflict (nvidia GTX 950 M)

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

 QA Contact|mesa-dev@lists.freedesktop. |nouveau@lists.freedesktop.o
   |org |rg
   Severity|blocker |normal
  Component|Other   |Drivers/DRI/nouveau
   Assignee|mesa-dev@lists.freedesktop. |nouveau@lists.freedesktop.o
   |org |rg

--- Comment #4 from Emil Velikov  ---
Considering that nouveau.modeset=0 helps, I'm flipping this to component
nouveau. Feel free to revert.

> kernel is: 4.13.0-36-generic
> mesa: OpenGL version string: 3.0 Mesa 17.2.8
FWIW these two are EOL. You might want to try something newer.

> libdrm: could not find
> xf86-video-nouveau: could not find.
> 
Exact names might differ across distros - please search carefully.

> -
> 
> Follow the "kernel_log.txt" output:
> 
Please make sure you _attach_ logs.

> [1.333868] nouveau :01:00.0: bus: MMIO read of  FAULT at
> 612004 [ IBUS ]
> [1.335248] nouveau :01:00.0: bus: MMIO read of  FAULT at
> 10ac08 [ IBUS ]

These two look mildly interesting. Not sure how much it matters sunce the
nvidia device is a 3D controller - there should be no outputs wired/plugged.

Potential next steps include:
 - using xserver or wayland - try the former
 - [it using xserver] - flip between the modesetting and nouveau DDX
 - attach the respective logs - xserver -> Xorg.*.log, wayland -> no idea where
kwin puts it

If the above are cryptic, do read through the wikis/googleit ;-)

https://nouveau.freedesktop.org/wiki/
https://nouveau.freedesktop.org/wiki/Optimus/
https://wiki.archlinux.org/index.php/nouveau

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

[Mesa-dev] [Bug 100259] [EGL] [GBM] undefined reference to `gbm_bo_create_with_modifiers'

[bugzilla-daemon]

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

--- Comment #22 from Daniel Stone  ---
Roman, that would only work if you have a newer version of GBM installed into
/opt/drm/lib. If you're doing completely clean builds, there is no full
solution: the only known workarounds are the ones Emil has posted earlier.

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

Re: [Mesa-dev] [PATCH] vulkan: do not expose surface/swapchain extensions on Android

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

At some point, we could add some code to the XML parser to parse extension
dependencies and maybe do this automatically.  However, that's a pile of
work to avoid a two-line change so let's not bother for now.

On Mon, Mar 5, 2018 at 8:46 AM, Tapani Pälli  wrote:

> On Android surface/swapchain extensions are implemented by the loader.
> Patch
> modifies both anv and radv extension scripts disabling currently exposed
> ones. See also earlier commit 9f763c1f9b.
>
> Signed-off-by: Tapani Pälli 
> ---
>  src/amd/vulkan/radv_extensions.py  | 4 ++--
>  src/intel/vulkan/anv_extensions.py | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_extensions.py b/src/amd/vulkan/radv_
> extensions.py
> index 92b1ea3e14..6a323ea9b0 100644
> --- a/src/amd/vulkan/radv_extensions.py
> +++ b/src/amd/vulkan/radv_extensions.py
> @@ -65,9 +65,9 @@ EXTENSIONS = [
>  Extension('VK_KHR_external_semaphore_fd', 1,
> 'device->rad_info.has_syncobj'),
>  Extension('VK_KHR_get_memory_requirements2',  1, True),
>  Extension('VK_KHR_get_physical_device_properties2',   1, True),
> -Extension('VK_KHR_get_surface_capabilities2', 1, True),
> +Extension('VK_KHR_get_surface_capabilities2', 1,
> 'RADV_HAS_SURFACE'),
>  Extension('VK_KHR_image_format_list', 1, True),
> -Extension('VK_KHR_incremental_present',   1, True),
> +Extension('VK_KHR_incremental_present',   1,
> 'RADV_HAS_SURFACE'),
>  Extension('VK_KHR_maintenance1',  1, True),
>  Extension('VK_KHR_maintenance2',  1, True),
>  Extension('VK_KHR_push_descriptor',   1, True),
> diff --git a/src/intel/vulkan/anv_extensions.py b/src/intel/vulkan/anv_
> extensions.py
> index 8d39038c43..4e5af7da2a 100644
> --- a/src/intel/vulkan/anv_extensions.py
> +++ b/src/intel/vulkan/anv_extensions.py
> @@ -68,7 +68,7 @@ EXTENSIONS = [
>  Extension('VK_KHR_get_physical_device_properties2',   1, True),
>  Extension('VK_KHR_get_surface_capabilities2', 1,
> 'ANV_HAS_SURFACE'),
>  Extension('VK_KHR_image_format_list', 1, True),
> -Extension('VK_KHR_incremental_present',   1, True),
> +Extension('VK_KHR_incremental_present',   1,
> 'ANV_HAS_SURFACE'),
>  Extension('VK_KHR_maintenance1',  1, True),
>  Extension('VK_KHR_maintenance2',  1, True),
>  Extension('VK_KHR_push_descriptor',   1, True),
> --
> 2.13.6
>
> ___
> 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] disk cache: Link with -latomic if necessary

[Emil Velikov]

[Trimming down the CC list]

Hi Mike,

On 4 March 2018 at 00:20, Mike Lothian  wrote:
> Hi
>
> Sorry to be a pain again
>
> I've just tested this with clang and the 32bit build still fails without
> -latomic
>
> libtool: link: /bin/true glsl/.libs/libstandalone.a
Eric has a point here - the patch brings meson up-to scratch, while
you're having some issues with autotools.

The link issue is in libstandalone, which pulls libmesautil/disk_cache.o
Yet libmesautil already has LIBATOMIC_LIBS (-latomic) so why things
fail is a bit fishy.

Can you isolate any funky LTO interactions?

If that doesn't cut it - please open a bug attaching the output of
make V=1. In particular the src/util and src/compiler bits.

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