[Mesa-dev] [RFC PATCH 4/5] ralloc: Make the C++ macros arrange for class destructors to be called.

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/21/2013 11:41 AM, Eric Anholt wrote:
> Ian Romanick <idr at freedesktop.org> writes:
> 
>> Premature "send" strikes again...
>> 
>> On 09/19/2013 05:26 PM, Ian Romanick wrote:
>>> On 09/18/2013 04:55 PM, Kenneth Graunke wrote:
>>>> Previously, almost all classes didn't actually call their
>>>> destructors, which is non-intuitive for C++ code.  Setting
>>>> them up to be called was somewhat of a pain, since it
>>>> required defining a helper function.
>>>> 
>>>> With the new macros, we can easily encapsulate this
>>>> complexity, making destructors just happen automatically.
>>>> 
>>>> Signed-off-by: Kenneth Graunke <kenneth at whitecape.org> --- 
>>>> src/glsl/ralloc.h | 8 ++++++++ 1 file changed, 8
>>>> insertions(+)
>>>> 
>>>> diff --git a/src/glsl/ralloc.h b/src/glsl/ralloc.h index
>>>> 799d3a9..82a3daa 100644 --- a/src/glsl/ralloc.h +++
>>>> b/src/glsl/ralloc.h @@ -405,15 +405,23 @@ bool
>>>> ralloc_vasprintf_append(char **str, const char *fmt, va_list
>>>> args); #endif
>>>> 
>>>> #define _RALLOC_OPS(ALLOC, TYPE)
>>>> \ +private:
>>>> \ +   static void _ralloc_##TYPE##_destructor_callback(void
>>>> *p)             \ +   {
>>>> \ +      reinterpret_cast<TYPE *>(p)->~TYPE();
>>>> \ +   }
>>>> \ +public:
>>>> \ static void* operator new(size_t size, void *mem_ctx)
>>>> \ {
>>>> \ void *p = ALLOC(mem_ctx, size);
>>>> \ assert(p != NULL);
>>>> \ +      ralloc_set_destructor(p,
>>>> _ralloc_##TYPE##_destructor_callback);    \
>> 
>> All of the IR objects share the ir_instruction destructor:
>> 
>> virtual ~ir_instruction() { }
>> 
>> Doing this universally will add two indirect function calls when
>> every object is released.  I wish we had a compiler benchmark so
>> that we could know whether this is going to hurt app start up
>> time on apps with lots of large shaders. :(
> 
> You can test this easily, thanks to shader_runner, "time", and 
> shader-db.
> 
> For a large l4d2 shader: N           Min           Max
> Median           Avg        Stddev x 1088      0.012401
> 0.024984      0.017926   0.017903518  0.0018709739 + 1088
> 0.012483      0.028997      0.017919   0.017883756  0.0019610448 No
> difference proven at 95.0% confidence

Does shader-db compile all the shaders in a single GL context?  If it
doesn't there's probably a lot of other overhead that could mask the
issue.  Still, this definitely means that compile times won't skyrocket...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iEYEARECAAYFAlI+Z9UACgkQX1gOwKyEAw9xeACcCWkedkyMwQtHjZ1u8iXytgk+
RmgAn1pXSLSJ3yUMJrwW6nuJXzTGWTKb
=6g6N
-----END PGP SIGNATURE-----