[Mesa-dev] [PATCH] util/anon_file: Fix build errors due to missing includes
Including stdlib.h and stdio.h is required in some configurations:
../src/util/anon_file.c: In function ‘create_tmpfile_cloexec’:
../src/util/anon_file.c:75:9: error: implicit declaration of function
‘mkostemp’ [-Werror=implicit-function-declaration]
fd = mkostemp(tmpname, O_CLOEXEC);
^~~~
../src/util/anon_file.c: In function ‘os_create_anonymous_file’:
../src/util/anon_file.c:126:11: error: implicit declaration of function
‘getenv’ [-Werror=implicit-function-declaration]
path = getenv("XDG_RUNTIME_DIR");
^~
../src/util/anon_file.c:126:9: warning: assignment makes pointer from integer
without a cast [-Wint-conversion]
path = getenv("XDG_RUNTIME_DIR");
^
../src/util/anon_file.c:133:7: error: implicit declaration of function
‘asprintf’ [-Werror=implicit-function-declaration]
asprintf(&name, "%s/mesa-shared-%s-XX", path, debug_name);
^~~~
../src/util/anon_file.c:141:4: error: implicit declaration of function ‘free’
[-Werror=implicit-function-declaration]
free(name);
^~~~
../src/util/anon_file.c:141:4: warning: incompatible implicit declaration of
built-in function ‘free’
../src/util/anon_file.c:141:4: note: include ‘’ or provide a
declaration of ‘free’
cc1: some warnings being treated as errors
---
src/util/anon_file.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/util/anon_file.c b/src/util/anon_file.c
index 184b8445bad..3334e793f5c 100644
--- a/src/util/anon_file.c
+++ b/src/util/anon_file.c
@@ -33,6 +33,8 @@
#include
#include
#include
+#include
+#include
#ifdef __FreeBSD__
#include
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111288] Memory leak in minecraft (supposedly related to rendering)
https://bugs.freedesktop.org/show_bug.cgi?id=111288 --- Comment #9 from Denis --- >and absurdly high amount of these records in process memory map seemed to be >quite rational explanation of where that memory leak is. Got you, thanks. >so amount of these can easily grow until there's no memory left ok, I see your point. I ran the game for a all night, and in the morning observed memory usage - and it still used 2.3 GB of RAM memory (it is for about 20 hours in pause) According to '/dev/dri/renderD128' records - they were increased up to 90. About memory allocated for them - most of them used 4-16 kb, not 1 MB. Only few of them used 400 Kb (1 or 2 records). And the last thing - I tried to run java process using valgrind, it created some logs (useless as they don't have information about possible leaks now) but game still didn't start :( Possibly it should take more time... (it used 1.2 GB of RAM memory now, as the original game uses 2.3 GB) -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util/slab: add slab_free_fast()
Yes, although not in front of me.. overall for gl_driver2 it was
something along the lines of 2-3%. Looking at perf-report, slab_free
(+ slab_free_fast) went from ~20% to nearly nothing(ish) iirc..
BR,
-R
On Wed, Aug 7, 2019 at 4:58 PM Jason Ekstrand wrote:
>
> Do you have any actual numbers for this?
>
> On August 7, 2019 17:02:22 Rob Clark wrote:
>
> > From: Rob Clark
> >
> > I noticed slab_free() showing up at the top of perf results in
> > gl_driver2, due to "streaming" GPU state objects, which are allocated
> > and destroyed within a single draw call.
> >
> > In this case, it is guaranteed that we free on the same child pool,
> > from the same (only) thread accessing the child pool. So add a faster,
> > but more restricted version of slab_free() to cut the overhead.
> >
> > Signed-off-by: Rob Clark
> > ---
> > src/util/slab.c | 20
> > src/util/slab.h | 1 +
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/src/util/slab.c b/src/util/slab.c
> > index 62634034fdc..21076a80238 100644
> > --- a/src/util/slab.c
> > +++ b/src/util/slab.c
> > @@ -276,6 +276,26 @@ void slab_free(struct slab_child_pool *pool, void *ptr)
> >}
> > }
> >
> > +/**
> > + * Similar to slab_free(), except that freeing an object in a different
> > pool
> > + * from the one it was allocated from is *not* allowed.
> > + */
> > +void slab_free_fast(struct slab_child_pool *pool, void *ptr)
> > +{
> > + struct slab_element_header *elt = ((struct slab_element_header*)ptr -
> > 1);
> > +
> > + CHECK_MAGIC(elt, SLAB_MAGIC_ALLOCATED);
> > + SET_MAGIC(elt, SLAB_MAGIC_FREE);
> > +
> > + assert(p_atomic_read(&elt->owner) == (intptr_t)pool);
> > +
> > + /* This is the simple case: The caller guarantees that we can safely
> > +* access the free list.
> > +*/
> > + elt->next = pool->free;
> > + pool->free = elt;
> > +}
> > +
> > /**
> > * Allocate an object from the slab. Single-threaded (no mutex).
> > */
> > diff --git a/src/util/slab.h b/src/util/slab.h
> > index 5a25adaf7f4..9748cd95858 100644
> > --- a/src/util/slab.h
> > +++ b/src/util/slab.h
> > @@ -78,6 +78,7 @@ void slab_create_child(struct slab_child_pool *pool,
> > void slab_destroy_child(struct slab_child_pool *pool);
> > void *slab_alloc(struct slab_child_pool *pool);
> > void slab_free(struct slab_child_pool *pool, void *ptr);
> > +void slab_free_fast(struct slab_child_pool *pool, void *ptr);
> >
> > struct slab_mempool {
> >struct slab_parent_pool parent;
> > --
> > 2.21.0
> >
> > ___
> > 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 111308] [Regression, NIR, bisected] Black squares in Unigine Heaven via DXVK
https://bugs.freedesktop.org/show_bug.cgi?id=111308 --- Comment #6 from Danylo --- Yes, changing fexp2 be >= 0 instead of > 0 solves the issue. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111288] Memory leak in minecraft (supposedly related to rendering)
https://bugs.freedesktop.org/show_bug.cgi?id=111288 --- Comment #10 from Greg --- >it is for about 20 hours in pause As I said, it pauses leaking when you stay still; it only seems to leak when you move (supposedly when new chunks (map is split into 16x16x256 (256 in vertical dimension) areas (chunks), only those near the player are loaded (are rendered and processed). When player moves, some chunks get loaded and some get unloaded to keep only area close to player loaded) are loaded). Reliable way to trigger leak is moving in one direction for some time. Can you please check trace I provided (replay it and monitor amount of `renderD128` records) (if leaks are 'replayed', then the problem is somewhere in jvm (i've noticed appearance of sigsegv signals that don't terminate program when I traced with ltrace), if not, then probably it's driver issue or something, and at least it'll be easier (than delving in decompiled minecraft) to locate troublesome chunk) -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/9] panfrost: Make ctx->job useful
On Fri, 2019-08-02 at 19:18 +0200, Boris Brezillon wrote:
> ctx->job is supposed to serve as a cache to avoid an hash table lookup
> everytime we access the job attached to the currently bound FB, except
> it was never assigned to anything but NULL.
>
> Fix that by adding the missing assignment in panfrost_get_job_for_fbo().
> Also add a missing NULL assignment in the ->set_framebuffer_state()
> path.
>
> While at it, add extra assert()s to make sure ctx->job is consistent.
>
> Fixes: 59c9623d0a75 ("panfrost: Import job data structures from v3d")
> Signed-off-by: Boris Brezillon
> Changes in v2:
> * New patch (suggested by Alyssa)
This patch is a candidate for 19.1, but unfortunately it does not apply cleanly.
It seems it depends on a bunch of other commits not in 19.1
At this point, I will ignore/reject this patch for 19.1, unless you can provide
me a specific version for 19.1 branch (use staging/19.1 as reference).
Thanks.
J.A.
> ---
> src/gallium/drivers/panfrost/pan_context.c | 5 +
> src/gallium/drivers/panfrost/pan_job.c | 19 ++-
> 2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_context.c
> b/src/gallium/drivers/panfrost/pan_context.c
> index 014f8f6a9d07..ba2df2ce66ae 100644
> --- a/src/gallium/drivers/panfrost/pan_context.c
> +++ b/src/gallium/drivers/panfrost/pan_context.c
> @@ -2372,6 +2372,11 @@ panfrost_set_framebuffer_state(struct pipe_context
> *pctx,
> panfrost_flush(pctx, NULL, PIPE_FLUSH_END_OF_FRAME);
> }
>
> +/* Invalidate the FBO job cache since we've just been assigned a new
> + * FB state.
> + */
> +ctx->job = NULL;
> +
> util_copy_framebuffer_state(&ctx->pipe_framebuffer, fb);
>
> /* Given that we're rendering, we'd love to have compression */
> diff --git a/src/gallium/drivers/panfrost/pan_job.c
> b/src/gallium/drivers/panfrost/pan_job.c
> index 6339b39d29a0..cc81d475165e 100644
> --- a/src/gallium/drivers/panfrost/pan_job.c
> +++ b/src/gallium/drivers/panfrost/pan_job.c
> @@ -23,6 +23,8 @@
> *
> */
>
> +#include
> +
> #include "pan_context.h"
> #include "util/hash_table.h"
> #include "util/ralloc.h"
> @@ -124,8 +126,13 @@ panfrost_get_job_for_fbo(struct panfrost_context *ctx)
>
> /* If we already began rendering, use that */
>
> -if (ctx->job)
> +if (ctx->job) {
> +assert(ctx->job->key.zsbuf == ctx->pipe_framebuffer.zsbuf &&
> + !memcmp(ctx->job->key.cbufs,
> + ctx->pipe_framebuffer.cbufs,
> + sizeof(ctx->job->key.cbufs)));
> return ctx->job;
> +}
>
> /* If not, look up the job */
>
> @@ -133,6 +140,10 @@ panfrost_get_job_for_fbo(struct panfrost_context *ctx)
> struct pipe_surface *zsbuf = ctx->pipe_framebuffer.zsbuf;
> struct panfrost_job *job = panfrost_get_job(ctx, cbufs, zsbuf);
>
> +/* Set this job as the current FBO job. Will be reset when updating
> the
> + * FB state and when submitting or releasing a job.
> + */
> +ctx->job = job;
> return job;
> }
>
> @@ -181,6 +192,12 @@ panfrost_job_submit(struct panfrost_context *ctx, struct
> panfrost_job *job)
>
> if (ret)
> fprintf(stderr, "panfrost_job_submit failed: %d\n", ret);
> +
> +/* The job has been submitted, let's invalidate the current FBO job
> + * cache.
> + */
> +assert(!ctx->job || job == ctx->job);
> +ctx->job = NULL;
> }
>
> void
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111288] Memory leak in minecraft (supposedly related to rendering)
https://bugs.freedesktop.org/show_bug.cgi?id=111288 --- Comment #11 from Michel Dänzer --- If you replace the trace with "valgrind --leak-check=full", valgrind's output should contain information about where how much memory is (possibly) leaked. P.S. If the trace was compressed with e.g. xz, it might be small enough to be attached here. -- 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] Mesa 19.2.0 release plan
On Wed, 7 Aug 2019 at 21:43, Mark Janes wrote: > > Eric Engestrom writes: > > > On 2019-07-31 at 09:38, Emil Velikov wrote: > >> Hi all, > >> > >> Here is the tentative release plan for 19.2.0. > >> > >> As many of you are well aware, it's time to the next branch point. > >> The calendar is already updated, so these are the tentative dates: > >> > >> Aug 06 2019 - Feature freeze/Release candidate 1 > >> Aug 13 2019 - Release candidate 2 > >> Aug 20 2019 - Release candidate 3 > >> Aug 27 2019 - Release candidate 4/final release > >> > >> This gives us around 1 week until the branch point. > >> > >> Note: In the spirit of keeping things clearer and more transparent, we > >> will be keeping track of any features planned for the release in > >> Bugzilla [1]. > >> > >> Do add a separate "Depends on" for each work you have planned. > >> Alternatively you can reply to this email and I'll add them for you. > >> > >> [1] https://bugs.freedesktop.org/show_bug.cgi?id=111265 > > > > Thanks! > > > > As per previous discussions (I don't remember where, sorry) as well as > > internal discussions, I think we should add all currently open > > regressions since 19.1 as blockers for this release. > > My understanding is that the "feature tracker" blocks the creation of > the release branchpoint. A separate "release tracker" blocks the > release of 19.2.0. Unfixed regressions go on the "release tracker", not > the "feature tracker". We backport bug fixes to release branches, but > we don't backport features. > Yes that is correct. We are interested in features for the next few days. Afterwords we'll focus on bugfixes. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111288] Memory leak in minecraft (supposedly related to rendering)
https://bugs.freedesktop.org/show_bug.cgi?id=111288 --- Comment #12 from Greg --- >"valgrind --leak-check=full" Valgrind doesn't do well with java. It detects over 1194 errors in jvm *before minecraft even starts*, and makes it very slow, as Denis mentioned. -- 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 111288] Memory leak in minecraft (supposedly related to rendering)
https://bugs.freedesktop.org/show_bug.cgi?id=111288 --- Comment #13 from Michel Dänzer --- Replaying the trace doesn't involve Java. -- 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 111288] Memory leak in minecraft (supposedly related to rendering)
https://bugs.freedesktop.org/show_bug.cgi?id=111288 --- Comment #14 from Tapani Pälli --- (In reply to Michel Dänzer from comment #13) > Replaying the trace doesn't involve Java. There seems no leaks on program exit when replaying the trace. Maybe the issue here is that for some reason memory usage keeps increasing all the time, even though finally it all gets released (?) --- 8< --- Rendered 896 frames in 15.3518 secs, average of 58.3646 fps ==19330== ==19330== HEAP SUMMARY: ==19330== in use at exit: 0 bytes in 0 blocks ==19330== total heap usage: 5,065 allocs, 5,065 frees, 2,423,144 bytes allocated ==19330== ==19330== All heap blocks were freed -- no leaks are possible -- 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 1/9] panfrost: Make ctx->job useful
@Boris I don't see why this patch particularly needs to be backported to
19.1?
On Thu, Aug 08, 2019 at 11:46:43AM +0200, Juan A. Suarez Romero wrote:
> On Fri, 2019-08-02 at 19:18 +0200, Boris Brezillon wrote:
> > ctx->job is supposed to serve as a cache to avoid an hash table lookup
> > everytime we access the job attached to the currently bound FB, except
> > it was never assigned to anything but NULL.
> >
> > Fix that by adding the missing assignment in panfrost_get_job_for_fbo().
> > Also add a missing NULL assignment in the ->set_framebuffer_state()
> > path.
> >
> > While at it, add extra assert()s to make sure ctx->job is consistent.
> >
> > Fixes: 59c9623d0a75 ("panfrost: Import job data structures from v3d")
> > Signed-off-by: Boris Brezillon
> > Changes in v2:
> > * New patch (suggested by Alyssa)
>
>
> This patch is a candidate for 19.1, but unfortunately it does not apply
> cleanly.
> It seems it depends on a bunch of other commits not in 19.1
>
> At this point, I will ignore/reject this patch for 19.1, unless you can
> provide
> me a specific version for 19.1 branch (use staging/19.1 as reference).
>
> Thanks.
>
> J.A.
>
> > ---
> > src/gallium/drivers/panfrost/pan_context.c | 5 +
> > src/gallium/drivers/panfrost/pan_job.c | 19 ++-
> > 2 files changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/panfrost/pan_context.c
> > b/src/gallium/drivers/panfrost/pan_context.c
> > index 014f8f6a9d07..ba2df2ce66ae 100644
> > --- a/src/gallium/drivers/panfrost/pan_context.c
> > +++ b/src/gallium/drivers/panfrost/pan_context.c
> > @@ -2372,6 +2372,11 @@ panfrost_set_framebuffer_state(struct pipe_context
> > *pctx,
> > panfrost_flush(pctx, NULL, PIPE_FLUSH_END_OF_FRAME);
> > }
> >
> > +/* Invalidate the FBO job cache since we've just been assigned a
> > new
> > + * FB state.
> > + */
> > +ctx->job = NULL;
> > +
> > util_copy_framebuffer_state(&ctx->pipe_framebuffer, fb);
> >
> > /* Given that we're rendering, we'd love to have compression */
> > diff --git a/src/gallium/drivers/panfrost/pan_job.c
> > b/src/gallium/drivers/panfrost/pan_job.c
> > index 6339b39d29a0..cc81d475165e 100644
> > --- a/src/gallium/drivers/panfrost/pan_job.c
> > +++ b/src/gallium/drivers/panfrost/pan_job.c
> > @@ -23,6 +23,8 @@
> > *
> > */
> >
> > +#include
> > +
> > #include "pan_context.h"
> > #include "util/hash_table.h"
> > #include "util/ralloc.h"
> > @@ -124,8 +126,13 @@ panfrost_get_job_for_fbo(struct panfrost_context *ctx)
> >
> > /* If we already began rendering, use that */
> >
> > -if (ctx->job)
> > +if (ctx->job) {
> > +assert(ctx->job->key.zsbuf == ctx->pipe_framebuffer.zsbuf
> > &&
> > + !memcmp(ctx->job->key.cbufs,
> > + ctx->pipe_framebuffer.cbufs,
> > + sizeof(ctx->job->key.cbufs)));
> > return ctx->job;
> > +}
> >
> > /* If not, look up the job */
> >
> > @@ -133,6 +140,10 @@ panfrost_get_job_for_fbo(struct panfrost_context *ctx)
> > struct pipe_surface *zsbuf = ctx->pipe_framebuffer.zsbuf;
> > struct panfrost_job *job = panfrost_get_job(ctx, cbufs, zsbuf);
> >
> > +/* Set this job as the current FBO job. Will be reset when
> > updating the
> > + * FB state and when submitting or releasing a job.
> > + */
> > +ctx->job = job;
> > return job;
> > }
> >
> > @@ -181,6 +192,12 @@ panfrost_job_submit(struct panfrost_context *ctx,
> > struct panfrost_job *job)
> >
> > if (ret)
> > fprintf(stderr, "panfrost_job_submit failed: %d\n", ret);
> > +
> > +/* The job has been submitted, let's invalidate the current FBO job
> > + * cache.
> > +*/
> > +assert(!ctx->job || job == ctx->job);
> > +ctx->job = NULL;
> > }
> >
> > void
>
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111302] radv assertion failed on SI cards `reg >= SI_CONTEXT_REG_OFFSET && reg < SI_CONFIG_REG_END'
https://bugs.freedesktop.org/show_bug.cgi?id=111302 Turo Lamminen changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Turo Lamminen --- Patch has landed, closing. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/9] panfrost: Make ctx->job useful
On Thu, 8 Aug 2019 06:08:05 -0700
Alyssa Rosenzweig wrote:
> @Boris I don't see why this patch particularly needs to be backported to
> 19.1?
Nope, no reason to backport it to 19.1. It's just a (bad?) kernel dev
habit to put "Fixes:" tag the patch fixes a problem introduced by a
previous commit. But it does not necessarily means "backport to stable"
in mind.
>
> On Thu, Aug 08, 2019 at 11:46:43AM +0200, Juan A. Suarez Romero wrote:
> > On Fri, 2019-08-02 at 19:18 +0200, Boris Brezillon wrote:
> > > ctx->job is supposed to serve as a cache to avoid an hash table lookup
> > > everytime we access the job attached to the currently bound FB, except
> > > it was never assigned to anything but NULL.
> > >
> > > Fix that by adding the missing assignment in panfrost_get_job_for_fbo().
> > > Also add a missing NULL assignment in the ->set_framebuffer_state()
> > > path.
> > >
> > > While at it, add extra assert()s to make sure ctx->job is consistent.
> > >
> > > Fixes: 59c9623d0a75 ("panfrost: Import job data structures from v3d")
> > > Signed-off-by: Boris Brezillon
> > > Changes in v2:
> > > * New patch (suggested by Alyssa)
> >
> >
> > This patch is a candidate for 19.1, but unfortunately it does not apply
> > cleanly.
> > It seems it depends on a bunch of other commits not in 19.1
> >
> > At this point, I will ignore/reject this patch for 19.1, unless you can
> > provide
> > me a specific version for 19.1 branch (use staging/19.1 as reference).
> >
> > Thanks.
> >
> > J.A.
> >
> > > ---
> > > src/gallium/drivers/panfrost/pan_context.c | 5 +
> > > src/gallium/drivers/panfrost/pan_job.c | 19 ++-
> > > 2 files changed, 23 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/gallium/drivers/panfrost/pan_context.c
> > > b/src/gallium/drivers/panfrost/pan_context.c
> > > index 014f8f6a9d07..ba2df2ce66ae 100644
> > > --- a/src/gallium/drivers/panfrost/pan_context.c
> > > +++ b/src/gallium/drivers/panfrost/pan_context.c
> > > @@ -2372,6 +2372,11 @@ panfrost_set_framebuffer_state(struct pipe_context
> > > *pctx,
> > > panfrost_flush(pctx, NULL, PIPE_FLUSH_END_OF_FRAME);
> > > }
> > >
> > > +/* Invalidate the FBO job cache since we've just been assigned a
> > > new
> > > + * FB state.
> > > + */
> > > +ctx->job = NULL;
> > > +
> > > util_copy_framebuffer_state(&ctx->pipe_framebuffer, fb);
> > >
> > > /* Given that we're rendering, we'd love to have compression */
> > > diff --git a/src/gallium/drivers/panfrost/pan_job.c
> > > b/src/gallium/drivers/panfrost/pan_job.c
> > > index 6339b39d29a0..cc81d475165e 100644
> > > --- a/src/gallium/drivers/panfrost/pan_job.c
> > > +++ b/src/gallium/drivers/panfrost/pan_job.c
> > > @@ -23,6 +23,8 @@
> > > *
> > > */
> > >
> > > +#include
> > > +
> > > #include "pan_context.h"
> > > #include "util/hash_table.h"
> > > #include "util/ralloc.h"
> > > @@ -124,8 +126,13 @@ panfrost_get_job_for_fbo(struct panfrost_context
> > > *ctx)
> > >
> > > /* If we already began rendering, use that */
> > >
> > > -if (ctx->job)
> > > +if (ctx->job) {
> > > +assert(ctx->job->key.zsbuf ==
> > > ctx->pipe_framebuffer.zsbuf &&
> > > + !memcmp(ctx->job->key.cbufs,
> > > + ctx->pipe_framebuffer.cbufs,
> > > + sizeof(ctx->job->key.cbufs)));
> > > return ctx->job;
> > > +}
> > >
> > > /* If not, look up the job */
> > >
> > > @@ -133,6 +140,10 @@ panfrost_get_job_for_fbo(struct panfrost_context
> > > *ctx)
> > > struct pipe_surface *zsbuf = ctx->pipe_framebuffer.zsbuf;
> > > struct panfrost_job *job = panfrost_get_job(ctx, cbufs, zsbuf);
> > >
> > > +/* Set this job as the current FBO job. Will be reset when
> > > updating the
> > > + * FB state and when submitting or releasing a job.
> > > + */
> > > +ctx->job = job;
> > > return job;
> > > }
> > >
> > > @@ -181,6 +192,12 @@ panfrost_job_submit(struct panfrost_context *ctx,
> > > struct panfrost_job *job)
> > >
> > > if (ret)
> > > fprintf(stderr, "panfrost_job_submit failed: %d\n", ret);
> > > +
> > > +/* The job has been submitted, let's invalidate the current FBO
> > > job
> > > + * cache.
> > > + */
> > > +assert(!ctx->job || job == ctx->job);
> > > +ctx->job = NULL;
> > > }
> > >
> > > void
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111288] Memory leak in minecraft (supposedly related to rendering)
https://bugs.freedesktop.org/show_bug.cgi?id=111288 --- Comment #15 from Denis --- >If you replace the trace with "valgrind --leak-check=full", valgrind's output >should contain information about where how much memory is (possibly) leaked. That's how I launched minecraft for tracing (it is HUGE command, I took it from the "real" process launched. Without valgrind it launches second instance with a game, without launching "minecraft launcher"). As I wrote, waited 20 hours without result. valgrind --leak-check=full \ --show-leak-kinds=all \ --track-origins=yes \ --verbose \ --log-file=valgrind-out.txt \ --suppressions=/home/den/Downloads/invalid_access.supp \ /usr/lib/jvm/java-8-openjdk/jre/bin/java -Xss1M -Djava.library.path=/tmp/3024-a622-fa75-1bb1 -Dminecraft.launcher.brand=minecraft-launcher -Dminecraft.launcher.version=2.1.5965 -cp /home/den/.minecraft/libraries/com/mojang/patchy/1.1/patchy-1.1.jar:/home/den/.minecraft/libraries/oshi-project/oshi-core/1.1/oshi-core-1.1.jar:/home/den/.minecraft/libraries/net/java/dev/jna/jna/4.4.0/jna-4.4.0.jar:/home/den/.minecraft/libraries/net/java/dev/jna/platform/3.4.0/platform-3.4.0.jar:/home/den/.minecraft/libraries/com/ibm/icu/icu4j-core-mojang/51.2/icu4j-core-mojang-51.2.jar:/home/den/.minecraft/libraries/com/mojang/javabridge/1.0.22/javabridge-1.0.22.jar:/home/den/.minecraft/libraries/net/sf/jopt-simple/jopt-simple/5.0.3/jopt-simple-5.0.3.jar:/home/den/.minecraft/libraries/io/netty/netty-all/4.1.25.Final/netty-all-4.1.25.Final.jar:/home/den/.minecraft/libraries/com/google/guava/guava/21.0/guava-21.0.jar:/home/den/.minecraft/libraries/org/apache/commons/commons-lang3/3.5/commons-lang3-3.5.jar:/home/den/.minecraft/libraries/commons-io/commons-io/2.5/commons-io-2.5.jar:/home/den/.minecraft/libraries/commons-codec/commons-codec/1.10/commons-codec-1.10.jar:/home/den/.minecraft/libraries/net/java/jinput/jinput/2.0.5/jinput-2.0.5.jar:/home/den/.minecraft/libraries/net/java/jutils/jutils/1.0.0/jutils-1.0.0.jar:/home/den/.minecraft/libraries/com/mojang/brigadier/1.0.17/brigadier-1.0.17.jar:/home/den/.minecraft/libraries/com/mojang/datafixerupper/2.0.24/datafixerupper-2.0.24.jar:/home/den/.minecraft/libraries/com/google/code/gson/gson/2.8.0/gson-2.8.0.jar:/home/den/.minecraft/libraries/com/mojang/authlib/1.5.25/authlib-1.5.25.jar:/home/den/.minecraft/libraries/org/apache/commons/commons-compress/1.8.1/commons-compress-1.8.1.jar:/home/den/.minecraft/libraries/org/apache/httpcomponents/httpclient/4.3.3/httpclient-4.3.3.jar:/home/den/.minecraft/libraries/commons-logging/commons-logging/1.1.3/commons-logging-1.1.3.jar:/home/den/.minecraft/libraries/org/apache/httpcomponents/httpcore/4.3.2/httpcore-4.3.2.jar:/home/den/.minecraft/libraries/it/unimi/dsi/fastutil/8.2.1/fastutil-8.2.1.jar:/home/den/.minecraft/libraries/org/apache/logging/log4j/log4j-api/2.8.1/log4j-api-2.8.1.jar:/home/den/.minecraft/libraries/org/apache/logging/log4j/log4j-core/2.8.1/log4j-core-2.8.1.jar:/home/den/.minecraft/libraries/org/lwjgl/lwjgl/3.2.2/lwjgl-3.2.2.jar:/home/den/.minecraft/libraries/org/lwjgl/lwjgl-jemalloc/3.2.2/lwjgl-jemalloc-3.2.2.jar:/home/den/.minecraft/libraries/org/lwjgl/lwjgl-openal/3.2.2/lwjgl-openal-3.2.2.jar:/home/den/.minecraft/libraries/org/lwjgl/lwjgl-opengl/3.2.2/lwjgl-opengl-3.2.2.jar:/home/den/.minecraft/libraries/org/lwjgl/lwjgl-glfw/3.2.2/lwjgl-glfw-3.2.2.jar:/home/den/.minecraft/libraries/org/lwjgl/lwjgl-stb/3.2.2/lwjgl-stb-3.2.2.jar:/home/den/.minecraft/libraries/com/mojang/text2speech/1.11.3/text2speech-1.11.3.jar:/home/den/.minecraft/versions/1.14.4/1.14.4.jar -Xmx2G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M -Dlog4j.configurationFile=/home/den/.minecraft/assets/log_configs/client-1.12.xml net.minecraft.client.main.Main --username Player --version 1.14.4 --gameDir /home/den/.minecraft --assetsDir /home/den/.minecraft/assets --assetIndex 1.14 --uuid 265e330a88c60b9ad41d57788ec45778 --accessToken fbaaa18c2da14c20b1211a28e69137c3 --userType legacy --versionType release --demo >Valgrind doesn't do well with java. It detects over 1194 errors in jvm >*before minecraft even starts*, and makes it very slow, as Denis mentioned. Confirming, I used to suppress some errors, because without this step it simply said "valgrind stopped. Fix your buggy program" :) >Can you please check trace I provided (replay it and monitor amount of >`renderD128` records) (if leaks are 'replayed', then the problem is somewhere >in jvm (i've noticed appearance of sigsegv signals that don't terminate >program when I traced with ltrace), if not, then probably it's driver issue or >something, and at least it'll be easier (than delving in decompiled minecraft) >to locate troublesome chunk) Interesting. Yesterday, when I replayed trace, I saw about 15 records for '/dev/dri/renderD128' at .../maps Today - no any records related to this de
[Mesa-dev] [Bug 110357] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" configuration
https://bugs.freedesktop.org/show_bug.cgi?id=110357 Andrés Gómez García changed: What|Removed |Added CC||agoldmi...@igalia.com, ||gpoo+b...@igalia.com -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/5] panfrost: Allocate shaders in their own BOs
On Wed, Aug 7, 2019 at 11:23 PM Tomeu Vizoso wrote:
>
> On Thu, 8 Aug 2019 at 00:47, Rob Herring wrote:
> >
> > On Wed, Aug 7, 2019 at 2:37 AM Tomeu Vizoso
> > wrote:
> > >
> > > Instead of all shaders being stored in a single BO, have each shader in
> > > its own.
> > >
> > > This removes the need for a 16MB allocation per context, and allows us
> > > to place transient blend shaders in BOs marked as executable (before
> > > they were allocated in the transient pool, which shouldn't be
> > > executable).
> > >
> > > v2: - Store compiled blend shaders in a malloc'ed buffer, to avoid
> > > reading from GPU-accessible memory when patching (Alyssa).
> > > - Free struct panfrost_blend_shader (Alyssa).
> > > - Give the job a reference to regular shaders when emitting
> > > (Alyssa).
> > >
> > > Signed-off-by: Tomeu Vizoso
> >
> >
> > > diff --git a/src/gallium/drivers/panfrost/pan_bo_cache.c
> > > b/src/gallium/drivers/panfrost/pan_bo_cache.c
> > > index fba495c1dd69..7378d0a8abea 100644
> > > --- a/src/gallium/drivers/panfrost/pan_bo_cache.c
> > > +++ b/src/gallium/drivers/panfrost/pan_bo_cache.c
> > > @@ -84,11 +84,10 @@ panfrost_bo_cache_fetch(
> > > {
> > > struct list_head *bucket = pan_bucket(screen, size);
> > >
> > > -/* TODO: Honour flags? */
> > > -
> > > /* Iterate the bucket looking for something suitable */
> > > list_for_each_entry_safe(struct panfrost_bo, entry, bucket,
> > > link) {
> > > -if (entry->size >= size) {
> > > +if (entry->size >= size &&
> > > +entry->flags == flags) {
> >
> > This change probably warrants its own patch IMO.
>
> Agreed.
>
> > This is using the
> > untranslated flags, but I think it should be the 'translated_flags' as
> > those are the ones changing the allocation. For example, I don't think
> > there's any reason for DELAYED_MMAP to be used as a match criteria
> > (BTW, I'm also not sure if we can reclaim BOs if they remain mmap'ed).
> >
> > Another problem I see, if we have a 100MB buffer in the cache, would
> > we really want to hit on a 4KB allocation? Perhaps a 'entry->size * 2
> > < size' check.
>
> Yeah, as mentioned in the v1 discussion, we have plenty of room for
> improvements here, but the goal now is just to stop doing memory
> allocation so greedily that we reach OOM after launching a few GL
> clients.
Sure. IMO, committing the BO cache without madvise was a mistake.
Without madvise, 2 instances of glmark will OOM. I should be able to
send out the patch for it today. I think it's going to need to disable
caching when madvise is not supported.
Rob
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/5] panfrost: Allocate shaders in their own BOs
On Wed, Aug 7, 2019 at 5:47 PM Alyssa Rosenzweig wrote: > > > This is using the > > untranslated flags, but I think it should be the 'translated_flags' as > > those are the ones changing the allocation. > > It's a little more complex than that. There some hypothetical > untranslated flags that I would want to match on. For instance, future > CPU read-only/write-only modifiers -- those affect the mmap (and need to > be accounted for in the BO cache) but aren't specified as > translated_flags to the kernel. I'll still argue that we shouldn't leave cached BOs mmap'ed so that example would be mute. The more bits we have to match on, the less effective the BO cache will be. Either we should use translated_flags or we should filter the untranslated flags to the ones we care about. The latter would be more flexible I guess. Rob ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: Bump number of allowed global buffers to 48 (again, for clover Blender assertion)
On Tue, 2019-08-06 at 23:20 -0400, Marek Olšák wrote: > Do you know why global buffers are in the compute state and not in the > context? Not really. I mostly follow the existing design when it comes to mesa. I'd assume it's a leftover from r600 which has limited number of cbufs (and uses shared pool to accommodate global buffers). cl global buffers are created in cl context so I think there shouldn't be too much trouble moving it to the driver equivalent of that. Jan > > Marek > > On Tue, Aug 6, 2019 at 10:50 PM Dieter Nützel wrote: > > > Am 20.06.2019 20:44, schrieb Jan Vesely: > > > On Sat, 2019-06-15 at 07:38 +0200, Dieter Nützel wrote: > > > > Am 14.06.2019 08:13, schrieb Jan Vesely: > > > > > On Thu, 2019-06-13 at 21:20 +0200, Dieter Nützel wrote: > > > > > > Blender crash as expected ;-) > > > > > > > > > > > > /home/dieter> trying to save userpref at > > > > > > /home/dieter/.config/blender/2.79/config/userpref.blend ok > > > > > > Read blend: /data/Blender/barbershop_interior_gpu.blend > > > > > > scripts disabled for "/data/Blender/barbershop_interior_gpu.blend", > > > > > > skipping 'generate_customprops.py' > > > > > > skipping driver 'var', automatic scripts are disabled > > > > > > skipping driver 'var', automatic scripts are disabled > > > > > > skipping driver 'var', automatic scripts are disabled > > > > > > skipping driver 'var', automatic scripts are disabled > > > > > > skipping driver 'var', automatic scripts are disabled > > > > > > skipping driver 'var', automatic scripts are disabled > > > > > > skipping driver 'var', automatic scripts are disabled > > > > > > skipping driver 'var', automatic scripts are disabled > > > > > > skipping driver 'var', automatic scripts are disabled > > > > > > Device init success > > > > > > Compiling OpenCL program split > > > > > > Kernel compilation of split finished in 8.41s. > > > > > > > > > > > > Compiling OpenCL program base > > > > > > Kernel compilation of base finished in 4.55s. > > > > > > > > > > > > Compiling OpenCL program denoising > > > > > > Kernel compilation of denoising finished in 2.08s. > > > > > > > > > > > > blender: ../src/gallium/drivers/radeonsi/si_compute.c:319: > > > > > > si_set_global_binding: Assertion `first + n <= MAX_GLOBAL_BUFFERS' > > > > > > failed. > > > > > > > > > > > > [1]Abbruch blender (core dumped) > > > > > > > > > > The number of max global buffers was bumped in 06bf56725d to fix > > > > > similar crash in luxmark. I guess it needs another bump. > > > > > > > > Hello Jan, > > > > > > > > I'm so blind... > > > > ...bumping it 48 and 64 (first try) works. 33 not ;-) > > > > We shouldn't waste to much memory. > > > > > > Feel free to post a patch. I'm not sure at which point Marek wants to > > > switch to dynamic allocation (or if at all), but there's no limit in > > > OCL so we might end up bumping this every time a new app pushes > > > against the limit. > > > > Hello Jan, > > > > comming 'happily' from vacation and think we should've this in 19.2. > > > > Marek, > > > > do we need dynamic allocation, yet? > > > > Sorry, please see attachment. > > Would be nice, if someone of you could add these lines during commit: > > > > Fixes assertion failure/crash when running Blender (2.79b) on > > clover. > > CC: mesa-sta...@lists.freedesktop.org<= ??? > > > > Greetings, > > Dieter -- Jan Vesely signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles
https://bugs.freedesktop.org/show_bug.cgi?id=77449 Bug 77449 depends on bug 100239, which changed state. Bug 100239 Summary: Incorrect rendering in CS:GO https://bugs.freedesktop.org/show_bug.cgi?id=100239 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- 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
