Re: [Mesa3d-dev] How do we init half float tables?

[Brian P. <br...@vm...>]

Luca Barbieri wrote:
> On Fri, Apr 2, 2010 at 9:51 AM, Jose Fonseca <jfo...@vm...> 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