S3TC was working on my machine and now it is not! How that goes for reliability?
I was unsure but now you sure convinced me. I'm removing this constructor magic madness. Please leave the much more reliable system of explicitly calling initializers. Jose ________________________________________ From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca Barbieri [l...@luca-barbieri.com] Sent: Friday, April 02, 2010 16:09 To: Jose Fonseca Cc: Brian Paul; mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] How do we init half float tables? 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. ------------------------------------------------------------------------------ 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
