Reliability goes both ways: using a global constructor simplifies the problem substantially, but it is only as reliable as the global constructor mechanism itself -- which it's not much given the compiler/linker magic necessary to work.
I also think that we should code generate most constat lookup tables: it avoids the initialization problem, and it saves memory when the SO is loaded in several processes as pages can be shared. For S3TC it is not a real problem: any code that exposes S3TC support needs to check if S3TC (de)compresion support is available before advertising (xxx_screen.c). Checking the support and initialization should be done by a single function. That is, if the libtxc_dxtn.so is not available the s3tc functions should *never* be called. Jose ________________________________________ From: Luca Barbieri [l...@luca-barbieri.com] Sent: Friday, April 02, 2010 2:17 To: Brian Paul Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] How do we init half float tables? Are you sure about this? I've tried doing it, and it turns out that basically every Gallium module needs this initialized. For instance: st/mesa due to glReadPixels vg/mesa due to vgReadPixels st/python due to mesa sampling several programs in rbug to dump textures to disk softpipe due to texture sampling nv50 due to static attrbutes Also, if translate did not needlessly duplicate the generic format support, it would also need it, and draw would too. Basically everything in Gallium will end up having util_format initialized, and it seems there are at least 10 different places in the code where such a call would need to be added (including strange places like rbug with call pipe*tile* which calls util_format_read*). I added it for nv50 before realizing the extent of the changes needed, but now think it is not really a feasible solution. In other words, I think this should be revisited as it results in cluttering the codebase and creating a somewhat unreliable system. I believe that we should either use the global constructor-like technique I introduced, or do the following: 1. Pregenerate half float tables 2. Initialize the S3TC function pointers to stubs that dlopen the library, initialize the function pointers to the real functions and then delegate to the real function corresponding to the stub More specifically, I think this two-step approach is superior to the global constructor, but that the global constructor technique may be useful in other cases where it is not possible to either pregenerate or have a "free initialization check" due to the S3TC dynamic loading. ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 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
