On Thu, Apr 1, 2010 at 4:29 PM, Luca Barbieri <l...@luca-barbieri.com> wrote: > The half float conversion code initially used a global C++ constructor > to initialize the tables. > > That fails to work since ld does not get the symbol from the shared > library, so I changed to use register a global constructor from C, > using GCC- or MSVC-specific code. > > This is not necessarily the best option, but clearly putting a check > in the functions as Corbin did is a bad idea performance-wise. > > So, how should this be done? > > Options are: > 1. Revert Corbin Simpsons's commit and if anyone complains about an > unsupported compiler, implement UTIL_INIT for that compiler too > 2a. Write the init module in C++ and use portable global constructor > syntax (but with other C++-related problems) > 2b. Write an auxiliary file in C++ with a global constructor and > reference it from the C init file so the static linker pulls it from > the .a > 3. Have all modules that need half float conversion directly or > indirectly call the init functions in their init code > 4. Make the build pregenerate the tables and ship them in the executables > > Option 1: > Pros: just works, other auxiliary modules can use the same system > Cons: need to write UTIL_INIT for each compiler, only GCC and MSVC > (and compatible ones) are currently supported > > Option 2a: > Pros: no compiler-specific UTIL_INIT > Cons: significant code written in C++ instead of C and you must link > all targets with a C++ compiler or use compiler-specific options to > prevent stuff like the G++ personality causing the link to fail > > Option 2b: > Like option 2a, but > Pro: less code written in C++ > Con: need an extra C++ file for every module with data to be initialized > > Option 3: > Pros: none of the cons of the other options > Cons: cumbersome to do, must not forget to call the init function or > you get silent corruption. Init calls creep through the whole > codebase. > > Option 4: > Pros: no need to do anything at runtime, pages can be shared between OpenGL > apps > Cons: need to write a special table generator, all DRI drivers get > 10KB larger, solution does not apply to all similar problems > > I would lean for either option 1 or option 4, perhaps option 4 > considering there seems to be disagreement over option 1. > Option 4 however is likely not universally applicable (not everything > can necessarily be pregenerated), so I'd keep the UTIL_INIT code > anyway. > > Which one do we pick?
#3. Yeah, in this day and age we should have a nice way to do global constructors but we don't. This solution is simple. A debug-only assert could be used to check that the table's initialized. It's not that big of deal. -Brian ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
