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);
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
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 fo
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.__
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 (ch
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
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
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 alre
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 b
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-
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 us
@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
https://bugs.freedesktop.org/show_bug.cgi?id=111302
Turo Lamminen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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.
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
https://bugs.freedesktop.org/show_bug.cgi?id=110357
Andrés Gómez García changed:
What|Removed |Added
CC||agoldmi...@igalia.com,
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
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 w
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 p
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
20 matches
Mail list logo
