Re: [Mesa-dev] RFC: Memory allocation on Mesa

[Jose Fonseca]

> What are the exact use-cases for Mesa specific allocation data?

In general, the use case is to implement Vulkan allocation callbacks.

Our particular use case is memory accounting: there is a fixed memory budget, 
so we need to keep track (not as an external tool but in the application 
itself) of all the memory consumed by every component.   So components can't 
just call malloc, but instead other memory allocating functions, which ensure 
they stay within their budget.

At any rate, I believe we'll pursue's Brian' u_trackmem.h approach for now.


Jose


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 
> 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 them always cross
> dynamic library boundary and therefore all of them can be caught with
> the dynamic linker features (LD_PRELOAD, LD_AUDIT...).
>
> True, one can easily intercept all mallocs using that sort of dynamic
> linking tricks, when doing full application interception.  (I even
> have done some of the sort on 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjrfonseca%2Fmemtrail&data=02%7C01%7Cjfonseca%40vmware.com%7C7803192c4bf349748ccd08d7f69f8305%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637249037275021774&sdata=Ep9otfr5LTrE8w2a3S1E12MhFHkt8Xvawp%2BxLbrciQs%3D&reserved=0
>  ,
> mostly to hunt down memory leaks on LLVM.) But the goal here is to
> intercept the OpenGL/Vulkan driver malloc calls alone.  Not the
> application mallocs.  Which is difficult to segregate when doing
> whole application interception.

Only reason to do this that I can think of would be to report some Mesa
specific metrics to an application at run-time.  But that will need
careful thought on how *applications* are supposed to *use* that data,
otherwise it's just "garbage in, garbage out".

What are the exact use-cases for Mesa specific allocation data?


> For simplicity imagine you have only these shared objects:
>application (not controlled by us)
>libVulkan.so
>libstdcc++.so
>libc.so
>
> Now imagine you're intercepting malloc doing some sort of LD_PRELOAD
> interception, and malloc is called.  How do you know if it's a call
> done by the Vulkan driver, hence should call the callback, or one
> done by the application, hence not call the Vulkan allocation
> callback.
>
> One can look at the caller IP address, but what if the caller is in
> libstdc++ which is used both by Vulkan and the app, is not
> immediately clear which to bill the memory.  One would need to walk
> back the stack completely, which is complicated and not very
> reliable.

Over decade ago it was unreliable, but not anymore.  Even stripped
binaries contain the frame information section (I think it's needed
e.g. for handling C++ exceptions).  So nowadays it's simple to use, and
Glibc has a function for it.

For analysis, you don't do filtering while tracing, as that's too
limiting, you do it in post-processing phase.


If you really need to do run-time per-library filtering, you could do
it based on the backtrace addresses, and whether they fall within the
address range where the library you're interested about is mapped.

For that, you need to overload library loading, so you can catch when
Mesa gets loaded, and find out its (address-space-randomized) load
address range.


> Imagine one guesses wrong -- the malloc interceptor believes the
> malloc call is done by the Vulkan driver, and calls the application
> callback, which then calls malloc again, and the interceptor guesses
> wrong again, therefore an infinite recursion loop.

If you find your own code addresses from the backtrace, STOP. :-)


> Could you be confusing this with trying to catch some Mesa specific
> function, where dynamic linker can catch only calls from application
> to
> Mesa, but not calls within Mesa library itself (as they don't cross
> dynamic library boundary)?
>
> My goal from the beginning is intercepting all mallocs/frees done by
> Mesa OpenGL/Vulkan driver, and only those.

If this is for analysis, I would do it in post-processing phase (with
sp-rtrace).  Just ask post-processor to filter-in allocation backtraces
going through the library I'm interested about.


...
> Yes, indeed Linux has much better tooling for this than
> Windows.  Note that memory debugging on Windows is just one of our
> needs.  The other being able to run Mesa driver on an embedded system
> with fixed amount of memory (a separate budget for Mesa mallocs.)

If that embedded target is still running something Linux-like, but
doesn't have enough memory for collecting the data, I would just stream
the data

[Mesa-dev] [radeonsi] Re: glthread: upload non-VBO vertices and indices for non-Indirect non-IBM draws - BISECTED

[Dieter Nützel]

Hello Marek,

this was time and nerve consuming (with all the LLVM 11 
revert/re-revert).

FreeCAD vbo rendering bugs.

Mesa-20.1-rc4 is fine (sure)

Mesa git with #2840bc3065b reverted (glthread_draw.c deleted), too.

/opt/mesa> git bisect bad
2840bc3065b9e991b2c5880a2ee02e2458a758c4 is the first bad commit
commit 2840bc3065b9e991b2c5880a2ee02e2458a758c4
Author: Marek Olšák 
Date:   Fri Mar 6 16:56:54 2020 -0500

glthread: upload non-VBO vertices and indices for non-Indirect 
non-IBM draws


This is basically the same thing u_vbuf does.

Part-of: 



 src/mapi/glapi/gen/ARB_base_instance.xml   |   9 +-
 .../glapi/gen/ARB_draw_elements_base_vertex.xml|  12 +-
 src/mapi/glapi/gen/ARB_draw_instanced.xml  |   6 +-
 src/mapi/glapi/gen/gl_API.xml  |  15 +-
 src/mesa/Makefile.sources  |   1 +
 src/mesa/main/glthread.c   |   7 +
 src/mesa/main/glthread.h   |   1 +
 src/mesa/main/glthread_draw.c  | 982 
+

 src/mesa/meson.build   |   1 +
 9 files changed, 1006 insertions(+), 28 deletions(-)
 create mode 100644 src/mesa/main/glthread_draw.c

Next 'night' I'll make an entry at gitlab, if you don't outpace me...;-)

Dieter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev