Re: [Mesa-dev] [PATCH 1/2] drisw: fix incomplete type compilation failure
Hi Brian, Both of these fixes: Reviewed-by: Mathias Fröhlich best Mathias On Friday, 8 March 2019 23:53:32 CET Brian Paul wrote: > Fixes: > ../src/gallium/winsys/sw/dri/dri_sw_winsys.c: In function > ‘dri_sw_displaytarget_display’: > ../src/gallium/winsys/sw/dri/dri_sw_winsys.c:255:39: error: dereferencing > pointer to incomplete type ‘struct pipe_box’ >offset = dri_sw_dt->stride * box->y; >^ > --- > src/gallium/winsys/sw/dri/dri_sw_winsys.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c > b/src/gallium/winsys/sw/dri/dri_sw_winsys.c > index c0200f9..3273813 100644 > --- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c > +++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c > @@ -35,6 +35,7 @@ > > #include "pipe/p_compiler.h" > #include "pipe/p_format.h" > +#include "pipe/p_state.h" > #include "util/u_inlines.h" > #include "util/u_format.h" > #include "util/u_math.h" > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/12] panfrost: Combine has_afbc/tiled in layout enum
AFBC, tiled, and linear BO layouts are mutually exclusive; they should
be coupled via a single enum rather than ad hoc checks of booleans.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 33 ++--
src/gallium/drivers/panfrost/pan_resource.c | 34 -
src/gallium/drivers/panfrost/pan_resource.h | 20 +---
3 files changed, 64 insertions(+), 23 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 4c41969fd05..630c41fbf1e 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -119,7 +119,7 @@ panfrost_enable_afbc(struct panfrost_context *ctx, struct
panfrost_resource *rsr
(rsrc->bo->afbc_metadata_size + main_size +
4095) / 4096,
true, 0, 0, 0);
-rsrc->bo->has_afbc = true;
+rsrc->bo->layout = PAN_AFBC;
/* Compressed textured reads use a tagged pointer to the metadata */
@@ -153,7 +153,7 @@ panfrost_set_fragment_afbc(struct panfrost_context *ctx)
struct panfrost_resource *rsrc = (struct panfrost_resource *)
ctx->pipe_framebuffer.cbufs[cb]->texture;
/* Non-AFBC is the default */
-if (!rsrc->bo->has_afbc)
+if (rsrc->bo->layout != PAN_AFBC)
continue;
if (require_sfbd) {
@@ -179,7 +179,7 @@ panfrost_set_fragment_afbc(struct panfrost_context *ctx)
if (ctx->pipe_framebuffer.zsbuf) {
struct panfrost_resource *rsrc = (struct panfrost_resource *)
ctx->pipe_framebuffer.zsbuf->texture;
-if (rsrc->bo->has_afbc) {
+if (rsrc->bo->layout == PAN_AFBC) {
if (require_sfbd) {
fprintf(stderr, "Depth AFBC not supported on
SFBD\n");
assert(0);
@@ -2244,6 +2244,23 @@ panfrost_create_sampler_view(
enum mali_format format = panfrost_find_format(desc);
+unsigned usage2_layout = 0x10;
+
+switch (prsrc->bo->layout) {
+case PAN_AFBC:
+usage2_layout |= 0xc;
+break;
+case PAN_TILED:
+usage2_layout |= 0x1;
+break;
+case PAN_LINEAR:
+usage2_layout |= 0x2;
+break;
+default:
+assert(0);
+break;
+}
+
struct mali_texture_descriptor texture_descriptor = {
.width = MALI_POSITIVE(texture->width0),
.height = MALI_POSITIVE(texture->height0),
@@ -2257,11 +2274,7 @@ panfrost_create_sampler_view(
.usage1 = 0x0,
.is_not_cubemap = 1,
-/* 0x11 - regular texture 2d, uncompressed tiled */
-/* 0x12 - regular texture 2d, uncompressed linear */
-/* 0x1c - AFBC compressed (internally tiled, probably)
texture 2D */
-
-.usage2 = prsrc->bo->has_afbc ? 0x1c :
(prsrc->bo->tiled ? 0x11 : 0x12),
+.usage2 = usage2_layout
},
.swizzle = panfrost_translate_swizzle_4(user_swizzle)
@@ -2353,7 +2366,7 @@ panfrost_set_framebuffer_state(struct pipe_context *pctx,
struct panfrost_resource *tex = ((struct panfrost_resource *)
ctx->pipe_framebuffer.cbufs[i]->texture);
bool is_scanout = panfrost_is_scanout(ctx);
-if (!is_scanout && !tex->bo->has_afbc) {
+if (!is_scanout && tex->bo->layout != PAN_AFBC) {
/* The blob is aggressive about enabling AFBC. As such,
* it's pretty much necessary to use it here, since we
* have no traces of non-compressed FBO. */
@@ -2387,7 +2400,7 @@ panfrost_set_framebuffer_state(struct pipe_context *pctx,
struct panfrost_resource *tex = ((struct
panfrost_resource *) ctx->pipe_framebuffer.zsbuf->texture);
-if (!tex->bo->has_afbc &&
!panfrost_is_scanout(ctx))
+if (tex->bo->layout != PAN_AFBC &&
!panfrost_is_scanout(ctx))
panfrost_enable_afbc(ctx, tex, true);
}
}
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index 7dfeb773d8b..0cebbdb6e51 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -195,10 +195,28 @@ panfrost_create_bo(struct panfrost_screen *screen, const
struct pipe_resource *t
if (template->height0) sz *=
[Mesa-dev] [PATCH 07/12] panfrost: Allocate dedicated slab for linear BOs
Previously, linear BOs shared memory with each other to minimize kernel
round-trips / latency, as well as to work around a bug in the free_slab
function. These concerns are invalid now, but continuing to use the slab
allocator for BOs resulted in memory allocation errors. This issue was
aggravated, though not introduced (so not a real regression) in the
previous commit.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 32 -
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index 39783f5a63a..0f11b8e5e38 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -248,14 +248,16 @@ panfrost_create_bo(struct panfrost_screen *screen, const
struct pipe_resource *t
sz >>= 2;
}
} else {
-/* But for linear, we can! */
+/* For a linear resource, allocate a block of memory from
+ * kernel space */
-struct pb_slab_entry *entry = pb_slab_alloc(>slabs,
sz, HEAP_TEXTURE);
-struct panfrost_memory_entry *p_entry = (struct
panfrost_memory_entry *) entry;
-struct panfrost_memory *backing = (struct panfrost_memory *)
entry->slab;
-bo->entry[0] = p_entry;
-bo->cpu[0] = backing->cpu + p_entry->offset;
-bo->gpu[0] = backing->gpu + p_entry->offset;
+struct panfrost_memory mem;
+
+unsigned pages = ((sz + 4095) / 4096) * 2;
+screen->driver->allocate_slab(screen, , pages, true, 0, 0,
0);
+
+bo->cpu[0] = mem.cpu;
+bo->gpu[0] = mem.gpu;
/* TODO: Mipmap */
}
@@ -325,12 +327,16 @@ panfrost_destroy_bo(struct panfrost_screen *screen,
struct panfrost_bo *pbo)
{
struct panfrost_bo *bo = (struct panfrost_bo *)pbo;
-for (int l = 0; l < MAX_MIP_LEVELS; ++l) {
-if (bo->entry[l] != NULL) {
-/* Most allocations have an entry to free */
-bo->entry[l]->freed = true;
-pb_slab_free(>slabs, >entry[l]->base);
-}
+if (bo->layout == PAN_LINEAR) {
+/* Construct a memory object for all mip levels */
+
+struct panfrost_memory mem = {
+.cpu = bo->cpu[0],
+.gpu = bo->gpu[0],
+.size = bo->imported_size
+};
+
+screen->driver->free_slab(screen, );
}
if (bo->layout == PAN_TILED) {
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/12] panfrost: Support linear depth buffers
Previously, only AFBC depth buffers were supported for writing; a
linear pseudo-depth-buffer was attached when clearing DEPTH but in
practice this was not actually used. Nevertheless, the hardware does
support honest-to-goodness linear depth buffers, which might be useful
at some point. If nothing else, having this implemented helps with
understanding the hardware, bringing to light some magic bits.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 30 +-
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 099d6d0389b..37f6ce4910f 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -246,6 +246,9 @@ panfrost_set_fragment_target_zsbuf(
{
struct panfrost_resource *rsrc = pan_resource(surf->texture);
+unsigned stride =
+util_format_get_stride(surf->format, surf->texture->width0);
+
if (rsrc->bo->layout == PAN_AFBC) {
/* TODO: AFBC on SFBD */
assert(!require_sfbd);
@@ -260,16 +263,27 @@ panfrost_set_fragment_target_zsbuf(
ctx->fragment_extra.ds_afbc.zero1 = 0x10009;
ctx->fragment_extra.ds_afbc.padding = 0x1000;
-/* There's a general 0x400 in all versions of this field scene.
+/* There's a general 0x400 in all versions of this field seen.
* ORed with 0x5 for depth/stencil. ORed 0x10 for AFBC encoded
- * depth stencil. It's unclear where the remaining 0x20 bit is
- * from */
+ * depth stencil -- er, no. It's unclear where the remaining
0x20 bit
+ * is from, checksumming maybe? */
ctx->fragment_extra.unk = 0x400 | 0x20 | 0x10 | 0x5;
ctx->fragment_mfbd.unk3 |= 0x400;
} else if (rsrc->bo->layout == PAN_LINEAR) {
-/* TODO */
+/* TODO: explicit depth on SFBD */
+assert(!require_sfbd);
+
+/* Setup combined 24/8 depth/stencil */
+ctx->fragment_mfbd.unk3 |= MALI_MFBD_EXTRA;
+
+ctx->fragment_extra.unk = 0x404;
+ctx->fragment_extra.ds_linear.depth = rsrc->bo->gpu[0];
+ctx->fragment_extra.ds_linear.depth_stride = stride;
+
+/* Seemingly means "write to depth buffer" */
+ctx->fragment_mfbd.unk3 |= 0x400;
} else {
fprintf(stderr, "Invalid render layout (zsbuf)");
assert(0);
@@ -525,14 +539,6 @@ panfrost_clear_mfbd(struct panfrost_job *job)
if (job->clear & PIPE_CLEAR_STENCIL) {
buffer_ds->clear_stencil = job->clear_stencil;
}
-
-if (job->clear & (PIPE_CLEAR_DEPTH | PIPE_CLEAR_STENCIL)) {
-/* Setup combined 24/8 depth/stencil */
-ctx->fragment_mfbd.unk3 |= MALI_MFBD_EXTRA;
-ctx->fragment_extra.unk = 0x405;
-ctx->fragment_extra.ds_linear.depth =
ctx->depth_stencil_buffer.gpu;
-ctx->fragment_extra.ds_linear.depth_stride =
ctx->pipe_framebuffer.width * 4;
-}
}
static void
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/12] panfrost: Identify fragment_extra flags
The fragment_extra structure contains additional fields extending the
MRT framebuffer descriptor, snuck in between the main framebuffer
descriptor and the render targets. Its fields include those related to
transaction elimination and depth/stencil buffers. This patch identifies
the flags field (previously just "unk" with some magic values) as well
as identifying some (but not all) flags set by the driver.
The process of identifying flags brought a bug to light where
transaction elimination (checksumming) could not be enabled unless AFBC
was in-use. This issue is now resolved.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/include/panfrost-job.h| 8 +++-
src/gallium/drivers/panfrost/pan_context.c | 16
.../drivers/panfrost/pandecode/decode.c| 18 +-
3 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h
b/src/gallium/drivers/panfrost/include/panfrost-job.h
index 3c5ed2bc802..dccd8410ae9 100644
--- a/src/gallium/drivers/panfrost/include/panfrost-job.h
+++ b/src/gallium/drivers/panfrost/include/panfrost-job.h
@@ -1419,12 +1419,18 @@ struct bifrost_render_target {
* - TODO: Anything else?
*/
+/* Flags */
+#define MALI_EXTRA_PRESENT (0x400)
+#define MALI_EXTRA_AFBC (0x20)
+#define MALI_EXTRA_AFBC_ZS (0x10)
+#define MALI_EXTRA_ZS (0x4)
+
struct bifrost_fb_extra {
mali_ptr checksum;
/* Each tile has an 8 byte checksum, so the stride is "width in tiles
* 8" */
u32 checksum_stride;
-u32 unk;
+u32 flags;
union {
/* Note: AFBC is only allowed for 24/8 combined depth/stencil.
*/
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 419c1a4eb6f..cdced27f101 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -263,12 +263,12 @@ panfrost_set_fragment_target_zsbuf(
ctx->fragment_extra.ds_afbc.zero1 = 0x10009;
ctx->fragment_extra.ds_afbc.padding = 0x1000;
-/* There's a general 0x400 in all versions of this field seen.
- * ORed with 0x5 for depth/stencil. ORed 0x10 for AFBC encoded
- * depth stencil -- er, no. It's unclear where the remaining
0x20 bit
- * is from, checksumming maybe? */
-
-ctx->fragment_extra.unk = 0x400 | 0x20 | 0x10 | 0x5;
+ctx->fragment_extra.flags =
+MALI_EXTRA_PRESENT |
+MALI_EXTRA_AFBC |
+MALI_EXTRA_AFBC_ZS |
+MALI_EXTRA_ZS |
+0x1; /* unknown */
ctx->fragment_mfbd.unk3 |= MALI_MFBD_DEPTH_WRITE;
} else if (rsrc->bo->layout == PAN_LINEAR) {
@@ -278,7 +278,7 @@ panfrost_set_fragment_target_zsbuf(
/* Setup combined 24/8 depth/stencil */
ctx->fragment_mfbd.unk3 |= MALI_MFBD_EXTRA;
-ctx->fragment_extra.unk = 0x404;
+ctx->fragment_extra.flags = MALI_EXTRA_PRESENT | MALI_EXTRA_ZS;
ctx->fragment_extra.ds_linear.depth = rsrc->bo->gpu[0];
ctx->fragment_extra.ds_linear.depth_stride = stride;
@@ -1027,7 +1027,7 @@ panfrost_fragment_job(struct panfrost_context *ctx)
int stride = util_format_get_stride(rsrc->base.format,
rsrc->base.width0);
ctx->fragment_mfbd.unk3 |= MALI_MFBD_EXTRA;
-ctx->fragment_extra.unk |= 0x420;
+ctx->fragment_extra.flags |= MALI_EXTRA_PRESENT;
ctx->fragment_extra.checksum_stride =
rsrc->bo->checksum_stride;
ctx->fragment_extra.checksum = rsrc->bo->gpu[0] +
stride * rsrc->base.height0;
}
diff --git a/src/gallium/drivers/panfrost/pandecode/decode.c
b/src/gallium/drivers/panfrost/pandecode/decode.c
index ea635bbe981..e6932744939 100644
--- a/src/gallium/drivers/panfrost/pandecode/decode.c
+++ b/src/gallium/drivers/panfrost/pandecode/decode.c
@@ -209,6 +209,15 @@ static const struct pandecode_flag_info
mfbd_fmt_flag_info[] = {
};
#undef FLAG_INFO
+#define FLAG_INFO(flag) { MALI_EXTRA_##flag, "MALI_EXTRA_" #flag }
+static const struct pandecode_flag_info mfbd_extra_flag_info[] = {
+FLAG_INFO(PRESENT),
+FLAG_INFO(AFBC),
+FLAG_INFO(ZS),
+{}
+};
+#undef FLAG_INFO
+
extern char *replace_fragment;
extern char *replace_vertex;
@@ -604,12 +613,11 @@ pandecode_replay_mfbd_bfr(uint64_t gpu_va, int job_no)
if (fbx->checksum_stride)
pandecode_prop("checksum_stride = %d",
fbx->checksum_stride);
-pandecode_prop("unk = 0x%x", fbx->unk);
+pandecode_log(".flags = ");
+
[Mesa-dev] [PATCH 12/12] panfrost: Make hacks a little more obvious
To be clear, the layout switching voodoo is still a hack that needs to
be cleaned up. But that's a job as big as this patch series always-is,
so at least explain _why_ we're working counterintuitively.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index 0f11b8e5e38..bf2e40e3086 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -212,12 +212,18 @@ panfrost_best_layout(const struct pipe_resource *rsrc)
PIPE_BIND_BLENDABLE;
if (rsrc->bind & renderable_bind) {
-/* TODO: AFBC */
-return PAN_LINEAR;
-} else if (rsrc->bind & PIPE_BIND_SAMPLER_VIEW) {
-return PAN_TILED;
+/* TODO: AFBC. Currently, on render we switch to AFBC. This is
+ * a hack, but the correct solution (deferring layout selection
+ * explicitly, switching upon any constrained use, shadowing if
+ * necessary) is a lot more complex than needed right now. So
+ * for now, pretend we're always regular textures;
+ * set_framebuffer_state has a hack to flip on AFBC later if
+ * strictly necessary */
}
+if (rsrc->bind & PIPE_BIND_SAMPLER_VIEW)
+return PAN_TILED;
+
/* If all else fails, we default to linear */
return PAN_LINEAR;
@@ -253,7 +259,7 @@ panfrost_create_bo(struct panfrost_screen *screen, const
struct pipe_resource *t
struct panfrost_memory mem;
-unsigned pages = ((sz + 4095) / 4096) * 2;
+unsigned pages = ((sz + 4095) / 4096);
screen->driver->allocate_slab(screen, , pages, true, 0, 0,
0);
bo->cpu[0] = mem.cpu;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/12] panfrost: Document "depth buffer writeback" bit
We were setting this bit as a magic value for a while when using depth
FBOs, but it is only now clear what the meaning is.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/include/panfrost-job.h | 8
src/gallium/drivers/panfrost/pan_context.c | 5 ++---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h
b/src/gallium/drivers/panfrost/include/panfrost-job.h
index d719325d07b..3c5ed2bc802 100644
--- a/src/gallium/drivers/panfrost/include/panfrost-job.h
+++ b/src/gallium/drivers/panfrost/include/panfrost-job.h
@@ -1457,6 +1457,14 @@ struct bifrost_fb_extra {
} __attribute__((packed));
/* flags for unk3 */
+
+/* Enables writing depth results back to main memory (rather than keeping them
+ * on-chip in the tile buffer and then discarding) */
+
+#define MALI_MFBD_DEPTH_WRITE (1 << 10)
+
+/* The MFBD contains the extra bifrost_fb_extra section*/
+
#define MALI_MFBD_EXTRA (1 << 13)
struct bifrost_framebuffer {
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 37f6ce4910f..419c1a4eb6f 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -270,7 +270,7 @@ panfrost_set_fragment_target_zsbuf(
ctx->fragment_extra.unk = 0x400 | 0x20 | 0x10 | 0x5;
-ctx->fragment_mfbd.unk3 |= 0x400;
+ctx->fragment_mfbd.unk3 |= MALI_MFBD_DEPTH_WRITE;
} else if (rsrc->bo->layout == PAN_LINEAR) {
/* TODO: explicit depth on SFBD */
assert(!require_sfbd);
@@ -282,8 +282,7 @@ panfrost_set_fragment_target_zsbuf(
ctx->fragment_extra.ds_linear.depth = rsrc->bo->gpu[0];
ctx->fragment_extra.ds_linear.depth_stride = stride;
-/* Seemingly means "write to depth buffer" */
-ctx->fragment_mfbd.unk3 |= 0x400;
+ctx->fragment_mfbd.unk3 |= MALI_MFBD_DEPTH_WRITE;
} else {
fprintf(stderr, "Invalid render layout (zsbuf)");
assert(0);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/12] panfrost: Determine framebuffer format bits late
Again, these formats are only properly known at the time of fragment job
emit. Rather than hardcoding the format, at least for MFBD we begin to
construct the format bits on-demand. This cleans up the code,
futureproofs for ES3 framebuffer formats, and should fix bugs regarding
FBO colour swizzles.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 59 +++---
1 file changed, 42 insertions(+), 17 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index d54b3df5962..9db667d8287 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -143,6 +143,35 @@ panfrost_enable_checksum(struct panfrost_context *ctx,
struct panfrost_resource
rsrc->bo->has_checksum = true;
}
+static unsigned
+panfrost_sfbd_format_for_surface(struct pipe_surface *surf)
+{
+/* TODO */
+return 0xb84e0281; /* RGB32, no MSAA */
+}
+
+static struct mali_rt_format
+panfrost_mfbd_format_for_surface(struct pipe_surface *surf)
+{
+/* Explode details on the format */
+
+const struct util_format_description *desc =
+util_format_description(surf->texture->format);
+
+/* Fill in accordingly */
+
+struct mali_rt_format fmt = {
+.unk1 = 0x400,
+.unk2 = 0x1,
+.nr_channels = MALI_POSITIVE(desc->nr_channels),
+.flags = 0x444,
+.swizzle = panfrost_translate_swizzle_4(desc->swizzle),
+.unk4 = 0x8
+};
+
+return fmt;
+}
+
static bool panfrost_is_scanout(struct panfrost_context *ctx);
/* These routines link a fragment job with the bound surface, accounting for
the
@@ -159,6 +188,18 @@ panfrost_set_fragment_target_cbuf(
signed stride =
util_format_get_stride(surf->format, surf->texture->width0);
+/* First, we set the format bits */
+
+if (require_sfbd) {
+ctx->fragment_sfbd.format =
+panfrost_sfbd_format_for_surface(surf);
+} else {
+ctx->fragment_rts[cb].format =
+panfrost_mfbd_format_for_surface(surf);
+}
+
+/* Now, we set the layout specific pieces */
+
if (rsrc->bo->layout == PAN_LINEAR) {
mali_ptr framebuffer = rsrc->bo->gpu[0];
@@ -392,7 +433,6 @@ panfrost_new_frag_framebuffer(struct panfrost_context *ctx)
{
if (require_sfbd) {
struct mali_single_framebuffer fb = panfrost_emit_sfbd(ctx);
-fb.format = 0xb84e0281; /* RGB32, no MSAA */
memcpy(>fragment_sfbd, , sizeof(fb));
} else {
struct bifrost_framebuffer fb = panfrost_emit_mfbd(ctx);
@@ -401,24 +441,9 @@ panfrost_new_frag_framebuffer(struct panfrost_context *ctx)
fb.rt_count_2 = 1;
fb.unk3 = 0x100;
-/* By default, Gallium seems to need a BGR framebuffer */
-unsigned char bgra[4] = {
-PIPE_SWIZZLE_Z, PIPE_SWIZZLE_Y, PIPE_SWIZZLE_X,
PIPE_SWIZZLE_W
-};
-
-struct bifrost_render_target rt = {
-.format = {
-.unk1 = 0x400,
-.unk2 = 0x1,
-.nr_channels = MALI_POSITIVE(4),
-.flags = 0x444,
-.swizzle = panfrost_translate_swizzle_4(bgra),
-.unk4 = 0x8
-},
-};
+struct bifrost_render_target rt = {};
memcpy(>fragment_rts[0], , sizeof(rt));
-
memset(>fragment_extra, 0, sizeof(ctx->fragment_extra));
memcpy(>fragment_mfbd, , sizeof(fb));
}
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/12] panfrost: Support linear depth textures
This combination has not yet been seen "in the wild" in traces, but to
support linear depth FBOs, ~bruteforce reveals this bit pattern is
necessary. It's not yet clear why the meanings of 0x1 and 0x2 are
essentially flipped (tiled vs linear for colour, linear vs some sort of
tiled for depth).
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 9db667d8287..099d6d0389b 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -2289,17 +2289,19 @@ panfrost_create_sampler_view(
enum mali_format format = panfrost_find_format(desc);
+bool is_depth = desc->format == PIPE_FORMAT_Z32_UNORM;
+
unsigned usage2_layout = 0x10;
switch (prsrc->bo->layout) {
case PAN_AFBC:
-usage2_layout |= 0xc;
+usage2_layout |= 0x8 | 0x4;
break;
case PAN_TILED:
usage2_layout |= 0x1;
break;
case PAN_LINEAR:
-usage2_layout |= 0x2;
+usage2_layout |= is_depth ? 0x1 : 0x2;
break;
default:
assert(0);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 00/12] Refactors related to BO layouts
Midgard supports (at least) 3 broad classes of resource layouts: * Linear: slow, but universally supported, uncompressed * Tiled: good for cache efficiency, uncompressed * Arm Framebuffer Compression (AFBC): tiled and compressed We can't render into tiled buffers (for technical reasons), and we can't manipulate AFBC from software (for practical reasons). But we can do a little better at formalizing the distinctions between these formats and implementing some edge cases. For instance, this series fixes support for linear FBOs (previously, only AFBC was supported). More work is needed to let layouts switch seemlessly to handle edge cases, but this series is already a nontrivial improvement (and it *is* getting long). Alyssa Rosenzweig (12): panfrost: Cleanup needless if in create_bo panfrost: Combine has_afbc/tiled in layout enum panfrost: Delay color buffer setup panfrost: Cleanup zsbuf emit in fragment job panfrost: Determine framebuffer format bits late panfrost: Refactor layout selection (BO creation) panfrost: Allocate dedicated slab for linear BOs panfrost: Support linear depth textures panfrost: Support linear depth buffers panfrost: Document "depth buffer writeback" bit panfrost: Identify fragment_extra flags panfrost: Make hacks a little more obvious .../drivers/panfrost/include/panfrost-job.h | 16 +- src/gallium/drivers/panfrost/pan_context.c| 267 +++--- src/gallium/drivers/panfrost/pan_resource.c | 154 ++ src/gallium/drivers/panfrost/pan_resource.h | 20 +- .../drivers/panfrost/pandecode/decode.c | 18 +- 5 files changed, 311 insertions(+), 164 deletions(-) -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/12] panfrost: Refactor layout selection (BO creation)
With a unified layout field, we can specify the logic for BO layout
explicitly, deciding between linear/tiled/AFBC based on the specified
usage/binding flags.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 64 ++---
1 file changed, 44 insertions(+), 20 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index 0cebbdb6e51..39783f5a63a 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -181,6 +181,48 @@ panfrost_surface_destroy(struct pipe_context *pipe,
free(surf);
}
+/* Based on the usage, figure out what storing will be used. There are
+ * various tradeoffs:
+ *
+ * Linear: the basic format, bad for memory bandwidth, bad for cache
+ * use. Zero-copy, though. Renderable.
+ *
+ * Tiled: Not compressed, but cache-optimized. Expensive to write into
+ * (due to software tiling), but cheap to sample from. Ideal for most
+ * textures.
+ *
+ * AFBC: Compressed and renderable (so always desirable for non-scanout
+ * rendertargets). Cheap to sample from. The format is black box, so we
+ * can't read/write from software.
+ */
+
+static enum panfrost_memory_layout
+panfrost_best_layout(const struct pipe_resource *rsrc)
+{
+/* For streaming, optimize for CPU write since it's one-use */
+
+if (rsrc->usage == PIPE_USAGE_STREAM)
+return PAN_LINEAR;
+
+/* Legal formats depends if we're renderable */
+
+unsigned renderable_bind =
+PIPE_BIND_DEPTH_STENCIL |
+PIPE_BIND_RENDER_TARGET |
+PIPE_BIND_BLENDABLE;
+
+if (rsrc->bind & renderable_bind) {
+/* TODO: AFBC */
+return PAN_LINEAR;
+} else if (rsrc->bind & PIPE_BIND_SAMPLER_VIEW) {
+return PAN_TILED;
+}
+
+/* If all else fails, we default to linear */
+
+return PAN_LINEAR;
+}
+
static struct panfrost_bo *
panfrost_create_bo(struct panfrost_screen *screen, const struct pipe_resource
*template)
{
@@ -195,26 +237,8 @@ panfrost_create_bo(struct panfrost_screen *screen, const
struct pipe_resource *t
if (template->height0) sz *= template->height0;
if (template->depth0) sz *= template->depth0;
-/* Based on the usage, figure out what storing will be used. There are
- * various tradeoffs:
- *
- * Linear: the basic format, bad for memory bandwidth, bad for cache
- * use. Zero-copy, though. Renderable.
- *
- * Tiled: Not compressed, but cache-optimized. Expensive to write into
- * (due to software tiling), but cheap to sample from. Ideal for most
- * textures.
- *
- * AFBC: Compressed and renderable (so always desirable for non-scanout
- * rendertargets). Cheap to sample from. The format is black box, so we
- * can't read/write from software.
- */
-
-/* Tiling textures is almost always faster, unless we only use it once
*/
-bool should_tile = (template->usage != PIPE_USAGE_STREAM) &&
(template->bind & PIPE_BIND_SAMPLER_VIEW);
-
-/* Set the layout appropriately */
-bo->layout = should_tile ? PAN_TILED : PAN_LINEAR;
+bo->imported_size = sz;
+bo->layout = panfrost_best_layout(template);
if (bo->layout == PAN_TILED) {
/* For tiled, we don't map directly, so just malloc any old
buffer */
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/12] panfrost: Delay color buffer setup
In an effort to cleanup framebuffer management code, we delay
colour buffer setup until the FRAGMENT job is actually emitted, allowing
the AFBC and linear codepaths to be unified.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 93 --
1 file changed, 50 insertions(+), 43 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 630c41fbf1e..71634c781a3 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -143,36 +143,67 @@ panfrost_enable_checksum(struct panfrost_context *ctx,
struct panfrost_resource
rsrc->bo->has_checksum = true;
}
-/* ..by contrast, this routine runs for every FRAGMENT job, but does no
- * allocation. AFBC is enabled on a per-surface basis */
+static bool panfrost_is_scanout(struct panfrost_context *ctx);
+
+/* These routines link a fragment job with the bound surface, accounting for
the
+ * BO layout. This routine runs per-frame */
static void
-panfrost_set_fragment_afbc(struct panfrost_context *ctx)
+panfrost_set_fragment_target_cbuf(
+struct panfrost_context *ctx,
+struct pipe_surface *surf,
+unsigned cb)
{
-for (int cb = 0; cb < ctx->pipe_framebuffer.nr_cbufs; ++cb) {
-struct panfrost_resource *rsrc = (struct panfrost_resource *)
ctx->pipe_framebuffer.cbufs[cb]->texture;
+struct panfrost_resource *rsrc = pan_resource(surf->texture);
-/* Non-AFBC is the default */
-if (rsrc->bo->layout != PAN_AFBC)
-continue;
+signed stride =
+util_format_get_stride(surf->format, surf->texture->width0);
+
+if (rsrc->bo->layout == PAN_LINEAR) {
+mali_ptr framebuffer = rsrc->bo->gpu[0];
+
+/* The default is upside down from OpenGL's perspective. */
+if (panfrost_is_scanout(ctx)) {
+framebuffer += stride * (surf->texture->height0 - 1);
+stride = -stride;
+}
if (require_sfbd) {
-fprintf(stderr, "Color AFBC not supported on SFBD\n");
-assert(0);
+ctx->fragment_sfbd.framebuffer = framebuffer;
+ctx->fragment_sfbd.stride = stride;
+} else {
+/* MFBD specifies stride in tiles */
+ctx->fragment_rts[cb].framebuffer = framebuffer;
+ctx->fragment_rts[cb].framebuffer_stride = stride / 16;
}
+} else if (rsrc->bo->layout == PAN_AFBC) {
+/* TODO: AFBC on SFBD */
+assert(!require_sfbd);
/* Enable AFBC for the render target */
-ctx->fragment_rts[0].afbc.metadata = rsrc->bo->afbc_slab.gpu;
-ctx->fragment_rts[0].afbc.stride = 0;
-ctx->fragment_rts[0].afbc.unk = 0x30009;
+ctx->fragment_rts[cb].afbc.metadata = rsrc->bo->afbc_slab.gpu;
+ctx->fragment_rts[cb].afbc.stride = 0;
+ctx->fragment_rts[cb].afbc.unk = 0x30009;
+
+ctx->fragment_rts[cb].format.flags |= MALI_MFBD_FORMAT_AFBC;
-ctx->fragment_rts[0].format.flags |= MALI_MFBD_FORMAT_AFBC;
+mali_ptr afbc_main = rsrc->bo->afbc_slab.gpu +
rsrc->bo->afbc_metadata_size;
+ctx->fragment_rts[cb].framebuffer = afbc_main;
-/* Point rendering to our special framebuffer */
-ctx->fragment_rts[0].framebuffer = rsrc->bo->afbc_slab.gpu +
rsrc->bo->afbc_metadata_size;
+/* TODO: Investigate shift */
+ctx->fragment_rts[cb].framebuffer_stride = stride << 1;
+} else {
+fprintf(stderr, "Invalid render layout (cbuf %d)", cb);
+assert(0);
+}
+}
-/* WAT? Stride is diff from the scanout case */
-ctx->fragment_rts[0].framebuffer_stride =
ctx->pipe_framebuffer.width * 2 * 4;
+static void
+panfrost_set_fragment_target(struct panfrost_context *ctx)
+{
+for (int cb = 0; cb < ctx->pipe_framebuffer.nr_cbufs; ++cb) {
+struct pipe_surface *surf = ctx->pipe_framebuffer.cbufs[cb];
+panfrost_set_fragment_target_cbuf(ctx, surf, cb);
}
/* Enable depth/stencil AFBC for the framebuffer (not the render
target) */
@@ -346,30 +377,8 @@ panfrost_is_scanout(struct panfrost_context *ctx)
static void
panfrost_new_frag_framebuffer(struct panfrost_context *ctx)
{
-mali_ptr framebuffer;
-int stride;
-
-if (ctx->pipe_framebuffer.nr_cbufs > 0) {
- framebuffer = ((struct panfrost_resource *)
ctx->pipe_framebuffer.cbufs[0]->texture)->bo->gpu[0];
-stride =
[Mesa-dev] [PATCH 01/12] panfrost: Cleanup needless if in create_bo
I'm not sure why we were checking for these additional criteria (likely
inherited from some other driver); remove the needless checks to cleanup
the code and perhaps fix some bugs down the line.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 56 ++---
1 file changed, 26 insertions(+), 30 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index f26f33db96b..7dfeb773d8b 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -246,37 +246,33 @@ panfrost_resource_create(struct pipe_screen *screen,
assert(0);
}
-if ((template->bind & PIPE_BIND_RENDER_TARGET) || (template->bind &
PIPE_BIND_DEPTH_STENCIL)) {
-if (template->bind & PIPE_BIND_DISPLAY_TARGET ||
-template->bind & PIPE_BIND_SCANOUT ||
-template->bind & PIPE_BIND_SHARED) {
-struct pipe_resource scanout_templat = *template;
-struct renderonly_scanout *scanout;
-struct winsys_handle handle;
-
-/* TODO: align width0 and height0? */
-
-scanout =
renderonly_scanout_for_resource(_templat,
- pscreen->ro,
);
-if (!scanout)
-return NULL;
-
-assert(handle.type == WINSYS_HANDLE_TYPE_FD);
-/* TODO: handle modifiers? */
-so = pan_resource(screen->resource_from_handle(screen,
template,
-
,
-
PIPE_HANDLE_USAGE_FRAMEBUFFER_WRITE));
-close(handle.handle);
-if (!so)
-return NULL;
-
-so->scanout = scanout;
-pscreen->display_target = so;
-} else {
- so->bo = panfrost_create_bo(pscreen, template);
-}
+if (template->bind & PIPE_BIND_DISPLAY_TARGET ||
+template->bind & PIPE_BIND_SCANOUT ||
+template->bind & PIPE_BIND_SHARED) {
+struct pipe_resource scanout_templat = *template;
+struct renderonly_scanout *scanout;
+struct winsys_handle handle;
+
+/* TODO: align width0 and height0? */
+
+scanout = renderonly_scanout_for_resource(_templat,
+ pscreen->ro,
);
+if (!scanout)
+return NULL;
+
+assert(handle.type == WINSYS_HANDLE_TYPE_FD);
+/* TODO: handle modifiers? */
+so = pan_resource(screen->resource_from_handle(screen,
template,
+ ,
+
PIPE_HANDLE_USAGE_FRAMEBUFFER_WRITE));
+close(handle.handle);
+if (!so)
+return NULL;
+
+so->scanout = scanout;
+pscreen->display_target = so;
} else {
- so->bo = panfrost_create_bo(pscreen, template);
+so->bo = panfrost_create_bo(pscreen, template);
}
return (struct pipe_resource *)so;
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/12] panfrost: Cleanup zsbuf emit in fragment job
This emit is only implemented for AFBC depth/stencil buffers, so
conceptually there is no change here, but we follow the style of the
previous patch to improve robustness and clarity.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 71 +-
1 file changed, 42 insertions(+), 29 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 71634c781a3..d54b3df5962 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -199,46 +199,61 @@ panfrost_set_fragment_target_cbuf(
}
static void
-panfrost_set_fragment_target(struct panfrost_context *ctx)
+panfrost_set_fragment_target_zsbuf(
+struct panfrost_context *ctx,
+struct pipe_surface *surf)
{
-for (int cb = 0; cb < ctx->pipe_framebuffer.nr_cbufs; ++cb) {
-struct pipe_surface *surf = ctx->pipe_framebuffer.cbufs[cb];
-panfrost_set_fragment_target_cbuf(ctx, surf, cb);
-}
+struct panfrost_resource *rsrc = pan_resource(surf->texture);
-/* Enable depth/stencil AFBC for the framebuffer (not the render
target) */
-if (ctx->pipe_framebuffer.zsbuf) {
-struct panfrost_resource *rsrc = (struct panfrost_resource *)
ctx->pipe_framebuffer.zsbuf->texture;
+if (rsrc->bo->layout == PAN_AFBC) {
+/* TODO: AFBC on SFBD */
+assert(!require_sfbd);
-if (rsrc->bo->layout == PAN_AFBC) {
-if (require_sfbd) {
-fprintf(stderr, "Depth AFBC not supported on
SFBD\n");
-assert(0);
-}
+ctx->fragment_mfbd.unk3 |= MALI_MFBD_EXTRA;
-ctx->fragment_mfbd.unk3 |= MALI_MFBD_EXTRA;
+ctx->fragment_extra.ds_afbc.depth_stencil_afbc_metadata =
rsrc->bo->afbc_slab.gpu;
+ctx->fragment_extra.ds_afbc.depth_stencil_afbc_stride = 0;
-
ctx->fragment_extra.ds_afbc.depth_stencil_afbc_metadata =
rsrc->bo->afbc_slab.gpu;
-ctx->fragment_extra.ds_afbc.depth_stencil_afbc_stride
= 0;
+ctx->fragment_extra.ds_afbc.depth_stencil =
rsrc->bo->afbc_slab.gpu + rsrc->bo->afbc_metadata_size;
-ctx->fragment_extra.ds_afbc.depth_stencil =
rsrc->bo->afbc_slab.gpu + rsrc->bo->afbc_metadata_size;
+ctx->fragment_extra.ds_afbc.zero1 = 0x10009;
+ctx->fragment_extra.ds_afbc.padding = 0x1000;
-ctx->fragment_extra.ds_afbc.zero1 = 0x10009;
-ctx->fragment_extra.ds_afbc.padding = 0x1000;
+/* There's a general 0x400 in all versions of this field scene.
+ * ORed with 0x5 for depth/stencil. ORed 0x10 for AFBC encoded
+ * depth stencil. It's unclear where the remaining 0x20 bit is
+ * from */
-ctx->fragment_extra.unk = 0x435; /* General 0x400 in
all unks. 0x5 for depth/stencil. 0x10 for AFBC encoded depth stencil. Unclear
where the 0x20 is from */
+ctx->fragment_extra.unk = 0x400 | 0x20 | 0x10 | 0x5;
-ctx->fragment_mfbd.unk3 |= 0x400;
-}
+ctx->fragment_mfbd.unk3 |= 0x400;
+} else if (rsrc->bo->layout == PAN_LINEAR) {
+/* TODO */
+} else {
+fprintf(stderr, "Invalid render layout (zsbuf)");
+assert(0);
}
+}
-/* For the special case of a depth-only FBO, we need to attach a dummy
render target */
+static void
+panfrost_set_fragment_target(struct panfrost_context *ctx)
+{
+for (int cb = 0; cb < ctx->pipe_framebuffer.nr_cbufs; ++cb) {
+struct pipe_surface *surf = ctx->pipe_framebuffer.cbufs[cb];
+panfrost_set_fragment_target_cbuf(ctx, surf, cb);
+}
+
+if (ctx->pipe_framebuffer.zsbuf) {
+struct pipe_surface *surf = ctx->pipe_framebuffer.zsbuf;
+panfrost_set_fragment_target_zsbuf(ctx, surf);
+
+ }
+
+/* There must always be at least one render-target, so attach a dummy
+ * if necessary */
if (ctx->pipe_framebuffer.nr_cbufs == 0) {
-if (require_sfbd) {
-fprintf(stderr, "Depth-only FBO not supported on
SFBD\n");
-assert(0);
-}
+assert(!require_sfbd);
struct mali_rt_format null_rt = {
.unk1 = 0x400,
@@ -246,8 +261,6 @@ panfrost_set_fragment_target(struct panfrost_context *ctx)
};
ctx->fragment_rts[0].format = null_rt;
-ctx->fragment_rts[0].framebuffer = 0;
-
[Mesa-dev] [Bug 109535] [Tracker] Mesa 19.0 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=109535 Cristian Aravena changed: What|Removed |Added CC||carav...@gmail.com -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/5] d3dadapter9: Support software renderer on any DRI device
After pushing this (with my r-b), gitlab's travis complained.
It seems there needs to be some ifdefs to check if kms was built.
I reverted the patch until it is fixed.
Axel
On 07/03/2019 23:23, Axel Davy wrote:
From: Patrick Rudolph
If D3D_ALWAYS_SOFTWARE is set for debugging purposes,
run on any DRI enabled platform.
Instead of probing for a compatible gallium driver (which might
fail if there's none) always use the KMS DRI software renderer.
Allows to run nine on i915 when D3D_ALWAYS_SOFTWARE=1.
Signed-off-by: Patrick Rudolph
---
src/gallium/targets/d3dadapter9/drm.c | 28 +++
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/src/gallium/targets/d3dadapter9/drm.c
b/src/gallium/targets/d3dadapter9/drm.c
index 1d01d4a067c..28dbd2ef9db 100644
--- a/src/gallium/targets/d3dadapter9/drm.c
+++ b/src/gallium/targets/d3dadapter9/drm.c
@@ -205,6 +205,7 @@ drm_create_adapter( int fd,
struct d3dadapter9drm_context *ctx =
CALLOC_STRUCT(d3dadapter9drm_context);
HRESULT hr;
bool different_device;
+bool software_device;
const struct drm_conf_ret *throttle_ret = NULL;
const struct drm_conf_ret *dmabuf_ret = NULL;
driOptionCache defaultInitOptions;
@@ -222,7 +223,11 @@ drm_create_adapter( int fd,
ctx->fd = fd;
ctx->base.linear_framebuffer = different_device;
-if (!pipe_loader_drm_probe_fd(>dev, fd)) {
+const char *force_sw = getenv("D3D_ALWAYS_SOFTWARE");
+software_device = force_sw && !strcmp(force_sw, "1");
+
+if ((software_device && !pipe_loader_sw_probe_kms(>dev, fd)) ||
+(!software_device && !pipe_loader_drm_probe_fd(>dev, fd))) {
ERR("Failed to probe drm fd %d.\n", fd);
FREE(ctx);
close(fd);
@@ -236,13 +241,20 @@ drm_create_adapter( int fd,
return D3DERR_DRIVERINTERNALERROR;
}
-dmabuf_ret = pipe_loader_configuration(ctx->dev, DRM_CONF_SHARE_FD);
-throttle_ret = pipe_loader_configuration(ctx->dev, DRM_CONF_THROTTLE);
-if (!dmabuf_ret || !dmabuf_ret->val.val_bool) {
-ERR("The driver is not capable of dma-buf sharing."
-"Abandon to load nine state tracker\n");
-drm_destroy(>base);
-return D3DERR_DRIVERINTERNALERROR;
+if (!software_device) {
+/*
+ * The software renderer isn't a DRM device and doesn't support
+ * pipe_loader_configuration.
+ * The KMS winsys supports SHARE_FD, so skip this check.
+ */
+dmabuf_ret = pipe_loader_configuration(ctx->dev, DRM_CONF_SHARE_FD);
+throttle_ret = pipe_loader_configuration(ctx->dev, DRM_CONF_THROTTLE);
+if (!dmabuf_ret || !dmabuf_ret->val.val_bool) {
+ERR("The driver is not capable of dma-buf sharing."
+"Abandon to load nine state tracker\n");
+drm_destroy(>base);
+return D3DERR_DRIVERINTERNALERROR;
+}
}
if (throttle_ret && throttle_ret->val.val_int != -1) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] st/nine: Disable depth write when nothing gets updated
On 08/03/2019 07:26, Kenneth Graunke wrote: On Thursday, March 7, 2019 2:23:53 PM PST Axel Davy wrote: I don't think we actually need the NEVER check, but it seems fine. Patches 1 and 3 are: Reviewed-by: Kenneth Graunke I'm not really up to speed to review the others. Thanks, I got a review for the other patches from Patrick. Axel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] dumb meson questions
Did you build LLVM yourself. In my experience, passing
-DCMAKE_C_FLAGS="-g1 -fno-omit-frame-pointer" \
-DCMAKE_CXX_FLAGS="-g1 -fno-omit-frame-pointer" \
to cmake when building LLVM makes debugging info much smaller, without
compromising the ability to get stack traces, etc.
Jose
From: mesa-dev on behalf of Brian Paul
Sent: Wednesday, March 6, 2019 15:46
To: Kenneth Graunke
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] dumb meson questions
On 03/06/2019 01:18 AM, Kenneth Graunke wrote:
> On Tuesday, March 5, 2019 10:20:10 PM PST Dave Airlie wrote:
>> On Wed, 6 Mar 2019 at 14:01, Brian Paul wrote:
>>> I guess I don't fully understand a few things about the new meson build.
>>>
>>> 1. I'm trying to build the gallium VMware driver with this:
>>>
>>> export BUILD_DIR=build-meson-dri
>>>
>>> mkdir "${BUILD_DIR}"
>>>
>>> meson -Dshared-llvm=false \
>>>-Dplatforms=x11,drm \
>>>-Dgallium-drivers=svga \
>>>-Dvulkan-drivers= \
>>>"${BUILD_DIR}"
>>>
>>> ninja -C "${BUILD_DIR}"
>>>
>>> When it's done, there is no vmwgfx_dri.so driver file. So libGL
>>> complains that it can't find the svga driver (nor swrast). I must be
>>> missing something.
>>
>> I don't think meson got the install in place stuff carried over, so I
>> think everyone does --prefix= somewhere
>> and that should create the vmwgfx_dri.so which will be a link to the
>> libgallium_dri.so you've found.
>
> Right. Running 'ninja' and 'ninja install' together, for the entire
> project, is still faster than the old 'make' system (at least with an
> SSD)...so we didn't bother with the custom lib/ symlinks.
>
> I wrote a wrapper script for ninja that makes it easy to work with
> multiple build trees, can also automatically 'ninja install', and
> which can be run from anywhere in your git repository:
>
> https://nam04.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~kwg%2Fnj%2Fplain%2Fnjdata=02%7C01%7Cjfonseca%40vmware.com%7C68873d3170214283bd2f08d6a24aea95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636874839986720161sdata=bQLVu4ZVREZaXrg%2BCi6ZmGsz5PGYYsOVV5qP%2FsGIKJs%3Dreserved=0
>
> In my setup, I do:
>
> $ mkdir -p build/debug/install
> $ meson --buildtype=debug --prefix=$PWD/build/debug/install \
>-Ddri-drivers=i965 -Dgallium-drivers=iris -Dvulkan-drivers=intel \
>-Dglvnd=true -Dtools=intel,nir,glsl,intel-ui build/debug
>
> $ mkdir -p build/release/install
> $ CFLAGS='-O3 -g -fno-omit-frame-pointer -march=native' \
>CXXFLAGS='-O3 -g -fno-omit-frame-pointer -march=native' \
>meson --buildtype=release --prefix=$PWD/build/release/install \
>-Ddri-drivers=i965 -Dvulkan-drivers=intel -Dgallium-drivers=iris \
>-Dglvnd=true build/release
>
> Then,
>
> $ nj
>
> from anywhere in your Mesa repo will build and install the build/debug
> tree. Or to use the build/release tree:
>
> $ nj release
> $ nj release clean
>
> You can simply point LD_LIBRARY_PATH at mesa/build/debug/install/lib to
> use your newly built Mesa (instead of pointing it at the old mesa/lib).
>
> For simpler projects, nj also works with a single 'build' directory
> (with no subdirectories), and it can also do in-tree builds if you're
> using CMake (say for Piglit).
>
> Hope this helps!
Yeah, doing a 'ninja install' with a few other tweaks to my script
solves the issue. Thanks, Ken!
I'd like to point out that the Mesa doc page for Meson doesn't even
mention 'ninja install' despite the title of the page being "Compilation
and *Installation* using Meson"
Perhaps someone can fix that. It would also be helpful to have a few
concrete examples of meson/ninja commands for common configurations.
>
>>> 2. When the build completes I see that there's a libgallium_dri.so file
>>> that's HUGE:
>>>
>>> $ ls -l build-meson-dri/src/gallium/targets/dri/libgallium_dri.so
>>>
>>> -rwxr-xr-x 1 brianp users 726507584 Mar 5 20:47
>>> build-meson-dri/src/gallium/targets/dri/libgallium_dri.so*
>>>
>>>
>>> 726MB seems a bit excessive. The libvdpau_gallium.so and
>>> libxatracker.so libraries are also about that size. What's the story there?
>>
>> meson build debug by default, I expect you've gotten a bunch of that.
>>
>> Dave.
>
> I suspect it also has to do with static LLVM. Mine is only 49M with
> debugging symbols...
Yeah, that occurred to me too later. But when I don't specify static
LLVM I get tons of undefined LLVM symbols:
[...]
src/gallium/auxiliary/libgallium.a(gallivm_lp_bld_tgsi.c.o): In function
`lp_build_action_set_dst_type':
/home/projects/Mesa-gitlab/mesa/build-meson-dri/../src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:94:
undefined reference to `LLVMTypeOf'
/home/projects/Mesa-gitlab/mesa/build-meson-dri/../src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:91:
undefined reference to `LLVMVoidTypeInContext'
[...]
I have LLVM 7.0 installed and see both static and dynamic libraries in
my /usr/local/lib/
-Brian
