Hi,
On Tue, 2020-05-12 at 14:36 +, Jose Fonseca wrote:
> From: mesa-dev on behalf of
> Tamminen, Eero T
> I've done a lot of resource usage analysis at former job[1], but I've
> never had needed anything like that. malloc etc all reside in a
> separate shared library from Mesa, so calls to
On 05/11/2020 10:13 AM, Jose Fonseca wrote:
> Hi,
>
> To give everybody a bit of background context, this email comes from
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/2911 .
>
> The short story is that Gallium components (but not Mesa) used to have
> their malloc/free calls intercepted, to
On Tue, 2020-05-12 at 15:11 +0200, Erik Faye-Lund wrote:
> On Tue, 2020-05-12 at 06:42 -0600, Brian Paul wrote:
> > On 05/12/2020 04:17 AM, Erik Faye-Lund wrote:
> > > On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote:
> > > > On 05/07/2020 04:33 AM, Erik Faye-Lund wrote:
> > > > > Hey Brian
> >
From: mesa-dev on behalf of Tamminen,
Eero T
Sent: Monday, May 11, 2020 21:19
To: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] RFC: Memory allocation on Mesa
Hi,
On Mon, 2020-05-11 at 16:13 +, Jose Fonseca wrote:
> Some might retort: why not
I have given some thought as to how we could do it in our compiler
stack. It basically comes down to adding a new type of ralloc context
which takes a Vulkan allocator struct. If the parent context has such
a struct, that allocator gets used. It wouldn't be that hard; I've
just not gone to the
From: Timur Kristóf
Sent: Monday, May 11, 2020 18:06
To: Jose Fonseca ; ML mesa-dev
Cc: erik.faye-l...@collabora.com
Subject: Re: [Mesa-dev] RFC: Memory allocation on Mesa
On Mon, 2020-05-11 at 16:13 +, Jose Fonseca wrote:
> Some might retort: why not
You raise a good point about LLVM. It can easily be the biggest memory
consumer (at least transiently) for any driver that uses it, so the value of
implementing Vulkan allocation callbacks without is indeed dubious.
Jose
From: Jason Ekstrand
Sent: Monday, May
On Tue, May 12, 2020 at 4:04 AM Daniel Stone wrote:
> Hi Brian,
>
> On Fri, 8 May 2020 at 15:30, Brian Paul wrote:
> > Done. easydns says it may take up to 3 hours to go into effect.
>
> Thanks for doing this! Could you please add the following TXT records
> as well (note that they're FQDN, so
On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote:
> On 05/07/2020 04:33 AM, Erik Faye-Lund wrote:
> > Hey Brian
> >
> > TLDR; are you OK with me moving forward with the rework of
> > mesa3d.org?
>
> Yes...
>
Cool! We've now set up a repo here:
https://gitlab.freedesktop.org/mesa/mesa3d.org
Hi Brian,
On Fri, 8 May 2020 at 15:30, Brian Paul wrote:
> Done. easydns says it may take up to 3 hours to go into effect.
Thanks for doing this! Could you please add the following TXT records
as well (note that they're FQDN, so you might want to chop the
trailing '.mesa3d.org' from the first
On Tue, 2020-05-12 at 08:51 +, Tamminen, Eero T wrote:
> Hi,
>
> On Tue, 2020-05-12 at 10:36 +0200, Timur Kristóf wrote:
> > On Mon, 2020-05-11 at 20:19 +, Tamminen, Eero T wrote:
> > > I've done a lot of resource usage analysis at former job[1], but
> > > I've
> > > never had needed
Hi,
On Tue, 2020-05-12 at 10:36 +0200, Timur Kristóf wrote:
> On Mon, 2020-05-11 at 20:19 +, Tamminen, Eero T wrote:
> > I've done a lot of resource usage analysis at former job[1], but
> > I've
> > never had needed anything like that. malloc etc all reside in a
> > separate shared library
On Mon, 2020-05-11 at 20:19 +, Tamminen, Eero T wrote:
> Hi,
>
> On Mon, 2020-05-11 at 16:13 +, Jose Fonseca wrote:
> > Some might retort: why not just play some tricks with the linker,
> > and
> > intercept all malloc/free calls, without actually having to modify
> > any source code?
> >
13 matches
Mail list logo
