Re: [Mesa-dev] [PATCH v2 8/8] egl: add EGL_platform_device support
Marek, On Tuesday, 2 April 2019 23:07:50 CEST Marek Olšák wrote: > Do you have a branch with patch 7/8 and 8/8? I'm interested in > EGL_EXT_platform_device on radeonsi. You can take a look at the egl-device-4 branch on https://gitlab.freedesktop.org/frohlich/mesa.git I pushed a rebased and slightly changed wip for you. I have also some more tests in my local piglit as well as separate tests/examples that I initially wrote as an example to make use of the extension. But I have to dig out these first... best Mathias > > Thanks, > Marek > > On Wed, Oct 3, 2018 at 4:36 AM Mathias Fröhlich > wrote: > > > Hi Emil, > > > > Ok, thanks for picking that up. > > > > On Tuesday, 2 October 2018 12:23:30 CEST Emil Velikov wrote: > > > On Thu, 20 Sep 2018 at 15:13, Mathias Fröhlich > > > wrote: > > > > > > > > > > > If I replace the above with > > > > > > > > EGLint surface_type = 0; > > > > /* Only advertise pbuffer configs for non swrast devices */ > > > > if (dri2_dpy->image_driver) > > > > surface_type = EGL_PBUFFER_BIT; > > > > > > > > dri2_conf = dri2_add_config(dpy, dri2_dpy->driver_configs[i], > > > >config_count + 1, surface_type, NULL, > > > >visuals[j].rgba_masks); > > > > > > > > then I can easily prohibit the crash that I mentioned when trying to > > > > create a pbuffer surface on the swrast device. > > > > At least I do no longer get a valid pbuffer config from eglChooseConfig > > > > and without that we cannot reach the crashing > > > > dri2_dpy->image_driver->createNewDrawable > > > > call somewhere from eglCreatePbufferSurface anymore. > > > > > > > > Still getting a surface less context on swrast should work... > > > > > > > Issue is that we do not know how to create a "pbuffer only" swrast. > > > > > > Hence one resolves to hacks like the ones we have in > > platform_surfaceless. > > > Effectively pilling hacks upon hacks - see swrast_loader_extensions > > > and "software path w/o DRM.". > > > > > > That said, I'm working on proper solution but since it will take some > > > time to finish/merge I'll drop this and 7/8 for now. > > > > > > That's fine too. > > > > What I wanted to avoid is that people using the extension correctly fail > > with a > > crash in the application when running on mesa. > > Think about it. Thats really bad from an application writers point of view > > as you do all right with checking extensions and that and then the opengl > > stack suddenly crashes. > > > > best > > > > Mathias > > > > > > ___ > > 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 1/3] panfrost: Cleanup some indirection in pan_resource
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 45 ++---
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index 3d93fd0dc4d..f7df1353d68 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -448,36 +448,33 @@ panfrost_tile_texture(struct panfrost_screen *screen,
struct panfrost_resource *
}
static void
-panfrost_unmap_bo(struct panfrost_context *ctx,
- struct pipe_transfer *transfer)
+panfrost_transfer_unmap(struct pipe_context *pctx,
+struct pipe_transfer *transfer)
{
+struct panfrost_context *ctx = pan_context(pctx);
+
+/* Gallium expects writeback here, so we tile */
+
struct panfrost_gtransfer *trans = pan_transfer(transfer);
- struct panfrost_bo *bo = (struct panfrost_bo
*)pan_resource(transfer->resource)->bo;
-if (transfer->usage & PIPE_TRANSFER_WRITE) {
+if (trans->map) {
struct panfrost_resource *prsrc = (struct panfrost_resource *)
transfer->resource;
-
-/* Gallium thinks writeback happens here; instead, this is our
cue to tile */
-if (bo->layout == PAN_AFBC) {
-DBG("Warning: writes to afbc surface can't possibly
work out well for you...\n");
-} else if (bo->layout == PAN_TILED) {
-struct pipe_context *gallium = (struct pipe_context *)
ctx;
-struct panfrost_screen *screen =
pan_screen(gallium->screen);
-assert(transfer->box.depth == 1);
-panfrost_tile_texture(screen, prsrc, trans);
+struct panfrost_bo *bo = prsrc->bo;
+
+if (transfer->usage & PIPE_TRANSFER_WRITE) {
+
+if (bo->layout == PAN_AFBC) {
+DBG("Unimplemented: writes to AFBC\n");
+} else if (bo->layout == PAN_TILED) {
+struct pipe_context *gallium = (struct
pipe_context *) ctx;
+struct panfrost_screen *screen =
pan_screen(gallium->screen);
+assert(transfer->box.depth == 1);
+panfrost_tile_texture(screen, prsrc, trans);
+}
}
-}
-
-free(trans->map);
-}
-
-static void
-panfrost_transfer_unmap(struct pipe_context *pctx,
-struct pipe_transfer *transfer)
-{
-struct panfrost_context *ctx = pan_context(pctx);
- panfrost_unmap_bo(ctx, transfer);
+free(trans->map);
+}
/* Derefence the resource */
pipe_resource_reference(>resource, NULL);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] panfrost: Respect box->width in tiled stores
This fixes a regression uploading partial tiled textures introduced
sometime during the cubemap series.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 4 +++-
src/gallium/drivers/panfrost/pan_swizzle.c | 4 ++--
src/gallium/drivers/panfrost/pan_swizzle.h | 2 +-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index f7df1353d68..217b27c5778 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -414,7 +414,8 @@ panfrost_transfer_map(struct pipe_context *pctx,
return NULL;
/* TODO: Reads */
-transfer->map = malloc(ALIGN(box->width, 16) *
ALIGN(box->height, 16) * bytes_per_pixel);
+/* TODO: Only allocate "just" enough, shortening the stride */
+transfer->map = malloc(transfer->base.stride * box->height);
return transfer->map;
} else {
@@ -440,6 +441,7 @@ panfrost_tile_texture(struct panfrost_screen *screen,
struct panfrost_resource *
trans->base.box.height,
util_format_get_blocksize(rsrc->base.format),
bo->slices[level].stride,
+u_minify(rsrc->base.width0, level),
trans->map,
bo->cpu
+ bo->slices[level].offset
diff --git a/src/gallium/drivers/panfrost/pan_swizzle.c
b/src/gallium/drivers/panfrost/pan_swizzle.c
index 578de655415..afc89506b33 100644
--- a/src/gallium/drivers/panfrost/pan_swizzle.c
+++ b/src/gallium/drivers/panfrost/pan_swizzle.c
@@ -149,12 +149,12 @@ swizzle_bpp4_align16(int width, int height, int
source_stride, int block_pitch,
void
panfrost_texture_swizzle(unsigned off_x,
unsigned off_y,
- int width, int height, int bytes_per_pixel, int
source_stride,
+ int width, int height, int bytes_per_pixel, int
source_stride, int dest_width,
const uint8_t *pixels,
uint8_t *ldest)
{
/* Calculate maximum size, overestimating a bit */
-int block_pitch = ALIGN(width, 16) >> 4;
+int block_pitch = ALIGN(dest_width, 16) >> 4;
/* Use fast path if available */
if (!(off_x || off_y)) {
diff --git a/src/gallium/drivers/panfrost/pan_swizzle.h
b/src/gallium/drivers/panfrost/pan_swizzle.h
index a4d603a0aad..6f4dadef494 100644
--- a/src/gallium/drivers/panfrost/pan_swizzle.h
+++ b/src/gallium/drivers/panfrost/pan_swizzle.h
@@ -32,7 +32,7 @@ panfrost_generate_space_filler_indices(void);
void
panfrost_texture_swizzle(unsigned off_x, unsigned off_y,
-int width, int height, int bytes_per_pixel, int
source_stride,
+int width, int height, int bytes_per_pixel, int
source_stride, int dest_width,
const uint8_t *pixels,
uint8_t *ldest);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] panfrost: Size tiled temp buffers correctly
This should lower transient memory usage and improve performance
slightly (due to less memory to malloc/free, better cache locality,
etc).
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 12 +++-
src/gallium/drivers/panfrost/pan_swizzle.c | 7 +--
src/gallium/drivers/panfrost/pan_swizzle.h | 2 +-
3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index 217b27c5778..15d522f1963 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -390,8 +390,6 @@ panfrost_transfer_map(struct pipe_context *pctx,
transfer->base.level = level;
transfer->base.usage = usage;
transfer->base.box = *box;
-transfer->base.stride = bo->slices[level].stride;
-transfer->base.layer_stride = bo->cubemap_stride;
pipe_resource_reference(>base.resource, resource);
@@ -413,12 +411,17 @@ panfrost_transfer_map(struct pipe_context *pctx,
if (usage & PIPE_TRANSFER_MAP_DIRECTLY)
return NULL;
+transfer->base.stride = box->width * bytes_per_pixel;
+transfer->base.layer_stride = transfer->base.stride *
box->height;
+
/* TODO: Reads */
-/* TODO: Only allocate "just" enough, shortening the stride */
-transfer->map = malloc(transfer->base.stride * box->height);
+transfer->map = malloc(transfer->base.layer_stride *
box->depth);
return transfer->map;
} else {
+transfer->base.stride = bo->slices[level].stride;
+transfer->base.layer_stride = bo->cubemap_stride;
+
return bo->cpu
+ bo->slices[level].offset
+ transfer->base.box.z * bo->cubemap_stride
@@ -440,7 +443,6 @@ panfrost_tile_texture(struct panfrost_screen *screen,
struct panfrost_resource *
trans->base.box.width,
trans->base.box.height,
util_format_get_blocksize(rsrc->base.format),
-bo->slices[level].stride,
u_minify(rsrc->base.width0, level),
trans->map,
bo->cpu
diff --git a/src/gallium/drivers/panfrost/pan_swizzle.c
b/src/gallium/drivers/panfrost/pan_swizzle.c
index afc89506b33..291bd1f88ae 100644
--- a/src/gallium/drivers/panfrost/pan_swizzle.c
+++ b/src/gallium/drivers/panfrost/pan_swizzle.c
@@ -149,15 +149,18 @@ swizzle_bpp4_align16(int width, int height, int
source_stride, int block_pitch,
void
panfrost_texture_swizzle(unsigned off_x,
unsigned off_y,
- int width, int height, int bytes_per_pixel, int
source_stride, int dest_width,
+ int width, int height, int bytes_per_pixel, int
dest_width,
const uint8_t *pixels,
uint8_t *ldest)
{
/* Calculate maximum size, overestimating a bit */
int block_pitch = ALIGN(dest_width, 16) >> 4;
+/* Strides must be tight, since we're only ever called indirectly */
+int source_stride = width * bytes_per_pixel;
+
/* Use fast path if available */
-if (!(off_x || off_y)) {
+if (!(off_x || off_y) && (width == dest_width)) {
if (bytes_per_pixel == 4 /* && (ALIGN(width, 16) == width) */)
{
swizzle_bpp4_align16(width, height, source_stride >>
2, (block_pitch * 256 >> 4), (const uint32_t *) pixels, (uint32_t *) ldest);
return;
diff --git a/src/gallium/drivers/panfrost/pan_swizzle.h
b/src/gallium/drivers/panfrost/pan_swizzle.h
index 6f4dadef494..f4188f13930 100644
--- a/src/gallium/drivers/panfrost/pan_swizzle.h
+++ b/src/gallium/drivers/panfrost/pan_swizzle.h
@@ -32,7 +32,7 @@ panfrost_generate_space_filler_indices(void);
void
panfrost_texture_swizzle(unsigned off_x, unsigned off_y,
-int width, int height, int bytes_per_pixel, int
source_stride, int dest_width,
+int width, int height, int bytes_per_pixel, int
dest_width,
const uint8_t *pixels,
uint8_t *ldest);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/3] Cleanup tiled texture upload
The state management for tiled textures was questionable to begin with; the cubemap changes transformed it to something only half-way reasonable, unwittingly regressing SuperTuxKart (among others). This change set finalizes the tiled texture refactor, fixing STK. Alyssa Rosenzweig (3): panfrost: Cleanup some indirection in pan_resource panfrost: Respect box->width in tiled stores panfrost: Size tiled temp buffers correctly src/gallium/drivers/panfrost/pan_resource.c | 57 +++-- src/gallium/drivers/panfrost/pan_swizzle.c | 9 ++-- src/gallium/drivers/panfrost/pan_swizzle.h | 2 +- 3 files changed, 36 insertions(+), 32 deletions(-) -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3] nir: propagate known constant values into the if-then branch
Helps Max Waves / VGPR use in a bunch of Unigine Heaven
shaders.
shader-db results radeonsi (VEGA):
Totals from affected shaders:
SGPRS: 5505440 -> 5505872 (0.01 %)
VGPRS: 3077520 -> 3077296 (-0.01 %)
Spilled SGPRs: 39032 -> 39030 (-0.01 %)
Spilled VGPRs: 16326 -> 16326 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 744 -> 744 (0.00 %) dwords per thread
Code Size: 123755028 -> 123753316 (-0.00 %) bytes
Compile Time: 2751028 -> 2560786 (-6.92 %) milliseconds
LDS: 1415 -> 1415 (0.00 %) blocks
Max Waves: 972192 -> 972240 (0.00 %)
Wait states: 0 -> 0 (0.00 %)
vkpipeline-db results RADV (VEGA):
Totals from affected shaders:
SGPRS: 160 -> 160 (0.00 %)
VGPRS: 88 -> 88 (0.00 %)
Spilled SGPRs: 0 -> 0 (0.00 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 0 -> 0 (0.00 %) dwords per thread
Code Size: 18268 -> 18152 (-0.63 %) bytes
LDS: 0 -> 0 (0.00 %) blocks
Max Waves: 26 -> 26 (0.00 %)
Wait states: 0 -> 0 (0.00 %)
v3: disable opt_for_known_values() for non scalar constants
Reviewed-by: Caio Marcelo de Oliveira Filho (v2)
---
src/compiler/nir/nir_opt_if.c | 61 +++
1 file changed, 61 insertions(+)
diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index 4d3183ed151..d8fa6b04b39 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -1326,6 +1326,66 @@ opt_if_merge(nir_if *nif)
return progress;
}
+/* Perform optimisations based on the values we can derive from the evaluation
+ * of if-statement conditions.
+ */
+static bool
+opt_for_known_values(nir_builder *b, nir_if *nif)
+{
+ bool progress = false;
+
+ assert(nif->condition.is_ssa);
+ nir_ssa_def *if_cond = nif->condition.ssa;
+
+ if (if_cond->parent_instr->type != nir_instr_type_alu)
+ return false;
+
+ nir_alu_instr *alu = nir_instr_as_alu(if_cond->parent_instr);
+ switch (alu->op) {
+ case nir_op_feq:
+ case nir_op_ieq: {
+ nir_load_const_instr *load_const = NULL;
+ nir_ssa_def *unknown_val = NULL;
+
+ nir_ssa_def *src0 = alu->src[0].src.ssa;
+ nir_ssa_def *src1 = alu->src[1].src.ssa;
+ if (src0->parent_instr->type == nir_instr_type_load_const) {
+ load_const = nir_instr_as_load_const(src0->parent_instr);
+ unknown_val = src1;
+ } else if (src1->parent_instr->type == nir_instr_type_load_const) {
+ load_const = nir_instr_as_load_const(src1->parent_instr);
+ unknown_val = src0;
+ }
+
+ if (!load_const)
+return false;
+
+ /* TODO: remove this and support swizzles? */
+ if (unknown_val->num_components != 1 ||
+ load_const->def.num_components != 1)
+return false;
+
+ /* Replace unknown ssa uses with the known constant */
+ nir_foreach_use_safe(use_src, unknown_val) {
+ nir_cursor cursor = nir_before_src(use_src, false);
+ nir_block *use_block = nir_cursor_current_block(cursor);
+ if (nir_block_dominates(nir_if_first_then_block(nif), use_block)) {
+nir_instr_rewrite_src(use_src->parent_instr, use_src,
+ nir_src_for_ssa(_const->def));
+progress = true;
+ }
+ }
+
+ break;
+ }
+
+ default:
+ return false;
+ }
+
+ return progress;
+}
+
static bool
opt_if_cf_list(nir_builder *b, struct exec_list *cf_list)
{
@@ -1380,6 +1440,7 @@ opt_if_safe_cf_list(nir_builder *b, struct exec_list
*cf_list)
progress |= opt_if_safe_cf_list(b, >then_list);
progress |= opt_if_safe_cf_list(b, >else_list);
progress |= opt_if_evaluate_condition_use(b, nif);
+ progress |= opt_for_known_values(b, nif);
break;
}
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Remove support for legacy kernels
On 4/1/19 2:16 AM, Alyssa Rosenzweig wrote:
Previously, there was minimal support for interoperating with legacy
kernels (reusing kernel modules originally designed for proprietary
legacy userspaces, rather than for upstream-friendly free software
stacks). Now that the Panfrost kernel is stabilising, this commit drops
the legacy code path.
Panfrost users need to use a modern, mainline kernel supporting the
Panfrost kernel driver from this commit forward.
Sounds good to me. This will make it easier to refactor code around and I
don't think I will need any more register dumps from kbase any more (and
if so, I can always go back in time).
Reviewed-by: Tomeu Vizoso
Thanks!
Tomeu
Signed-off-by: Alyssa Rosenzweig
Cc: Tomeu Vizoso
Cc: Rob Herring
---
src/gallium/drivers/panfrost/.gitignore| 1 -
src/gallium/drivers/panfrost/meson.build | 10 --
src/gallium/drivers/panfrost/pan_drm.c | 1 -
src/gallium/drivers/panfrost/pan_public.h | 2 +-
src/gallium/drivers/panfrost/pan_screen.c | 14 ++
src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c| 11 +--
.../winsys/panfrost/drm/panfrost_drm_public.h | 2 +-
.../winsys/panfrost/drm/panfrost_drm_winsys.c | 6 +++---
8 files changed, 8 insertions(+), 39 deletions(-)
diff --git a/src/gallium/drivers/panfrost/.gitignore
b/src/gallium/drivers/panfrost/.gitignore
index 9d2c2c18bef..e69de29bb2d 100644
--- a/src/gallium/drivers/panfrost/.gitignore
+++ b/src/gallium/drivers/panfrost/.gitignore
@@ -1 +0,0 @@
-nondrm
diff --git a/src/gallium/drivers/panfrost/meson.build
b/src/gallium/drivers/panfrost/meson.build
index e3569e73468..371a11a934b 100644
--- a/src/gallium/drivers/panfrost/meson.build
+++ b/src/gallium/drivers/panfrost/meson.build
@@ -62,16 +62,6 @@ compile_args_panfrost = [
'-Wno-pointer-arith'
]
-overlay = join_paths(meson.source_root(), meson.current_source_dir(), 'nondrm/pan_nondrm.c')
-nondrm_overlay_check = run_command('ls', overlay)
-has_nondrm_overlay = nondrm_overlay_check.returncode() == 0
-
-if has_nondrm_overlay
- files_panfrost += files('nondrm/pan_nondrm.c')
- inc_panfrost += include_directories('nondrm/include')
- compile_args_panfrost += '-DPAN_NONDRM_OVERLAY'
-endif
-
midgard_nir_algebraic_c = custom_target(
'midgard_nir_algebraic.c',
input : 'midgard/midgard_nir_algebraic.py',
diff --git a/src/gallium/drivers/panfrost/pan_drm.c
b/src/gallium/drivers/panfrost/pan_drm.c
index c30beaf2b50..4b8c197be0e 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -298,7 +298,6 @@ panfrost_drm_force_flush_fragment(struct panfrost_context
*ctx,
struct pipe_context *gallium = (struct pipe_context *) ctx;
struct panfrost_screen *screen = pan_screen(gallium->screen);
struct panfrost_drm *drm = (struct panfrost_drm *)screen->driver;
-int ret;
if (!screen->last_fragment_flushed) {
drmSyncobjWait(drm->fd, >out_sync, 1, INT64_MAX, 0, NULL);
diff --git a/src/gallium/drivers/panfrost/pan_public.h
b/src/gallium/drivers/panfrost/pan_public.h
index f57fd6157f4..c7e72f94246 100644
--- a/src/gallium/drivers/panfrost/pan_public.h
+++ b/src/gallium/drivers/panfrost/pan_public.h
@@ -32,7 +32,7 @@ struct pipe_screen;
struct renderonly;
struct pipe_screen *
-panfrost_create_screen(int fd, struct renderonly *ro, bool is_drm);
+panfrost_create_screen(int fd, struct renderonly *ro);
#ifdef __cplusplus
}
diff --git a/src/gallium/drivers/panfrost/pan_screen.c
b/src/gallium/drivers/panfrost/pan_screen.c
index 682eb37f5c7..71c6175d069 100644
--- a/src/gallium/drivers/panfrost/pan_screen.c
+++ b/src/gallium/drivers/panfrost/pan_screen.c
@@ -63,7 +63,6 @@ DEBUG_GET_ONCE_FLAGS_OPTION(pan_debug, "PAN_MESA_DEBUG",
debug_options, 0)
int pan_debug = 0;
struct panfrost_driver *panfrost_create_drm_driver(int fd);
-struct panfrost_driver *panfrost_create_nondrm_driver(int fd);
const char *pan_counters_base = NULL;
@@ -549,7 +548,7 @@ panfrost_screen_get_compiler_options(struct pipe_screen *pscreen,
}
struct pipe_screen *
-panfrost_create_screen(int fd, struct renderonly *ro, bool is_drm)
+panfrost_create_screen(int fd, struct renderonly *ro)
{
struct panfrost_screen *screen = CALLOC_STRUCT(panfrost_screen);
@@ -567,16 +566,7 @@ panfrost_create_screen(int fd, struct renderonly *ro, bool is_drm)
}
}
-if (is_drm) {
-screen->driver = panfrost_create_drm_driver(fd);
-} else {
-#ifdef PAN_NONDRM_OVERLAY
-screen->driver = panfrost_create_nondrm_driver(fd);
-#else
-fprintf(stderr, "Legacy (non-DRM) operation requires out-of-tree
overlay\n");
-return NULL;
-#endif
-}
+screen->driver = panfrost_create_drm_driver(fd);
/* Dump memory and/or performance
[Mesa-dev] [PATCH 2/2] panfrost: Implement system values
This patch implements system values via specially-crafted uniforms.
While we previously had an ad hoc system for passing the viewport into
the vertex shader, this commit generalizes the system to allow for
arbitrary system values to be added to both shader stages. While we're
at it, we clean up uniform handling code (which was considerably muddied
to handle the ad hoc viewport uniform).
This commit serves as both a cleanup of the existing codebase and the
precursor to new functionality, like implementing textureSize().
Concurrent with these changes is respecting the depth transform, which
was not possible with the old fixed uniform system and here serves as a
proof-of-correctness test (as well as justifying the NIR changes).
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/meson.build | 1 +
.../drivers/panfrost/midgard/helpers.h| 4 -
.../panfrost/midgard/midgard_compile.c| 272 +-
.../panfrost/midgard/midgard_compile.h| 27 +-
src/gallium/drivers/panfrost/pan_assemble.c | 5 +
src/gallium/drivers/panfrost/pan_context.c| 103 +++
src/gallium/drivers/panfrost/pan_context.h| 5 +
7 files changed, 229 insertions(+), 188 deletions(-)
diff --git a/src/gallium/drivers/panfrost/meson.build
b/src/gallium/drivers/panfrost/meson.build
index e3569e73468..d8b8b5a7947 100644
--- a/src/gallium/drivers/panfrost/meson.build
+++ b/src/gallium/drivers/panfrost/meson.build
@@ -119,6 +119,7 @@ midgard_compiler = executable(
link_with : [
libgallium,
libglsl_standalone,
+libmesa_gallium, # for st_glsl_storage_type_size
libmesa_util
],
build_by_default : true
diff --git a/src/gallium/drivers/panfrost/midgard/helpers.h
b/src/gallium/drivers/panfrost/midgard/helpers.h
index 530a086e928..54960c7e599 100644
--- a/src/gallium/drivers/panfrost/midgard/helpers.h
+++ b/src/gallium/drivers/panfrost/midgard/helpers.h
@@ -95,10 +95,6 @@
#define REGISTER_TEXTURE_BASE 28
#define REGISTER_SELECT 31
-/* Special uniforms used for e.g. vertex epilogues */
-#define SPECIAL_UNIFORM_BASE (1 << 24)
-#define UNIFORM_VIEWPORT (SPECIAL_UNIFORM_BASE + 0)
-
/* SSA helper aliases to mimic the registers. UNUSED_0 encoded as an inline
* constant. UNUSED_1 encoded as REGISTER_UNUSED */
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index ea8c0153c96..c68067d50a5 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -32,6 +32,7 @@
#include "main/mtypes.h"
#include "compiler/glsl/glsl_to_nir.h"
+#include "mesa/state_tracker/st_glsl_types.h"
#include "compiler/nir_types.h"
#include "main/imports.h"
#include "compiler/nir/nir_builder.h"
@@ -176,6 +177,7 @@ typedef struct midgard_block {
* driver seems to do it that way */
#define EMIT(op, ...) emit_mir_instruction(ctx, v_##op(__VA_ARGS__));
+#define SWIZZLE_XYZW SWIZZLE(COMPONENT_X, COMPONENT_Y, COMPONENT_Z,
COMPONENT_W)
#define M_LOAD_STORE(name, rname, uname) \
static midgard_instruction m_##name(unsigned ssa, unsigned address) { \
@@ -189,7 +191,7 @@ typedef struct midgard_block {
.load_store = { \
.op = midgard_op_##name, \
.mask = 0xF, \
- .swizzle = SWIZZLE(COMPONENT_X, COMPONENT_Y,
COMPONENT_Z, COMPONENT_W), \
+ .swizzle = SWIZZLE_XYZW, \
.address = address \
} \
}; \
@@ -432,10 +434,6 @@ typedef struct compiler_context {
int temp_count;
int max_hash;
-/* Uniform IDs for mdg */
-struct hash_table_u64 *uniform_nir_to_mdg;
-int uniform_count;
-
/* Just the count of the max register used. Higher count => higher
* register pressure */
int work_registers;
@@ -447,9 +445,6 @@ typedef struct compiler_context {
/* Mapping of texture register -> SSA index for unaliasing */
int texture_index[2];
-/* Count of special uniforms (viewport, etc) in vec4 units */
-int special_uniforms;
-
/* If any path hits a discard instruction */
bool can_discard;
@@ -464,6 +459,11 @@ typedef struct compiler_context {
/* The index corresponding to the fragment output */
unsigned fragment_output;
+
+/* The mapping of sysvals to uniforms, the count, and the off-by-one
inverse */
+unsigned sysvals[MAX_SYSVAL_COUNT];
+unsigned sysval_count;
+struct hash_table_u64 *sysval_to_id;
} compiler_context;
/* Append instruction to end of current block */
@@ -645,6 +645,12 @@ glsl_type_size(const struct glsl_type *type)
return glsl_count_attribute_slots(type, false);
}
+static int
+uniform_type_size(const struct glsl_type *type)
+{
[Mesa-dev] [PATCH 0/2] Implement (viewport) system values
This patch set implements the infrastructure for piping system values through Panfrost, replacing the prior brittle system of magic uniform offsets. This infrastructure is used to implement the vertex shader viewport transformation, which will soon be shared with lima. Alyssa Rosenzweig (2): nir: Add "viewport vector" system values panfrost: Implement system values src/compiler/nir/nir_intrinsics.py| 5 + src/gallium/drivers/panfrost/meson.build | 1 + .../drivers/panfrost/midgard/helpers.h| 4 - .../panfrost/midgard/midgard_compile.c| 272 +- .../panfrost/midgard/midgard_compile.h| 27 +- src/gallium/drivers/panfrost/pan_assemble.c | 5 + src/gallium/drivers/panfrost/pan_context.c| 103 +++ src/gallium/drivers/panfrost/pan_context.h| 5 + 8 files changed, 234 insertions(+), 188 deletions(-) -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] nir: Add "viewport vector" system values
While a partial set of viewport system values exist, these are scalar
values, which is a poor fit for viewport transformations on vector ISAs
like Midgard (where the vec3 values for scale and offset each need to be
coherent in a vec4 uniform slot to take advantage of vectorized
transform math). This patch adds vec3 scale/offset fields corresponding
to the 3D Gallium viewport / glViewport+depth
Signed-off-by: Alyssa Rosenzweig
Cc: Eric Anholt
---
src/compiler/nir/nir_intrinsics.py | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/compiler/nir/nir_intrinsics.py
b/src/compiler/nir/nir_intrinsics.py
index fd06393d308..9b307b34c75 100644
--- a/src/compiler/nir/nir_intrinsics.py
+++ b/src/compiler/nir/nir_intrinsics.py
@@ -547,10 +547,15 @@ system_value("work_dim", 1)
# VC4 and V3D need to emit a scaled version of the position in the vertex
# shaders for binning, and having system values lets us move the math for that
# into NIR.
+#
+# Panfrost needs to implement all coordinate transformation in the
+# vertex shader; system values allow us to share this routine in NIR.
system_value("viewport_x_scale", 1)
system_value("viewport_y_scale", 1)
system_value("viewport_z_scale", 1)
system_value("viewport_z_offset", 1)
+system_value("viewport_scale", 3)
+system_value("viewport_offset", 3)
# Blend constant color values. Float values are clamped.#
system_value("blend_const_color_r_float", 1)
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: disable opt_for_known_values() for non scalar constants
We don't handle swizzles and non-scalar backends don't split these
constants so we need to skip these too.
Fixes: 4218b6422cf1 ("nir: propagate known constant values into the if-then
branch")
https://bugs.freedesktop.org/show_bug.cgi?id=110311
---
src/compiler/nir/nir_opt_if.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index af63b90f249..d8fa6b04b39 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -1361,7 +1361,8 @@ opt_for_known_values(nir_builder *b, nir_if *nif)
return false;
/* TODO: remove this and support swizzles? */
- if (unknown_val->num_components != 1)
+ if (unknown_val->num_components != 1 ||
+ load_const->def.num_components != 1)
return false;
/* Replace unknown ssa uses with the known constant */
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] new dispatch generator broke with Marek's parallel compile commit
On Wed, 3 Apr 2019 at 04:32, Emil Velikov wrote: > > On Tue, 2 Apr 2019 at 12:43, Emil Velikov wrote: > > > > On Tue, 2 Apr 2019 at 04:55, Dave Airlie wrote: > > > > > > On Tue, 2 Apr 2019 at 11:24, Dave Airlie wrote: > > > > > > > > Marek's commit to add ARB_parallel_shader_compile broke some es1 tests > > > > in the Intel CI. > > > > > > > > It appears the whatever generates the es1api isn't consistent, for > > > > example glTranslatex on my local system is 1405 in es1api but is 1406 > > > > in the gl api. > > > > > > > > I'm no expert on this area, Emil any ideas? > > > > > > This seems to be due the new registry xml parser, I'm not sure how > > > broken it is, but it seems like it's a bit busted, and nobody tested > > > the scenario where a new function gets introduced in the middle. > > > > > > It looks like static_data.py has a limit on the offsets it cares > > > about, I thought adding static offsets for these functions would help > > > here, but it appears currently it all just work by luck, that the > > > static offsets work out to be the same as ones generated by gl_XML.py > > > for values above MAX_OFFSETS. > > > > > > I've got a hacky patch that makes it work here, that increases > > > MAX_OFFSETS to 1420, adds a new entry to the end for the new APIs, but > > > really I think the current code is broken, and is happening to work > > > out, but I'm hoping I'm just missing something obvious and it'll be a > > > one line fix for Emil. > > > > > As you have noticed the old generator would add entries to the glapi > > table in arbitrary order. > > Meaning that the ABI between dri/glapi/libGL* would break every now and > > then. > > > > In more detail - libGL* would expect glFooBar at offset X, while the > > function is at Y according to glapi and the dri module sets the > > dispatch at Y. Latter uses a combination of fixed offset and dynamic > > offset lookup. > > > > Currently ES* is ported to the new generator and I have some patches > > for libGL and glapi, but no DRI modules just yet. > > A reasonable short term fix is to update the old generator to honour > > the full static_data table. > > > > I'll have a look at that and updating the libGL/libglapi patches. > > > Currently tweaking the most annoying bits - need to ensure the > function aliasing is correct (+ add some test) and go through the > massive diff. > > Dave, anyone - do we have details (build options, test command > failing) about the CI breakage? > From a quick look, I did not see anything related in > https://mesa-ci.01.org/mesa_master/builds/ and > https://mesa-ci.01.org/mesa_master_daily/builds/ https://mesa-ci.01.org/mesa_master/builds/15830/group/63a9f0ea7bb98050796b649e85481845#fails anything GLES1 broke by the looks of it. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: close drm fd when destroying virgl screen.
On Mon, Apr 1, 2019 at 12:39 PM Lepton Wu wrote:
>
> On Wed, Mar 20, 2019 at 2:26 PM Chia-I Wu wrote:
>
>> Reviewed-by: Chia-I Wu
>>
> Anything else to need for merging this? I think this is a straightforward
> leaking fix.
>
Merged. Thanks for the patch and review!
>
>
>>
>> On Mon, Mar 18, 2019 at 4:40 PM Lepton Wu wrote:
>>
>>> This fd was create in virgl_drm_screen_create and should be closed
>>> in virgl_drm_screen_destroy.
>>>
>>> Signed-off-by: Lepton Wu
>>> ---
>>> src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>>> b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>>> index 01811a0e997..5501fe3ed48 100644
>>> --- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>>> +++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>>> @@ -973,6 +973,7 @@ virgl_drm_screen_destroy(struct pipe_screen *pscreen)
>>> if (destroy) {
>>>int fd = virgl_drm_winsys(screen->vws)->fd;
>>>util_hash_table_remove(fd_tab, intptr_to_pointer(fd));
>>> + close(fd);
>>> }
>>> mtx_unlock(_screen_mutex);
>>>
>>> --
>>> 2.21.0.225.g810b269d1ac-goog
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 8/8] egl: add EGL_platform_device support
Do you have a branch with patch 7/8 and 8/8? I'm interested in EGL_EXT_platform_device on radeonsi. Thanks, Marek On Wed, Oct 3, 2018 at 4:36 AM Mathias Fröhlich wrote: > Hi Emil, > > Ok, thanks for picking that up. > > On Tuesday, 2 October 2018 12:23:30 CEST Emil Velikov wrote: > > On Thu, 20 Sep 2018 at 15:13, Mathias Fröhlich > > wrote: > > > > > > > > If I replace the above with > > > > > > EGLint surface_type = 0; > > > /* Only advertise pbuffer configs for non swrast devices */ > > > if (dri2_dpy->image_driver) > > > surface_type = EGL_PBUFFER_BIT; > > > > > > dri2_conf = dri2_add_config(dpy, dri2_dpy->driver_configs[i], > > >config_count + 1, surface_type, NULL, > > >visuals[j].rgba_masks); > > > > > > then I can easily prohibit the crash that I mentioned when trying to > > > create a pbuffer surface on the swrast device. > > > At least I do no longer get a valid pbuffer config from eglChooseConfig > > > and without that we cannot reach the crashing > > > dri2_dpy->image_driver->createNewDrawable > > > call somewhere from eglCreatePbufferSurface anymore. > > > > > > Still getting a surface less context on swrast should work... > > > > > Issue is that we do not know how to create a "pbuffer only" swrast. > > > > Hence one resolves to hacks like the ones we have in > platform_surfaceless. > > Effectively pilling hacks upon hacks - see swrast_loader_extensions > > and "software path w/o DRM.". > > > > That said, I'm working on proper solution but since it will take some > > time to finish/merge I'll drop this and 7/8 for now. > > > That's fine too. > > What I wanted to avoid is that people using the extension correctly fail > with a > crash in the application when running on mesa. > Think about it. Thats really bad from an application writers point of view > as you do all right with checking extensions and that and then the opengl > stack suddenly crashes. > > best > > Mathias > > > ___ > 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 110310] glXQueryServerString is weirdly restrictive
https://bugs.freedesktop.org/show_bug.cgi?id=110310 Bug ID: 110310 Summary: glXQueryServerString is weirdly restrictive Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: enhancement Priority: medium Component: GLX Assignee: mesa-dev@lists.freedesktop.org Reporter: a...@nwnk.net QA Contact: mesa-dev@lists.freedesktop.org (This is with reference to src/glx/glxcmds.c; other implementations in the tree might have similar issues, I haven't checked) In principle you might want to query GLX_VENDOR_NAMES_EXT if you're trying to do something clever with glvnd; other strings are imaginable for other possible extensions. But at the moment the call to __glXQueryServerString is unreachable, because of the 'default: return NULL;' in the switch statement. Part of the reason for this is that the `priv->serverXXX` strings are saved in the GLX display state and are manually freed at shutdown. If we returned arbitrary strings too, we'd need to track them in a hash table; and once you're doing that, why not do that for _all_ server strings. This probably also requires making __glXQueryServerString robust against getting errors instead of replies. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.3.6 release candidate
On Mon, Apr 1, 2019 at 5:18 AM Emil Velikov wrote: > For anyone wondering about the delay: > > We have been using LunarG OpenGL and Vulkan testing service to > validate Mesa releases since day 1. > > Unfortunately, they've been experiencing some issues which we're > expecting to be resolved any day now. We have? Who is we? Dylan doesn't (and his releases make it out on time). The 18.3.x release train has gone off the rails repeatedly. We should not be holding releases up because of the LunarG testing service without prior discussion. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] new dispatch generator broke with Marek's parallel compile commit
On 4/2/19 4:43 AM, Emil Velikov wrote: > On Tue, 2 Apr 2019 at 04:55, Dave Airlie wrote: >> >> On Tue, 2 Apr 2019 at 11:24, Dave Airlie wrote: >>> >>> Marek's commit to add ARB_parallel_shader_compile broke some es1 tests >>> in the Intel CI. >>> >>> It appears the whatever generates the es1api isn't consistent, for >>> example glTranslatex on my local system is 1405 in es1api but is 1406 >>> in the gl api. >>> >>> I'm no expert on this area, Emil any ideas? >> >> This seems to be due the new registry xml parser, I'm not sure how >> broken it is, but it seems like it's a bit busted, and nobody tested >> the scenario where a new function gets introduced in the middle. >> >> It looks like static_data.py has a limit on the offsets it cares >> about, I thought adding static offsets for these functions would help >> here, but it appears currently it all just work by luck, that the >> static offsets work out to be the same as ones generated by gl_XML.py >> for values above MAX_OFFSETS. >> >> I've got a hacky patch that makes it work here, that increases >> MAX_OFFSETS to 1420, adds a new entry to the end for the new APIs, but >> really I think the current code is broken, and is happening to work >> out, but I'm hoping I'm just missing something obvious and it'll be a >> one line fix for Emil. >> > As you have noticed the old generator would add entries to the glapi > table in arbitrary order. > Meaning that the ABI between dri/glapi/libGL* would break every now and then. > > In more detail - libGL* would expect glFooBar at offset X, while the > function is at Y according to glapi and the dri module sets the > dispatch at Y. Latter uses a combination of fixed offset and dynamic > offset lookup. This doesn't make sense to me. Can you explain more? There are only two parts. There's the loader, and there's the driver. The loader assigns locations either at compile-time or at run-time. The driver queries the locations of functions that it will provide. All functions that the loader knows about should realistically have a dispatch location set at compile time. The loader should only generate new locations at run-time if the application or driver asks for a function that it does not know. For things that don't have a static dispatch location set in the XML, the loader is free to assign any location is pleases, but that location must be consistent across all APIs because a single application can create contexts from every possible API in the same address space, but glXGetProcAddress or eglGetProcAddress are API agnostic. If there is any possibility for a single function to have different dispatch locations in different APIs, then the single most fundamental invariant of the entire dispatch table system is being violated. That is a pretty catastrophic failure. > Currently ES* is ported to the new generator and I have some patches > for libGL and glapi, but no DRI modules just yet. > A reasonable short term fix is to update the old generator to honour > the full static_data table. > > I'll have a look at that and updating the libGL/libglapi patches. > > Thanks > Emil > ___ > 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 109929] tgsi_to_nir.c:2111: undefined reference to `gl_nir_lower_samplers_as_deref'
https://bugs.freedesktop.org/show_bug.cgi?id=109929 --- Comment #15 from Timur Kristóf --- As discussed with Jan and Jason on IRC, the proper solution will be to attempt to refactor gl_nir_lower_samplers and gl_nir_lower_samplers_as_deref in a way that separates the GLSL specific code. Then switch TTN over to the new, non-GL-specific functions instead of the current ones. Currently working on a patch. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move adriconf to mesa repositories
Hey Emil, You also showed interest in this project in the past. Any thoughts about moving it to mesa gitlab? Kind Regards, Jean Hertel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] new dispatch generator broke with Marek's parallel compile commit
On Tue, 2 Apr 2019 at 12:43, Emil Velikov wrote: > > On Tue, 2 Apr 2019 at 04:55, Dave Airlie wrote: > > > > On Tue, 2 Apr 2019 at 11:24, Dave Airlie wrote: > > > > > > Marek's commit to add ARB_parallel_shader_compile broke some es1 tests > > > in the Intel CI. > > > > > > It appears the whatever generates the es1api isn't consistent, for > > > example glTranslatex on my local system is 1405 in es1api but is 1406 > > > in the gl api. > > > > > > I'm no expert on this area, Emil any ideas? > > > > This seems to be due the new registry xml parser, I'm not sure how > > broken it is, but it seems like it's a bit busted, and nobody tested > > the scenario where a new function gets introduced in the middle. > > > > It looks like static_data.py has a limit on the offsets it cares > > about, I thought adding static offsets for these functions would help > > here, but it appears currently it all just work by luck, that the > > static offsets work out to be the same as ones generated by gl_XML.py > > for values above MAX_OFFSETS. > > > > I've got a hacky patch that makes it work here, that increases > > MAX_OFFSETS to 1420, adds a new entry to the end for the new APIs, but > > really I think the current code is broken, and is happening to work > > out, but I'm hoping I'm just missing something obvious and it'll be a > > one line fix for Emil. > > > As you have noticed the old generator would add entries to the glapi > table in arbitrary order. > Meaning that the ABI between dri/glapi/libGL* would break every now and then. > > In more detail - libGL* would expect glFooBar at offset X, while the > function is at Y according to glapi and the dri module sets the > dispatch at Y. Latter uses a combination of fixed offset and dynamic > offset lookup. > > Currently ES* is ported to the new generator and I have some patches > for libGL and glapi, but no DRI modules just yet. > A reasonable short term fix is to update the old generator to honour > the full static_data table. > > I'll have a look at that and updating the libGL/libglapi patches. > Currently tweaking the most annoying bits - need to ensure the function aliasing is correct (+ add some test) and go through the massive diff. Dave, anyone - do we have details (build options, test command failing) about the CI breakage? From a quick look, I did not see anything related in https://mesa-ci.01.org/mesa_master/builds/ and https://mesa-ci.01.org/mesa_master_daily/builds/ Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] gallium/auxiliary/vl: Add barrier/unbind after compute shader launch.
Add memory barrier sync and unbind resource after launch will enhance the robustness. Signed-off-by: James Zhu --- src/gallium/auxiliary/vl/vl_compositor_cs.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c b/src/gallium/auxiliary/vl/vl_compositor_cs.c index c3afe61..f00cb65 100644 --- a/src/gallium/auxiliary/vl/vl_compositor_cs.c +++ b/src/gallium/auxiliary/vl/vl_compositor_cs.c @@ -292,6 +292,17 @@ cs_launch(struct vl_compositor *c, info.grid[2] = 1; ctx->launch_grid(ctx, ); + + /* Make the result visible to all clients. */ + ctx->memory_barrier(ctx, PIPE_BARRIER_ALL); + + /* Unbind. */ + ctx->set_shader_images(ctx, PIPE_SHADER_COMPUTE, 0, 1, NULL); + ctx->set_constant_buffer(ctx, PIPE_SHADER_COMPUTE, 0, NULL); + ctx->set_sampler_views(c->pipe, PIPE_SHADER_FRAGMENT, 0, 0, NULL); + ctx->bind_compute_state(ctx, NULL); + ctx->bind_sampler_states(c->pipe, PIPE_SHADER_COMPUTE, 0, 0, NULL); + ctx->flush(ctx, NULL, 0); } static inline struct u_rect -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] gallium/auxiliary/vl: Fixed blank issue with compute shader
Multiple init buffer within one open instance will cause blank issue.
Updating viewport per frame will fix this issue.
Signed-off-by: James Zhu
Tested-by: Bruno Milreu
---
src/gallium/auxiliary/vl/vl_compositor_cs.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c
b/src/gallium/auxiliary/vl/vl_compositor_cs.c
index 6336b23..c3afe61 100644
--- a/src/gallium/auxiliary/vl/vl_compositor_cs.c
+++ b/src/gallium/auxiliary/vl/vl_compositor_cs.c
@@ -362,7 +362,6 @@ draw_layers(struct vl_compositor *c,
struct u_rect *dirty)
{
unsigned i;
- static struct cs_viewport old_drawn;
assert(c);
@@ -381,11 +380,7 @@ draw_layers(struct vl_compositor *c,
drawn.translate_y = (int)layer->viewport.translate[1];
drawn.sampler0_w = (float)layer->sampler_views[0]->texture->width0;
drawn.sampler0_h = (float)layer->sampler_views[0]->texture->height0;
-
- if (memcmp(, _drawn, sizeof(struct cs_viewport))) {
-set_viewport(s, );
-old_drawn = drawn;
- }
+ set_viewport(s, );
c->pipe->bind_sampler_states(c->pipe, PIPE_SHADER_COMPUTE, 0,
num_sampler_views, layer->samplers);
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] gallium/auxiliary/vl: Fixed blur issue with weave compute shader
Correct wrong interpolatation with top/bottom row which caused blur issue. Signed-off-by: James Zhu Tested-by: Bruno Milreu --- src/gallium/auxiliary/vl/vl_compositor_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.c b/src/gallium/auxiliary/vl/vl_compositor_cs.c index bad7d5f..6336b23 100644 --- a/src/gallium/auxiliary/vl/vl_compositor_cs.c +++ b/src/gallium/auxiliary/vl/vl_compositor_cs.c @@ -201,7 +201,7 @@ const char *compute_shader_weave = "TEX_LZ TEMP[11].y, TEMP[13], SAMP[1], 2D_ARRAY\n" "TEX_LZ TEMP[11].z, TEMP[13], SAMP[2], 2D_ARRAY\n" - "LRP TEMP[6], TEMP[14], TEMP[11], TEMP[10]\n" + "LRP TEMP[6], TEMP[14], TEMP[10], TEMP[11]\n" "MOV TEMP[6].w, IMM[1].\n" /* Color Space Conversion */ -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa gallium: use compute shaders for vaapi blit
Ilia Mirkin writes: > Shouldn't this sort of decision be left up to the driver? If the > driver would like to use CS for blits, fine, but why not let it blit > in the most optimal way possible and force it to use a compute shader? Yeah, commit messages require an explanation of why a change is being made. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New JIT Features in LLVM
Hi all, Just following up on this request, Feel free to reply On 02/04/19 12:51 AM, preejackie wrote: Hi I'm Praveen Velliengiri, student from India. I'm working on developing a Speculative compilation support in LLVM ORC JIT Infrastructure. As LLVM ORC supports compiling in multiple backend threads, it would be effective if we compile the functions speculatively before they are called by the executing function. So when we request JIT to compile a function, JIT will immediately returns the function address for raw executable bits. This will greatly reduce the JIT latencies in modern multi-core machines. And also I'm working on designing a ORC in-place dynamic profiling support, by this JIT will automatically able to identify the hot functions, and compile it in higher optimization level to achieve good performance. I'm proposing this project for GSoC 2019. It would be helpful to know how this new features are effective to Mesa library, so that I include your comments in "View from Clients" proposal section. Please reply :) -- Have a great day! PreeJackie -- Have a great day! PreeJackie ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa gallium: use compute shaders for vaapi blit
Shouldn't this sort of decision be left up to the driver? If the
driver would like to use CS for blits, fine, but why not let it blit
in the most optimal way possible and force it to use a compute shader?
On Tue, Apr 2, 2019 at 1:44 PM Jiang, Sonny wrote:
>
> Signed-off-by: Sonny Jiang
> ---
> src/gallium/auxiliary/Makefile.sources | 2 +
> src/gallium/auxiliary/util/u_compute.c | 165 +
> src/gallium/auxiliary/util/u_compute.h | 44 ++
> src/gallium/state_trackers/va/context.c| 2 +
> src/gallium/state_trackers/va/postproc.c | 6 +-
> src/gallium/state_trackers/va/va_private.h | 1 +
> 6 files changed, 219 insertions(+), 1 deletion(-)
> create mode 100644 src/gallium/auxiliary/util/u_compute.c
> create mode 100644 src/gallium/auxiliary/util/u_compute.h
>
> diff --git a/src/gallium/auxiliary/Makefile.sources
> b/src/gallium/auxiliary/Makefile.sources
> index 02cc5df70a7..6f5266fe273 100644
> --- a/src/gallium/auxiliary/Makefile.sources
> +++ b/src/gallium/auxiliary/Makefile.sources
> @@ -218,6 +218,8 @@ C_SOURCES := \
> util/u_box.h \
> util/u_cache.c \
> util/u_cache.h \
> + util/u_compute.c \
> + util/u_compute.h \
> util/u_debug_gallium.h \
> util/u_debug_gallium.c \
> util/u_debug_describe.c \
> diff --git a/src/gallium/auxiliary/util/u_compute.c
> b/src/gallium/auxiliary/util/u_compute.c
> new file mode 100644
> index 000..e2e39227206
> --- /dev/null
> +++ b/src/gallium/auxiliary/util/u_compute.c
> @@ -0,0 +1,165 @@
> +/**
> + *
> + * Copyright 2019 Sonny Jiang
> + * Copyright 2019 Advanced Micro Devices, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
> + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + **/
> +
> +#include "pipe/p_context.h"
> +#include "pipe/p_state.h"
> +
> +#include "u_bitcast.h"
> +#include "u_format.h"
> +#include "u_sampler.h"
> +#include "tgsi/tgsi_text.h"
> +#include "tgsi/tgsi_ureg.h"
> +#include "u_inlines.h"
> +
> +void *blit_compute_shader(struct pipe_context *ctx)
> +{
> + static const char text[] =
> + "COMP\n"
> + "PROPERTY CS_FIXED_BLOCK_WIDTH 64\n"
> + "PROPERTY CS_FIXED_BLOCK_HEIGHT 1\n"
> + "PROPERTY CS_FIXED_BLOCK_DEPTH 1\n"
> + "DCL SV[0], THREAD_ID\n"
> + "DCL SV[1], BLOCK_ID\n"
> + "DCL IMAGE[0], 2D_ARRAY, PIPE_FORMAT_R32G32B32A32_FLOAT, WR\n"
> + "DCL SAMP[0]\n"
> + "DCL SVIEW[0], 2D_ARRAY, FLOAT\n"
> + "DCL CONST[0][0..2]\n" // 0:xyzw 1:xyzw
> + "DCL TEMP[0..4], LOCAL\n"
> + "IMM[0] UINT32 {64, 1, 0, 0}\n"
> +
> + "UMAD TEMP[0].xyz, SV[1].xyzz, IMM[0].xyyy, SV[0].xyzz\n"
> + "U2F TEMP[1].xyz, TEMP[0]\n"
> + "MAD TEMP[2].xyz, TEMP[1], CONST[0][1], CONST[0][0]\n"
> + "TEX_LZ TEMP[3], TEMP[2], SAMP[0], 2D_ARRAY\n"
> + "UADD TEMP[4].xyz, TEMP[0], CONST[0][2]\n"
> + "STORE IMAGE[0], TEMP[4], TEMP[3], 2D_ARRAY,
> PIPE_FORMAT_R32G32B32A32_FLOAT\n"
> + "END\n";
> +
> + struct tgsi_token tokens[1024];
> + struct pipe_compute_state state = {0};
> +
> + if (!tgsi_text_translate(text, tokens, ARRAY_SIZE(tokens))) {
> + assert(false);
> + return NULL;
> + }
> +
> + state.ir_type = PIPE_SHADER_IR_TGSI;
> + state.prog = tokens;
> +
> + return ctx->create_compute_state(ctx, );
> +}
> +
> +void util_compute_blit(struct pipe_context *ctx, struct pipe_blit_info
> *blit_info,
> + void **compute_state)
> +{
> + if (blit_info->src.box.width == 0 ||
[Mesa-dev] [PATCH] mesa gallium: use compute shaders for vaapi blit
Signed-off-by: Sonny Jiang
---
src/gallium/auxiliary/Makefile.sources | 2 +
src/gallium/auxiliary/util/u_compute.c | 165 +
src/gallium/auxiliary/util/u_compute.h | 44 ++
src/gallium/state_trackers/va/context.c| 2 +
src/gallium/state_trackers/va/postproc.c | 6 +-
src/gallium/state_trackers/va/va_private.h | 1 +
6 files changed, 219 insertions(+), 1 deletion(-)
create mode 100644 src/gallium/auxiliary/util/u_compute.c
create mode 100644 src/gallium/auxiliary/util/u_compute.h
diff --git a/src/gallium/auxiliary/Makefile.sources
b/src/gallium/auxiliary/Makefile.sources
index 02cc5df70a7..6f5266fe273 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -218,6 +218,8 @@ C_SOURCES := \
util/u_box.h \
util/u_cache.c \
util/u_cache.h \
+ util/u_compute.c \
+ util/u_compute.h \
util/u_debug_gallium.h \
util/u_debug_gallium.c \
util/u_debug_describe.c \
diff --git a/src/gallium/auxiliary/util/u_compute.c
b/src/gallium/auxiliary/util/u_compute.c
new file mode 100644
index 000..e2e39227206
--- /dev/null
+++ b/src/gallium/auxiliary/util/u_compute.c
@@ -0,0 +1,165 @@
+/**
+ *
+ * Copyright 2019 Sonny Jiang
+ * Copyright 2019 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include "pipe/p_context.h"
+#include "pipe/p_state.h"
+
+#include "u_bitcast.h"
+#include "u_format.h"
+#include "u_sampler.h"
+#include "tgsi/tgsi_text.h"
+#include "tgsi/tgsi_ureg.h"
+#include "u_inlines.h"
+
+void *blit_compute_shader(struct pipe_context *ctx)
+{
+ static const char text[] =
+ "COMP\n"
+ "PROPERTY CS_FIXED_BLOCK_WIDTH 64\n"
+ "PROPERTY CS_FIXED_BLOCK_HEIGHT 1\n"
+ "PROPERTY CS_FIXED_BLOCK_DEPTH 1\n"
+ "DCL SV[0], THREAD_ID\n"
+ "DCL SV[1], BLOCK_ID\n"
+ "DCL IMAGE[0], 2D_ARRAY, PIPE_FORMAT_R32G32B32A32_FLOAT, WR\n"
+ "DCL SAMP[0]\n"
+ "DCL SVIEW[0], 2D_ARRAY, FLOAT\n"
+ "DCL CONST[0][0..2]\n" // 0:xyzw 1:xyzw
+ "DCL TEMP[0..4], LOCAL\n"
+ "IMM[0] UINT32 {64, 1, 0, 0}\n"
+
+ "UMAD TEMP[0].xyz, SV[1].xyzz, IMM[0].xyyy, SV[0].xyzz\n"
+ "U2F TEMP[1].xyz, TEMP[0]\n"
+ "MAD TEMP[2].xyz, TEMP[1], CONST[0][1], CONST[0][0]\n"
+ "TEX_LZ TEMP[3], TEMP[2], SAMP[0], 2D_ARRAY\n"
+ "UADD TEMP[4].xyz, TEMP[0], CONST[0][2]\n"
+ "STORE IMAGE[0], TEMP[4], TEMP[3], 2D_ARRAY,
PIPE_FORMAT_R32G32B32A32_FLOAT\n"
+ "END\n";
+
+ struct tgsi_token tokens[1024];
+ struct pipe_compute_state state = {0};
+
+ if (!tgsi_text_translate(text, tokens, ARRAY_SIZE(tokens))) {
+ assert(false);
+ return NULL;
+ }
+
+ state.ir_type = PIPE_SHADER_IR_TGSI;
+ state.prog = tokens;
+
+ return ctx->create_compute_state(ctx, );
+}
+
+void util_compute_blit(struct pipe_context *ctx, struct pipe_blit_info
*blit_info,
+ void **compute_state)
+{
+ if (blit_info->src.box.width == 0 || blit_info->src.box.height == 0 ||
+ blit_info->dst.box.width == 0 || blit_info->dst.box.height == 0)
+ return;
+
+ struct pipe_resource *src = blit_info->src.resource;
+ struct pipe_resource *dst = blit_info->dst.resource;
+ struct pipe_sampler_view src_templ = {0}, *src_view;
+ void *sampler_state_p;
+ unsigned width = blit_info->dst.box.width;
+ unsigned height = blit_info->dst.box.height;
+ float x_scale =
[Mesa-dev] [Bug 87738] [OpenCL] Please add Image support
https://bugs.freedesktop.org/show_bug.cgi?id=87738 --- Comment #5 from smt --- Is there any progress at all towards this? I feel like it would really improve Linux use case for some of us using software like Darktable and whatever other software could possibly use this, I'm still unable to use opencl in Darktable with the same error: 0.021473 [opencl_init] found opencl runtime library 'libOpenCL' 0.021502 [opencl_init] opencl library 'libOpenCL' found on your system and loaded 0.081308 [opencl_init] found 1 platform 0.081325 [opencl_init] found 1 device 0.081354 [opencl_init] discarding device 0 `AMD Radeon (TM) RX 460 Graphics (POLARIS11, DRM 3.27.0, 5.0.0-8-generic, LLVM 8.0.0)' due to missing image support. 0.081359 [opencl_init] no suitable devices found. 0.081360 [opencl_init] FINALLY: opencl is NOT AVAILABLE on this system. -- 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] docs: Fix 19.0.x version numbers
Quoting Guido Günther (2019-04-01 08:58:24) > The list has 19.0.2 twice. > > Signed-off-by: Guido Günther > --- > docs/release-calendar.html | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/docs/release-calendar.html b/docs/release-calendar.html > index 0b0bb138b12..35965f68de8 100644 > --- a/docs/release-calendar.html > +++ b/docs/release-calendar.html > @@ -64,25 +64,25 @@ if you'd like to nominate a patch in the next stable > release. > > > 2019-04-23 > -19.0.2 > +19.0.3 > Dylan Baker > > > > 2019-05-07 > -19.0.3 > +19.0.4 > Dylan Baker > > > > 2019-05-21 > -19.0.4 > +19.0.5 > Dylan Baker > > > > 2019-06-04 > -19.0.5 > +19.0.6 > Dylan Baker > Last planned 19.0.x release > > -- > 2.20.1 > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev Reviewed-by: Dylan Baker I'll go ahead and push this. Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110253] glBlitFramebuffer fails on MSAA fbo source.
https://bugs.freedesktop.org/show_bug.cgi?id=110253 --- Comment #1 from Bruce Cherniak --- Thank you for reporting this bug and a possible solution. We will investigate. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 1/2] egl: introduce a log level getter function
Being able to retrieve the log level can be useful to enable/disable
debug code. The alternative, which is calling 'getenv' function every
time to retrieve the log level, is more "expensive".
Signed-off-by: Silvestrs Timofejevs
Reviewed-by: Eric Engestrom
---
src/egl/main/egllog.c | 9 +
src/egl/main/egllog.h | 4
2 files changed, 13 insertions(+)
diff --git a/src/egl/main/egllog.c b/src/egl/main/egllog.c
index c223f49..42bae01 100644
--- a/src/egl/main/egllog.c
+++ b/src/egl/main/egllog.c
@@ -133,6 +133,15 @@ _eglInitLogger(void)
}
}
+/**
+ * Return the log level.
+ */
+EGLint
+_eglGetLogLevel(void)
+{
+ return logging.level;
+}
+
/**
* Log a message with message logger.
diff --git a/src/egl/main/egllog.h b/src/egl/main/egllog.h
index 2a06a34..a1cf977 100644
--- a/src/egl/main/egllog.h
+++ b/src/egl/main/egllog.h
@@ -44,6 +44,10 @@ extern "C" {
#define _EGL_DEBUG 3 /* useful info for debugging */
+extern EGLint
+_eglGetLogLevel(void);
+
+
extern void
_eglLog(EGLint level, const char *fmtStr, ...);
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 2/2] egl: add config debug printout (v4)
Feature to print out EGL returned configs for debug purposes.
'eglChooseConfig' and 'eglGetConfigs' debug information printout is
enabled when the log level equals '_EGL_DEBUG'. The configs are
printed, and if any of them are "chosen" they are marked with their
index in the chosen configs array.
v2:
a) re-factor the code in line with review comments
b) rename function _snprintfStrcat, split it out and put into the
src/util/u_string.h, make it a separate patch.
v3:
remove unnecessary 'const' qualifiers from the function prototype
v4:
a) re-factor the code in line with review comments
b) move util_strnappend from utils back to eglconfigdebug.c. In my
opinion this function is the best way of achieving the desired
result, so it still used but made private to eglconfigdebug.c.
Signed-off-by: Silvestrs Timofejevs
Reviewed-by: Eric Engestrom
---
src/egl/Makefile.sources | 4 +-
src/egl/main/eglconfig.c | 20 +++-
src/egl/main/eglconfigdebug.c | 222 ++
src/egl/main/eglconfigdebug.h | 47 +
src/egl/meson.build | 2 +
5 files changed, 290 insertions(+), 5 deletions(-)
create mode 100644 src/egl/main/eglconfigdebug.c
create mode 100644 src/egl/main/eglconfigdebug.h
diff --git a/src/egl/Makefile.sources b/src/egl/Makefile.sources
index 0cc5f1b..353a848 100644
--- a/src/egl/Makefile.sources
+++ b/src/egl/Makefile.sources
@@ -28,7 +28,9 @@ LIBEGL_C_FILES := \
main/eglsync.c \
main/eglsync.h \
main/eglentrypoint.h \
- main/egltypedefs.h
+ main/egltypedefs.h \
+ main/eglconfigdebug.h \
+ main/eglconfigdebug.c
dri2_backend_core_FILES := \
drivers/dri2/egl_dri2.c \
diff --git a/src/egl/main/eglconfig.c b/src/egl/main/eglconfig.c
index 72cd73d..5addbd9 100644
--- a/src/egl/main/eglconfig.c
+++ b/src/egl/main/eglconfig.c
@@ -40,6 +40,7 @@
#include "util/macros.h"
#include "eglconfig.h"
+#include "eglconfigdebug.h"
#include "egldisplay.h"
#include "eglcurrent.h"
#include "egllog.h"
@@ -797,14 +798,21 @@ _eglChooseConfig(_EGLDriver *drv, _EGLDisplay *disp,
const EGLint *attrib_list,
EGLConfig *configs, EGLint config_size, EGLint *num_configs)
{
_EGLConfig criteria;
+ EGLBoolean result;
if (!_eglParseConfigAttribList(, disp, attrib_list))
return _eglError(EGL_BAD_ATTRIBUTE, "eglChooseConfig");
- return _eglFilterConfigArray(disp->Configs,
- configs, config_size, num_configs,
- _eglFallbackMatch, _eglFallbackCompare,
- (void *) );
+ result = _eglFilterConfigArray(disp->Configs,
+ configs, config_size, num_configs,
+ _eglFallbackMatch, _eglFallbackCompare,
+ (void *) );
+
+ if (result && (_eglGetLogLevel() == _EGL_DEBUG))
+ eglPrintConfigDebug(drv, disp, configs, *num_configs,
+ EGL_TRUE);
+
+ return result;
}
@@ -857,5 +865,9 @@ _eglGetConfigs(_EGLDriver *drv, _EGLDisplay *disp,
EGLConfig *configs,
*num_config = _eglFlattenArray(disp->Configs, (void *) configs,
sizeof(configs[0]), config_size, _eglFlattenConfig);
+ if (_eglGetLogLevel() == _EGL_DEBUG)
+ eglPrintConfigDebug(drv, disp, configs, *num_config,
+ EGL_FALSE);
+
return EGL_TRUE;
}
diff --git a/src/egl/main/eglconfigdebug.c b/src/egl/main/eglconfigdebug.c
new file mode 100644
index 000..ee4303a
--- /dev/null
+++ b/src/egl/main/eglconfigdebug.c
@@ -0,0 +1,222 @@
+/*
+ * Copyright 2019 Imagination Technologies.
+ * All Rights Reserved.
+ *
+ * Based on eglinfo, which has copyright:
+ * Copyright (C) 2005 Brian Paul All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+ * AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "eglarray.h"
+#include "eglconfig.h"
+#include "eglconfigdebug.h"
+#include
[Mesa-dev] debug feature to dump "get configs" and "chosen configs" (v4)
This patch series provides an easy way to see what configs have been returned by the 'eglGetConfigs' and 'eglChooseConfig' functions, and give an overview of config attributes. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 4/8] gallium/u_vbuf: export u_vbuf_get_minmax_index
Reviewed-by: Marek Olšák
Marek
On Fri, Mar 22, 2019 at 10:30 AM Qiang Yu wrote:
> This helper function can be used by driver which
> always need min/max index.
>
> Signed-off-by: Qiang Yu
> ---
> src/gallium/auxiliary/util/u_vbuf.c | 7 +++
> src/gallium/auxiliary/util/u_vbuf.h | 3 +++
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_vbuf.c
> b/src/gallium/auxiliary/util/u_vbuf.c
> index f721613cbc5..02a59bc0575 100644
> --- a/src/gallium/auxiliary/util/u_vbuf.c
> +++ b/src/gallium/auxiliary/util/u_vbuf.c
> @@ -1093,10 +1093,9 @@ u_vbuf_get_minmax_index_mapped(const struct
> pipe_draw_info *info,
> *out_max_index = max;
> }
>
> -static void
> -u_vbuf_get_minmax_index(struct pipe_context *pipe,
> -const struct pipe_draw_info *info,
> -unsigned *out_min_index, unsigned *out_max_index)
> +void u_vbuf_get_minmax_index(struct pipe_context *pipe,
> + const struct pipe_draw_info *info,
> + unsigned *out_min_index, unsigned
> *out_max_index)
> {
> struct pipe_transfer *transfer = NULL;
> const void *indices;
> diff --git a/src/gallium/auxiliary/util/u_vbuf.h
> b/src/gallium/auxiliary/util/u_vbuf.h
> index a6139834575..604e8c8b8b0 100644
> --- a/src/gallium/auxiliary/util/u_vbuf.h
> +++ b/src/gallium/auxiliary/util/u_vbuf.h
> @@ -72,6 +72,9 @@ void u_vbuf_set_vertex_buffers(struct u_vbuf *mgr,
> unsigned start_slot, unsigned count,
> const struct pipe_vertex_buffer *bufs);
> void u_vbuf_draw_vbo(struct u_vbuf *mgr, const struct pipe_draw_info
> *info);
> +void u_vbuf_get_minmax_index(struct pipe_context *pipe,
> + const struct pipe_draw_info *info,
> + unsigned *out_min_index, unsigned
> *out_max_index);
>
> /* Save/restore functionality. */
> void u_vbuf_save_vertex_elements(struct u_vbuf *mgr);
> --
> 2.17.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
Re: [Mesa-dev] [PATCH 4/9] gallium: add a cap to force compute minmax indices
On Fri, Mar 15, 2019 at 9:30 PM Qiang Yu wrote:
> 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);
>
Can you call this only once at context creation?
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On 2019-04-02 2:57 p.m., Marek Olšák wrote: > On Tue, Apr 2, 2019 at 4:57 AM Michel Dänzer wrote: >> On 2019-04-02 12:39 a.m., Marek Olšák wrote: >>> On Mon, Apr 1, 2019 at 1:28 PM Jan Vesely >> wrote: On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote: > Does the attached patch fix the copy-buffer test? it does thanks. Won't the compute only context still need some synchronization? Is there anything else to guarantee that the data is in place after return from resource_copy_region ? >>> >>> The synchronization is the same on gfx and compute rings. >> >> BTW, did you see https://bugs.freedesktop.org/show_bug.cgi?id=110214#c24 >> ? It does indicate some kind of synchronization issue between >> si_resource_copy_region using a compute ring and other operations using >> a GFX ring. > > Only OpenCL uses the compute ring. xterm doesn't invoke OpenCL AFAIK. That bugzilla comment is about the GTK menu issue, not about xterm. Anyway, I doubt GTK uses OpenCL either, and neither does glamor, so it was probably an invalid bisect result then. Thanks, -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Bug 99553 depends on bug 110045, which changed state. Bug 110045 Summary: [radeonsi][clover][regression][bisected] cl-api-enqueue-copy-buffer hangs on radeonsi https://bugs.freedesktop.org/show_bug.cgi?id=110045 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On Tue, Apr 2, 2019 at 4:57 AM Michel Dänzer wrote: > On 2019-04-02 12:39 a.m., Marek Olšák wrote: > > On Mon, Apr 1, 2019 at 1:28 PM Jan Vesely > wrote: > >> On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote: > >>> Does the attached patch fix the copy-buffer test? > >> > >> it does thanks. > >> Won't the compute only context still need some synchronization? > >> Is there anything else to guarantee that the data is in place after > >> return from resource_copy_region ? > > > > The synchronization is the same on gfx and compute rings. > > BTW, did you see https://bugs.freedesktop.org/show_bug.cgi?id=110214#c24 > ? It does indicate some kind of synchronization issue between > si_resource_copy_region using a compute ring and other operations using > a GFX ring. > Only OpenCL uses the compute ring. xterm doesn't invoke OpenCL AFAIK. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: don't use PFP_SYNC_ME with compute-only contexts
Tested-by: Dieter Nützel
For the first time since ages no horizontal line corruption with old
luxmark-linux64-v2.0 (LuxBall e.g. HDR) on RX580.
Dieter
Am 02.04.2019 00:37, schrieb Marek Olšák:
From: Marek Olšák
Fixes: a1378639ab1 "radeonsi: always use compute rings for clover on
CI and newer (v2)"
---
src/gallium/drivers/radeonsi/si_cp_dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_cp_dma.c
b/src/gallium/drivers/radeonsi/si_cp_dma.c
index 5993369d2da..f349325202c 100644
--- a/src/gallium/drivers/radeonsi/si_cp_dma.c
+++ b/src/gallium/drivers/radeonsi/si_cp_dma.c
@@ -124,21 +124,21 @@ static void si_emit_cp_dma(struct si_context
*sctx, struct radeon_cmdbuf *cs,
radeon_emit(cs, dst_va);/* DST_ADDR_LO [31:0] */
radeon_emit(cs, (dst_va >> 32) & 0x); /* DST_ADDR_HI [15:0]
*/
radeon_emit(cs, command);
}
/* CP DMA is executed in ME, but index buffers are read by PFP.
* This ensures that ME (CP DMA) is idle before PFP starts fetching
* indices. If we wanted to execute CP DMA in PFP, this packet
* should precede it.
*/
- if (flags & CP_DMA_PFP_SYNC_ME) {
+ if (sctx->has_graphics && flags & CP_DMA_PFP_SYNC_ME) {
radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
radeon_emit(cs, 0);
}
}
void si_cp_dma_wait_for_idle(struct si_context *sctx)
{
/* Issue a dummy DMA that copies zero bytes.
*
* The DMA engine will see that there's no work to do and skip this
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] new dispatch generator broke with Marek's parallel compile commit
On Tue, 2 Apr 2019 at 04:55, Dave Airlie wrote: > > On Tue, 2 Apr 2019 at 11:24, Dave Airlie wrote: > > > > Marek's commit to add ARB_parallel_shader_compile broke some es1 tests > > in the Intel CI. > > > > It appears the whatever generates the es1api isn't consistent, for > > example glTranslatex on my local system is 1405 in es1api but is 1406 > > in the gl api. > > > > I'm no expert on this area, Emil any ideas? > > This seems to be due the new registry xml parser, I'm not sure how > broken it is, but it seems like it's a bit busted, and nobody tested > the scenario where a new function gets introduced in the middle. > > It looks like static_data.py has a limit on the offsets it cares > about, I thought adding static offsets for these functions would help > here, but it appears currently it all just work by luck, that the > static offsets work out to be the same as ones generated by gl_XML.py > for values above MAX_OFFSETS. > > I've got a hacky patch that makes it work here, that increases > MAX_OFFSETS to 1420, adds a new entry to the end for the new APIs, but > really I think the current code is broken, and is happening to work > out, but I'm hoping I'm just missing something obvious and it'll be a > one line fix for Emil. > As you have noticed the old generator would add entries to the glapi table in arbitrary order. Meaning that the ABI between dri/glapi/libGL* would break every now and then. In more detail - libGL* would expect glFooBar at offset X, while the function is at Y according to glapi and the dri module sets the dispatch at Y. Latter uses a combination of fixed offset and dynamic offset lookup. Currently ES* is ported to the new generator and I have some patches for libGL and glapi, but no DRI modules just yet. A reasonable short term fix is to update the old generator to honour the full static_data table. I'll have a look at that and updating the libGL/libglapi patches. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110301] mesa-git reports Vulkan 1.1.90
https://bugs.freedesktop.org/show_bug.cgi?id=110301 Eric Engestrom changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #1 from Eric Engestrom --- The version reported by the driver is the one it supports, regardless of what exists out there, so this is not a bug :) It is possible that the driver already does everything required to support a higher version, but this hasn't been verified; once it is, the version will be bumped appropriately. -- 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 2/2] etnaviv: flush all pending contexts when accessing a resource with the CPU
Hi Lucas,
On Wed, Mar 27, 2019 at 12:22:58PM +0100, Lucas Stach wrote:
> When setting up a transfer to a resource, all contexts where the resource
> is pending must be flushed. Otherwise a write transfer might be started
> in the current context before all contexts that access the resource in
> shared (read) mode have been executed.
>
> Fixes: 64813541d575 (etnaviv: fix resource usage tracking across
> different pipe_context's)
> Signed-off-by: Lucas Stach
> ---
> src/gallium/drivers/etnaviv/etnaviv_transfer.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> index 45cd31207f70..d875803bde26 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
> @@ -360,8 +360,14 @@ etna_transfer_map(struct pipe_context *pctx, struct
> pipe_resource *prsc,
>if ((trans->rsc && (etna_resource(trans->rsc)->status &
> ETNA_PENDING_WRITE)) ||
>(!trans->rsc &&
> (((usage & PIPE_TRANSFER_READ) && (rsc->status &
> ETNA_PENDING_WRITE)) ||
> - ((usage & PIPE_TRANSFER_WRITE) && rsc->status
> - pctx->flush(pctx, NULL, 0);
> + ((usage & PIPE_TRANSFER_WRITE) && rsc->status {
> + set_foreach(rsc->pending_ctx, entry) {
> +struct etna_context *pend_ctx = (struct etna_context
> *)entry->key;
> +struct pipe_context *pend_pctx = _ctx->base;
> +
> +pend_pctx->flush(pend_pctx, NULL, 0);
> + }
> + }
>
>mtx_unlock(>lock);
I would not say that I have understood all the details of resource
flushing but in my tests it doesn't break anything so:
Tested-By: Guido Günther
Cheers,
-- Guido
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
On 2019-04-02 12:39 a.m., Marek Olšák wrote: > On Mon, Apr 1, 2019 at 1:28 PM Jan Vesely wrote: >> On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote: >>> Does the attached patch fix the copy-buffer test? >> >> it does thanks. >> Won't the compute only context still need some synchronization? >> Is there anything else to guarantee that the data is in place after >> return from resource_copy_region ? > > The synchronization is the same on gfx and compute rings. BTW, did you see https://bugs.freedesktop.org/show_bug.cgi?id=110214#c24 ? It does indicate some kind of synchronization issue between si_resource_copy_region using a compute ring and other operations using a GFX ring. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move adriconf to mesa repositories
Hi, On Tue, 2 Apr 2019 at 00:19, Rob Clark wrote: > On Mon, Apr 1, 2019 at 1:55 PM Jean Hertel wrote: > > As we have spoken already in the past, I have the intention to move > > adriconf under the mesa project umbrella, as an official tool for > > configuring DRI options. > > I would like to ask your advice, as well as other mesa developers, on how > > to properly do this. (If people is willing to accept it) > > So far the questions I have are: > > > > - What is the proccess to become an official mesa tool? > > Maybe a gitlab ticket? Or ping daniels and ask? > > > - Do I need any approval? Like from other mesa developers or X.Org > > Foundation? > > No approval from X.Org foundation or anything like that.. maybe some > general consensus among mesa dev's (or at least a few others who think > it is a good idea). For the record, I think living under > gitlab.freedesktop.org/mesa/adriconf makes sense. Right. As long as Mesa people agree then any project owner can just go ahead and create the owner in Mesa themselves; no need for admins to do anything. > > - Also, what about gitlab? If we move, can we use it? I already know the > > tool and would really appreciate using it. > > Yes, I don't think the fd.o admin's are creating new non-gitlab projects. Absolutely correct. > > - Is there anyone else willing to have commit rights on it? I known the > > project is public, but I feel it would be nice to have someone else also > > with commit/admin rights in case I'm hit by a bus :) > > Hmm, I guess it is possible to set it up so anyone with mesa commit > rights would have adriconf commit rights. But afaiu gitlab is > somewhat flexible on groups so we could I guess do something more fine > grained. It's quite fine-grained, yes. It inherits the permissions of the Mesa group, so anyone who has permission to Mesa can commit to it. You can also add committers specifically to the adriconf project, so they can only commit to that. Again this doesn't need admin intervention, you can just go ahead and do it yourself. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: don't use PFP_SYNC_ME with compute-only contexts
On Mon, 2019-04-01 at 18:37 -0400, Marek Olšák wrote:
> From: Marek Olšák
Tested-by: Jan Vesely
Can you add a note along the lines; "compute rings don't have PFP" or
anything more descriptive on the commit message?
thanks,
Jan
>
> Fixes: a1378639ab1 "radeonsi: always use compute rings for clover on CI and
> newer (v2)"
> ---
> src/gallium/drivers/radeonsi/si_cp_dma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_cp_dma.c
> b/src/gallium/drivers/radeonsi/si_cp_dma.c
> index 5993369d2da..f349325202c 100644
> --- a/src/gallium/drivers/radeonsi/si_cp_dma.c
> +++ b/src/gallium/drivers/radeonsi/si_cp_dma.c
> @@ -124,21 +124,21 @@ static void si_emit_cp_dma(struct si_context *sctx,
> struct radeon_cmdbuf *cs,
> radeon_emit(cs, dst_va);/* DST_ADDR_LO [31:0] */
> radeon_emit(cs, (dst_va >> 32) & 0x); /* DST_ADDR_HI [15:0]
> */
> radeon_emit(cs, command);
> }
>
> /* CP DMA is executed in ME, but index buffers are read by PFP.
>* This ensures that ME (CP DMA) is idle before PFP starts fetching
>* indices. If we wanted to execute CP DMA in PFP, this packet
>* should precede it.
>*/
> - if (flags & CP_DMA_PFP_SYNC_ME) {
> + if (sctx->has_graphics && flags & CP_DMA_PFP_SYNC_ME) {
> radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
> radeon_emit(cs, 0);
> }
> }
>
> void si_cp_dma_wait_for_idle(struct si_context *sctx)
> {
> /* Issue a dummy DMA that copies zero bytes.
>*
>* The DMA engine will see that there's no work to do and skip this
--
Jan Vesely
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Commit 'gallium: fix autotools build of pipe_msm.la' broke Clover - bisected
On Tue, 2019-04-02 at 02:37 +0200, Dieter Nützel wrote:
> Am 01.04.2019 07:43, schrieb Jan Vesely:
> > Hi,
> >
> > On Mon, 2019-04-01 at 06:24 +0200, Dieter Nützel wrote:
> > > Hello,
> > >
> > > commit #356ec7a2196 'gallium: fix autotools build of pipe_msm.la'
> > > broke
> > > Clover.
> > >
> > > biseted:
> > > 356ec7a21960d77db282f67af577dcdb46966b5a is the first bad commit
> > > commit 356ec7a21960d77db282f67af577dcdb46966b5a
> > > Author: Timur Kristóf
> > > Date: Thu Mar 14 15:32:37 2019 +0100
> > >
> > > gallium: fix autotools build of pipe_msm.la
> > >
> > > Signed-off-by: Vinson Lee
> > > Fixes: 9a834447d652 ("tgsi_to_nir: Produce optimized NIR for a
> > > given
> > > pipe_screen.")
> > > Bugzilla:
> > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D109929data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Ca161a421657d40f6011908d6b70370c0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C636897622770137680sdata=QJFTMLeoBK4TjYtc34RHvrJ7NeloOORard6nQ5eBQVQ%3Dreserved=0
> > >
> > > :04 04 601ddeba6f98a1872a8f49667c89224601afe31b
> > > cee6467ed172beb890455d0874a2e883e6c95e14 M src
> > >
> > > Reverting it bring Clover back.
> >
> > I'm guessing you use autotools to build clover?
> > My digging shows that the culprit is
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F225data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Ca161a421657d40f6011908d6b70370c0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C1%7C636897622770137680sdata=1g%2B7aR%2FuaegKvF7fpvErlzP113xy8nsSKs4z5oudh3k%3Dreserved=0
> > which
> > makes users of gallium/axuiliary pull in libglsl.
> > 356ec7a21 tries to fix it by adding libglsl to pipe_loader, thus
> > making pipe drivers require glsl symbols and breaking every state
> > tracker that does not provide them. I'd expect omx and vdpau state
> > trackers would fail in similar manner.
>
> I didn't use omx (do not compile, but can try), but vdpau works with
> 'meson build'.
>
> > > The most annoying thing for me is, that even 'meson build' of Clover
> > > do
> > > NOT work for me (hello Dylan? ;-)):
> > >
> > > ../src/gallium/state_trackers/clover/api/event.cpp: In function
> > > ‘cl_int
> > > clGetEventProfilingInfo(cl_event, cl_profiling_info, size_t, void*,
> > > size_t*)’:
> > > ../src/gallium/state_trackers/clover/api/event.cpp:256:58: error:
> > > ‘dynamic_cast’ not permitted with -fno-rtti
> > > hard_event = dynamic_cast(obj(d_ev));
> > >^
> > > ../src/gallium/state_trackers/clover/api/event.cpp:287:23: warning:
> > > ignoring attributes on template argument ‘cl_ulong’ {aka ‘long
> > > unsigned
> > > int’} [-Wignored-attributes]
> > > } catch (lazy::undefined_error ) {
> > > ^
> > > In file included from
> > > ../src/gallium/state_trackers/clover/core/event.hpp:29,
> > > from
> > > ../src/gallium/state_trackers/clover/api/event.cpp:24:
> > > ../src/gallium/state_trackers/clover/core/object.hpp: In instantiation
> > > of ‘static void clover::detail::descriptor_traits::validate(D*)
> > > [with T = clover::soft_event; D = _cl_event]’:
> > > ../src/gallium/state_trackers/clover/core/object.hpp:148:48:
> > > required
> > > from ‘typename clover::detail::descriptor_traits::object_type&
> > > clover::obj(D*) [with T = clover::soft_event; D = _cl_event; typename
> > > clover::detail::descriptor_traits::object_type =
> > > clover::soft_event]’
> > > ../src/gallium/state_trackers/clover/api/event.cpp:42:36: required
> > > from here
> > > ../src/gallium/state_trackers/clover/core/object.hpp:72:18: error:
> > > ‘dynamic_cast’ not permitted with -fno-rtti
> > > !dynamic_cast(o))
> > >^~
> >
> > This looks like the -fno-rtti flags got there from 'llvm-config --
> > cxxflags'.
>
> Yes.
>
> /home/dieter> llvm-config --cxxflags
> -I/usr/local/include -std=c++11 -fno-exceptions -fno-rtti
> -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
> -D__STDC_LIMIT_MACROS
>
> > Clover makes use of rtti(as you've found out), and I'd say
> > that you need it in LLVM too.
> > Mixing Clover/rtti and llvm/no-rtti
> > would probably complain about missing symbols in llvm libraries.
>
> But why is this?
> My 'autotools' Mesa/Clover compilations worked for ages with my current
> LLVM settings.
It might be OK to just filter out the -fno-rtti flag. If the llvm's
rtti information is not used, it should work.
I honestly don't know what determines whether llvm's rtti info is used
or not. It might be ifdef/assert or anything else in the headers which
would get interpreted differently when building llvm vs. mesa.
I remember quite a lot of discussion about llvm-config not reporting
the flag correctly, and issues with rtti/no-rtti combination, at which
point I
Re: [Mesa-dev] [PATCH] radeonsi: don't use PFP_SYNC_ME with compute-only contexts
Reviewed-by: Samuel Pitoiset
On 4/2/19 12:37 AM, Marek Olšák wrote:
From: Marek Olšák
Fixes: a1378639ab1 "radeonsi: always use compute rings for clover on CI and newer
(v2)"
---
src/gallium/drivers/radeonsi/si_cp_dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_cp_dma.c
b/src/gallium/drivers/radeonsi/si_cp_dma.c
index 5993369d2da..f349325202c 100644
--- a/src/gallium/drivers/radeonsi/si_cp_dma.c
+++ b/src/gallium/drivers/radeonsi/si_cp_dma.c
@@ -124,21 +124,21 @@ static void si_emit_cp_dma(struct si_context *sctx,
struct radeon_cmdbuf *cs,
radeon_emit(cs, dst_va);/* DST_ADDR_LO [31:0] */
radeon_emit(cs, (dst_va >> 32) & 0x); /* DST_ADDR_HI [15:0]
*/
radeon_emit(cs, command);
}
/* CP DMA is executed in ME, but index buffers are read by PFP.
* This ensures that ME (CP DMA) is idle before PFP starts fetching
* indices. If we wanted to execute CP DMA in PFP, this packet
* should precede it.
*/
- if (flags & CP_DMA_PFP_SYNC_ME) {
+ if (sctx->has_graphics && flags & CP_DMA_PFP_SYNC_ME) {
radeon_emit(cs, PKT3(PKT3_PFP_SYNC_ME, 0, 0));
radeon_emit(cs, 0);
}
}
void si_cp_dma_wait_for_idle(struct si_context *sctx)
{
/* Issue a dummy DMA that copies zero bytes.
*
* The DMA engine will see that there's no work to do and skip this
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109939] After upgrade mesa to 19.0.0 stop working the game Rise of the Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=109939 --- Comment #25 from mikhail.v.gavri...@gmail.com --- Alex, can you look please at this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1694938 There about warning "Current CPU governor may impact performance" even when package gamemode is installed. Looks like affected only "Rise of the Tomb Raider" because with "DiRT 4" all ok. -- 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
