Ian Romanick <[email protected]> writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 09/21/2013 11:41 AM, Eric Anholt wrote: >> Ian Romanick <[email protected]> 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 <[email protected]> --- >>>>> 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...
I've used this many times to show overhead in compiling, I didn't see
any reason things would be different this time.
Of course, this time I happened to run the wrong version of the script,
which wasn't successfully compiling. Updated numbers:
x 4636 0.029608 0.057734 0.04657 0.044289073 0.0049689317
+ 4636 0.029798 0.057689 0.046927 0.044643953 0.0049795278
Difference at 95.0% confidence
0.00035488 +/- 0.0002025
0.801281% +/- 0.457224%
(Student's t, pooled s = 0.00497423)
So, yeah, there's a bit of a loss here, much more than I expected.
pgpcK2c5cHmKY.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
