Re: [Mesa-dev] [PATCH] i965: Don't disable CCS for RT dependencies when dispatching compute.

[Jason Ekstrand]

Rb


On October 23, 2017 22:21:47 Kenneth Graunke  wrote:


Compute shaders don't have access to the framebuffer, so there's no
point in worrying whether a texture is bound as a render target.

This saves a bunch of resolves in GFXBench4 Manhattan 3.1, but doesn't
seem to impact performance at all, at least on Apollolake.
---
 src/mesa/drivers/dri/i965/brw_compute.c | 2 +-
 src/mesa/drivers/dri/i965/brw_context.h | 2 +-
 src/mesa/drivers/dri/i965/brw_draw.c| 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

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

index c1b2df590b7..9be7523bab3 100644
--- a/src/mesa/drivers/dri/i965/brw_compute.c
+++ b/src/mesa/drivers/dri/i965/brw_compute.c
@@ -177,7 +177,7 @@ brw_dispatch_compute_common(struct gl_context *ctx)

brw_validate_textures(brw);

-   brw_predraw_resolve_inputs(brw);
+   brw_predraw_resolve_inputs(brw, false);

/* Flush the batch if the batch/state buffers are nearly full.  We can
 * grow them if needed, but this is not free, so we'd like to avoid it.
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h

index 26e71e62b54..0102f154248 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1234,7 +1234,7 @@ void intel_update_renderbuffers(__DRIcontext *context,
 __DRIdrawable *drawable);
 void intel_prepare_render(struct brw_context *brw);

-void brw_predraw_resolve_inputs(struct brw_context *brw);
+void brw_predraw_resolve_inputs(struct brw_context *brw, bool rendering);

 void intel_resolve_for_dri2_flush(struct brw_context *brw,
   __DRIdrawable *drawable);
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c

index b74ab8bde23..80d4891f6f6 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -381,7 +381,7 @@ intel_disable_rb_aux_buffer(struct brw_context *brw,
  * enabled depth texture, and flush the render cache for any dirty textures.
  */
 void
-brw_predraw_resolve_inputs(struct brw_context *brw)
+brw_predraw_resolve_inputs(struct brw_context *brw, bool rendering)
 {
struct gl_context *ctx = >ctx;
struct intel_texture_object *tex_obj;
@@ -416,7 +416,7 @@ brw_predraw_resolve_inputs(struct brw_context *brw)
  num_layers = INTEL_REMAINING_LAYERS;
   }

-  const bool disable_aux =
+  const bool disable_aux = rendering &&
  intel_disable_rb_aux_buffer(brw, tex_obj->mt, min_level, num_levels,
  "for sampling");

@@ -678,7 +678,7 @@ brw_prepare_drawing(struct gl_context *ctx,
 * and finalizing textures but before setting up any hardware state for
 * this draw call.
 */
-   brw_predraw_resolve_inputs(brw);
+   brw_predraw_resolve_inputs(brw, true);
brw_predraw_resolve_framebuffer(brw);

/* Bind all inputs, derive varying and size information:
--
2.14.2




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

[Mesa-dev] [PATCH] i965: Don't disable CCS for RT dependencies when dispatching compute.

[Kenneth Graunke]

Compute shaders don't have access to the framebuffer, so there's no
point in worrying whether a texture is bound as a render target.

This saves a bunch of resolves in GFXBench4 Manhattan 3.1, but doesn't
seem to impact performance at all, at least on Apollolake.
---
 src/mesa/drivers/dri/i965/brw_compute.c | 2 +-
 src/mesa/drivers/dri/i965/brw_context.h | 2 +-
 src/mesa/drivers/dri/i965/brw_draw.c| 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compute.c 
b/src/mesa/drivers/dri/i965/brw_compute.c
index c1b2df590b7..9be7523bab3 100644
--- a/src/mesa/drivers/dri/i965/brw_compute.c
+++ b/src/mesa/drivers/dri/i965/brw_compute.c
@@ -177,7 +177,7 @@ brw_dispatch_compute_common(struct gl_context *ctx)
 
brw_validate_textures(brw);
 
-   brw_predraw_resolve_inputs(brw);
+   brw_predraw_resolve_inputs(brw, false);
 
/* Flush the batch if the batch/state buffers are nearly full.  We can
 * grow them if needed, but this is not free, so we'd like to avoid it.
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 26e71e62b54..0102f154248 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1234,7 +1234,7 @@ void intel_update_renderbuffers(__DRIcontext *context,
 __DRIdrawable *drawable);
 void intel_prepare_render(struct brw_context *brw);
 
-void brw_predraw_resolve_inputs(struct brw_context *brw);
+void brw_predraw_resolve_inputs(struct brw_context *brw, bool rendering);
 
 void intel_resolve_for_dri2_flush(struct brw_context *brw,
   __DRIdrawable *drawable);
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index b74ab8bde23..80d4891f6f6 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -381,7 +381,7 @@ intel_disable_rb_aux_buffer(struct brw_context *brw,
  * enabled depth texture, and flush the render cache for any dirty textures.
  */
 void
-brw_predraw_resolve_inputs(struct brw_context *brw)
+brw_predraw_resolve_inputs(struct brw_context *brw, bool rendering)
 {
struct gl_context *ctx = >ctx;
struct intel_texture_object *tex_obj;
@@ -416,7 +416,7 @@ brw_predraw_resolve_inputs(struct brw_context *brw)
  num_layers = INTEL_REMAINING_LAYERS;
   }
 
-  const bool disable_aux =
+  const bool disable_aux = rendering &&
  intel_disable_rb_aux_buffer(brw, tex_obj->mt, min_level, num_levels,
  "for sampling");
 
@@ -678,7 +678,7 @@ brw_prepare_drawing(struct gl_context *ctx,
 * and finalizing textures but before setting up any hardware state for
 * this draw call.
 */
-   brw_predraw_resolve_inputs(brw);
+   brw_predraw_resolve_inputs(brw, true);
brw_predraw_resolve_framebuffer(brw);
 
/* Bind all inputs, derive varying and size information:
-- 
2.14.2

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

Re: [Mesa-dev] [PATCH 1/2] mesa: enum checks for GL_EXT_occlusion_query_boolean

[Tapani Pälli]

gentle ping ..

(after this we could also enable GL_EXT_disjoint_timer_query and have 
more queries available for gles)



On 10/04/2017 02:56 PM, Tapani Pälli wrote:

Some of the checks are valid for generic ES 3.2 as well.

Signed-off-by: Tapani Pälli 
---
  src/mesa/main/queryobj.c | 44 
  1 file changed, 44 insertions(+)

diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index 46535d7b4c..d966814a76 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -165,6 +165,20 @@ get_pipe_stats_binding_point(struct gl_context *ctx,
  static struct gl_query_object **
  get_query_binding_point(struct gl_context *ctx, GLenum target, GLuint index)
  {
+
+   /* From GL_EXT_occlusion_query_boolean spec:
+*
+*"Accepted by the  parameter of BeginQueryEXT, EndQueryEXT,
+*and GetQueryivEXT:
+*
+*   ANY_SAMPLES_PASSED_EXT 0x8C2F
+*   ANY_SAMPLES_PASSED_CONSERVATIVE_EXT0x8D6A"
+*/
+   if ((_mesa_is_gles(ctx) && ctx->Version == 20) &&
+   (target != GL_ANY_SAMPLES_PASSED &&
+target != GL_ANY_SAMPLES_PASSED_CONSERVATIVE))
+  return NULL;
+
 switch (target) {
 case GL_SAMPLES_PASSED_ARB:
if (ctx->Extensions.ARB_occlusion_query)
@@ -649,6 +663,19 @@ _mesa_GetQueryIndexediv(GLenum target, GLuint index, 
GLenum pname,
 if (!query_error_check_index(ctx, target, index))
return;
  
+   /* From the GL_EXT_occlusion_query_boolean spec:

+*
+* "The error INVALID_ENUM is generated if GetQueryivEXT is called where
+*  is not CURRENT_QUERY_EXT."
+*
+* Same rule is present also in ES 3.2 spec.
+*/
+   if (_mesa_is_gles(ctx) && pname != GL_CURRENT_QUERY) {
+  _mesa_error(ctx, GL_INVALID_ENUM, "glGetQueryivEXT(%s)",
+  _mesa_enum_to_string(pname));
+  return;
+   }
+
 if (target == GL_TIMESTAMP) {
if (!ctx->Extensions.ARB_timer_query) {
   _mesa_error(ctx, GL_INVALID_ENUM, "glGetQueryARB(target)");
@@ -775,6 +802,23 @@ get_query_object(struct gl_context *ctx, const char *func,
return;
 }
  
+   /* From GL_EXT_occlusion_query_boolean spec:

+*
+*"Accepted by the  parameter of GetQueryObjectivEXT and
+*GetQueryObjectuivEXT:
+*
+*QUERY_RESULT_EXT   0x8866
+*QUERY_RESULT_AVAILABLE_EXT 0x8867"
+*
+* Same rule is present also in ES 3.2 spec.
+*/
+   if (_mesa_is_gles(ctx) &&
+   (pname != GL_QUERY_RESULT && pname != GL_QUERY_RESULT_AVAILABLE)) {
+  _mesa_error(ctx, GL_INVALID_ENUM, "%s(%s)", func,
+  _mesa_enum_to_string(pname));
+  return;
+   }
+
 if (buf && buf != ctx->Shared->NullBufferObj) {
bool is_64bit = ptype == GL_INT64_ARB ||
   ptype == GL_UNSIGNED_INT64_ARB;


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

[Mesa-dev] [PATCH] radv: only emit dfsm packets if dfsm is allowed.

[Dave Airlie]

From: Dave Airlie 

radeonsi only emits these when dfsm is enabled, so for now
just hinge them on a flag we never set.

Signed-off-by: Dave Airlie 
---
 src/amd/vulkan/radv_cmd_buffer.c | 6 +++---
 src/amd/vulkan/radv_private.h| 1 +
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index ba382c8691b..807283be1d8 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -551,7 +551,7 @@ radv_update_multisample_state(struct radv_cmd_buffer 
*cmd_buffer,
radv_cayman_emit_msaa_sample_locs(cmd_buffer->cs, num_samples);
 
/* GFX9: Flush DFSM when the AA mode changes. */
-   if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) {
+   if (cmd_buffer->device->dfsm_allowed) {
radeon_emit(cmd_buffer->cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
radeon_emit(cmd_buffer->cs, EVENT_TYPE(V_028A90_FLUSH_DFSM) | 
EVENT_INDEX(0));
}
@@ -956,7 +956,7 @@ radv_emit_fragment_shader(struct radv_cmd_buffer 
*cmd_buffer,
radeon_set_context_reg(cmd_buffer->cs, R_028238_CB_TARGET_MASK, 
blend->cb_target_mask);
radeon_set_context_reg(cmd_buffer->cs, R_02823C_CB_SHADER_MASK, 
blend->cb_shader_mask);
 
-   if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) {
+   if (cmd_buffer->device->dfsm_allowed) {
/* optimise this? */
radeon_emit(cmd_buffer->cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
radeon_emit(cmd_buffer->cs, EVENT_TYPE(V_028A90_FLUSH_DFSM) | 
EVENT_INDEX(0));
@@ -1443,7 +1443,7 @@ radv_emit_framebuffer_state(struct radv_cmd_buffer 
*cmd_buffer)
   S_028208_BR_X(framebuffer->width) |
   S_028208_BR_Y(framebuffer->height));
 
-   if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) {
+   if (cmd_buffer->device->dfsm_allowed) {
radeon_emit(cmd_buffer->cs, PKT3(PKT3_EVENT_WRITE, 0, 0));
radeon_emit(cmd_buffer->cs, EVENT_TYPE(V_028A90_BREAK_BATCH) | 
EVENT_INDEX(0));
}
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index a4e52b25306..83529015c5d 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -531,6 +531,7 @@ struct radv_device {
 
bool llvm_supports_spill;
bool has_distributed_tess;
+   bool dfsm_allowed;
uint32_t tess_offchip_block_dw_size;
uint32_t scratch_waves;
 
-- 
2.14.2

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

Re: [Mesa-dev] [PATCH v3 00/34] i965 disk shader cache

[Jason Ekstrand]

I didn't re-read every thing in v3 but I did read all of v2 on Friday.
Assuming you didn't make any massive changes other than those detailed
here,  the series is

Reviewed-by: Jason Ekstrand 

Except, of course, for the couple of patches written by me.  Also, I can't
really say I properly reviewed the nir_serialize patch so best to keep that
one to an Ack.

I think Ken still has some right of review here and, since it's not going
in 17.3, we do have some time.  Hopefully me reviewing it will give him a
bit more confidence. :-)

--Jason

On Mon, Oct 23, 2017 at 2:42 PM, Jordan Justen 
wrote:

> On 2017-10-22 13:01:08, Jordan Justen wrote:
> >
> > Patch code review status:
> >
> > mesa/glsl: add api_enabled flag to gl_transform_feedback_info
> >
> > i965: add support for cached shaders with xfb qualifiers
>
> It sounds like Tim has a plan for supporting shader cache with
> transform feedback, but for now these two are:
>
> Reviewed-by: Jordan Justen 
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 21/34] i965: add initial implementation of on disk shader cache

[Jason Ekstrand]

I made one minor comment below.

Reviewed-by: Jason Ekstrand 

On Sun, Oct 22, 2017 at 1:01 PM, Jordan Justen 
wrote:

> From: Timothy Arceri 
>
> This uses the recently-added disk_cache.c to write out the final
> linked binary for vertex and fragment shader programs.
>
> This is based off the initial implementation done by Carl Worth.
>
> v2:
>  * Squash 'i965: add image param shader cache support'
>  * Squash 'i965: add shader cache support for pull param pointers'
>  * Sustantially simplified by a rework on top of Jason's 2975e4c56a7a.
>  * Rename load_program_data to read_program_data. (Jason)
>
> v3:
>  * Simplify and align program read/write. (Jason)
>
> [jordan.l.jus...@intel.com: *_cached_program => brw_disk_cache_*_program]
> [jordan.l.jus...@intel.com: brw_shader_cache.c => brw_disk_cache.c]
> [jordan.l.jus...@intel.com: don't map to write program when LLC is
> present]
> [jordan.l.jus...@intel.com: set program_written_to_cache on read from
> cache]
> [jordan.l.jus...@intel.com: only try cache when status is linking_skipped]
> [jordan.l.jus...@intel.com: rework based on uniforms rework 2975e4c56a7a]
> [jordan.l.jus...@intel.com: Simplify and align program read/write]
> Signed-off-by: Jordan Justen 
> ---
>  src/mesa/drivers/dri/i965/Makefile.sources |   1 +
>  src/mesa/drivers/dri/i965/brw_disk_cache.c | 329
> +
>  src/mesa/drivers/dri/i965/brw_state.h  |   5 +
>  src/mesa/drivers/dri/i965/meson.build  |   1 +
>  4 files changed, 336 insertions(+)
>  create mode 100644 src/mesa/drivers/dri/i965/brw_disk_cache.c
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index 053d89b81ec..2980cdb3c54 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -14,6 +14,7 @@ i965_FILES = \
> brw_cs.h \
> brw_curbe.c \
> brw_defines.h \
> +   brw_disk_cache.c \
> brw_draw.c \
> brw_draw.h \
> brw_draw_upload.c \
> diff --git a/src/mesa/drivers/dri/i965/brw_disk_cache.c
> b/src/mesa/drivers/dri/i965/brw_disk_cache.c
> new file mode 100644
> index 000..186cbe83706
> --- /dev/null
> +++ b/src/mesa/drivers/dri/i965/brw_disk_cache.c
> @@ -0,0 +1,329 @@
> +/*
> + * Copyright © 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> next
> + * paragraph) shall be included in all copies or substantial portions of
> the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include "compiler/blob.h"
> +#include "compiler/glsl/ir_uniform.h"
> +#include "compiler/glsl/shader_cache.h"
> +#include "main/mtypes.h"
> +#include "util/disk_cache.h"
> +#include "util/macros.h"
> +#include "util/mesa-sha1.h"
> +
> +#include "brw_context.h"
> +#include "brw_state.h"
> +#include "brw_vs.h"
> +#include "brw_wm.h"
> +
> +static void
> +gen_shader_sha1(struct brw_context *brw, struct gl_program *prog,
> +gl_shader_stage stage, void *key, unsigned char *out_sha1)
> +{
> +   char sha1_buf[41];
> +   unsigned char sha1[20];
> +   char manifest[256];
> +   int offset = 0;
> +
> +   _mesa_sha1_format(sha1_buf, prog->sh.data->sha1);
> +   offset += snprintf(manifest, sizeof(manifest), "program: %s\n",
> sha1_buf);
> +
> +   _mesa_sha1_compute(key, brw_prog_key_size(stage), sha1);
> +   _mesa_sha1_format(sha1_buf, sha1);
> +   offset += snprintf(manifest + offset, sizeof(manifest) - offset,
> +  "%s_key: %s\n", _mesa_shader_stage_to_abbrev(
> stage),
> +  sha1_buf);
> +
> +   _mesa_sha1_compute(manifest, strlen(manifest), out_sha1);
> +}
> +
> +static void
> +write_blob_program_data(struct blob *binary, const void *program,
> +size_t program_size,
> +struct brw_stage_prog_data *prog_data,
> +

Re: [Mesa-dev] [PATCH 3/5] compiler: define endian for FreeBSD

[Brian Paul]

On 10/23/2017 02:20 PM, Greg V wrote:

Obtained from: FreeBSD ports
---
  src/mesa/main/compiler.h | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 43a06b4313..8652aac36c 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -51,6 +51,9 @@
  #if defined(__linux__)
  #include 
  #define CPU_TO_LE32( x )  bswap_32( x )
+#elif defined(__FreeBSD__)
+#include 
+#define CPU_TO_LE32( x )   bswap32( x )
  #elif defined(__APPLE__)
  #include 
  #define CPU_TO_LE32( x )  CFSwapInt32HostToLittle( x )



I think "compiler:" in the subject line could be just "mesa:".

Otherwise, for patches 3,4,5: Reviewed-by: Brian Paul 

I'll leave 1,2 to others.

-Brian

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

[Mesa-dev] [PATCH 2/5] loader: use drmGetDeviceNameFromFd2 from libdrm

[Greg V]

Reduce code duplication and automatically benefit from OS-specific
fixes to libdrm (e.g. in FreeBSD ports).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103283
---
 src/loader/loader.c | 36 +---
 1 file changed, 1 insertion(+), 35 deletions(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 182ba90a0d..f7f85e37c2 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -244,29 +244,6 @@ int loader_get_user_preferred_fd(int default_fd, bool 
*different_device)
 }
 #endif
 
-#if defined(HAVE_LIBDRM)
-static int
-dev_node_from_fd(int fd, unsigned int *maj, unsigned int *min)
-{
-   struct stat buf;
-
-   if (fstat(fd, ) < 0) {
-  log_(_LOADER_WARNING, "MESA-LOADER: failed to stat fd %d\n", fd);
-  return -1;
-   }
-
-   if (!S_ISCHR(buf.st_mode)) {
-  log_(_LOADER_WARNING, "MESA-LOADER: fd %d not a character device\n", fd);
-  return -1;
-   }
-
-   *maj = major(buf.st_rdev);
-   *min = minor(buf.st_rdev);
-
-   return 0;
-}
-#endif
-
 #if defined(HAVE_LIBDRM)
 
 static int
@@ -312,18 +289,7 @@ loader_get_pci_id_for_fd(int fd, int *vendor_id, int 
*chip_id)
 static char *
 drm_get_device_name_for_fd(int fd)
 {
-   unsigned int maj, min;
-   char buf[0x40];
-   int n;
-
-   if (dev_node_from_fd(fd, , ) < 0)
-  return NULL;
-
-   n = snprintf(buf, sizeof(buf), DRM_DEV_NAME, DRM_DIR_NAME, min);
-   if (n == -1 || n >= sizeof(buf))
-  return NULL;
-
-   return strdup(buf);
+   return drmGetDeviceNameFromFd2(fd);
 }
 #endif
 
-- 
2.14.2

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

Re: [Mesa-dev] [PATCH] automake: intel: correctly append to the LIBADD variable

[Hongxu Jia]

On 2017年10月23日 20:29, Emil Velikov wrote:

From: Emil Velikov 

Commit 05fc62d89f5 sets the variable, yet it forgot the update the
existing reference to append (instead of assign).

Thus as-is the expat library was discarded from the link chain when
building with Android.

Fixes: 05fc62d89f5 ("automake: intel: move expat handling where it's
used")
Cc: Hongxu Jia 


Thanks for pointing it out

//Hongxu


Signed-off-by: Emil Velikov 
---
  src/intel/Makefile.common.am | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/Makefile.common.am b/src/intel/Makefile.common.am
index 894dbb5208c..443cefc522a 100644
--- a/src/intel/Makefile.common.am
+++ b/src/intel/Makefile.common.am
@@ -27,5 +27,5 @@ common_libintel_common_la_LIBADD = $(EXPAT_LIBS)
  
  if HAVE_PLATFORM_ANDROID

  common_libintel_common_la_CFLAGS += $(ANDROID_CFLAGS)
-common_libintel_common_la_LIBADD = $(ANDROID_LIBS)
+common_libintel_common_la_LIBADD += $(ANDROID_LIBS)
  endif



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

[Mesa-dev] [PATCH 4/5] winsys/svga/drm: add ERESTART define for *BSD

[Greg V]

Obtained from: FreeBSD ports
---
 src/gallium/winsys/svga/drm/vmw_screen_ioctl.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c 
b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
index 79f9d950d9..62a2af6d65 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
@@ -70,6 +70,11 @@ vmw_region_size(struct vmw_region *region)
return region->size;
 }
 
+#if defined(__DragonFly__) || defined(__FreeBSD__) || \
+defined(__NetBSD__) || defined(__OpenBSD__)
+#define ERESTART EINTR
+#endif
+
 uint32
 vmw_ioctl_context_create(struct vmw_winsys_screen *vws)
 {
-- 
2.14.2

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

[Mesa-dev] [PATCH 3/5] compiler: define endian for FreeBSD

[Greg V]

Obtained from: FreeBSD ports
---
 src/mesa/main/compiler.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 43a06b4313..8652aac36c 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -51,6 +51,9 @@
 #if defined(__linux__)
 #include 
 #define CPU_TO_LE32( x )   bswap_32( x )
+#elif defined(__FreeBSD__)
+#include 
+#define CPU_TO_LE32( x )   bswap32( x )
 #elif defined(__APPLE__)
 #include 
 #define CPU_TO_LE32( x )   CFSwapInt32HostToLittle( x )
-- 
2.14.2

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

[Mesa-dev] [PATCH 1/5] anv: add ETIME fallback define

[Greg V]

FreeBSD only has ETIMEDOUT, not ETIME
---
 src/intel/vulkan/anv_device.c | 4 
 src/intel/vulkan/anv_gem.c| 4 
 src/intel/vulkan/anv_queue.c  | 4 
 3 files changed, 12 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 67028e8da9..fab2a394ca 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -39,6 +39,10 @@
 
 #include "genxml/gen7_pack.h"
 
+#ifndef ETIME
+#define ETIME ETIMEDOUT
+#endif
+
 static void
 compiler_debug_log(void *data, const char *fmt, ...)
 { }
diff --git a/src/intel/vulkan/anv_gem.c b/src/intel/vulkan/anv_gem.c
index 34c0989108..4a885617ab 100644
--- a/src/intel/vulkan/anv_gem.c
+++ b/src/intel/vulkan/anv_gem.c
@@ -31,6 +31,10 @@
 
 #include "anv_private.h"
 
+#ifndef ETIME
+#define ETIME ETIMEDOUT
+#endif
+
 static int
 anv_ioctl(int fd, unsigned long request, void *arg)
 {
diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index c6b2e01c62..b1662c1720 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -34,6 +34,10 @@
 
 #include "genxml/gen7_pack.h"
 
+#ifndef ETIME
+#define ETIME ETIMEDOUT
+#endif
+
 VkResult
 anv_device_execbuf(struct anv_device *device,
struct drm_i915_gem_execbuffer2 *execbuf,
-- 
2.14.2

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

[Mesa-dev] [PATCH 5/5] util: use OpenBSD/NetBSD code on FreeBSD/DragonFly

[Greg V]

Obtained from: FreeBSD ports
---
 src/util/u_endian.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/util/u_endian.h b/src/util/u_endian.h
index b9d563dd43..7be33dd3a5 100644
--- a/src/util/u_endian.h
+++ b/src/util/u_endian.h
@@ -54,7 +54,7 @@
 # define PIPE_ARCH_BIG_ENDIAN
 #endif
 
-#elif defined(__OpenBSD__) || defined(__NetBSD__)
+#elif defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__) || 
defined(__DragonFly__)
 #include 
 #include 
 
-- 
2.14.2

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

[Mesa-dev] [PATCH 0/5] FreeBSD compatibility patches

[Greg V]

This set of patches includes a bunch of simple fixes from FreeBSD ports
and a loader patch that fixes Wayland/EGL clients not reading GPU device 
name correctly on FreeBSD.

Greg V (5):
  anv: add ETIME fallback define
  loader: use drmGetDeviceNameFromFd2 from libdrm
  compiler: define endian for FreeBSD
  winsys/svga/drm: add ERESTART define for *BSD
  util: use OpenBSD/NetBSD code on FreeBSD/DragonFly

 src/gallium/winsys/svga/drm/vmw_screen_ioctl.c |  5 
 src/intel/vulkan/anv_device.c  |  4 +++
 src/intel/vulkan/anv_gem.c |  4 +++
 src/intel/vulkan/anv_queue.c   |  4 +++
 src/loader/loader.c| 36 +-
 src/mesa/main/compiler.h   |  3 +++
 src/util/u_endian.h|  2 +-
 7 files changed, 22 insertions(+), 36 deletions(-)

-- 
2.14.2

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

Re: [Mesa-dev] [PATCH] mesa: fix GL_{COLOR, DEPTH, STENCIL}_COMPONENTS queries for TBOs

[Ilia Mirkin]

On Mon, Oct 23, 2017 at 9:16 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> ---
>  src/mesa/main/formatquery.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/src/mesa/main/formatquery.c b/src/mesa/main/formatquery.c
> index 05b7810..9c53d7c 100644
> --- a/src/mesa/main/formatquery.c
> +++ b/src/mesa/main/formatquery.c
> @@ -1094,43 +1094,54 @@ _mesa_GetInternalformativ(GLenum target, GLenum 
> internalformat, GLenum pname,
> }
>
> case GL_COLOR_COMPONENTS:
>/* The ARB_internalformat_query2 spec says:
> *
> * "- COLOR_COMPONENTS: If the internal format contains any color
> * components (R, G, B, or A), TRUE is returned in .
> * If the internal format is unsupported or contains no color
> * components, FALSE is returned."
> */
> +  if (target == GL_TEXTURE_BUFFER &&
> +  _mesa_validate_texbuffer_format(ctx, internalformat) ==
> +  MESA_FORMAT_NONE)
> + break;

Because not all color formats are supported for TBO's, right?

Although _mesa_is_color_format returns true for unsupported formats as
well... although that's probably a separate bug.

Reviewed-by: Ilia Mirkin 

> +
>if (_mesa_is_color_format(internalformat))
>   buffer[0] = GL_TRUE;
>break;
>
> case GL_DEPTH_COMPONENTS:
>/* The ARB_internalformat_query2 spec says:
> *
> * "- DEPTH_COMPONENTS: If the internal format contains a depth
> * component (D), TRUE is returned in . If the internal 
> format
> * is unsupported or contains no depth component, FALSE is 
> returned."
> */
> +  if (target == GL_TEXTURE_BUFFER)
> + break;
> +
>if (_mesa_is_depth_format(internalformat) ||
>_mesa_is_depthstencil_format(internalformat))
>   buffer[0] = GL_TRUE;
>break;
>
> case GL_STENCIL_COMPONENTS:
>/* The ARB_internalformat_query2 spec says:
> *
> * "- STENCIL_COMPONENTS: If the internal format contains a stencil
> * component (S), TRUE is returned in . If the internal 
> format
> * is unsupported or contains no stencil component, FALSE is 
> returned.
> */
> +  if (target == GL_TEXTURE_BUFFER)
> + break;
> +
>if (_mesa_is_stencil_format(internalformat) ||
>_mesa_is_depthstencil_format(internalformat))
>   buffer[0] = GL_TRUE;
>break;
>
> case GL_COLOR_RENDERABLE:
> case GL_DEPTH_RENDERABLE:
> case GL_STENCIL_RENDERABLE:
>if (!_is_renderable(ctx, internalformat))
>   goto end;
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: fix GL_{COLOR, DEPTH, STENCIL}_COMPONENTS queries for TBOs

[Marek Olšák]

From: Marek Olšák 

---
 src/mesa/main/formatquery.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/mesa/main/formatquery.c b/src/mesa/main/formatquery.c
index 05b7810..9c53d7c 100644
--- a/src/mesa/main/formatquery.c
+++ b/src/mesa/main/formatquery.c
@@ -1094,43 +1094,54 @@ _mesa_GetInternalformativ(GLenum target, GLenum 
internalformat, GLenum pname,
}
 
case GL_COLOR_COMPONENTS:
   /* The ARB_internalformat_query2 spec says:
*
* "- COLOR_COMPONENTS: If the internal format contains any color
* components (R, G, B, or A), TRUE is returned in .
* If the internal format is unsupported or contains no color
* components, FALSE is returned."
*/
+  if (target == GL_TEXTURE_BUFFER &&
+  _mesa_validate_texbuffer_format(ctx, internalformat) ==
+  MESA_FORMAT_NONE)
+ break;
+
   if (_mesa_is_color_format(internalformat))
  buffer[0] = GL_TRUE;
   break;
 
case GL_DEPTH_COMPONENTS:
   /* The ARB_internalformat_query2 spec says:
*
* "- DEPTH_COMPONENTS: If the internal format contains a depth
* component (D), TRUE is returned in . If the internal 
format
* is unsupported or contains no depth component, FALSE is returned."
*/
+  if (target == GL_TEXTURE_BUFFER)
+ break;
+
   if (_mesa_is_depth_format(internalformat) ||
   _mesa_is_depthstencil_format(internalformat))
  buffer[0] = GL_TRUE;
   break;
 
case GL_STENCIL_COMPONENTS:
   /* The ARB_internalformat_query2 spec says:
*
* "- STENCIL_COMPONENTS: If the internal format contains a stencil
* component (S), TRUE is returned in . If the internal 
format
* is unsupported or contains no stencil component, FALSE is 
returned.
*/
+  if (target == GL_TEXTURE_BUFFER)
+ break;
+
   if (_mesa_is_stencil_format(internalformat) ||
   _mesa_is_depthstencil_format(internalformat))
  buffer[0] = GL_TRUE;
   break;
 
case GL_COLOR_RENDERABLE:
case GL_DEPTH_RENDERABLE:
case GL_STENCIL_RENDERABLE:
   if (!_is_renderable(ctx, internalformat))
  goto end;
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH v3] egl/wayland: Support for KHR_partial_update

[Harish Krupo]

Hi Emil,

Emil Velikov  writes:

> On 23 October 2017 at 11:50, Harish Krupo  wrote:
>> This passes 33/37 deqp tests related to partial_update, 4 are not
>> supported. Tests not supported:
>> dEQP-EGL.functional.negative_partial_update.not_postable_surface
>> dEQP-EGL.functional.negative_partial_update.not_current_surface
>> dEQP-EGL.functional.negative_partial_update.buffer_preserved
>> dEQP-EGL.functional.negative_partial_update.not_current_surface2
>> Reason: No matching egl config found.
>>
>> v2: Remove unnecessary return statement. Keep function names
>> consistent.  (Emil Velikov)
>> Add not supported list to commit message. (Eric Engestrom)
>>
>> v3: Remove explicit with_damage variable. (Eric Engestrom)
>>
> Did you send the wrong version by any chance?
> The summary does not reflect the actual changes.
>

Sorry, should have actually been:
v3: Remove explicit with_damage variable and swap_buffers_common
function. Make SwapBuffers and SwapBuffersWithDamage(NULL,0)
equivalent in behavior. Fix called via comment for
swap_buffers_with_damage. (Eric Engestrom)
Rework try_buffer_damage into set_damage_region as it is being
called only from set_damage_region.

> Why did you rework try_damage_buffer into dri2_wl_set_damage_region?
> It seems harder to follow over the previous patches.
>

As try_damage_buffer was being used only in dri2_wl_set_damage_region
and swap_buffers_with_damage was calling set_damage_region so I removed
the unnecessary (extra) call to try_damage_region from set_damage_region
and reworked try_damage_region to set_damage_region. Do we need to keep
try_damage_region? If so, I will break them into two separate functions.

>
>> @@ -928,7 +944,8 @@ dri2_wl_query_buffer_age(_EGLDriver *drv,
>>  static EGLBoolean
>>  dri2_wl_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *draw)
>>  {
>> -   return dri2_wl_swap_buffers_with_damage(drv, disp, draw, NULL, 0);
>> +   return dri2_wl_swap_buffers_with_damage(drv, disp, draw,
>> +  NULL, 0);
>
> Unrelated noop change.
>

I had previously broken it into two lines to accomodate the EGL_TRUE
change. After removing it I forgot to set it back to the same line. Will
fix this.

Thank you

Regards
Harish Krupo

> Thanks
> Emil

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

Re: [Mesa-dev] [PATCH v3 17/34] intel/compiler: Remove final_program_size from brw_compile_*

[Jason Ekstrand]

On Mon, Oct 23, 2017 at 5:11 PM, Jordan Justen 
wrote:

> Attached is the missing change to brw_vec4_gs_visitor.cpp, which Jason
> pointed out. The issue was hiding out in a compiler warning.
>

We should be able to drop the final_program_size variable.  I think that
would be a bit more fool-proof.  Other than that, this patch (with the
attached squash-in) is

Reviewed-by: Jason Ekstrand 


> -Jordan
>
> On 2017-10-22 13:01:25, Jordan Justen wrote:
> > The caller can now use brw_stage_prog_data::program_size which is set
> > by the brw_compile_* functions.
> >
> > Cc: Jason Ekstrand 
> > Signed-off-by: Jordan Justen 
> > ---
> >  src/intel/blorp/blorp.c | 10 --
> >  src/intel/blorp/blorp_blit.c|  5 ++---
> >  src/intel/blorp/blorp_clear.c   | 15 ++-
> >  src/intel/blorp/blorp_priv.h|  6 ++
> >  src/intel/compiler/brw_compiler.h   |  6 --
> >  src/intel/compiler/brw_fs.cpp   | 10 ++
> >  src/intel/compiler/brw_shader.cpp   |  8 
> >  src/intel/compiler/brw_vec4.cpp |  8 
> >  src/intel/compiler/brw_vec4_tcs.cpp |  8 
> >  src/intel/vulkan/anv_pipeline.c | 23 ---
> >  src/mesa/drivers/dri/i965/brw_cs.c  |  5 ++---
> >  src/mesa/drivers/dri/i965/brw_gs.c  |  5 ++---
> >  src/mesa/drivers/dri/i965/brw_tcs.c |  5 ++---
> >  src/mesa/drivers/dri/i965/brw_tes.c |  5 ++---
> >  src/mesa/drivers/dri/i965/brw_vs.c  | 11 +--
> >  src/mesa/drivers/dri/i965/brw_wm.c  |  5 ++---
> >  16 files changed, 55 insertions(+), 80 deletions(-)
> >
> > diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
> > index 7cc6335f2f6..5faba75b8db 100644
> > --- a/src/intel/blorp/blorp.c
> > +++ b/src/intel/blorp/blorp.c
> > @@ -162,8 +162,7 @@ blorp_compile_fs(struct blorp_context *blorp, void
> *mem_ctx,
> >   struct nir_shader *nir,
> >   struct brw_wm_prog_key *wm_key,
> >   bool use_repclear,
> > - struct brw_wm_prog_data *wm_prog_data,
> > - unsigned *program_size)
> > + struct brw_wm_prog_data *wm_prog_data)
> >  {
> > const struct brw_compiler *compiler = blorp->compiler;
> >
> > @@ -194,7 +193,7 @@ blorp_compile_fs(struct blorp_context *blorp, void
> *mem_ctx,
> > const unsigned *program =
> >brw_compile_fs(compiler, blorp->driver_ctx, mem_ctx, wm_key,
> >   wm_prog_data, nir, NULL, -1, -1, false,
> use_repclear,
> > - NULL, program_size, NULL);
> > + NULL, NULL);
> >
> > return program;
> >  }
> > @@ -202,8 +201,7 @@ blorp_compile_fs(struct blorp_context *blorp, void
> *mem_ctx,
> >  const unsigned *
> >  blorp_compile_vs(struct blorp_context *blorp, void *mem_ctx,
> >   struct nir_shader *nir,
> > - struct brw_vs_prog_data *vs_prog_data,
> > - unsigned *program_size)
> > + struct brw_vs_prog_data *vs_prog_data)
> >  {
> > const struct brw_compiler *compiler = blorp->compiler;
> >
> > @@ -225,7 +223,7 @@ blorp_compile_vs(struct blorp_context *blorp, void
> *mem_ctx,
> > const unsigned *program =
> >brw_compile_vs(compiler, blorp->driver_ctx, mem_ctx,
> >   _key, vs_prog_data, nir,
> > - false, -1, program_size, NULL);
> > + false, -1, NULL);
> >
> > return program;
> >  }
> > diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> > index 4507046dae5..9b5c1f1f8c1 100644
> > --- a/src/intel/blorp/blorp_blit.c
> > +++ b/src/intel/blorp/blorp_blit.c
> > @@ -1308,7 +1308,6 @@ brw_blorp_get_blit_kernel(struct blorp_context
> *blorp,
> > void *mem_ctx = ralloc_context(NULL);
> >
> > const unsigned *program;
> > -   unsigned program_size;
> > struct brw_wm_prog_data prog_data;
> >
> > nir_shader *nir = brw_blorp_build_nir_shader(blorp, mem_ctx,
> prog_key);
> > @@ -1322,11 +1321,11 @@ brw_blorp_get_blit_kernel(struct blorp_context
> *blorp,
> > wm_key.multisample_fbo = prog_key->rt_samples > 1;
> >
> > program = blorp_compile_fs(blorp, mem_ctx, nir, _key, false,
> > -  _data, _size);
> > +  _data);
> >
> > bool result =
> >blorp->upload_shader(blorp, prog_key, sizeof(*prog_key),
> > -   program, program_size,
> > +   program, prog_data.base.program_size,
> > _data.base, sizeof(prog_data),
> > >wm_prog_kernel,
> >wm_prog_data);
> >
> > diff --git a/src/intel/blorp/blorp_clear.c
> b/src/intel/blorp/blorp_clear.c
> > index cd83fa13caf..8d758df155f 100644
> > --- a/src/intel/blorp/blorp_clear.c
> > +++ b/src/intel/blorp/blorp_clear.c
> > @@ -75,14 +75,13 @@ 

[Mesa-dev] [PATCH 1/3] i965/blorp: Use blorp_to_isl_format for src_isl_format in blit_miptrees

[Jason Ekstrand]

---
 src/mesa/drivers/dri/i965/brw_blorp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index ed4f987..f7d128d 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -315,7 +315,8 @@ brw_blorp_blit_miptrees(struct brw_context *brw,
   src_format = dst_format = MESA_FORMAT_R_FLOAT32;
}
 
-   enum isl_format src_isl_format = brw_isl_format_for_mesa_format(src_format);
+   enum isl_format src_isl_format =
+  brw_blorp_to_isl_format(brw, src_format, false);
enum isl_aux_usage src_aux_usage =
   intel_miptree_texture_aux_usage(brw, src_mt, src_isl_format);
/* We do format workarounds for some depth formats so we can't reliably
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 3/3] i965/miptree: Take an isl_format in render_aux_usage

[Jason Ekstrand]

Not all rendering matches the miptree format.  We allow rendering to
texture views so there are cases where it may not match.  In those
cases, our current scheme of just passing the value of ctx->sRGBEnabled
isn't viable.  Instead, just do what we do for texturing and pass the
view format in directly.
---
 src/mesa/drivers/dri/i965/brw_blorp.c|  8 
 src/mesa/drivers/dri/i965/brw_draw.c | 13 +++--
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 13 +++--
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 23 +++
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h|  9 ++---
 5 files changed, 39 insertions(+), 27 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 05204a9..58e1f8a 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -332,7 +332,7 @@ brw_blorp_blit_miptrees(struct brw_context *brw,
enum isl_format dst_isl_format =
   brw_blorp_to_isl_format(brw, dst_format, true);
enum isl_aux_usage dst_aux_usage =
-  intel_miptree_render_aux_usage(brw, dst_mt, encode_srgb, false);
+  intel_miptree_render_aux_usage(brw, dst_mt, dst_isl_format, false);
const bool dst_clear_supported = dst_aux_usage != ISL_AUX_USAGE_NONE;
intel_miptree_prepare_access(brw, dst_mt, dst_level, 1, dst_layer, 1,
 dst_aux_usage, dst_clear_supported);
@@ -1277,9 +1277,9 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
   irb->mt, irb->mt_level, irb->mt_layer, num_layers);
 
   enum isl_aux_usage aux_usage =
- intel_miptree_render_aux_usage(brw, irb->mt, encode_srgb, false);
+ intel_miptree_render_aux_usage(brw, irb->mt, isl_format, false);
   intel_miptree_prepare_render(brw, irb->mt, level, irb->mt_layer,
-   num_layers, encode_srgb, false);
+   num_layers, isl_format, false);
 
   struct isl_surf isl_tmp[2];
   struct blorp_surf surf;
@@ -1298,7 +1298,7 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
   blorp_batch_finish();
 
   intel_miptree_finish_render(brw, irb->mt, level, irb->mt_layer,
-  num_layers, encode_srgb, false);
+  num_layers, isl_format, false);
}
 
return;
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index b74ab8b..1e5c499 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -25,6 +25,7 @@
 
 #include 
 
+#include "main/blend.h"
 #include "main/context.h"
 #include "main/condrender.h"
 #include "main/samplerobj.h"
@@ -503,9 +504,13 @@ brw_predraw_resolve_framebuffer(struct brw_context *brw)
   if (irb == NULL || irb->mt == NULL)
  continue;
 
+  mesa_format mesa_format =
+ _mesa_get_render_format(ctx, intel_rb_format(irb));
+  enum isl_format isl_format = brw_isl_format_for_mesa_format(mesa_format);
+
   intel_miptree_prepare_render(brw, irb->mt, irb->mt_level,
irb->mt_layer, irb->layer_count,
-   ctx->Color.sRGBEnabled,
+   isl_format,
ctx->Color.BlendEnabled & (1 << i));
}
 }
@@ -571,10 +576,14 @@ brw_postdraw_set_buffers_need_resolve(struct brw_context 
*brw)
   if (!irb)
  continue;
 
+  mesa_format mesa_format =
+ _mesa_get_render_format(ctx, intel_rb_format(irb));
+  enum isl_format isl_format = brw_isl_format_for_mesa_format(mesa_format);
+
   brw_render_cache_set_add_bo(brw, irb->mt->bo);
   intel_miptree_finish_render(brw, irb->mt, irb->mt_level,
   irb->mt_layer, irb->layer_count,
-  ctx->Color.sRGBEnabled,
+  isl_format,
   ctx->Color.BlendEnabled & (1 << i));
}
 }
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index f4e9cf4..d668cd8 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -213,11 +213,6 @@ gen6_update_renderbuffer_surface(struct brw_context *brw,
struct intel_renderbuffer *irb = intel_renderbuffer(rb);
struct intel_mipmap_tree *mt = irb->mt;
 
-   enum isl_aux_usage aux_usage =
-  brw->draw_aux_buffer_disabled[unit] ? ISL_AUX_USAGE_NONE :
-  intel_miptree_render_aux_usage(brw, mt, ctx->Color.sRGBEnabled,
- ctx->Color.BlendEnabled & (1 << unit));
-
assert(brw_render_target_supported(brw, rb));
 
mesa_format rb_format = _mesa_get_render_format(ctx, intel_rb_format(irb));
@@ -225,9 +220,15 @@ 

[Mesa-dev] [PATCH 2/3] i965/blorp: Use more temporary isl_format variables

[Jason Ekstrand]

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

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index f7d128d..05204a9 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -329,6 +329,8 @@ brw_blorp_blit_miptrees(struct brw_context *brw,
intel_miptree_prepare_access(brw, src_mt, src_level, 1, src_layer, 1,
 src_aux_usage, src_clear_supported);
 
+   enum isl_format dst_isl_format =
+  brw_blorp_to_isl_format(brw, dst_format, true);
enum isl_aux_usage dst_aux_usage =
   intel_miptree_render_aux_usage(brw, dst_mt, encode_srgb, false);
const bool dst_clear_supported = dst_aux_usage != ISL_AUX_USAGE_NONE;
@@ -352,10 +354,9 @@ brw_blorp_blit_miptrees(struct brw_context *brw,
struct blorp_batch batch;
blorp_batch_init(>blorp, , brw, 0);
blorp_blit(, _surf, src_level, src_layer,
-  brw_blorp_to_isl_format(brw, src_format, false), src_isl_swizzle,
+  src_isl_format, src_isl_swizzle,
   _surf, dst_level, dst_layer,
-  brw_blorp_to_isl_format(brw, dst_format, true),
-  ISL_SWIZZLE_IDENTITY,
+  dst_isl_format, ISL_SWIZZLE_IDENTITY,
   src_x0, src_y0, src_x1, src_y1,
   dst_x0, dst_y0, dst_x1, dst_y1,
   filter, mirror_x, mirror_y);
@@ -1158,6 +1159,7 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
mesa_format format = irb->Base.Base.Format;
if (!encode_srgb && _mesa_get_format_color_encoding(format) == GL_SRGB)
   format = _mesa_get_srgb_format_linear(format);
+   enum isl_format isl_format = brw->mesa_to_isl_render_format[format];
 
x0 = fb->_Xmin;
x1 = fb->_Xmax;
@@ -1256,8 +1258,7 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
 
   struct blorp_batch batch;
   blorp_batch_init(>blorp, , brw, 0);
-  blorp_fast_clear(, ,
-   brw->mesa_to_isl_render_format[format],
+  blorp_fast_clear(, , isl_format,
level, irb->mt_layer, num_layers,
x0, y0, x1, y1);
   blorp_batch_finish();
@@ -1290,9 +1291,7 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
 
   struct blorp_batch batch;
   blorp_batch_init(>blorp, , brw, 0);
-  blorp_clear(, ,
-  brw->mesa_to_isl_render_format[format],
-  ISL_SWIZZLE_IDENTITY,
+  blorp_clear(, , isl_format, ISL_SWIZZLE_IDENTITY,
   level, irb->mt_layer, num_layers,
   x0, y0, x1, y1,
   clear_color, color_write_disable);
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH v3 17/34] intel/compiler: Remove final_program_size from brw_compile_*

[Jordan Justen]

Attached is the missing change to brw_vec4_gs_visitor.cpp, which Jason
pointed out. The issue was hiding out in a compiler warning.

-Jordan

On 2017-10-22 13:01:25, Jordan Justen wrote:
> The caller can now use brw_stage_prog_data::program_size which is set
> by the brw_compile_* functions.
> 
> Cc: Jason Ekstrand 
> Signed-off-by: Jordan Justen 
> ---
>  src/intel/blorp/blorp.c | 10 --
>  src/intel/blorp/blorp_blit.c|  5 ++---
>  src/intel/blorp/blorp_clear.c   | 15 ++-
>  src/intel/blorp/blorp_priv.h|  6 ++
>  src/intel/compiler/brw_compiler.h   |  6 --
>  src/intel/compiler/brw_fs.cpp   | 10 ++
>  src/intel/compiler/brw_shader.cpp   |  8 
>  src/intel/compiler/brw_vec4.cpp |  8 
>  src/intel/compiler/brw_vec4_tcs.cpp |  8 
>  src/intel/vulkan/anv_pipeline.c | 23 ---
>  src/mesa/drivers/dri/i965/brw_cs.c  |  5 ++---
>  src/mesa/drivers/dri/i965/brw_gs.c  |  5 ++---
>  src/mesa/drivers/dri/i965/brw_tcs.c |  5 ++---
>  src/mesa/drivers/dri/i965/brw_tes.c |  5 ++---
>  src/mesa/drivers/dri/i965/brw_vs.c  | 11 +--
>  src/mesa/drivers/dri/i965/brw_wm.c  |  5 ++---
>  16 files changed, 55 insertions(+), 80 deletions(-)
> 
> diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
> index 7cc6335f2f6..5faba75b8db 100644
> --- a/src/intel/blorp/blorp.c
> +++ b/src/intel/blorp/blorp.c
> @@ -162,8 +162,7 @@ blorp_compile_fs(struct blorp_context *blorp, void 
> *mem_ctx,
>   struct nir_shader *nir,
>   struct brw_wm_prog_key *wm_key,
>   bool use_repclear,
> - struct brw_wm_prog_data *wm_prog_data,
> - unsigned *program_size)
> + struct brw_wm_prog_data *wm_prog_data)
>  {
> const struct brw_compiler *compiler = blorp->compiler;
>  
> @@ -194,7 +193,7 @@ blorp_compile_fs(struct blorp_context *blorp, void 
> *mem_ctx,
> const unsigned *program =
>brw_compile_fs(compiler, blorp->driver_ctx, mem_ctx, wm_key,
>   wm_prog_data, nir, NULL, -1, -1, false, use_repclear,
> - NULL, program_size, NULL);
> + NULL, NULL);
>  
> return program;
>  }
> @@ -202,8 +201,7 @@ blorp_compile_fs(struct blorp_context *blorp, void 
> *mem_ctx,
>  const unsigned *
>  blorp_compile_vs(struct blorp_context *blorp, void *mem_ctx,
>   struct nir_shader *nir,
> - struct brw_vs_prog_data *vs_prog_data,
> - unsigned *program_size)
> + struct brw_vs_prog_data *vs_prog_data)
>  {
> const struct brw_compiler *compiler = blorp->compiler;
>  
> @@ -225,7 +223,7 @@ blorp_compile_vs(struct blorp_context *blorp, void 
> *mem_ctx,
> const unsigned *program =
>brw_compile_vs(compiler, blorp->driver_ctx, mem_ctx,
>   _key, vs_prog_data, nir,
> - false, -1, program_size, NULL);
> + false, -1, NULL);
>  
> return program;
>  }
> diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> index 4507046dae5..9b5c1f1f8c1 100644
> --- a/src/intel/blorp/blorp_blit.c
> +++ b/src/intel/blorp/blorp_blit.c
> @@ -1308,7 +1308,6 @@ brw_blorp_get_blit_kernel(struct blorp_context *blorp,
> void *mem_ctx = ralloc_context(NULL);
>  
> const unsigned *program;
> -   unsigned program_size;
> struct brw_wm_prog_data prog_data;
>  
> nir_shader *nir = brw_blorp_build_nir_shader(blorp, mem_ctx, prog_key);
> @@ -1322,11 +1321,11 @@ brw_blorp_get_blit_kernel(struct blorp_context *blorp,
> wm_key.multisample_fbo = prog_key->rt_samples > 1;
>  
> program = blorp_compile_fs(blorp, mem_ctx, nir, _key, false,
> -  _data, _size);
> +  _data);
>  
> bool result =
>blorp->upload_shader(blorp, prog_key, sizeof(*prog_key),
> -   program, program_size,
> +   program, prog_data.base.program_size,
> _data.base, sizeof(prog_data),
> >wm_prog_kernel, >wm_prog_data);
>  
> diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
> index cd83fa13caf..8d758df155f 100644
> --- a/src/intel/blorp/blorp_clear.c
> +++ b/src/intel/blorp/blorp_clear.c
> @@ -75,14 +75,13 @@ blorp_params_get_clear_kernel(struct blorp_context *blorp,
> brw_blorp_init_wm_prog_key(_key);
>  
> struct brw_wm_prog_data prog_data;
> -   unsigned program_size;
> const unsigned *program =
>blorp_compile_fs(blorp, mem_ctx, b.shader, _key, 
> use_replicated_data,
> -   _data, _size);
> +   _data);
>  
> bool result =
>blorp->upload_shader(blorp, _key, sizeof(blorp_key),
> -   program, program_size,
> +   

[Mesa-dev] [Bug 103312] meson/macOS: Dependency libdrm_intel found: NO

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #4 from Dylan Baker  ---
Okay, I've found a macbook and I'm going to look into getting meson working for
macos. I need some information though.

What configuration options are supposed to work on macOS? swrast? softpipe?
llvmpipe? osmesa? glx? egl? obviously not dri drivers.

What autotools configuration did you provide?

What packages did you have to install from source/macports/homebrew/etc.

-- 
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] i965: Revert absolute mode for constant buffer pointers.

[Kenneth Graunke]

On Monday, October 23, 2017 3:53:15 PM PDT Rodrigo Vivi wrote:
> On Mon, Oct 23, 2017 at 10:32:43PM +, Jordan Justen wrote:
> > On 2017-10-19 16:30:44, Kristian Høgsberg wrote:
> > > On Thu, Oct 19, 2017 at 4:18 PM, Kenneth Graunke  
> > > wrote:
> > > > The kernel doesn't initialize the value of the INSTPM or CS_DEBUG_MODE2
> > > > registers at context initialization time.  Instead, they're inherited
> > > > from whatever happened to be running on the GPU prior to first run of a
> > > > new context.  So, when we started setting these, other contexts in the
> > > > system started inheriting our values.  Since this controls whether
> > > > 3DSTATE_CONSTANT_* takes a pointer or an offset, getting the wrong
> > > > setting is fatal for almost any process which isn't expecting this.
> > > >
> > > > Unfortunately, VA-API and Beignet don't initialize this (nor does older
> > > > Mesa), so they will die horribly if we start doing this.  UXA and SNA
> > > > don't use any push constants, so they are unaffected.
> > > >
> > > > The kernel developers are apparently uninterested in making the proto-
> > > > context initialize these registers to guarantee deterministic behavior.
> > > 
> > > Could somebody from the kernel team elaborate here? This is obviously
> > > broken and undermines the security and containerization that hw
> > > contexts are supposed to provide. I'm really curious what the thinking
> > > is here...
> > > 
> > > Kristian
> > 
> > Cc intel-gfx, maintainers
> 
> Is this the null-state/golden-context related discussions?
> 
> I assume we are ok for older platforms, but the problem would be only for
> CNL+ where we are not adding the null context initialization yet.
> Am I getting it right?

No, this problem exists on earlier platforms as well.  We saw the issue
on Broadwell and Kabylake.


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] radv: move nir print after linking is done

[Bas Nieuwenhuizen]

r-b

On Tue, Oct 24, 2017 at 12:59 AM, Timothy Arceri  wrote:
> We now have linking optimisation so we want to delay dumping the
> nir until after these are complete.
>
> Fixes: 06f05040eb73 (radv: Link shaders)
> ---
>  src/amd/vulkan/radv_pipeline.c | 9 +++--
>  src/amd/vulkan/radv_shader.c   | 3 ---
>  2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index 30a90ac960..d6b33a5327 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -1863,22 +1863,27 @@ void radv_create_shaders(struct radv_pipeline 
> *pipeline,
>code_size);
> }
> free(gs_copy_code);
> }
>
> radv_pipeline_cache_insert_shaders(device, cache, hash, 
> pipeline->shaders,
>(const void**)codes, code_sizes);
>
> for (int i = 0; i < MESA_SHADER_STAGES; ++i) {
> free(codes[i]);
> -   if (modules[i] && !pipeline->device->trace_bo)
> -   ralloc_free(nir[i]);
> +   if (modules[i]) {
> +   if (device->instance->debug_flags & 
> RADV_DEBUG_DUMP_SHADERS)
> +   nir_print_shader(nir[i], stderr);
> +
> +   if (!pipeline->device->trace_bo)
> +   ralloc_free(nir[i]);
> +   }
> }
>
> if (fs_m.nir)
> ralloc_free(fs_m.nir);
>  }
>
>  static VkResult
>  radv_pipeline_init(struct radv_pipeline *pipeline,
>struct radv_device *device,
>struct radv_pipeline_cache *cache,
> diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
> index 6176a2e590..5903917068 100644
> --- a/src/amd/vulkan/radv_shader.c
> +++ b/src/amd/vulkan/radv_shader.c
> @@ -284,23 +284,20 @@ radv_shader_compile_to_nir(struct radv_device *device,
> };
>
> nir_lower_tex(nir, _options);
>
> nir_lower_vars_to_ssa(nir);
> nir_lower_var_copies(nir);
> nir_lower_global_vars_to_local(nir);
> nir_remove_dead_variables(nir, nir_var_local);
> radv_optimize_nir(nir);
>
> -   if (device->instance->debug_flags & RADV_DEBUG_DUMP_SHADERS)
> -   nir_print_shader(nir, stderr);
> -
> return nir;
>  }
>
>  void *
>  radv_alloc_shader_memory(struct radv_device *device,
>  struct radv_shader_variant *shader)
>  {
> mtx_lock(>shader_slab_mutex);
> list_for_each_entry(struct radv_shader_slab, slab, 
> >shader_slabs, slabs) {
> uint64_t offset = 0;
> --
> 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

[Mesa-dev] [PATCH] radv: move nir print after linking is done

[Timothy Arceri]

We now have linking optimisation so we want to delay dumping the
nir until after these are complete.

Fixes: 06f05040eb73 (radv: Link shaders)
---
 src/amd/vulkan/radv_pipeline.c | 9 +++--
 src/amd/vulkan/radv_shader.c   | 3 ---
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 30a90ac960..d6b33a5327 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1863,22 +1863,27 @@ void radv_create_shaders(struct radv_pipeline *pipeline,
   code_size);
}
free(gs_copy_code);
}
 
radv_pipeline_cache_insert_shaders(device, cache, hash, 
pipeline->shaders,
   (const void**)codes, code_sizes);
 
for (int i = 0; i < MESA_SHADER_STAGES; ++i) {
free(codes[i]);
-   if (modules[i] && !pipeline->device->trace_bo)
-   ralloc_free(nir[i]);
+   if (modules[i]) {
+   if (device->instance->debug_flags & 
RADV_DEBUG_DUMP_SHADERS)
+   nir_print_shader(nir[i], stderr);
+
+   if (!pipeline->device->trace_bo)
+   ralloc_free(nir[i]);
+   }
}
 
if (fs_m.nir)
ralloc_free(fs_m.nir);
 }
 
 static VkResult
 radv_pipeline_init(struct radv_pipeline *pipeline,
   struct radv_device *device,
   struct radv_pipeline_cache *cache,
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 6176a2e590..5903917068 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -284,23 +284,20 @@ radv_shader_compile_to_nir(struct radv_device *device,
};
 
nir_lower_tex(nir, _options);
 
nir_lower_vars_to_ssa(nir);
nir_lower_var_copies(nir);
nir_lower_global_vars_to_local(nir);
nir_remove_dead_variables(nir, nir_var_local);
radv_optimize_nir(nir);
 
-   if (device->instance->debug_flags & RADV_DEBUG_DUMP_SHADERS)
-   nir_print_shader(nir, stderr);
-
return nir;
 }
 
 void *
 radv_alloc_shader_memory(struct radv_device *device,
 struct radv_shader_variant *shader)
 {
mtx_lock(>shader_slab_mutex);
list_for_each_entry(struct radv_shader_slab, slab, 
>shader_slabs, slabs) {
uint64_t offset = 0;
-- 
2.13.6

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

Re: [Mesa-dev] [PATCH] i965: Revert absolute mode for constant buffer pointers.

[Rodrigo Vivi]

On Mon, Oct 23, 2017 at 10:32:43PM +, Jordan Justen wrote:
> On 2017-10-19 16:30:44, Kristian Høgsberg wrote:
> > On Thu, Oct 19, 2017 at 4:18 PM, Kenneth Graunke  
> > wrote:
> > > The kernel doesn't initialize the value of the INSTPM or CS_DEBUG_MODE2
> > > registers at context initialization time.  Instead, they're inherited
> > > from whatever happened to be running on the GPU prior to first run of a
> > > new context.  So, when we started setting these, other contexts in the
> > > system started inheriting our values.  Since this controls whether
> > > 3DSTATE_CONSTANT_* takes a pointer or an offset, getting the wrong
> > > setting is fatal for almost any process which isn't expecting this.
> > >
> > > Unfortunately, VA-API and Beignet don't initialize this (nor does older
> > > Mesa), so they will die horribly if we start doing this.  UXA and SNA
> > > don't use any push constants, so they are unaffected.
> > >
> > > The kernel developers are apparently uninterested in making the proto-
> > > context initialize these registers to guarantee deterministic behavior.
> > 
> > Could somebody from the kernel team elaborate here? This is obviously
> > broken and undermines the security and containerization that hw
> > contexts are supposed to provide. I'm really curious what the thinking
> > is here...
> > 
> > Kristian
> 
> Cc intel-gfx, maintainers

Is this the null-state/golden-context related discussions?

I assume we are ok for older platforms, but the problem would be only for
CNL+ where we are not adding the null context initialization yet.
Am I getting it right?

> 
> > 
> > > Apparently, the "Default Value" of registers in the documentation is a
> > > total lie, and cannot be relied upon by userspace.  So, we need to find
> > > a new solution.  One would be to patch VA-API and Beignet to initialize
> > > these, then get every distributor to ship those in tandem with the newer
> > > Mesa version.  I'm unclear when va-intel-driver releases might happen.
> > > Another option would be to hack Mesa to restore the register back to the
> > > historical default (relative mode) at the end of each batch.  This is
> > > also gross, as it has non-zero cost, and is also relying on userspace to
> > > be "polite" to other broken userspace.  A large part of the motivation
> > > for contexts was to provide proper process isolation, so we should not
> > > have to do this.  But, we're already doing it in some cases, because
> > > our kernel fixes to enforce isolation were reverted.
> > >
> > > In the meantime, I guess we'll just revert this patch and abandon using
> > > the feature.  It will lead to fewer pushed UBOs on Broadwell+, which may
> > > lead to lower performance, but I don't have any data on the impact.
> > >
> > > Cc: "17.2" 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102774
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_state_upload.c | 24 
> > > 
> > >  src/mesa/drivers/dri/i965/intel_screen.c |  2 +-
> > >  2 files changed, 1 insertion(+), 25 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
> > > b/src/mesa/drivers/dri/i965/brw_state_upload.c
> > > index 16f44d03bbe..23e4ebda259 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> > > @@ -101,30 +101,6 @@ brw_upload_initial_gpu_state(struct brw_context *brw)
> > >OUT_BATCH(0);
> > >ADVANCE_BATCH();
> > > }
> > > -
> > > -   /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
> > > -* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
> > > -*
> > > -* On Gen6-7.5, we use an execbuf parameter to do this for us.
> > > -* However, the kernel ignores that when execlists are in use.
> > > -* Fortunately, we can just write the registers from userspace
> > > -* on Gen8+, and they're context saved/restored.
> > > -*/
> > > -   if (devinfo->gen >= 9) {
> > > -  BEGIN_BATCH(3);
> > > -  OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
> > > -  OUT_BATCH(CS_DEBUG_MODE2);
> > > -  OUT_BATCH(REG_MASK(CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
> > > -CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
> > > -  ADVANCE_BATCH();
> > > -   } else if (devinfo->gen == 8) {
> > > -  BEGIN_BATCH(3);
> > > -  OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
> > > -  OUT_BATCH(INSTPM);
> > > -  OUT_BATCH(REG_MASK(INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
> > > -INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
> > > -  ADVANCE_BATCH();
> > > -   }
> > >  }
> > >
> > >  static inline const struct brw_tracked_state *
> > > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> > > b/src/mesa/drivers/dri/i965/intel_screen.c
> > > index ea04a72e860..776c2898d5b 100644
> > > --- a/src/mesa/drivers/dri/i965/intel_screen.c
> > > +++ 

[Mesa-dev] [PATCH] st/mesa: enable nir path for all shaders.

[Dave Airlie]

From: Dave Airlie 

There is no reason to block this here, if a driver enables
it, let it handle it.

Signed-off-by: Dave Airlie 
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index a45f0047a8..9599402056 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -6976,15 +6976,7 @@ st_link_shader(struct gl_context *ctx, struct 
gl_shader_program *prog)
 
   struct gl_program *linked_prog = NULL;
   if (preferred_ir == PIPE_SHADER_IR_NIR) {
- /* TODO only for GLSL VS/FS/CS for now: */
- switch (shader->Stage) {
- case MESA_SHADER_VERTEX:
- case MESA_SHADER_FRAGMENT:
- case MESA_SHADER_COMPUTE:
-linked_prog = st_nir_get_mesa_program(ctx, prog, shader);
- default:
-break;
- }
+ linked_prog = st_nir_get_mesa_program(ctx, prog, shader);
   } else {
  linked_prog = get_mesa_program_tgsi(ctx, prog, shader);
   }
-- 
2.14.2

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

[Mesa-dev] [PATCH 2/2] st/program: add support for gs/tes/tcs nir shaders.

[Dave Airlie]

From: Dave Airlie 

This probably needs more work but this just add the initial
code to convert gs/tcs/tes nir based shaders in the state tracker.

Signed-off-by: Dave Airlie 
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp | 12 +
 src/mesa/state_tracker/st_program.c   | 45 ---
 src/mesa/state_tracker/st_program.h   |  3 +++
 3 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 4effd8074e..e9a8d6414e 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -359,6 +359,11 @@ st_finalize_nir(struct st_context *st, struct gl_program 
*prog, nir_shader *nir)
case MESA_SHADER_VERTEX:
   shader_program = ((struct st_vertex_program *)prog)->shader_program;
   break;
+   case MESA_SHADER_GEOMETRY:
+   case MESA_SHADER_TESS_CTRL:
+   case MESA_SHADER_TESS_EVAL:
+  shader_program = ((struct st_common_program *)prog)->shader_program;
+  break;
case MESA_SHADER_FRAGMENT:
   shader_program = ((struct st_fragment_program *)prog)->shader_program;
   break;
@@ -451,6 +456,7 @@ st_nir_get_mesa_program(struct gl_context *ctx,
_mesa_associate_uniform_storage(ctx, shader_program, prog, true);
 
struct st_vertex_program *stvp;
+   struct st_common_program *stp;
struct st_fragment_program *stfp;
struct st_compute_program *stcp;
 
@@ -459,6 +465,12 @@ st_nir_get_mesa_program(struct gl_context *ctx,
   stvp = (struct st_vertex_program *)prog;
   stvp->shader_program = shader_program;
   break;
+   case MESA_SHADER_GEOMETRY:
+   case MESA_SHADER_TESS_CTRL:
+   case MESA_SHADER_TESS_EVAL:
+  stp = (struct st_common_program *)prog;
+  stp->shader_program = shader_program;
+  break;
case MESA_SHADER_FRAGMENT:
   stfp = (struct st_fragment_program *)prog;
   stfp->shader_program = shader_program;
diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 1695f4835d..335d45ba28 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -1576,6 +1576,16 @@ st_translate_geometry_program(struct st_context *st,
 {
struct ureg_program *ureg;
 
+   if (stgp->shader_program) {
+  nir_shader *nir = st_glsl_to_nir(st, >Base, stgp->shader_program,
+   MESA_SHADER_GEOMETRY);
+
+  stgp->tgsi.type = PIPE_SHADER_IR_NIR;
+  stgp->tgsi.ir.nir = nir;
+
+  return true;
+   }
+
ureg = ureg_create_with_screen(PIPE_SHADER_GEOMETRY, st->pipe->screen);
if (ureg == NULL)
   return false;
@@ -1609,7 +1619,7 @@ st_get_basic_variant(struct st_context *st,
struct pipe_context *pipe = st->pipe;
struct st_basic_variant *v;
struct st_basic_variant_key key;
-
+   struct pipe_shader_state tgsi = {0};
memset(, 0, sizeof(key));
key.st = st->has_shareable_shaders ? NULL : st;
 
@@ -1624,16 +1634,23 @@ st_get_basic_variant(struct st_context *st,
   /* create new */
   v = CALLOC_STRUCT(st_basic_variant);
   if (v) {
+
+if (prog->tgsi.type == PIPE_SHADER_IR_NIR) {
+   tgsi.type = PIPE_SHADER_IR_NIR;
+   tgsi.ir.nir = nir_shader_clone(NULL, prog->tgsi.ir.nir);
+   st_finalize_nir(st, >Base, tgsi.ir.nir);
+} else
+   tgsi = prog->tgsi;
  /* fill in new variant */
  switch (pipe_shader) {
  case PIPE_SHADER_TESS_CTRL:
-v->driver_shader = pipe->create_tcs_state(pipe, >tgsi);
+v->driver_shader = pipe->create_tcs_state(pipe, );
 break;
  case PIPE_SHADER_TESS_EVAL:
-v->driver_shader = pipe->create_tes_state(pipe, >tgsi);
+v->driver_shader = pipe->create_tes_state(pipe, );
 break;
  case PIPE_SHADER_GEOMETRY:
-v->driver_shader = pipe->create_gs_state(pipe, >tgsi);
+v->driver_shader = pipe->create_gs_state(pipe, );
 break;
  default:
 assert(!"unhandled shader type");
@@ -1662,6 +1679,16 @@ st_translate_tessctrl_program(struct st_context *st,
 {
struct ureg_program *ureg;
 
+   if (sttcp->shader_program) {
+  nir_shader *nir = st_glsl_to_nir(st, >Base, sttcp->shader_program,
+   MESA_SHADER_TESS_EVAL);
+
+  sttcp->tgsi.type = PIPE_SHADER_IR_NIR;
+  sttcp->tgsi.ir.nir = nir;
+
+  return true;
+   }
+
ureg = ureg_create_with_screen(PIPE_SHADER_TESS_CTRL, st->pipe->screen);
if (ureg == NULL)
   return false;
@@ -1687,6 +1714,16 @@ st_translate_tesseval_program(struct st_context *st,
 {
struct ureg_program *ureg;
 
+   if (sttep->shader_program) {
+  nir_shader *nir = st_glsl_to_nir(st, >Base, sttep->shader_program,
+   MESA_SHADER_TESS_EVAL);
+
+  sttep->tgsi.type = 

[Mesa-dev] [PATCH 1/2] st/program: rework basic variant interface

[Dave Airlie]

From: Dave Airlie 

This just passes st_common_program and uses it.

Signed-off-by: Dave Airlie 
---
 src/mesa/state_tracker/st_atom_shader.c |  3 +--
 src/mesa/state_tracker/st_program.c | 21 ++---
 src/mesa/state_tracker/st_program.h |  3 +--
 3 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom_shader.c 
b/src/mesa/state_tracker/st_atom_shader.c
index b5ba33a488..c6faa3f07f 100644
--- a/src/mesa/state_tracker/st_atom_shader.c
+++ b/src/mesa/state_tracker/st_atom_shader.c
@@ -215,8 +215,7 @@ st_update_common_program(struct st_context *st, struct 
gl_program *prog,
if (st->shader_has_one_variant[prog->info.stage] && stp->variants)
   return stp->variants->driver_shader;
 
-   return st_get_basic_variant(st, pipe_shader, >tgsi,
-   >variants)->driver_shader;
+   return st_get_basic_variant(st, pipe_shader, stp)->driver_shader;
 }
 
 
diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 41ebfa9003..1695f4835d 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -1604,8 +1604,7 @@ st_translate_geometry_program(struct st_context *st,
 struct st_basic_variant *
 st_get_basic_variant(struct st_context *st,
  unsigned pipe_shader,
- struct pipe_shader_state *tgsi,
- struct st_basic_variant **variants)
+ struct st_common_program *prog)
 {
struct pipe_context *pipe = st->pipe;
struct st_basic_variant *v;
@@ -1615,7 +1614,7 @@ st_get_basic_variant(struct st_context *st,
key.st = st->has_shareable_shaders ? NULL : st;
 
/* Search for existing variant */
-   for (v = *variants; v; v = v->next) {
+   for (v = prog->variants; v; v = v->next) {
   if (memcmp(>key, , sizeof(key)) == 0) {
  break;
   }
@@ -1628,13 +1627,13 @@ st_get_basic_variant(struct st_context *st,
  /* fill in new variant */
  switch (pipe_shader) {
  case PIPE_SHADER_TESS_CTRL:
-v->driver_shader = pipe->create_tcs_state(pipe, tgsi);
+v->driver_shader = pipe->create_tcs_state(pipe, >tgsi);
 break;
  case PIPE_SHADER_TESS_EVAL:
-v->driver_shader = pipe->create_tes_state(pipe, tgsi);
+v->driver_shader = pipe->create_tes_state(pipe, >tgsi);
 break;
  case PIPE_SHADER_GEOMETRY:
-v->driver_shader = pipe->create_gs_state(pipe, tgsi);
+v->driver_shader = pipe->create_gs_state(pipe, >tgsi);
 break;
  default:
 assert(!"unhandled shader type");
@@ -1645,8 +1644,8 @@ st_get_basic_variant(struct st_context *st,
  v->key = key;
 
  /* insert into list */
- v->next = *variants;
- *variants = v;
+ v->next = prog->variants;
+ prog->variants = v;
   }
}
 
@@ -2004,19 +2003,19 @@ st_precompile_shader_variant(struct st_context *st,
 
case GL_TESS_CONTROL_PROGRAM_NV: {
   struct st_common_program *p = st_common_program(prog);
-  st_get_basic_variant(st, PIPE_SHADER_TESS_CTRL, >tgsi, >variants);
+  st_get_basic_variant(st, PIPE_SHADER_TESS_CTRL, p);
   break;
}
 
case GL_TESS_EVALUATION_PROGRAM_NV: {
   struct st_common_program *p = st_common_program(prog);
-  st_get_basic_variant(st, PIPE_SHADER_TESS_EVAL, >tgsi, >variants);
+  st_get_basic_variant(st, PIPE_SHADER_TESS_EVAL, p);
   break;
}
 
case GL_GEOMETRY_PROGRAM_NV: {
   struct st_common_program *p = st_common_program(prog);
-  st_get_basic_variant(st, PIPE_SHADER_GEOMETRY, >tgsi, >variants);
+  st_get_basic_variant(st, PIPE_SHADER_GEOMETRY, p);
   break;
}
 
diff --git a/src/mesa/state_tracker/st_program.h 
b/src/mesa/state_tracker/st_program.h
index 8e9f4c5e82..27cc9b6e92 100644
--- a/src/mesa/state_tracker/st_program.h
+++ b/src/mesa/state_tracker/st_program.h
@@ -384,8 +384,7 @@ st_get_cp_variant(struct st_context *st,
 extern struct st_basic_variant *
 st_get_basic_variant(struct st_context *st,
  unsigned pipe_shader,
- struct pipe_shader_state *tgsi,
- struct st_basic_variant **variants);
+ struct st_common_program *p);
 
 extern void
 st_release_vp_variants( struct st_context *st,
-- 
2.14.2

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

Re: [Mesa-dev] [PATCH] i965: Revert absolute mode for constant buffer pointers.

[Jordan Justen]

On 2017-10-19 16:30:44, Kristian Høgsberg wrote:
> On Thu, Oct 19, 2017 at 4:18 PM, Kenneth Graunke  
> wrote:
> > The kernel doesn't initialize the value of the INSTPM or CS_DEBUG_MODE2
> > registers at context initialization time.  Instead, they're inherited
> > from whatever happened to be running on the GPU prior to first run of a
> > new context.  So, when we started setting these, other contexts in the
> > system started inheriting our values.  Since this controls whether
> > 3DSTATE_CONSTANT_* takes a pointer or an offset, getting the wrong
> > setting is fatal for almost any process which isn't expecting this.
> >
> > Unfortunately, VA-API and Beignet don't initialize this (nor does older
> > Mesa), so they will die horribly if we start doing this.  UXA and SNA
> > don't use any push constants, so they are unaffected.
> >
> > The kernel developers are apparently uninterested in making the proto-
> > context initialize these registers to guarantee deterministic behavior.
> 
> Could somebody from the kernel team elaborate here? This is obviously
> broken and undermines the security and containerization that hw
> contexts are supposed to provide. I'm really curious what the thinking
> is here...
> 
> Kristian

Cc intel-gfx, maintainers

> 
> > Apparently, the "Default Value" of registers in the documentation is a
> > total lie, and cannot be relied upon by userspace.  So, we need to find
> > a new solution.  One would be to patch VA-API and Beignet to initialize
> > these, then get every distributor to ship those in tandem with the newer
> > Mesa version.  I'm unclear when va-intel-driver releases might happen.
> > Another option would be to hack Mesa to restore the register back to the
> > historical default (relative mode) at the end of each batch.  This is
> > also gross, as it has non-zero cost, and is also relying on userspace to
> > be "polite" to other broken userspace.  A large part of the motivation
> > for contexts was to provide proper process isolation, so we should not
> > have to do this.  But, we're already doing it in some cases, because
> > our kernel fixes to enforce isolation were reverted.
> >
> > In the meantime, I guess we'll just revert this patch and abandon using
> > the feature.  It will lead to fewer pushed UBOs on Broadwell+, which may
> > lead to lower performance, but I don't have any data on the impact.
> >
> > Cc: "17.2" 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102774
> > ---
> >  src/mesa/drivers/dri/i965/brw_state_upload.c | 24 
> >  src/mesa/drivers/dri/i965/intel_screen.c |  2 +-
> >  2 files changed, 1 insertion(+), 25 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
> > b/src/mesa/drivers/dri/i965/brw_state_upload.c
> > index 16f44d03bbe..23e4ebda259 100644
> > --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> > +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> > @@ -101,30 +101,6 @@ brw_upload_initial_gpu_state(struct brw_context *brw)
> >OUT_BATCH(0);
> >ADVANCE_BATCH();
> > }
> > -
> > -   /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
> > -* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
> > -*
> > -* On Gen6-7.5, we use an execbuf parameter to do this for us.
> > -* However, the kernel ignores that when execlists are in use.
> > -* Fortunately, we can just write the registers from userspace
> > -* on Gen8+, and they're context saved/restored.
> > -*/
> > -   if (devinfo->gen >= 9) {
> > -  BEGIN_BATCH(3);
> > -  OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
> > -  OUT_BATCH(CS_DEBUG_MODE2);
> > -  OUT_BATCH(REG_MASK(CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
> > -CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
> > -  ADVANCE_BATCH();
> > -   } else if (devinfo->gen == 8) {
> > -  BEGIN_BATCH(3);
> > -  OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
> > -  OUT_BATCH(INSTPM);
> > -  OUT_BATCH(REG_MASK(INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
> > -INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
> > -  ADVANCE_BATCH();
> > -   }
> >  }
> >
> >  static inline const struct brw_tracked_state *
> > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> > b/src/mesa/drivers/dri/i965/intel_screen.c
> > index ea04a72e860..776c2898d5b 100644
> > --- a/src/mesa/drivers/dri/i965/intel_screen.c
> > +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> > @@ -2510,7 +2510,7 @@ __DRIconfig **intelInitScreen2(__DRIscreen 
> > *dri_screen)
> > screen->compiler = brw_compiler_create(screen, devinfo);
> > screen->compiler->shader_debug_log = shader_debug_log_mesa;
> > screen->compiler->shader_perf_log = shader_perf_log_mesa;
> > -   screen->compiler->constant_buffer_0_is_relative = devinfo->gen < 8;
> > +   screen->compiler->constant_buffer_0_is_relative = true;
> > 

Re: [Mesa-dev] [PATCH v3 00/34] i965 disk shader cache

[Jordan Justen]

On 2017-10-22 13:01:08, Jordan Justen wrote:
> 
> Patch code review status:
> 
> mesa/glsl: add api_enabled flag to gl_transform_feedback_info
> 
> i965: add support for cached shaders with xfb qualifiers

It sounds like Tim has a plan for supporting shader cache with
transform feedback, but for now these two are:

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

Re: [Mesa-dev] [PATCH] configure: Allow android as an EGL platform

[Benjamin Gordon]

On Mon, Oct 23, 2017 at 11:10 AM, Eric Engestrom 
wrote:

> On Friday, 2017-10-20 15:34:57 -0600, Benjamin Gordon wrote:
> > I'm working on radeonsi support in the Chrome OS Android container
> > (ARC++).  Mesa in ARC++ uses autotools instead of Android.mk, but all
> > the necessary EGL bits are there, so the existing check is too strict.
> >
> > Signed-off-by: Benjamin Gordon 
>
> Didn't double-check that all the android bits are wired, but I don't
> think this can break anything outside android, so:
> Reviewed-by: Eric Engestrom 
>
> Do you need someone to push this for you?
>

Yes, please :)


>
> > ---
> >  configure.ac | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index e05c34eb7b..b971b36333 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -2393,12 +2393,13 @@ dnl Surfaceless is an alternative for the last
> one.
> >  dnl
> >  require_basic_egl() {
> >  case "$with_platforms" in
> > -*drm*|*surfaceless*)
> > +*drm*|*surfaceless*|*android*)
> >  ;;
> >  *)
> >  AC_MSG_ERROR([$1 requires one of these:
> >1) --with-platforms=drm (X, Wayland, offscreen
> rendering based on DRM)
> >2) --with-platforms=surfaceless (offscreen only)
> > +  3) --with-platforms=android (Android only)
> >Recommended options: drm,x11])
> >  ;;
> >  esac
> > --
> > 2.15.0.rc0.271.g36b669edcc-goog
>  
> Side note, do you guys have google builds of git?
>

We probably do, but I'm afraid I don't have any idea what's in it.   There
are several git contributors working here, so maybe stuff that they haven't
finished upstreaming yet?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium/util: use util_snprintf() in u_socket_connect()

[Brian Paul]

Instead of plain snprintf().  To fix the MSVC build.

snprintf() is used in various places in Mesa/gallium, but apparently,
not in code built with MSVC.
---
 src/gallium/auxiliary/util/u_network.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/util/u_network.c 
b/src/gallium/auxiliary/util/u_network.c
index a7a4d28..203205d 100644
--- a/src/gallium/auxiliary/util/u_network.c
+++ b/src/gallium/auxiliary/util/u_network.c
@@ -2,6 +2,7 @@
 #include "pipe/p_compiler.h"
 #include "util/u_network.h"
 #include "util/u_debug.h"
+#include "util/u_string.h"
 
 #include 
 #if defined(PIPE_SUBSYSTEM_WINDOWS_USER)
@@ -120,7 +121,7 @@ u_socket_connect(const char *hostname, uint16_t port)
hints.ai_family = AF_UNSPEC; // AF_INET or AF_INET6 to force version
hints.ai_socktype = SOCK_STREAM;
 
-   snprintf(portString, sizeof(portString), "%d", port);
+   util_snprintf(portString, sizeof(portString), "%d", port);
 
r = getaddrinfo(hostname, portString, NULL, );
if (r != 0) {
-- 
1.9.1

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

[Mesa-dev] [AppVeyor] mesa master #5910 failed

[AppVeyor]

Build mesa 5910 failed


Commit 069211f205 by Brian Paul on 10/17/2017 7:59 PM:

gallium/util: don't call close() on Windows in u_tests.c\n\nReviewed-by: Nicolai Hähnle 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH v2 6/8] egl: add dri2_egl_surface_destroy_image_front() helper (v2)

[Mun, Gwan-gyeong]

Hi Gurchetan,

2017-10-18 6:02 GMT+09:00 Gurchetan Singh :
> dri2_egl_surface_destroy_image_front and dri2_egl_surface_destroy_image_back
> are almost identical.  Why don't you just create a
> dri2_surface_free_image(struct dri2_egl_surface *dri2_surf, __DRIimage
> **img) that you will call with both the front and back images?  In addition,

As your opinion, we can rafactor more for dri2_surface_free_image.

Nevertheless however, I'd suggest keeping that as separate series.
these patches started as a way to minimise the duplication we have in
drivers/dri2.
So that new platforms such as Tizen do not need to copy the lot. [1]

> only platform_android has dri_image_back and dri_image_front -- please keep

In this patch, dri2_egl_surface_destroy_image_front() helper is only
used for android
however it will also be used for new platform (Tizen). [2]

[1] https://lists.freedesktop.org/archives/mesa-dev/2017-October/173269.html
[2] https://lists.freedesktop.org/archives/mesa-dev/2017-October/172007.html


Thanks,

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

[Mesa-dev] [Bug 103427] VK_ERROR_INITIALIZATION_FAILED with 280x: vkEnumeratePhysicalDevices(vk->inst, , NULL): VK_ERROR_INITIALIZATION_FAILED

[bugzilla-daemon]

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

--- Comment #3 from Emil Velikov  ---
Adding some debug information in radv_EnumeratePhysicalDevices and/or stepping
through it with a debugger might be a good idea. There are multiple reasons why
enumeration can fail.

-- 
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 v2 1/8] egl: add dri2_egl_surface_free_outdated_buffers_and_update_size() helper (v2)

[Mun, Gwan-gyeong]

Hi Emil and Gurchetan,

Thank you for  reviewing the patches.

2017-10-20 6:18 GMT+09:00 Gurchetan Singh :
> De-duplicating and then trimming down works for me.
>
> On Thu, Oct 19, 2017 at 3:31 AM, Emil Velikov 
> wrote:
>>
>> On 18 October 2017 at 23:36, Gurchetan Singh
>>  wrote:
>> >> Then again, I'd suggest keeping that as separate series. These patches
>> >> started as a way to minimise the duplication we have in drivers/dri2.
>> >
>> > I'm fine with dri2_$action_$object.  We can modify the existing
>> > functions
>> > later, but I recommend adopting more concise conventions in this
>> > patchset,
>> > i.e:
>> >
>> > dri2_egl_surface_record_buffers_and_update_back_buffer -->
>> > dri2_set_back_buffer_surface
>> > dri2_egl_surface_free_outdated_buffers_and_update_size -->
>> > dri2_fixup_surface
>> > dri2_egl_surface_update_buffer_age --> dri2_update_age_surface
>> > dri2_egl_surface_get_image_front --> dri2_get_front_image_surface
>> >
>> Sure thing, let's use consistent names with this series.
>>

It seems great with your suggested helper function names.

nevertheless, egl/driver/dri3/ codes also use such as
dri2_surface_$action_$object naming conventions.

(ie.
  __DRIdrawable *dri2_surface_get_dri_drawable(_EGLSurface *surf)
  void dri2_surface_set_out_fence_fd(_EGLSurface *surf, int fence_fd)
)

If you are fine with dri2_surface_$action_$object naming convention, I
suggest these function prototype.
These have dri2_surface_$action_$object naming convention and change
type of first argument.
 (struct dri2_egl_surface => _EGLSurface )

ie.
  void dri2_egl_surface_record_buffers_and_update_back_buffer(struct
dri2_egl_surface *dri2_surf, void *buffer)
   => void dri2_surface_set_back_buffer(_EGLSurface *surf, void *buffer)

  void dri2_egl_surface_free_outdated_buffers_and_update_size(struct
dri2_egl_surface *dri2_surf, int width, int height)
   => void dri2_surface_fixup(_EGLSurface *surf, int width, int height)

  void dri2_egl_surface_update_buffer_age(struct dri2_egl_surface *dri2_surf)
   => void dri2_surface_update_age(_EGLSurface *surf)

  int dri2_egl_surface_get_image_front(struct dri2_egl_surface
*dri2_surf, unsigned int format)
   => int dri2_surface_get_front_image(_EGLSurface *surf, unsigned int format)


What do you think about this?

Thanks,

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

[Mesa-dev] [PATCH 1/3] i965: Move _mesa_shader_write_subroutine_indices down a level.

[Kenneth Graunke]

Now we call it in one place instead of making every caller do it.
---
 src/mesa/drivers/dri/i965/gen6_constant_state.c | 3 +++
 src/mesa/drivers/dri/i965/genX_state_upload.c   | 6 --
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen6_constant_state.c 
b/src/mesa/drivers/dri/i965/gen6_constant_state.c
index 121ba672575..6b5d2e66cc9 100644
--- a/src/mesa/drivers/dri/i965/gen6_constant_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_constant_state.c
@@ -28,6 +28,7 @@
 #include "intel_batchbuffer.h"
 #include "intel_buffer_objects.h"
 #include "program/prog_parameter.h"
+#include "main/shaderapi.h"
 
 static uint32_t
 f_as_u32(float f)
@@ -129,6 +130,8 @@ gen6_upload_push_constants(struct brw_context *brw,
const struct gen_device_info *devinfo = >screen->devinfo;
struct gl_context *ctx = >ctx;
 
+   _mesa_shader_write_subroutine_indices(ctx, stage_state->stage);
+
if (prog_data->nr_params == 0) {
   stage_state->push_const_size = 0;
} else {
diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index 63ad02ff499..66b1ad9dbda 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -3143,7 +3143,6 @@ genX(upload_vs_push_constants)(struct brw_context *brw)
/* BRW_NEW_VS_PROG_DATA */
const struct brw_stage_prog_data *prog_data = brw->vs.base.prog_data;
 
-   _mesa_shader_write_subroutine_indices(>ctx, MESA_SHADER_VERTEX);
gen6_upload_push_constants(brw, >program, prog_data, stage_state);
 }
 
@@ -3172,7 +3171,6 @@ genX(upload_gs_push_constants)(struct brw_context *brw)
   /* BRW_NEW_GS_PROG_DATA */
   struct brw_stage_prog_data *prog_data = brw->gs.base.prog_data;
 
-  _mesa_shader_write_subroutine_indices(>ctx, MESA_SHADER_GEOMETRY);
   gen6_upload_push_constants(brw, >program, prog_data, stage_state);
}
 }
@@ -3199,8 +3197,6 @@ genX(upload_wm_push_constants)(struct brw_context *brw)
/* BRW_NEW_FS_PROG_DATA */
const struct brw_stage_prog_data *prog_data = brw->wm.base.prog_data;
 
-   _mesa_shader_write_subroutine_indices(>ctx, MESA_SHADER_FRAGMENT);
-
gen6_upload_push_constants(brw, >program, prog_data, stage_state);
 }
 
@@ -4038,7 +4034,6 @@ genX(upload_tes_push_constants)(struct brw_context *brw)
if (tep) {
   /* BRW_NEW_TES_PROG_DATA */
   const struct brw_stage_prog_data *prog_data = brw->tes.base.prog_data;
-  _mesa_shader_write_subroutine_indices(>ctx, MESA_SHADER_TESS_EVAL);
   gen6_upload_push_constants(brw, >program, prog_data, stage_state);
}
 }
@@ -4067,7 +4062,6 @@ genX(upload_tcs_push_constants)(struct brw_context *brw)
   /* BRW_NEW_TCS_PROG_DATA */
   const struct brw_stage_prog_data *prog_data = brw->tcs.base.prog_data;
 
-  _mesa_shader_write_subroutine_indices(>ctx, MESA_SHADER_TESS_CTRL);
   gen6_upload_push_constants(brw, >program, prog_data, stage_state);
}
 }
-- 
2.14.2

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

[Mesa-dev] [PATCH 3/3] i965: Call gen6_upload_push_constants() even when the stage is disabled.

[Kenneth Graunke]

This properly sets stage_state->push_constant_dirty = true, so that we
emit 3DSTATE_CONSTANT_XS to disable the constant buffer for the shader
stage.  It also sets stage_state->push_const_size = 0.
---
 src/mesa/drivers/dri/i965/gen6_constant_state.c |  9 +++--
 src/mesa/drivers/dri/i965/genX_state_upload.c   | 25 +
 2 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen6_constant_state.c 
b/src/mesa/drivers/dri/i965/gen6_constant_state.c
index 6b5d2e66cc9..acf7454cef5 100644
--- a/src/mesa/drivers/dri/i965/gen6_constant_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_constant_state.c
@@ -130,9 +130,14 @@ gen6_upload_push_constants(struct brw_context *brw,
const struct gen_device_info *devinfo = >screen->devinfo;
struct gl_context *ctx = >ctx;
 
-   _mesa_shader_write_subroutine_indices(ctx, stage_state->stage);
+   bool active = prog_data &&
+  (stage_state->stage != MESA_SHADER_TESS_CTRL ||
+   brw->programs[MESA_SHADER_TESS_EVAL]);
 
-   if (prog_data->nr_params == 0) {
+   if (active)
+  _mesa_shader_write_subroutine_indices(ctx, stage_state->stage);
+
+   if (!active || prog_data->nr_params == 0) {
   stage_state->push_const_size = 0;
} else {
   /* Updates the ParamaterValues[i] pointers for all parameters of the
diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index f2b3e4570b2..4ccfd489191 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -3165,12 +3165,10 @@ genX(upload_gs_push_constants)(struct brw_context *brw)
/* BRW_NEW_GEOMETRY_PROGRAM */
const struct gl_program *gp = brw->programs[MESA_SHADER_GEOMETRY];
 
-   if (gp) {
-  /* BRW_NEW_GS_PROG_DATA */
-  struct brw_stage_prog_data *prog_data = brw->gs.base.prog_data;
+   /* BRW_NEW_GS_PROG_DATA */
+   struct brw_stage_prog_data *prog_data = brw->gs.base.prog_data;
 
-  gen6_upload_push_constants(brw, gp, prog_data, stage_state);
-   }
+   gen6_upload_push_constants(brw, gp, prog_data, stage_state);
 }
 
 static const struct brw_tracked_state genX(gs_push_constants) = {
@@ -4027,11 +4025,9 @@ genX(upload_tes_push_constants)(struct brw_context *brw)
/* BRW_NEW_TESS_PROGRAMS */
const struct gl_program *tep = brw->programs[MESA_SHADER_TESS_EVAL];
 
-   if (tep) {
-  /* BRW_NEW_TES_PROG_DATA */
-  const struct brw_stage_prog_data *prog_data = brw->tes.base.prog_data;
-  gen6_upload_push_constants(brw, tep, prog_data, stage_state);
-   }
+   /* BRW_NEW_TES_PROG_DATA */
+   const struct brw_stage_prog_data *prog_data = brw->tes.base.prog_data;
+   gen6_upload_push_constants(brw, tep, prog_data, stage_state);
 }
 
 static const struct brw_tracked_state genX(tes_push_constants) = {
@@ -4051,14 +4047,11 @@ genX(upload_tcs_push_constants)(struct brw_context *brw)
struct brw_stage_state *stage_state = >tcs.base;
/* BRW_NEW_TESS_PROGRAMS */
const struct gl_program *tcp = brw->programs[MESA_SHADER_TESS_CTRL];
-   bool active = brw->programs[MESA_SHADER_TESS_EVAL];
 
-   if (active) {
-  /* BRW_NEW_TCS_PROG_DATA */
-  const struct brw_stage_prog_data *prog_data = brw->tcs.base.prog_data;
+   /* BRW_NEW_TCS_PROG_DATA */
+   const struct brw_stage_prog_data *prog_data = brw->tcs.base.prog_data;
 
-  gen6_upload_push_constants(brw, tcp, prog_data, stage_state);
-   }
+   gen6_upload_push_constants(brw, tcp, prog_data, stage_state);
 }
 
 static const struct brw_tracked_state genX(tcs_push_constants) = {
-- 
2.14.2

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

[Mesa-dev] [PATCH 2/3] i965: Drop a bunch of downcasting and upcasting of gl_program pointers.

[Kenneth Graunke]

We have a gl_program and we want a gl_program.  There's no point in
converting to brw_program and back again.  This probably made more
sense in the old days before Tim dropped a layer of subclassing.
---
 src/mesa/drivers/dri/i965/genX_state_upload.c | 31 +++
 1 file changed, 12 insertions(+), 19 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index 66b1ad9dbda..f2b3e4570b2 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -3138,12 +3138,11 @@ genX(upload_vs_push_constants)(struct brw_context *brw)
struct brw_stage_state *stage_state = >vs.base;
 
/* BRW_NEW_VERTEX_PROGRAM */
-   const struct brw_program *vp =
-  brw_program_const(brw->programs[MESA_SHADER_VERTEX]);
+   const struct gl_program *vp = brw->programs[MESA_SHADER_VERTEX];
/* BRW_NEW_VS_PROG_DATA */
const struct brw_stage_prog_data *prog_data = brw->vs.base.prog_data;
 
-   gen6_upload_push_constants(brw, >program, prog_data, stage_state);
+   gen6_upload_push_constants(brw, vp, prog_data, stage_state);
 }
 
 static const struct brw_tracked_state genX(vs_push_constants) = {
@@ -3164,14 +3163,13 @@ genX(upload_gs_push_constants)(struct brw_context *brw)
struct brw_stage_state *stage_state = >gs.base;
 
/* BRW_NEW_GEOMETRY_PROGRAM */
-   const struct brw_program *gp =
-  brw_program_const(brw->programs[MESA_SHADER_GEOMETRY]);
+   const struct gl_program *gp = brw->programs[MESA_SHADER_GEOMETRY];
 
if (gp) {
   /* BRW_NEW_GS_PROG_DATA */
   struct brw_stage_prog_data *prog_data = brw->gs.base.prog_data;
 
-  gen6_upload_push_constants(brw, >program, prog_data, stage_state);
+  gen6_upload_push_constants(brw, gp, prog_data, stage_state);
}
 }
 
@@ -3192,12 +3190,11 @@ genX(upload_wm_push_constants)(struct brw_context *brw)
 {
struct brw_stage_state *stage_state = >wm.base;
/* BRW_NEW_FRAGMENT_PROGRAM */
-   const struct brw_program *fp =
-  brw_program_const(brw->programs[MESA_SHADER_FRAGMENT]);
+   const struct gl_program *fp = brw->programs[MESA_SHADER_FRAGMENT];
/* BRW_NEW_FS_PROG_DATA */
const struct brw_stage_prog_data *prog_data = brw->wm.base.prog_data;
 
-   gen6_upload_push_constants(brw, >program, prog_data, stage_state);
+   gen6_upload_push_constants(brw, fp, prog_data, stage_state);
 }
 
 static const struct brw_tracked_state genX(wm_push_constants) = {
@@ -4028,13 +4025,12 @@ genX(upload_tes_push_constants)(struct brw_context *brw)
 {
struct brw_stage_state *stage_state = >tes.base;
/* BRW_NEW_TESS_PROGRAMS */
-   const struct brw_program *tep =
-  brw_program_const(brw->programs[MESA_SHADER_TESS_EVAL]);
+   const struct gl_program *tep = brw->programs[MESA_SHADER_TESS_EVAL];
 
if (tep) {
   /* BRW_NEW_TES_PROG_DATA */
   const struct brw_stage_prog_data *prog_data = brw->tes.base.prog_data;
-  gen6_upload_push_constants(brw, >program, prog_data, stage_state);
+  gen6_upload_push_constants(brw, tep, prog_data, stage_state);
}
 }
 
@@ -4054,15 +4050,14 @@ genX(upload_tcs_push_constants)(struct brw_context *brw)
 {
struct brw_stage_state *stage_state = >tcs.base;
/* BRW_NEW_TESS_PROGRAMS */
-   const struct brw_program *tcp =
-  brw_program_const(brw->programs[MESA_SHADER_TESS_CTRL]);
+   const struct gl_program *tcp = brw->programs[MESA_SHADER_TESS_CTRL];
bool active = brw->programs[MESA_SHADER_TESS_EVAL];
 
if (active) {
   /* BRW_NEW_TCS_PROG_DATA */
   const struct brw_stage_prog_data *prog_data = brw->tcs.base.prog_data;
 
-  gen6_upload_push_constants(brw, >program, prog_data, stage_state);
+  gen6_upload_push_constants(brw, tcp, prog_data, stage_state);
}
 }
 
@@ -4089,8 +4084,7 @@ genX(upload_cs_push_constants)(struct brw_context *brw)
struct brw_stage_state *stage_state = >cs.base;
 
/* BRW_NEW_COMPUTE_PROGRAM */
-   const struct brw_program *cp =
-  (struct brw_program *) brw->programs[MESA_SHADER_COMPUTE];
+   const struct gl_program *cp = brw->programs[MESA_SHADER_COMPUTE];
 
if (cp) {
   /* BRW_NEW_CS_PROG_DATA */
@@ -4098,8 +4092,7 @@ genX(upload_cs_push_constants)(struct brw_context *brw)
  brw_cs_prog_data(brw->cs.base.prog_data);
 
   _mesa_shader_write_subroutine_indices(>ctx, MESA_SHADER_COMPUTE);
-  brw_upload_cs_push_constants(brw, >program, cs_prog_data,
-   stage_state);
+  brw_upload_cs_push_constants(brw, cp, cs_prog_data, stage_state);
}
 }
 
-- 
2.14.2

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

[Mesa-dev] [Bug 103427] VK_ERROR_INITIALIZATION_FAILED with 280x: vkEnumeratePhysicalDevices(vk->inst, , NULL): VK_ERROR_INITIALIZATION_FAILED

[bugzilla-daemon]

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

--- Comment #2 from Cris  ---
(In reply to Bas Nieuwenhuizen from comment #1)
> So according to the glxinfo log, you're still using the radeon kernel
> driver.(See the DRM version bit in the renderer string? 2.x is radeon, 3.x
> is amdgpu). radv doesn't support the radeon driver currently.

Oh yeah, I blacklisted radeon (and checked with lsmod | grep radeon) and it
still didn't work.

-- 
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 103427] VK_ERROR_INITIALIZATION_FAILED with 280x: vkEnumeratePhysicalDevices(vk->inst, , NULL): VK_ERROR_INITIALIZATION_FAILED

[bugzilla-daemon]

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

Bas Nieuwenhuizen  changed:

   What|Removed |Added

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

--- Comment #1 from Bas Nieuwenhuizen  ---
So according to the glxinfo log, you're still using the radeon kernel
driver.(See the DRM version bit in the renderer string? 2.x is radeon, 3.x is
amdgpu). radv doesn't support the radeon driver currently.

-- 
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 103427] VK_ERROR_INITIALIZATION_FAILED with 280x: vkEnumeratePhysicalDevices(vk->inst, , NULL): VK_ERROR_INITIALIZATION_FAILED

[bugzilla-daemon]

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

Bug ID: 103427
   Summary: VK_ERROR_INITIALIZATION_FAILED with 280x:
vkEnumeratePhysicalDevices(vk->inst, , NULL):
VK_ERROR_INITIALIZATION_FAILED
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: cristian...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Tested with mesa 17.2.3, but have also tested with git master and the results
were the same.

https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/2152

All the information and logs you might need or want are there^. Apart from
that, feel free to make any requests.

Relevant in case you refuse to click on the link above:
The error doesn't occur until until the application calls
vkEnumeratePhysicalDevices. At that point, the driver is returning the
VK_ERROR_INITIALIZATION_FAILED error. It appears that the first call into the
driver is actually working just fine, but the loader calls
vkEnumeratePhysicalDevices twice (once to get the count and once to get the
content) and only the second call fails. The loader just passes this error up
to the user.

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

Re: [Mesa-dev] [PATCH 1/2] intel: fix memmem() warning first arg shouldn't be NULL

[Matt Turner]

On Sun, Oct 22, 2017 at 6:26 PM, Timothy Arceri  wrote:
> ---
>  src/intel/compiler/brw_eu_validate.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/intel/compiler/brw_eu_validate.c 
> b/src/intel/compiler/brw_eu_validate.c
> index 9f72c650ddb..07318b9d3c0 100644
> --- a/src/intel/compiler/brw_eu_validate.c
> +++ b/src/intel/compiler/brw_eu_validate.c
> @@ -47,6 +47,9 @@ cat(struct string *dest, const struct string src)
>  static bool
>  contains(const struct string haystack, const struct string needle)
>  {
> +   if (!haystack.str)
> +  return false;
> +

Thanks. Strange that I don't see this. Must require a newer gcc than
what I have.

I just reviewed Eric Anholt's similar patch to solve this problem, so
we can drop this one.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] intel/eu/validate: avoid null deref

[Matt Turner]

On Mon, Oct 23, 2017 at 10:08 AM, Eric Engestrom
 wrote:
> src/intel/compiler/brw_eu_validate.c:50:11: warning: argument 1 null where 
> non-null expected [-Wnonnull]
> return memmem(haystack.str, haystack.len, needle.str, needle.len) != NULL;
>^~
> In file included from src/gallium/include/pipe/p_compiler.h:39:0,
>  from src/gallium/auxiliary/util/u_math.h:42,
>  from src/mesa/main/macros.h:35,
>  from src/intel/compiler/brw_reg.h:47,
>  from src/intel/compiler/brw_eu.h:39,
>  from src/intel/compiler/brw_eu_validate.c:29:
> /usr/include/string.h:368:14: note: in a call to function ‘memmem’ declared 
> here
>  extern void *memmem (const void *__haystack, size_t __haystacklen,
>   ^~
>
> Signed-off-by: Eric Engestrom 
> ---
> Looks to me like error_msg.str always starts off being NULL, so I would
> have expected this to have blown up already? I feel like I must be
> missing something here.

Thanks. Strange that I don't see this. Must require a newer gcc than
what I have.

I just reviewed Eric Anholt's similar patch to solve this problem, so
we can drop this one.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Fix memmem compiler warnings.

[Matt Turner]

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

Re: [Mesa-dev] [PATCH] configure: Allow android as an EGL platform

[Eric Engestrom]

On Friday, 2017-10-20 15:34:57 -0600, Benjamin Gordon wrote:
> I'm working on radeonsi support in the Chrome OS Android container
> (ARC++).  Mesa in ARC++ uses autotools instead of Android.mk, but all
> the necessary EGL bits are there, so the existing check is too strict.
> 
> Signed-off-by: Benjamin Gordon 

Didn't double-check that all the android bits are wired, but I don't
think this can break anything outside android, so:
Reviewed-by: Eric Engestrom 

Do you need someone to push this for you?

> ---
>  configure.ac | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index e05c34eb7b..b971b36333 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2393,12 +2393,13 @@ dnl Surfaceless is an alternative for the last one.
>  dnl
>  require_basic_egl() {
>  case "$with_platforms" in
> -*drm*|*surfaceless*)
> +*drm*|*surfaceless*|*android*)
>  ;;
>  *)
>  AC_MSG_ERROR([$1 requires one of these:
>1) --with-platforms=drm (X, Wayland, offscreen rendering 
> based on DRM)
>2) --with-platforms=surfaceless (offscreen only)
> +  3) --with-platforms=android (Android only)
>Recommended options: drm,x11])
>  ;;
>  esac
> -- 
> 2.15.0.rc0.271.g36b669edcc-goog
 
Side note, do you guys have google builds of git?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH mesa] intel/eu/validate: avoid null deref

[Eric Engestrom]

src/intel/compiler/brw_eu_validate.c:50:11: warning: argument 1 null where 
non-null expected [-Wnonnull]
return memmem(haystack.str, haystack.len, needle.str, needle.len) != NULL;
   ^~
In file included from src/gallium/include/pipe/p_compiler.h:39:0,
 from src/gallium/auxiliary/util/u_math.h:42,
 from src/mesa/main/macros.h:35,
 from src/intel/compiler/brw_reg.h:47,
 from src/intel/compiler/brw_eu.h:39,
 from src/intel/compiler/brw_eu_validate.c:29:
/usr/include/string.h:368:14: note: in a call to function ‘memmem’ declared here
 extern void *memmem (const void *__haystack, size_t __haystacklen,
  ^~

Signed-off-by: Eric Engestrom 
---
Looks to me like error_msg.str always starts off being NULL, so I would
have expected this to have blown up already? I feel like I must be
missing something here.
---
 src/intel/compiler/brw_eu_validate.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/intel/compiler/brw_eu_validate.c 
b/src/intel/compiler/brw_eu_validate.c
index 9f72c650ddbd67ac6e18..a1c9e27ea2f8c1b466fd 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++ b/src/intel/compiler/brw_eu_validate.c
@@ -47,6 +47,8 @@ cat(struct string *dest, const struct string src)
 static bool
 contains(const struct string haystack, const struct string needle)
 {
+   if (!haystack.str || !needle.str)
+  return false;
return memmem(haystack.str, haystack.len, needle.str, needle.len) != NULL;
 }
 #define CONTAINS(haystack, needle) \
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] [PATCH 7/9] wayland-drm: static inline wayland_drm_buffer_get

[Emil Velikov]

On 23 October 2017 at 16:41, Daniel Stone  wrote:
> Hi Emil,
>
> On 28 September 2017 at 13:36, Emil Velikov  wrote:
>> On 20 September 2017 at 15:06, Daniel Stone  wrote:
>>> On 19 September 2017 at 11:25, Emil Velikov  
>>> wrote:
 It looks a bit icky and my Wayland knowledge is limited to actually review 
 it.

 I still think that we're trying to do different things - me simplify
 things, while you're focusing on fixing a bug.
>>>
>>> I like the idea of the simplification, but it's just that a) it can't
>>> actually be simplified that far, and b) whilst we still rely on
>>> consistent resolution of wl_buffer_interface, your proposed change may
>>> actually _introduce_ a bug.
>>
>> Right, I did not see that one. Can you share your train of thought?
>
> Happily!
>
> When a compositor creates a client buffer, the request is dispatched
> by libwayland-server.so into libEGL.so (libEGL explicitly links
> libwayland-server). This lands in
> src/egl/wayland/wayland-drm/wayland-drm.c's create_buffer(), which
> calls wl_resource_create() with 'wl_buffer_interface'. Since libEGL.so
> is explicitly linked against both libwayland-client and
> libwayland-server, and both of those DSOs provide a resolution of
> wl_buffer_interface, resource->interface could be
> libwayland-server.so::wl_buffer_interface, or
> libwayland-client.so::wl_buffer_interface.
>
> When a compositor wants to import a buffer into GBM, it calls
> gbm_bo_import(), which will call wl_drm_buffer_get().
> wl_drm_buffer_get will test (resource->interface ==
> _buffer_interface). Previously, both create_buffer() and
> wl_drm_buffer_get() at least came from the same compilation unit, but
> now they are built and linked separately. This seems to make an
> existing problem (ambiguity of 'wl_buffer_interface') worse (symbol
> resolution now performed in separate compilation units).
>
> I don't really see a solution to this, apart from no longer relying on
> having a single canonical resolution of wl_buffer_interface. The above
> patch implements that, by removing the interface-address-equal test
> and replacing it with the destroy-listener test. The patch I provided
> is equally valid both with and without your series.
>
Ouch, that's something I did not expect looking at the Mesa code alone.

Generally, this type of issues are not specific to Mesa, but come due
to the implementation/use of wl_resource_instance_of. Is that correct?

I'm itching to bring back my suggestions to fix this in its root, but
let's ignore that for a moment ;-)

Having a look at the wl_resource_instance_of() implementation

WL_EXPORT int
wl_resource_instance_of(struct wl_resource *resource,
   const struct wl_interface *interface,
   const void *implementation)
{
   return wl_interface_equal(resource->object.interface, interface) &&
   resource->object.implementation == implementation;
}

... and wl_interface_equal()

int
wl_interface_equal(const struct wl_interface *a, const struct wl_interface *b)
{
 /* In most cases the pointer equality test is sufficient.
  * However, in some cases, depending on how things are split
  * across shared objects, we can end up with multiple
  * instances of the interface metadata constants.  So if the
  * pointers match, the interfaces are equal, if they don't
  * match we have to compare the interface names.
  */
 return a == b || strcmp(a->name, b->name) == 0;
}

Am I reading it incorrectly, or you forgot about the name check?
It seems like the name check was added explicitly to workaround the
issue you're talking about.

Thus wl_resource_instance_of() should return the same result with or
without my patch?
Or perhaps the interface check is safe, but the implementation one isn't?

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

Re: [Mesa-dev] create src/wsi

[Emil Velikov]

On 23 October 2017 at 17:05, Nicolai Hähnle  wrote:
> On 23.10.2017 17:16, Emil Velikov wrote:
>>
>> On 23 October 2017 at 16:03, Jason Ekstrand  wrote:
>>>
>>> On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle 
>>> wrote:


 On 21.10.2017 03:00, Dylan Baker wrote:
>
>
> This very short series creates a new src/wsi folder, and moves
> wayland-drm into
> it. Basically wsi stuff is scattered about, and is needed by multiple
> components
> within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan
> wayland-wsi.
>
> I think there's more that could be moved into wsi, we could move EGL,
> GBM, and
> GLX, and vulkan/wsi, for example.



 The general thrust sounds good to me.

 Is there a clean model for what should go into src/wsi and what
 shouldn't?
 Where's the boundary?

 For an example of the type of headaches, does DRI driver code (stuff
 that
 ends up in xxx_dri.so, for example) count as part of src/wsi? If so,
 then
 what about gallium/state_trackers/dri? What about
 mesa/drivers/dri/common?
>>>
>>>
>>>
>>> Maybe?  I guess it depends on what it does and how much sense it makes to
>>> share it higher than the gallium level.
>>>

 I don't have a full picture of all this code so it's hard for me to say,
 but I really hope your changes will lead to a clearer picture overall :)
>>>
>>>
>>>
>>> Dylan and I talked about it quite a bit off-line so I have a few
>>> opinions.
>>> :)  In particular, here's what I envison:
>>>
>>> src/wsi/gbm
>>> src/wsi/egl
>>> src/wsi/wayland-drm
>>> src/wsi/dri3 (currently src/loader)
>>> src/wsi/glx
>>> src/wsi/vulkan (currently src/vulkan/wsi)
>>> src/wsi/hgl
>>>
>> Idea is mostly ok, but there's a bit of a snafu:
>>
>> Things are not as clean cut/split as per above. Here are some of the
>> current inter-dependencies.
>>
>> src/loader - loader.c WSI agnostic DRI loader code.
>> src/loader - loader_dri3.c X11 DRI3 code.
>>
>> gbm - depends on loader.c, wayland-drm (I've sent patches to remove this),
>> egl
For the gbm <> wayland-drm bits
https://lists.freedesktop.org/archives/mesa-dev/2017-September/168952.html

Although Daniel has some concerns
https://lists.freedesktop.org/archives/mesa-dev/2017-October/173915.html

>> egl  - depends on loader.c loader_dri3.c wayland-drm, gbm (pokes one
>> of the AMD devs to attempt this)

The egl <> gbm bits
https://lists.freedesktop.org/archives/mesa-dev/2017-October/173088.html

>
>
> Which part / what do you mean?
>
> I'm perfectly fine with keeping the state_tracker/dri/ and dri/common bits
> where they are, I just wanted to get some clarification :)
>
Fwiw - if anyone can suggest a reasonable way to rework/fold/split I'm all ears.

Otherwise I fear that just moving things won't help much. Things are
quite interconnected.

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

Re: [Mesa-dev] [PATCH 6/7] glsl/parser: Track built-in types using the glsl_type directly

[Nicolai Hähnle]

On 18.10.2017 16:39, Ian Romanick wrote:

On 10/17/2017 12:54 PM, Nicolai Hähnle wrote:

On 17.10.2017 20:14, Ian Romanick wrote:

From: Ian Romanick 

     text   data    bss    dec    hex    filename
8255243 268856 294072    8818171 868dfb    32-bit
i965_dri.so before
8255291 268856 294072    8818219 868e2b    32-bit
i965_dri.so after
7815195 345592 420592    8581379 82f103    64-bit
i965_dri.so before
7815339 345592 420592    8581523 82f193    64-bit
i965_dri.so after


How does this change lead to such a big reduction, and shouldn't the
lexer changes be in a separate patch?


Without the lexer changes, tests/glslparsertest/glsl2/tex_rect-02.frag
fails.  Before this change, the parser would determine that
sampler2DRect is not a valid type because the call to
state->symbols->get_type() in ast_type_specifier::glsl_type() would
return NULL.  Since ast_type_specifier::glsl_type() is now going to
return the glsl_type pointer that it received from the lexer, it doesn't
have an opportunity to generate an error.

It took me a bit to remember why I did it like this, so, at the very
least, I will add that text to the commit message.


Seems reasonable, thanks for the explanation. With the explanation 
added, this patch has my R-b as well.


Cheers,
Nicolai





Cheers,
Nicolai



Signed-off-by: Ian Romanick 
---
   src/compiler/glsl/ast.h  | 13 +++--
   src/compiler/glsl/ast_to_hir.cpp |  4 +++-
   src/compiler/glsl/glsl_lexer.ll  | 21 +
   src/compiler/glsl/glsl_parser.yy |  2 +-
   4 files changed, 28 insertions(+), 12 deletions(-)

diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h
index 1be86ac..eee2248 100644
--- a/src/compiler/glsl/ast.h
+++ b/src/compiler/glsl/ast.h
@@ -27,6 +27,7 @@
     #include "list.h"
   #include "glsl_parser_extras.h"
+#include "compiler/glsl_types.h"
     struct _mesa_glsl_parse_state;
   @@ -853,7 +854,7 @@ class ast_type_specifier : public ast_node {
   public:
  /** Construct a type specifier from a type name */
  ast_type_specifier(const char *name)
-  : type_name(name), structure(NULL), array_specifier(NULL),
+  : type(NULL), type_name(name), structure(NULL),
array_specifier(NULL),
   default_precision(ast_precision_none)
  {
     /* empty */
@@ -861,12 +862,19 @@ public:
    /** Construct a type specifier from a structure definition */
  ast_type_specifier(ast_struct_specifier *s)
-  : type_name(s->name), structure(s), array_specifier(NULL),
+  : type(NULL), type_name(s->name), structure(s),
array_specifier(NULL),
   default_precision(ast_precision_none)
  {
     /* empty */
  }
   +   ast_type_specifier(const glsl_type *t)
+  : type(t), type_name(t->name), structure(NULL),
array_specifier(NULL),
+    default_precision(ast_precision_none)
+   {
+  /* empty */
+   }
+
  const struct glsl_type *glsl_type(const char **name,
    struct _mesa_glsl_parse_state *state)
     const;
@@ -875,6 +883,7 @@ public:
    ir_rvalue *hir(exec_list *, struct _mesa_glsl_parse_state *);
   +   const struct glsl_type *type;
  const char *type_name;
  ast_struct_specifier *structure;
   diff --git a/src/compiler/glsl/ast_to_hir.cpp
b/src/compiler/glsl/ast_to_hir.cpp
index d7c8b47..6090ee9 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -2361,7 +2361,9 @@ ast_type_specifier::glsl_type(const char **name,
   {
  const struct glsl_type *type;
   -   if (structure)
+   if (this->type != NULL)
+  type = this->type;
+   else if (structure)
     type = structure->type;
  else
     type = state->symbols->get_type(this->type_name);
diff --git a/src/compiler/glsl/glsl_lexer.ll
b/src/compiler/glsl/glsl_lexer.ll
index 5dad6ee..d2278ba 100644
--- a/src/compiler/glsl/glsl_lexer.ll
+++ b/src/compiler/glsl/glsl_lexer.ll
@@ -132,18 +132,23 @@ static int classify_identifier(struct
_mesa_glsl_parse_state *, const char *,
   /**
    * Like DEPRECATED_ES_KEYWORD, but for types
    */
-#define DEPRECATED_ES_TYPE(gtype)    \
+#define DEPRECATED_ES_TYPE_WITH_ALT(alt_expr, gtype)    \
  do {    \
     if (yyextra->is_version(0, 300)) {    \
- _mesa_glsl_error(yylloc, yyextra,    \
-  "illegal use of reserved word `%s'", yytext);    \
- return ERROR_TOK;    \
-  } else {    \
- yylval->type = gtype;    \
+ _mesa_glsl_error(yylloc, yyextra,    \
+  "illegal use of reserved word `%s'",
yytext);    \
+ return ERROR_TOK;    \
+  } else if (alt_expr) {    \
+ yylval->type = gtype;    \
    

Re: [Mesa-dev] [PATCH 5/5] gallium/util: don't call close() on Windows in u_tests.c

[Nicolai Hähnle]

For the series:

Reviewed-by: Nicolai Hähnle 

On 17.10.2017 23:17, Brian Paul wrote:

---
  src/gallium/auxiliary/util/u_tests.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_tests.c 
b/src/gallium/auxiliary/util/u_tests.c
index 3cc79af..2548b46 100644
--- a/src/gallium/auxiliary/util/u_tests.c
+++ b/src/gallium/auxiliary/util/u_tests.c
@@ -567,6 +567,7 @@ test_sync_file_fences(struct pipe_context *ctx)
 pass = pass && screen->fence_finish(screen, NULL, final_fence, 0);
  
 /* Cleanup. */

+#ifndef PIPE_OS_WINDOWS
 if (buf_fd >= 0)
close(buf_fd);
 if (tex_fd >= 0)
@@ -575,6 +576,7 @@ test_sync_file_fences(struct pipe_context *ctx)
close(merged_fd);
 if (final_fd >= 0)
close(final_fd);
+#endif
  
 screen->fence_reference(screen, _fence, NULL);

 screen->fence_reference(screen, _fence, NULL);




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] ac: Silence a compiler warning about results[0].

[Nicolai Hähnle]

Both patches:

Reviewed-by: Nicolai Hähnle 

On 17.10.2017 22:50, Eric Anholt wrote:

We know that num_components will be > 0, but it doesn't.
---
  src/amd/common/ac_nir_to_llvm.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 3ba3ebf051e2..07fa3fdf84b5 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2390,6 +2390,7 @@ static LLVMValueRef visit_load_buffer(struct 
ac_nir_context *ctx,
  
  	}
  
+	assume(results[0]);

LLVMValueRef ret = results[0];
if (num_components > 4 || num_components == 3) {
LLVMValueRef masks[] = {




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] radeonsi: postponed KILL isn't postponed anymore, but maintains WQM

[Nicolai Hähnle]

I found my peace with the new intrinsic for now. This series is

Reviewed-by: Nicolai Hähnle 

On 14.10.2017 02:58, Marek Olšák wrote:

From: Marek Olšák 

This restores performance for the drirc workaround, i.e.
KILL_IF does:
visible = src0 >= 0;
kill_flag &= visible; // accumulate kills
amdgcn_kill(wqm_vote(visible)); // kill fully dead quads only

And all helper pixels are killed at the end of the shader:
amdgcn_kill(kill_flag);
---
  src/amd/common/ac_llvm_build.c| 7 +++
  src/amd/common/ac_llvm_build.h| 1 +
  src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 6 ++
  3 files changed, 14 insertions(+)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 0550f80..2f8f59f 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1398,20 +1398,27 @@ LLVMValueRef ac_build_cvt_pkrtz_f16(struct 
ac_llvm_context *ctx,
   v2f16, args, 2,
   AC_FUNC_ATTR_READNONE);
return LLVMBuildBitCast(ctx->builder, res, ctx->i32, "");
}
  
  	return ac_build_intrinsic(ctx, "llvm.SI.packf16", ctx->i32, args, 2,

  AC_FUNC_ATTR_READNONE |
  AC_FUNC_ATTR_LEGACY);
  }
  
+LLVMValueRef ac_build_wqm_vote(struct ac_llvm_context *ctx, LLVMValueRef i1)

+{
+   assert(HAVE_LLVM >= 0x0600);
+   return ac_build_intrinsic(ctx, "llvm.amdgcn.wqm.vote", ctx->i1,
+ , 1, AC_FUNC_ATTR_READNONE);
+}
+
  void ac_build_kill_if_false(struct ac_llvm_context *ctx, LLVMValueRef i1)
  {
if (HAVE_LLVM >= 0x0600) {
ac_build_intrinsic(ctx, "llvm.amdgcn.kill", ctx->voidt,
   , 1, 0);
return;
}
  
  	LLVMValueRef value = LLVMBuildSelect(ctx->builder, i1,

 LLVMConstReal(ctx->f32, 1),
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index b721782..088a986 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -258,20 +258,21 @@ struct ac_image_args {
LLVMValueRef addr;
unsigned dmask;
bool unorm;
bool da;
  };
  
  LLVMValueRef ac_build_image_opcode(struct ac_llvm_context *ctx,

   struct ac_image_args *a);
  LLVMValueRef ac_build_cvt_pkrtz_f16(struct ac_llvm_context *ctx,
LLVMValueRef args[2]);
+LLVMValueRef ac_build_wqm_vote(struct ac_llvm_context *ctx, LLVMValueRef i1);
  void ac_build_kill_if_false(struct ac_llvm_context *ctx, LLVMValueRef i1);
  LLVMValueRef ac_build_bfe(struct ac_llvm_context *ctx, LLVMValueRef input,
  LLVMValueRef offset, LLVMValueRef width,
  bool is_signed);
  
  void ac_get_image_intr_name(const char *base_name,

LLVMTypeRef data_type,
LLVMTypeRef coords_type,
LLVMTypeRef rsrc_type,
char *out_name, unsigned out_len);
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
index 283a889..913b6c3 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
@@ -62,20 +62,26 @@ static void kil_emit(const struct lp_build_tgsi_action 
*action,
LLVMValueRef visible;
  
  	if (emit_data->inst->Instruction.Opcode == TGSI_OPCODE_KILL_IF) {

visible = emit_data->args[0];
} else {
assert(emit_data->inst->Instruction.Opcode == TGSI_OPCODE_KILL);
visible = LLVMConstInt(ctx->i1, false, 0);
}
  
  	if (ctx->shader->selector->force_correct_derivs_after_kill) {

+   /* LLVM 6.0 can kill immediately while maintaining WQM. */
+   if (HAVE_LLVM >= 0x0600) {
+   ac_build_kill_if_false(>ac,
+  ac_build_wqm_vote(>ac, 
visible));
+   }
+
LLVMValueRef mask = LLVMBuildLoad(builder, ctx->postponed_kill, 
"");
mask = LLVMBuildAnd(builder, mask, visible, "");
LLVMBuildStore(builder, mask, ctx->postponed_kill);
return;
}
  
  	ac_build_kill_if_false(>ac, visible);

  }
  
  static void emit_icmp(const struct lp_build_tgsi_action *action,





--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 1/2] glsl: allow any l-value of an input variable as interpolant in interpolateAt*

[Nicolai Hähnle]

Ping?

On 10.10.2017 14:09, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

The intended rule has been clarified in GLSL 4.60, Section 8.13.2
(Interpolation Functions):

"For all of the interpolation functions, interpolant must be an l-value
 from an in declaration; this can include a variable, a block or
 structure member, an array element, or some combination of these.
 Component selection operators (e.g., .xy) may be used when specifying
 interpolant."

For members of interface blocks, var->data.must_be_shader_input must be
determined on-the-fly after lowering interface blocks, since we don't want
to disable varying packing for an entire block just because one input in it
is used in interpolateAt*.

v2: keep setting must_be_shader_input in ast_function (Ian)
v3: follow the relaxed rule of GLSL 4.60
v4: only apply the relaxed rules to desktop GL
 (the ES WG decided that the relaxed rules may apply in a future version
  but not retroactively; see also
  
dEQP-GLES31.functional.shaders.multisample_interpolation.interpolate_at_centroid.negative.*)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101378
Reviewed-by: Ian Romanick  (v1)
---
  src/compiler/glsl/ast_function.cpp | 19 ++-
  src/compiler/glsl/lower_named_interface_blocks.cpp | 18 ++
  2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/src/compiler/glsl/ast_function.cpp 
b/src/compiler/glsl/ast_function.cpp
index 46a61e46fd5..d1596c272e6 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -220,33 +220,42 @@ verify_parameter_modes(_mesa_glsl_parse_state *state,
   if (val->ir_type == ir_type_swizzle) {
  if (!state->is_version(440, 0)) {
 _mesa_glsl_error(, state,
  "parameter `%s` must not be swizzled",
  formal->name);
 return false;
  }
  val = ((ir_swizzle *)val)->val;
   }
  
- while (val->ir_type == ir_type_dereference_array) {

-val = ((ir_dereference_array *)val)->array;
+ for (;;) {
+if (val->ir_type == ir_type_dereference_array) {
+   val = ((ir_dereference_array *)val)->array;
+} else if (val->ir_type == ir_type_dereference_record &&
+   !state->es_shader) {
+   val = ((ir_dereference_record *)val)->record;
+} else
+   break;
   }
  
- if (!val->as_dereference_variable() ||

- val->variable_referenced()->data.mode != ir_var_shader_in) {
+ ir_variable *var = NULL;
+ if (const ir_dereference_variable *deref_var = 
val->as_dereference_variable())
+var = deref_var->variable_referenced();
+
+ if (!var || var->data.mode != ir_var_shader_in) {
  _mesa_glsl_error(, state,
   "parameter `%s` must be a shader input",
   formal->name);
  return false;
   }
  
- val->variable_referenced()->data.must_be_shader_input = 1;

+ var->data.must_be_shader_input = 1;
}
  
/* Verify that 'out' and 'inout' actual parameters are lvalues. */

if (formal->data.mode == ir_var_function_out
|| formal->data.mode == ir_var_function_inout) {
   const char *mode = NULL;
   switch (formal->data.mode) {
   case ir_var_function_out:   mode = "out";   break;
   case ir_var_function_inout: mode = "inout"; break;
   default:assert(false);  break;
diff --git a/src/compiler/glsl/lower_named_interface_blocks.cpp 
b/src/compiler/glsl/lower_named_interface_blocks.cpp
index 064694128bf..136352a131b 100644
--- a/src/compiler/glsl/lower_named_interface_blocks.cpp
+++ b/src/compiler/glsl/lower_named_interface_blocks.cpp
@@ -108,20 +108,21 @@ public:
  
 flatten_named_interface_blocks_declarations(void *mem_ctx)

: mem_ctx(mem_ctx),
  interface_namespace(NULL)
 {
 }
  
 void run(exec_list *instructions);
  
 virtual ir_visitor_status visit_leave(ir_assignment *);

+   virtual ir_visitor_status visit_leave(ir_expression *);
 virtual void handle_rvalue(ir_rvalue **rvalue);
  };
  
  } /* anonymous namespace */
  
  void

  flatten_named_interface_blocks_declarations::run(exec_list *instructions)
  {
 interface_namespace = _mesa_hash_table_create(NULL, _mesa_key_hash_string,
   _mesa_key_string_equal);
@@ -231,20 +232,37 @@ 
flatten_named_interface_blocks_declarations::visit_leave(ir_assignment *ir)
}
  
ir_variable *lhs_var =  lhs_rec_tmp->variable_referenced();

if (lhs_var) {
   lhs_var->data.assigned = 1;
}
 }
 return rvalue_visit(ir);
  }

Re: [Mesa-dev] create src/wsi

[Nicolai Hähnle]

On 23.10.2017 17:16, Emil Velikov wrote:

On 23 October 2017 at 16:03, Jason Ekstrand  wrote:

On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle  wrote:


On 21.10.2017 03:00, Dylan Baker wrote:


This very short series creates a new src/wsi folder, and moves
wayland-drm into
it. Basically wsi stuff is scattered about, and is needed by multiple
components
within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan
wayland-wsi.

I think there's more that could be moved into wsi, we could move EGL,
GBM, and
GLX, and vulkan/wsi, for example.



The general thrust sounds good to me.

Is there a clean model for what should go into src/wsi and what shouldn't?
Where's the boundary?

For an example of the type of headaches, does DRI driver code (stuff that
ends up in xxx_dri.so, for example) count as part of src/wsi? If so, then
what about gallium/state_trackers/dri? What about mesa/drivers/dri/common?



Maybe?  I guess it depends on what it does and how much sense it makes to
share it higher than the gallium level.



I don't have a full picture of all this code so it's hard for me to say,
but I really hope your changes will lead to a clearer picture overall :)



Dylan and I talked about it quite a bit off-line so I have a few opinions.
:)  In particular, here's what I envison:

src/wsi/gbm
src/wsi/egl
src/wsi/wayland-drm
src/wsi/dri3 (currently src/loader)
src/wsi/glx
src/wsi/vulkan (currently src/vulkan/wsi)
src/wsi/hgl


Idea is mostly ok, but there's a bit of a snafu:

Things are not as clean cut/split as per above. Here are some of the
current inter-dependencies.

src/loader - loader.c WSI agnostic DRI loader code.
src/loader - loader_dri3.c X11 DRI3 code.

gbm - depends on loader.c, wayland-drm (I've sent patches to remove this), egl
egl  - depends on loader.c loader_dri3.c wayland-drm, gbm (pokes one
of the AMD devs to attempt this)


Which part / what do you mean?

I'm perfectly fine with keeping the state_tracker/dri/ and dri/common 
bits where they are, I just wanted to get some clarification :)


Cheers,
Nicolai



vulkan - has completely different wayland-drm/X11 dri3 code.

One could be able to flatten and use uniform interface across the
board. I would be weary as above code gets limited testing with
piglit/CTS/dEQP.

-Emil




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] mesa 17.3.0-rc1

[Nicolai Hähnle]

On 23.10.2017 15:46, Emil Velikov wrote:

  1 Nicolai Hähnle
  3 Nicolai Hähnle
270 Nicolai Hähnle


:(

I blame Ubuntu 17.04.

Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] Haiku: convert to autotools

[Jerome Duval]

* configure.ac:
  -pthread is not available on Haiku.
  Haiku doesn't require --enable-dri
  build hgl on Haiku
* egl/Makefile.am: define backendfiles for Haiku
* src/gallium/Makefile.am: build winsys/sw/hgl, state_trackers/hgl and
targets/haiku-softpipe on Haiku.
* src/gallium/targets/haiku-softpipe: add Makefile.am
* src/gallium/state_trackers/hgl: add Makefile.am
* winsys/sw/hgl: add Makefile.am
* src/hgl/Makefile.am: add Makefile.am
---
 configure.ac   | 30 +-
 src/Makefile.am|  4 ++
 src/egl/Makefile.am| 20 ++-
 src/gallium/Makefile.am|  9 ++-
 src/gallium/state_trackers/hgl/Makefile.am | 39 
 src/gallium/state_trackers/hgl/Makefile.sources|  3 +
 src/gallium/targets/haiku-softpipe/Makefile.am | 69 ++
 .../targets/haiku-softpipe/SoftwareRenderer.cpp|  2 +
 src/gallium/winsys/sw/hgl/Makefile.am  | 34 +++
 src/gallium/winsys/sw/hgl/Makefile.sources |  3 +
 src/hgl/Makefile.am| 50 
 src/hgl/Makefile.sources   |  8 +++
 src/hgl/gl.pc.in   | 11 
 13 files changed, 277 insertions(+), 5 deletions(-)
 create mode 100644 src/gallium/state_trackers/hgl/Makefile.am
 create mode 100644 src/gallium/state_trackers/hgl/Makefile.sources
 create mode 100644 src/gallium/targets/haiku-softpipe/Makefile.am
 create mode 100644 src/gallium/winsys/sw/hgl/Makefile.am
 create mode 100644 src/gallium/winsys/sw/hgl/Makefile.sources
 create mode 100644 src/hgl/Makefile.am
 create mode 100644 src/hgl/Makefile.sources
 create mode 100644 src/hgl/gl.pc.in

diff --git a/configure.ac b/configure.ac
index add3830..1d8efc5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -272,6 +272,9 @@ case "$host_os" in
 *-android*)
 android=yes
 ;;
+*haiku)
+haiku=yes
+;;
 linux*|*-gnu*|gnu*|cygwin*)
 DEFINES="$DEFINES -D_GNU_SOURCE"
 ;;
@@ -281,6 +284,7 @@ solaris*)
 esac
 
 AM_CONDITIONAL(HAVE_ANDROID, test "x$android" = xyes)
+AM_CONDITIONAL(HAVE_HAIKU, test "x$haiku" = xyes)
 
 dnl
 dnl Check compiler flags
@@ -863,12 +867,18 @@ dnl According to the manual when using pthreads, one 
should add -pthread to
 dnl both compile and link-time arguments.
 dnl In practise that should be sufficient for all platforms, since any
 dnl platforms build with GCC and Clang support the flag.
-PTHREAD_LIBS="$PTHREAD_LIBS -pthread"
+case "$host_os" in
+haiku*)
+;;
+* )
+PTHREAD_LIBS="$PTHREAD_LIBS -pthread"
+;;
+esac
 
 dnl pthread-stubs is mandatory on BSD platforms, due to the nature of the
 dnl project. Even then there's a notable issue as described in the project 
README
 case "$host_os" in
-linux* | cygwin* | darwin* | solaris* | *-gnu* | gnu*)
+linux* | cygwin* | darwin* | solaris* | *-gnu* | gnu* | haiku*)
 pthread_stubs_possible="no"
 ;;
 * )
@@ -1518,7 +1528,12 @@ require_dri_shared_libs_and_glapi() {
 if test "x$enable_dri" != xyes; then
 # There is only a single backend which won't be build/used otherwise.
 # XXX: Revisit this as the egl/haiku is a thing.
-AC_MSG_ERROR([$1 requires --enable-dri])
+case "$host_os" in
+haiku*)
+;;
+*)
+AC_MSG_ERROR([$1 requires --enable-dri]) ;;
+   esac
 fi
 
 if test "x$enable_shared_glapi" != xyes; then
@@ -1748,6 +1763,10 @@ for plat in $platforms; do
 DEFINES="$DEFINES -DHAVE_ANDROID_PLATFORM"
 ;;
 
+haiku)
+DEFINES="$DEFINES -DHAVE_HAIKU_PLATFORM"
+;;
+
 *)
 AC_MSG_ERROR([platform '$plat' does not exist])
 ;;
@@ -2891,6 +2910,7 @@ AC_CONFIG_FILES([Makefile
  src/gallium/state_trackers/clover/Makefile
  src/gallium/state_trackers/dri/Makefile
  src/gallium/state_trackers/glx/xlib/Makefile
+ src/gallium/state_trackers/hgl/Makefile
  src/gallium/state_trackers/nine/Makefile
  src/gallium/state_trackers/omx_bellagio/Makefile
  src/gallium/state_trackers/osmesa/Makefile
@@ -2901,6 +2921,7 @@ AC_CONFIG_FILES([Makefile
  src/gallium/targets/d3dadapter9/Makefile
  src/gallium/targets/d3dadapter9/d3d.pc
  src/gallium/targets/dri/Makefile
+ src/gallium/targets/haiku-softpipe/Makefile
  src/gallium/targets/libgl-xlib/Makefile
  src/gallium/targets/omx-bellagio/Makefile
  src/gallium/targets/opencl/Makefile
@@ -2925,6 +2946,7 @@ AC_CONFIG_FILES([Makefile
  src/gallium/winsys/amdgpu/drm/Makefile
  src/gallium/winsys/svga/drm/Makefile
  src/gallium/winsys/sw/dri/Makefile
+ src/gallium/winsys/sw/hgl/Makefile
   

Re: [Mesa-dev] [PATCH V2 1/4] i965/gen10: Implement WaSampleOffsetIZ workaround

[Anuj Phogat]

Ping. Patches 2-4 in this series are still waiting for review.
Anyone interested?
Thanks!



On Fri, Oct 13, 2017 at 3:35 PM, Rafael Antognolli
 wrote:
> Hi Anuj, sorry that I missed this patch. Please see below.
>
> On Fri, Oct 06, 2017 at 04:30:47PM -0700, Anuj Phogat wrote:
>> There are few other (duplicate) workarounds which have similar 
>> recommendations:
>> WaFlushHangWhenNonPipelineStateAndMarkerStalled
>> WaCSStallBefore3DSamplePattern
>> WaPipeControlBefore3DStateSamplePattern
>>
>> WaPipeControlBefore3DStateSamplePattern has some extra recommendations if
>> driver is using mid batch context restore. Ignoring it for now because We're
>> not doing mid-batch context restore in Mesa.
>>
>> Cc: mesa-sta...@lists.freedesktop.org
>> Cc: Jason Ekstrand 
>> Cc: Rafael Antognolli 
>> Signed-off-by: Anuj Phogat 
>> ---
>>  src/mesa/drivers/dri/i965/brw_context.h|  2 +
>>  src/mesa/drivers/dri/i965/brw_defines.h|  1 +
>>  src/mesa/drivers/dri/i965/brw_pipe_control.c   | 50 
>> ++
>>  src/mesa/drivers/dri/i965/gen8_multisample_state.c |  8 
>>  4 files changed, 61 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
>> b/src/mesa/drivers/dri/i965/brw_context.h
>> index 92fc16de13..f0e8d562e9 100644
>> --- a/src/mesa/drivers/dri/i965/brw_context.h
>> +++ b/src/mesa/drivers/dri/i965/brw_context.h
>> @@ -1647,6 +1647,8 @@ void brw_emit_post_sync_nonzero_flush(struct 
>> brw_context *brw);
>>  void brw_emit_depth_stall_flushes(struct brw_context *brw);
>>  void gen7_emit_vs_workaround_flush(struct brw_context *brw);
>>  void gen7_emit_cs_stall_flush(struct brw_context *brw);
>> +void gen10_emit_wa_cs_stall_flush(struct brw_context *brw);
>> +void gen10_emit_wa_lri_to_cache_mode_zero(struct brw_context *brw);
>>
>>  /* brw_queryformat.c */
>>  void brw_query_internal_format(struct gl_context *ctx, GLenum target,
>> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
>> b/src/mesa/drivers/dri/i965/brw_defines.h
>> index 4abb790612..270cdf29db 100644
>> --- a/src/mesa/drivers/dri/i965/brw_defines.h
>> +++ b/src/mesa/drivers/dri/i965/brw_defines.h
>> @@ -1609,6 +1609,7 @@ enum brw_pixel_shader_coverage_mask_mode {
>>  #define GEN7_GPGPU_DISPATCHDIMY 0x2504
>>  #define GEN7_GPGPU_DISPATCHDIMZ 0x2508
>>
>> +#define GEN7_CACHE_MODE_0   0x7000
>>  #define GEN7_CACHE_MODE_1   0x7004
>>  # define GEN9_FLOAT_BLEND_OPTIMIZATION_ENABLE (1 << 4)
>>  # define GEN8_HIZ_NP_PMA_FIX_ENABLE(1 << 11)
>> diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c 
>> b/src/mesa/drivers/dri/i965/brw_pipe_control.c
>> index 460b8f73b6..156f5c25ec 100644
>> --- a/src/mesa/drivers/dri/i965/brw_pipe_control.c
>> +++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
>> @@ -278,6 +278,56 @@ gen7_emit_cs_stall_flush(struct brw_context *brw)
>> brw->workaround_bo, 0, 0);
>>  }
>>
>> +static void
>> +brw_flush_gpu_caches(struct brw_context *brw) {
>> +   brw_emit_pipe_control_flush(brw,
>> +   PIPE_CONTROL_CACHE_FLUSH_BITS |
>> +   PIPE_CONTROL_CACHE_INVALIDATE_BITS);
>> +}
>
> This function is only calling another function without any extra logic, so I
> would just call brw_emit_pipe_control_flush() and remove this declaration. But
> that's just cosmetic.
>
> With or without this change, this patch correctly implements the workaround
> imho, so it is
>
> Reviewed-by: Rafael Antognolli 
>
>> +/**
>> + * From Gen10 Workarounds page in h/w specs:
>> + * WaSampleOffsetIZ:
>> + * Prior to the 3DSTATE_SAMPLE_PATTERN driver must ensure there are no
>> + * markers in the pipeline by programming a PIPE_CONTROL with stall.
>> + */
>> +void
>> +gen10_emit_wa_cs_stall_flush(struct brw_context *brw)
>> +{
>> +   const struct gen_device_info *devinfo = >screen->devinfo;
>> +   assert(devinfo->gen == 10);
>> +   brw_emit_pipe_control_flush(brw,
>> +   PIPE_CONTROL_CS_STALL |
>> +   PIPE_CONTROL_STALL_AT_SCOREBOARD);
>> +}
>> +
>> +/**
>> + * From Gen10 Workarounds page in h/w specs:
>> + * WaSampleOffsetIZ:
>> + * When 3DSTATE_SAMPLE_PATTERN is programmed, driver must then issue an
>> + * MI_LOAD_REGISTER_IMM command to an offset between 0x7000 and 0x7FFF(SVL)
>> + * after the command to ensure the state has been delivered prior to any
>> + * command causing a marker in the pipeline.
>> + */
>> +void
>> +gen10_emit_wa_lri_to_cache_mode_zero(struct brw_context *brw)
>> +{
>> +   const struct gen_device_info *devinfo = >screen->devinfo;
>> +   assert(devinfo->gen == 10);
>> +
>> +   /* Before changing the value of CACHE_MODE_0 register, GFX pipeline must
>> +* be idle; i.e., full flush is required.
>> +*/
>> +   brw_flush_gpu_caches(brw);
>> +
>> +   /* Write to 

Re: [Mesa-dev] [PATCH 7/9] wayland-drm: static inline wayland_drm_buffer_get

[Daniel Stone]

Hi Emil,

On 28 September 2017 at 13:36, Emil Velikov  wrote:
> On 20 September 2017 at 15:06, Daniel Stone  wrote:
>> On 19 September 2017 at 11:25, Emil Velikov  wrote:
>>> It looks a bit icky and my Wayland knowledge is limited to actually review 
>>> it.
>>>
>>> I still think that we're trying to do different things - me simplify
>>> things, while you're focusing on fixing a bug.
>>
>> I like the idea of the simplification, but it's just that a) it can't
>> actually be simplified that far, and b) whilst we still rely on
>> consistent resolution of wl_buffer_interface, your proposed change may
>> actually _introduce_ a bug.
>
> Right, I did not see that one. Can you share your train of thought?

Happily!

When a compositor creates a client buffer, the request is dispatched
by libwayland-server.so into libEGL.so (libEGL explicitly links
libwayland-server). This lands in
src/egl/wayland/wayland-drm/wayland-drm.c's create_buffer(), which
calls wl_resource_create() with 'wl_buffer_interface'. Since libEGL.so
is explicitly linked against both libwayland-client and
libwayland-server, and both of those DSOs provide a resolution of
wl_buffer_interface, resource->interface could be
libwayland-server.so::wl_buffer_interface, or
libwayland-client.so::wl_buffer_interface.

When a compositor wants to import a buffer into GBM, it calls
gbm_bo_import(), which will call wl_drm_buffer_get().
wl_drm_buffer_get will test (resource->interface ==
_buffer_interface). Previously, both create_buffer() and
wl_drm_buffer_get() at least came from the same compilation unit, but
now they are built and linked separately. This seems to make an
existing problem (ambiguity of 'wl_buffer_interface') worse (symbol
resolution now performed in separate compilation units).

I don't really see a solution to this, apart from no longer relying on
having a single canonical resolution of wl_buffer_interface. The above
patch implements that, by removing the interface-address-equal test
and replacing it with the destroy-listener test. The patch I provided
is equally valid both with and without your series.

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

Re: [Mesa-dev] create src/wsi

[Jason Ekstrand]

On Mon, Oct 23, 2017 at 8:16 AM, Emil Velikov 
wrote:

> On 23 October 2017 at 16:03, Jason Ekstrand  wrote:
> > On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle 
> wrote:
> >>
> >> On 21.10.2017 03:00, Dylan Baker wrote:
> >>>
> >>> This very short series creates a new src/wsi folder, and moves
> >>> wayland-drm into
> >>> it. Basically wsi stuff is scattered about, and is needed by multiple
> >>> components
> >>> within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan
> >>> wayland-wsi.
> >>>
> >>> I think there's more that could be moved into wsi, we could move EGL,
> >>> GBM, and
> >>> GLX, and vulkan/wsi, for example.
> >>
> >>
> >> The general thrust sounds good to me.
> >>
> >> Is there a clean model for what should go into src/wsi and what
> shouldn't?
> >> Where's the boundary?
> >>
> >> For an example of the type of headaches, does DRI driver code (stuff
> that
> >> ends up in xxx_dri.so, for example) count as part of src/wsi? If so,
> then
> >> what about gallium/state_trackers/dri? What about
> mesa/drivers/dri/common?
> >
> >
> > Maybe?  I guess it depends on what it does and how much sense it makes to
> > share it higher than the gallium level.
> >
> >>
> >> I don't have a full picture of all this code so it's hard for me to say,
> >> but I really hope your changes will lead to a clearer picture overall :)
> >
> >
> > Dylan and I talked about it quite a bit off-line so I have a few
> opinions.
> > :)  In particular, here's what I envison:
> >
> > src/wsi/gbm
> > src/wsi/egl
> > src/wsi/wayland-drm
> > src/wsi/dri3 (currently src/loader)
> > src/wsi/glx
> > src/wsi/vulkan (currently src/vulkan/wsi)
> > src/wsi/hgl
> >
> Idea is mostly ok, but there's a bit of a snafu:
>
> Things are not as clean cut/split as per above. Here are some of the
> current inter-dependencies.
>
> src/loader - loader.c WSI agnostic DRI loader code.
> src/loader - loader_dri3.c X11 DRI3 code.
>

Ok, so maybe src/wsi/dri3 isn't quite the right name.  Maybe we need a
src/wsi/dri-loader.


> gbm - depends on loader.c, wayland-drm (I've sent patches to remove this),
> egl
> egl  - depends on loader.c loader_dri3.c wayland-drm, gbm (pokes one
> of the AMD devs to attempt this)
> vulkan - has completely different wayland-drm/X11 dri3 code.
>

It does share some code with EGL which is implemented terribly at the
moment.  In particular, we need to share all of the Wayland XML and
generated headers and protocol source files.  If we ever did a server-side
Wayland Vulkan extension (which I think is probably unlikely), we could
possibly re-use the rest of wayland-drm.  This was part of the motivation
for doing this rework.


> One could be able to flatten and use uniform interface across the
> board.


I'm not sure what you mean by that.  I don't think it's worth it to try and
make a common core codebase to share between GLX, EGL, and Vulkan WSI.
Vulkan is enough different, that I think the current plan of re-rolling the
WSI bits almost entirely is the best plan.


> I would be weary as above code gets limited testing with
> piglit/CTS/dEQP.
>

Agreed!  However, what Dylan is trying to do doesn't involve changing
anything more than some include directories so it should be reasonably safe.

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

Re: [Mesa-dev] [PATCH v3] egl/wayland: Support for KHR_partial_update

[Emil Velikov]

On 23 October 2017 at 11:50, Harish Krupo  wrote:
> This passes 33/37 deqp tests related to partial_update, 4 are not
> supported. Tests not supported:
> dEQP-EGL.functional.negative_partial_update.not_postable_surface
> dEQP-EGL.functional.negative_partial_update.not_current_surface
> dEQP-EGL.functional.negative_partial_update.buffer_preserved
> dEQP-EGL.functional.negative_partial_update.not_current_surface2
> Reason: No matching egl config found.
>
> v2: Remove unnecessary return statement. Keep function names
> consistent.  (Emil Velikov)
> Add not supported list to commit message. (Eric Engestrom)
>
> v3: Remove explicit with_damage variable. (Eric Engestrom)
>
Did you send the wrong version by any chance?
The summary does not reflect the actual changes.

Why did you rework try_damage_buffer into dri2_wl_set_damage_region?
It seems harder to follow over the previous patches.


> @@ -928,7 +944,8 @@ dri2_wl_query_buffer_age(_EGLDriver *drv,
>  static EGLBoolean
>  dri2_wl_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *draw)
>  {
> -   return dri2_wl_swap_buffers_with_damage(drv, disp, draw, NULL, 0);
> +   return dri2_wl_swap_buffers_with_damage(drv, disp, draw,
> +  NULL, 0);

Unrelated noop change.

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

Re: [Mesa-dev] create src/wsi

[Emil Velikov]

On 23 October 2017 at 16:03, Jason Ekstrand  wrote:
> On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle  wrote:
>>
>> On 21.10.2017 03:00, Dylan Baker wrote:
>>>
>>> This very short series creates a new src/wsi folder, and moves
>>> wayland-drm into
>>> it. Basically wsi stuff is scattered about, and is needed by multiple
>>> components
>>> within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan
>>> wayland-wsi.
>>>
>>> I think there's more that could be moved into wsi, we could move EGL,
>>> GBM, and
>>> GLX, and vulkan/wsi, for example.
>>
>>
>> The general thrust sounds good to me.
>>
>> Is there a clean model for what should go into src/wsi and what shouldn't?
>> Where's the boundary?
>>
>> For an example of the type of headaches, does DRI driver code (stuff that
>> ends up in xxx_dri.so, for example) count as part of src/wsi? If so, then
>> what about gallium/state_trackers/dri? What about mesa/drivers/dri/common?
>
>
> Maybe?  I guess it depends on what it does and how much sense it makes to
> share it higher than the gallium level.
>
>>
>> I don't have a full picture of all this code so it's hard for me to say,
>> but I really hope your changes will lead to a clearer picture overall :)
>
>
> Dylan and I talked about it quite a bit off-line so I have a few opinions.
> :)  In particular, here's what I envison:
>
> src/wsi/gbm
> src/wsi/egl
> src/wsi/wayland-drm
> src/wsi/dri3 (currently src/loader)
> src/wsi/glx
> src/wsi/vulkan (currently src/vulkan/wsi)
> src/wsi/hgl
>
Idea is mostly ok, but there's a bit of a snafu:

Things are not as clean cut/split as per above. Here are some of the
current inter-dependencies.

src/loader - loader.c WSI agnostic DRI loader code.
src/loader - loader_dri3.c X11 DRI3 code.

gbm - depends on loader.c, wayland-drm (I've sent patches to remove this), egl
egl  - depends on loader.c loader_dri3.c wayland-drm, gbm (pokes one
of the AMD devs to attempt this)
vulkan - has completely different wayland-drm/X11 dri3 code.

One could be able to flatten and use uniform interface across the
board. I would be weary as above code gets limited testing with
piglit/CTS/dEQP.

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

Re: [Mesa-dev] create src/wsi

[Jason Ekstrand]

On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle  wrote:

> On 21.10.2017 03:00, Dylan Baker wrote:
>
>> This very short series creates a new src/wsi folder, and moves
>> wayland-drm into
>> it. Basically wsi stuff is scattered about, and is needed by multiple
>> components
>> within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan
>> wayland-wsi.
>>
>> I think there's more that could be moved into wsi, we could move EGL,
>> GBM, and
>> GLX, and vulkan/wsi, for example.
>>
>
> The general thrust sounds good to me.
>
> Is there a clean model for what should go into src/wsi and what shouldn't?
> Where's the boundary?
>
> For an example of the type of headaches, does DRI driver code (stuff that
> ends up in xxx_dri.so, for example) count as part of src/wsi? If so, then
> what about gallium/state_trackers/dri? What about mesa/drivers/dri/common?
>

Maybe?  I guess it depends on what it does and how much sense it makes to
share it higher than the gallium level.


> I don't have a full picture of all this code so it's hard for me to say,
> but I really hope your changes will lead to a clearer picture overall :)
>

Dylan and I talked about it quite a bit off-line so I have a few opinions.
:)  In particular, here's what I envison:

src/wsi/gbm
src/wsi/egl
src/wsi/wayland-drm
src/wsi/dri3 (currently src/loader)
src/wsi/glx
src/wsi/vulkan (currently src/vulkan/wsi)
src/wsi/hgl

So, basically, it's window system integration layers and the helpers we
want to share among them.  I wasn't envisioning it containing anything to
handle the DRI layer though I suppose it probably could.

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

Re: [Mesa-dev] [PATCH 5/7] u_queue: add a futex-based implementation of fences

[Grazvydas Ignotas]

On Mon, Oct 23, 2017 at 4:04 PM, Nicolai Hähnle  wrote:
> On 23.10.2017 13:50, Grazvydas Ignotas wrote:
>>
>> On Sun, Oct 22, 2017 at 9:33 PM, Nicolai Hähnle 
>> wrote:
>>>
>>> From: Nicolai Hähnle 
>>>
>>> Fences are now 4 bytes instead of 96 bytes (on my 64-bit system).
>>>
>>> Signaling a fence is a single atomic operation in the fast case plus a
>>> syscall in the slow case.
>>>
>>> Testing if a fence is signaled is the same as before (a simple
>>> comparison),
>>> but waiting on a fence is now no more expensive than just testing it in
>>> the fast (already signaled) case.
>>> ---
>>>   src/util/futex.h   |  4 +++
>>>   src/util/u_queue.c |  2 ++
>>>   src/util/u_queue.h | 88
>>> ++
>>>   3 files changed, 94 insertions(+)
>>>
>>> ...
>>>
>>> diff --git a/src/util/u_queue.h b/src/util/u_queue.h
>>> index a3e12260e30..3d9f19f4e6c 100644
>>> --- a/src/util/u_queue.h
>>> +++ b/src/util/u_queue.h
>>> @@ -28,30 +28,117 @@
>>>*
>>>* Jobs can be added from any thread. After that, the wait call can be
>>> used
>>>* to wait for completion of the job.
>>>*/
>>>
>>>   #ifndef U_QUEUE_H
>>>   #define U_QUEUE_H
>>>
>>>   #include 
>>>
>>> +#include "util/futex.h"
>>>   #include "util/list.h"
>>> +#include "util/macros.h"
>>>   #include "util/u_thread.h"
>>>
>>>   #ifdef __cplusplus
>>>   extern "C" {
>>>   #endif
>>>
>>>   #define UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY  (1 << 0)
>>>   #define UTIL_QUEUE_INIT_RESIZE_IF_FULL(1 << 1)
>>>
>>> +#if defined(__GNUC__) && defined(HAVE_FUTEX)
>>> +#define UTIL_QUEUE_FENCE_FUTEX
>>> +#else
>>> +#define UTIL_QUEUE_FENCE_STANDARD
>>> +#endif
>>> +
>>> +#ifdef UTIL_QUEUE_FENCE_FUTEX
>>> +/* Job completion fence.
>>> + * Put this into your job structure.
>>> + */
>>> +struct util_queue_fence {
>>> +   /* The fence can be in one of three states:
>>> +*  0 - signaled
>>> +*  1 - unsignaled
>>> +*  2 - unsignaled, may have waiters
>>> +*/
>>> +   uint32_t val;
>>> +};
>>> +
>>> +static inline void
>>> +util_queue_fence_init(struct util_queue_fence *fence)
>>> +{
>>> +   fence->val = 0;
>>> +}
>>> +
>>> +static inline void
>>> +util_queue_fence_destroy(struct util_queue_fence *fence)
>>> +{
>>> +   assert(fence->val == 0);
>>> +   /* no-op */
>>> +}
>>> +
>>> +static inline void
>>> +util_queue_fence_wait(struct util_queue_fence *fence)
>>> +{
>>> +   uint32_t v = fence->val;
>>> +
>>> +   if (likely(v == 0))
>>> +  return;
>>> +
>>> +   do {
>>> +  if (v != 2)
>>> + v = __sync_val_compare_and_swap(>val, 1, 2);
>>> +
>>> +  futex_wait(>val, 2);
>>> +  v = fence->val;
>>> +   } while(v != 0);
>>> +}
>>> +
>>> +static inline void
>>> +util_queue_fence_signal(struct util_queue_fence *fence)
>>> +{
>>> +   uint32_t val = __sync_lock_test_and_set(>val, 0);
>>
>>
>> As this is _signal(), don't you need a full barrier here?
>
>
> You're right. It's a bit surprising that __sync_lock_test_and_set isn't one.
>
>
>>> +
>>> +   assert(val != 0);
>>> +
>>> +   if (val == 2)
>>
>>
>> The documentation says some architectures may only support a constant
>> of 1 here...
>
>
> Again, surprising, but you're right.
>
> I believe both of these could be addressed by using
> __sync_val_compare_and_swap instead, right?

I believe so too.

> Or we could move to new-style gcc atomic built-ins, but I'm not sure
> off-hand how widely available those are.

There's u_atomic.h that already uses some __atomic_*() built-ins,
p_atomic_cmpxchg is just __sync_val_compare_and_swap but could use it
for consistency with other mesa code.

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

Re: [Mesa-dev] [PATCH v2] clover: Fix compilation after clang r315871

[Jan Vesely]

On Sun, 2017-10-22 at 20:40 -0700, Francisco Jerez wrote:
> Jan Vesely  writes:
> 
> > From: Jan Vesely 
> > 
> > v2: use a more generic compat function
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103388
> > Signed-off-by: Jan Vesely 
> > ---
> >  src/gallium/state_trackers/clover/llvm/codegen/common.cpp |  5 ++---
> >  src/gallium/state_trackers/clover/llvm/compat.hpp | 12 ++--
> >  2 files changed, 12 insertions(+), 5 deletions(-)
> > 
> > diff --git a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp 
> > b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
> > index 075183400a..dd9d02ab11 100644
> > --- a/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
> > +++ b/src/gallium/state_trackers/clover/llvm/codegen/common.cpp
> > @@ -70,7 +70,6 @@ namespace {
> > make_kernel_args(const Module , const std::string _name,
> >  const clang::CompilerInstance ) {
> >std::vector args;
> > -  const auto address_spaces = c.getTarget().getAddressSpaceMap();
> >const Function  = *mod.getFunction(kernel_name);
> >::llvm::DataLayout dl();
> >const auto size_type =
> > @@ -128,8 +127,8 @@ namespace {
> > const unsigned address_space =
> >cast< 
> > ::llvm::PointerType>(actual_type)->getAddressSpace();
> >  
> > -   if (address_space == 
> > address_spaces[clang::LangAS::opencl_local
> > -   - 
> > compat::lang_as_offset]) {
> > +   if (address_space == compat::target_lang_address_space(
> > +  c.getTarget(), 
> > clang::LangAS::opencl_local)) {
> >args.emplace_back(module::argument::local, arg_api_size,
> >  target_size, target_align,
> >  module::argument::zero_ext);
> > diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> > b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > index f8b56516d5..3e34f0dd94 100644
> > --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> > +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > @@ -69,11 +69,19 @@ namespace clover {
> >   typedef ::llvm::TargetLibraryInfo target_library_info;
> >  #endif
> >  
> > + template
> > + unsigned target_lang_address_space(const T& target, const AS 
> > lang_as) {
> 
> Can you name this "target_address_space" (to me lang address space means
> the LangAS enum, i.e. the non-target-dependent representation, which is
> not what you get as result from this function), and place the '&' sign
> consistently in the argument declaration? 

Does this refer only to whitespace around "T& target", or would you
prefer to pass lang_as as reference as well? (it's an integral type so
I did not consider it necessary).

Jan

>  With that cleaned up patch
> is:
> 
> Reviewed-by: Francisco Jerez 
> 
> Thanks!
> 
> > +const auto  = target.getAddressSpaceMap();
> > +#if HAVE_LLVM >= 0x0500
> > +return map[static_cast(lang_as)];
> > +#else
> > +return map[lang_as - clang::LangAS::Offset];
> > +#endif
> > + }
> > +
> >  #if HAVE_LLVM >= 0x0500
> > - const auto lang_as_offset = 0;
> >   const clang::InputKind ik_opencl = clang::InputKind::OpenCL;
> >  #else
> > - const auto lang_as_offset = clang::LangAS::Offset;
> >   const clang::InputKind ik_opencl = clang::IK_OpenCL;
> >  #endif
> >  
> > -- 
> > 2.13.6


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] [ANNOUNCE] mesa 17.3.0-rc1

[Emil Velikov]

The first release candidate for Mesa 17.3.0 is now available.

The plan is to have one release candidate every Friday, until the final
release on 11th November 2017.

The expectation is that the 17.2 branch will remain alive with bi-weekly
releases until the 17.3.1 release.

Here are the people which helped shape the current release.

 4 Aaron Watry
10 Adam Jackson
 5 Alex Smith
 1 Alexandru-Liviu Prodea
12 Andres Gomez
28 Andres Rodriguez
 8 Anuj Phogat
   100 Bas Nieuwenhuizen
 5 Ben Crocker
 4 Ben Widawsky
 2 Benedikt Schemmer
 1 Boris Brezillon
 1 Boyuan Zhang
50 Brian Paul
 1 Bruce Cherniak
19 Chad Versace
 6 Charmaine Lee
 1 Cherniak, Bruce
 1 Chih-Wei Huang
21 Chris Wilson
10 Christian Gmeiner
 1 Christian König
 1 Christoph Berliner
 1 Christoph Haag
 1 Chuck Atkins
12 Connor Abbott
 2 Constantine Charlamov
10 Daniel Stone
 2 Darren Salt
   121 Dave Airlie
 4 David Airlie
 1 Denis Pauk
 1 Derek Foreman
56 Dylan Baker
 1 Eduardo Lima Mitev
 1 Eleni Maria Stea
91 Emil Velikov
   111 Eric Anholt
74 Eric Engestrom
 4 Francisco Jerez
 3 Frank Richter
 1 Fredrik Höglund
 5 George Kyriazis
13 Gert Wollny
 7 Grazvydas Ignotas
 1 Grigori Goronzy
 7 Gurchetan Singh
 1 Gurkirpal Singh
12 Gwan-gyeong Mun
 1 Henri Verbeet
 1 Hongxu Jia
22 Iago Toral Quiroga
20 Ian Romanick
20 Ilia Mirkin
 1 Jakob Bornecrantz
11 Jan Vesely
   170 Jason Ekstrand
 2 Jeremy Huddleston
 1 Jon Turney
 1 Jonas Pfeil
 1 Jordan Justen
 3 José Fonseca
18 Juan A. Suarez Romero
 1 Julien Isorce
 5 Józef Kucia
 1 Kai Chen
 2 Kamil Páral
 3 Karol Herbst
   125 Kenneth Graunke
 2 Kevin Rogovin
 1 Krzysztof Sobiecki
56 Leo Liu
45 Lionel Landwerlin
 2 Louis-Francis Ratté-Boulianne
11 Lucas Stach
   233 Marek Olšák
 1 Mario Kleiner
 1 Mark Janes
 5 Mark Thompson
   103 Matt Turner
 4 Mauro Rossi
 1 Micah Fedke
 1 Michael Olbrich
 1 Michal Srb
 6 Michel Dänzer
 2 Miklós Máté
 2 Neha Bhende
 2 Nicholas Miell
 1 Nicolai Hähnle
 3 Nicolai Hähnle
   270 Nicolai Hähnle
 4 Plamena Manolova
 2 Rafael Antognolli
 1 Ray Strode
 4 Rob Clark
11 Rob Herring
14 Roland Scheidegger
 6 Samuel Iglesias Gonsálvez
   298 Samuel Pitoiset
 3 Scott D Phillips
 1 Stefan Schake
24 Tapani Pälli
 7 Thomas Helland
26 Thomas Hellstrom
60 Tim Rowley
98 Timothy Arceri
 3 Tobias Klausmann
 1 Tomasz Figa
 4 Topi Pohjolainen
 2 Ville Syrjälä
 3 Vinson Lee
12 Wladimir J. van der Laan
 1 Xavier Bouchoux
 1 Yogesh Marathe
 3 Zhongmin Wu
 1 tournier.elie


git tag: mesa-17.3.0-rc1

https://mesa.freedesktop.org/archive/mesa-17.3.0-rc1.tar.gz
MD5:  b9d56f841f6bcdefbbb817ab46748323  mesa-17.3.0-rc1.tar.gz
SHA1: bec1cfa8578bb474f23672a9889a300622ba59df  mesa-17.3.0-rc1.tar.gz
SHA256: e399c7a9af6228334b28eb888ce9050042dfbde05ee6cd0afcf1bb6c546bff4b
mesa-17.3.0-rc1.tar.gz
SHA512: 
0ef8519d6efa0435085fd5102254f5f597fca7d7a3fe5ab51dfe9ee283a915ab965027b40227fc4e49e6d31579ab30d8a796e29ba77af8706f38a86a51a93b51
mesa-17.3.0-rc1.tar.gz
PGP:  https://mesa.freedesktop.org/archive/mesa-17.3.0-rc1.tar.gz.sig

https://mesa.freedesktop.org/archive/mesa-17.3.0-rc1.tar.xz
MD5:  54bc51619a0309b09df190b8d96f4d92  mesa-17.3.0-rc1.tar.xz
SHA1: 5806030c27d9b91613e04b2e8339415422457813  mesa-17.3.0-rc1.tar.xz
SHA256: 290b162e85ad1baa6d8cf59828eeaa6bfd03db122a954dee73cd7a0a87ebd880
mesa-17.3.0-rc1.tar.xz
SHA512: 
573dff68ed757b2787162fd2fdc3bcaca33cf51901d60321066d9e29e014c2ba7398942941e067871311b4e3dd002574fea37b5afd2c9fd58530f69aca32a7cb
mesa-17.3.0-rc1.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-17.3.0-rc1.tar.xz.sig
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] create src/wsi

[Nicolai Hähnle]

On 21.10.2017 03:00, Dylan Baker wrote:

This very short series creates a new src/wsi folder, and moves wayland-drm into
it. Basically wsi stuff is scattered about, and is needed by multiple components
within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan
wayland-wsi.

I think there's more that could be moved into wsi, we could move EGL, GBM, and
GLX, and vulkan/wsi, for example.


The general thrust sounds good to me.

Is there a clean model for what should go into src/wsi and what 
shouldn't? Where's the boundary?


For an example of the type of headaches, does DRI driver code (stuff 
that ends up in xxx_dri.so, for example) count as part of src/wsi? If 
so, then what about gallium/state_trackers/dri? What about 
mesa/drivers/dri/common?


I don't have a full picture of all this code so it's hard for me to say, 
but I really hope your changes will lead to a clearer picture overall :)


Cheers,
Nicolai



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




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/7] radeonsi: reduce the scope of sel->mutex in si_shader_select_with_key

[Nicolai Hähnle]

On 23.10.2017 13:53, Grazvydas Ignotas wrote:

On Sun, Oct 22, 2017 at 9:33 PM, Nicolai Hähnle  wrote:

From: Nicolai Hähnle 

We only need the lock to guard changes in the variant linked list. The
actual compilation can happen outside the lock, since we use the ready
fence as a guard.
---
  src/gallium/drivers/radeonsi/si_state_shaders.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 8c589928b8c..d0bef09748f 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1618,41 +1618,42 @@ current_not_ready:
 if (thread_index < 0)
 util_queue_fence_wait(>ready);

 mtx_lock(>mutex);

 /* Find the shader variant. */
 for (iter = sel->first_variant; iter; iter = iter->next_variant) {
 /* Don't check the "current" shader. We checked it above. */
 if (current != iter &&
 memcmp(>key, key, sizeof(*key)) == 0) {
+   mtx_unlock(>mutex);
+
 if 
(unlikely(!util_queue_fence_is_signalled(>ready))) {
 /* If it's an optimized shader and its 
compilation has
  * been started but isn't done, use the 
unoptimized
  * shader so as not to cause a stall due to 
compilation.
  */
 if (iter->is_optimized) {
 memset(>opt, 0, sizeof(key->opt));
 mtx_unlock(>mutex);


Double unlock


 goto again;
 }

 util_queue_fence_wait(>ready);
 }

 if (iter->compilation_failed) {
 mtx_unlock(>mutex);


here too.


Right on both counts. No idea what happened there :) I'll fix it.

Cheers,
Nicolai




 return -1; /* skip the draw call */
 }

 state->current = iter;
-   mtx_unlock(>mutex);
 return 0;
 }
 }

 /* Build a new shader. */
 shader = CALLOC_STRUCT(si_shader);
 if (!shader) {
 mtx_unlock(>mutex);
 return -ENOMEM;
 }


Gražvydas



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

Re: [Mesa-dev] [PATCH 5/7] u_queue: add a futex-based implementation of fences

[Nicolai Hähnle]

On 23.10.2017 13:50, Grazvydas Ignotas wrote:

On Sun, Oct 22, 2017 at 9:33 PM, Nicolai Hähnle  wrote:

From: Nicolai Hähnle 

Fences are now 4 bytes instead of 96 bytes (on my 64-bit system).

Signaling a fence is a single atomic operation in the fast case plus a
syscall in the slow case.

Testing if a fence is signaled is the same as before (a simple comparison),
but waiting on a fence is now no more expensive than just testing it in
the fast (already signaled) case.
---
  src/util/futex.h   |  4 +++
  src/util/u_queue.c |  2 ++
  src/util/u_queue.h | 88 ++
  3 files changed, 94 insertions(+)

...

diff --git a/src/util/u_queue.h b/src/util/u_queue.h
index a3e12260e30..3d9f19f4e6c 100644
--- a/src/util/u_queue.h
+++ b/src/util/u_queue.h
@@ -28,30 +28,117 @@
   *
   * Jobs can be added from any thread. After that, the wait call can be used
   * to wait for completion of the job.
   */

  #ifndef U_QUEUE_H
  #define U_QUEUE_H

  #include 

+#include "util/futex.h"
  #include "util/list.h"
+#include "util/macros.h"
  #include "util/u_thread.h"

  #ifdef __cplusplus
  extern "C" {
  #endif

  #define UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY  (1 << 0)
  #define UTIL_QUEUE_INIT_RESIZE_IF_FULL(1 << 1)

+#if defined(__GNUC__) && defined(HAVE_FUTEX)
+#define UTIL_QUEUE_FENCE_FUTEX
+#else
+#define UTIL_QUEUE_FENCE_STANDARD
+#endif
+
+#ifdef UTIL_QUEUE_FENCE_FUTEX
+/* Job completion fence.
+ * Put this into your job structure.
+ */
+struct util_queue_fence {
+   /* The fence can be in one of three states:
+*  0 - signaled
+*  1 - unsignaled
+*  2 - unsignaled, may have waiters
+*/
+   uint32_t val;
+};
+
+static inline void
+util_queue_fence_init(struct util_queue_fence *fence)
+{
+   fence->val = 0;
+}
+
+static inline void
+util_queue_fence_destroy(struct util_queue_fence *fence)
+{
+   assert(fence->val == 0);
+   /* no-op */
+}
+
+static inline void
+util_queue_fence_wait(struct util_queue_fence *fence)
+{
+   uint32_t v = fence->val;
+
+   if (likely(v == 0))
+  return;
+
+   do {
+  if (v != 2)
+ v = __sync_val_compare_and_swap(>val, 1, 2);
+
+  futex_wait(>val, 2);
+  v = fence->val;
+   } while(v != 0);
+}
+
+static inline void
+util_queue_fence_signal(struct util_queue_fence *fence)
+{
+   uint32_t val = __sync_lock_test_and_set(>val, 0);


As this is _signal(), don't you need a full barrier here?


You're right. It's a bit surprising that __sync_lock_test_and_set isn't one.



+
+   assert(val != 0);
+
+   if (val == 2)


The documentation says some architectures may only support a constant
of 1 here...


Again, surprising, but you're right.

I believe both of these could be addressed by using 
__sync_val_compare_and_swap instead, right?


Or we could move to new-style gcc atomic built-ins, but I'm not sure 
off-hand how widely available those are.


Thanks,
Nicolai




+  futex_wake_all(>val);
+}


Gražvydas



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

[Mesa-dev] [PATCH] automake: intel: correctly append to the LIBADD variable

[Emil Velikov]

From: Emil Velikov 

Commit 05fc62d89f5 sets the variable, yet it forgot the update the
existing reference to append (instead of assign).

Thus as-is the expat library was discarded from the link chain when
building with Android.

Fixes: 05fc62d89f5 ("automake: intel: move expat handling where it's
used")
Cc: Hongxu Jia 
Signed-off-by: Emil Velikov 
---
 src/intel/Makefile.common.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/Makefile.common.am b/src/intel/Makefile.common.am
index 894dbb5208c..443cefc522a 100644
--- a/src/intel/Makefile.common.am
+++ b/src/intel/Makefile.common.am
@@ -27,5 +27,5 @@ common_libintel_common_la_LIBADD = $(EXPAT_LIBS)
 
 if HAVE_PLATFORM_ANDROID
 common_libintel_common_la_CFLAGS += $(ANDROID_CFLAGS)
-common_libintel_common_la_LIBADD = $(ANDROID_LIBS)
+common_libintel_common_la_LIBADD += $(ANDROID_LIBS)
 endif
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH 3/3] Move src/eg/wayland/wayland-drm into src/wsi

[Daniel Stone]

Hi Dylan,
I'm not 100% sure how autotools deals with cross-directory
dependencies for generated files, but assuming this works, the series
is:
Reviewed-by: Daniel Stone 

Thanks for doing this!

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

Re: [Mesa-dev] [PATCH 7/7] radeonsi: reduce the scope of sel->mutex in si_shader_select_with_key

[Grazvydas Ignotas]

On Sun, Oct 22, 2017 at 9:33 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> We only need the lock to guard changes in the variant linked list. The
> actual compilation can happen outside the lock, since we use the ready
> fence as a guard.
> ---
>  src/gallium/drivers/radeonsi/si_state_shaders.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
> b/src/gallium/drivers/radeonsi/si_state_shaders.c
> index 8c589928b8c..d0bef09748f 100644
> --- a/src/gallium/drivers/radeonsi/si_state_shaders.c
> +++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
> @@ -1618,41 +1618,42 @@ current_not_ready:
> if (thread_index < 0)
> util_queue_fence_wait(>ready);
>
> mtx_lock(>mutex);
>
> /* Find the shader variant. */
> for (iter = sel->first_variant; iter; iter = iter->next_variant) {
> /* Don't check the "current" shader. We checked it above. */
> if (current != iter &&
> memcmp(>key, key, sizeof(*key)) == 0) {
> +   mtx_unlock(>mutex);
> +
> if 
> (unlikely(!util_queue_fence_is_signalled(>ready))) {
> /* If it's an optimized shader and its 
> compilation has
>  * been started but isn't done, use the 
> unoptimized
>  * shader so as not to cause a stall due to 
> compilation.
>  */
> if (iter->is_optimized) {
> memset(>opt, 0, 
> sizeof(key->opt));
> mtx_unlock(>mutex);

Double unlock

> goto again;
> }
>
> util_queue_fence_wait(>ready);
> }
>
> if (iter->compilation_failed) {
> mtx_unlock(>mutex);

here too.

> return -1; /* skip the draw call */
> }
>
> state->current = iter;
> -   mtx_unlock(>mutex);
> return 0;
> }
> }
>
> /* Build a new shader. */
> shader = CALLOC_STRUCT(si_shader);
> if (!shader) {
> mtx_unlock(>mutex);
> return -ENOMEM;
> }

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

Re: [Mesa-dev] [PATCH 5/7] u_queue: add a futex-based implementation of fences

[Grazvydas Ignotas]

On Sun, Oct 22, 2017 at 9:33 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> Fences are now 4 bytes instead of 96 bytes (on my 64-bit system).
>
> Signaling a fence is a single atomic operation in the fast case plus a
> syscall in the slow case.
>
> Testing if a fence is signaled is the same as before (a simple comparison),
> but waiting on a fence is now no more expensive than just testing it in
> the fast (already signaled) case.
> ---
>  src/util/futex.h   |  4 +++
>  src/util/u_queue.c |  2 ++
>  src/util/u_queue.h | 88 
> ++
>  3 files changed, 94 insertions(+)
>
> ...
>
> diff --git a/src/util/u_queue.h b/src/util/u_queue.h
> index a3e12260e30..3d9f19f4e6c 100644
> --- a/src/util/u_queue.h
> +++ b/src/util/u_queue.h
> @@ -28,30 +28,117 @@
>   *
>   * Jobs can be added from any thread. After that, the wait call can be used
>   * to wait for completion of the job.
>   */
>
>  #ifndef U_QUEUE_H
>  #define U_QUEUE_H
>
>  #include 
>
> +#include "util/futex.h"
>  #include "util/list.h"
> +#include "util/macros.h"
>  #include "util/u_thread.h"
>
>  #ifdef __cplusplus
>  extern "C" {
>  #endif
>
>  #define UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY  (1 << 0)
>  #define UTIL_QUEUE_INIT_RESIZE_IF_FULL(1 << 1)
>
> +#if defined(__GNUC__) && defined(HAVE_FUTEX)
> +#define UTIL_QUEUE_FENCE_FUTEX
> +#else
> +#define UTIL_QUEUE_FENCE_STANDARD
> +#endif
> +
> +#ifdef UTIL_QUEUE_FENCE_FUTEX
> +/* Job completion fence.
> + * Put this into your job structure.
> + */
> +struct util_queue_fence {
> +   /* The fence can be in one of three states:
> +*  0 - signaled
> +*  1 - unsignaled
> +*  2 - unsignaled, may have waiters
> +*/
> +   uint32_t val;
> +};
> +
> +static inline void
> +util_queue_fence_init(struct util_queue_fence *fence)
> +{
> +   fence->val = 0;
> +}
> +
> +static inline void
> +util_queue_fence_destroy(struct util_queue_fence *fence)
> +{
> +   assert(fence->val == 0);
> +   /* no-op */
> +}
> +
> +static inline void
> +util_queue_fence_wait(struct util_queue_fence *fence)
> +{
> +   uint32_t v = fence->val;
> +
> +   if (likely(v == 0))
> +  return;
> +
> +   do {
> +  if (v != 2)
> + v = __sync_val_compare_and_swap(>val, 1, 2);
> +
> +  futex_wait(>val, 2);
> +  v = fence->val;
> +   } while(v != 0);
> +}
> +
> +static inline void
> +util_queue_fence_signal(struct util_queue_fence *fence)
> +{
> +   uint32_t val = __sync_lock_test_and_set(>val, 0);

As this is _signal(), don't you need a full barrier here?

> +
> +   assert(val != 0);
> +
> +   if (val == 2)

The documentation says some architectures may only support a constant
of 1 here...

> +  futex_wake_all(>val);
> +}

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

Re: [Mesa-dev] [PATCH 03/25] threads: update for late C11 changes

[Nicolai Hähnle]

On 23.10.2017 13:15, Emil Velikov wrote:

Hi Nicolai,

On 22 October 2017 at 20:07, Nicolai Hähnle  wrote:

From: Nicolai Hähnle 

C11 threads were changed to use struct timespec instead of xtime, and
thrd_sleep got a second argument.


As xtime was replaced with timespec there's a couple of odd bits in the code.



See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1554.htm and
http://en.cppreference.com/w/c/thread/{thrd_sleep,cnd_timedwait,mtx_timedlock}

Note that cnd_timedwait is spec'd to be relative to TIME_UTC / CLOCK_REALTIME.

Cc: Jose Fonseca 
---
  include/c11/threads.h   | 11 ---
  include/c11/threads_posix.h | 39 +++
  include/c11/threads_win32.h | 37 +++--
  src/egl/drivers/dri2/egl_dri2.c | 24 +---
  4 files changed, 47 insertions(+), 64 deletions(-)

diff --git a/include/c11/threads.h b/include/c11/threads.h
index 573348d8091..3c3f23a8ab8 100644
--- a/include/c11/threads.h
+++ b/include/c11/threads.h
@@ -23,42 +23,31 @@
   * FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
   * SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
   * FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
   * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
   * DEALINGS IN THE SOFTWARE.
   */
  #ifndef EMULATED_THREADS_H_INCLUDED_
  #define EMULATED_THREADS_H_INCLUDED_

  #include 
-#ifdef _MSC_VER
-#include   // for xtime
-#endif

  #ifndef TIME_UTC
  #define TIME_UTC 1
  #endif

  #include "c99_compat.h" /* for `inline` */

  /* types */
  typedef void (*tss_dtor_t)(void*);
  typedef int (*thrd_start_t)(void*);

-#ifndef _MSC_VER
-struct xtime {
-time_t sec;
-long nsec;
-};
-typedef struct xtime xtime;
-#endif
-


We don't have a fall-back declaration of the struct, yet we use it
below and provide a timespec_get() implementation.
I'd imagine you haven't tested this on Windows (hence Jose in CC)?


Right on both counts, as I don't really have a way of testing on Windows.



Quick search suggests that MSVC 2015 was the first one that introduces
the struct and timespec_get.

If we're safe as-is, please add a comment with some details - I'd
imagine Jose had better knowledge in the area.



  /* 7.25.7 Time functions */
  // 7.25.6.1
+#if 0

I'd just drop the hunk mentioning that timespec_get() is part of time.h


I wasn't sure when timespec_get was introduced, so I thought it safer to 
keep it around for a while in case we run into systems where time.h 
doesn't provide it.


I can add a comment, or remove it entirely if you think that's not a 
concern.


Cheers,
Nicolai




Thank
Emil




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 03/25] threads: update for late C11 changes

[Emil Velikov]

Hi Nicolai,

On 22 October 2017 at 20:07, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> C11 threads were changed to use struct timespec instead of xtime, and
> thrd_sleep got a second argument.
>
As xtime was replaced with timespec there's a couple of odd bits in the code.


> See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1554.htm and
> http://en.cppreference.com/w/c/thread/{thrd_sleep,cnd_timedwait,mtx_timedlock}
>
> Note that cnd_timedwait is spec'd to be relative to TIME_UTC / CLOCK_REALTIME.
>
> Cc: Jose Fonseca 
> ---
>  include/c11/threads.h   | 11 ---
>  include/c11/threads_posix.h | 39 +++
>  include/c11/threads_win32.h | 37 +++--
>  src/egl/drivers/dri2/egl_dri2.c | 24 +---
>  4 files changed, 47 insertions(+), 64 deletions(-)
>
> diff --git a/include/c11/threads.h b/include/c11/threads.h
> index 573348d8091..3c3f23a8ab8 100644
> --- a/include/c11/threads.h
> +++ b/include/c11/threads.h
> @@ -23,42 +23,31 @@
>   * FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
>   * SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
>   * FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR 
> OTHERWISE,
>   * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR 
> OTHER
>   * DEALINGS IN THE SOFTWARE.
>   */
>  #ifndef EMULATED_THREADS_H_INCLUDED_
>  #define EMULATED_THREADS_H_INCLUDED_
>
>  #include 
> -#ifdef _MSC_VER
> -#include   // for xtime
> -#endif
>
>  #ifndef TIME_UTC
>  #define TIME_UTC 1
>  #endif
>
>  #include "c99_compat.h" /* for `inline` */
>
>  /* types */
>  typedef void (*tss_dtor_t)(void*);
>  typedef int (*thrd_start_t)(void*);
>
> -#ifndef _MSC_VER
> -struct xtime {
> -time_t sec;
> -long nsec;
> -};
> -typedef struct xtime xtime;
> -#endif
> -

We don't have a fall-back declaration of the struct, yet we use it
below and provide a timespec_get() implementation.
I'd imagine you haven't tested this on Windows (hence Jose in CC)?

Quick search suggests that MSVC 2015 was the first one that introduces
the struct and timespec_get.

If we're safe as-is, please add a comment with some details - I'd
imagine Jose had better knowledge in the area.


>  /* 7.25.7 Time functions */
>  // 7.25.6.1
> +#if 0
I'd just drop the hunk mentioning that timespec_get() is part of time.h


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

[Mesa-dev] [PATCH v3] egl/wayland: Support for KHR_partial_update

[Harish Krupo]

This passes 33/37 deqp tests related to partial_update, 4 are not
supported. Tests not supported:
dEQP-EGL.functional.negative_partial_update.not_postable_surface
dEQP-EGL.functional.negative_partial_update.not_current_surface
dEQP-EGL.functional.negative_partial_update.buffer_preserved
dEQP-EGL.functional.negative_partial_update.not_current_surface2
Reason: No matching egl config found.

v2: Remove unnecessary return statement. Keep function names
consistent.  (Emil Velikov)
Add not supported list to commit message. (Eric Engestrom)

v3: Remove explicit with_damage variable. (Eric Engestrom)

Signed-off-by: Harish Krupo 
---
 src/egl/drivers/dri2/platform_wayland.c | 54 ++---
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index b38eb1c335..8846099d57 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -790,27 +790,44 @@ create_wl_buffer(struct dri2_egl_display *dri2_dpy,
return ret;
 }
 
+/**
+ * Called via eglSetDamageRegionKHR(), drv->API.SetDamageRegion().
+ */
 static EGLBoolean
-try_damage_buffer(struct dri2_egl_surface *dri2_surf,
-  const EGLint *rects,
-  EGLint n_rects)
+dri2_wl_set_damage_region(_EGLDriver *drv,
+ _EGLDisplay *dpy,
+ _EGLSurface *surf,
+ const EGLint *rects,
+ EGLint n_rects)
 {
-   if (wl_proxy_get_version((struct wl_proxy *) dri2_surf->wl_surface_wrapper)
-   < WL_SURFACE_DAMAGE_BUFFER_SINCE_VERSION)
-  return EGL_FALSE;
+   struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surf);
 
-   for (int i = 0; i < n_rects; i++) {
-  const int *rect = [i * 4];
+   /* The spec doesn't mention what should be returned in case of
+* failure in setting the damage buffer with the window system, so
+* setting the damage to maximum surface area
+*/
+   if (!n_rects ||
+   wl_proxy_get_version((struct wl_proxy *) dri2_surf->wl_surface_wrapper)
+   < WL_SURFACE_DAMAGE_BUFFER_SINCE_VERSION) {
+  wl_surface_damage(dri2_surf->wl_surface_wrapper,
+0, 0, INT32_MAX, INT32_MAX);
+   } else {
+  for (int i = 0; i < n_rects; i++) {
+ const int *rect = [i * 4];
 
-  wl_surface_damage_buffer(dri2_surf->wl_surface_wrapper,
-   rect[0],
-   dri2_surf->base.Height - rect[1] - rect[3],
-   rect[2], rect[3]);
+ wl_surface_damage_buffer(dri2_surf->wl_surface_wrapper,
+  rect[0],
+  dri2_surf->base.Height - rect[1] - rect[3],
+  rect[2], rect[3]);
+  }
}
+
return EGL_TRUE;
 }
+
 /**
- * Called via eglSwapBuffers(), drv->API.SwapBuffers().
+ * Called via eglSwapBuffersWithDamage{KHR,EXT}(),
+ * drv->API.SwapBuffersWithDamageEXT().
  */
 static EGLBoolean
 dri2_wl_swap_buffers_with_damage(_EGLDriver *drv,
@@ -875,9 +892,8 @@ dri2_wl_swap_buffers_with_damage(_EGLDriver *drv,
/* If the compositor doesn't support damage_buffer, we deliberately
 * ignore the damage region and post maximum damage, due to
 * https://bugs.freedesktop.org/78190 */
-   if (!n_rects || !try_damage_buffer(dri2_surf, rects, n_rects))
-  wl_surface_damage(dri2_surf->wl_surface_wrapper,
-0, 0, INT32_MAX, INT32_MAX);
+   if (n_rects || !dri2_surf->base.SetDamageRegionCalled)
+  dri2_wl_set_damage_region(drv, disp, draw, rects, n_rects);
 
if (dri2_dpy->is_different_gpu) {
   _EGLContext *ctx = _eglGetCurrentContext();
@@ -928,7 +944,8 @@ dri2_wl_query_buffer_age(_EGLDriver *drv,
 static EGLBoolean
 dri2_wl_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *draw)
 {
-   return dri2_wl_swap_buffers_with_damage(drv, disp, draw, NULL, 0);
+   return dri2_wl_swap_buffers_with_damage(drv, disp, draw,
+  NULL, 0);
 }
 
 static struct wl_buffer *
@@ -1166,7 +1183,7 @@ static const struct dri2_egl_display_vtbl 
dri2_wl_display_vtbl = {
.swap_buffers = dri2_wl_swap_buffers,
.swap_buffers_with_damage = dri2_wl_swap_buffers_with_damage,
.swap_buffers_region = dri2_fallback_swap_buffers_region,
-   .set_damage_region = dri2_fallback_set_damage_region,
+   .set_damage_region = dri2_wl_set_damage_region,
.post_sub_buffer = dri2_fallback_post_sub_buffer,
.copy_buffers = dri2_fallback_copy_buffers,
.query_buffer_age = dri2_wl_query_buffer_age,
@@ -1378,6 +1395,7 @@ dri2_initialize_wayland_drm(_EGLDriver *drv, _EGLDisplay 
*disp)
disp->Extensions.EXT_buffer_age = EGL_TRUE;
 
disp->Extensions.EXT_swap_buffers_with_damage = EGL_TRUE;
+   disp->Extensions.KHR_partial_update = EGL_TRUE;
 
/* Fill vtbl last to prevent accidentally 

[Mesa-dev] [Bug 100202] llvmpipe Windows scons build can't detect Visual Studio 2017 toolchain

[bugzilla-daemon]

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

Alex Granni  changed:

   What|Removed |Added

 Resolution|NOTOURBUG   |FIXED

--- Comment #4 from Alex Granni  ---
Mesa 17.2.3 supports Scons 3.0.0 which in turn supports Visual Studio 2017.
This marks this bug as fixed.

-- 
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 v2 00/32] i965 disk shader cache

[Emil Velikov]

On 21 October 2017 at 00:28, Jason Ekstrand  wrote:
> Over-all, I'm very happy with the way this turned out.  Good work to all
> involved!  I made a few comments here and there and a pile on patch 18.
> That said, I think they should all be fairly easy to resolve and, should
> Emil be willing to hold off on branching for a couple of days, think this
> should be good to land.  With all of the refactors and changes that have
> happened (particularly about params arrays and NIR serialization), I have a
> high level of confidence that we're probably getting it right.  Obviously,
> user testing will be needed, but I think it's all solid in concept.  Let's
> do this!
>
I fear that this request is tad late.

As seen already I'm happy to hear when people plans on feature X.
This was the case with Andres Rodriguez, Christian Gmeiner this
release and Kenneth with earlier one.

Important difference is that those where made ahead of the planned branchpoint.

To help awareness, we have the preliminary schedule available month+
in advance on mesa3d.org.
There are also reminders on mesa-dev/mesa-announce as we get closer to the date.

I realise it may be uneasy reading this but please try to give timely heads-up.

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

Re: [Mesa-dev] [PATCH v2] glsl: fix derived cs variables

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

On 10/22/2017 11:37 PM, Ilia Mirkin wrote:

There are two issues with the current implementation. First, it relies
on the layout(local_size_*) happening in the same shader as the main
function, and secondly it doesn't work for variable group sizes.

In both cases, the simplest fix is to move the setup of these derived
values to a later time, similar to how the gl_VertexID workarounds are
done. There already exist system values defined for both of the derived
values, so we use them unconditionally, and lower them after linking is
performed.

While we're at it, we move to using gl_LocalGroupSizeARB instead of
gl_WorkGroupSize for variable group sizes.

Also the dead code elimination avoidance can be removed, since there
can be situations where gl_LocalGroupSizeARB is needed but has not been
inserted for the shader with main function. As a result, the lowering
code has to insert its own copies of the system values if needed.

Reported-by: Stephane Chevigny 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103393
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Ilia Mirkin 
---

Well this all turned out to be a deeper rabbit-hole than I was anticipating.
I'm going to write up some piglit tests for these cases as they are fairly
subtle, and unlikely to occur in practice.

I figured it was easier to just re-add the system values instead of having
the dead code not-remove them, since gl_LocalGroupSizeARB might not be in
the shader with the main function (it's only added if the variable size ext
is enabled, which it might only be in a second shader which sets the
local_size_*). So we'd have to have it anyways, might as well do it for all.

  src/compiler/Makefile.sources|   1 +
  src/compiler/glsl/builtin_variables.cpp  |  94 +
  src/compiler/glsl/glsl_parser_extras.cpp |   2 -
  src/compiler/glsl/ir.h   |   4 -
  src/compiler/glsl/ir_optimization.h  |   1 +
  src/compiler/glsl/linker.cpp |   3 +
  src/compiler/glsl/lower_cs_derived.cpp   | 234 +++
  src/compiler/glsl/meson.build|   1 +
  src/compiler/glsl/opt_dead_builtin_variables.cpp |  22 ---
  9 files changed, 244 insertions(+), 118 deletions(-)
  create mode 100644 src/compiler/glsl/lower_cs_derived.cpp

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 2724a41286e..27cc33ab835 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -85,6 +85,7 @@ LIBGLSL_FILES = \
glsl/lower_buffer_access.cpp \
glsl/lower_buffer_access.h \
glsl/lower_const_arrays_to_uniforms.cpp \
+   glsl/lower_cs_derived.cpp \
glsl/lower_discard.cpp \
glsl/lower_discard_flow.cpp \
glsl/lower_distance.cpp \
diff --git a/src/compiler/glsl/builtin_variables.cpp 
b/src/compiler/glsl/builtin_variables.cpp
index ea2d897cc8e..00bc99dd619 100644
--- a/src/compiler/glsl/builtin_variables.cpp
+++ b/src/compiler/glsl/builtin_variables.cpp
@@ -1295,15 +1295,10 @@ builtin_variable_generator::generate_cs_special_vars()
 uvec3_t, "gl_LocalGroupSizeARB");
 }
  
-   if (state->ctx->Const.LowerCsDerivedVariables) {

-  add_variable("gl_GlobalInvocationID", uvec3_t, ir_var_auto, 0);
-  add_variable("gl_LocalInvocationIndex", uint_t, ir_var_auto, 0);
-   } else {
-  add_system_value(SYSTEM_VALUE_GLOBAL_INVOCATION_ID,
-   uvec3_t, "gl_GlobalInvocationID");
-  add_system_value(SYSTEM_VALUE_LOCAL_INVOCATION_INDEX,
-   uint_t, "gl_LocalInvocationIndex");
-   }
+   add_system_value(SYSTEM_VALUE_GLOBAL_INVOCATION_ID,
+uvec3_t, "gl_GlobalInvocationID");
+   add_system_value(SYSTEM_VALUE_LOCAL_INVOCATION_INDEX,
+uint_t, "gl_LocalInvocationIndex");
  }
  
  
@@ -1474,84 +1469,3 @@ _mesa_glsl_initialize_variables(exec_list *instructions,

break;
 }
  }
-
-
-/**
- * Initialize compute shader variables with values that are derived from other
- * compute shader variable.
- */
-static void
-initialize_cs_derived_variables(gl_shader *shader,
-ir_function_signature *const main_sig)
-{
-   assert(shader->Stage == MESA_SHADER_COMPUTE);
-
-   ir_variable *gl_GlobalInvocationID =
-  shader->symbols->get_variable("gl_GlobalInvocationID");
-   assert(gl_GlobalInvocationID);
-   ir_variable *gl_WorkGroupID =
-  shader->symbols->get_variable("gl_WorkGroupID");
-   assert(gl_WorkGroupID);
-   ir_variable *gl_WorkGroupSize =
-  shader->symbols->get_variable("gl_WorkGroupSize");
-   if (gl_WorkGroupSize == NULL) {
-  void *const mem_ctx = ralloc_parent(shader->ir);
-  gl_WorkGroupSize = new(mem_ctx) ir_variable(glsl_type::uvec3_type,
- 

Re: [Mesa-dev] [PATCH 0/7] u_queue fence patches and a radeonsi fix

[Nicolai Hähnle]

On 23.10.2017 11:29, Samuel Pitoiset wrote:

Is there a branch somewhere that can be pulled? Thanks


I just pushed 
https://cgit.freedesktop.org/~nh/mesa/log/?h=fences-threads-ddebug, 
which contains all the patches I sent out yesterday in sequence.


Cheers,
Nicolai



On 10/22/2017 08:33 PM, Nicolai Hähnle wrote:

Hi all,

Another multi-threading bug I ran into, this time with radeonsi shader
fences.

Patches 1-5 make util_queue_fence more widely usable, and include an
optional futex-based implementation. The patches themselves are on top
of the simple-mutex patches, but could easily be removed to drop the
futex stuff (though the memory improvements are a pretty strong
argument).

Please review!
Thanks,
Nicolai
--
  src/gallium/drivers/radeonsi/si_shader.c |   3 +
  src/gallium/drivers/radeonsi/si_shader.h |   2 +-
  .../drivers/radeonsi/si_state_shaders.c  |  94 +
  src/util/Makefile.sources    |   1 +
  src/util/futex.h |  55 
  src/util/meson.build |   1 +
  src/util/simple_mtx.h    |  20 +--
  src/util/u_queue.c   |   8 +-
  src/util/u_queue.h   | 121 +++--
  9 files changed, 245 insertions(+), 60 deletions(-)

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




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103412] gallium/wgl: Another fix to context creation without prior SetPixelFormat()

[bugzilla-daemon]

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

Bug ID: 103412
   Summary: gallium/wgl: Another fix to context creation without
prior SetPixelFormat()
   Product: Mesa
   Version: 17.2
  Hardware: Other
OS: Windows (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: frank.rich...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 135000
  --> https://bugs.freedesktop.org/attachment.cgi?id=135000=edit
patch: Don't blindly use GetPixelFormat() return value

This is a follow-up to bug 101326.

The patch for that bug blindly took the pixel format index returned by
GetPixelFormat(). However, what's the guarantee that this pixel format index is
actually sensible in the Mesa context, or even a valid index?

Well, none actually. (It's also not an entirely theoretic problem. I received a
crash report where an invalid index is indicated, though I couldn't reproduce
the exact scenario.)

The attached patch fixes the blind usage of the index by computing the proper
Mesa pixel format index from the pixel format description.

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

[Mesa-dev] [PATCH] radv: Update code pointer correctly if a variant is already created

[Alex Smith]

This was the actual cause of GPU hangs fixed by 0fdd531457ec ("radv:
Fix pipeline cache locking issues"), since multiple threads would end
up trying to create the variants for a single entry.

Now that we're locking around the whole of this function, this isn't
really necessary (we either create all or none of the variants), but
fix this anyway in case things change later.

Signed-off-by: Alex Smith 
---
 src/amd/vulkan/radv_pipeline_cache.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/amd/vulkan/radv_pipeline_cache.c 
b/src/amd/vulkan/radv_pipeline_cache.c
index a75356b822..9ba9a3b61b 100644
--- a/src/amd/vulkan/radv_pipeline_cache.c
+++ b/src/amd/vulkan/radv_pipeline_cache.c
@@ -231,6 +231,8 @@ radv_create_shader_variants_from_pipeline_cache(struct 
radv_device *device,
p += entry->code_sizes[i];
 
entry->variants[i] = variant;
+   } else if (entry->code_sizes[i]) {
+   p += sizeof(struct cache_entry_variant_info) + 
entry->code_sizes[i];
}
 
}
-- 
2.13.6

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

Re: [Mesa-dev] [PATCH 0/7] u_queue fence patches and a radeonsi fix

[Samuel Pitoiset]

Is there a branch somewhere that can be pulled? Thanks

On 10/22/2017 08:33 PM, Nicolai Hähnle wrote:

Hi all,

Another multi-threading bug I ran into, this time with radeonsi shader
fences.

Patches 1-5 make util_queue_fence more widely usable, and include an
optional futex-based implementation. The patches themselves are on top
of the simple-mutex patches, but could easily be removed to drop the
futex stuff (though the memory improvements are a pretty strong
argument).

Please review!
Thanks,
Nicolai
--
  src/gallium/drivers/radeonsi/si_shader.c |   3 +
  src/gallium/drivers/radeonsi/si_shader.h |   2 +-
  .../drivers/radeonsi/si_state_shaders.c  |  94 +
  src/util/Makefile.sources|   1 +
  src/util/futex.h |  55 
  src/util/meson.build |   1 +
  src/util/simple_mtx.h|  20 +--
  src/util/u_queue.c   |   8 +-
  src/util/u_queue.h   | 121 +++--
  9 files changed, 245 insertions(+), 60 deletions(-)

___
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] radv: Fix pipeline cache locking issues

[Alex Smith]

On 21 October 2017 at 02:54, Bas Nieuwenhuizen 
wrote:

> For radv_create_shader_variants_from_pipeline_cache I'm not really
> sure why this would cause corruption. Yes we might create the variants
> a few times too much, but that should not cause any corruption.
>

Just had another look and figured out what the actual problem is - if
there's a race between multiple threads to create the variants for a single
entry, then they may not update p inside the loop properly (since they only
do so when the variant isn't already created), so can end up using the
wrong code. I'll send a patch - I don't think it's necessary now that we're
locking around there (we'll only create all or none of the variants), but
may as well fix it in case things change later.

Alex


>
> Either way, it is a fix, so
> Reviewed-by: Bas Nieuwenhuizen 
>
> and pushed. Thanks.
>
> On Thu, Oct 19, 2017 at 12:49 PM, Alex Smith
>  wrote:
> > Need to lock around the whole process of retrieving cached shaders, and
> > around GetPipelineCacheData.
> >
> > This fixes GPU hangs observed when creating multiple pipelines in
> > parallel, which appeared to be due to invalid shader code being pulled
> > from the cache.
> >
> > Signed-off-by: Alex Smith 
> > ---
> >  src/amd/vulkan/radv_pipeline_cache.c | 30
> +++---
> >  1 file changed, 23 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_pipeline_cache.c b/src/amd/vulkan/radv_
> pipeline_cache.c
> > index 034dc35af8..a75356b822 100644
> > --- a/src/amd/vulkan/radv_pipeline_cache.c
> > +++ b/src/amd/vulkan/radv_pipeline_cache.c
> > @@ -177,15 +177,20 @@ radv_create_shader_variants_from_pipeline_cache(struct
> radv_device *device,
> > struct
> radv_shader_variant **variants)
> >  {
> > struct cache_entry *entry;
> > -   if (cache)
> > -   entry = radv_pipeline_cache_search(cache, sha1);
> > -   else
> > -   entry = radv_pipeline_cache_search(device->mem_cache,
> sha1);
> > +
> > +   if (!cache)
> > +   cache = device->mem_cache;
> > +
> > +   pthread_mutex_lock(>mutex);
> > +
> > +   entry = radv_pipeline_cache_search_unlocked(cache, sha1);
> >
> > if (!entry) {
> > if (!device->physical_device->disk_cache ||
> > -   (device->instance->debug_flags &
> RADV_DEBUG_NO_CACHE))
> > +   (device->instance->debug_flags &
> RADV_DEBUG_NO_CACHE)) {
> > +   pthread_mutex_unlock(>mutex);
> > return false;
> > +   }
> >
> > uint8_t disk_sha1[20];
> > disk_cache_compute_key(device-
> >physical_device->disk_cache,
> > @@ -193,8 +198,10 @@ radv_create_shader_variants_from_pipeline_cache(struct
> radv_device *device,
> > entry = (struct cache_entry *)
> > disk_cache_get(device->
> physical_device->disk_cache,
> >disk_sha1, NULL);
> > -   if (!entry)
> > +   if (!entry) {
> > +   pthread_mutex_unlock(>mutex);
> > return false;
> > +   }
> > }
> >
> > char *p = entry->code;
> > @@ -204,8 +211,10 @@ radv_create_shader_variants_from_pipeline_cache(struct
> radv_device *device,
> > struct cache_entry_variant_info info;
> >
> > variant = calloc(1, sizeof(struct
> radv_shader_variant));
> > -   if (!variant)
> > +   if (!variant) {
> > +   pthread_mutex_unlock(>mutex);
> > return false;
> > +   }
> >
> > memcpy(, p, sizeof(struct
> cache_entry_variant_info));
> > p += sizeof(struct cache_entry_variant_info);
> > @@ -231,6 +240,7 @@ radv_create_shader_variants_from_pipeline_cache(struct
> radv_device *device,
> > p_atomic_inc(>variants[i]->ref_count);
> >
> > memcpy(variants, entry->variants, sizeof(entry->variants));
> > +   pthread_mutex_unlock(>mutex);
> > return true;
> >  }
> >
> > @@ -509,12 +519,17 @@ VkResult radv_GetPipelineCacheData(
> > RADV_FROM_HANDLE(radv_pipeline_cache, cache, _cache);
> > struct cache_header *header;
> > VkResult result = VK_SUCCESS;
> > +
> > +   pthread_mutex_lock(>mutex);
> > +
> > const size_t size = sizeof(*header) + cache->total_size;
> > if (pData == NULL) {
> > +   pthread_mutex_unlock(>mutex);
> > *pDataSize = size;
> > return VK_SUCCESS;
> > }
> > if (*pDataSize < sizeof(*header)) {
> > +   pthread_mutex_unlock(>mutex);
> > 

Re: [Mesa-dev] [PATCH] mesa/bufferobj: don't double negate the range

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

On 10/23/2017 02:38 AM, Dave Airlie wrote:

From: Dave Airlie 

This fixes a regression I introduced refactoring this code,
I managed to invert range twice, I moved the inversion into
the common code, but forgot to stop doing it in the callee.

Fixes: GL45-CTS.multi_bind.dispatch_bind_buffers_base

Fixes: 35ac13ed3 (mesa/bufferobj: consolidate some codepaths between 
ubo/ssbo/atomics.)
Reported-by: Nicolai Hähnle 
Signed-off-by: Dave Airlie 
---
  src/mesa/main/bufferobj.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index b7a9692..dfeea94 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -3815,7 +3815,7 @@ bind_uniform_buffers(struct gl_context *ctx, GLuint 
first, GLsizei count,
}
  
set_buffer_multi_binding(ctx, buffers, i, caller,

-   binding, offset, size, !range,
+   binding, offset, size, range,
 USAGE_UNIFORM_BUFFER);
 }
  
@@ -3916,7 +3916,7 @@ bind_shader_storage_buffers(struct gl_context *ctx, GLuint first,

}
  
set_buffer_multi_binding(ctx, buffers, i, caller,

-   binding, offset, size, !range,
+   binding, offset, size, range,
 USAGE_SHADER_STORAGE_BUFFER);
 }
  
@@ -4238,7 +4238,7 @@ bind_atomic_buffers(struct gl_context *ctx,

}
  
set_buffer_multi_binding(ctx, buffers, i, caller,

-   binding, offset, size, !range,
+   binding, offset, size, range,
 USAGE_ATOMIC_COUNTER_BUFFER);
 }
  


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

Re: [Mesa-dev] [PATCH 1/8] mesa: handle OES_texture_half_float formats in _mesa_base_tex_format()

[Tapani Pälli]

Maybe combine common items with ARB_texture_float check below? You could 
introduce something like:


if (ctx->Extensions.ARB_texture_float || 
ctx->Extensions.OES_texture_half_float) {

...
}

if (ctx->Extensions.ARB_texture_float || 
ctx->Extensions.OES_texture_float) {

...
}


On 10/20/2017 11:21 PM, Christian Gmeiner wrote:

Signed-off-by: Christian Gmeiner 
---
  src/mesa/main/glformats.c | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 1e797c24c2..78299aebae 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -2424,6 +2424,25 @@ _mesa_base_tex_format(const struct gl_context *ctx, 
GLint internalFormat)
   return GL_YCBCR_MESA;
 }
  
+   if (ctx->Extensions.OES_texture_half_float) {

+   switch (internalFormat) {
+   case GL_ALPHA16F_ARB:
+  return GL_ALPHA;
+   case GL_RGBA16F_ARB:
+  return GL_RGBA;
+   case GL_RGB16F_ARB:
+  return GL_RGB;
+   case GL_INTENSITY16F_ARB:
+  return GL_INTENSITY;
+   case GL_LUMINANCE16F_ARB:
+  return GL_LUMINANCE;
+   case GL_LUMINANCE_ALPHA16F_ARB:
+  return GL_LUMINANCE_ALPHA;
+   default:
+  ; /* fallthrough */
+   }
+   }
+
 if (ctx->Extensions.ARB_texture_float) {
switch (internalFormat) {
case GL_ALPHA16F_ARB:


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