[Mesa-dev] [Bug 111728] regression: corrupted UI elements in Heroes of the Storm
https://bugs.freedesktop.org/show_bug.cgi?id=111728 Bug ID: 111728 Summary: regression: corrupted UI elements in Heroes of the Storm Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: tempel.jul...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org Since one of the recent commits of mesa-git, there is this corruption in HotS. It doesn't occur with mesa 19.1.7. What can't be shown on the picture is that some units' healthbars are disappearing too. Depending on what is happening on the screen, they are visible though and then neither the avatar in the left corner is broken (only broken when healthbars are missing). Perhaps this is some viewport issue? Uploading screenshot and renderdoc capture. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111728] regression: corrupted UI elements in Heroes of the Storm
https://bugs.freedesktop.org/show_bug.cgi?id=111728 --- Comment #1 from tempel.jul...@gmail.com --- Created attachment 145417 --> https://bugs.freedesktop.org/attachment.cgi?id=145417&action=edit screenshot showing the corrupted avatar -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111728] regression: corrupted UI elements in Heroes of the Storm
https://bugs.freedesktop.org/show_bug.cgi?id=111728 --- Comment #2 from tempel.jul...@gmail.com --- Created attachment 145418 --> https://bugs.freedesktop.org/attachment.cgi?id=145418&action=edit renderdoc capture part 1 -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111728] regression: corrupted UI elements in Heroes of the Storm
https://bugs.freedesktop.org/show_bug.cgi?id=111728 --- Comment #3 from tempel.jul...@gmail.com --- Created attachment 145419 --> https://bugs.freedesktop.org/attachment.cgi?id=145419&action=edit renderdoc capture part 2 -- 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 111728] regression: corrupted UI elements in Heroes of the Storm
https://bugs.freedesktop.org/show_bug.cgi?id=111728 --- Comment #4 from tempel.jul...@gmail.com --- Created attachment 145420 --> https://bugs.freedesktop.org/attachment.cgi?id=145420&action=edit renderdoc capture part 3/3 -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111728] regression: corrupted UI elements in Heroes of the Storm
https://bugs.freedesktop.org/show_bug.cgi?id=111728 --- Comment #5 from tempel.jul...@gmail.com --- This is with an RX 570 and mesa-git 8d5f905faad76a46c732dc43c4009cbf0f5da170 -- 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 111728] regression: corrupted UI elements in Heroes of the Storm
https://bugs.freedesktop.org/show_bug.cgi?id=111728 --- Comment #6 from Samuel Pitoiset --- RADV_DEBUG=nohiz? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 00/37] panfrost: Support batch pipelining
+Rob
On Tue, 17 Sep 2019 17:13:04 +0200
Boris Brezillon wrote:
> On Tue, 17 Sep 2019 08:36:56 -0400
> Alyssa Rosenzweig wrote:
>
> > "Can't use pipe_framebuffer_state as a hash key" Is this still relevant?
> > I thought we did this.
>
> I did this yes. I thought it was only a problem for the wallpaper
> draw, but it's actually wrong for any kind of blit where src and
> dst point to the same resource, you're right. I guess the solution
> would be to not use util_framebuffer_state_equal() but compare the
> resources pointed by surfaces contained in the fb state, and not hash
> the fb state directly, but hash its resource pointers instead (pretty
> much what was done before my patch :-/).
I tried implementing my own hash/compare funcs for the FBO key (instead
of using util_framebuffer_state_equal() and hashing the whole struct)
based on the freedreno logic, and I added an assert to see if there was
cases where util_framebuffer_state_equal() was returning something
different (see the below diff). There are indeed 2 deqp-gles2 tests that
trigger this assert.
So, now the question is, is it worth fixing, or can we live with the
extra batch addition because we can't figure out that 2 FBOs are identical
in rare occasions.
There's still something I don't understand in the freedreno logic: they
say they don't want to retain refs to the surface pointed by the fb
state, because refcounting gets messy then, but I don't get why, especially
since they retain refs to the resources pointed by those surfaces.
Anyway, I guess all of this can be sorted out after this series has landed.
--->8---
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index 04257727ee0a..a90c427f6042 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -100,6 +100,74 @@ panfrost_batch_fence_reference(struct panfrost_batch_fence
*fence)
pipe_reference(NULL, &fence->reference);
}
+static bool
+panfrost_batch_surf_compare(const struct pipe_surface *a,
+const struct pipe_surface *b)
+{
+if (!a || !b)
+return a == b;
+
+if (a->texture != b->texture ||
+memcmp(&a->u, &b->u, sizeof(a->u)) ||
+a->nr_samples != b->nr_samples ||
+a->format != b->format)
+return false;
+
+return true;
+}
+
+static bool
+panfrost_batch_compare(const void *a, const void *b)
+{
+const struct pipe_framebuffer_state *fba = a, *fbb = b;
+unsigned i;
+
+if (fba->width != fbb->width || fba->height != fbb->height ||
+fba->layers != fbb->layers || fba->samples != fbb->samples ||
+fba->nr_cbufs != fbb->nr_cbufs)
+return false;
+
+for (i = 0; i < fba->nr_cbufs; i++) {
+if (!panfrost_batch_surf_compare(fba->cbufs[i], fbb->cbufs[i]))
+return false;
+}
+
+return panfrost_batch_surf_compare(fba->zsbuf, fbb->zsbuf);
+}
+
+static uint32_t
+panfrost_batch_surf_hash(uint32_t hash, const struct pipe_surface *surf)
+{
+uint32_t fmt_samples = surf ? (surf->format | (surf->nr_samples <<
16)) : 0;
+struct pipe_resource *rsrc = surf ? surf->texture : NULL;
+union pipe_surface_desc dummy_desc = { };
+
+hash = _mesa_fnv32_1a_accumulate_block(hash, &rsrc, sizeof(rsrc));
+hash = _mesa_fnv32_1a_accumulate_block(hash,
+ surf ? &surf->u : &dummy_desc,
+ sizeof(surf->u));
+return _mesa_fnv32_1a_accumulate_block(hash, &fmt_samples,
+ sizeof(fmt_samples));
+}
+
+static uint32_t
+panfrost_batch_hash(const void *key)
+{
+const struct pipe_framebuffer_state *fb = key;
+uint64_t header = fb->width | fb->height << 16 |
+ (uint64_t)fb->layers << 32 |
+ (uint64_t)fb->samples << 48 |
+ (uint64_t)fb->nr_cbufs << 56;
+uint32_t hash = _mesa_fnv32_1a_offset_bias;
+unsigned i;
+
+hash = _mesa_fnv32_1a_accumulate_block(hash, &header, sizeof(header));
+for (i = 0; i < ARRAY_SIZE(fb->cbufs); i++)
+hash = panfrost_batch_surf_hash(hash, fb->cbufs[i]);
+
+return panfrost_batch_surf_hash(hash, fb->zsbuf);
+}
+
static struct panfrost_batch *
panfrost_create_batch(struct panfrost_context *ctx,
const struct pipe_framebuffer_state *key)
@@ -252,8 +320,10 @@ panfrost_get_batch(struct panfrost_context *ctx,
struct hash_entry *entry = _mesa_hash_table_search(ctx->fbo_to_batch,
key);
-if (entry)
+if (entry) {
+assert(util_framebuffer_state_equal(entry->key, key));
return entry->data;
+}
/* Other
[Mesa-dev] [Bug 111728] regression: corrupted UI elements in Heroes of the Storm
https://bugs.freedesktop.org/show_bug.cgi?id=111728 --- Comment #7 from tempel.jul...@gmail.com --- Issue does not occur with RADV_DEBUG=nohiz. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111728] regression: corrupted UI elements in Heroes of the Storm
https://bugs.freedesktop.org/show_bug.cgi?id=111728 --- Comment #8 from Samuel Pitoiset --- Could be related to my recent HTILE changes. I'm looking. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111728] regression: corrupted UI elements in Heroes of the Storm
https://bugs.freedesktop.org/show_bug.cgi?id=111728 --- Comment #9 from Samuel Pitoiset --- https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2023 -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111728] regression: corrupted UI elements in Heroes of the Storm
https://bugs.freedesktop.org/show_bug.cgi?id=111728 tempel.jul...@gmail.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from tempel.jul...@gmail.com --- Fixed. That was insanely fast, thanks a lot! -- 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 110995] performance regression in Heroes of the Storm with Mesa 19.1.1 & Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110995 --- Comment #4 from tempel.jul...@gmail.com --- This is unfortunately unchanged with latest master: ~148fps where it was ~162fps. amdvlk scores ~155fps, and with pageflipping + amdgpu.dc=0 ~160fps I can't workaround this anymore by reverting 0a313cc285c2939de9cac07f045b0b699bc208ca, as radv stopped building successfully without it. -- 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 110995] performance regression in Heroes of the Storm with Mesa 19.1.1 & Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110995 --- Comment #5 from Samuel Pitoiset --- Should be fixed by https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2025 -- 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 110995] performance regression in Heroes of the Storm with Mesa 19.1.1 & Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110995 tempel.jul...@gmail.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from tempel.jul...@gmail.com --- Confirmed, performance is back to >160fps. Thanks a lot, your efforts are really outstanding! -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110995] performance regression in Heroes of the Storm with Mesa 19.1.1 & Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110995 --- Comment #7 from Samuel Pitoiset --- Can you please wait before closing tickets? Sending a change doesn't necessarily mean that it will be pushed/accepted. Thanks! -- 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 111728] regression: corrupted UI elements in Heroes of the Storm
https://bugs.freedesktop.org/show_bug.cgi?id=111728 --- Comment #11 from Samuel Pitoiset --- Fixed by https://gitlab.freedesktop.org/mesa/mesa/commit/46b7512b0a73b24a00fa9308a44ab4ffe6054874 -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110995] performance regression in Heroes of the Storm with Mesa 19.1.1 & Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110995 --- Comment #8 from tempel.jul...@gmail.com --- Of course, sorry. -- 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 v3 01/17] panfrost: Extend the panfrost_batch_add_bo() API to pass access flags
The type of access being done on a BO has impacts on job scheduling
(shared resources being written enforce serialization while those
being read only allow for job parallelization) and BO lifetime (the
fragment job might last longer than the vertex/tiler ones, if we can,
it's good to release BOs earlier so that others can re-use them
through the BO re-use cache).
Let's pass extra access flags to panfrost_batch_add_bo() and
panfrost_batch_create_bo() so the batch submission logic can take the
appropriate when submitting batches. Note that this information is not
used yet, we're just patching callers to pass the correct flags here.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* s/PAN_BO_GPU_ACCESS/PAN_BO_ACCESS/
* Fix wrong access types for streamout and vertex index buf
* Add a panfrost_bo_access_for_stage() helper
---
src/gallium/drivers/panfrost/pan_allocate.c | 14 ++-
src/gallium/drivers/panfrost/pan_blend_cso.c | 6 ++-
src/gallium/drivers/panfrost/pan_bo.h | 29 ++
src/gallium/drivers/panfrost/pan_context.c| 36 +
src/gallium/drivers/panfrost/pan_instancing.c | 5 ++-
src/gallium/drivers/panfrost/pan_job.c| 39 ++-
src/gallium/drivers/panfrost/pan_job.h| 5 ++-
src/gallium/drivers/panfrost/pan_varyings.c | 10 -
8 files changed, 120 insertions(+), 24 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_allocate.c
b/src/gallium/drivers/panfrost/pan_allocate.c
index 3076c23ab1cc..b16a1253ac2f 100644
--- a/src/gallium/drivers/panfrost/pan_allocate.c
+++ b/src/gallium/drivers/panfrost/pan_allocate.c
@@ -63,8 +63,18 @@ panfrost_allocate_transient(struct panfrost_batch *batch,
size_t sz)
size_t bo_sz = sz < TRANSIENT_SLAB_SIZE ?
TRANSIENT_SLAB_SIZE : ALIGN_POT(sz, 4096);
-/* We can't reuse the current BO, but we can create a new one.
*/
-bo = panfrost_batch_create_bo(batch, bo_sz, 0);
+/* We can't reuse the current BO, but we can create a new one.
+ * We don't know what the BO will be used for, so let's flag it
+ * RW and attach it to both the fragment and vertex/tiler jobs.
+ * TODO: if we want fine grained BO assignment we should pass
+ * flags to this function and keep the read/write,
+ * fragment/vertex+tiler pools separate.
+ */
+bo = panfrost_batch_create_bo(batch, bo_sz, 0,
+ PAN_BO_ACCESS_PRIVATE |
+ PAN_BO_ACCESS_RW |
+ PAN_BO_ACCESS_VERTEX_TILER |
+ PAN_BO_ACCESS_FRAGMENT);
if (sz < TRANSIENT_SLAB_SIZE) {
batch->transient_bo = bo;
diff --git a/src/gallium/drivers/panfrost/pan_blend_cso.c
b/src/gallium/drivers/panfrost/pan_blend_cso.c
index 6bd6ff71cdc7..48bd513ab6e5 100644
--- a/src/gallium/drivers/panfrost/pan_blend_cso.c
+++ b/src/gallium/drivers/panfrost/pan_blend_cso.c
@@ -273,7 +273,11 @@ panfrost_get_blend_for_context(struct panfrost_context
*ctx, unsigned rti)
/* Upload the shader */
final.shader.bo = panfrost_batch_create_bo(batch, shader->size,
- PAN_BO_EXECUTE);
+ PAN_BO_EXECUTE,
+ PAN_BO_ACCESS_PRIVATE |
+ PAN_BO_ACCESS_READ |
+ PAN_BO_ACCESS_VERTEX_TILER |
+ PAN_BO_ACCESS_FRAGMENT);
memcpy(final.shader.bo->cpu, shader->buffer, shader->size);
if (shader->patch_index) {
diff --git a/src/gallium/drivers/panfrost/pan_bo.h
b/src/gallium/drivers/panfrost/pan_bo.h
index 33fbddff3369..73cc74a260d4 100644
--- a/src/gallium/drivers/panfrost/pan_bo.h
+++ b/src/gallium/drivers/panfrost/pan_bo.h
@@ -56,6 +56,24 @@ struct panfrost_screen;
* let the BO logic know about this contraint. */
#define PAN_BO_DONT_REUSE (1 << 5)
+/* GPU access flags */
+
+/* BO is either shared (can be accessed by more than one GPU batch) or private
+ * (reserved by a specific GPU job). */
+#define PAN_BO_ACCESS_PRIVATE (0 << 0)
+#define PAN_BO_ACCESS_SHARED (1 << 0)
+
+/* BO is being read/written by the GPU */
+#define PAN_BO_ACCESS_READ(1 << 1)
+#define PAN_BO_ACCESS_WRITE (1 << 2)
+#define PAN_BO_ACCESS_RW (PAN_BO_ACCESS_READ |
PAN_BO_ACCESS_WRITE)
+
+/* BO is accessed by the vertex/tiler job. */
+#define PAN_BO_ACCESS_VERTEX_TILER(1 << 3)
+
+/* BO is accessed by the fragment job. */
+#define PAN_BO_ACCESS_FRAGMENT(1 << 4)
+
struct panfrost_bo {
/* Must be first for
[Mesa-dev] [PATCH v3 00/17] panfrost: Support batch pipelining
Hello, This is the third attempt at supporting batch pipelining. This time I implemented it using a dependency graph (as suggested by Alyssa and Steven) so that batch submission can be delayed even more: the only time we flush batches now is when we have an explicit flush or when the CPU needs to access a BO (we might want to tweak that a bit to avoid the extra latency incurred by this solution). With that in place we hope to increase GPU utilization. Patches 15 and 16 are optional, but I remember reading (I think it was Steven who mentioned that) that draw order matters when queueing render operations for different frames (frame N should ideally be ready before frame N+1). Not sure if enforcing draw call order is enough to guarantee that rendering of frame N always finishes before frame N+1 though. If that's something you don't want to merge, I can drop it. Regards, Boris Boris Brezillon (17): panfrost: Extend the panfrost_batch_add_bo() API to pass access flags panfrost: Make panfrost_batch->bos a hash table panfrost: Add a batch fence panfrost: Use the per-batch fences to wait on the last submitted batch panfrost: Add a panfrost_freeze_batch() helper panfrost: Start tracking inter-batch dependencies panfrost: Prepare panfrost_fence for batch pipelining panfrost: Add a panfrost_flush_all_batches() helper panfrost: Add a panfrost_flush_batches_accessing_bo() helper panfrost: Kill the explicit serialization in panfrost_batch_submit() panfrost: Get rid of the flush in panfrost_set_framebuffer_state() panfrost: Add flags to reflect the BO imported/exported state panfrost: Make sure the BO is 'ready' when picked from the cache panfrost: Do fine-grained flushing when preparing BO for CPU accesses panfrost: Rename ctx->batches into ctx->fbo_to_batch panfrost: Take draw call order into account panfrost/ci: New tests are passing .../drivers/panfrost/ci/expected-failures.txt | 4 - src/gallium/drivers/panfrost/pan_allocate.c | 14 +- src/gallium/drivers/panfrost/pan_blend_cso.c | 6 +- src/gallium/drivers/panfrost/pan_bo.c | 116 ++- src/gallium/drivers/panfrost/pan_bo.h | 44 ++ src/gallium/drivers/panfrost/pan_compute.c| 2 +- src/gallium/drivers/panfrost/pan_context.c| 121 ++-- src/gallium/drivers/panfrost/pan_context.h| 15 +- src/gallium/drivers/panfrost/pan_instancing.c | 5 +- src/gallium/drivers/panfrost/pan_job.c| 668 -- src/gallium/drivers/panfrost/pan_job.h| 58 +- src/gallium/drivers/panfrost/pan_resource.c | 27 +- src/gallium/drivers/panfrost/pan_screen.c | 65 +- src/gallium/drivers/panfrost/pan_screen.h | 3 +- src/gallium/drivers/panfrost/pan_varyings.c | 10 +- 15 files changed, 956 insertions(+), 202 deletions(-) -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 04/17] panfrost: Use the per-batch fences to wait on the last submitted batch
We just replace the per-context out_sync object by a pointer to the
the fence of the last last submitted batch. Pipelining of batches will
come later.
Signed-off-by: Boris Brezillon
---
Alyssa, I dropped your R-b since the other changes you asked me to do
in "panfrost: Add a batch fence" had some impact on this patch.
Changes in v3:
* Make sure we don't try to wait on dummy batches (those with no
vertex/tiler/fragment jobs)
---
src/gallium/drivers/panfrost/pan_context.c | 6
src/gallium/drivers/panfrost/pan_context.h | 3 +-
src/gallium/drivers/panfrost/pan_job.c | 35 ++
src/gallium/drivers/panfrost/pan_screen.c | 18 +--
4 files changed, 47 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 65a6c7f8c5ae..312a9e93e455 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -2702,12 +2702,6 @@ panfrost_create_context(struct pipe_screen *screen, void
*priv, unsigned flags)
panfrost_blend_context_init(gallium);
panfrost_compute_context_init(gallium);
-ASSERTED int ret;
-
-ret = drmSyncobjCreate(pscreen->fd, DRM_SYNCOBJ_CREATE_SIGNALED,
- &ctx->out_sync);
-assert(!ret);
-
/* XXX: leaks */
gallium->stream_uploader = u_upload_create_default(gallium);
gallium->const_uploader = gallium->stream_uploader;
diff --git a/src/gallium/drivers/panfrost/pan_context.h
b/src/gallium/drivers/panfrost/pan_context.h
index c145d589757e..ce3e0c899a4f 100644
--- a/src/gallium/drivers/panfrost/pan_context.h
+++ b/src/gallium/drivers/panfrost/pan_context.h
@@ -191,7 +191,8 @@ struct panfrost_context {
/* True for t6XX, false for t8xx. */
bool is_t6xx;
-uint32_t out_sync;
+/* The out sync fence of the last submitted batch. */
+struct panfrost_batch_fence *last_out_sync;
};
/* Corresponds to the CSO */
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index b6763da66a97..55780dd3d9d6 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -425,11 +425,13 @@ panfrost_batch_submit_ioctl(struct panfrost_batch *batch,
uint32_t *bo_handles;
int ret;
-submit.in_syncs = (u64) (uintptr_t) &ctx->out_sync;
-submit.in_sync_count = 1;
-submit.out_sync = ctx->out_sync;
+if (ctx->last_out_sync) {
+submit.in_sync_count = 1;
+submit.in_syncs = (uintptr_t)&ctx->last_out_sync->syncobj;
+}
+submit.out_sync = batch->out_sync->syncobj;
submit.jc = first_job_desc;
submit.requirements = reqs;
@@ -445,6 +447,14 @@ panfrost_batch_submit_ioctl(struct panfrost_batch *batch,
submit.bo_handles = (u64) (uintptr_t) bo_handles;
ret = drmIoctl(screen->fd, DRM_IOCTL_PANFROST_SUBMIT, &submit);
free(bo_handles);
+
+/* Release the last batch fence if any, and retain the new one */
+if (ctx->last_out_sync)
+panfrost_batch_fence_unreference(ctx->last_out_sync);
+
+panfrost_batch_fence_reference(batch->out_sync);
+ctx->last_out_sync = batch->out_sync;
+
if (ret) {
fprintf(stderr, "Error submitting: %m\n");
return errno;
@@ -453,7 +463,8 @@ panfrost_batch_submit_ioctl(struct panfrost_batch *batch,
/* Trace the job if we're doing that */
if (pan_debug & PAN_DBG_TRACE) {
/* Wait so we can get errors reported back */
-drmSyncobjWait(screen->fd, &ctx->out_sync, 1, INT64_MAX, 0,
NULL);
+drmSyncobjWait(screen->fd, &batch->out_sync->syncobj, 1,
+ INT64_MAX, 0, NULL);
pandecode_jc(submit.jc, FALSE);
}
@@ -495,6 +506,15 @@ panfrost_batch_submit(struct panfrost_batch *batch)
* to wait on it.
*/
batch->out_sync->signaled = true;
+
+/* Release the last batch fence if any, and set ->last_out_sync
+ * to NULL
+ */
+if (ctx->last_out_sync) {
+panfrost_batch_fence_unreference(ctx->last_out_sync);
+ctx->last_out_sync = NULL;
+}
+
goto out;
}
@@ -527,8 +547,11 @@ out:
* rendering is quite broken right now (to be fixed by the panfrost_job
* refactor, just take the perf hit for correctness)
*/
-drmSyncobjWait(pan_screen(ctx->base.screen)->fd, &ctx->out_sync, 1,
- INT64_MAX, 0, NULL);
+if (!batch->out_sync->signaled)
+drmSyncobjWait(pan_screen(ctx->base.screen)->fd,
+ &batch->out_sync->syncobj, 1, I
[Mesa-dev] [PATCH v3 08/17] panfrost: Add a panfrost_flush_all_batches() helper
And use it in panfrost_flush() to flush all batches, and not only the
one currently bound to the context.
We also replace all internal calls to panfrost_flush() by
panfrost_flush_all_batches() ones.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v3:
* Add missing blank line
* Collect R-b
---
src/gallium/drivers/panfrost/pan_compute.c | 2 +-
src/gallium/drivers/panfrost/pan_context.c | 23 +++
src/gallium/drivers/panfrost/pan_job.c | 46 -
src/gallium/drivers/panfrost/pan_job.h | 2 +-
src/gallium/drivers/panfrost/pan_resource.c | 6 +--
5 files changed, 64 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_compute.c
b/src/gallium/drivers/panfrost/pan_compute.c
index 4639c1b03c38..036dffbb17be 100644
--- a/src/gallium/drivers/panfrost/pan_compute.c
+++ b/src/gallium/drivers/panfrost/pan_compute.c
@@ -133,7 +133,7 @@ panfrost_launch_grid(struct pipe_context *pipe,
/* Queue the job */
panfrost_scoreboard_queue_compute_job(batch, transfer);
-panfrost_flush(pipe, NULL, PIPE_FLUSH_END_OF_FRAME);
+panfrost_flush_all_batches(ctx, true);
}
void
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index aad69e3f9991..861b4b621602 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1348,7 +1348,6 @@ panfrost_flush(
unsigned flags)
{
struct panfrost_context *ctx = pan_context(pipe);
-struct panfrost_batch *batch = panfrost_get_batch_for_fbo(ctx);
struct util_dynarray fences;
/* We must collect the fences before the flush is done, otherwise we'll
@@ -1356,13 +1355,18 @@ panfrost_flush(
*/
if (fence) {
util_dynarray_init(&fences, NULL);
-panfrost_batch_fence_reference(batch->out_sync);
-util_dynarray_append(&fences, struct panfrost_batch_fence *,
- batch->out_sync);
+hash_table_foreach(ctx->batches, hentry) {
+struct panfrost_batch *batch = hentry->data;
+
+panfrost_batch_fence_reference(batch->out_sync);
+util_dynarray_append(&fences,
+ struct panfrost_batch_fence *,
+ batch->out_sync);
+}
}
-/* Submit the frame itself */
-panfrost_batch_submit(batch);
+/* Submit all pending jobs */
+panfrost_flush_all_batches(ctx, false);
if (fence) {
struct panfrost_fence *f = panfrost_fence_create(ctx, &fences);
@@ -2321,7 +2325,7 @@ panfrost_set_framebuffer_state(struct pipe_context *pctx,
}
if (!is_scanout || has_draws)
-panfrost_flush(pctx, NULL, PIPE_FLUSH_END_OF_FRAME);
+panfrost_flush_all_batches(ctx, true);
else
assert(!ctx->payloads[PIPE_SHADER_VERTEX].postfix.framebuffer
&&
!ctx->payloads[PIPE_SHADER_FRAGMENT].postfix.framebuffer);
@@ -2553,6 +2557,7 @@ panfrost_get_query_result(struct pipe_context *pipe,
union pipe_query_result *vresult)
{
struct panfrost_query *query = (struct panfrost_query *) q;
+struct panfrost_context *ctx = pan_context(pipe);
switch (query->type) {
@@ -2560,7 +2565,7 @@ panfrost_get_query_result(struct pipe_context *pipe,
case PIPE_QUERY_OCCLUSION_PREDICATE:
case PIPE_QUERY_OCCLUSION_PREDICATE_CONSERVATIVE:
/* Flush first */
-panfrost_flush(pipe, NULL, PIPE_FLUSH_END_OF_FRAME);
+panfrost_flush_all_batches(ctx, true);
/* Read back the query results */
unsigned *result = (unsigned *) query->transfer.cpu;
@@ -2576,7 +2581,7 @@ panfrost_get_query_result(struct pipe_context *pipe,
case PIPE_QUERY_PRIMITIVES_GENERATED:
case PIPE_QUERY_PRIMITIVES_EMITTED:
-panfrost_flush(pipe, NULL, PIPE_FLUSH_END_OF_FRAME);
+panfrost_flush_all_batches(ctx, true);
vresult->u64 = query->end - query->start;
break;
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index 211e48bafd4e..3ccf4bb6b3e9 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -856,7 +856,7 @@ panfrost_batch_submit_jobs(struct panfrost_batch *batch)
return ret;
}
-void
+static void
panfrost_batch_submit(struct panfrost_batch *batch)
{
assert(batch);
@@ -904,8 +904,52 @@ out:
panfrost_free_batch(batch);
+}
+
+void
+panfrost_flush_all_batches(struct panfrost_context *ctx, bool wait)
+{
+struct util_dynarray fences, syncobjs;
[Mesa-dev] [PATCH v3 03/17] panfrost: Add a batch fence
So we can implement fine-grained dependency tracking between batches.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* Fix typos
* Do not initialize the syncobj in a signaled state, and set
fence->signaled to true when submitting a dummy batch (one with no
draw/clear queued)
---
src/gallium/drivers/panfrost/pan_job.c | 56 +-
src/gallium/drivers/panfrost/pan_job.h | 39 ++
2 files changed, 94 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index 785317dbd0b0..b6763da66a97 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -36,6 +36,45 @@
#include "pan_util.h"
#include "pandecode/decode.h"
+static struct panfrost_batch_fence *
+panfrost_create_batch_fence(struct panfrost_batch *batch)
+{
+struct panfrost_batch_fence *fence;
+ASSERTED int ret;
+
+fence = rzalloc(NULL, struct panfrost_batch_fence);
+assert(fence);
+pipe_reference_init(&fence->reference, 1);
+fence->ctx = batch->ctx;
+fence->batch = batch;
+ret = drmSyncobjCreate(pan_screen(batch->ctx->base.screen)->fd, 0,
+ &fence->syncobj);
+assert(!ret);
+
+return fence;
+}
+
+static void
+panfrost_free_batch_fence(struct panfrost_batch_fence *fence)
+{
+drmSyncobjDestroy(pan_screen(fence->ctx->base.screen)->fd,
+ fence->syncobj);
+ralloc_free(fence);
+}
+
+void
+panfrost_batch_fence_unreference(struct panfrost_batch_fence *fence)
+{
+if (pipe_reference(&fence->reference, NULL))
+ panfrost_free_batch_fence(fence);
+}
+
+void
+panfrost_batch_fence_reference(struct panfrost_batch_fence *fence)
+{
+pipe_reference(NULL, &fence->reference);
+}
+
static struct panfrost_batch *
panfrost_create_batch(struct panfrost_context *ctx,
const struct pipe_framebuffer_state *key)
@@ -53,6 +92,7 @@ panfrost_create_batch(struct panfrost_context *ctx,
util_dynarray_init(&batch->headers, batch);
util_dynarray_init(&batch->gpu_headers, batch);
+batch->out_sync = panfrost_create_batch_fence(batch);
util_copy_framebuffer_state(&batch->key, key);
return batch;
@@ -74,6 +114,15 @@ panfrost_free_batch(struct panfrost_batch *batch)
if (ctx->batch == batch)
ctx->batch = NULL;
+/* The out_sync fence lifetime is different from the the batch one
+ * since other batches might want to wait on a fence of already
+ * submitted/signaled batch. All we need to do here is make sure the
+ * fence does not point to an invalid batch, which the core will
+ * interpret as 'batch is already submitted'.
+ */
+batch->out_sync->batch = NULL;
+panfrost_batch_fence_unreference(batch->out_sync);
+
util_unreference_framebuffer_state(&batch->key);
ralloc_free(batch);
}
@@ -441,8 +490,13 @@ panfrost_batch_submit(struct panfrost_batch *batch)
int ret;
/* Nothing to do! */
-if (!batch->last_job.gpu && !batch->clear)
+if (!batch->last_job.gpu && !batch->clear) {
+/* Mark the fence as signaled so the fence logic does not try
+ * to wait on it.
+ */
+batch->out_sync->signaled = true;
goto out;
+}
if (!batch->clear && batch->last_tiler.gpu)
panfrost_batch_draw_wallpaper(batch);
diff --git a/src/gallium/drivers/panfrost/pan_job.h
b/src/gallium/drivers/panfrost/pan_job.h
index 3f2cf1a999f3..88f1e4620fd0 100644
--- a/src/gallium/drivers/panfrost/pan_job.h
+++ b/src/gallium/drivers/panfrost/pan_job.h
@@ -31,6 +31,36 @@
#include "pan_allocate.h"
#include "pan_resource.h"
+/* panfrost_batch_fence is the out fence of a batch that users or other batches
+ * might want to wait on. The batch fence lifetime is different from the batch
+ * one as want will certainly want to wait upon the fence after the batch has
+ * been submitted (which is when panfrost_batch objects are freed).
+ */
+struct panfrost_batch_fence {
+/* Refcounting object for the fence. */
+struct pipe_reference reference;
+
+/* Batch that created this fence object. Will become NULL at batch
+ * submission time. This field is mainly here to know whether the
+ * batch has been flushed or not.
+ */
+struct panfrost_batch *batch;
+
+/* Context this fence is attached to. We need both ctx and batch, as
+ * the batch will go away after it's been submitted, but the fence
+ * will stay a bit longer.
+ */
+struct panfrost_context *ctx;
+
+/* Sync object backing this fence. */
+uint32_t syncobj;
+
+/* Cached value of the signaled state to avoid calling WAIT_SYNCOB
[Mesa-dev] [PATCH v3 02/17] panfrost: Make panfrost_batch->bos a hash table
So we can store the flags as data and keep the BO as a key. This way
we keep track of the type of access done on BOs.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* None
---
src/gallium/drivers/panfrost/pan_job.c | 33 +-
src/gallium/drivers/panfrost/pan_job.h | 2 +-
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index 8e2703ae168c..785317dbd0b0 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -44,9 +44,8 @@ panfrost_create_batch(struct panfrost_context *ctx,
batch->ctx = ctx;
-batch->bos = _mesa_set_create(batch,
- _mesa_hash_pointer,
- _mesa_key_pointer_equal);
+batch->bos = _mesa_hash_table_create(batch, _mesa_hash_pointer,
+ _mesa_key_pointer_equal);
batch->minx = batch->miny = ~0;
batch->maxx = batch->maxy = 0;
@@ -67,10 +66,8 @@ panfrost_free_batch(struct panfrost_batch *batch)
struct panfrost_context *ctx = batch->ctx;
-set_foreach(batch->bos, entry) {
-struct panfrost_bo *bo = (struct panfrost_bo *)entry->key;
-panfrost_bo_unreference(bo);
-}
+hash_table_foreach(batch->bos, entry)
+panfrost_bo_unreference((struct panfrost_bo *)entry->key);
_mesa_hash_table_remove_key(ctx->batches, &batch->key);
@@ -138,11 +135,25 @@ panfrost_batch_add_bo(struct panfrost_batch *batch,
struct panfrost_bo *bo,
if (!bo)
return;
-if (_mesa_set_search(batch->bos, bo))
+struct hash_entry *entry;
+uint32_t old_flags = 0;
+
+entry = _mesa_hash_table_search(batch->bos, bo);
+if (!entry) {
+entry = _mesa_hash_table_insert(batch->bos, bo,
+(void *)(uintptr_t)flags);
+panfrost_bo_reference(bo);
+ } else {
+old_flags = (uintptr_t)entry->data;
+}
+
+assert(entry);
+
+if (old_flags == flags)
return;
-panfrost_bo_reference(bo);
-_mesa_set_add(batch->bos, bo);
+flags |= old_flags;
+entry->data = (void *)(uintptr_t)flags;
}
void panfrost_batch_add_fbo_bos(struct panfrost_batch *batch)
@@ -376,7 +387,7 @@ panfrost_batch_submit_ioctl(struct panfrost_batch *batch,
bo_handles = calloc(batch->bos->entries, sizeof(*bo_handles));
assert(bo_handles);
-set_foreach(batch->bos, entry) {
+hash_table_foreach(batch->bos, entry) {
struct panfrost_bo *bo = (struct panfrost_bo *)entry->key;
assert(bo->gem_handle > 0);
bo_handles[submit.bo_handle_count++] = bo->gem_handle;
diff --git a/src/gallium/drivers/panfrost/pan_job.h
b/src/gallium/drivers/panfrost/pan_job.h
index 0b37a3131e86..3f2cf1a999f3 100644
--- a/src/gallium/drivers/panfrost/pan_job.h
+++ b/src/gallium/drivers/panfrost/pan_job.h
@@ -98,7 +98,7 @@ struct panfrost_batch {
unsigned job_index;
/* BOs referenced -- will be used for flushing logic */
-struct set *bos;
+struct hash_table *bos;
/* Current transient BO */
struct panfrost_bo *transient_bo;
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 05/17] panfrost: Add a panfrost_freeze_batch() helper
We'll soon need to freeze a batch not only when it's flushed, but also
when another batch depends on us, so let's add a helper to avoid
duplicating the logic.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v3:
* Collect R-b
---
src/gallium/drivers/panfrost/pan_job.c | 62 ++
1 file changed, 44 insertions(+), 18 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index 55780dd3d9d6..872c846207bf 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -98,22 +98,59 @@ panfrost_create_batch(struct panfrost_context *ctx,
return batch;
}
+static void
+panfrost_freeze_batch(struct panfrost_batch *batch)
+{
+struct panfrost_context *ctx = batch->ctx;
+struct hash_entry *entry;
+
+/* Remove the entry in the FBO -> batch hash table if the batch
+ * matches. This way, next draws/clears targeting this FBO will trigger
+ * the creation of a new batch.
+ */
+entry = _mesa_hash_table_search(ctx->batches, &batch->key);
+if (entry && entry->data == batch)
+_mesa_hash_table_remove(ctx->batches, entry);
+
+/* If this is the bound batch, the panfrost_context parameters are
+ * relevant so submitting it invalidates those parameters, but if it's
+ * not bound, the context parameters are for some other batch so we
+ * can't invalidate them.
+ */
+if (ctx->batch == batch) {
+panfrost_invalidate_frame(ctx);
+ctx->batch = NULL;
+}
+}
+
+#ifndef NDEBUG
+static bool panfrost_batch_is_frozen(struct panfrost_batch *batch)
+{
+struct panfrost_context *ctx = batch->ctx;
+struct hash_entry *entry;
+
+entry = _mesa_hash_table_search(ctx->batches, &batch->key);
+if (entry && entry->data == batch)
+return false;
+
+if (ctx->batch == batch)
+return false;
+
+return true;
+}
+#endif
+
static void
panfrost_free_batch(struct panfrost_batch *batch)
{
if (!batch)
return;
-struct panfrost_context *ctx = batch->ctx;
+assert(panfrost_batch_is_frozen(batch));
hash_table_foreach(batch->bos, entry)
panfrost_bo_unreference((struct panfrost_bo *)entry->key);
-_mesa_hash_table_remove_key(ctx->batches, &batch->key);
-
-if (ctx->batch == batch)
-ctx->batch = NULL;
-
/* The out_sync fence lifetime is different from the the batch one
* since other batches might want to wait on a fence of already
* submitted/signaled batch. All we need to do here is make sure the
@@ -529,19 +566,8 @@ panfrost_batch_submit(struct panfrost_batch *batch)
fprintf(stderr, "panfrost_batch_submit failed: %d\n", ret);
out:
-/* If this is the bound batch, the panfrost_context parameters are
- * relevant so submitting it invalidates those paramaters, but if it's
- * not bound, the context parameters are for some other batch so we
- * can't invalidate them.
- */
-if (ctx->batch == batch)
-panfrost_invalidate_frame(ctx);
-
-/* The job has been submitted, let's invalidate the current FBO job
- * cache.
-*/
+panfrost_freeze_batch(batch);
assert(!ctx->batch || batch == ctx->batch);
-ctx->batch = NULL;
/* We always stall the pipeline for correct results since pipelined
* rendering is quite broken right now (to be fixed by the panfrost_job
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 09/17] panfrost: Add a panfrost_flush_batches_accessing_bo() helper
This will allow us to only flush batches touching a specific resource,
which is particularly useful when the CPU needs to access a BO.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v3:
* Collect R-b
---
src/gallium/drivers/panfrost/pan_job.c | 31 ++
src/gallium/drivers/panfrost/pan_job.h | 4
2 files changed, 35 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index 3ccf4bb6b3e9..e7eae399830f 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -952,6 +952,37 @@ panfrost_flush_all_batches(struct panfrost_context *ctx,
bool wait)
util_dynarray_fini(&syncobjs);
}
+void
+panfrost_flush_batches_accessing_bo(struct panfrost_context *ctx,
+struct panfrost_bo *bo,
+uint32_t access_type)
+{
+struct panfrost_bo_access *access;
+struct hash_entry *hentry;
+
+/* It doesn't make any to flush only the readers. */
+assert(access_type == PAN_BO_ACCESS_WRITE ||
+ access_type == PAN_BO_ACCESS_RW);
+
+hentry = _mesa_hash_table_search(ctx->accessed_bos, bo);
+access = hentry ? hentry->data : NULL;
+if (!access)
+return;
+
+if (access_type & PAN_BO_ACCESS_WRITE && access->writer &&
+access->writer->batch)
+panfrost_batch_submit(access->writer->batch);
+
+if (!(access_type & PAN_BO_ACCESS_READ))
+return;
+
+util_dynarray_foreach(&access->readers, struct panfrost_batch_fence *,
+ reader) {
+if (*reader && (*reader)->batch)
+panfrost_batch_submit((*reader)->batch);
+}
+}
+
void
panfrost_batch_set_requirements(struct panfrost_batch *batch)
{
diff --git a/src/gallium/drivers/panfrost/pan_job.h
b/src/gallium/drivers/panfrost/pan_job.h
index e95e156a40f8..25905b516739 100644
--- a/src/gallium/drivers/panfrost/pan_job.h
+++ b/src/gallium/drivers/panfrost/pan_job.h
@@ -185,6 +185,10 @@ panfrost_batch_create_bo(struct panfrost_batch *batch,
size_t size,
void
panfrost_flush_all_batches(struct panfrost_context *ctx, bool wait);
+void
+panfrost_flush_batches_accessing_bo(struct panfrost_context *ctx,
+struct panfrost_bo *bo, uint32_t flags);
+
void
panfrost_batch_set_requirements(struct panfrost_batch *batch);
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 07/17] panfrost: Prepare panfrost_fence for batch pipelining
The panfrost_fence logic currently waits on the last submitted batch,
but the batch serialization that was enforced in
panfrost_batch_submit() is about to go away, allowing for several
batches to be pipelined, and the last submitted one is not necessarily
the one that will finish last.
We need to make sure the fence logic waits on all flushed batches, not
only the last one.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v3:
* Fix a comment
* Adjust things to match the changes done in "panfrost: Add a batch fence"
---
src/gallium/drivers/panfrost/pan_context.c | 18 +-
src/gallium/drivers/panfrost/pan_context.h | 5 +-
src/gallium/drivers/panfrost/pan_job.c | 16 -
src/gallium/drivers/panfrost/pan_screen.c | 71 +++---
src/gallium/drivers/panfrost/pan_screen.h | 3 +-
5 files changed, 57 insertions(+), 56 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 312a9e93e455..aad69e3f9991 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1349,14 +1349,30 @@ panfrost_flush(
{
struct panfrost_context *ctx = pan_context(pipe);
struct panfrost_batch *batch = panfrost_get_batch_for_fbo(ctx);
+struct util_dynarray fences;
+
+/* We must collect the fences before the flush is done, otherwise we'll
+ * lose track of them.
+ */
+if (fence) {
+util_dynarray_init(&fences, NULL);
+panfrost_batch_fence_reference(batch->out_sync);
+util_dynarray_append(&fences, struct panfrost_batch_fence *,
+ batch->out_sync);
+}
/* Submit the frame itself */
panfrost_batch_submit(batch);
if (fence) {
-struct panfrost_fence *f = panfrost_fence_create(ctx);
+struct panfrost_fence *f = panfrost_fence_create(ctx, &fences);
pipe->screen->fence_reference(pipe->screen, fence, NULL);
*fence = (struct pipe_fence_handle *)f;
+
+util_dynarray_foreach(&fences, struct panfrost_batch_fence *,
fence)
+panfrost_batch_fence_unreference(*fence);
+
+util_dynarray_fini(&fences);
}
}
diff --git a/src/gallium/drivers/panfrost/pan_context.h
b/src/gallium/drivers/panfrost/pan_context.h
index 3b09952345cf..d50ed57d5d8a 100644
--- a/src/gallium/drivers/panfrost/pan_context.h
+++ b/src/gallium/drivers/panfrost/pan_context.h
@@ -94,7 +94,7 @@ struct panfrost_query {
struct panfrost_fence {
struct pipe_reference reference;
-int fd;
+struct util_dynarray syncfds;
};
struct panfrost_streamout {
@@ -193,9 +193,6 @@ struct panfrost_context {
/* True for t6XX, false for t8xx. */
bool is_t6xx;
-
-/* The out sync fence of the last submitted batch. */
-struct panfrost_batch_fence *last_out_sync;
};
/* Corresponds to the CSO */
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index b0494af3482f..211e48bafd4e 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -819,13 +819,6 @@ panfrost_batch_submit_ioctl(struct panfrost_batch *batch,
free(bo_handles);
free(in_syncs);
-/* Release the last batch fence if any, and retain the new one */
-if (ctx->last_out_sync)
-panfrost_batch_fence_unreference(ctx->last_out_sync);
-
-panfrost_batch_fence_reference(batch->out_sync);
-ctx->last_out_sync = batch->out_sync;
-
if (ret) {
fprintf(stderr, "Error submitting: %m\n");
return errno;
@@ -884,15 +877,6 @@ panfrost_batch_submit(struct panfrost_batch *batch)
* to wait on it.
*/
batch->out_sync->signaled = true;
-
-/* Release the last batch fence if any, and set ->last_out_sync
- * to NULL
- */
-if (ctx->last_out_sync) {
-panfrost_batch_fence_unreference(ctx->last_out_sync);
-ctx->last_out_sync = NULL;
-}
-
goto out;
}
diff --git a/src/gallium/drivers/panfrost/pan_screen.c
b/src/gallium/drivers/panfrost/pan_screen.c
index e2c31f7f8213..55c66e0c9a79 100644
--- a/src/gallium/drivers/panfrost/pan_screen.c
+++ b/src/gallium/drivers/panfrost/pan_screen.c
@@ -575,7 +575,9 @@ panfrost_fence_reference(struct pipe_screen *pscreen,
struct panfrost_fence *old = *p;
if (pipe_reference(&(*p)->reference, &f->reference)) {
-close(old->fd);
+util_dynarray_foreach(&old->syncfds, int, fd)
+close(*fd);
+util_dynarray_fini(&old->syncfds);
[Mesa-dev] [PATCH v3 10/17] panfrost: Kill the explicit serialization in panfrost_batch_submit()
Now that we have all the pieces in place to support pipelining batches we can get rid of the drmSyncobjWait() at the end of panfrost_batch_submit(). Signed-off-by: Boris Brezillon Reviewed-by: Alyssa Rosenzweig --- Changes in v3: * Collect R-b --- src/gallium/drivers/panfrost/pan_job.c | 12 1 file changed, 12 deletions(-) diff --git a/src/gallium/drivers/panfrost/pan_job.c b/src/gallium/drivers/panfrost/pan_job.c index e7eae399830f..235cb21dc8c8 100644 --- a/src/gallium/drivers/panfrost/pan_job.c +++ b/src/gallium/drivers/panfrost/pan_job.c @@ -868,7 +868,6 @@ panfrost_batch_submit(struct panfrost_batch *batch) panfrost_batch_submit((*dep)->batch); } -struct panfrost_context *ctx = batch->ctx; int ret; /* Nothing to do! */ @@ -892,18 +891,7 @@ panfrost_batch_submit(struct panfrost_batch *batch) out: panfrost_freeze_batch(batch); - -/* We always stall the pipeline for correct results since pipelined - * rendering is quite broken right now (to be fixed by the panfrost_job - * refactor, just take the perf hit for correctness) - */ -if (!batch->out_sync->signaled) -drmSyncobjWait(pan_screen(ctx->base.screen)->fd, - &batch->out_sync->syncobj, 1, INT64_MAX, 0, - NULL); - panfrost_free_batch(batch); - } void -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 11/17] panfrost: Get rid of the flush in panfrost_set_framebuffer_state()
Now that we have track inter-batch dependencies, the flush done in
panfrost_set_framebuffer_state() is no longer needed. Let's get rid of
it.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v3:
* Collect R-b
---
src/gallium/drivers/panfrost/pan_context.c | 46 ++
1 file changed, 3 insertions(+), 43 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 861b4b621602..07bafad58a00 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -2299,50 +2299,10 @@ panfrost_set_framebuffer_state(struct pipe_context
*pctx,
{
struct panfrost_context *ctx = pan_context(pctx);
-/* Flush when switching framebuffers, but not if the framebuffer
- * state is being restored by u_blitter
- */
-
-struct panfrost_batch *batch = panfrost_get_batch_for_fbo(ctx);
-bool is_scanout = panfrost_batch_is_scanout(batch);
-bool has_draws = batch->last_job.gpu;
-
-/* Bail out early when the current and new states are the same. */
-if (util_framebuffer_state_equal(&ctx->pipe_framebuffer, fb))
-return;
-
-/* The wallpaper logic sets a new FB state before doing the blit and
- * restore the old one when it's done. Those FB states are reported to
- * be different because the surface they are pointing to are different,
- * but those surfaces actually point to the same cbufs/zbufs. In that
- * case we definitely don't want new FB descs to be emitted/attached
- * since the job is expected to be flushed just after the blit is done,
- * so let's just copy the new state and return here.
- */
-if (ctx->wallpaper_batch) {
-util_copy_framebuffer_state(&ctx->pipe_framebuffer, fb);
-return;
-}
-
-if (!is_scanout || has_draws)
-panfrost_flush_all_batches(ctx, true);
-else
-assert(!ctx->payloads[PIPE_SHADER_VERTEX].postfix.framebuffer
&&
-
!ctx->payloads[PIPE_SHADER_FRAGMENT].postfix.framebuffer);
-
-/* Invalidate the FBO job cache since we've just been assigned a new
- * FB state.
- */
-ctx->batch = NULL;
-
+panfrost_hint_afbc(pan_screen(pctx->screen), fb);
util_copy_framebuffer_state(&ctx->pipe_framebuffer, fb);
-
-/* Given that we're rendering, we'd love to have compression */
-struct panfrost_screen *screen = pan_screen(ctx->base.screen);
-
-panfrost_hint_afbc(screen, &ctx->pipe_framebuffer);
-for (unsigned i = 0; i < PIPE_SHADER_TYPES; ++i)
-ctx->payloads[i].postfix.framebuffer = 0;
+ctx->batch = NULL;
+panfrost_invalidate_frame(ctx);
}
static void *
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 06/17] panfrost: Start tracking inter-batch dependencies
The idea is to track which BO are being accessed and the type of access
to determine when a dependency exists. Thanks to that we can build a
dependency graph that will allow us to flush batches in the correct
order.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* Fix coding style issues
* Do not check for batch presence in the reader array when updating
a BO access (we already have this information)
* Add more comments to explain what we're doing and why we're doing
it like that
---
src/gallium/drivers/panfrost/pan_context.h | 3 +
src/gallium/drivers/panfrost/pan_job.c | 355 -
src/gallium/drivers/panfrost/pan_job.h | 3 +
3 files changed, 356 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.h
b/src/gallium/drivers/panfrost/pan_context.h
index ce3e0c899a4f..3b09952345cf 100644
--- a/src/gallium/drivers/panfrost/pan_context.h
+++ b/src/gallium/drivers/panfrost/pan_context.h
@@ -114,6 +114,9 @@ struct panfrost_context {
struct panfrost_batch *batch;
struct hash_table *batches;
+/* panfrost_bo -> panfrost_bo_access */
+struct hash_table *accessed_bos;
+
/* Within a launch_grid call.. */
const struct pipe_grid_info *compute_grid;
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index 872c846207bf..b0494af3482f 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -36,6 +36,29 @@
#include "pan_util.h"
#include "pandecode/decode.h"
+/* panfrost_bo_access is here to help us keep track of batch accesses to BOs
+ * and build a proper dependency graph such that batches can be pipelined for
+ * better GPU utilization.
+ *
+ * Each accessed BO has a corresponding entry in the ->accessed_bos hash table.
+ * A BO is either being written or read at any time, that's what the type field
+ * encodes.
+ * When the last access is a write, the batch writing the BO might have read
+ * dependencies (readers that have not been executed yet and want to read the
+ * previous BO content), and when the last access is a read, all readers might
+ * depend on another batch to push its results to memory. That's what the
+ * readers/writers keep track off.
+ * There can only be one writer at any given time, if a new batch wants to
+ * write to the same BO, a dependency will be added between the new writer and
+ * the old writer (at the batch level), and panfrost_bo_access->writer will be
+ * updated to point to the new writer.
+ */
+struct panfrost_bo_access {
+uint32_t type;
+struct util_dynarray readers;
+struct panfrost_batch_fence *writer;
+};
+
static struct panfrost_batch_fence *
panfrost_create_batch_fence(struct panfrost_batch *batch)
{
@@ -92,6 +115,7 @@ panfrost_create_batch(struct panfrost_context *ctx,
util_dynarray_init(&batch->headers, batch);
util_dynarray_init(&batch->gpu_headers, batch);
+util_dynarray_init(&batch->dependencies, batch);
batch->out_sync = panfrost_create_batch_fence(batch);
util_copy_framebuffer_state(&batch->key, key);
@@ -151,6 +175,11 @@ panfrost_free_batch(struct panfrost_batch *batch)
hash_table_foreach(batch->bos, entry)
panfrost_bo_unreference((struct panfrost_bo *)entry->key);
+util_dynarray_foreach(&batch->dependencies,
+ struct panfrost_batch_fence *, dep) {
+panfrost_batch_fence_unreference(*dep);
+}
+
/* The out_sync fence lifetime is different from the the batch one
* since other batches might want to wait on a fence of already
* submitted/signaled batch. All we need to do here is make sure the
@@ -164,6 +193,56 @@ panfrost_free_batch(struct panfrost_batch *batch)
ralloc_free(batch);
}
+#ifndef NDEBUG
+static bool
+panfrost_dep_graph_contains_batch(struct panfrost_batch *root,
+ struct panfrost_batch *batch)
+{
+if (!root)
+return false;
+
+util_dynarray_foreach(&root->dependencies,
+ struct panfrost_batch_fence *, dep) {
+if ((*dep)->batch == batch ||
+panfrost_dep_graph_contains_batch((*dep)->batch, batch))
+return true;
+}
+
+return false;
+}
+#endif
+
+static void
+panfrost_batch_add_dep(struct panfrost_batch *batch,
+ struct panfrost_batch_fence *newdep)
+{
+if (batch == newdep->batch)
+return;
+
+/* We might want to turn ->dependencies into a set if the number of
+ * deps turns out to be big enough to make this 'is dep already there'
+ * search inefficient.
+ */
+util_dynarray_foreach(&batch->dependencies,
+ struct panfrost_batch_fence *, dep) {
+if (*dep == newde
[Mesa-dev] [PATCH v3 14/17] panfrost: Do fine-grained flushing when preparing BO for CPU accesses
We don't have to flush all batches when we're only interested in
reading/writing a specific BO. Thanks to the
panfrost_flush_batches_accessing_bo() and panfrost_bo_wait() helpers
we can now flush only the batches touching the BO we want to access
from the CPU.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v3:
* Collect R-b
---
src/gallium/drivers/panfrost/pan_resource.c | 27 +
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index 1f7605adcd5d..d59529ff15b7 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -578,10 +578,8 @@ panfrost_transfer_map(struct pipe_context *pctx,
is_bound |= fb->cbufs[c]->texture == resource;
}
-if (is_bound && (usage & PIPE_TRANSFER_READ)) {
-assert(level == 0);
-panfrost_flush_all_batches(ctx, true);
-}
+if (is_bound && (usage & PIPE_TRANSFER_READ))
+ assert(level == 0);
/* TODO: Respect usage flags */
@@ -594,11 +592,11 @@ panfrost_transfer_map(struct pipe_context *pctx,
/* No flush for writes to uninitialized */
} else if (!(usage & PIPE_TRANSFER_UNSYNCHRONIZED)) {
if (usage & PIPE_TRANSFER_WRITE) {
-/* STUB: flush reading */
-//printf("debug: missed reading flush %d\n",
resource->target);
+panfrost_flush_batches_accessing_bo(ctx, bo,
PAN_BO_GPU_ACCESS_RW);
+panfrost_bo_wait(bo, INT64_MAX, PAN_BO_GPU_ACCESS_RW);
} else if (usage & PIPE_TRANSFER_READ) {
-/* STUB: flush writing */
-//printf("debug: missed writing flush %d (%d-%d)\n",
resource->target, box->x, box->x + box->width);
+panfrost_flush_batches_accessing_bo(ctx, bo,
PAN_BO_GPU_ACCESS_WRITE);
+panfrost_bo_wait(bo, INT64_MAX,
PAN_BO_GPU_ACCESS_WRITE);
} else {
/* Why are you even mapping?! */
}
@@ -748,11 +746,8 @@ panfrost_generate_mipmap(
* reorder-type optimizations in place. But for now prioritize
* correctness. */
-struct panfrost_batch *batch = panfrost_get_batch_for_fbo(ctx);
-bool has_draws = batch->last_job.gpu;
-
-if (has_draws)
-panfrost_flush_all_batches(ctx, true);
+panfrost_flush_batches_accessing_bo(ctx, rsrc->bo,
PAN_BO_GPU_ACCESS_RW);
+panfrost_bo_wait(rsrc->bo, INT64_MAX, PAN_BO_GPU_ACCESS_RW);
/* We've flushed the original buffer if needed, now trigger a blit */
@@ -765,8 +760,10 @@ panfrost_generate_mipmap(
/* If the blit was successful, flush once more. If it wasn't, well, let
* the state tracker deal with it. */
-if (blit_res)
-panfrost_flush_all_batches(ctx, true);
+if (blit_res) {
+panfrost_flush_batches_accessing_bo(ctx, rsrc->bo,
PAN_BO_GPU_ACCESS_WRITE);
+panfrost_bo_wait(rsrc->bo, INT64_MAX, PAN_BO_GPU_ACCESS_WRITE);
+}
return blit_res;
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 16/17] panfrost: Take draw call order into account
This is not strictly required, but let's try to match the draw call
orders, just in case the app had a reason to do it in this order.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.h | 6 ++
src/gallium/drivers/panfrost/pan_job.c | 23 +++---
src/gallium/drivers/panfrost/pan_job.h | 3 +++
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.h
b/src/gallium/drivers/panfrost/pan_context.h
index f13967f51b46..c6b53685b285 100644
--- a/src/gallium/drivers/panfrost/pan_context.h
+++ b/src/gallium/drivers/panfrost/pan_context.h
@@ -114,6 +114,12 @@ struct panfrost_context {
struct panfrost_batch *batch;
struct hash_table *fbo_to_batch;
+/* A list containing all non-submitted batches since the last flush.
+ * This list is used to keep track of clear/draw order on batches that
+ * don't have explicit dependencies between them.
+ */
+struct list_head batch_queue;
+
/* panfrost_bo -> panfrost_bo_access */
struct hash_table *accessed_bos;
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index 45f9d9d24b41..d8330bc133a6 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -116,6 +116,7 @@ panfrost_create_batch(struct panfrost_context *ctx,
util_dynarray_init(&batch->headers, batch);
util_dynarray_init(&batch->gpu_headers, batch);
util_dynarray_init(&batch->dependencies, batch);
+list_inithead(&batch->queue_node);
batch->out_sync = panfrost_create_batch_fence(batch);
util_copy_framebuffer_state(&batch->key, key);
@@ -180,6 +181,9 @@ panfrost_free_batch(struct panfrost_batch *batch)
panfrost_batch_fence_unreference(*dep);
}
+/* Remove the batch from the batch queue. */
+list_del(&batch->queue_node);
+
/* The out_sync fence lifetime is different from the the batch one
* since other batches might want to wait on a fence of already
* submitted/signaled batch. All we need to do here is make sure the
@@ -570,6 +574,13 @@ void panfrost_batch_add_fbo_bos(struct panfrost_batch
*batch)
struct panfrost_resource *rsrc =
pan_resource(batch->key.zsbuf->texture);
panfrost_batch_add_bo(batch, rsrc->bo, flags);
}
+
+/* We the batch was not already present in the queue, add it know.
+ * Should we move the batch at end of the queue when a new draw
+ * happens?
+ */
+if (list_empty(&batch->queue_node))
+list_addtail(&batch->queue_node, &batch->ctx->batch_queue);
}
struct panfrost_bo *
@@ -916,10 +927,15 @@ panfrost_flush_all_batches(struct panfrost_context *ctx,
bool wait)
util_dynarray_init(&syncobjs, NULL);
}
-hash_table_foreach(ctx->fbo_to_batch, hentry) {
-struct panfrost_batch *batch = hentry->data;
+/* We can use the for_each_entry_safe() iterator here because the
+ * next element might be removed from the list when flushing the
+ * dependencies in panfrost_batch_submit().
+ */
+while (!list_empty(&ctx->batch_queue)) {
+struct panfrost_batch *batch;
-assert(batch);
+batch = list_first_entry(&ctx->batch_queue,
+ struct panfrost_batch, queue_node);
if (wait) {
panfrost_batch_fence_reference(batch->out_sync);
@@ -1189,4 +1205,5 @@ panfrost_batch_init(struct panfrost_context *ctx)
panfrost_batch_compare);
ctx->accessed_bos = _mesa_hash_table_create(ctx, _mesa_hash_pointer,
_mesa_key_pointer_equal);
+list_inithead(&ctx->batch_queue);
}
diff --git a/src/gallium/drivers/panfrost/pan_job.h
b/src/gallium/drivers/panfrost/pan_job.h
index 25905b516739..e1b1f56a2e64 100644
--- a/src/gallium/drivers/panfrost/pan_job.h
+++ b/src/gallium/drivers/panfrost/pan_job.h
@@ -71,6 +71,9 @@ struct panfrost_batch {
struct panfrost_context *ctx;
struct pipe_framebuffer_state key;
+/* Used to insert the batch in the batch queue */
+struct list_head queue_node;
+
/* Buffers cleared (PIPE_CLEAR_* bitmask) */
unsigned clear;
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 15/17] panfrost: Rename ctx->batches into ctx->fbo_to_batch
We are about to add a batch queue to keep track of submission order.
Let's rename the existing batches hash table (which is used to get the
batch attached to an FBO) into fbo_to_batch to avoid confusion.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 2 +-
src/gallium/drivers/panfrost/pan_context.h | 2 +-
src/gallium/drivers/panfrost/pan_job.c | 21 +++--
src/gallium/drivers/panfrost/pan_resource.c | 16
4 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 07bafad58a00..0330b5852676 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1355,7 +1355,7 @@ panfrost_flush(
*/
if (fence) {
util_dynarray_init(&fences, NULL);
-hash_table_foreach(ctx->batches, hentry) {
+hash_table_foreach(ctx->fbo_to_batch, hentry) {
struct panfrost_batch *batch = hentry->data;
panfrost_batch_fence_reference(batch->out_sync);
diff --git a/src/gallium/drivers/panfrost/pan_context.h
b/src/gallium/drivers/panfrost/pan_context.h
index d50ed57d5d8a..f13967f51b46 100644
--- a/src/gallium/drivers/panfrost/pan_context.h
+++ b/src/gallium/drivers/panfrost/pan_context.h
@@ -112,7 +112,7 @@ struct panfrost_context {
/* Bound job batch and map of panfrost_batch_key to job batches */
struct panfrost_batch *batch;
-struct hash_table *batches;
+struct hash_table *fbo_to_batch;
/* panfrost_bo -> panfrost_bo_access */
struct hash_table *accessed_bos;
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index a56f4044fda0..45f9d9d24b41 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -132,9 +132,9 @@ panfrost_freeze_batch(struct panfrost_batch *batch)
* matches. This way, next draws/clears targeting this FBO will trigger
* the creation of a new batch.
*/
-entry = _mesa_hash_table_search(ctx->batches, &batch->key);
+entry = _mesa_hash_table_search(ctx->fbo_to_batch, &batch->key);
if (entry && entry->data == batch)
-_mesa_hash_table_remove(ctx->batches, entry);
+_mesa_hash_table_remove(ctx->fbo_to_batch, entry);
/* If this is the bound batch, the panfrost_context parameters are
* relevant so submitting it invalidates those parameters, but if it's
@@ -153,7 +153,7 @@ static bool panfrost_batch_is_frozen(struct panfrost_batch
*batch)
struct panfrost_context *ctx = batch->ctx;
struct hash_entry *entry;
-entry = _mesa_hash_table_search(ctx->batches, &batch->key);
+entry = _mesa_hash_table_search(ctx->fbo_to_batch, &batch->key);
if (entry && entry->data == batch)
return false;
@@ -248,7 +248,8 @@ panfrost_get_batch(struct panfrost_context *ctx,
const struct pipe_framebuffer_state *key)
{
/* Lookup the job first */
-struct hash_entry *entry = _mesa_hash_table_search(ctx->batches, key);
+struct hash_entry *entry = _mesa_hash_table_search(ctx->fbo_to_batch,
+ key);
if (entry)
return entry->data;
@@ -258,7 +259,7 @@ panfrost_get_batch(struct panfrost_context *ctx,
struct panfrost_batch *batch = panfrost_create_batch(ctx, key);
/* Save the created job */
-_mesa_hash_table_insert(ctx->batches, &batch->key, batch);
+_mesa_hash_table_insert(ctx->fbo_to_batch, &batch->key, batch);
return batch;
}
@@ -915,7 +916,7 @@ panfrost_flush_all_batches(struct panfrost_context *ctx,
bool wait)
util_dynarray_init(&syncobjs, NULL);
}
-hash_table_foreach(ctx->batches, hentry) {
+hash_table_foreach(ctx->fbo_to_batch, hentry) {
struct panfrost_batch *batch = hentry->data;
assert(batch);
@@ -931,7 +932,7 @@ panfrost_flush_all_batches(struct panfrost_context *ctx,
bool wait)
panfrost_batch_submit(batch);
}
-assert(!ctx->batches->entries);
+assert(!ctx->fbo_to_batch->entries);
/* Collect batch fences before returning */
panfrost_gc_fences(ctx);
@@ -1183,9 +1184,9 @@ panfrost_batch_is_scanout(struct panfrost_batch *batch)
void
panfrost_batch_init(struct panfrost_context *ctx)
{
-ctx->batches = _mesa_hash_table_create(ctx,
- panfrost_batch_hash,
- panfrost_batch_compare);
+ctx->fbo_to_batch = _mesa_hash_table_create(ctx,
+panfrost_bat
[Mesa-dev] [PATCH v3 12/17] panfrost: Add flags to reflect the BO imported/exported state
Will be useful to make the ioctl(WAIT_BO) call conditional on BOs that are not exported/imported (meaning that all GPU accesses are known by the context). Signed-off-by: Boris Brezillon Reviewed-by: Alyssa Rosenzweig --- Changes in v3: * Collect R-b --- src/gallium/drivers/panfrost/pan_bo.c | 4 ++-- src/gallium/drivers/panfrost/pan_bo.h | 6 ++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/panfrost/pan_bo.c b/src/gallium/drivers/panfrost/pan_bo.c index 209d1e0d71e5..9daddf9d0cc2 100644 --- a/src/gallium/drivers/panfrost/pan_bo.c +++ b/src/gallium/drivers/panfrost/pan_bo.c @@ -355,7 +355,7 @@ panfrost_bo_import(struct panfrost_screen *screen, int fd) bo->gem_handle = gem_handle; bo->gpu = (mali_ptr) get_bo_offset.offset; bo->size = lseek(fd, 0, SEEK_END); -bo->flags |= PAN_BO_DONT_REUSE; +bo->flags |= PAN_BO_DONT_REUSE | PAN_BO_IMPORTED; assert(bo->size > 0); pipe_reference_init(&bo->reference, 1); @@ -376,7 +376,7 @@ panfrost_bo_export(struct panfrost_bo *bo) if (ret == -1) return -1; -bo->flags |= PAN_BO_DONT_REUSE; +bo->flags |= PAN_BO_DONT_REUSE | PAN_BO_EXPORTED; return args.fd; } diff --git a/src/gallium/drivers/panfrost/pan_bo.h b/src/gallium/drivers/panfrost/pan_bo.h index 73cc74a260d4..e4743f820aeb 100644 --- a/src/gallium/drivers/panfrost/pan_bo.h +++ b/src/gallium/drivers/panfrost/pan_bo.h @@ -56,6 +56,12 @@ struct panfrost_screen; * let the BO logic know about this contraint. */ #define PAN_BO_DONT_REUSE (1 << 5) +/* BO has been imported */ +#define PAN_BO_IMPORTED (1 << 6) + +/* BO has been exported */ +#define PAN_BO_EXPORTED (1 << 7) + /* GPU access flags */ /* BO is either shared (can be accessed by more than one GPU batch) or private -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 13/17] panfrost: Make sure the BO is 'ready' when picked from the cache
This is needed if we want to free the panfrost_batch object at submit
time in order to not have to GC the batch on the next job submission.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* Move the patch later in the series and squash "panfrost: Cache GPU
accesses to BOs" in it
* Add extra comments to explain what we're doing
---
src/gallium/drivers/panfrost/pan_bo.c | 112 -
src/gallium/drivers/panfrost/pan_bo.h | 9 ++
src/gallium/drivers/panfrost/pan_job.c | 11 +++
3 files changed, 109 insertions(+), 23 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_bo.c
b/src/gallium/drivers/panfrost/pan_bo.c
index 9daddf9d0cc2..37602688d630 100644
--- a/src/gallium/drivers/panfrost/pan_bo.c
+++ b/src/gallium/drivers/panfrost/pan_bo.c
@@ -23,6 +23,7 @@
* Authors (Collabora):
* Alyssa Rosenzweig
*/
+#include
#include
#include
#include
@@ -101,6 +102,63 @@ panfrost_bo_free(struct panfrost_bo *bo)
ralloc_free(bo);
}
+/* Returns true if the BO is ready, false otherwise.
+ * access_type is encoding the type of access one wants to ensure is done.
+ * Say you want to make sure all writers are done writing, you should pass
+ * PAN_BO_ACCESS_WRITE.
+ * If you want to wait for all users, you should pass PAN_BO_ACCESS_RW.
+ * PAN_BO_ACCESS_READ would work too as waiting for readers implies
+ * waiting for writers as well, but we want to make things explicit and waiting
+ * only for readers is impossible.
+ */
+bool
+panfrost_bo_wait(struct panfrost_bo *bo, int64_t timeout_ns,
+ uint32_t access_type)
+{
+struct drm_panfrost_wait_bo req = {
+.handle = bo->gem_handle,
+ .timeout_ns = timeout_ns,
+};
+int ret;
+
+assert(access_type == PAN_BO_ACCESS_WRITE ||
+ access_type == PAN_BO_ACCESS_RW);
+
+/* If the BO has been exported or imported we can't rely on the cached
+ * state, we need to call the WAIT_BO ioctl.
+ */
+if (!(bo->flags & (PAN_BO_IMPORTED | PAN_BO_EXPORTED))) {
+/* If ->gpu_access is 0, the BO is idle, no need to wait. */
+if (!bo->gpu_access)
+return true;
+
+/* If the caller only wants to wait for writers and no
+ * writes are pending, we don't have to wait.
+ */
+if (access_type == PAN_BO_ACCESS_WRITE &&
+!(bo->gpu_access & PAN_BO_ACCESS_WRITE))
+return true;
+}
+
+/* The ioctl returns >= 0 value when the BO we are waiting for is ready
+ * -1 otherwise.
+ */
+ret = drmIoctl(bo->screen->fd, DRM_IOCTL_PANFROST_WAIT_BO, &req);
+if (ret != -1) {
+/* Set gpu_access to 0 so that the next call to bo_wait()
+ * doesn't have to call the WAIT_BO ioctl.
+ */
+bo->gpu_access = 0;
+return true;
+}
+
+/* If errno is not ETIMEDOUT or EBUSY that means the handle we passed
+ * is invalid, which shouldn't happen here.
+ */
+assert(errno == ETIMEDOUT || errno == EBUSY);
+return false;
+}
+
/* Helper to calculate the bucket index of a BO */
static unsigned
@@ -137,9 +195,8 @@ pan_bucket(struct panfrost_screen *screen, unsigned size)
* BO. */
static struct panfrost_bo *
-panfrost_bo_cache_fetch(
-struct panfrost_screen *screen,
-size_t size, uint32_t flags)
+panfrost_bo_cache_fetch(struct panfrost_screen *screen,
+size_t size, uint32_t flags, bool dontwait)
{
pthread_mutex_lock(&screen->bo_cache_lock);
struct list_head *bucket = pan_bucket(screen, size);
@@ -147,27 +204,30 @@ panfrost_bo_cache_fetch(
/* Iterate the bucket looking for something suitable */
list_for_each_entry_safe(struct panfrost_bo, entry, bucket, link) {
-if (entry->size >= size &&
-entry->flags == flags) {
-int ret;
-struct drm_panfrost_madvise madv;
+if (entry->size < size || entry->flags != flags)
+continue;
-/* This one works, splice it out of the cache */
-list_del(&entry->link);
+if (!panfrost_bo_wait(entry, dontwait ? 0 : INT64_MAX,
+ PAN_BO_ACCESS_RW))
+continue;
-madv.handle = entry->gem_handle;
-madv.madv = PANFROST_MADV_WILLNEED;
-madv.retained = 0;
+struct drm_panfrost_madvise madv = {
+.handle = entry->gem_handle,
+.madv = PANFROST_MADV_WILLNEED,
+};
+int ret;
-ret = drmIoctl(screen->f
[Mesa-dev] [PATCH v3 17/17] panfrost/ci: New tests are passing
All dEQP-GLES2.functional.fbo.render.texsubimage.* tests are now passing. Signed-off-by: Boris Brezillon Reviewed-by: Alyssa Rosenzweig --- Changes in v3: * Collect R-b --- src/gallium/drivers/panfrost/ci/expected-failures.txt | 4 1 file changed, 4 deletions(-) diff --git a/src/gallium/drivers/panfrost/ci/expected-failures.txt b/src/gallium/drivers/panfrost/ci/expected-failures.txt index b0fc872a3009..3c707230dd23 100644 --- a/src/gallium/drivers/panfrost/ci/expected-failures.txt +++ b/src/gallium/drivers/panfrost/ci/expected-failures.txt @@ -53,10 +53,6 @@ dEQP-GLES2.functional.fbo.render.shared_colorbuffer.tex2d_rgb_depth_component16 dEQP-GLES2.functional.fbo.render.shared_depthbuffer.rbo_rgb565_depth_component16 Fail dEQP-GLES2.functional.fbo.render.shared_depthbuffer.tex2d_rgba_depth_component16 Fail dEQP-GLES2.functional.fbo.render.shared_depthbuffer.tex2d_rgb_depth_component16 Fail -dEQP-GLES2.functional.fbo.render.texsubimage.after_render_tex2d_rgba Fail -dEQP-GLES2.functional.fbo.render.texsubimage.after_render_tex2d_rgb Fail -dEQP-GLES2.functional.fbo.render.texsubimage.between_render_tex2d_rgba Fail -dEQP-GLES2.functional.fbo.render.texsubimage.between_render_tex2d_rgb Fail dEQP-GLES2.functional.fragment_ops.depth_stencil.random.0 Fail dEQP-GLES2.functional.fragment_ops.depth_stencil.random.10 Fail dEQP-GLES2.functional.fragment_ops.depth_stencil.random.11 Fail -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110995] performance regression in Heroes of the Storm with Mesa 19.1.1 & Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110995 Samuel Pitoiset changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #9 from Samuel Pitoiset --- Can you please pull the MR and try again? Does the performance regression is still fixed? I would say yes, just want a confirmation. -- 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 1/2] panfrost: Fix indexed draws
->padded_count should be large enough to cover all vertices pointed by
the index array. Use the local vertex_count variable that contains the
updated vertex_count value for the indexed draw case.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 08b799b66bf8..1b8558c1c2c1 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1601,7 +1601,7 @@ panfrost_draw_vbo(
ctx->padded_count = pan_expand_shift_odd(so);
} else {
-ctx->padded_count = ctx->vertex_count;
+ctx->padded_count = vertex_count;
/* Reset instancing state */
ctx->payloads[PIPE_SHADER_VERTEX].instance_shift = 0;
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] dEQP-GLES2.functional.buffer.write.use.index_array.* are passing now.
Signed-off-by: Boris Brezillon --- src/gallium/drivers/panfrost/ci/expected-failures.txt | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/gallium/drivers/panfrost/ci/expected-failures.txt b/src/gallium/drivers/panfrost/ci/expected-failures.txt index b0fc872a3009..0cadaa20cdb2 100644 --- a/src/gallium/drivers/panfrost/ci/expected-failures.txt +++ b/src/gallium/drivers/panfrost/ci/expected-failures.txt @@ -1,5 +1,3 @@ -dEQP-GLES2.functional.buffer.write.use.index_array.array Fail -dEQP-GLES2.functional.buffer.write.use.index_array.element_array Fail dEQP-GLES2.functional.color_clear.masked_rgba Fail dEQP-GLES2.functional.color_clear.masked_rgb Fail dEQP-GLES2.functional.color_clear.masked_scissored_rgba Fail -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111734] Geometry shader with double interpolators fails in LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=111734
Bug ID: 111734
Summary: Geometry shader with double interpolators fails in
LLVM
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: not set
Component: Drivers/Vulkan/radeon
Assignee: mesa-dev@lists.freedesktop.org
Reporter: bald...@baldurk.org
QA Contact: mesa-dev@lists.freedesktop.org
Created attachment 145427
--> https://bugs.freedesktop.org/attachment.cgi?id=145427&action=edit
VkRunner test showing crash
When compiling a geometry shader with double inputs and outputs I get an LLVM
fatal error:
LLVM ERROR: Cannot select: 0x55de91ee9320: v2i32 = bitcast 0x55de91ee9048
0x55de91ee9048: f32,ch = BUFFER_LOAD<(dereferenceable load 4 from custom
TargetCustom7, align 1, addrspace 4)> 0x55de91dcfbc8, 0x55de91e58860,
Constant:i32<0>, 0x55de91ee8a98, Constant:i32<0>, Constant:i32<0>,
Constant:i32<1>, Constant:i1<0>
0x55de91e58860: v4i32,ch = load<(invariant load 16 from %ir.12, addrspace
4)> 0x55de91dcfbc8, 0x55de91e581e0, undef:i64
0x55de91e581e0: i64 = add 0x55de91e587f8, Constant:i64<32>
0x55de91e587f8: i64,ch = CopyFromReg 0x55de91dcfbc8, Register:i64 %0
0x55de91ee8e40: i64 = Register %0
0x55de91e58318: i64 = Constant<32>
0x55de91e58380: i64 = undef
0x55de91ee8b68: i32 = Constant<0>
0x55de91ee8a98: i32 = add 0x55de91e58e10, Constant:i32<4096>
0x55de91e58e10: i32 = shl 0x55de91e58998, Constant:i32<2>
0x55de91e58998: i32,ch = CopyFromReg 0x55de91dcfbc8, Register:i32 %3
0x55de91e586c0: i32 = Register %3
0x55de91e58cd8: i32 = Constant<2>
0x55de91ee8a30: i32 = Constant<4096>
0x55de91ee8b68: i32 = Constant<0>
0x55de91ee8b68: i32 = Constant<0>
0x55de91e58ad0: i32 = Constant<1>
0x55de91eeb340: i1 = Constant<0>
In function: main
with this geometry shader:
#version 450 core
layout(triangles) in;
layout(triangle_strip, max_vertices = 3) out;
layout(location = 0) in double InDouble[3];
layout(location = 0) out double OutDouble;
void main() {
gl_Position = vec4(0);
for(int i = 0; i < 3; i++) {
OutDouble = InDouble[i];
EmitVertex();
}
EndPrimitive();
}
I've attached a VkRunner test which shows the crash.
--
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 110995] performance regression in Heroes of the Storm with Mesa 19.1.1 & Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110995 --- Comment #10 from tempel.jul...@gmail.com --- With the updated MR, performance unfortunately is worse again. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110995] performance regression in Heroes of the Storm with Mesa 19.1.1 & Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110995 --- Comment #11 from Samuel Pitoiset --- Okay, that's unfortunate but I prefer correctness vs performance. I will wait for the MR to be reviewed and let you know what happens. -- 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 111734] Geometry shader with double interpolators fails in LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=111734 Samuel Pitoiset changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Samuel Pitoiset --- Fixed by https://gitlab.freedesktop.org/mesa/mesa/commit/68820007fddbb5b79f1b2b08e66ef14092053a95 -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111737] nir_opt_algebraic.c takes too long to compile
https://bugs.freedesktop.org/show_bug.cgi?id=111737 Bug ID: 111737 Summary: nir_opt_algebraic.c takes too long to compile Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: glsl-compiler Assignee: mesa-dev@lists.freedesktop.org Reporter: i...@freedesktop.org QA Contact: intel-3d-b...@lists.freedesktop.org One our 72-thread build machine, release builds of Mesa used to take 90 seconds. They now take closer to 8 minutes. All of the extra time is spent compiling nir_opt_algebraic.c. Debug builds do not seem to be affected. I bisected this to: f097247dd831da9b6e48baebc8b91efec3afcd28 is the first bad commit commit f097247dd831da9b6e48baebc8b91efec3afcd28 Author: Samuel Iglesias Gonsálvez Date: Wed Dec 12 16:29:13 2018 +0100 nir/algebraic: disable inexact optimizations depending on float controls execution mode If FLOAT_CONTROLS_SIGNED_ZERO_INF_NAN_PRESERVE or FLOAT_CONTROLS_DENORM_FLUSH_TO_ZERO are enabled, do not apply the inexact optimizations so the VK_KHR_shader_float_controls execution mode is respected. v2: - Do not apply inexact optimizations if SHADER_DENORM_FLUSH_TO_ZERO is enabled (Andres). v3: - Updated to renamed shader info member (Andres). v4: - Directly access execution mode instead of dragging it by parameter (Caio). Signed-off-by: Samuel Iglesias Gonsálvez Signed-off-by: Andres Gomez Reviewed-by: Connor Abbott [v1] :04 04 33e076aacc5a6a4f10065cac2c8b06af0a5439a2 2b4a6e086b09648fc67a1f219777d51dc96f60f5 M src -- 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 111737] nir_opt_algebraic.c takes too long to compile
https://bugs.freedesktop.org/show_bug.cgi?id=111737 Ian Romanick changed: What|Removed |Added Keywords||bisected Assignee|mesa-dev@lists.freedesktop. |sigles...@igalia.com |org | -- 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] Switching to Gitlab Issues instead of Bugzilla?
On Thu, 2019-08-29 at 11:52 -0700, Kenneth Graunke wrote: > What do people think? If folks are in favor, Daniel can migrate > everything for us, like he did with the other projects. If not, > I'd like to hear what people's concerns are. It's been almost three weeks, and this seems to have resulted in broad consensus and very little objection, mostly around how to build searches effectively. So, let's do it. I've enabled filing issues for the remaining mesa projects that didn't have it already (vkpipeline-db, shader-db, drm, and mesa itself). I also turned merge requests on for mesa/drm (which is just libdrm, not the kernel). I'll be going through bugzilla for the Mesa and DRI products and migrating or closing bugs as appropriate. After each component is migrated it will be closed for bug entry, so there will be a small window here where bugs can be filed in two places, hopefully this shouldn't cause too much confusion. The remaining bikeshed here is the drm kernel repository, and relatedly, what to do with bugs that are kernel issues. For now I'm going to handle that by trying to avoid migrating obvious kernel issues. There's the outline of a migration plan already in: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/69 If the kernel maintainers are ready to move the canonical repo URL and issues, then let's get that moving sooner rather than later. For progress on the migration, suggestions about how and where to move issues, etc., please see: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/190 - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 18508] OpenGL texture corruption
https://bugs.freedesktop.org/show_bug.cgi?id=18508 Adam Jackson changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #7 from Adam Jackson --- Ten year old bug, closing. -- 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 32515] Wrong rendering of Vertex Buffer Object backed Vertex Array
https://bugs.freedesktop.org/show_bug.cgi?id=32515 Adam Jackson changed: What|Removed |Added Component|Drivers/X11 |Drivers/DRI/swrast -- 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 32528] X server crashes in VMware guest when KDE started with kwin "OpenGLIsUnsafe=false"
https://bugs.freedesktop.org/show_bug.cgi?id=32528 Adam Jackson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Adam Jackson --- Ancient bug, closing. -- 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 38869] Cannot create a valid pBuffer with height and/or width of zero
https://bugs.freedesktop.org/show_bug.cgi?id=38869 Adam Jackson changed: What|Removed |Added Component|Drivers/X11 |GLX -- 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 39846] can't compile mesa ‘__u64’problem.
https://bugs.freedesktop.org/show_bug.cgi?id=39846 Adam Jackson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #7 from Adam Jackson --- Ancient bug, closing. -- 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 43128] Software Rasterizer Alpha buffer transparent when window does not request an alpha buffer.
https://bugs.freedesktop.org/show_bug.cgi?id=43128 Adam Jackson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Adam Jackson --- Recent Xorgs will punish the alpha-ful visual by hiding it in a lower-priority select group, so you won't get alpha unless you ask for it. -- 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 101498] Graphical glitches when updating window content on screen
https://bugs.freedesktop.org/show_bug.cgi?id=101498 Adam Jackson changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes |org |ktop.org QA Contact|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes |org |ktop.org Component|Drivers/X11 |Drivers/DRI/i965 -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 93103] llvm symbols leak through, cause trouble with software rendering in llvm-linked software
https://bugs.freedesktop.org/show_bug.cgi?id=93103 Adam Jackson changed: What|Removed |Added Component|Drivers/X11 |Drivers/Gallium/llvmpipe -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109574] Blender 2.8
https://bugs.freedesktop.org/show_bug.cgi?id=109574 Adam Jackson changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Component|Drivers/X11 |Drivers/Gallium/r600 QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110337] Mesa 19.0.0(1) freeze system on Oland with amdgpu driver
https://bugs.freedesktop.org/show_bug.cgi?id=110337 Adam Jackson changed: What|Removed |Added Component|Drivers/X11 |Drivers/Vulkan/radeon -- 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 111430] modesetting driver causes artefacts on HD Graphics 620
https://bugs.freedesktop.org/show_bug.cgi?id=111430 Adam Jackson changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes |org |ktop.org Component|Drivers/X11 |Drivers/DRI/i965 QA Contact|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes |org |ktop.org -- 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 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Mark Janes changed: What|Removed |Added Depends on||111631 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=111631 [Bug 111631] HSW. Tropico 6 and SuperTuxKart have shadows flickering -- 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 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Bug 111444 depends on bug 110395, which changed state. Bug 110395 Summary: Gen8 and lower. Shadows are flickering in SuperTuxKart https://bugs.freedesktop.org/show_bug.cgi?id=110395 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |DUPLICATE -- 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] [ANNOUNCE] mesa 19.2.0-rc4
Hi List,
I'd like to announce the availability of mesa 19.2.0-rc4. Things are starting to
slow down, which I like to see this late in the release cycle. There are only 4
blocking bugs left on the tracker:
https://bugs.freedesktop.org/show_bug.cgi?id=111444 (plus 1 soft blocker),
and it looks like there's progress on all of them, so I'm still hopeful that
next week we'll have the final 19.2.0 release next week.
Dylan
Shortlog
Caio Marcelo de Oliveira Filho (1):
glsl/nir: Avoid overflow when setting max_uniform_location
Danylo Piliaiev (2):
nir/loop_analyze: Treat do{}while(false) loops as 0 iterations
tgsi_to_nir: Translate TGSI_INTERPOLATE_COLOR as INTERP_MODE_NONE
Dylan Baker (3):
meson: don't generate file into subdirs
add patches to be ignored
Bump version for 19.2.0-rc4
Iago Toral Quiroga (1):
v3d: make sure we have enough space in the CL for the primitive counts
packet
Jason Ekstrand (1):
intel/fs: Handle UNDEF in split_virtual_grfs
Kenneth Graunke (3):
iris: Fix constant buffer sizes for non-UBOs
gallium: Fix util_format_get_depth_only
iris: Initialize ice->state.prim_mode to an invalid value
Lionel Landwerlin (5):
radv: store engine name
driconfig: add a new engine name/version parameter
vulkan: add vk_x11_strict_image_count option
util/xmlconfig: fix regexp compile failure check
drirc: include unreal engine version 0 to 23
Marek Olšák (1):
radeonsi: add Navi12 PCI ID
Rhys Perry (1):
radv: always emit a position export in gs copy shaders
Samuel Pitoiset (1):
radv: fix allocating number of user sgprs if streamout is used
Sergii Romantsov (1):
nir/large_constants: more careful data copying
Tapani Pälli (1):
iris: close screen fd on iris_destroy_screen
git tag: mesa-19.2.0-rc4
https://mesa.freedesktop.org/archive/release/mesa/meson-dist/mesa-19.2.0-rc4.tar.xz
SHA256: 1b286be9c60bf831f024fc5de83a424ac463b77c8b568ca26657ec76307e8d10
mesa-19.2.0-rc4.tar.xz
SHA512:
a00422b4278951e4706671fe1507d5ba323a3badaceb03649dde425216fbb3cd83a21785374c75135e90fc5c6c67963f8aad0c33dac1cedaed3b69f2cd9f1c9b
mesa-19.2.0-rc4.tar.xz
PGP:
https://mesa.freedesktop.org/archive/release/mesa/meson-dist/mesa-19.2.0-rc4.tar.xz.sig
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Switching to Gitlab Issues instead of Bugzilla?
On Wed, Sep 18, 2019 at 8:45 AM Adam Jackson wrote:
>
> On Thu, 2019-08-29 at 11:52 -0700, Kenneth Graunke wrote:
>
> > What do people think? If folks are in favor, Daniel can migrate
> > everything for us, like he did with the other projects. If not,
> > I'd like to hear what people's concerns are.
>
> It's been almost three weeks, and this seems to have resulted in broad
> consensus and very little objection, mostly around how to build
> searches effectively. So, let's do it.
>
> I've enabled filing issues for the remaining mesa projects that didn't
> have it already (vkpipeline-db, shader-db, drm, and mesa itself). I
> also turned merge requests on for mesa/drm (which is just libdrm, not
> the kernel). I'll be going through bugzilla for the Mesa and DRI
> products and migrating or closing bugs as appropriate. After each
> component is migrated it will be closed for bug entry, so there will be
> a small window here where bugs can be filed in two places, hopefully
> this shouldn't cause too much confusion.
Thanks Adam! I moved the freedreno bugs from krh/mesa to mesa/mesa.
For reference, here's the commandline I pieced together from Adam's
pointers:
https://docs.gitlab.com/ee/api/issues.html#move-an-issue
and
https://gitlab.freedesktop.org/profile/personal_access_tokens
and then:
for i in {1..46}; do echo move issue $i; curl --header "PRIVATE-TOKEN:
$token" --form to_project_id=176
https://gitlab.freedesktop.org/api/v4/projects/420/issues/$i/move;
echo; done
Kristian
> The remaining bikeshed here is the drm kernel repository, and
> relatedly, what to do with bugs that are kernel issues. For now I'm
> going to handle that by trying to avoid migrating obvious kernel
> issues. There's the outline of a migration plan already in:
>
> https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/69
>
> If the kernel maintainers are ready to move the canonical repo URL and
> issues, then let's get that moving sooner rather than later.
>
> For progress on the migration, suggestions about how and where to move
> issues, etc., please see:
>
> https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/190
>
> - ajax
>
> ___
> 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 22014] Bogus GL_INVALID_OPERATION when calling glGetError inside glNewList() - glEndList() block with GL_COMPILE_AND_EXECUTE
https://bugs.freedesktop.org/show_bug.cgi?id=22014 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #2 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/43. -- 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 64335] DispatchList leaked in glxapi.c?
https://bugs.freedesktop.org/show_bug.cgi?id=64335 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #1 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/45. -- 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 64324] memory leak of visual info
https://bugs.freedesktop.org/show_bug.cgi?id=64324 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #2 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/44. -- 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 14134] Crash when context is shared among 2 processes.
https://bugs.freedesktop.org/show_bug.cgi?id=14134 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #1 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/53. -- 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 10488] assertion failure in libGL.so.1 when running wine on xvnc4 at 16bpp
https://bugs.freedesktop.org/show_bug.cgi?id=10488 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #1 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/49. -- 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 10542] Non-accelerated renderer on pipe B
https://bugs.freedesktop.org/show_bug.cgi?id=10542 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #30 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/50. -- 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 17659] driver_configs never deallocated
https://bugs.freedesktop.org/show_bug.cgi?id=17659 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #5 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/54. -- 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 13398] X crashes when logging out of second display with composite
https://bugs.freedesktop.org/show_bug.cgi?id=13398 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #5 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/52. -- 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 9272] glXDestroyContext causes fatal error when sharing display lists (dri)
https://bugs.freedesktop.org/show_bug.cgi?id=9272 GitLab Migration User changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |MOVED --- Comment #3 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/48. -- 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 11016] glGetVertexAttribivARB(0, GL_VERTEX_ATTRIB_ARRAY_ENABLED_ARB, ...) generates GL_INVALID_ENUM with indirect rendering
https://bugs.freedesktop.org/show_bug.cgi?id=11016 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #2 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/51. -- 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 23380] glxChooseVisual: visualList might have not been initialized (crash)
https://bugs.freedesktop.org/show_bug.cgi?id=23380 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #4 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/56. -- 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 4681] glDeleteTextures and glDeleteTexturesEXT erroneously share same offset
https://bugs.freedesktop.org/show_bug.cgi?id=4681 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #3 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/47. -- 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 24226] libGL tries using direct mode when it should use indirect (only tries indirect if forced)
https://bugs.freedesktop.org/show_bug.cgi?id=24226 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #20 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/57. -- 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 24342] "bad target in _mesa_select_tex_object()" when using glXBindTexImageEXT
https://bugs.freedesktop.org/show_bug.cgi?id=24342 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #1 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/58. -- 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 25778] radeon driver crashes kwin
https://bugs.freedesktop.org/show_bug.cgi?id=25778 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #7 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/59. -- 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 26487] freeglut segfault because it receives a __GLcontextModes instead of a GLXFBConfig
https://bugs.freedesktop.org/show_bug.cgi?id=26487 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|ASSIGNED|RESOLVED --- Comment #3 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/60. -- 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 29344] Long urls in chromium causes X to close when I use compositing window manager.
https://bugs.freedesktop.org/show_bug.cgi?id=29344 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #1 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/65. -- 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 29646] baddrawable when resizing a window in gnome-shell/mutter
https://bugs.freedesktop.org/show_bug.cgi?id=29646 Adam Jackson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Adam Jackson --- Ancient bug that bztogl doesn't want to import correctly for whatever reason, closing. -- 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 30102] glean depthStencil test fails BadLength with indirect non-swrast rendering
https://bugs.freedesktop.org/show_bug.cgi?id=30102 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #4 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/67. -- 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 30220] Change windowExistsErrorHandler to drawableExistsErrorHandler in glxcmds.c ?
https://bugs.freedesktop.org/show_bug.cgi?id=30220 Adam Jackson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #8 from Adam Jackson --- Closing per comment #7 -- 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 31898] Unstable menus, dropdowns, dialog boxes (turning black)
https://bugs.freedesktop.org/show_bug.cgi?id=31898 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #1 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/69. -- 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 32946] piglit glx-make-current gives X error BadMatch
https://bugs.freedesktop.org/show_bug.cgi?id=32946 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #7 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/70. -- 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 33078] Sauerbraten refuses to start
https://bugs.freedesktop.org/show_bug.cgi?id=33078 Adam Jackson changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #6 from Adam Jackson --- Migrated to https://gitlab.freedesktop.org/mesa/mesa/issues/71 -- 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 33758] CreateDRIDrawable can't fail gracefully
https://bugs.freedesktop.org/show_bug.cgi?id=33758 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #6 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/72. -- 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 38970] [bisected]piglit glx/glx-pixmap-multi failed
https://bugs.freedesktop.org/show_bug.cgi?id=38970 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #21 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/78. -- You are receiving this mail because: You are on the CC list for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38676] glproto pkg-config settings not propagated to src/glx/Makefile
https://bugs.freedesktop.org/show_bug.cgi?id=38676 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #1 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/76. -- 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 34401] glXGetScreenDriver doesn't report the same driver name as used in ~/.drirc
https://bugs.freedesktop.org/show_bug.cgi?id=34401 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #2 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/73. -- 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 38869] Cannot create a valid pBuffer with height and/or width of zero
https://bugs.freedesktop.org/show_bug.cgi?id=38869 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #6 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/77. -- 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 39570] glx-multithread lock during piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=39570 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #1 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/80. -- 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 35607] glXWaitVideoSyncSGI() function freezes at resolution change
https://bugs.freedesktop.org/show_bug.cgi?id=35607 GitLab Migration User changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |MOVED --- Comment #2 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/75. -- 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 46502] Wine crashes with idnirect rendering
https://bugs.freedesktop.org/show_bug.cgi?id=46502 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #5 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/83. -- 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 47066] glxinfo says "nouveau" on dual seat when on a monitor drived by a radeon card
https://bugs.freedesktop.org/show_bug.cgi?id=47066 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #14 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/84. -- 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 54971] __glXInitialize can initialize same display multiple times
https://bugs.freedesktop.org/show_bug.cgi?id=54971 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #4 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/87. -- 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 45352] SIGSEGV drisw_glx.c:95
https://bugs.freedesktop.org/show_bug.cgi?id=45352 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #1 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/82. -- 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 52930] glXWaitX is often ineffective
https://bugs.freedesktop.org/show_bug.cgi?id=52930 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #1 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/85. -- 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 54736] Creating a Pbuffer requires a pixmap of same depth.
https://bugs.freedesktop.org/show_bug.cgi?id=54736 GitLab Migration User changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #1 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/86. -- 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 39219] libgl conflict with xbmc causes lock up on xbmc exit
https://bugs.freedesktop.org/show_bug.cgi?id=39219 GitLab Migration User changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |MOVED --- Comment #13 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/79. -- 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 55552] Compile errors with --enable-mangling
https://bugs.freedesktop.org/show_bug.cgi?id=2 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #1 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/88. -- 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 79629] [Dri3 bisected] piglit glx_GLX_ARB_create_context_current_with_no_framebuffer fail
https://bugs.freedesktop.org/show_bug.cgi?id=79629 GitLab Migration User changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |MOVED --- Comment #22 from GitLab Migration User --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/95. -- 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
