<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi,</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
To give everybody a bit of background context, this email comes from <a href="https://gitlab.freedesktop.org/mesa/mesa/-/issues/2911" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;">https://gitlab.freedesktop.org/mesa/mesa/-/issues/2911</a> .</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;"><br>
</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;">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 Windows,
2) memory accounting on embedded systems. But with the unification of Gallium into Mesa, the gallium vs non-gallium division got blurred, leading to some mallocs being intercepted but not the respective frees, and vice-versa.</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I admit that trying to intercept mallocs/frees for some components and not others is error prone. We could get this going on again, it's doable, but it's possible it would keep come causing troubles, for us or others, over and over again.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;">The two needs mentioned above were mostly VMware's needs. So I've reevaluated, and I
<i>think</i> that with some trickery we satisfy those two needs differently. (Without wide spread source code changes.)</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
On the other hand, VMware is probably not the only one to have such needs. In fact Vulkan spec added memory callbacks precisely with the same use cases as ours, as seen <a href="https://www.khronos.org/registry/vulkan/specs/1.2/html/chap10.html#memory-host">https://www.khronos.org/registry/vulkan/specs/1.2/html/chap10.html#memory-host</a> which
states:</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<i>Vulkan provides applications the opportunity to perform host memory allocations on behalf of the Vulkan implementation. If this feature is not used, the implementation will perform its own memory allocations. Since most memory allocations are off the critical
path, this is not meant as a performance feature. <b>Rather, this can be useful for certain embedded systems, for debugging purposes (e.g. putting a guard page after all host allocations), or for memory allocation logging.</b></i></div>
</blockquote>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
And I know there were people interested in having Mesa drivers on embedded devices on the past (the old Tunsten Graphics having even been multiple times hired to do so), and I'm pretty sure they exist again.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Therefore, rather than shying away from memory allocation abstractions now, I wonder if now it's not the time to actually double down on them and ensure we do so comprehensively throughout the whole mesa, all drivers?</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b><br>
</b></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
After all Mesa traditionally always had MALLOC*/CALLOC*/FREE wrappers around malloc/free. As so many other projects do.<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
<span></span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
More concretely, I'd like to propose that we:</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<div>
<ul>
<li>ensure all components use MALLOC*/CALLOC*/FREE and never malloc/calloc/free directly (unless interfacing with a 3rd party which expects memory to be allocated/freed with malloc/free directly)</li><li>Perhaps consider renaming MALLOC -> _mesa_malloc etc while we're at it</li><li>introduce a mechanisms to quickly catch any mistaken use of malloc/calloc/free, regardless compiler/OS used:</li><ul>
<li>#define malloc/free/calloc as malloc_do_not_use/free<span style="font-family: Calibri, Helvetica, sans-serif; background-color: rgb(255, 255, 255); display: inline !important">_do_not_use to trigger compilation errors, except on files which explicely opt
out of this (source files which need to interface with 3rd party, or source files which implement the callbacks)</span></li><li>Add a cookie to MALLOC/CALLOC/FREE memory to ensure it's not inadvertently mixed with malloc/calloc/free</li></ul>
</ul>
<div>The end goal is that we should be able to have a memory allocation abstraction which can be used for all the needs above: memory debugging, memory accounting, and satisfying Vulkan host memory callbacks.</div>
<div><br>
</div>
<div><br>
</div>
<div>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?<br>
</div>
</div>
<div><br>
</div>
<div>Yes, that's indeed technically feasible. And is precisely the sort of trick I was planing to resort to satisfy VMware needs without having to further modify the source code. But for these tricks to work, it is absolutely
<i>imperative</i> that one statically links C++ library and STL. The problem being that if one doesn't then there's an imbalance: the malloc/free/new/delete calls done in inline code on C++ headers will be intercepted, where as malloc/free/new/delete calls
done in code from the shared object which is not inlined will not, causing havoc. This is OK for us VMware (we do it already for many other reasons, including avoiding DLL hell.) But I doubt it will be palatable for everybody else, particularly Linux distros,
to have everything statically linked.</div>
<div><br>
</div>
<div>So effectively, if one really wants to implement Vulkan host memory callbacks, the best way is to explicitly use malloc/free abstractions, instead of the malloc/free directly.</div>
<div><br>
</div>
<div><br>
</div>
<div>So before we put more time on pursuing either the "all" or "nothing" approaches, I'd like to get a feel for where people's preferences are.</div>
<div><br>
</div>
<div><span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;">Jose</span><br>
</div>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
</body>
</html>