[Mesa-dev] [Bug 109752] meson: more ensure that xmlpool_options.h is generated for targets that need it
https://bugs.freedesktop.org/show_bug.cgi?id=109752 Eric Engestrom changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Eric Engestrom --- Hi David! Thanks for your patch! I verified it and you are entirely correct :) The preferred way to send patches for Mesa is by submitting a merge request (https://gitlab.freedesktop.org/mesa/mesa/merge_requests, see https://mesa3d.org/submittingpatches.html). I just saw that you attached your patch, which I missed earlier, and I couldn't manage to fixup the copy/pasted patch, so I rewrote it, added a few `Fixes:` tags so that it gets picked up for backports, and pushed it as: commit 6fa923a65daf1ee73c5cc763ade91abc82da7085 Author: David Shao Date: Sun, 24 Feb 2019 09:00:36 + meson: ensure that xmlpool_options.h is generated for gallium targets that need it Fixes: 68076b87474e7959c161 "meson: build gallium vdpau state tracker" Fixes: 22a817af8a89eb3c762f "meson: build gallium xvmc state tracker" Fixes: 5a785d51a6d68ec676ce "meson: build gallium va state tracker" Fixes: 0ba909f0f111824223bc "meson: build gallium xa state tracker" Fixes: 1d36dc674d528b93bec3 "meson: build gallium omx state tracker" Reviewed-by: Eric Engestrom Please double check the commit to make sure I didn't miss something :) https://gitlab.freedesktop.org/mesa/mesa/commit/6fa923a65daf1ee73c5cc763ade91abc82da7085 Thanks again for your patch, and welcome to Mesa! -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109747] Add framerate to vulkan-overlay-layer
https://bugs.freedesktop.org/show_bug.cgi?id=109747 --- Comment #5 from osch...@web.de --- Adding more graphs should be relatively straight forward but someone would need to implement querying the relevant information first, preferably in a cross-platform manner. I might give adding a cpu-usage graph a go next week. Personally I don't see much value in reducing the information displayed by default. Anyways, this bug should be either renamed or closed. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109747] Add framerate to vulkan-overlay-layer
https://bugs.freedesktop.org/show_bug.cgi?id=109747 Lionel Landwerlin changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Lionel Landwerlin --- FPS counter added in : commit f91654120b6ce4b2ff413f1b02ced965000c0bc3 Author: Matthias Lorenz Date: Sat Feb 23 00:08:28 2019 +0100 vulkan/overlay: Add fps counter -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109761] misuse of enums in vdpau_private.h
https://bugs.freedesktop.org/show_bug.cgi?id=109761 Bug ID: 109761 Summary: misuse of enums in vdpau_private.h Product: Mesa Version: git Hardware: All OS: NetBSD Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: co...@sdf.org QA Contact: mesa-dev@lists.freedesktop.org using a custom build system and clang 7, I get warnings about src/gallium/state_trackers/vdpau/vdpau_private.h. functions like FormatYCBCRToPipeChroma return enum pipe_video_chroma_format. PIPE_FORMAT_NONE, returned in the else case, isn't in this enum, it's enum pipe_format. I can trivially replace for returning PIPE_VIDEO_CHROMA_FORMAT_NONE but that sounds like a risky change that might have harmful effects, so making a bug reports rather than a patch. -- 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/3] panfrost: Add RGB555, RGB5A1 texture formats
On Sun, Feb 24, 2019 at 1:36 AM Alyssa Rosenzweig wrote:
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> src/gallium/drivers/panfrost/include/panfrost-job.h | 2 ++
> src/gallium/drivers/panfrost/pan_pretty_print.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h
> b/src/gallium/drivers/panfrost/include/panfrost-job.h
> index 82b3cfb2a4f..072f0258bea 100644
> --- a/src/gallium/drivers/panfrost/include/panfrost-job.h
> +++ b/src/gallium/drivers/panfrost/include/panfrost-job.h
> @@ -306,6 +306,8 @@ struct mali_channel_swizzle {
> #define MALI_CHANNEL_FLOAT 7
>
> enum mali_format {
> + MALI_RGB555 = MALI_FORMAT_SPECIAL | 0x0,
Just a thought -- RGB565, which is a fairly popular 16-bit color
variant, would fit nicely into the space here, and is probably also
one of the "special" formats. (Slightly surprising there's a separate
RGB555 and RGB5_A1 - normally that's handled by swizzling. Could it be
the difference between where the A1 bit is -- first vs last? Perhaps
that's also why there's a space after each of the RGB10A2 formats --
to also allow A2RGB10.)
Another good candidate for special handling is RGB9_E5 (shared
exponent), and I don't see a Z24 in the list.
Cheers,
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] panfrost: Add RGB555, RGB5A1 texture formats
> Just a thought -- RGB565, which is a fairly popular 16-bit color > variant, would fit nicely into the space here, and is probably also > one of the "special" formats. Oh, dear, this is embarassing -- I misread my notes. The format code in question is for RGB565, not RGB555. Thank you for pointing that out! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109764] [radv] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109764 Bug ID: 109764 Summary: [radv] Enable framerate capping Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: shtetl...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org It can be beneficial to enable framerate capping, to reduce power consumption and hardware wear out in case when user can be satisfied with certain max framerate. There is a similar DRI bug: https://bugs.freedesktop.org/show_bug.cgi?id=100389 But not sure what the right place is for such capping to occur, so opening one for radv. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109765] Incorrect assert in gallium/state_trackers/va/picture_mjpeg.c
https://bugs.freedesktop.org/show_bug.cgi?id=109765 Bug ID: 109765 Summary: Incorrect assert in gallium/state_trackers/va/picture_mjpeg.c Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: andre...@chromium.org QA Contact: mesa-dev@lists.freedesktop.org The assert in vlVaHandleHuffmanTableBufferType() [1] seems incorrect. Based on the pattern of the other functions in the file, it should be: assert(buf->size >= sizeof(VAHuffmanTableBufferJPEGBaseline) && buf->num_elements == 1); instead of assert(buf->size >= sizeof(VASliceParameterBufferJPEGBaseline) && buf->num_elements == 1); [1] https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/state_trackers/va/picture_mjpeg.c#L74 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] radeonsi: fix query buffer allocation
Fix the logic for buffer full check on alloc.
This patch just takes the fix Nicolai attached to the bug report
and updates it to work on master.
Fixes: e0f0d3675d4 ("radeonsi: factor si_query_buffer logic out of si_query_hw")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109561
---
src/gallium/drivers/radeonsi/si_query.c | 52 ++---
src/gallium/drivers/radeonsi/si_query.h | 5 ++-
2 files changed, 32 insertions(+), 25 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_query.c
b/src/gallium/drivers/radeonsi/si_query.c
index 266b9d3ce84..280eee3a280 100644
--- a/src/gallium/drivers/radeonsi/si_query.c
+++ b/src/gallium/drivers/radeonsi/si_query.c
@@ -549,11 +549,15 @@ void si_query_buffer_reset(struct si_context *sctx,
struct si_query_buffer *buff
}
buffer->results_end = 0;
+ if (!buffer->buf)
+ return;
+
/* Discard even the oldest buffer if it can't be mapped without a
stall. */
- if (buffer->buf &&
- (si_rings_is_buffer_referenced(sctx, buffer->buf->buf,
RADEON_USAGE_READWRITE) ||
-!sctx->ws->buffer_wait(buffer->buf->buf, 0,
RADEON_USAGE_READWRITE))) {
+ if (si_rings_is_buffer_referenced(sctx, buffer->buf->buf,
RADEON_USAGE_READWRITE) ||
+ !sctx->ws->buffer_wait(buffer->buf->buf, 0,
RADEON_USAGE_READWRITE)) {
si_resource_reference(&buffer->buf, NULL);
+ } else {
+ buffer->unprepared = true;
}
}
@@ -561,29 +565,31 @@ bool si_query_buffer_alloc(struct si_context *sctx,
struct si_query_buffer *buff
bool (*prepare_buffer)(struct si_context *, struct
si_query_buffer*),
unsigned size)
{
- if (buffer->buf && buffer->results_end + size >=
buffer->buf->b.b.width0)
- return true;
+ bool unprepared = buffer->unprepared;
+ buffer->unprepared = false;
+
+ if (!buffer->buf || buffer->results_end + size >
buffer->buf->b.b.width0) {
+ if (buffer->buf) {
+ struct si_query_buffer *qbuf =
MALLOC_STRUCT(si_query_buffer);
+ memcpy(qbuf, buffer, sizeof(*qbuf));
+ buffer->previous = qbuf;
+ }
+ buffer->results_end = 0;
- if (buffer->buf) {
- struct si_query_buffer *qbuf = MALLOC_STRUCT(si_query_buffer);
- memcpy(qbuf, buffer, sizeof(*qbuf));
- buffer->previous = qbuf;
+ /* Queries are normally read by the CPU after
+* being written by the gpu, hence staging is probably a good
+* usage pattern.
+*/
+ struct si_screen *screen = sctx->screen;
+ unsigned buf_size = MAX2(size, screen->info.min_alloc_size);
+ buffer->buf = si_resource(
+ pipe_buffer_create(&screen->b, 0, PIPE_USAGE_STAGING,
buf_size));
+ if (unlikely(!buffer->buf))
+ return false;
+ unprepared = true;
}
- buffer->results_end = 0;
-
- /* Queries are normally read by the CPU after
-* being written by the gpu, hence staging is probably a good
-* usage pattern.
-*/
- struct si_screen *screen = sctx->screen;
- unsigned buf_size = MAX2(size, screen->info.min_alloc_size);
- buffer->buf = si_resource(
- pipe_buffer_create(&screen->b, 0, PIPE_USAGE_STAGING,
buf_size));
- if (unlikely(!buffer->buf))
- return false;
-
- if (prepare_buffer) {
+ if (unprepared && prepare_buffer) {
if (unlikely(!prepare_buffer(sctx, buffer))) {
si_resource_reference(&buffer->buf, NULL);
return false;
diff --git a/src/gallium/drivers/radeonsi/si_query.h
b/src/gallium/drivers/radeonsi/si_query.h
index aaf0bd03aca..c61af51d57c 100644
--- a/src/gallium/drivers/radeonsi/si_query.h
+++ b/src/gallium/drivers/radeonsi/si_query.h
@@ -177,12 +177,13 @@ struct si_query_hw_ops {
struct si_query_buffer {
/* The buffer where query results are stored. */
struct si_resource *buf;
- /* Offset of the next free result after current query data */
- unsignedresults_end;
/* If a query buffer is full, a new buffer is created and the old one
* is put in here. When we calculate the result, we sum up the samples
* from all buffers. */
struct si_query_buffer *previous;
+ /* Offset of the next free result after current query data */
+ unsignedresults_end;
+ bool unprepared;
};
void si_query_buffer_destroy(struct si_screen *sctx, struct si_query_buffer
*buffer);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/
[Mesa-dev] [PATCH 1/3] panfrost: Add RGB565, RGB5A1 texture formats
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/include/panfrost-job.h | 2 ++
src/gallium/drivers/panfrost/pan_pretty_print.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h
b/src/gallium/drivers/panfrost/include/panfrost-job.h
index 82b3cfb2a4f..072f0258bea 100644
--- a/src/gallium/drivers/panfrost/include/panfrost-job.h
+++ b/src/gallium/drivers/panfrost/include/panfrost-job.h
@@ -306,6 +306,8 @@ struct mali_channel_swizzle {
#define MALI_CHANNEL_FLOAT 7
enum mali_format {
+ MALI_RGB565 = MALI_FORMAT_SPECIAL | 0x0,
+ MALI_RGB5_A1_UNORM = MALI_FORMAT_SPECIAL | 0x2,
MALI_RGB10_A2_UNORM = MALI_FORMAT_SPECIAL | 0x3,
MALI_RGB10_A2_SNORM = MALI_FORMAT_SPECIAL | 0x5,
MALI_RGB10_A2UI = MALI_FORMAT_SPECIAL | 0x7,
diff --git a/src/gallium/drivers/panfrost/pan_pretty_print.c
b/src/gallium/drivers/panfrost/pan_pretty_print.c
index f9fd2c0e6da..e2a8d9e1461 100644
--- a/src/gallium/drivers/panfrost/pan_pretty_print.c
+++ b/src/gallium/drivers/panfrost/pan_pretty_print.c
@@ -36,6 +36,8 @@ char *pandecode_format_name(enum mali_format format)
static char unk_format_str[5];
switch (format) {
+ DEFINE_CASE(RGB565);
+ DEFINE_CASE(RGB5_A1_UNORM);
DEFINE_CASE(RGB10_A2_UNORM);
DEFINE_CASE(RGB10_A2_SNORM);
DEFINE_CASE(RGB10_A2UI);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] panfrost: Expose perf counters in environment
Previously, we were guarded by an #ifdef, which is generally a bad form.
This patch instead guards them behind an environmental variable.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 9 +++--
src/gallium/drivers/panfrost/pan_screen.c | 13 -
src/gallium/drivers/panfrost/pan_screen.h | 2 --
3 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 508f55200af..81c29dc929d 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -43,9 +43,8 @@
#include "pan_blend_shaders.h"
#include "pan_wallpaper.h"
-#ifdef DUMP_PERFORMANCE_COUNTERS
static int performance_counter_number = 0;
-#endif
+extern const char *pan_counters_base;
/* Do not actually send anything to the GPU; merely generate the cmdstream as
fast as possible. Disables framebuffer writes */
//#define DRY_RUN
@@ -1570,17 +1569,15 @@ panfrost_submit_frame(struct panfrost_context *ctx,
bool flush_immediate)
if (panfrost_is_scanout(ctx) && flush_immediate)
screen->driver->force_flush_fragment(ctx);
-#ifdef DUMP_PERFORMANCE_COUNTERS
-if (screen->driver->dump_counters) {
+if (screen->driver->dump_counters && pan_counters_base) {
screen->driver->dump_counters(screen);
char filename[128];
-snprintf(filename, sizeof(filename),
"/dev/shm/frame%d.mdgprf", ++performance_counter_number);
+snprintf(filename, sizeof(filename), "%s/frame%d.mdgprf",
pan_counters_base, ++performance_counter_number);
FILE *fp = fopen(filename, "wb");
fwrite(screen->perf_counters.cpu, 4096, sizeof(uint32_t), fp);
fclose(fp);
}
-#endif
#endif
}
diff --git a/src/gallium/drivers/panfrost/pan_screen.c
b/src/gallium/drivers/panfrost/pan_screen.c
index f61758d1bb9..b8a119fd343 100644
--- a/src/gallium/drivers/panfrost/pan_screen.c
+++ b/src/gallium/drivers/panfrost/pan_screen.c
@@ -53,6 +53,8 @@
struct panfrost_driver *panfrost_create_drm_driver(int fd);
struct panfrost_driver *panfrost_create_nondrm_driver(int fd);
+const char *pan_counters_base = NULL;
+
static const char *
panfrost_get_name(struct pipe_screen *screen)
{
@@ -551,17 +553,18 @@ panfrost_create_screen(int fd, struct renderonly *ro,
bool is_drm)
#endif
}
-/* Enable pantrace iff asked for in the environment */
+/* Dump memory and/or performance counters iff asked for in the
environment */
const char *pantrace_base = getenv("PANTRACE_BASE");
+pan_counters_base = getenv("PANCOUNTERS_BASE");
if (pantrace_base) {
pantrace_initialize(pantrace_base);
}
-#ifdef DUMP_PERFORMANCE_COUNTERS
-screen->driver->allocate_slab(screen, &screen->perf_counters, 64,
true, 0, 0, 0);
-screen->driver->enable_counters(screen);
-#endif
+if (pan_counters_base) {
+screen->driver->allocate_slab(screen, &screen->perf_counters,
64, true, 0, 0, 0);
+screen->driver->enable_counters(screen);
+}
screen->base.destroy = panfrost_destroy_screen;
diff --git a/src/gallium/drivers/panfrost/pan_screen.h
b/src/gallium/drivers/panfrost/pan_screen.h
index e976b78b5a2..0005b2feb15 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -41,8 +41,6 @@ struct panfrost_context;
struct panfrost_resource;
struct panfrost_screen;
-//#define DUMP_PERFORMANCE_COUNTERS
-
/* Flags for allocated memory */
#define PAN_ALLOCATE_EXECUTE (1 << 0)
#define PAN_ALLOCATE_GROWABLE (1 << 1)
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] panfrost/midgard: Allow flt to run on most units
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/helpers.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/midgard/helpers.h
b/src/gallium/drivers/panfrost/midgard/helpers.h
index 12235f8f9ff..b597e516f20 100644
--- a/src/gallium/drivers/panfrost/midgard/helpers.h
+++ b/src/gallium/drivers/panfrost/midgard/helpers.h
@@ -216,7 +216,7 @@ static unsigned alu_opcode_props[256] = {
/* For vector comparisons, use ball etc */
[midgard_alu_op_feq]= UNITS_MOST,
[midgard_alu_op_fne]= UNITS_MOST,
-[midgard_alu_op_flt]= UNIT_SADD,
+[midgard_alu_op_flt]= UNITS_MOST,
[midgard_alu_op_ieq]= UNITS_MOST,
[midgard_alu_op_ine]= UNITS_MOST,
[midgard_alu_op_ilt]= UNITS_MOST,
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] panfrost: Remove some scanout special cases
The scanout checks are fundamentally hacks; let's remove as many as we can. Signed-off-by: Alyssa Rosenzweig --- src/gallium/drivers/panfrost/pan_context.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/panfrost/pan_context.c b/src/gallium/drivers/panfrost/pan_context.c index 508f55200af..f2e10b12599 100644 --- a/src/gallium/drivers/panfrost/pan_context.c +++ b/src/gallium/drivers/panfrost/pan_context.c @@ -1560,14 +1560,14 @@ panfrost_submit_frame(struct panfrost_context *ctx, bool flush_immediate) /* If visual, we can stall a frame */ -if (panfrost_is_scanout(ctx) && !flush_immediate) +if (!flush_immediate) screen->driver->force_flush_fragment(ctx); screen->last_fragment_id = fragment_id; screen->last_fragment_flushed = false; /* If readback, flush now (hurts the pipelined performance) */ -if (panfrost_is_scanout(ctx) && flush_immediate) +if (flush_immediate) screen->driver->force_flush_fragment(ctx); #ifdef DUMP_PERFORMANCE_COUNTERS @@ -1585,8 +1585,6 @@ panfrost_submit_frame(struct panfrost_context *ctx, bool flush_immediate) #endif } -bool dont_scanout = false; - void panfrost_flush( struct pipe_context *pipe, -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109532] ir_variable has maximum access out of bounds -- but it's not out of bounds
https://bugs.freedesktop.org/show_bug.cgi?id=109532 --- Comment #39 from Mark Janes --- I just noticed that this new test passes for 32 bit builds. Does that surprise anyone else? http://mesa-ci.01.org/mesa_master_daily/builds/4806/group/e60513df13ade427f01bb7334bd5174e -- 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
