ose
From: mesa-dev on behalf of Tamminen,
Eero T
Sent: Tuesday, May 12, 2020 19:08
To: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] RFC: Memory allocation on Mesa
Hi,
On Tue, 2020-05-12 at 14:36 +, Jose Fonseca wrote:
> From: mesa-dev on behalf of
> Tamminen, Eero T
&g
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
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:
acks without is indeed dubious.
>
> Jose
>
>
> From: Jason Ekstrand
> Sent: Monday, May 11, 2020 17:29
> To: Jose Fonseca
> Cc: ML mesa-dev ;
> erik.faye-l...@collabora.com
> Subject: Re: [Mesa-dev] RFC: Memory allocation on Mesa
>
>
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:
11, 2020 17:29
To: Jose Fonseca
Cc: ML mesa-dev ; erik.faye-l...@collabora.com
Subject: Re: [Mesa-dev] RFC: Memory allocation on Mesa
Sorry for the top-post.
Very quick comment: If part of your objective is to fulfill Vulkan's
requirements, we need a LOT more plumbing than just
MALLOC/CALLOC
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?
> >
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
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?
>
> Yes, that's indeed technically feasible. And is precisely the sort
> of
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?
>
> Yes, that's indeed technically feasible. And is precisely the sort
> of trick
Sorry for the top-post.
Very quick comment: If part of your objective is to fulfill Vulkan's
requirements, we need a LOT more plumbing than just
MALLOC/CALLOC/FREE. The Vulkan callbacks aren't set at a global level
when the driver is loaded but are provided to every call that
allocates anything
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 satisfy certain needs: 1) memory debugging on
15 matches
Mail list logo
