Luca Barbieri wrote: > On Fri, Apr 2, 2010 at 9:51 AM, Jose Fonseca <jfons...@vmware.com> wrote: >> 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. > > Once it is written and works, it should just work indefinitely, since > the C++ ABI relies on it. > >> 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. > > Yes, I have done exactly this, for the reasons you describe. > The half float tables are now pre-generated by a Python script. > >> 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. > > I changed the format code to add a new "util_format_is_supported" that > allows users to query if the util_format code can pack/unpack a given > format. > > That function, if called on an s3tc format, will automatically call > the S3TC init function. > This way, users of the format helpers no longer need to know about > S3TC at all, and it will just work. > > Even if the util_format_is_supported function is not called before > reading/writing an S3TC format, the fetch/pack function pointers are > initialized to versions that will autoload the S3TC library. > > Additionally, the S3TC library may now support only a subset of the > formats. This may be even more useful as further compressed formats > are added. > > There are two areas where I'm not totally happy with the approach I did > though: > 1. Currently upon a successful load of S3TC, we hack the format > descriptions to set the is_supported bit to 1. Not sure if it is the > best way to do it. > 2. If S3TC is not available, the functions just do nothing: this is > consistent with other unsupported formats. We may however want to read > black pixels, throw an error, or read a special "error" image instead > (I'd suggest having "unsupported" unpack/pack functions and pointing > all unsupported formats to them) > > Also, I think we should remove all the Mesa internal format code and > make it use util_format instead, unless there is really a good reason > to duplicate it all. > Same thing for util_half.
So far, there are no dependencies on Gallium in core Mesa. We've talked about refactoring some of the Gallium code into a separate module that'd be sharable between Gallium and Mesa. The format code would probably fit into that. -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
