Re: [Mesa-dev] [PATCH 3/9] u_dynarray: add util_dynarray_enlarge
On Sat, Mar 16, 2019 at 09:28:48AM +0800, Qiang Yu wrote:
> This is for the case that user only know a max size
> it wants to append to the array and enlarge the array
> capacity before writing into it.
>
> Signed-off-by: Qiang Yu
> ---
> src/util/u_dynarray.h | 19 +++
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/src/util/u_dynarray.h b/src/util/u_dynarray.h
> index 9bed2b9c25c..c5217082b7f 100644
> --- a/src/util/u_dynarray.h
> +++ b/src/util/u_dynarray.h
> @@ -77,11 +77,9 @@ util_dynarray_clear(struct util_dynarray *buf)
>
> #define DYN_ARRAY_INITIAL_SIZE 64
>
> -/* use util_dynarray_trim to reduce the allocated storage */
> static inline void *
> -util_dynarray_resize(struct util_dynarray *buf, unsigned newsize)
> +util_dynarray_ensure_cap(struct util_dynarray *buf, unsigned newsize)
Rename the parameter to newcap to avoid confusion in the body.
> {
> - void *p;
> if (newsize > buf->capacity) {
>if (buf->capacity == 0)
> buf->capacity = DYN_ARRAY_INITIAL_SIZE;
> @@ -96,7 +94,20 @@ util_dynarray_resize(struct util_dynarray *buf, unsigned
> newsize)
>}
> }
>
> - p = (void *)((char *)buf->data + buf->size);
> + return (void *)((char *)buf->data + buf->size);
> +}
> +
> +static inline void *
> +util_dynarray_enlarge(struct util_dynarray *buf, int diff)
> +{
> + return util_dynarray_ensure_cap(buf, buf->size + diff);
> +}
We already have util_dynarray_grow for size, so enlarge can be
confusing. What do you think about calling this one
util_dynarray_grow_cap?
> +
> +/* use util_dynarray_trim to reduce the allocated storage */
> +static inline void *
> +util_dynarray_resize(struct util_dynarray *buf, unsigned newsize)
> +{
> + void *p = util_dynarray_ensure_cap(buf, newsize);
> buf->size = newsize;
>
> return p;
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Caio
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/9] gallium/u_math: add ushort_to_float/float_to_ushort
Am 16.03.19 um 02:28 schrieb Qiang Yu:
> Signed-off-by: Qiang Yu
> ---
> src/util/u_math.h | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/src/util/u_math.h b/src/util/u_math.h
> index e7dbbe5ca22..ffadfb47282 100644
> --- a/src/util/u_math.h
> +++ b/src/util/u_math.h
> @@ -389,6 +389,37 @@ float_to_ubyte(float f)
> }
> }
>
> +/**
> + * Convert ushort to float in [0, 1].
> + */
> +static inline float
> +ushort_to_float(ushort us)
> +{
> + return (float) us * (1.0f / 65535.0f);
> +}
> +
> +
> +/**
> + * Convert float in [0,1] to ushort in [0,65535] with clamping.
> + */
> +static inline ushort
> +float_to_ushort(float f)
> +{
> + union fi tmp;
> +
> + tmp.f = f;
> + if (tmp.i < 0) {
> + return (ushort) 0;
> + }
> + else if (tmp.i >= 0x3f80 /* 1.0f */) {
> + return (ushort) 65535;
> + }
This will convert NaNs to either 0 or 65535, depending on their sign.
I think generally it's better to convert this consistently to 0 (gl
usually doesn't require this, however d3d10 does).
Roland
> + else {
> + tmp.f = tmp.f * (65535.0f/65536.0f) + 128.0f;
> + return (ushort) tmp.i;
> + }
> +}
> +
> static inline float
> byte_to_float_tex(int8_t b)
> {
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/9] nir: add load uniform lower to scalar
This is needed for lima gp compiler.
Signed-off-by: Qiang Yu
---
src/compiler/nir/nir_intrinsics.py| 4 +--
src/compiler/nir/nir_lower_io.c | 2 +-
src/compiler/nir/nir_lower_io_to_scalar.c | 41 +--
3 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/src/compiler/nir/nir_intrinsics.py
b/src/compiler/nir/nir_intrinsics.py
index a6c74dc2543..5aea515258f 100644
--- a/src/compiler/nir/nir_intrinsics.py
+++ b/src/compiler/nir/nir_intrinsics.py
@@ -603,8 +603,8 @@ def load(name, num_srcs, indices=[], flags=[]):
intrinsic("load_" + name, [1] * num_srcs, dest_comp=0, indices=indices,
flags=flags)
-# src[] = { offset }. const_index[] = { base, range }
-load("uniform", 1, [BASE, RANGE], [CAN_ELIMINATE, CAN_REORDER])
+# src[] = { offset }. const_index[] = { base, range, component }
+load("uniform", 1, [BASE, RANGE, COMPONENT], [CAN_ELIMINATE, CAN_REORDER])
# src[] = { buffer_index, offset }. const_index[] = { align_mul, align_offset }
load("ubo", 2, [ALIGN_MUL, ALIGN_OFFSET], flags=[CAN_ELIMINATE, CAN_REORDER])
# src[] = { offset }. const_index[] = { base, component }
diff --git a/src/compiler/nir/nir_lower_io.c b/src/compiler/nir/nir_lower_io.c
index d1f95cfe6ac..058151c915e 100644
--- a/src/compiler/nir/nir_lower_io.c
+++ b/src/compiler/nir/nir_lower_io.c
@@ -251,7 +251,7 @@ lower_load(nir_intrinsic_instr *intrin, struct
lower_io_state *state,
load->num_components = intrin->num_components;
nir_intrinsic_set_base(load, var->data.driver_location);
- if (mode == nir_var_shader_in || mode == nir_var_shader_out)
+ if (mode == nir_var_shader_in || mode == nir_var_shader_out || mode ==
nir_var_uniform)
nir_intrinsic_set_component(load, component);
if (load->intrinsic == nir_intrinsic_load_uniform)
diff --git a/src/compiler/nir/nir_lower_io_to_scalar.c
b/src/compiler/nir/nir_lower_io_to_scalar.c
index 559d80b214a..1f0990d5dc5 100644
--- a/src/compiler/nir/nir_lower_io_to_scalar.c
+++ b/src/compiler/nir/nir_lower_io_to_scalar.c
@@ -27,8 +27,8 @@
/** @file nir_lower_io_to_scalar.c
*
- * Replaces nir_load_input/nir_store_output operations with num_components !=
- * 1 with individual per-channel operations.
+ * Replaces nir_load_input/nir_store_output/nir_load_uniform operations
+ * with num_components != 1 with individual per-channel operations.
*/
static void
@@ -63,6 +63,39 @@ lower_load_input_to_scalar(nir_builder *b,
nir_intrinsic_instr *intr)
nir_instr_remove(&intr->instr);
}
+static void
+lower_load_uniform_to_scalar(nir_builder *b, nir_intrinsic_instr *intr)
+{
+ b->cursor = nir_before_instr(&intr->instr);
+
+ assert(intr->dest.is_ssa);
+
+ nir_ssa_def *loads[NIR_MAX_VEC_COMPONENTS];
+
+ for (unsigned i = 0; i < intr->num_components; i++) {
+ nir_intrinsic_instr *chan_intr =
+ nir_intrinsic_instr_create(b->shader, intr->intrinsic);
+ nir_ssa_dest_init(&chan_intr->instr, &chan_intr->dest,
+1, intr->dest.ssa.bit_size, NULL);
+ chan_intr->num_components = 1;
+
+ nir_intrinsic_set_base(chan_intr, nir_intrinsic_base(intr));
+ nir_intrinsic_set_component(chan_intr, nir_intrinsic_component(intr) +
i);
+ nir_intrinsic_set_range(chan_intr, nir_intrinsic_range(intr));
+ /* offset */
+ nir_src_copy(&chan_intr->src[0], &intr->src[0], chan_intr);
+
+ nir_builder_instr_insert(b, &chan_intr->instr);
+
+ loads[i] = &chan_intr->dest.ssa;
+ }
+
+ nir_ssa_def_rewrite_uses(&intr->dest.ssa,
+nir_src_for_ssa(nir_vec(b, loads,
+intr->num_components)));
+ nir_instr_remove(&intr->instr);
+}
+
static void
lower_store_output_to_scalar(nir_builder *b, nir_intrinsic_instr *intr)
{
@@ -120,6 +153,10 @@ nir_lower_io_to_scalar(nir_shader *shader,
nir_variable_mode mask)
if (mask & nir_var_shader_out)
lower_store_output_to_scalar(&b, intr);
break;
+ case nir_intrinsic_load_uniform:
+ if (mask & nir_var_uniform)
+ lower_load_uniform_to_scalar(&b, intr);
+ break;
default:
break;
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/9] u_dynarray: add util_dynarray_enlarge
This is for the case that user only know a max size
it wants to append to the array and enlarge the array
capacity before writing into it.
Signed-off-by: Qiang Yu
---
src/util/u_dynarray.h | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/util/u_dynarray.h b/src/util/u_dynarray.h
index 9bed2b9c25c..c5217082b7f 100644
--- a/src/util/u_dynarray.h
+++ b/src/util/u_dynarray.h
@@ -77,11 +77,9 @@ util_dynarray_clear(struct util_dynarray *buf)
#define DYN_ARRAY_INITIAL_SIZE 64
-/* use util_dynarray_trim to reduce the allocated storage */
static inline void *
-util_dynarray_resize(struct util_dynarray *buf, unsigned newsize)
+util_dynarray_ensure_cap(struct util_dynarray *buf, unsigned newsize)
{
- void *p;
if (newsize > buf->capacity) {
if (buf->capacity == 0)
buf->capacity = DYN_ARRAY_INITIAL_SIZE;
@@ -96,7 +94,20 @@ util_dynarray_resize(struct util_dynarray *buf, unsigned
newsize)
}
}
- p = (void *)((char *)buf->data + buf->size);
+ return (void *)((char *)buf->data + buf->size);
+}
+
+static inline void *
+util_dynarray_enlarge(struct util_dynarray *buf, int diff)
+{
+ return util_dynarray_ensure_cap(buf, buf->size + diff);
+}
+
+/* use util_dynarray_trim to reduce the allocated storage */
+static inline void *
+util_dynarray_resize(struct util_dynarray *buf, unsigned newsize)
+{
+ void *p = util_dynarray_ensure_cap(buf, newsize);
buf->size = newsize;
return p;
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 8/9] kmsro: Add lima renderonly support
From: Rob Herring
Enable using lima for KMS renderonly. This still needs KMS driver
name mapping to kmsro to be used automatically.
Signed-off-by: Rob Herring
Signed-off-by: Qiang Yu
---
meson.build | 4 ++--
src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c | 11 +++
src/gallium/winsys/kmsro/drm/meson.build| 3 +++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 98bbe756b39..318c4d59478 100644
--- a/meson.build
+++ b/meson.build
@@ -217,8 +217,8 @@ endif
if with_dri_i915 and with_gallium_i915
error('Only one i915 provider can be built')
endif
-if with_gallium_kmsro and not (with_gallium_vc4 or with_gallium_etnaviv or
with_gallium_freedreno or with_gallium_panfrost)
- error('kmsro driver requires one or more renderonly drivers (vc4, etnaviv,
freedreno, panfrost)')
+if with_gallium_kmsro and not (with_gallium_vc4 or with_gallium_etnaviv or
with_gallium_freedreno or with_gallium_panfrost or with_gallium_lima)
+ error('kmsro driver requires one or more renderonly drivers (vc4, etnaviv,
freedreno, panfrost, lima)')
endif
if with_gallium_tegra and not with_gallium_nouveau
error('tegra driver requires nouveau driver')
diff --git a/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
b/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
index 7752474f8aa..0bb8d437cd6 100644
--- a/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
+++ b/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
@@ -30,6 +30,7 @@
#include "etnaviv/drm/etnaviv_drm_public.h"
#include "freedreno/drm/freedreno_drm_public.h"
#include "panfrost/drm/panfrost_drm_public.h"
+#include "lima/drm/lima_drm_public.h"
#include "xf86drm.h"
#include "pipe/p_screen.h"
@@ -105,7 +106,17 @@ struct pipe_screen *kmsro_drm_screen_create(int fd)
}
#endif
+#if defined(GALLIUM_LIMA)
+ ro.gpu_fd = drmOpenWithType("lima", NULL, DRM_NODE_RENDER);
+ if (ro.gpu_fd >= 0) {
+ ro.create_for_resource = renderonly_create_kms_dumb_buffer_for_resource,
+ screen = lima_drm_screen_create_renderonly(&ro);
+ if (!screen)
+ close(ro.gpu_fd);
+ return screen;
+ }
+#endif
return screen;
}
diff --git a/src/gallium/winsys/kmsro/drm/meson.build
b/src/gallium/winsys/kmsro/drm/meson.build
index 51246b68e34..02064025b4d 100644
--- a/src/gallium/winsys/kmsro/drm/meson.build
+++ b/src/gallium/winsys/kmsro/drm/meson.build
@@ -22,6 +22,9 @@ kmsro_c_args = []
if with_gallium_etnaviv
kmsro_c_args += '-DGALLIUM_ETNAVIV'
endif
+if with_gallium_lima
+ kmsro_c_args += '-DGALLIUM_LIMA'
+endif
if with_gallium_vc4
kmsro_c_args += '-DGALLIUM_VC4'
endif
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/9] drm-uapi: drm_fourcc.h add ARM GPU modifier
Signed-off-by: Qiang Yu
---
include/drm-uapi/drm_fourcc.h | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
index bab20298f42..56f737af8ca 100644
--- a/include/drm-uapi/drm_fourcc.h
+++ b/include/drm-uapi/drm_fourcc.h
@@ -585,6 +585,19 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_BROADCOM_UIF fourcc_mod_code(BROADCOM, 6)
+/*
+ * Arm Buffer Layout Type Code
+ *
+ * Arm has multiple types of buffer layout which are not totally shared
+ * across devices, so add a type field at the MSB of the format field
+ * to separate each type's encoding.
+ */
+#define DRM_FORMAT_MOD_ARM_TYPE_AFBC 0x00
+#define DRM_FORMAT_MOD_ARM_TYPE_AGTB 0x01
+
+#define DRM_FORMAT_MOD_ARM_CODE(type, val) \
+ fourcc_mod_code(ARM, ((__u64)type << 48) | ((val) &
0xULL))
+
/*
* Arm Framebuffer Compression (AFBC) modifiers
*
@@ -599,7 +612,8 @@ extern "C" {
* Further information on the use of AFBC modifiers can be found in
* Documentation/gpu/afbc.rst
*/
-#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) fourcc_mod_code(ARM,
__afbc_mode)
+#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) \
+ DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AFBC, __afbc_mode)
/*
* AFBC superblock size
@@ -693,6 +707,21 @@ extern "C" {
*/
#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
+/*
+ * Arm Graphics Tiled Buffer (AGTB) modifiers
+ */
+#define DRM_FORMAT_MOD_ARM_AGTB(mode) \
+ DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AGTB, mode)
+
+/*
+ * AGTB mode 0 modifier
+ *
+ * This is used by ARM Mali Utgard/Midgard GPU. It divides buffer into
+ * 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
+ * in the block are reordered.
+ */
+#define DRM_FORMAT_MOD_ARM_AGTB_MODE0 DRM_FORMAT_MOD_ARM_AGTB(1)
+
/*
* Allwinner tiled modifier
*
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/9] gallium: add a cap to force compute minmax indices
From: Erico Nunes
pipe_draw_info has min_index and max_index fields that can be useful in
indexed drawing, however gallium may decide to not compute them in some
cases to avoid impacting performance if the driver won't need them.
However, some drivers may need to always compute these values to build a
valid command stream for indexed draw.
Instead of reimplementing this functionality or having to explicitly
compute those in driver specific code, this new cap can be used to
ensure that gallium will not skip the computation.
Drivers that set this cap will be able to rely on those values to build
the command stream.
For more details on this patch:
https://lists.freedesktop.org/archives/mesa-dev/2018-March/189251.html
Signed-off-by: Erico Nunes
---
src/gallium/auxiliary/util/u_screen.c | 3 +++
src/gallium/include/pipe/p_defines.h | 1 +
src/mesa/state_tracker/st_draw.c | 5 -
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_screen.c
b/src/gallium/auxiliary/util/u_screen.c
index 50964f3b3ef..e8fbdf56e2f 100644
--- a/src/gallium/auxiliary/util/u_screen.c
+++ b/src/gallium/auxiliary/util/u_screen.c
@@ -341,6 +341,9 @@ u_pipe_screen_get_param_defaults(struct pipe_screen
*pscreen,
case PIPE_CAP_MAX_VARYINGS:
return 8;
+ case PIPE_CAP_FORCE_COMPUTE_MINMAX_INDICES:
+ return 0;
+
default:
unreachable("bad PIPE_CAP_*");
}
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index e2b0104ce43..495ba88e521 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -858,6 +858,7 @@ enum pipe_cap
PIPE_CAP_DEST_SURFACE_SRGB_CONTROL,
PIPE_CAP_NIR_COMPACT_ARRAYS,
PIPE_CAP_MAX_VARYINGS,
+ PIPE_CAP_FORCE_COMPUTE_MINMAX_INDICES,
};
/**
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 7485fc82b18..501c09817c0 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -195,9 +195,12 @@ st_draw_vbo(struct gl_context *ctx,
if (ib) {
struct gl_buffer_object *bufobj = ib->obj;
+ struct pipe_screen *screen = st->pipe->screen;
+ bool needs_minmax_index = st->draw_needs_minmax_index ||
+ screen->get_param(screen, PIPE_CAP_FORCE_COMPUTE_MINMAX_INDICES);
/* Get index bounds for user buffers. */
- if (!index_bounds_valid && st->draw_needs_minmax_index) {
+ if (!index_bounds_valid && needs_minmax_index) {
vbo_get_minmax_indices(ctx, prims, ib, &min_index, &max_index,
nr_prims);
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/9] gallium/u_math: add ushort_to_float/float_to_ushort
Signed-off-by: Qiang Yu
---
src/util/u_math.h | 31 +++
1 file changed, 31 insertions(+)
diff --git a/src/util/u_math.h b/src/util/u_math.h
index e7dbbe5ca22..ffadfb47282 100644
--- a/src/util/u_math.h
+++ b/src/util/u_math.h
@@ -389,6 +389,37 @@ float_to_ubyte(float f)
}
}
+/**
+ * Convert ushort to float in [0, 1].
+ */
+static inline float
+ushort_to_float(ushort us)
+{
+ return (float) us * (1.0f / 65535.0f);
+}
+
+
+/**
+ * Convert float in [0,1] to ushort in [0,65535] with clamping.
+ */
+static inline ushort
+float_to_ushort(float f)
+{
+ union fi tmp;
+
+ tmp.f = f;
+ if (tmp.i < 0) {
+ return (ushort) 0;
+ }
+ else if (tmp.i >= 0x3f80 /* 1.0f */) {
+ return (ushort) 65535;
+ }
+ else {
+ tmp.f = tmp.f * (65535.0f/65536.0f) + 128.0f;
+ return (ushort) tmp.i;
+ }
+}
+
static inline float
byte_to_float_tex(int8_t b)
{
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/9] drm-uapi: add lima_drm.h
Signed-of-by: Qiang Yu
---
include/drm-uapi/lima_drm.h | 169
1 file changed, 169 insertions(+)
create mode 100644 include/drm-uapi/lima_drm.h
diff --git a/include/drm-uapi/lima_drm.h b/include/drm-uapi/lima_drm.h
new file mode 100644
index 000..95a00fb867e
--- /dev/null
+++ b/include/drm-uapi/lima_drm.h
@@ -0,0 +1,169 @@
+/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT */
+/* Copyright 2017-2018 Qiang Yu */
+
+#ifndef __LIMA_DRM_H__
+#define __LIMA_DRM_H__
+
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+enum drm_lima_param_gpu_id {
+ DRM_LIMA_PARAM_GPU_ID_UNKNOWN,
+ DRM_LIMA_PARAM_GPU_ID_MALI400,
+ DRM_LIMA_PARAM_GPU_ID_MALI450,
+};
+
+enum drm_lima_param {
+ DRM_LIMA_PARAM_GPU_ID,
+ DRM_LIMA_PARAM_NUM_PP,
+ DRM_LIMA_PARAM_GP_VERSION,
+ DRM_LIMA_PARAM_PP_VERSION,
+};
+
+/**
+ * get various information of the GPU
+ */
+struct drm_lima_get_param {
+ __u32 param; /* in, value in enum drm_lima_param */
+ __u32 pad; /* pad, must be zero */
+ __u64 value; /* out, parameter value */
+};
+
+/**
+ * create a buffer for used by GPU
+ */
+struct drm_lima_gem_create {
+ __u32 size;/* in, buffer size */
+ __u32 flags; /* in, currently no flags, must be zero */
+ __u32 handle; /* out, GEM buffer handle */
+ __u32 pad; /* pad, must be zero */
+};
+
+/**
+ * get information of a buffer
+ */
+struct drm_lima_gem_info {
+ __u32 handle; /* in, GEM buffer handle */
+ __u32 va; /* out, virtual address mapped into GPU MMU */
+ __u64 offset; /* out, used to mmap this buffer to CPU */
+};
+
+#define LIMA_SUBMIT_BO_READ 0x01
+#define LIMA_SUBMIT_BO_WRITE 0x02
+
+/* buffer information used by one task */
+struct drm_lima_gem_submit_bo {
+ __u32 handle; /* in, GEM buffer handle */
+ __u32 flags; /* in, buffer read/write by GPU */
+};
+
+#define LIMA_GP_FRAME_REG_NUM 6
+
+/* frame used to setup GP for each task */
+struct drm_lima_gp_frame {
+ __u32 frame[LIMA_GP_FRAME_REG_NUM];
+};
+
+#define LIMA_PP_FRAME_REG_NUM 23
+#define LIMA_PP_WB_REG_NUM 12
+
+/* frame used to setup mali400 GPU PP for each task */
+struct drm_lima_m400_pp_frame {
+ __u32 frame[LIMA_PP_FRAME_REG_NUM];
+ __u32 num_pp;
+ __u32 wb[3 * LIMA_PP_WB_REG_NUM];
+ __u32 plbu_array_address[4];
+ __u32 fragment_stack_address[4];
+};
+
+/* frame used to setup mali450 GPU PP for each task */
+struct drm_lima_m450_pp_frame {
+ __u32 frame[LIMA_PP_FRAME_REG_NUM];
+ __u32 num_pp;
+ __u32 wb[3 * LIMA_PP_WB_REG_NUM];
+ __u32 use_dlbu;
+ __u32 _pad;
+ union {
+ __u32 plbu_array_address[8];
+ __u32 dlbu_regs[4];
+ };
+ __u32 fragment_stack_address[8];
+};
+
+#define LIMA_PIPE_GP 0x00
+#define LIMA_PIPE_PP 0x01
+
+#define LIMA_SUBMIT_FLAG_EXPLICIT_FENCE (1 << 0)
+
+/**
+ * submit a task to GPU
+ *
+ * User can always merge multi sync_file and drm_syncobj
+ * into one drm_syncobj as in_sync[0], but we reserve
+ * in_sync[1] for another task's out_sync to avoid the
+ * export/import/merge pass when explicit sync.
+ */
+struct drm_lima_gem_submit {
+ __u32 ctx; /* in, context handle task is submitted to */
+ __u32 pipe;/* in, which pipe to use, GP/PP */
+ __u32 nr_bos; /* in, array length of bos field */
+ __u32 frame_size; /* in, size of frame field */
+ __u64 bos; /* in, array of drm_lima_gem_submit_bo */
+ __u64 frame; /* in, GP/PP frame */
+ __u32 flags; /* in, submit flags */
+ __u32 out_sync;/* in, drm_syncobj handle used to wait task finish
after submission */
+ __u32 in_sync[2]; /* in, drm_syncobj handle used to wait before start
this task */
+};
+
+#define LIMA_GEM_WAIT_READ 0x01
+#define LIMA_GEM_WAIT_WRITE 0x02
+
+/**
+ * wait pending GPU task finish of a buffer
+ */
+struct drm_lima_gem_wait {
+ __u32 handle; /* in, GEM buffer handle */
+ __u32 op; /* in, CPU want to read/write this buffer */
+ __s64 timeout_ns; /* in, wait timeout in absulute time */
+};
+
+/**
+ * create a context
+ */
+struct drm_lima_ctx_create {
+ __u32 id; /* out, context handle */
+ __u32 _pad;/* pad, must be zero */
+};
+
+/**
+ * free a context
+ */
+struct drm_lima_ctx_free {
+ __u32 id; /* in, context handle */
+ __u32 _pad;/* pad, must be zero */
+};
+
+#define DRM_LIMA_GET_PARAM 0x00
+#define DRM_LIMA_GEM_CREATE 0x01
+#define DRM_LIMA_GEM_INFO0x02
+#define DRM_LIMA_GEM_SUBMIT 0x03
+#define DRM_LIMA_GEM_WAIT0x04
+#define DRM_LIMA_CTX_CREATE 0x05
+#define DRM_LIMA_CTX_FREE0x06
+
+#define DRM_IOCTL_LIMA_GET_PARAM DRM_IOWR(DRM_COMMAND_BASE +
DRM_LIMA_GET_PARAM, struct drm_lima_get_param)
+#define DRM_IOCTL_LIMA_GEM_CREATE DRM_IOWR(DRM_COMMAND
[Mesa-dev] [PATCH 9/9] kmsro: Add platform support for exynos and sun4i
From: Rob Herring Signed-off-by: Rob Herring Signed-off-by: Qiang Yu --- src/gallium/targets/dri/meson.build | 2 ++ src/gallium/targets/dri/target.c| 2 ++ 2 files changed, 4 insertions(+) diff --git a/src/gallium/targets/dri/meson.build b/src/gallium/targets/dri/meson.build index ff3455592ca..ae417d8ad5b 100644 --- a/src/gallium/targets/dri/meson.build +++ b/src/gallium/targets/dri/meson.build @@ -63,6 +63,7 @@ libgallium_dri = shared_library( ) foreach d : [[with_gallium_kmsro, [ + 'exynos_dri.so', 'hx8357d_dri.so', 'ili9225_dri.so', 'ili9341_dri.so', @@ -74,6 +75,7 @@ foreach d : [[with_gallium_kmsro, [ 'rockchip_dri.so', 'st7586.so', 'st7735r.so', + 'sun4i-drm_dri.so', ]], [with_gallium_radeonsi, 'radeonsi_dri.so'], [with_gallium_nouveau, 'nouveau_dri.so'], diff --git a/src/gallium/targets/dri/target.c b/src/gallium/targets/dri/target.c index c702058b0c9..ec657de277d 100644 --- a/src/gallium/targets/dri/target.c +++ b/src/gallium/targets/dri/target.c @@ -93,6 +93,7 @@ DEFINE_LOADER_DRM_ENTRYPOINT(tegra); #endif #if defined(GALLIUM_KMSRO) +DEFINE_LOADER_DRM_ENTRYPOINT(exynos) DEFINE_LOADER_DRM_ENTRYPOINT(hx8357d) DEFINE_LOADER_DRM_ENTRYPOINT(ili9225) DEFINE_LOADER_DRM_ENTRYPOINT(ili9341) @@ -103,6 +104,7 @@ DEFINE_LOADER_DRM_ENTRYPOINT(repaper) DEFINE_LOADER_DRM_ENTRYPOINT(rockchip) DEFINE_LOADER_DRM_ENTRYPOINT(st7586) DEFINE_LOADER_DRM_ENTRYPOINT(st7735r) +DEFINE_LOADER_DRM_ENTRYPOINT(sun4i_drm) #endif #if defined(GALLIUM_LIMA) -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/9] Lima mesa driver
Mesa Gallium3D driver for ARM Mali 400/450 GPUs. Lima is still in development and not ready for daily usage, but can run some simple tests like kmscube and glamrk2, and some single full screen application like kodi-gbm. Mesa related EGL/GLX_EXT_buffer_age and EGL_KHR_partial_update changes are not in this patch series because the solution has not been settle down yet. All lima commits are squashed. For whole history of this driver's development, see: https://gitlab.freedesktop.org/lima/mesa/commits/lima-18.3 https://gitlab.freedesktop.org/lima/mesa/commits/lima-18.1 Kernel driver is ready to be merged: https://patchwork.kernel.org/patch/10845911/ This patch series also depends on a kernel patch which is under review now: https://patchwork.kernel.org/patch/10852619/ Erico Nunes (1): gallium: add a cap to force compute minmax indices Qiang Yu (6): gallium/u_math: add ushort_to_float/float_to_ushort nir: add load uniform lower to scalar u_dynarray: add util_dynarray_enlarge drm-uapi: drm_fourcc.h add ARM GPU modifier drm-uapi: add lima_drm.h gallium: add lima driver Rob Herring (2): kmsro: Add lima renderonly support kmsro: Add platform support for exynos and sun4i include/drm-uapi/drm_fourcc.h | 31 +- include/drm-uapi/lima_drm.h | 169 ++ meson.build |7 +- meson_options.txt |2 +- src/compiler/nir/nir_intrinsics.py|4 +- src/compiler/nir/nir_lower_io.c |2 +- src/compiler/nir/nir_lower_io_to_scalar.c | 41 +- .../auxiliary/pipe-loader/pipe_loader_drm.c |5 + .../auxiliary/target-helpers/drm_helper.h | 23 + .../target-helpers/drm_helper_public.h|3 + src/gallium/auxiliary/util/u_screen.c |3 + src/gallium/drivers/lima/ir/gp/codegen.c | 619 +++ src/gallium/drivers/lima/ir/gp/codegen.h | 166 ++ src/gallium/drivers/lima/ir/gp/disasm.c | 568 ++ src/gallium/drivers/lima/ir/gp/gpir.h | 392 src/gallium/drivers/lima/ir/gp/instr.c| 488 + src/gallium/drivers/lima/ir/gp/lower.c| 529 ++ src/gallium/drivers/lima/ir/gp/nir.c | 420 + src/gallium/drivers/lima/ir/gp/node.c | 492 + .../drivers/lima/ir/gp/physical_regalloc.c| 135 ++ .../drivers/lima/ir/gp/reduce_scheduler.c | 220 +++ src/gallium/drivers/lima/ir/gp/scheduler.c| 809 .../drivers/lima/ir/gp/value_regalloc.c | 170 ++ src/gallium/drivers/lima/ir/lima_ir.h | 65 + src/gallium/drivers/lima/ir/pp/codegen.c | 669 +++ src/gallium/drivers/lima/ir/pp/codegen.h | 359 src/gallium/drivers/lima/ir/pp/disasm.c | 776 src/gallium/drivers/lima/ir/pp/instr.c| 311 src/gallium/drivers/lima/ir/pp/lower.c| 483 + src/gallium/drivers/lima/ir/pp/nir.c | 497 + src/gallium/drivers/lima/ir/pp/node.c | 432 + .../drivers/lima/ir/pp/node_to_instr.c| 401 src/gallium/drivers/lima/ir/pp/ppir.h | 515 ++ src/gallium/drivers/lima/ir/pp/regalloc.c | 757 src/gallium/drivers/lima/ir/pp/scheduler.c| 197 ++ src/gallium/drivers/lima/lima_bo.c| 337 src/gallium/drivers/lima/lima_bo.h| 66 + src/gallium/drivers/lima/lima_context.c | 262 +++ src/gallium/drivers/lima/lima_context.h | 291 +++ src/gallium/drivers/lima/lima_draw.c | 1636 + src/gallium/drivers/lima/lima_fence.c | 120 ++ src/gallium/drivers/lima/lima_fence.h | 36 + src/gallium/drivers/lima/lima_program.c | 311 src/gallium/drivers/lima/lima_program.h | 35 + src/gallium/drivers/lima/lima_query.c | 96 + src/gallium/drivers/lima/lima_resource.c | 610 ++ src/gallium/drivers/lima/lima_resource.h | 86 + src/gallium/drivers/lima/lima_screen.c| 554 ++ src/gallium/drivers/lima/lima_screen.h| 88 + src/gallium/drivers/lima/lima_state.c | 516 ++ src/gallium/drivers/lima/lima_submit.c| 184 ++ src/gallium/drivers/lima/lima_submit.h| 43 + src/gallium/drivers/lima/lima_texture.c | 278 +++ src/gallium/drivers/lima/lima_texture.h | 35 + src/gallium/drivers/lima/lima_tiling.c| 184 ++ src/gallium/drivers/lima/lima_tiling.h| 44 + src/gallium/drivers/lima/lima_util.c | 80 + src/gallium/drivers/lima/lima_util.h | 37 + src/gallium/drivers/lima/meson.build | 87 + src/gallium/include/pipe/p_defines.h |1 + src/gallium/meson.build |6 + src/gallium/targets/dri/meson.build |7 +- src/gallium/targets/dri/target.c |5 + .../winsys/kmsro/drm/kmsro_drm_winsys.c | 11 + src/gallium/winsys/kmsro/drm/meson.build |3 + src/ga
Re: [Mesa-dev] [PATCH] radv: remove sisched hack for talos
On 16/3/19 6:53 am, Dieter Nützel wrote:
Am 15.03.2019 15:20, schrieb Samuel Pitoiset:
Results of my benchmarks are:
3 runs at 1080p:
GFX8: -1%
GFX9: -1.12%
3 runs at 4k:
GFX8: -2%
GFX9: -1.85%
I'm actually not sure if we want to remove it...
Yes, my hint is we should wait until Marek is back from vacation.
Running all the time with AMD_DEBUB (R600_DEBUG)=nir,sisched 'cause it's
worth it...
Can you point to specific games that are helped?
Dieter
On 3/15/19 11:25 AM, Timothy Arceri wrote:
This was added in 8a7d4092d260 but no longer seems to have any
impact on performance.
---
src/amd/vulkan/radv_device.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 9570c15af02..56421dbc74b 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -499,15 +499,7 @@ radv_handle_per_app_options(struct radv_instance
*instance,
if (!name)
return;
- if (!strcmp(name, "Talos - Linux - 32bit") ||
- !strcmp(name, "Talos - Linux - 64bit")) {
- if (!(instance->debug_flags & RADV_DEBUG_NO_SISCHED)) {
- /* Force enable LLVM sisched for Talos because it looks
- * safe and it gives few more FPS.
- */
- instance->perftest_flags |= RADV_PERFTEST_SISCHED;
- }
- } else if (!strcmp(name, "DOOM_VFR")) {
+ if (!strcmp(name, "DOOM_VFR")) {
/* Work around a Doom VFR game bug */
instance->debug_flags |= RADV_DEBUG_NO_DYNAMIC_BOUNDS;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/8] st/mesa: implement "zombie" sampler views
On Fri, Mar 15, 2019 at 8:55 AM Jose Fonseca wrote:
>
> On 14/03/2019 19:37, Brian Paul wrote:
> > When st_texture_release_all_sampler_views() is called the texture may
> > have sampler views belonging to several contexts. If we unreference a
> > sampler view and its refcount hits zero, we need to be sure to destroy
> > the sampler view with the same context which created it.
> >
> > This was not the case with the previous code which used
> > pipe_sampler_view_release(). That function could end up freeing a
> > sampler view with a context different than the one which created it.
> > In the case of the VMware svga driver, we detected this but leaked the
> > sampler view. This led to a crash with google-chrome when the kernel
> > module had too many sampler views. VMware bug 2274734.
> >
> > Alternately, if we try to delete a sampler view with the correct
> > context, we may be "reaching into" a context which is active on
> > another thread. That's not safe.
> >
> > To fix these issues this patch adds a per-context list of "zombie"
> > sampler views. These are views which are to be freed at some point
> > when the context is active. Other contexts may safely add sampler
> > views to the zombie list at any time (it's mutex protected). This
> > avoids the context/view ownership mix-ups we had before.
> >
> > Tested with: google-chrome, google earth, Redway3D Watch/Turbine demos
> > a few Linux games. If anyone can recomment some other multi-threaded,
> > multi-context GL apps to test, please let me know.
> > ---
> > src/mesa/state_tracker/st_cb_flush.c | 6 +++
> > src/mesa/state_tracker/st_context.c | 81
> >
> > src/mesa/state_tracker/st_context.h | 25 ++
> > src/mesa/state_tracker/st_sampler_view.c | 27 +--
> > src/mesa/state_tracker/st_texture.h | 3 ++
> > 5 files changed, 138 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/mesa/state_tracker/st_cb_flush.c
> > b/src/mesa/state_tracker/st_cb_flush.c
> > index 5b3188c..81e5338 100644
> > --- a/src/mesa/state_tracker/st_cb_flush.c
> > +++ b/src/mesa/state_tracker/st_cb_flush.c
> > @@ -39,6 +39,7 @@
> > #include "st_cb_flush.h"
> > #include "st_cb_clear.h"
> > #include "st_cb_fbo.h"
> > +#include "st_context.h"
> > #include "st_manager.h"
> > #include "pipe/p_context.h"
> > #include "pipe/p_defines.h"
> > @@ -53,6 +54,11 @@ st_flush(struct st_context *st,
> > {
> > st_flush_bitmap_cache(st);
> >
> > + /* We want to call this function periodically.
> > +* Typically, it has nothing to do so it shouldn't be expensive.
> > +*/
> > + st_context_free_zombie_objects(st);
> > +
> > st->pipe->flush(st->pipe, fence, flags);
> > }
> >
> > diff --git a/src/mesa/state_tracker/st_context.c
> > b/src/mesa/state_tracker/st_context.c
> > index 2898279..bd919da 100644
> > --- a/src/mesa/state_tracker/st_context.c
> > +++ b/src/mesa/state_tracker/st_context.c
> > @@ -261,6 +261,80 @@ st_invalidate_state(struct gl_context *ctx)
> > }
> >
> >
> > +/*
> > + * In some circumstances (such as running google-chrome) the state
> > + * tracker may try to delete a resource view from a context different
> > + * than when it was created. We don't want to do that.
> > + * In that situation, st_texture_release_all_sampler_views() calls this
> > + * function to save the view for later deletion. The context here is
> > + * expected to be the context which created the view.
> > + */
> > +void
> > +st_save_zombie_sampler_view(struct st_context *st,
> > +struct pipe_sampler_view *view)
> > +{
> > + struct st_zombie_sampler_view_node *entry;
> > +
> > + assert(view->context == st->pipe);
> > + assert(view->reference.count == 1);
> > +
> > + entry = MALLOC_STRUCT(st_zombie_sampler_view_node);
> > + if (!entry)
> > + return;
> > +
> > + entry->view = view;
> > +
> > + /* We need a mutex since this function may be called from one thread
> > +* while free_zombie_resource_views() is called from another.
> > +*/
> > + mtx_lock(&st->zombie_sampler_views.mutex);
> > + LIST_ADDTAIL(&entry->node, &st->zombie_sampler_views.list.node);
> > + mtx_unlock(&st->zombie_sampler_views.mutex);
> > +}
> > +
> > +
> > +/*
> > + * Free any zombie sampler views that may be attached to this context.
> > + */
> > +static void
> > +free_zombie_sampler_views(struct st_context *st)
> > +{
> > + struct st_zombie_sampler_view_node *entry, *next;
> > +
> > + if (LIST_IS_EMPTY(&st->zombie_sampler_views.list.node)) {
> > + return;
> > + }
> > +
> > + mtx_lock(&st->zombie_sampler_views.mutex);
> > +
> > + LIST_FOR_EACH_ENTRY_SAFE(entry, next,
> > +&st->zombie_sampler_views.list.node, node) {
> > + LIST_DEL(&entry->node); // remove this entry from the list
> > +
> > + assert(entry->view->context == st->pipe);
> > + assert(entry->view->reference.count == 1);
> > + pipe_sam
[Mesa-dev] [PATCH] st/mesa: implement "zombie" sampler views (v2)
When st_texture_release_all_sampler_views() is called the texture may
have sampler views belonging to several contexts. If we unreference a
sampler view and its refcount hits zero, we need to be sure to destroy
the sampler view with the same context which created it.
This was not the case with the previous code which used
pipe_sampler_view_release(). That function could end up freeing a
sampler view with a context different than the one which created it.
In the case of the VMware svga driver, we detected this but leaked the
sampler view. This led to a crash with google-chrome when the kernel
module had too many sampler views. VMware bug 2274734.
Alternately, if we try to delete a sampler view with the correct
context, we may be "reaching into" a context which is active on
another thread. That's not safe.
To fix these issues this patch adds a per-context list of "zombie"
sampler views. These are views which are to be freed at some point
when the context is active. Other contexts may safely add sampler
views to the zombie list at any time (it's mutex protected). This
avoids the context/view ownership mix-ups we had before.
Tested with: google-chrome, google earth, Redway3D Watch/Turbine demos
a few Linux games. If anyone can recomment some other multi-threaded,
multi-context GL apps to test, please let me know.
v2: avoid potential race issue by always adding sampler views to the
zombie list if the view's context doesn't match the current context,
ignoring the refcount.
Reviewed-by: Roland Scheidegger
Reviewed-by: Neha Bhende
Reviewed-by: Mathias Fröhlich
Reviewed-By: Jose Fonseca
---
src/mesa/state_tracker/st_cb_flush.c | 6 +++
src/mesa/state_tracker/st_context.c | 80
src/mesa/state_tracker/st_context.h | 25 ++
src/mesa/state_tracker/st_sampler_view.c | 21 +++--
src/mesa/state_tracker/st_texture.h | 3 ++
5 files changed, 131 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_flush.c
b/src/mesa/state_tracker/st_cb_flush.c
index 5b3188c..81e5338 100644
--- a/src/mesa/state_tracker/st_cb_flush.c
+++ b/src/mesa/state_tracker/st_cb_flush.c
@@ -39,6 +39,7 @@
#include "st_cb_flush.h"
#include "st_cb_clear.h"
#include "st_cb_fbo.h"
+#include "st_context.h"
#include "st_manager.h"
#include "pipe/p_context.h"
#include "pipe/p_defines.h"
@@ -53,6 +54,11 @@ st_flush(struct st_context *st,
{
st_flush_bitmap_cache(st);
+ /* We want to call this function periodically.
+* Typically, it has nothing to do so it shouldn't be expensive.
+*/
+ st_context_free_zombie_objects(st);
+
st->pipe->flush(st->pipe, fence, flags);
}
diff --git a/src/mesa/state_tracker/st_context.c
b/src/mesa/state_tracker/st_context.c
index 2898279..c38f8e5 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -261,6 +261,79 @@ st_invalidate_state(struct gl_context *ctx)
}
+/*
+ * In some circumstances (such as running google-chrome) the state
+ * tracker may try to delete a resource view from a context different
+ * than when it was created. We don't want to do that.
+ *
+ * In that situation, st_texture_release_all_sampler_views() calls this
+ * function to transfer the sampler view reference to this context (expected
+ * to be the context which created the view.)
+ */
+void
+st_save_zombie_sampler_view(struct st_context *st,
+struct pipe_sampler_view *view)
+{
+ struct st_zombie_sampler_view_node *entry;
+
+ assert(view->context == st->pipe);
+
+ entry = MALLOC_STRUCT(st_zombie_sampler_view_node);
+ if (!entry)
+ return;
+
+ entry->view = view;
+
+ /* We need a mutex since this function may be called from one thread
+* while free_zombie_resource_views() is called from another.
+*/
+ mtx_lock(&st->zombie_sampler_views.mutex);
+ LIST_ADDTAIL(&entry->node, &st->zombie_sampler_views.list.node);
+ mtx_unlock(&st->zombie_sampler_views.mutex);
+}
+
+
+/*
+ * Free any zombie sampler views that may be attached to this context.
+ */
+static void
+free_zombie_sampler_views(struct st_context *st)
+{
+ struct st_zombie_sampler_view_node *entry, *next;
+
+ if (LIST_IS_EMPTY(&st->zombie_sampler_views.list.node)) {
+ return;
+ }
+
+ mtx_lock(&st->zombie_sampler_views.mutex);
+
+ LIST_FOR_EACH_ENTRY_SAFE(entry, next,
+&st->zombie_sampler_views.list.node, node) {
+ LIST_DEL(&entry->node); // remove this entry from the list
+
+ assert(entry->view->context == st->pipe);
+ pipe_sampler_view_reference(&entry->view, NULL);
+
+ free(entry);
+ }
+
+ assert(LIST_IS_EMPTY(&st->zombie_sampler_views.list.node));
+
+ mtx_unlock(&st->zombie_sampler_views.mutex);
+}
+
+
+/*
+ * This function is called periodically to free any zombie objects
+ * which are attached to this context.
+ */
+void
+st_context_free_zombie_objects(struct st_context *st)
+{
+ free_zombie_samp
Re: [Mesa-dev] [PATCH 1/8] st/mesa: implement "zombie" sampler views
On 03/15/2019 09:54 AM, Jose Fonseca wrote:
On 14/03/2019 19:37, Brian Paul wrote:
When st_texture_release_all_sampler_views() is called the texture may
have sampler views belonging to several contexts. If we unreference a
sampler view and its refcount hits zero, we need to be sure to destroy
the sampler view with the same context which created it.
This was not the case with the previous code which used
pipe_sampler_view_release(). That function could end up freeing a
sampler view with a context different than the one which created it.
In the case of the VMware svga driver, we detected this but leaked the
sampler view. This led to a crash with google-chrome when the kernel
module had too many sampler views. VMware bug 2274734.
Alternately, if we try to delete a sampler view with the correct
context, we may be "reaching into" a context which is active on
another thread. That's not safe.
To fix these issues this patch adds a per-context list of "zombie"
sampler views. These are views which are to be freed at some point
when the context is active. Other contexts may safely add sampler
views to the zombie list at any time (it's mutex protected). This
avoids the context/view ownership mix-ups we had before.
Tested with: google-chrome, google earth, Redway3D Watch/Turbine demos
a few Linux games. If anyone can recomment some other multi-threaded,
multi-context GL apps to test, please let me know.
---
src/mesa/state_tracker/st_cb_flush.c | 6 +++
src/mesa/state_tracker/st_context.c | 81
src/mesa/state_tracker/st_context.h | 25 ++
src/mesa/state_tracker/st_sampler_view.c | 27 +--
src/mesa/state_tracker/st_texture.h | 3 ++
5 files changed, 138 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_flush.c
b/src/mesa/state_tracker/st_cb_flush.c
index 5b3188c..81e5338 100644
--- a/src/mesa/state_tracker/st_cb_flush.c
+++ b/src/mesa/state_tracker/st_cb_flush.c
@@ -39,6 +39,7 @@
#include "st_cb_flush.h"
#include "st_cb_clear.h"
#include "st_cb_fbo.h"
+#include "st_context.h"
#include "st_manager.h"
#include "pipe/p_context.h"
#include "pipe/p_defines.h"
@@ -53,6 +54,11 @@ st_flush(struct st_context *st,
{
st_flush_bitmap_cache(st);
+ /* We want to call this function periodically.
+ * Typically, it has nothing to do so it shouldn't be expensive.
+ */
+ st_context_free_zombie_objects(st);
+
st->pipe->flush(st->pipe, fence, flags);
}
diff --git a/src/mesa/state_tracker/st_context.c
b/src/mesa/state_tracker/st_context.c
index 2898279..bd919da 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -261,6 +261,80 @@ st_invalidate_state(struct gl_context *ctx)
}
+/*
+ * In some circumstances (such as running google-chrome) the state
+ * tracker may try to delete a resource view from a context different
+ * than when it was created. We don't want to do that.
+ * In that situation, st_texture_release_all_sampler_views() calls this
+ * function to save the view for later deletion. The context here is
+ * expected to be the context which created the view.
+ */
+void
+st_save_zombie_sampler_view(struct st_context *st,
+ struct pipe_sampler_view *view)
+{
+ struct st_zombie_sampler_view_node *entry;
+
+ assert(view->context == st->pipe);
+ assert(view->reference.count == 1);
+
+ entry = MALLOC_STRUCT(st_zombie_sampler_view_node);
+ if (!entry)
+ return;
+
+ entry->view = view;
+
+ /* We need a mutex since this function may be called from one thread
+ * while free_zombie_resource_views() is called from another.
+ */
+ mtx_lock(&st->zombie_sampler_views.mutex);
+ LIST_ADDTAIL(&entry->node, &st->zombie_sampler_views.list.node);
+ mtx_unlock(&st->zombie_sampler_views.mutex);
+}
+
+
+/*
+ * Free any zombie sampler views that may be attached to this context.
+ */
+static void
+free_zombie_sampler_views(struct st_context *st)
+{
+ struct st_zombie_sampler_view_node *entry, *next;
+
+ if (LIST_IS_EMPTY(&st->zombie_sampler_views.list.node)) {
+ return;
+ }
+
+ mtx_lock(&st->zombie_sampler_views.mutex);
+
+ LIST_FOR_EACH_ENTRY_SAFE(entry, next,
+ &st->zombie_sampler_views.list.node, node) {
+ LIST_DEL(&entry->node); // remove this entry from the list
+
+ assert(entry->view->context == st->pipe);
+ assert(entry->view->reference.count == 1);
+ pipe_sampler_view_reference(&entry->view, NULL);
+
+ free(entry);
+ }
+
+ assert(LIST_IS_EMPTY(&st->zombie_sampler_views.list.node));
+
+ mtx_unlock(&st->zombie_sampler_views.mutex);
+}
+
+
+/*
+ * This function is called periodically to free any zombie objects
+ * which are attached to this context.
+ */
+void
+st_context_free_zombie_objects(struct st_context *st)
+{
+ free_zombie_sampler_views(st);
+}
+
+
static void
st_destroy_context_priv(struct st_context *st, bool de
Re: [Mesa-dev] [PATCH] radv: remove sisched hack for talos
Am 15.03.2019 15:20, schrieb Samuel Pitoiset:
Results of my benchmarks are:
3 runs at 1080p:
GFX8: -1%
GFX9: -1.12%
3 runs at 4k:
GFX8: -2%
GFX9: -1.85%
I'm actually not sure if we want to remove it...
Yes, my hint is we should wait until Marek is back from vacation.
Running all the time with AMD_DEBUB (R600_DEBUG)=nir,sisched 'cause it's
worth it...
Dieter
On 3/15/19 11:25 AM, Timothy Arceri wrote:
This was added in 8a7d4092d260 but no longer seems to have any
impact on performance.
---
src/amd/vulkan/radv_device.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c
b/src/amd/vulkan/radv_device.c
index 9570c15af02..56421dbc74b 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -499,15 +499,7 @@ radv_handle_per_app_options(struct radv_instance
*instance,
if (!name)
return;
- if (!strcmp(name, "Talos - Linux - 32bit") ||
- !strcmp(name, "Talos - Linux - 64bit")) {
- if (!(instance->debug_flags & RADV_DEBUG_NO_SISCHED)) {
- /* Force enable LLVM sisched for Talos because it looks
-* safe and it gives few more FPS.
-*/
- instance->perftest_flags |= RADV_PERFTEST_SISCHED;
- }
- } else if (!strcmp(name, "DOOM_VFR")) {
+ if (!strcmp(name, "DOOM_VFR")) {
/* Work around a Doom VFR game bug */
instance->debug_flags |= RADV_DEBUG_NO_DYNAMIC_BOUNDS;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 35268] initial-exec TLS model breaks dlopen'ed libGL
https://bugs.freedesktop.org/show_bug.cgi?id=35268 makep...@firemail.cc changed: What|Removed |Added CC||makep...@firemail.cc -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
> So you have to be able to generate both S,T and S,1-T. [Or > perhaps there's an explicit control for it, I forget.] With GLES2+, > it's just gl_PointCoord though. FWIW, the blob emits a linear (er, affine technically?) transformation in the shader to do the flip, loading the matrix from a special uniform so they can reuse the same shader across contexts and maybe also APIs. This seems a little excessive to me since for OpenGL scanout they're just using the identity matrix but hey. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110116] Neverball particles are broken (GL_POINT_SPRITE)
https://bugs.freedesktop.org/show_bug.cgi?id=110116 --- Comment #6 from QwertyChouskie --- Created attachment 143684 --> https://bugs.freedesktop.org/attachment.cgi?id=143684&action=edit Neverball apitrace Here's an apitrace from my system with the Ubuntu 18.04, Mesa 18.3.3, and Neverball 1.6.0 from the repos. -- 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 110116] Neverball particles are broken (GL_POINT_SPRITE)
https://bugs.freedesktop.org/show_bug.cgi?id=110116 --- Comment #5 from QwertyChouskie --- According to https://github.com/Neverball/neverball/issues/170#issuecomment-473301333 there seems to be some difference between the Debian/Ubuntu packaged Neverball and building it from source. Also, the code at https://github.com/Neverball/neverball does have changes from 1.6.0, so this may not be a fair comparison. I'll try to get an apitrace and post it here. -- 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 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
On Fri, Mar 15, 2019 at 5:00 PM Ilia Mirkin wrote: > > On Fri, Mar 15, 2019 at 11:52 AM Connor Abbott wrote: > > > > On Fri, Mar 15, 2019 at 3:46 PM Ilia Mirkin wrote: > > > > > > On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig < aly...@rosenzweig.io> wrote: > > > > > > > > > This is needed if you can only handle point sprites on certain > > > > > varyings but not others. This is the case for nv30- and nvc0-based > > > > > GPUs, which is why the cap was introduced. > > > > > > > > > > If your GPU does not have such restrictions, you can safely remove the cap. > > > > > > > > Ah-ha, I see, thank you. > > > > > > > > I can't handle point sprites on any varyings (they all have to get > > > > lowered to gl_PointCoord), so.. :) > > > > > > Yeah, that's not extremely surprising. Point sprites weren't a thing > > > in GLES 1, and only available as gl_PointCoord in GLES 2. With GL 1.x > > > + multitexture, you can have up to 8 tex coords used in your fragment > > > pipeline, and so need a fixed-function way of setting them to point > > > coords when drawing points. Hence the current TEXCOORD semantics of > > > just bumping generic varyings by 8, so that we can be sure that any > > > shaders with true gl_TexCoord[] usage get the low 8 varyings assigned > > > (and which, on nvc0+ go through "special" shader outputs, subject to > > > the replacement). > > > > > > Note that e.g. Adreno A3xx+ is capable of doing the replacement > > > everywhere, despite being a GLES-targeted GPU. So it's not out of the > > > realm of possibility that you just haven't figured out the full > > > mechanism for doing it yet. > > > > Can you replace more than one varying and output multiple points vertex shader, or something crazy like that? On Mali gl_PointCoord is just a normal varying whose descriptor points to a special point-coord buffer that gets fed to the tiler, so we should be able to make an arbitrary varying "turn into" gl_PointCoord just by changing its descriptor at draw time. > > Yeah, any (gl_TexCoord) varying may get replaced by a point sprite > coord (in GL 1.x / GL 2.x). Note that there's additional complication > from coordinate inversion, when you're drawing on the winsys fb vs an > fbo. So you have to be able to generate both S,T and S,1-T. [Or > perhaps there's an explicit control for it, I forget.] With GLES2+, > it's just gl_PointCoord though. > > The way gallium handles this is that you get a mask of varyings to > replace in https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe/p_state.h#n188 > + whether to invert or not (sprite_coord_mode). Oh, whoops... I guess I was thinking of gl_PointSize. gl_PointCoord in the fragment shader does indeed come through an extra-special varying, at least the way the blob does it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
On Fri, Mar 15, 2019 at 11:52 AM Connor Abbott wrote: > > On Fri, Mar 15, 2019 at 3:46 PM Ilia Mirkin wrote: > > > > On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig > > wrote: > > > > > > > This is needed if you can only handle point sprites on certain > > > > varyings but not others. This is the case for nv30- and nvc0-based > > > > GPUs, which is why the cap was introduced. > > > > > > > > If your GPU does not have such restrictions, you can safely remove the > > > > cap. > > > > > > Ah-ha, I see, thank you. > > > > > > I can't handle point sprites on any varyings (they all have to get > > > lowered to gl_PointCoord), so.. :) > > > > Yeah, that's not extremely surprising. Point sprites weren't a thing > > in GLES 1, and only available as gl_PointCoord in GLES 2. With GL 1.x > > + multitexture, you can have up to 8 tex coords used in your fragment > > pipeline, and so need a fixed-function way of setting them to point > > coords when drawing points. Hence the current TEXCOORD semantics of > > just bumping generic varyings by 8, so that we can be sure that any > > shaders with true gl_TexCoord[] usage get the low 8 varyings assigned > > (and which, on nvc0+ go through "special" shader outputs, subject to > > the replacement). > > > > Note that e.g. Adreno A3xx+ is capable of doing the replacement > > everywhere, despite being a GLES-targeted GPU. So it's not out of the > > realm of possibility that you just haven't figured out the full > > mechanism for doing it yet. > > Can you replace more than one varying and output multiple points vertex > shader, or something crazy like that? On Mali gl_PointCoord is just a normal > varying whose descriptor points to a special point-coord buffer that gets fed > to the tiler, so we should be able to make an arbitrary varying "turn into" > gl_PointCoord just by changing its descriptor at draw time. Yeah, any (gl_TexCoord) varying may get replaced by a point sprite coord (in GL 1.x / GL 2.x). Note that there's additional complication from coordinate inversion, when you're drawing on the winsys fb vs an fbo. So you have to be able to generate both S,T and S,1-T. [Or perhaps there's an explicit control for it, I forget.] With GLES2+, it's just gl_PointCoord though. The way gallium handles this is that you get a mask of varyings to replace in https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe/p_state.h#n188 + whether to invert or not (sprite_coord_mode). Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/8] st/mesa: implement "zombie" sampler views
On 14/03/2019 19:37, Brian Paul wrote:
When st_texture_release_all_sampler_views() is called the texture may
have sampler views belonging to several contexts. If we unreference a
sampler view and its refcount hits zero, we need to be sure to destroy
the sampler view with the same context which created it.
This was not the case with the previous code which used
pipe_sampler_view_release(). That function could end up freeing a
sampler view with a context different than the one which created it.
In the case of the VMware svga driver, we detected this but leaked the
sampler view. This led to a crash with google-chrome when the kernel
module had too many sampler views. VMware bug 2274734.
Alternately, if we try to delete a sampler view with the correct
context, we may be "reaching into" a context which is active on
another thread. That's not safe.
To fix these issues this patch adds a per-context list of "zombie"
sampler views. These are views which are to be freed at some point
when the context is active. Other contexts may safely add sampler
views to the zombie list at any time (it's mutex protected). This
avoids the context/view ownership mix-ups we had before.
Tested with: google-chrome, google earth, Redway3D Watch/Turbine demos
a few Linux games. If anyone can recomment some other multi-threaded,
multi-context GL apps to test, please let me know.
---
src/mesa/state_tracker/st_cb_flush.c | 6 +++
src/mesa/state_tracker/st_context.c | 81
src/mesa/state_tracker/st_context.h | 25 ++
src/mesa/state_tracker/st_sampler_view.c | 27 +--
src/mesa/state_tracker/st_texture.h | 3 ++
5 files changed, 138 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_flush.c
b/src/mesa/state_tracker/st_cb_flush.c
index 5b3188c..81e5338 100644
--- a/src/mesa/state_tracker/st_cb_flush.c
+++ b/src/mesa/state_tracker/st_cb_flush.c
@@ -39,6 +39,7 @@
#include "st_cb_flush.h"
#include "st_cb_clear.h"
#include "st_cb_fbo.h"
+#include "st_context.h"
#include "st_manager.h"
#include "pipe/p_context.h"
#include "pipe/p_defines.h"
@@ -53,6 +54,11 @@ st_flush(struct st_context *st,
{
st_flush_bitmap_cache(st);
+ /* We want to call this function periodically.
+* Typically, it has nothing to do so it shouldn't be expensive.
+*/
+ st_context_free_zombie_objects(st);
+
st->pipe->flush(st->pipe, fence, flags);
}
diff --git a/src/mesa/state_tracker/st_context.c b/src/mesa/state_tracker/st_context.c
index 2898279..bd919da 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -261,6 +261,80 @@ st_invalidate_state(struct gl_context *ctx)
}
+/*
+ * In some circumstances (such as running google-chrome) the state
+ * tracker may try to delete a resource view from a context different
+ * than when it was created. We don't want to do that.
+ * In that situation, st_texture_release_all_sampler_views() calls this
+ * function to save the view for later deletion. The context here is
+ * expected to be the context which created the view.
+ */
+void
+st_save_zombie_sampler_view(struct st_context *st,
+struct pipe_sampler_view *view)
+{
+ struct st_zombie_sampler_view_node *entry;
+
+ assert(view->context == st->pipe);
+ assert(view->reference.count == 1);
+
+ entry = MALLOC_STRUCT(st_zombie_sampler_view_node);
+ if (!entry)
+ return;
+
+ entry->view = view;
+
+ /* We need a mutex since this function may be called from one thread
+* while free_zombie_resource_views() is called from another.
+*/
+ mtx_lock(&st->zombie_sampler_views.mutex);
+ LIST_ADDTAIL(&entry->node, &st->zombie_sampler_views.list.node);
+ mtx_unlock(&st->zombie_sampler_views.mutex);
+}
+
+
+/*
+ * Free any zombie sampler views that may be attached to this context.
+ */
+static void
+free_zombie_sampler_views(struct st_context *st)
+{
+ struct st_zombie_sampler_view_node *entry, *next;
+
+ if (LIST_IS_EMPTY(&st->zombie_sampler_views.list.node)) {
+ return;
+ }
+
+ mtx_lock(&st->zombie_sampler_views.mutex);
+
+ LIST_FOR_EACH_ENTRY_SAFE(entry, next,
+&st->zombie_sampler_views.list.node, node) {
+ LIST_DEL(&entry->node); // remove this entry from the list
+
+ assert(entry->view->context == st->pipe);
+ assert(entry->view->reference.count == 1);
+ pipe_sampler_view_reference(&entry->view, NULL);
+
+ free(entry);
+ }
+
+ assert(LIST_IS_EMPTY(&st->zombie_sampler_views.list.node));
+
+ mtx_unlock(&st->zombie_sampler_views.mutex);
+}
+
+
+/*
+ * This function is called periodically to free any zombie objects
+ * which are attached to this context.
+ */
+void
+st_context_free_zombie_objects(struct st_context *st)
+{
+ free_zombie_sampler_views(st);
+}
+
+
static void
st_destroy_context_priv(struct st_context *st, bool destroy_pipe)
{
@@ -568,6 +642,9 @@
Re: [Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
On Fri, Mar 15, 2019 at 3:46 PM Ilia Mirkin wrote: > > On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig wrote: > > > > > This is needed if you can only handle point sprites on certain > > > varyings but not others. This is the case for nv30- and nvc0-based > > > GPUs, which is why the cap was introduced. > > > > > > If your GPU does not have such restrictions, you can safely remove the cap. > > > > Ah-ha, I see, thank you. > > > > I can't handle point sprites on any varyings (they all have to get > > lowered to gl_PointCoord), so.. :) > > Yeah, that's not extremely surprising. Point sprites weren't a thing > in GLES 1, and only available as gl_PointCoord in GLES 2. With GL 1.x > + multitexture, you can have up to 8 tex coords used in your fragment > pipeline, and so need a fixed-function way of setting them to point > coords when drawing points. Hence the current TEXCOORD semantics of > just bumping generic varyings by 8, so that we can be sure that any > shaders with true gl_TexCoord[] usage get the low 8 varyings assigned > (and which, on nvc0+ go through "special" shader outputs, subject to > the replacement). > > Note that e.g. Adreno A3xx+ is capable of doing the replacement > everywhere, despite being a GLES-targeted GPU. So it's not out of the > realm of possibility that you just haven't figured out the full > mechanism for doing it yet. Can you replace more than one varying and output multiple points vertex shader, or something crazy like that? On Mali gl_PointCoord is just a normal varying whose descriptor points to a special point-coord buffer that gets fed to the tiler, so we should be able to make an arbitrary varying "turn into" gl_PointCoord just by changing its descriptor at draw time. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] Mesa 18.3.5 release candidate
Hello list, The candidate for the Mesa 18.3.5 is now available. Currently we have: - 67 queued - 0 nominated (outstanding) - and 6 rejected patches Take a look at section "Mesa stable queue" for more information. Testing reports/general approval Any testing reports (or general approval of the state of the branch) will be greatly appreciated. The plan is to have 18.3.5 this Saturday (16 March 2019), around or shortly after 16 GMT. If you have any questions or suggestions - be that about the current patch queue or otherwise, please let me know. Trivial merge conflicts --- commit 41d78f9ed7ebbdd8bd10268635e9bc883a8ffc33 Author: Jason Ekstrand intel/fs: Bail in optimize_extract_to_float if we have modifiers (cherry picked from commit 367b0ede4d9115aba772d6e46ec73642761f7ff6) commit 6fb3cec8bc55d140e12c5161ad5e404baa698e6f Author: Jason Ekstrand nir/xfb: Work in terms of components rather than slots (cherry picked from commit 558c3145045f1c6da8bddb31ed77a418ab27f2f9) commit e8d3c8458291e02459146bb458547baec93d2efe Author: Bas Nieuwenhuizen radv: Fix float16 interpolation set up. (cherry picked from commit a1fdd4a4a73604469b6204a56457b08f8ae4a948) commit 3c4cc070c12ca8dcb287dcb10bff32ae19913d32 Author: Samuel Pitoiset radv: fix clearing attachments in secondary command buffers (cherry picked from commit 5671f38085216caf2cbf221a9fcda08b7571a762) commit 3c4cc070c12ca8dcb287dcb10bff32ae19913d32 Author: Samuel Pitoiset radv: fix clearing attachments in secondary command buffers (cherry picked from commit 5671f38085216caf2cbf221a9fcda08b7571a762) commit 079c124bcbc9231ef2c5bd9b465f0241902412cd Author: Samuel Pitoiset radv: properly align the fence and EOP bug VA on GFX9 (cherry picked from commit c2a148692b4d728e481b60a503e21931f9cf43f0) commit 8448ece46090c1b387640b244959f1d45b23a764 Author: Ian Romanick intel/fs: nir_op_extract_i8 extracts a byte, not a word (cherry picked from commit 4aaf139ea4cc7c4703e1906e0074f87f76c8e4cc) commit 81107c96e600277ac0db8216d99c2ec1b7699642 Author: Tapani Pälli anv: destroy descriptor sets when pool gets destroyed (cherry picked from commit 105002bd2d6173b24f6955c22340b5bc77e029fa) Cheers, Emil Mesa stable queue - Queued (67) === Alok Hota (1): swr/rast: bypass size limit for non-sampled textures Andrii Simiklit (1): i965: re-emit index buffer state on a reset option change. Axel Davy (2): st/nine: Ignore window size if error st/nine: Ignore multisample quality level if no ms Bas Nieuwenhuizen (4): radv: Sync ETC2 whitelisted devices. radv: Fix float16 interpolation set up. radv: Allow interpolation on non-float types. radv: Interpolate less aggressively. Carlos Garnacho (1): wayland/egl: Ensure EGL surface is resized on DRI update_buffers() Danylo Piliaiev (1): glsl/linker: Fix unmatched TCS outputs being reduced to local variable David Shao (1): meson: ensure that xmlpool_options.h is generated for gallium targets that need it Eleni Maria Stea (1): i965: fixed clamping in set_scissor_bits when the y is flipped Emil Velikov (6): docs: add sha256 checksums for 18.3.4 meson: egl: correctly manage loader/xmlconfig cherry-ignore: add 19.0 only anv/push buffer nominations cherry-ignore: add gitlab-ci fixup commit cherry-ignore: ignore glsl_types memory cleanup patch cherry-ignore: add explicit 19.0 performance optimisations Eric Engestrom (1): egl: fix libdrm-less builds Francisco Jerez (1): intel/fs: Implement extended strides greater than 4 for IR source regions. Ian Romanick (2): intel/fs: nir_op_extract_i8 extracts a byte, not a word intel/fs: Fix extract_u8 of an odd byte from a 64-bit integer Ilia Mirkin (1): glsl: fix recording of variables for XFB in TCS shaders Jason Ekstrand (10): intel/fs: Bail in optimize_extract_to_float if we have modifiers compiler/types: Add a contains_64bit helper nir/xfb: Properly align 64-bit values nir/xfb: Work in terms of components rather than slots nir/xfb: Handle compact arrays in gather_xfb_info anv: Count surfaces for non-YCbCr images in GetDescriptorSetLayoutSupport spirv: OpImageQueryLod requires a sampler spirv: Pull offset/stride from the pointer for OpArrayLength glsl/list: Add a list variant of insert_after glsl/lower_vector_derefs: Don't use a temporary for TCS outputs Jose Maria Casanova Crespo (1): glsl: TCS outputs can not be transform feedback candidates on GLES José Fonseca (1): scons: Workaround failures with MSVC when using SCons 3.0.[2-4]. Juan A. Suarez Romero (3): genxml: add missing field values for 3DSTATE_SF anv: advertise 8 subpixel precision bits anv: destroy descriptor sets when pool gets
Re: [Mesa-dev] [Mesa-stable] [PATCH 2/3] glsl: TCS outputs can not be transform feedback candidates on GLES
On Thu, 14 Mar 2019 at 10:41, Chema Casanova wrote: > > On 13/3/19 23:17, Emil Velikov wrote: > > Hi Jose, > > > > On Wed, 21 Nov 2018 at 18:45, Jose Maria Casanova Crespo > > wrote: > >> > >> Fixes: > >> KHR-GLES*.core.tessellation_shader.single.xfb_captures_data_from_correct_stage > >> > > This and the follow-up patch "glsl: fix recording of variables for XFB > > in TCS shaders" are explicitly marked as 19.0 only. > > As such I've omitted them from 18.3, let me know if you prefer to include > > them. > > I've checked and both patches apply clearly on 18.3 and they fix the CTS > failure there. So I think it is useful to include them. > > Thanks for checking, > Ack, picked them up. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig wrote: > > > This is needed if you can only handle point sprites on certain > > varyings but not others. This is the case for nv30- and nvc0-based > > GPUs, which is why the cap was introduced. > > > > If your GPU does not have such restrictions, you can safely remove the cap. > > Ah-ha, I see, thank you. > > I can't handle point sprites on any varyings (they all have to get > lowered to gl_PointCoord), so.. :) Yeah, that's not extremely surprising. Point sprites weren't a thing in GLES 1, and only available as gl_PointCoord in GLES 2. With GL 1.x + multitexture, you can have up to 8 tex coords used in your fragment pipeline, and so need a fixed-function way of setting them to point coords when drawing points. Hence the current TEXCOORD semantics of just bumping generic varyings by 8, so that we can be sure that any shaders with true gl_TexCoord[] usage get the low 8 varyings assigned (and which, on nvc0+ go through "special" shader outputs, subject to the replacement). Note that e.g. Adreno A3xx+ is capable of doing the replacement everywhere, despite being a GLES-targeted GPU. So it's not out of the realm of possibility that you just haven't figured out the full mechanism for doing it yet. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] panfrost: Always shadow vertex elements buffers
There is no BO tracking for vertex buffers yet, so it is not safe to
directly map even when we can according to alignment restrictions. For
now, always create a shadow buffer.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index b6cf5302cae..a255e09b886 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -691,7 +691,10 @@ panfrost_emit_vertex_data(struct panfrost_context *ctx)
mali_ptr effective_address = (rsrc->bo->gpu[0] +
buf->buffer_offset);
-if (effective_address & 0x3F) {
+/* Due to lack of BO waits and such, it's not safe to direct
+ * map ever yet, so always do a shadow buffer */
+
+if (/*effective_address & 0x3F*/1) {
attrs[i].elements = panfrost_upload_transient(ctx,
rsrc->bo->cpu[0] + buf->buffer_offset, attrs[i].size) | 1;
} else {
attrs[i].elements = effective_address | 1;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
> This is needed if you can only handle point sprites on certain > varyings but not others. This is the case for nv30- and nvc0-based > GPUs, which is why the cap was introduced. > > If your GPU does not have such restrictions, you can safely remove the cap. Ah-ha, I see, thank you. I can't handle point sprites on any varyings (they all have to get lowered to gl_PointCoord), so.. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: remove sisched hack for talos
Results of my benchmarks are:
3 runs at 1080p:
GFX8: -1%
GFX9: -1.12%
3 runs at 4k:
GFX8: -2%
GFX9: -1.85%
I'm actually not sure if we want to remove it...
On 3/15/19 11:25 AM, Timothy Arceri wrote:
This was added in 8a7d4092d260 but no longer seems to have any
impact on performance.
---
src/amd/vulkan/radv_device.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 9570c15af02..56421dbc74b 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -499,15 +499,7 @@ radv_handle_per_app_options(struct radv_instance *instance,
if (!name)
return;
- if (!strcmp(name, "Talos - Linux - 32bit") ||
- !strcmp(name, "Talos - Linux - 64bit")) {
- if (!(instance->debug_flags & RADV_DEBUG_NO_SISCHED)) {
- /* Force enable LLVM sisched for Talos because it looks
-* safe and it gives few more FPS.
-*/
- instance->perftest_flags |= RADV_PERFTEST_SISCHED;
- }
- } else if (!strcmp(name, "DOOM_VFR")) {
+ if (!strcmp(name, "DOOM_VFR")) {
/* Work around a Doom VFR game bug */
instance->debug_flags |= RADV_DEBUG_NO_DYNAMIC_BOUNDS;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: remove sisched hack for talos
On Friday, 2019-03-15 21:25:33 +1100, Timothy Arceri wrote:
> This was added in 8a7d4092d260 but no longer seems to have any
> impact on performance.
> ---
> src/amd/vulkan/radv_device.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 9570c15af02..56421dbc74b 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -499,15 +499,7 @@ radv_handle_per_app_options(struct radv_instance
> *instance,
> if (!name)
> return;
>
> - if (!strcmp(name, "Talos - Linux - 32bit") ||
> - !strcmp(name, "Talos - Linux - 64bit")) {
> - if (!(instance->debug_flags & RADV_DEBUG_NO_SISCHED)) {
RADV_DEBUG_NO_SISCHED is now unused; remove it at the same time?
> - /* Force enable LLVM sisched for Talos because it looks
> - * safe and it gives few more FPS.
> - */
> - instance->perftest_flags |= RADV_PERFTEST_SISCHED;
> - }
> - } else if (!strcmp(name, "DOOM_VFR")) {
> + if (!strcmp(name, "DOOM_VFR")) {
> /* Work around a Doom VFR game bug */
> instance->debug_flags |= RADV_DEBUG_NO_DYNAMIC_BOUNDS;
> }
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110116] Neverball particles are broken (GL_POINT_SPRITE)
https://bugs.freedesktop.org/show_bug.cgi?id=110116 --- Comment #4 from Denis --- update - checked and 18.3.3 mesa version (built from git). Also works fine (HSW). HSW on X (mesa 18.3.4) also doesn't reproduce the issue -- 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 110116] Neverball particles are broken (GL_POINT_SPRITE)
https://bugs.freedesktop.org/show_bug.cgi?id=110116 --- Comment #3 from Denis --- hi, I also checked on KBL and HSW. Don't see this issue (KBL was launched under X, mesa-git from master, for HSW I installed gnome and launched under wayland). GL renderer: Mesa DRI Intel(R) Haswell Mobile GL version: 3.0 Mesa 18.3.4 (From Fedora repository) GPU HD Graphics 4600 kernel 4.20.13-200.fc29.x86_64 [root@localhost mesa]# loginctl show-session 9 -p Type Type=wayland neverball was compiled from source. According to game header, it is also 1.6.0 version. Checked and LIBGL_ALWAYS_SOFTWARE, also works fine. Will check 18.3.3, mentioned by you -- 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 109354] eglCreateImageKHR should throw a error when called with anything but EGL_NO_CONTEXT
https://bugs.freedesktop.org/show_bug.cgi?id=109354 Eric Engestrom changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |fdo-b...@engestrom.ch |org | Status|NEW |ASSIGNED --- Comment #2 from Eric Engestrom --- Fix here: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/454 But we'll have to wait before actually landing it. -- 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] gallium/docs: clarify set_sampler_views
On Fri, Mar 15, 2019 at 8:21 AM Axel Davy wrote: > > On 15/03/2019 13:12, Rob Clark wrote: > > On Fri, Mar 15, 2019 at 3:49 AM Axel Davy wrote: > > >> To my knowledge, the semantic of set_sampler_views was changed two years > >> ago, and that caused some issues: > >> https://github.com/iXit/Mesa-3D/issues/308 > >> > >> Making drivers consistent (and complete the doc) is a good initiative. > >> > >> My understanding though is that some drivers may want different > >> behaviors in order to reduce overhead. If I understood correctly, > >> radeonsi prefers to minimize view changes to reduce cpu overhead (and > >> thus prefers not to unbind things outside of the set_sampler_views call > >> range), > >> while nouveau prefers to have only what's needed by the call bound for > >> better gpu performance. I think both are happy with the current code, > >> because the latter preferred behavior can be emulated in the driver, > >> while it would be more difficult for the former. > > Hmm, but this is at odds with Roland's statement that sampler views > > outside the specified range are unmodified. > > > > If we defined the API such that slots >= start+nr are unbound, then a > > driver could choose not to touch them to minimize CPU overhead. But > > if defined that they are unmodified then the driver cannot silently > > discard them. > > > > BR, > > -R > > > The sampler views outside the specified range are unmodified. > This is compatible with what I said. Nouveau determines the minimum > number of samplers actually needed > by the current shader, and internally unbinds those above (and rebinds > if needed by new shader). > Mmmm, unless there is something subtle that I'm overlooking, I'm not sure that I agree.. nvc0_stage_set_sampler_views() unref's the remaining sampler views. The end result is what you describe, but only because of an implementation detail of how mesa/st works (ie. it rebinds them if needed for a new shader). But as Ilia mentioned, I see the use in differentiating between active and bound. Thas might be a good argument to switch back to my initial docs patch which defined slots >= nr+count as unbound. (otoh, nouveau could just track a bitmask of samplers used by the shader internally, I guess?) BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/docs: clarify set_sampler_views
On Fri, Mar 15, 2019 at 8:21 AM Axel Davy wrote: > This is compatible with what I said. Nouveau determines the minimum > number of samplers actually needed > by the current shader, and internally unbinds those above (and rebinds > if needed by new shader). The things nouveau does today aren't necessarily the best thought out things -- it's mostly this way because it's always been that way and there's been no reason to change it. Also the (usage of the) API for set_sampler_views changed underneath nouveau a while back, and nouveau hasn't been adjusted for the new world, leading to occasional issues (although most seem to have been fixed by adjusting set_samplers). It's important to know what's active though, since that means fewer buffers to "bind" to the draw (i.e. have to be in vram/etc), fewer buffers to wait on, fewer texture slots to flush out if there's coherency things going on. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/docs: clarify set_sampler_views
On 15/03/2019 13:12, Rob Clark wrote: On Fri, Mar 15, 2019 at 3:49 AM Axel Davy wrote: On 15/03/2019 03:12, Rob Clark wrote: On Thu, Mar 14, 2019 at 9:58 PM Roland Scheidegger wrote: Am 15.03.19 um 02:18 schrieb Rob Clark: On Thu, Mar 14, 2019 at 8:28 PM Roland Scheidegger wrote: Am 14.03.19 um 22:06 schrieb Rob Clark: On Thu, Mar 14, 2019 at 3:58 PM Roland Scheidegger wrote: Am 14.03.19 um 14:13 schrieb Rob Clark: On Tue, Mar 12, 2019 at 1:59 PM Roland Scheidegger wrote: Am 12.03.19 um 16:16 schrieb Rob Clark: This previously was not called out clearly, but based on a survey of the code, it seems the expected behavior is to release the reference to any sampler views beyond the new range being bound. That isn't really true. This was designed to work like d3d10, where other views are unmodified. The cso code will actually unset all views which previously were set and are above the num_views in the call (this wouldn't be necessary if the pipe function itself would work like this). However, it will only do this for fragment textures, and pass through the parameters unmodified otherwise. Which means behavior might not be very consistent for the different stages... Any opinion about whether views==NULL should be allowed? Currently I have something like: diff --git a/src/gallium/docs/source/context.rst b/src/gallium/docs/source/context.rst index f89d9e1005e..06d30bfb38b 100644 --- a/src/gallium/docs/source/context.rst +++ b/src/gallium/docs/source/context.rst @@ -143,6 +143,11 @@ to the array index which is used for sampling. to a respective sampler view and releases a reference to the previous sampler view. + Sampler views outside of ``[start_slot, start_slot + num_views)`` are + unmodified. If ``views`` is NULL, the behavior is the same as if + ``views[n]`` was NULL for the entire range, ie. releasing the reference + for all the sampler views in the specified range. + * ``create_sampler_view`` creates a new sampler view. ``texture`` is associated with the sampler view which results in sampler view holding a reference to the texture. Format specified in template must be compatible But going thru the other drivers, a lot of them also don't handle the views==NULL case. This case doesn't seem to come up with mesa/st, but does with XA and nine, and some of the test code. I think this should be illegal. As you've noted some drivers can't handle it, and I don't see a particularly good reason to allow it. Well I guess it trades some complexity in state trackers with some complexity in drivers... fwiw, going with the idea that it should be legal, I fixed that in the drivers that didn't handle it in: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F449&data=02%7C01%7Csroland%40vmware.com%7C2fe81dea2d9d4de1974f08d6a8e42caa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636882095286989477&sdata=qd1z5iv8dvt2z16ZlT2OPngoDGofvCM%2F%2F0hsddqAbO4%3D&reserved=0 (planning to send to list, I just pushed a WIP MR to run it thru the CI system) I'm pretty sure both softpipe and llvmpipe would crash too, they dereference this without checking if it's null. So effectively all drivers but one thought it was illegal? I still see no point in allowing it (or rather, changing this to be allowed - per se there's nothing really wrong with this to be allowed). That said, it appears that set_shader_images and set_shader_buffers allow it, so there's some precedence for this. hmm, I'd assumed llvmpipe was used with xa somewhere so I didn't really look at it and assumed it handled this.. xa only sets fragment sampler views, and those only through cso. cso will turn this into a non-null views parameter. (cso itself also won't tolerate null views parameter, unless the count is zero, but that should be alright since its semantics are that it will unbind all views above the count - well for fragment sampler views...) nine also sets vertex sampler views through cso, which will get passed through to drivers as-is. However, the NULL views used there is always accompanied by a 0 count, so for drivers interpreting things as range to change rather than unbind things outside it is a natural no-op, and they'll never even look at views in their loop. (Of course, that's not quite what nine actually wanted to do...) And yes things are very inconsistent when passed through cso (for drivers interpreting it as range to change), since cso will unbind the views above count for fragment shader views explicitly, but won't do anything for any other shader stage... but as you mentioned below, if set_shader_buffers and set_shader_images allow null, for consistency (and since I'm already fixing up a bunch of set_shader_buffer implementations, so handling the ==NULL case isn't a big deal), I'd lean towards allowing NULL. I guess if we are going to do API cleanup, then consistency is a useful thing.. I can check llvmpipe and softp
Re: [Mesa-dev] [PATCH] gallium/docs: clarify set_sampler_views
On Fri, Mar 15, 2019 at 3:49 AM Axel Davy wrote: > > On 15/03/2019 03:12, Rob Clark wrote: > > On Thu, Mar 14, 2019 at 9:58 PM Roland Scheidegger > > wrote: > >> Am 15.03.19 um 02:18 schrieb Rob Clark: > >>> On Thu, Mar 14, 2019 at 8:28 PM Roland Scheidegger > >>> wrote: > Am 14.03.19 um 22:06 schrieb Rob Clark: > > On Thu, Mar 14, 2019 at 3:58 PM Roland Scheidegger > > wrote: > >> Am 14.03.19 um 14:13 schrieb Rob Clark: > >>> On Tue, Mar 12, 2019 at 1:59 PM Roland Scheidegger > >>> wrote: > Am 12.03.19 um 16:16 schrieb Rob Clark: > > This previously was not called out clearly, but based on a survey > > of the > > code, it seems the expected behavior is to release the reference to > > any > > sampler views beyond the new range being bound. > That isn't really true. This was designed to work like d3d10, where > other views are unmodified. > The cso code will actually unset all views which previously were set > and > are above the num_views in the call (this wouldn't be necessary if > the > pipe function itself would work like this). > However, it will only do this for fragment textures, and pass through > the parameters unmodified otherwise. Which means behavior might not > be > very consistent for the different stages... > >>> Any opinion about whether views==NULL should be allowed? Currently I > >>> have something like: > >>> > >>> > >>> diff --git a/src/gallium/docs/source/context.rst > >>> b/src/gallium/docs/source/context.rst > >>> index f89d9e1005e..06d30bfb38b 100644 > >>> --- a/src/gallium/docs/source/context.rst > >>> +++ b/src/gallium/docs/source/context.rst > >>> @@ -143,6 +143,11 @@ to the array index which is used for sampling. > >>> to a respective sampler view and releases a reference to the > >>> previous > >>> sampler view. > >>> > >>> + Sampler views outside of ``[start_slot, start_slot + num_views)`` > >>> are > >>> + unmodified. If ``views`` is NULL, the behavior is the same as if > >>> + ``views[n]`` was NULL for the entire range, ie. releasing the > >>> reference > >>> + for all the sampler views in the specified range. > >>> + > >>> * ``create_sampler_view`` creates a new sampler view. ``texture`` > >>> is associated > >>> with the sampler view which results in sampler view holding a > >>> reference > >>> to the texture. Format specified in template must be compatible > >>> > >>> > >>> But going thru the other drivers, a lot of them also don't handle the > >>> views==NULL case. This case doesn't seem to come up with mesa/st, but > >>> does with XA and nine, and some of the test code. > >> I think this should be illegal. As you've noted some drivers can't > >> handle it, and I don't see a particularly good reason to allow it. Well > >> I guess it trades some complexity in state trackers with some > >> complexity > >> in drivers... > > fwiw, going with the idea that it should be legal, I fixed that in the > > drivers that didn't handle it in: > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F449&data=02%7C01%7Csroland%40vmware.com%7C2fe81dea2d9d4de1974f08d6a8e42caa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636882095286989477&sdata=qd1z5iv8dvt2z16ZlT2OPngoDGofvCM%2F%2F0hsddqAbO4%3D&reserved=0 > > > > (planning to send to list, I just pushed a WIP MR to run it thru the CI > > system) > I'm pretty sure both softpipe and llvmpipe would crash too, they > dereference this without checking if it's null. > So effectively all drivers but one thought it was illegal? > I still see no point in allowing it (or rather, changing this to be > allowed - per se there's nothing really wrong with this to be allowed). > That said, it appears that set_shader_images and set_shader_buffers > allow it, so there's some precedence for this. > >>> hmm, I'd assumed llvmpipe was used with xa somewhere so I didn't > >>> really look at it and assumed it handled this.. > >> xa only sets fragment sampler views, and those only through cso. > >> cso will turn this into a non-null views parameter. > >> (cso itself also won't tolerate null views parameter, unless the count > >> is zero, but that should be alright since its semantics are that it will > >> unbind all views above the count - well for fragment sampler views...) > >> nine also sets vertex sampler views through cso, which will get passed > >> through to drivers as-is. However, the NULL views used there is always > >> accompanied by a 0 count, so for drivers interpreting things as range to > >> change rather than unbind things outside it is a natural no-o
Re: [Mesa-dev] MESA_Build_ERROR
> > /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c: In > function 'memfd_create': > /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19: > error: 'SYS_memfd_create' undeclared (first use in this function) > /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19: > note: each undeclared identifier is reported only once for each function it > appears in What is your kernel (uname -a)? Seems memfd_create is supported from 3.17 And just for case what is content of file '/usr/include/bits/syscall.h'? On Fri, Mar 15, 2019 at 10:26 AM Milav wrote: > Hello Sir, > > This Is Milav Soni From TEQ DILIGENT. > > I cross compiled the xserver using jhbuild. > > I follow the following link. > > https://www.x.org/wiki/CrossCompilingXorg/ > > But when it comes in mesa configuration, it gives following error. > > > /*--error-*/ > > copying selected object files to avoid basename conflicts... > CXXLDglsl_compiler > make[4]: Leaving directory > `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/compiler' > make[3]: Leaving directory > `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/compiler' > Making all in intel > make[3]: Entering directory > `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel' > make all-am > make[4]: Entering directory > `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel' > CC isl/libisl_tiled_memcpy_sse41_la-isl_tiled_memcpy_sse41.lo > CC tools/tools_aubinator-aub_mem.o > /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c: In > function 'memfd_create': > /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19: > error: 'SYS_memfd_create' undeclared (first use in this function) > /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19: > note: each undeclared identifier is reported only once for each function it > appears in > make[4]: *** [tools/tools_aubinator-aub_mem.o] Error 1 > make[4]: *** Waiting for unfinished jobs > *arm-cortexa8-linux-gnueabihf-gcc: error: unrecognized command line option > '-msse4.1'* > make[4]: *** [isl/libisl_tiled_memcpy_sse41_la-isl_tiled_memcpy_sse41.lo] > Error 1 > make[4]: Leaving directory > `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel' > make[3]: *** [all] Error 2 > make[3]: Leaving directory > `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src' > make[1]: *** [all] Error 2 > make[1]: Leaving directory > `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src' > make: *** [all-recursive] Error 1 > *** Error during phase build of mesa-mesa: ## Error running make > -j 2 *** [37/38] > > [1] Rerun phase build > [2] Ignore error and continue to install > [3] Give up on module > [4] Start shell > [5] Reload configuration > [6] Go to phase "wipe directory and start over" > [7] Go to phase "configure" > [8] Go to phase "clean" > [9] Go to phase "distclean" > choice: ^X^CInterrupted > teqdiligent@ubuntu:~$ > > > /*---*/ > > I use following configuration. > > $/home/teqdiligent/sources/xorg/git/mesa/mesa/autogen.sh --prefix > /home/teqdiligent/jhbuild/wega_build/usr/local --disable-Werror > --enable-autotools --enable-xa --disable-static --disable-dri2 > --with-driver=dri --cache-file=~/sources/xorg/git/autoconf-cache > --with-log-dir=/var/log --with-mesa-source=~/sources/xorg/git/mesa > --enable-malloc0returnsnull --build=x86_64-unknown-linux-gnu > --host=arm-cortexa8-linux-gnueabihf --target=arm-cortexa8-linux-gnueabihf > AR="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-ar" > RANLIB="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-ranlib" > STRIP="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-strip" > AS="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-as" > OBJDUMP="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-objdump" > NM="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-nm" > > > > please help me to sort out this problem. > > Looking forward hearing from you. > > Regards > > Milav Soni > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Sergii Romantsov | Senior Software Engineer GlobalLogic Inc. M +3.8098.660.7538 S sromerson www.glo
Re: [Mesa-dev] [PATCH 3/5] panfrost: Disable PIPE_CAP_TGSI_TEXCOORD
This is needed if you can only handle point sprites on certain varyings but not others. This is the case for nv30- and nvc0-based GPUs, which is why the cap was introduced. If your GPU does not have such restrictions, you can safely remove the cap. -ilia On Fri, Mar 15, 2019 at 12:25 AM Alyssa Rosenzweig wrote: > > I don't know why this was on to begin with...? > > Signed-off-by: Alyssa Rosenzweig > --- > src/gallium/drivers/panfrost/pan_screen.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/src/gallium/drivers/panfrost/pan_screen.c > b/src/gallium/drivers/panfrost/pan_screen.c > index 9cd65ca8ff8..9672048bca8 100644 > --- a/src/gallium/drivers/panfrost/pan_screen.c > +++ b/src/gallium/drivers/panfrost/pan_screen.c > @@ -195,9 +195,6 @@ panfrost_get_param(struct pipe_screen *screen, enum > pipe_cap param) > case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT: > return 0; > > -case PIPE_CAP_TGSI_TEXCOORD: > -return 1; /* XXX: What should this me exactly? */ > - > case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER: > return 0; > > -- > 2.20.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110116] Neverball particles are broken (GL_POINT_SPRITE)
https://bugs.freedesktop.org/show_bug.cgi?id=110116 --- Comment #2 from Ilia Mirkin --- Seems to work with llvmpipe on 19.0-rc7. (And with nouveau on multiple GPU generations.) -- 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] MESA_Build_ERROR
On 3/14/19 1:26 PM, Milav wrote: Hello Sir, This Is Milav Soni From TEQ DILIGENT. I cross compiled the xserver using jhbuild. I follow the following link. https://www.x.org/wiki/CrossCompilingXorg/ But when it comes in mesa configuration, it gives following error. /*--error-*/ copying selected object files to avoid basename conflicts... CXXLD glsl_compiler make[4]: Leaving directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/compiler' make[3]: Leaving directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/compiler' Making all in intel make[3]: Entering directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel' make all-am make[4]: Entering directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel' CC isl/libisl_tiled_memcpy_sse41_la-isl_tiled_memcpy_sse41.lo CC tools/tools_aubinator-aub_mem.o /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c: In function 'memfd_create': /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19: error: 'SYS_memfd_create' undeclared (first use in this function) /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [tools/tools_aubinator-aub_mem.o] Error 1 make[4]: *** Waiting for unfinished jobs *arm-cortexa8-linux-gnueabihf-gcc: error: unrecognized command line option '-msse4.1'* What comes to sse41 error, it looks like we properly check for support in configure.ac but ignore the result (SSE41_SUPPORTED) in Makefile.isl.am. This change should fix it: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/451 (meson build handles this correctly) make[4]: *** [isl/libisl_tiled_memcpy_sse41_la-isl_tiled_memcpy_sse41.lo] Error 1 make[4]: Leaving directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src' make: *** [all-recursive] Error 1 *** Error during phase build of mesa-mesa: ## Error running make -j 2 *** [37/38] [1] Rerun phase build [2] Ignore error and continue to install [3] Give up on module [4] Start shell [5] Reload configuration [6] Go to phase "wipe directory and start over" [7] Go to phase "configure" [8] Go to phase "clean" [9] Go to phase "distclean" choice: ^X^CInterrupted teqdiligent@ubuntu:~$ /*---*/ I use following configuration. $/home/teqdiligent/sources/xorg/git/mesa/mesa/autogen.sh --prefix /home/teqdiligent/jhbuild/wega_build/usr/local --disable-Werror --enable-autotools --enable-xa --disable-static --disable-dri2 --with-driver=dri --cache-file=~/sources/xorg/git/autoconf-cache --with-log-dir=/var/log --with-mesa-source=~/sources/xorg/git/mesa --enable-malloc0returnsnull --build=x86_64-unknown-linux-gnu --host=arm-cortexa8-linux-gnueabihf --target=arm-cortexa8-linux-gnueabihf AR="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-ar" RANLIB="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-ranlib" STRIP="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-strip" AS="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-as" OBJDUMP="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-objdump" NM="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-nm" please help me to sort out this problem. Looking forward hearing from you. Regards Milav Soni ___ 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: remove sisched hack for talos
This was added in 8a7d4092d260 but no longer seems to have any
impact on performance.
---
src/amd/vulkan/radv_device.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 9570c15af02..56421dbc74b 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -499,15 +499,7 @@ radv_handle_per_app_options(struct radv_instance *instance,
if (!name)
return;
- if (!strcmp(name, "Talos - Linux - 32bit") ||
- !strcmp(name, "Talos - Linux - 64bit")) {
- if (!(instance->debug_flags & RADV_DEBUG_NO_SISCHED)) {
- /* Force enable LLVM sisched for Talos because it looks
-* safe and it gives few more FPS.
-*/
- instance->perftest_flags |= RADV_PERFTEST_SISCHED;
- }
- } else if (!strcmp(name, "DOOM_VFR")) {
+ if (!strcmp(name, "DOOM_VFR")) {
/* Work around a Doom VFR game bug */
instance->debug_flags |= RADV_DEBUG_NO_DYNAMIC_BOUNDS;
}
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v5 08/11] anv: Added support for dynamic sample locations
On Thu, 14 Mar 2019 20:00:45 -0500
Jason Ekstrand wrote:
> >
> > extern const struct anv_dynamic_state default_dynamic_state;
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> > b/src/intel/vulkan/genX_cmd_buffer.c
> > index 7687507e6b7..5d2b17cf8ae 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -2796,6 +2796,17 @@ genX(cmd_buffer_flush_state)(struct
> > anv_cmd_buffer *cmd_buffer)
> >ANV_CMD_DIRTY_RENDER_TARGETS))
> >gen7_cmd_buffer_emit_scissor(cmd_buffer);
> >
> > + if (cmd_buffer->state.gfx.dynamic.sample_locations.valid) {
> > + uint32_t samples =
> > cmd_buffer->state.gfx.dynamic.sample_locations.samples;
> > + const VkSampleLocationEXT *locations =
> > + cmd_buffer->state.gfx.dynamic.sample_locations.locations;
> > + genX(emit_multisample)(&cmd_buffer->batch, samples,
> > locations); +#if GEN_GEN >= 8
> > + genX(emit_sample_pattern)(&cmd_buffer->batch, samples,
> > locations); +#endif
> > + cmd_buffer->state.gfx.dynamic.sample_locations.valid = false;
> >
>
> I'm not sure this is actually going to be correct. With dynamic
> state, you're required to set it before you use it. With pipeline
> state, it gets set every time the pipeline is bound. Effectively,
> the pipeline state is a big bag of dynamic state. With both of
> these, however, there are no defaults and you're required to bind a
> pipeline containing the state or explicitly set it on the command
> buffer before it gets used. VK_EXT_sample_locations is different
> though because it does have a default. So the question I'm coming
> around to is: When does the default get applied? The only sensible
> thing I can think of is at the top of the command buffer or maybe the
> top of the subpass. If this is the case, then we need to emit sample
> positions at the start of every subpass. Does the spec talk about
> this at all?
>
> --Jason
>
> >
Hi Jason,
If I understand well (sorry if I misunderstood), you want to make sure
that in every case we will have locations set either the default or
custom, and that we emit the default locations when a pipeline (or
subpass, but we don't have locations per subpass, only per pipeline) is
bound after a pipeline for which custom locations were set dynamically?
I didn't find any reference to this problem in the spec, the solution I
thought myself was to use the variable bool custom_locations to decide
if we are going to emit custom locations or the default in
emit_ms_state and always emit some locations when the extension is
enabled.
So:
When the emit_ms_state is called for each new pipeline at rasterization,
we check if 1- the custom locations are TRUE and if 2- the flag for the
dynamic locations (VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_EXT) is set to
false. If both apply we emit the custom locations. In every other case
(when locations_enabled are false, or when dynamic state is true) we
emit the default locations.
This way, in the non-dynamic case (no VK_DYNAMIC_STATE... set):
If a pipeline has the locations enabled, we emit the custom.
If a pipeline doesn't have locations enabled, we emit the default.
So, we always have some locations set for the pipeline.
Similarly in the dynamic case:
When the user sets locations with vkCmdSetSampleLocations we use these
locations.
As we have locations per pipeline not per subpass (variable sample
locations = false) next pipeline that will be bound will have either
custom locations (from emit_ms_state) or the default (emitted by
the emit_ms_state), unless if the DYNAMIC_STATE flag is set and the user
calls the vkCmdSetSampleLocationsEXT again to override the default,
that we'll set the user's.
So, again we'll always have some locations set (and these will be the
default when the user doesn't chain the locations info struct, or
disables the locations, or sets the DYNAMIC flag but doesn't override
the locations with the VkCmdSetLocationsEXT).
So, I think we are fine.
If we didn't emit always the default pipelines created after setting
locations with any of the 2 possible ways would have garbage locations
set.
I verified this would happen like that: If you don't make use of the
bool custom_locations and run all the multisample.* vulkancts tests at
once, you will notice that tests that don't set the sample locations in
the pipeline and run after some tests that set them fail. I had spotted
the following failures:
dEQP-VK.glsl.builtin_var.fragcoord_msaa.*
dEQP-VK.pipeline.multisample.sample_mask_with_depth_test.samples_.*
dEQP-VK.pipeline.multisample.sample_mask_with_depth_test.samples_.*_post_depth_coverage
dEQP-VK.pipeline.multisample_interpolation.sample_interpolate_at_distinct_values.128_128_1.samples_.*
dEQP-VK.pipeline.multisample_interpolation.sample_interpolate_at_distinct_values.137_191_1.samples_.*
dEQP-VK.pipeline.multisample_interpolation.sample_qualifier_distinct_values.128_128_1.samples_.*
dEQP-VK.pip
[Mesa-dev] [PATCH] radv: always load 3 channels for formats that need to be shuffled
This fixes a rendering issue with Hellblade and DXVK.
Fixes: a66b186bebf ("radv: use typed buffer loads for vertex input fetches")
Reported-by: Philip Rebohle
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_nir_to_llvm.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index dbe4be907ec..58a3cf18fe1 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -2166,6 +2166,13 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
unsigned attrib_offset =
ctx->options->key.vs.vertex_attribute_offsets[attrib_index];
unsigned attrib_stride =
ctx->options->key.vs.vertex_attribute_strides[attrib_index];
+ if (ctx->options->key.vs.post_shuffle & (1 << attrib_index)) {
+ /* Always load, at least, 3 channels for formats that
+* need to be shuffled because X<->Z.
+*/
+ num_channels = MAX2(num_channels, 3);
+ }
+
if (attrib_stride != 0 && attrib_offset > attrib_stride) {
LLVMValueRef buffer_offset =
LLVMConstInt(ctx->ac.i32,
@@ -2190,15 +2197,13 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
false, false, true);
if (ctx->options->key.vs.post_shuffle & (1 << attrib_index)) {
- if (num_channels > 1) {
- LLVMValueRef c[4];
- c[0] = ac_llvm_extract_elem(&ctx->ac, input, 2);
- c[1] = ac_llvm_extract_elem(&ctx->ac, input, 1);
- c[2] = ac_llvm_extract_elem(&ctx->ac, input, 0);
- c[3] = ac_llvm_extract_elem(&ctx->ac, input, 3);
-
- input = ac_build_gather_values(&ctx->ac, c, 4);
- }
+ LLVMValueRef c[4];
+ c[0] = ac_llvm_extract_elem(&ctx->ac, input, 2);
+ c[1] = ac_llvm_extract_elem(&ctx->ac, input, 1);
+ c[2] = ac_llvm_extract_elem(&ctx->ac, input, 0);
+ c[3] = ac_llvm_extract_elem(&ctx->ac, input, 3);
+
+ input = ac_build_gather_values(&ctx->ac, c, 4);
}
input = radv_fixup_vertex_input_fetches(ctx, input,
num_channels,
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] MESA_Build_ERROR
Hello Sir, This Is Milav Soni From TEQ DILIGENT. I cross compiled the xserver using jhbuild. I follow the following link. https://www.x.org/wiki/CrossCompilingXorg/ But when it comes in mesa configuration, it gives following error. /*--error-*/ copying selected object files to avoid basename conflicts... CXXLD glsl_compiler make[4]: Leaving directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/compiler' make[3]: Leaving directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/compiler' Making all in intel make[3]: Entering directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel' make all-am make[4]: Entering directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel' CC isl/libisl_tiled_memcpy_sse41_la-isl_tiled_memcpy_sse41.lo CC tools/tools_aubinator-aub_mem.o /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c: In function 'memfd_create': /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19: error: 'SYS_memfd_create' undeclared (first use in this function) /home/teqdiligent/sources/xorg/git/mesa/mesa/src/intel/tools/aub_mem.c:37:19: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [tools/tools_aubinator-aub_mem.o] Error 1 make[4]: *** Waiting for unfinished jobs *arm-cortexa8-linux-gnueabihf-gcc: error: unrecognized command line option '-msse4.1'* make[4]: *** [isl/libisl_tiled_memcpy_sse41_la-isl_tiled_memcpy_sse41.lo] Error 1 make[4]: Leaving directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src/intel' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/teqdiligent/.cache/jhbuild/build/mesa/mesa/src' make: *** [all-recursive] Error 1 *** Error during phase build of mesa-mesa: ## Error running make -j 2 *** [37/38] [1] Rerun phase build [2] Ignore error and continue to install [3] Give up on module [4] Start shell [5] Reload configuration [6] Go to phase "wipe directory and start over" [7] Go to phase "configure" [8] Go to phase "clean" [9] Go to phase "distclean" choice: ^X^CInterrupted teqdiligent@ubuntu:~$ /*---*/ I use following configuration. $/home/teqdiligent/sources/xorg/git/mesa/mesa/autogen.sh --prefix /home/teqdiligent/jhbuild/wega_build/usr/local --disable-Werror --enable-autotools --enable-xa --disable-static --disable-dri2 --with-driver=dri --cache-file=~/sources/xorg/git/autoconf-cache --with-log-dir=/var/log --with-mesa-source=~/sources/xorg/git/mesa --enable-malloc0returnsnull --build=x86_64-unknown-linux-gnu --host=arm-cortexa8-linux-gnueabihf --target=arm-cortexa8-linux-gnueabihf AR="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-ar" RANLIB="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-ranlib" STRIP="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-strip" AS="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-as" OBJDUMP="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-objdump" NM="/home/teqdiligent/HMI_SCADA/Toolchain/arm-cortexa8-linux-gnueabihf/bin/arm-cortexa8-linux-gnueabihf-nm" please help me to sort out this problem. Looking forward hearing from you. Regards Milav Soni ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/docs: clarify set_sampler_views
On 15/03/2019 03:12, Rob Clark wrote: On Thu, Mar 14, 2019 at 9:58 PM Roland Scheidegger wrote: Am 15.03.19 um 02:18 schrieb Rob Clark: On Thu, Mar 14, 2019 at 8:28 PM Roland Scheidegger wrote: Am 14.03.19 um 22:06 schrieb Rob Clark: On Thu, Mar 14, 2019 at 3:58 PM Roland Scheidegger wrote: Am 14.03.19 um 14:13 schrieb Rob Clark: On Tue, Mar 12, 2019 at 1:59 PM Roland Scheidegger wrote: Am 12.03.19 um 16:16 schrieb Rob Clark: This previously was not called out clearly, but based on a survey of the code, it seems the expected behavior is to release the reference to any sampler views beyond the new range being bound. That isn't really true. This was designed to work like d3d10, where other views are unmodified. The cso code will actually unset all views which previously were set and are above the num_views in the call (this wouldn't be necessary if the pipe function itself would work like this). However, it will only do this for fragment textures, and pass through the parameters unmodified otherwise. Which means behavior might not be very consistent for the different stages... Any opinion about whether views==NULL should be allowed? Currently I have something like: diff --git a/src/gallium/docs/source/context.rst b/src/gallium/docs/source/context.rst index f89d9e1005e..06d30bfb38b 100644 --- a/src/gallium/docs/source/context.rst +++ b/src/gallium/docs/source/context.rst @@ -143,6 +143,11 @@ to the array index which is used for sampling. to a respective sampler view and releases a reference to the previous sampler view. + Sampler views outside of ``[start_slot, start_slot + num_views)`` are + unmodified. If ``views`` is NULL, the behavior is the same as if + ``views[n]`` was NULL for the entire range, ie. releasing the reference + for all the sampler views in the specified range. + * ``create_sampler_view`` creates a new sampler view. ``texture`` is associated with the sampler view which results in sampler view holding a reference to the texture. Format specified in template must be compatible But going thru the other drivers, a lot of them also don't handle the views==NULL case. This case doesn't seem to come up with mesa/st, but does with XA and nine, and some of the test code. I think this should be illegal. As you've noted some drivers can't handle it, and I don't see a particularly good reason to allow it. Well I guess it trades some complexity in state trackers with some complexity in drivers... fwiw, going with the idea that it should be legal, I fixed that in the drivers that didn't handle it in: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F449&data=02%7C01%7Csroland%40vmware.com%7C2fe81dea2d9d4de1974f08d6a8e42caa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636882095286989477&sdata=qd1z5iv8dvt2z16ZlT2OPngoDGofvCM%2F%2F0hsddqAbO4%3D&reserved=0 (planning to send to list, I just pushed a WIP MR to run it thru the CI system) I'm pretty sure both softpipe and llvmpipe would crash too, they dereference this without checking if it's null. So effectively all drivers but one thought it was illegal? I still see no point in allowing it (or rather, changing this to be allowed - per se there's nothing really wrong with this to be allowed). That said, it appears that set_shader_images and set_shader_buffers allow it, so there's some precedence for this. hmm, I'd assumed llvmpipe was used with xa somewhere so I didn't really look at it and assumed it handled this.. xa only sets fragment sampler views, and those only through cso. cso will turn this into a non-null views parameter. (cso itself also won't tolerate null views parameter, unless the count is zero, but that should be alright since its semantics are that it will unbind all views above the count - well for fragment sampler views...) nine also sets vertex sampler views through cso, which will get passed through to drivers as-is. However, the NULL views used there is always accompanied by a 0 count, so for drivers interpreting things as range to change rather than unbind things outside it is a natural no-op, and they'll never even look at views in their loop. (Of course, that's not quite what nine actually wanted to do...) And yes things are very inconsistent when passed through cso (for drivers interpreting it as range to change), since cso will unbind the views above count for fragment shader views explicitly, but won't do anything for any other shader stage... but as you mentioned below, if set_shader_buffers and set_shader_images allow null, for consistency (and since I'm already fixing up a bunch of set_shader_buffer implementations, so handling the ==NULL case isn't a big deal), I'd lean towards allowing NULL. I guess if we are going to do API cleanup, then consistency is a useful thing.. I can check llvmpipe and softpipe and add patches to fix them if needed. Yes consistency is a nice goal. I'm just not sure i
